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
livenessProbe.initialDelaySeconds parameters define how long to wait before
performing the first probe.
- 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.
- 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
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"