Prerequisites for Component Pack

On a very high level, to install and successfully run HCL Component Pack, you will need HCL Connections plus the following additional resources:

  • Fully functioning Kubernetes cluster using Docker or containerd as the container runtime, and support for persistent volumes.
  • Docker Registry for storing Component Pack images and later pulling them by Kubernetes workers.
  • One machine with kubectl and Helm v3 installed and configured and at least 50G of free space. This machine can be any machine in the cluster, but must be used exclusively for Component Pack installation, configuration, and upgrades.

Supported Kubernetes platforms

How to install Kubernetes?
Official Kubernetes documentation and terminology distinguish between learning and production environments, and it is best if you follow the official documentation on how to set up Kubernetes. Note that Component Pack needs to run in both learning and production environments.
Supported container runtimes
Docker and containterd are supported as the container runtime for Kubernetes. Kubernetes 1.19 requires a Docker runtime, but later versions can use containerd as the runtime.See the Kubernetes documentation for the installation instructions for Docker. Docker versions depend heavily on the version of Kubernetes that you are going to use.
If you are setting up the cluster yourself, see which Docker versions are supported by which version of Kubernetes in the Kubernetes documentation.
Supported Kubernetes versions
Component Pack for Connections was tested and is supported on Kubernetes 1.19 using a Docker runtime, and Kubernetes 1.20 and 1.21 using a containerd runtime. Component Pack for Connections follows the same Kubernetes support pattern that Kubernetes itself is following.
Supported Kubernetes flavors
Component Pack is designed to work with Kubernetes platforms that are using Docker as the container runtime. To ensure compatibility, all development and testing is done internally on the vanilla Kubernetes installations, without preference for any specific provider.
However, HCL is always working on optimizing the Component Pack experience, which includes lowering costs for our customers, and is therefore trying to ensure that some vendor-specific options are supported as well.
Supported Kubernetes network plugins
Component Pack is developed and tested using Calico as the Kubernetes CNI, but you can use another CNI if it better suits your use case.
Persistent volumes
Component Pack uses persistent volumes to store Connections data. To set up persistent volumes for Component Pack, see the section on persistent volumes in the HCL Connections documentation. Persistent volumes are a firm requirement for Component Pack.
Cluster layout considerations
Because Component Pack runs on Kubernetes, it can run on one or multiple servers, depending on how your Kubernetes cluster is set up.

Please note that Elasticsearch is a somewhat of a special case. Elasticsearch can be used as a backend for the Orient Me component and as a part of the Elastic Stack installation. Elasticsearch itself can use most of the memory (Component Pack will scale three pods, and each can use up to 8G of RAM). In that case it is best to have a separate Kubernetes worker for only the Elasticsearch-tainted-as-infrastructure node, with scheduling disabled. The same requirement applies when you extend your deployment to include Elastic Stack. In that case Elasticsearch and the rest of Elastic Stack should be on the same dedicated node (or nodes) where scheduling all other types of pods is disabled.

However, if you don't plan to use a full-blown distributed cluster, you can also try to locate Elastic Stack services with the rest of pods. If there are any performance issues after the cluster is fully provisioned and Component Pack deployed, you can always add new infrastructure workers, and Elastic Stack (and Elasticsearch) pods will be rescheduled there.

Supported Helm Versions

Component Pack supports Helm v3.