Setting up a Kubernetes cluster to use to write output data to container artifacts

A Docker instance of Tonic Structural does not automatically support the option to write destination data to a container artifact.

To enable this option, you can set up a separate Kubernetes cluster. You then configure Structural environment settings to enable Structural to use that Kubernetes cluster as the destination location.

Installing the Kubernetes cluster

You can install the Kubernetes cluster on the same server where Docker is installed, or on a remote host that has network access to the Docker server.

You can use any compatible Kubernetes distribution. Here are links to the installation instructions for a few different options that will work:

• minikube

• K3s

• K0s

The Structural service account must have the permissions listed in Required access to write destination data to container artifacts.

Setting the host location in the mounted kubeconfig

In the kubeconfig file, you must change the server property value from localhost to either:

• If the cluster is remote, the Kubernetes host IP address or hostname

• If the cluster is on the same host, to host.docker.internal

clusters:
- cluster:
certificate-authority-data: ...
server: <IP address or hostname, or host.docker.internal>
name: ..

Configuring Structural environment settings

To allow Structural to connect to the Kubernetes cluster and to write destination data to it, you must configure the following environment settings.

You can add these settings manually to the list on the Environment Settings tab of Structural Settings.

Setting	Description
CONTAINERIZATION_USE_REMOTE_KUBERNETES	Whether Structural can write destination data to a remote Kubernetes cluster. Set this to true.
CONTAINERIZATION_PULL_SECRET	A base64 encoded Docker secret used to pull datapacker images. This should be the same pull secret that you use to pull other images from Tonic.
CONTAINERIZATION_IMAGE_REPOSITORY	The repository where the base images are located. If you use the images provided by Structural, then you do not need to set this.
CONTAINERIZATION_REMOTE_KUBERNETES_HOST	IP address or hostname of the host for the Kubernetes cluster. If you installed Kubernetes on the same host as Docker, then you do not need to set this.
CONTAINERIZATION_MANAGE_NAMESPACE	Whether to allow Structural to manage the remote namespace. If you set this to true, then you can include {workspaceId} and {jobId} as placeholders in the value of CONTAINERIZATION_NAMESPACE. You must also add an rbac grant to enable the Structural service account to work with namespaces.
CONTAINERIZATION_NAMESPACE	The namespace where Structural writes the destination data. If CONTAINERIZATION_MANAGE_NAMESPACE is true, then the namespace can include the placeholders {workspaceId} and {jobId} to represent the specific workspace identifier and data generation job identifier.

Specifying the kubeconfig path

To allow Structural to write output data to the Kubernetes cluster, Structural also needs the path where kubeconfig is mounted to the Structural worker.

In the Docker Compose file, to specify the kubeconfig path, add the KUBECONFIG environment variable to the tonic_worker environment section.

tonic_worker:
  environment:
    KUBECONFIG: <fully qualified kubeconfig path>