Skip to content

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
      pingdatagovernance:
        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.