Installing Connectware (Kubernetes)

Install Connectware on a Kubernetes cluster using Helm.

This guide walks you through installing Connectware on a Kubernetes cluster using Helm charts. The installation process includes configuring your Helm repository, customizing deployment settings in a values.yaml file, and verifying the installation.

Prerequisites

Before installing Connectware, make sure to meet the following requirements:

• Connectware license key is available.

• Helm version 4 is installed on your system.

• kubectl is installed on your system.

• A Kubernetes cluster that meets the cluster requirements.

• A chosen Kubernetes namespace for the installation (e.g., cybus).

• A chosen installation name (e.g., connectware).

Throughout this guide, command examples use variables like ${NAMESPACE}, ${INSTALLATION_NAME}, and ${REPO_NAME}. Replace these with your actual values. For example, replace ${NAMESPACE} with cybus if that is your chosen namespace.

Overview of the Installation Process

To install Connectware on Kubernetes, complete the following steps:

1. Choose a chart version.

2. Configure a values.yaml file.

3. Install Connectware.

4. Verify the installation.

5. Log into Connectware for the first time.

Choosing a Chart Version

When installing Connectware, you can either use the latest chart version or pin to a specific version.

When you do not specify a chart version, Helm installs the latest chart, which targets the latest Connectware release.

To install a specific version, look up your target Connectware version in the Compatibility Matrix, find the matching Helm chart version, and install that version of the chart with the --version flag.

For production environments, install a specific chart version. This gives you reproducible deployments and prevents unintended upgrades.

Configuring the values.yaml File

The values.yaml file configures your Connectware deployment through Helm. Use it to customize deployment parameters, manage resources, and configure version settings.

This guide focuses on basic Kubernetes configuration and commonly used parameters.

We recommend that you store the values.yaml file in a version control system.

Creating a Copy of the Default values.yaml File

A Helm chart includes default configuration values. We recommend creating a copy of the default values.yaml file named default-values.yaml for reference, and a new empty values.yaml file for your customizations.

• Extract the default values and store them in default-values.yaml via the following command:

Example

helm show values oci://repo.cybus.io/charts/connectware > default-values.yaml

Creating a values.yaml File

After creating the default-values.yaml file, create an empty values.yaml file for your custom configuration.

• Create and open the file with your preferred editor via the following command. This example uses vi. Substitute with your preferred editor:

Example

vi values.yaml

Specifying the License Key

A valid license key is required to install Connectware.

Choosing a Method

You have the following methods for providing your license key. Choose the method that best fits your security and operational requirements:

• Method 1 - Plaintext License Key: For quick testing and development environments.

• Method 2 - Kubernetes Secret: For production environments where secrets should be managed separately from configuration files.

Method 1 - Plaintext License Key

• Add your license key directly in the values.yaml file. Replace ${LICENSE_KEY} with your actual license key.

values.yaml

global:
  licenseKey: ${LICENSE_KEY}

Method 2 - Kubernetes Secret

Using this method, you manage your license key within your own workflow. You only provide Connectware with the name of a Kubernetes Secret that contains the key. This makes it suitable for production environments where security is a top concern.

When using this method, you must create at least one Secret:

• A generic Secret for the license key itself (required)

• A Docker registry Secret for pulling Connectware container images (optional, see warning below)

Unlike Method 1, the Helm chart does not automatically generate the image pull Secret when using an existing Kubernetes Secret for the license key. You must create it manually in step 2 below, unless you are using a custom registry that does not require authentication.

1. Create a generic Secret containing your license key under the key licenseKey. Replace ${LICENSE_KEY} with your actual license key, ${LICENSE_SECRET_NAME} with your chosen Secret name, and ${NAMESPACE} with your target namespace.

kubectl create secret generic ${LICENSE_SECRET_NAME} \
  --from-literal=licenseKey=${LICENSE_KEY} \
  -n ${NAMESPACE}

1. Optional: Create the Docker registry Secret to allow your cluster to pull Connectware container images. Replace ${REGISTRY_SECRET_NAME} with your chosen Secret name. For the Cybus registry, use your Connectware license key as the password and license as the username. Skip this step only if you are using a custom registry that does not require authentication. If using a custom registry with authentication, adjust the --docker-server, --docker-username, and --docker-password values accordingly.

kubectl create secret docker-registry ${REGISTRY_SECRET_NAME} \
  --docker-server=registry.cybus.io \
  --docker-username=license \
  --docker-password=${LICENSE_KEY} \
  -n ${NAMESPACE}

1. Reference the Secrets in your values.yaml file. Replace ${LICENSE_SECRET_NAME} with your chosen license Secret name. If you completed step 2, also replace ${REGISTRY_SECRET_NAME} with your chosen registry Secret name. If you skipped step 2, omit the image.pullSecrets section.

values.yaml

global:
  existingLicenseKeySecret: ${LICENSE_SECRET_NAME}
  image:
    pullSecrets:
      - name: ${REGISTRY_SECRET_NAME}

Configuring DNS Names in Helm Values

When you are using Connectware's auto-generated TLS server certificate (cybus_server.crt), configure global.ingressDNSNames to define the hostnames Connectware includes in the certificate's Subject Alternative Names (SAN) list. External agents need these hostnames to connect to the Connectware control plane.

Providing your own TLS certificate

If you provide your own TLS server certificate, global.ingressDNSNames has no effect. Add the required hostnames to your certificate's SAN list directly.

• Set the global.ingressDNSNames list in your Helm values to include all hostnames used for Connectware access.

Example

If Connectware is accessible at hostname company.io, set the Helm value to:

values.yaml

global:
  ingressDNSNames:
    - company.io

Hostname Formats

You can include multiple hostnames in the list. The certificate includes all specified names in its SAN section.

The configuration accepts various hostname formats:

• Wildcards (e.g., *.company.io)

• Subdomains (e.g., connectware.company.io)

• Custom hostnames (e.g., localhost)

Example

values.yaml

global:
  ingressDNSNames:
    - company.io
    - localhost
    - *.company.io
    - connectware.company.io
    - 192.168.100.42

Specifying the NATS Streaming Server Cluster Replica Count (Optional)

Connectware uses a NATS streaming server cluster for inter-service communication on the control plane. By default, the cluster runs with three replicas.

You can configure an odd number of replicas to suit your environment:

• Increase to five for higher redundancy. Five replicas tolerate two simultaneous failures (N+2) instead of one (N+1).

• Reduce to one for lightweight test environments. A single-node setup provides no redundancy.

For production, three (the default) or five replicas are typical.

You can only set the replica count at initial installation

The value defines the NATS cluster topology and is shared across many Connectware components, so it cannot be changed later. Do not attempt to scale the nats StatefulSet manually.

• In the values.yaml file, set the replica count via nats.replicas.

Example

values.yaml

nats:
  replicas: 5

Specifying the Broker Cluster Secret (Optional)

Connectware secures the internal broker cluster using a cluster secret.

Treat the broker cluster secret with the same care as a password. Store it securely and restrict access to authorized personnel only.

Choosing a Configuration Method

You have the following methods for configuring the broker cluster secret. Choose the method that best fits your security and operational requirements:

• Method 1 - Auto-Generated Secret (Recommended): Helm generates a cryptographically secure random value at install time. No configuration required. Best for most installations.

• Method 2 - Plaintext Secret in Helm Values: You set the secret directly in your values.yaml file. Use only in non-production environments, since the value is stored unencrypted.

• Method 3 - Existing Kubernetes Secret: You create a Kubernetes Secret beforehand and reference it by name. Suits production environments that use external secret management systems or GitOps workflows.

Method 1 - Auto-Generated Secret (Recommended)

For most installations, let Helm automatically generate a secure random secret. This is the simplest and most secure approach for new deployments.

• Leave the broker cluster secret configuration empty in your values.yaml file. Helm generates and stores the secret automatically during installation.

Helm stores the auto-generated secret in a Kubernetes Secret that persists across Helm upgrades. To retrieve it later, run kubectl get secret -n ${NAMESPACE} -l app.kubernetes.io/name=broker-cluster-secret -o yaml.

Method 2 - Plaintext Secret in Helm Values

Use this method for development environments or when you need to specify a known secret value for migration or testing purposes.

This method stores the secret in plaintext in your values.yaml file. Only use this in non-production environments or ensure your values file is stored securely.

• In the values.yaml file, specify the broker cluster secret in the Helm value broker.clusterSecret:

Example

values.yaml

broker:
  clusterSecret: Uhoo:RahShie6goh4eid # example value

Method 3 - Existing Kubernetes Secret

Use this method for production environments where you manage secrets through a dedicated secret management system or GitOps workflow.

1. Create the Kubernetes Secret in the same namespace where you will install Connectware. The Secret must contain a key named clusterSecret with your secret value. Replace ${SECRET_NAME} with your chosen Secret name and ${CLUSTER_SECRET} with your actual cluster secret:

Example

kubectl create secret generic ${SECRET_NAME} \
  --from-literal=clusterSecret="${CLUSTER_SECRET}" \
  -n ${NAMESPACE}

1. In the values.yaml file, reference the Secret name in the Helm value broker.existingClusterSecret:

Example

values.yaml

broker:
  existingClusterSecret: ${SECRET_NAME}

When using an existing Secret, Helm does not create or manage the cluster secret. You are responsible for ensuring the Secret exists before installation and for managing it throughout the lifecycle.

Specifying the Broker Cluster Replica Count (Optional)

By default, Connectware uses three nodes for the broker cluster that moves data. You can specify a custom number of broker nodes. For example, increase the broker nodes to handle higher data loads or decrease the broker nodes for a testing environment.

• In the values.yaml file, specify the number of broker nodes in the Helm value broker.replicas.

Example

values.yaml

broker:
  replicas: 5

Specifying Which StorageClass Connectware Should Use (Optional)

A Kubernetes cluster can contain several StorageClasses. You can specify which StorageClass Connectware should use.

• In the values.yaml file, specify the StorageClass in the Helm value global.persistence.storageClassName.

Example

values.yaml

global:
  persistence:
    storageClassName: gp2 # example value

There are several configuration parameters to control the StorageClass of each volume that Connectware uses.

Specifying CPU and Memory Resources (Optional)

By default, Connectware is configured with resource requests only, allowing it to burst and utilize available node resources when needed. To control the CPU and memory available to Connectware, set the Kubernetes requests and limits values under a component's resources Helm value, such as protocolMapper.resources.

Adjusting CPU and memory resources can impact the performance and availability of Connectware. When you customize the settings for CPU and memory resources, make sure that you monitor the performance and make adjustments if necessary.

For per-chart syntax, defaults, and examples, see Configuring Compute Resources. For guidance on measuring actual usage and right-sizing these values, see Right-Sizing Kubernetes Resources for Connectware.

Installing Connectware

After you have configured your values.yaml file, deploy Connectware to your Kubernetes cluster.

• Run the following command, specifying your installation name and target namespace:

Example

helm install ${INSTALLATION_NAME} oci://repo.cybus.io/charts/connectware --version ${VERSION} -f ./values.yaml -n ${NAMESPACE} --create-namespace

Replace ${VERSION} with the chart version from the Compatibility Matrix. Omit --version to install the latest available chart version.

Result: Connectware deploys to your cluster according to your kubectl configuration.

Verifying the Connectware Installation

Monitor the Connectware installation progress to ensure everything runs smoothly and identify any potential issues.

Monitoring the Installation Progress

The installation typically takes a few minutes. Choose one of these monitoring options:

• To monitor the current status of the installation process, enter the following command:

kubectl get pods -n ${NAMESPACE}

• To monitor the continuous progress of the installation process, enter the following command. This command refreshes every five seconds to reflect the current status:

while true; do clear; kubectl get pods -n ${NAMESPACE}; sleep 5; done

• To stop monitoring the continuous progress of the installation process, press Ctrl+C.

Pod Stages During Installation

During the Connectware installation, pods progress through these stages:

• Pending

• PodInitializing

• ContainerCreating

• Init:x/x

• Running

When pods reach Running status, they complete their startup process before reporting as ready. All pods must reach Running status with all containers ready. This is shown when the READY column displays matching numbers (e.g., 1/1).

Example

kubectl get pods -n ${NAMESPACE}

NAME	READY	STATUS	RESTARTS	AGE
admin-web-app-7cd8ccfbc5-bvnzx	1/1	Running	0	3h44m
auth-server-5b8c899958-f9nl4	1/1	Running	0	3m3s
broker-0	1/1	Running	0	3h44m
broker-1	1/1	Running	0	2m1s
connectware-ingress-7784b5f4c5-g8krn	1/1	Running	0	21s
container-manager-558d9c4cbf-m82bz	1/1	Running	0	3h44m
ingress-controller-6bcf66495c-l5dpk	1/1	Running	0	18s
postgresql-0	1/1	Running	0	3h44m
protocol-mapper-67cfc6c848-qqtx9	1/1	Running	0	3h44m
service-manager-f68ccb767-cftps	1/1	Running	0	3h44m
system-control-server-58f47c69bf-plzt5	1/1	Running	0	3h44m
workbench-5c69654659-qwhgc	1/1	Running	0	15s

Result: When all pods show Running status with matching READY values, Connectware is installed and started. You can now access the Admin UI for additional configuration or verification.

Troubleshooting Pod Stages

If a pod is in a different state than expected or if it is stuck at a certain stage for more than three minutes, there might be an issue.

• To investigate the pod status, enter the following command:

kubectl describe pod ${PODNAME} -n ${NAMESPACE}

For help on solving issues, see Troubleshooting Connectware on Kubernetes.

Logging Into Connectware for the First Time

Access the Admin UI through the Kubernetes LoadBalancer Service. In your new Connectware installation, the LoadBalancer is named connectware. How to access the LoadBalancer depends on which LoadBalancer provider your cluster offers.

1. Check if your load balancer provider has connected to your Connectware service via the following command:

kubectl -n ${NAMESPACE} get svc/connectware

1. Depending on the result, do one of the following:

   1. If your IP address or hostname is displayed in the EXTERNAL-IP column, you can access the Admin UI through it.

   2. If no load balancer provider is available in your cluster, you can add an external load balancer.

2. To verify that the installation was successful, enter the following command to forward the service to your local machine through kubectl:

kubectl -n ${NAMESPACE} port-forward svc/connectware 10443:443

1. Access the Admin UI at https://localhost:10443. Connectware uses its own PKI infrastructure by default.

2. Accept the certificate warning in your browser.

3. Retrieve the initial password. During installation, Connectware generates a random password and stores it in the Kubernetes Secret connectware-initial-password as a double base64-encoded value. The following command retrieves and decodes it:

kubectl -n ${NAMESPACE} get secret connectware-initial-password -o jsonpath="{.data.initialPassword}" | base64 -d | base64 -d

1. In the Admin UI, log in with username admin and the password retrieved in the previous step.

Immediately change the default username and password after your first login.

1. To change the username and password, see Changing Usernames and Changing User Passwords.

2. Navigate to System > Status and verify all components show Running status.

Result: Your Connectware installation is ready to use.

For more information about LoadBalancer services, see LoadBalancer (Kubernetes documentation).