Tips and best practices for using InfoSphere MDM on Kubernetes

Pod security policies

InfoSphere® MDM Docker images all run scripts as non-root users. They do not require root access. This makes it easy for a Kubernetes cluster administrator to define a Pod Security Policy and then create roles that enable the policy to be bound to specific users or service accounts.

Configuring liveness and readiness probes

With the default configuration, readiness and liveness probes are determined by attempting to establish a connection over a TCP socket to your container on the specified target port. If a connection can be established, then the container is considered healthy. If not, the container is considered a failure.

HTTP probes determine readiness and liveness. The readinessProbe.initialDelaySeconds and livenessProbe.initialDelaySeconds parameters define how long to wait before performing the first probe.

Tips:

Set appropriate values for your container to ensure that the readiness and liveness probes don’t interfere with each other. Otherwise, the liveness probe might continuously restart the pod, meaning the pod will never be marked as ready.
Be aware that the readiness probe runs periodically even after the pod has been verified as ready for service.
If the actions for the readiness probe and liveness probe are exactly the same, it may not be necessary to have a liveness probe.

For more information about configuring liveness and readiness probes, see the Kubernetes online documentation.

Pod disruption budgets

A Pod Disruption Budget limits the number of pods of a replicated application that can be down simultaneously from voluntary disruptions. For more information about configuring a Pod Disruption Budget, see the Kubernetes online documentation.

To create a Pod Disruption Budget for the MDM operational server:

Right-click here to download an archive containing mdm_disruption.yml. Save mdm_disruption.yml to your Docker working directory (/mdm).
Run the following command:
```
kubectl create -f mdm_disruption.yml
```

Running mdm_disruption.yml ensures that 60% of the pods specified in the replicaCount will be available even in case of voluntary disruptions in the Kubernetes cluster. The value of minAvailable can either be a number of replicas or a percentage, and you can be modify this value in the YAML file before creating the Pod Disruption Budget.

Session affinities

Depending on the underlying ingress controller (NGINX Plus Ingress Controller or NGINX Ingress Controller), you will see different formats of session affinities settings. For reference, sample session affinity formats are shown below. Both of these formats are included in the InfoSphere MDM Kubernetes YAML files.

NGINX Plus Ingress Controller format

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: cafe-ingress-with-session-persistence
annotations:
    nginx.com/sticky-cookie-services: "serviceName=coffee-svc srv_id expires=1h path=/coffee;serviceName=tea-svc srv_id expires=2h path=/tea"
spec:
    rules:
    - host: cafe.example.com
    http:
        paths:
        - path: /tea
        backend:
            serviceName: tea-svc
            servicePort: 80
        - path: /coffee
        backend:
            serviceName: coffee-svc
            servicePort: 80

NGINX Ingress Controller format

Note: Annotations can contain either the new prefix (nginx.ingress.kubernetes.io) or the old prefix (ingress.kubernetes.io).

nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "route"
nginx.ingress.kubernetes.io/secure-backends: "true" 
nginx.ingress.kubernetes.io/session-cookie-hash: "sha1"
ingress.kubernetes.io/affinity: "cookie"
ingress.kubernetes.io/session-cookie-name: "route"
ingress.kubernetes.io/secure-backends: "true"
ingress.kubernetes.io/session-cookie-hash: "sha1"