kubernetes controllers

Ensure kubernetes pod can be restarted in another node if the node that hosts the kubernetes pod crashes.

ReplicaSet

• ensure a Pod is launched and works as intended by creating new Pods if there are any missing Pod in the node
• can handle multiple copies of the same Pod, i.e. autoscaling
• uses kubernetes label to identify Pods that it manages
• manages Pods on multiple nodes

It's recommended to use a ReplicaSet even if there is only one pod.

ReplicaSet selector

Accept 2 selection types:

• matchLabels: simple key=value select
• matchExpressions: advanced selection:
  • level with value novice or intermediate
  • key level is defined, regardless of the value

Example:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
    matchExpressions:
      - key: level
        operator: In
        values:
          - novice
          - intermediate
  template:
  # ...

operators, matchLabels and matchExpresssions

4 available operators:

• In
• NotIn
• Exists
• DoesNotExists

If matchLabels and matchExpressions are both defined, then both must be validated (i.e. AND equivalent).

A ReplicaSet is only in charge of having a set number of pods up! Thus, if a pod crashes every 5m, it's not its problem!

DaemonSets

Launch only one Pod on each node.

Use cases:

• storage daemon on each node (e.g. glusterd, ceph, rook, …)
• log agent (fluentd, logstash, …)
• metrics agent (prometheus, collectd, datadog, …)

A DaemonSet deploys its pods on all cluster nodes, except if we specify which node to deploy using nodeSelector (example use case: specific tool for a specific node hardware).

Jobs

• execute a Job to launch a kubernetes pod once and expect a successful return
• a Job can restart a kubernetes pod if the latter did not exit with a success code
• a Job can launch several kubernetes pod in parallel

Additional parameters

• to execute multiple time a Job, use the .spec.completions parameter
• to execute kubernetes pod in parallel, use the parameter .spec.parallelism
• to add a timeout, use the parameter .spec.activeDeadlineSeconds
• to specify that a Job cannot be restarted after a number of times, use .spec.backoffLimit

The default value of RestartPolicy for a kubernetes pod is Always, so it's mandatory to set the RestartPolicy for a Job to OnFailure or Never!

Cronjobs

It’s also possible to execute Job at a fixed frequency or a future date using the resource type Cronjob.

---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: hello
              image: debian: 10 - slim
              args:
                - bash
                - - c
                - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

The timezone used is the one from the kubernetes controller manager!

Once a Job is finished, it’s not automatically destroyed. Same for its associated kubernetes pods. It’s for reading logs afterwards. So it’s up to the user to delete manually the Job.

It’s also possible to set the max history size with .spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit.

Jobs must be idempotents:

• in case a node crashes while the job is in progress
• in case a cronjob is launched twice (can happen)
• in case a cronjob is not launched at all