Digital Garden

Kubernetes

This article contains my observations from various explorations I conducted regarding Kubernetes and docker. It might be a little unstructured, so bare with me. Also see to colima to read about various experiments I did with minikube.

CRI

The Container Runtime Interface is a plugin interface which enables the kubelet to use a wide variety of container runtimes, without having a need to recompile the cluster components.

Kubernetes repo contains a good readme on Why CRI?

Dockershim: the old way

Kubernetes_docker_history
Image ref

Historically, the early versions of Kubernetes only worked with a specific container runtime: Docker Engine. Later, Kubernetes added support for working with other container runtimes.

kubernetes_before_cri
Image ref

The CRI standard was created to enable interoperability between orchestrators (like Kubernetes) and many different container runtimes (crun, rkt, hypernetes).

Docker Engine doesn’t implement that interface (CRI). To solve this, a small software shim (dockershim) was introduced as part of the kubelet component specifically to fill in the gaps between Docker Engine and CRI. But dockershim was never intended to be a permanent solution, and over the course of years, its existence has introduced a lot of unnecessary complexity to the kubelet itself.

dockershim_cri
Image ref

So dockershim was deprecated in k8s v1.20, and completely removed in v1.24.

As mentioned in this article from kubernetes:

You see, the thing we call “Docker” isn’t actually one thing—it’s an entire tech stack, and one part of it is a thing called “containerd,” which is a high-level container runtime by itself
Docker is cool and useful because it has a lot of UX enhancements that make it really easy for humans to interact with while we’re doing development work, but those UX enhancements aren’t necessary for Kubernetes, because it isn’t a human.

Docker isn’t compliant with CRI, the Container Runtime Interface. If it were, we wouldn’t need the shim, and this wouldn’t be a thing

CRI: the replacement

Kubelet always uses CRI except for using the rktnetes integration.
The old, pre-CRI Docker integration was removed in 1.7.

To maintain backward compatibility, Docker and Mirantis came together to develop the cri-docker

Widely used CRIs:

Deprecated CRI:

Running kubelet with --container-runtime-endpoint is now deprecated, instead one must use kubelet’s --config option specifying the config file.

References:
The first release article (2016, k8s 1.5): https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/
Not so updated readme file in k8s: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md

cri-tools

cri-tools provide CLI and validation tools for Kubelet Container Runtime Interface (CRI) .

crictl is a command-line interface for CRI-compatible container runtimes.
Supported comamands: images, ps
See the documentation

Kubectl

A cli tool to play with k8s cluster, similar to docker-cli

Kubectl context

similar to docker context, kubectl also has its context
dependeing on which context is selected, kubectl can toggle between multiple k8s clusters

to see all contexts in kubectl, run kubectl config get-contexts
to see name of the active context, run kubectl config current-context
to change active context, run kubectl config use-context

information about all contexts is stored in a config file (by default) located in $HOME/.kube/config
with kubectl we can specify other config file using --kubeconfig flag
or update $KUBECONFIG env variable with multiple config file paths (: seperated), to create one merged config.

To view the config, run kubectl config view
see kubectl config --help for detailed working of how config is generated

Graph View

Backlinks