Kubernetes and Co.

The sedex Client Docker container can be run on a Kubernetes-based orchestration platform. The following points must be taken into account.

Note

A separate page shows a working example deployment manifets files for Kubernetes. You can use this as a starting point for your own deployments.

Memory Allocation

It is recommended to allocate at least 1GB memory for the sedex Docker container. If additional containers will run within a Kubernetes Pod (e.g. side car proxies of a service mesh), their memory requirements must be added and more memory must be allocated to the Pod accordingly.

Use the scripted initial configuration to automate the setup in Phase 1

If the initial configuration with manually creating an init.conf file is not a feasible way for you, the provided init-scripts in the sedex Client container may be able to help you out and automate this task. See Phase 1: Initial Configuration for details.

Ensure a maximum of one running client instance per participant

Due to the architecture of the sedex system, a maximum of one sedex Client may be running for a participant at any time. This must also be ensured when operating the sedex Client as a container.

On an orchestration platform for each container can be defined how many instances should run. E.g. Kubernetes calls this the number of "replicas".

An orchestration platform can move containers to another node at any time. Usually this is done by starting a container on the new node before the old one is deactivated. This default strategy may make sense for most web applications. However, when applied to the sedex Client, this would result in two sedex Clients running for a short moment. This can be prevented by setting the replication strategy to be used. Kubernetes calls the strategy to be chosen for sedex "Recreate".

The following excerpt from a Kubernetes deployment shows this aspect of configuration for a sedex Client:

    [...]
    spec:
      replicas: 1
      strategy:
        type: Recreate
    [...]

Persistent Volume

It must be ensured that the volume for the external data storage is made persistent, i.e. has a lifetime independent of the container.

This can be achieved with Kubernetes by means of a so-called persistentVolumeClaim.

The following is an excerpt from a Kubernetes deployment shows this aspect of configuration for a sedex Client:

    [...]
        spec:
          volumes:
            - name: sedex-client-YOUR_SEDEX_ID-volume
              persistentVolumeClaim:
                claimName:  sedex-client-YOUR_SEDEX_ID-persistent-volume-claim
    [...]