Adding Sidecars and Volumes

Attach sidecar containers and shared volumes to Connectware and Connectware agent components for advanced Kubernetes scheduling.

Sidecars extend Connectware component functionality by running auxiliary containers alongside the main application container within the same pod.

Advanced configuration, use with caution

These configurations require deep Kubernetes and Connectware expertise. Misconfiguration can compromise system stability, security, and functionality. Always thoroughly test before applying to production environments.

Cybus does not officially support modified installations. We recommend informing Customer Success of your planned changes to identify compatibility concerns.

When to Use Sidecars

Sidecars run continuously alongside the main container, sharing the pod's lifecycle. Use sidecars when you need auxiliary processes that support the main application.

Common use cases:

• Separation of concerns: Log shipping, metrics collection, or security scanning that runs continuously alongside the main application.

• Dynamic configuration and secrets syncing: Fetch, rotate, or sync data (such as TLS certificates) from external systems into a shared volume.

• Network proxying: Intermediary process (Envoy, Nginx) to handle TLS termination or routing for a specific Connectware component.

Configuration Values

The following Helm values attach sidecar containers and storage to Connectware components:

Value	Description
extraContainers	List of containers to run within the pod alongside the main Connectware container. Accepts standard Kubernetes container specifications.
extraVolumes	List of volumes attached at the pod level. Can be mounted by both the main Connectware container and sidecars.
extraVolumeMounts	Volume mounts for the main Connectware container. Requires corresponding volume definition in extraVolumes.

Volume mounts require a matching volume

If you define extraVolumeMounts, you must also define the corresponding volume in extraVolumes. Defining a volume mount without its underlying volume definition causes the deployment to fail.

Adding Sidecar Containers

Attach sidecar containers to a component using the extraContainers Helm value. This value accepts a standard Kubernetes container definition list.

Overriding defaults with the connectware-agent Helm chart

When configuring connectware-agent, values set on a specific agent in protocolMapperAgents[] completely replace values from protocolMapperAgentDefaults. This applies to extraContainers, extraVolumes, and extraVolumeMounts. Set an empty list ([]) on a specific agent to exclude it from defaults.

Example: Adding a Basic Sidecar Container

The following tabs show how to configure sidecar containers for the connectware Helm chart and the connectware-agent Helm chart.

connectware Helm Chart

values.yaml

# Note: 'authServer' is used as an example, but this configuration
# is applicable to any Connectware component.
authServer:
  extraContainers:
    - name: tls-proxy
      image: registry.my-company.tld/tls-proxy/tls-proxy:latest
      env:
        - name: 'PROXY_HANDLE_TCP_CONNECTIONS'
          value: 'true'

connectware-agent Helm Chart

Adding Shared Volumes

If your sidecar needs to share data with the main Connectware component or main agent container or requires its own storage, you can define pod-level volumes using extraVolumes. This Helm value accepts standard Kubernetes volume definitions (such as emptyDir, secret, configMap, or persistentVolumeClaim).

Once a volume is defined, you can mount it into the main Connectware component or main agent container using extraVolumeMounts as described in Kubernetes documentation, and mount it into your sidecar using a standard volumeMounts block within the extraContainers definition.

Example: Sharing an emptyDir Volume

The following tabs show how to share volumes between the main container and sidecars for the connectware Helm chart and the connectware-agent Helm chart.

connectware Helm Chart

values.yaml

# Note: 'authServer' is used as an example, but this configuration
# is applicable to any Connectware component.
authServer:
  extraVolumes:
    - name: shared-data
      emptyDir: {}
  extraVolumeMounts:
    - name: shared-data
      mountPath: /opt/connectware/shared
  extraContainers:
    - name: data-processor
      image: busybox:latest
      command: ['sh', '-c', 'while true; do date > /sidecar-data/time.txt; sleep 10; done']
      volumeMounts:
        - name: shared-data
          mountPath: /sidecar-data

connectware-agent Helm Chart

Using Existing Kubernetes Volumes

You can use the extraVolumes Helm value to mount existing Kubernetes resources into your sidecars without modifying the main Connectware component or the main agent container's mounts.

Example: Mounting a ConfigMap

The following tabs show how to mount existing Kubernetes resources for both Helm charts.

connectware Helm Chart

Example: Mounting a ConfigMap into a sidecar

values.yaml

# Note: 'authServer' is used as an example, but this configuration
# is applicable to any Connectware component.
authServer:
  extraVolumes:
    - name: custom-config-volume
      configMap:
        name: my-custom-config
  extraContainers:
    - name: custom-app
      image: my-company/custom-app:1.0.0
      volumeMounts:
        - name: custom-config-volume
          mountPath: /app/config

connectware-agent Helm Chart

Verification

After applying your changes, verify that sidecars are running successfully:

# Check pod status and container list
kubectl get pods -n ${NAMESPACE}

# View sidecar logs
kubectl logs -n ${NAMESPACE} ${POD_NAME} -c ${SIDECAR_NAME}

# Describe the pod to see all containers and their status
kubectl describe pod -n ${NAMESPACE} ${POD_NAME}

Replace ${NAMESPACE} with your Connectware namespace, ${POD_NAME} with the pod name, and ${SIDECAR_NAME} with the name you defined in extraContainers.

Result

All containers (main Connectware component and sidecars) show a Running status in the pod description. Both the main Connectware container and sidecars start together and run continuously. If a sidecar fails, it restarts according to the pod's restart policy.