Kubernetes is closely linked with Docker, since it is the main containerization application. However, there has been a trend to building with vendor neutral features and not build the Kubernetes ecosystem mainly on the Docker system.
A container runtime is the component that runs the containerized application on request, which by default is the Docker Engine.
A container runtime interface (CRI) allows integration of container runtimes with kubelet.
rkt is a CLI for running containers, and deploys immutable pods.
cri-o is a implementation of CRI to enable using OCI (Open Container Initiative) compatible runtimes.
containerd is used to expose low level primitives
- minimal CLI
- embedded into larger systems
- runs containers in accordance to OCI
Containerization of an Application: While all applications can be containerized, it makes more sense to containerize applications that are stateless and transient.
Multi-Container Pods: For some applications, it does not make sense to create a new image to add functionality like logging. So we can create a new container inside the pod. Each container must to decoupled as much as possible.
readinessProbe: Sometimes a application must be initalized before it can start accepting traffic or requests, especially during scaling. We use a readinessProbe to ensure that a container will not accept traffic until the probe returns the container as a healthy state. There are many different probs. One prob fails on exec unless ready, and another uses an HTTP GET on a predefined port and path. A TCP Socket will attempt to open a socket a predetermined port and keep trying until it succeeds.
livenessProbe: A livenessProbe continuously checks the health of a container and ensures it can accept traffic, and if it fails for any reason, the container is terminated. If the container is under a Kubernetes controller, a replacement is respawned.