Workload Configuration ¶

Kubernetes Workload resources:

are created depending on configuration values.

Global Section ¶

Default yaml is defined in the global workload section. Individual products override these defaults based on the needed workload.

global:
  workload:
    type: Deployment

    deployment:
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0

    statefulSet:
      partition: 0

      persistentvolume:
        enabled: true
        volumes:
          out-dir:
            mountPath: /opt/out
            persistentVolumeClaim:
              accessModes:
              - ReadWriteOnce
              storageClassName:
              resources:
                requests:
                  storage: 4Gi

    securityContext:
      fsGroup: 9999
    securityContext: {}

Workload Parameters	Description
type	One of Deployment or StatefulSet
deployment.strategy.type	One of RollingUpdate or ReCreate
deployment.strategy.rollingUpdate	If type=RollingUpdate
statefulSet.partition	Used for canary testing if n>0
statefulSet.persistentVolume	Provides details around creation of PVC/Volumes (see below)
securityContext	Provides security context details for starting container as different user/group (see below)
securityContext.fsGroup	Sets the group id on fileSystem writes. This is needed especially for mounted volumes (pvs)

Persistent Volumes

For every volume defined in the volumes list, 3 items will be created in the StatefulSet:

container.volumeMounts - name and mountPath
template.spec.volume - name and persistentVolumeClaim.claimName
spec.volumeClaimTemplates - persistentVolumeClaim

More Info - https://kubernetes.io/docs/concepts/storage/persistent-volumes/

Security Context

To run the containers with a different user/group/fsgroup, use the following example to set those details on the deployment/statefulset:

global:
  workload:
    container:
      securityContext:
        runAsGroup: 9999
        runAsUser: 9031
        fsGroup: 9999

WaitFor

For each product, a waitFor structure providing the name, service and timeout, in seconds, that should be waited (defaults to 300 if not provided) on before the running container con continue. This will inject an initContainer using the PingToolkit wait-for utility until it can nc host:port before continuing.

Example: PingFederate Admin waiting on pingdirectory ldaps service to be available

pingfederate-admin:
  container:
    waitFor:
      pingdirectory:
        service: ldaps
        timeoutSeconds: 600
      pingauthorize:
        service: https
        timeoutSeconds: 300

By default, the pingfederate-engine will waitFor pingfederate-admin before it starts.
By default, the pingaccess-engine will waitFor pingaccess-admin before it starts.