Kubernetes¶

Connect a Kubernetes cluster as a workload backend. SRM selects a binding; the SDK executes against that binding's explicit cluster, context and namespace.

Before you start¶

Configure the Kubernetes workload backend through the Release 2 platform chart, either when installing OpenOP or when upgrading an existing deployment. Decide whether workloads run on the platform cluster or on a remote cluster. Select the workload namespace and an application NodePort address reachable by clients.

The examples below contain complete bootstrap values for a fresh installation. Replace the documentation addresses before using them. To extend an existing installation, preserve its control paths and topology refs: seeding creates missing rows and leaves existing rows unchanged.

Steps¶

1. Choose the connection mode¶

Mode	Required infrastructure settings	Identity used
Platform cluster	`in_cluster: true`, `namespace`	SRM Pod's ServiceAccount
Explicit cluster	Absolute `kubeconfig_path`, `kube_context`, `namespace`	Selected kubeconfig user

Do not mix the modes. There is no ambient kubeconfig fallback. Independent api_server overrides, unresolved kubeconfig_ref, external exec/auth-provider plugins, basic authentication and configured kubeconfig proxies are unsupported.

For a local cluster, adapt local-kubernetes.values.yaml. srm.workloads.namespaces grants SRM's ServiceAccount permissions on the platform cluster. Namespace creation is controlled by srm.workloads.createNamespaces.

2. Prepare remote credentials, if needed¶

Adapt remote-kubernetes.values.yaml. Put the selected kubeconfig and any relative certificate/token files together in a Secret in SRM's namespace. Ensure that namespace (oop in this example) exists before creating the Secret. For a self-contained kubeconfig:

kubectl --context PLATFORM_CONTEXT -n oop create secret generic remote-edge-kubeconfig \
  --from-file=config=/absolute/path/to/remote.kubeconfig

The example mounts the Secret directory at /etc/openop/kubeconfigs/remote-edge; the bootstrap selects /etc/openop/kubeconfigs/remote-edge/config and context remote-edge. The SDK reads the mounted files; it does not fetch Secrets.

After changing the selected context, API server address or user settings in the kubeconfig, restart the SRM Pod so the SDK loads the updated configuration. A token stored in a separate mounted file can be renewed without restarting SRM.

On the remote cluster, grant the selected kubeconfig identity the permissions needed to deploy and manage application workloads, including the Secrets Helm uses to store their release state. Helm's namespace creation also needs suitable namespace permissions. Setting srm.workloads.namespaces on the platform cluster grants no remote rights. Check access using the same kubeconfig and context, for example:

kubectl --kubeconfig /absolute/path/to/remote.kubeconfig --context remote-edge \
  auth can-i create deployments.apps -n oop-apps
kubectl --kubeconfig /absolute/path/to/remote.kubeconfig --context remote-edge \
  auth can-i create secrets -n oop-apps

These are initial checks; a chart may require additional permissions.

3. Configure endpoints and apply¶

endpoint_host is the host clients use for application NodePorts. It is independent of the Kubernetes API server. Device Traffic Influence requires an observed application IPv4 endpoint. A workload may become active without endpoint metadata when this host is absent.

With Helm, pass your adapted local-kubernetes.values.yaml or remote-kubernetes.values.yaml as the last -f argument, after the values files used to install the platform. For a concrete example on kind, the platform values are the chart's environments/kind/values.yaml. Download the local-cluster example into your Release 2 Helm checkout, adapt it for your deployment, and run:

helm upgrade --install oop-platform ./oop-platform-chart \
  --kube-context PLATFORM_CONTEXT \
  -n oop --create-namespace \
  -f environments/kind/values.yaml \
  -f local-kubernetes.values.yaml

For another environment, replace the kind values with that environment's platform values; for a remote workload backend, pass the adapted remote-cluster example last instead. When upgrading, use the existing platform release name, namespace and context, and retain all required platform values files. Later -f files override earlier ones. Keep srm.topology as one complete YAML string: the last value replaces the entire bootstrap rather than merging its contents. See Define zones. The chart validates credential mount mappings, without testing remote connectivity or authorization.

Check it worked¶

List the zone through authenticated OEG access, then deploy an application. Confirm its Helm release and resources exist in the selected cluster and namespace, its public lifecycle completes, and its reported endpoint responds.

All options¶

See the SDK connection settings, chart credential mounts and support matrix.