Container Runtime Interface (CRI)

Kubernetes uses a CRI to communicate with a container runtime.

Container runtimes includes CRI-O the default in OCP (developed by RHEL).

The most common container runtimes are containerd a cncf project (used by GKE, …​), Kata or the traditional docker daemon.


A pod is the atomic unit of scheduling. Containers inside a pod share network and storage resource.

The most common use of a Pod is to run a single container. Situations where different processes work on the same shared resource benefit from having multiple containers in a single Pod.

Some projects inject containers into running Pods to deliver a service. An example of this is the Istio service mesh, which uses this injected container as a proxy for all communication.

Control plane

Kubernetes master cluster that includes:

  • the apiserver

  • the scheduler

  • the controller managers.

Usually the etcd cluster is part of it too (but it can be separated).


Create multiple virtual clusters on the same physical clusters. You can limit resources such as CPU per namespace.


A Deployment manages a ReplicaSet. It gives more control over the rollout strategies of the Pods that the ReplicaSet controls.


The ReplicaSet maintains the desired number of copies of a Pod running within the cluster.


A DaemonSet runs one copy of the Pod on each node in the Kubernetes cluster.


Appropriate for situations where Pods have a similar definition but need a unique identity, ordered deployment and scaling, and storage that persists across Pod rescheduling.


  • Separate sensible information and flag them as such.

  • Don’t provide encryption (Base64 encoded).

  • Set of key/value pairs




Detect if a container becomes unresponsive (need to be restarted)


Detect if a ready to start accepting traffic.