Overview

CommandK's Kubernetes integration seamlessly synchronizes application secrets with deployments within your Kubernetes cluster.

Integration Modes with Kubernetes

Mode	Description
Kubernetes Operator	The Kubernetes operator can be installed in every Kubernetes cluster you wish to manage. The operator will deliver secrets to a K8S Secret object. You are further required to modify every application's deployment manifest file to mount the K8S Secret as an environment variable or a volume mount.
Kubernetes Agent	The agent is installed in every Kubernetes cluster. Each agent is responsible for syncing the application's secrets to the Kubernetes deployment via K8S Secret. With the Kubernetes agent, CommandK can deliver the secrets to your pods without any additional code changes. The agent uses an admission controller to mount the secrets by modifying the application manifest.

Association between K8S Namespace & Environments

Each namespace of the Kubernetes cluster can be associated at most one environment in CommandK. This association allows for the mapping of the CommandK App with a Kubernetes deployment and facilitates secret synching.

Linking CommandK App & K8S Objects

Each environment of the CommandK app can be associated with one or more Kubernetes deployments from the namespace associated with the environment.

Deployment Configuration

Deployment Strategy

Deployment strategies are ways to inject secrets into Kubernetes deployments. Deployment Strategy are configured for an application for all environments.The are two primary strategies that we support -

Environment Variables
Secrets are provided as environment variables within containers. These environment variables are accessible within your application's runtime environment.
Volume Mount
Secrets are injected as files mounted into containers. When you use volume mounts to inject secrets, the files inside the mounted volume always reflect the latest secret values. Applications that read these files can access the updated secrets without requiring pod restarts. For applications that do not automatically watch for file changes, you may need to restart the pods to ensure they use the updated secrets from the mounted files.

Volume Mount is supported for Version v0.1.4, and later.

Reload Strategy

Reload strategy specifies how changes to secrets are applied to affected deployments. Reload Strategies are configured for an application at an environment level. CommandK supports Auto, and Manual reload strategies -

Auto-Reload
In the case of auto-reload, when you update a secret, the changes are automatically and immediately applied to your deployment. This means that as soon as you update a secret, the changes trigger a deployment rollout and the affected pods are restarted automatically. Your application starts using the updated secrets without manual intervention.

Auto reload feature is only available for Kubernetes deployments, for Version v0.1.4 and later.
Manual Reload
Manual reload puts you in control. In case of manual reload, Secrets are only delivered to your cluster and you must manually trigger the deployment restart. This gives you the flexibility to choose when the updated secrets are applied to your application.

In CommandK, when you make changes to your deployment strategy, or reload type for a specific application or environment, those changes are scheduled to be applied during the next delivery of secrets, not immediately.

Let's break down what this means in practice:

Deployment Strategy Change: If you decide to switch your deployment strategy (e.g., from environment variables to volume mounts) for a specific application or environment, this change won't take effect right away. Your existing pods continue to use the previous strategy until the next delivery of secrets. You can trigger a redeploy of secrets from the CommandK dashboard to trigger the change.
Reload Type Change: Similarly, if you switch from "auto-reload" to "manual reload" (or vice versa), this change doesn't immediately affect your running pods. The updated reload type will only come into play during the next delivery of secrets. Until that next delivery occurs, the previous reload type remains in effect.

Ignoring new secrets / Detaching secrets

If you wish to prevent a certain deployment of your app from receiving any new secrets or even if you want to detach secrets entirely from a deployment, CommandK provides an annotation that you can add to your deployment, scout.commandk.dev/mutation-mode.

Mutation mode	Description
Ignore `scout.commandk.dev/mutation-mode: ignore`	This indicates that this deployment must be ignored with respect to any changes in secrets. So no new secrets will be delivered to this deployment and whatever secret was attached to it before the annotation was added will remain.
Ignore and detach `scout.commandk.dev/mutation-mode: ignore-and-detach`	All CommandK managed secrets that are attached to this deployment will be detached and deleted and now new secrets will be delivered to it.

These annotations can be added to your deployment by:

Editing the YAML manifest that was used to create your app and re-applying it with kubectl apply
Adding them to the deployment directly with kubectl edit

Note: If either of these annotations are removed then it will return to the normal behavior and all secrets will be attached back to the deployment.