docs(Kubernetes): Update the documentation

Describe the newly added functionality for additional containers and
named volume mounts.

Signed-off-by: Oliver Heger <oliver.heger@bosch.com>

Author: oheger-bosch

website/docs/admin-guide/infrastructure/transport/kubernetes.md

@@ -7,6 +7,7 @@ This module provides an implementation of the transport abstraction layer using
 The Kubernetes transport abstraction layer exchanges messages via environment variables.
 The sender creates a Kubernetes Job using the Kubernetes API, that runs the configured container image and sets the message content as environment variables.
 The container started by the Kubernetes Job acts as the receiver and constructs the message from the environment variables.
+The implementation supports a number of configuration options to customize the resulting Kubernetes Job, for instance, to mount secrets or persistent volumes, or to set resource requests and limits.
 
 ## Configuration
 
@@ -25,7 +26,7 @@ endpoint {
         backoffLimit = 5
         commands = "/bin/sh"
         args = "-c java my.pkg.MyClass"
-        mountSecrets = "server-secrets->/mnt/secrets server-certificates->/mnt/certificates"
+        mountSecrets = "secretVolume=server-secrets->/mnt/secrets server-certificates->/mnt/certificates"
         mountPvcs = "my-pvc->/mnt/data,W"
         mountEmptyDirs = "shared->/mnt/shared"
         labels = "label1=value1,label2=value2"
@@ -35,6 +36,8 @@ endpoint {
         cpuLimit = 500m
         memoryRequest = 64Mi
         memoryLimit = 128Mi
+        additionalContainers = "init-container, sidecar-container"
+        volumeMounts = "secretVolume"
     }
 }
 ```
@@ -224,6 +227,31 @@ kubernetes.memory = 768M
 
 Then the memory limit of the pod to be created will be set to 768 megabytes.
 
+### `additionalContainers`
+
+**Default: `empty`**
+
+The Kubernetes Transport implementation supports adding additional containers to the pod created by the sender. This can be used to enable advanced use cases, for instance, to run an init container that prepares the environment for the main container, or to run a sidecar container that provides additional services to the main container.
+
+Declaring additional containers is done by providing a comma-separated list of container names in the `additionalContainers` property. While the properties of the main container are configured via the properties described above, additional containers take their configuration from environment variables: For each container, a set of environment variables starting with the name of the container in upper case followed by an underscore is expected. There are then corresponding variables for each property of the container, using snake-case for the property name instead of camelCase. For instance, for a container named _sidecar_, there can be variables like `SIDECAR_IMAGE_NAME` for the `imageName` property or `SIDECAR_CPU_LIMIT` for the `cpuLimit` property. These variables are optional; for missing variables, the value from the main container is used with the following exceptions:
+
+- Resource requests and limits are not copied from the main container. They should be set explicitly for each additional container if needed.
+- Volume mounts are undefined as well if they are not set explicitly.
+
+The variable `<CONTAINER_NAME>_INIT_CONTAINER=TRUE` can be used to declare a container as init container. If this variable is not set or has a different value, the container is treated as a regular container.
+
+### `volumeMounts`
+
+**Default: `empty`**
+
+When additional containers are declared, this property can be used to specify which of the volumes should be mounted into which container. This makes it possible for instance, to exchange data between two containers via a shared volume, or to restrict volumes with secrets to specific containers.
+
+To make use of this property, as a first step, volume mounts must be assigned a name. This is simply done by adding the name of the volume mount as a prefix to the mount declaration, separated by an equals sign. Such a name can be provided for all types of volume mounts. For instance, the declaration of a secret volume mount could look like `secretVolume=secretName->/mnt/secrets`. It is then known under the name _secretVolume_.
+
+As a second step, the `volumeMounts` property of the main container, or the `<CONTAINER_NAME>_VOLUME_MOUNTS` environment variable for an additional container, can reference these names to select the volume mounts to be used in the respective container. Its value is a comma-separated list of volume mount names.
+
+Volume mounts without a name are automatically added to all containers.
+
 > [!NOTE]
 > The receiver part does not need any specific configuration settings except for the transport type itself.