Kubernetes начинался как слой планировщика поверх набора однохостовых Docker-демонов. Это значит, что долгое время Kubernetes-поды были всего лишь "полусклеенными" группами Docker-контейнеров.

Со временем появился Container Runtime Interface (CRI), который дал возможность подменять и настраивать container runtime’ы. Большинство кластеров перешло с тяжеловесного Docker на более специализированный containerd в качестве «высокоуровневого» runtime’а, при этом низкоуровневый OCI runtime (runc) остался без изменений.

Однако потребность в более изолированных подах продолжала расти, и вслед за этим появились "альтернативные" реализации – альтернативные по отношению к Docker-style контейнерам. Самые заметные из них – gVisor и Kata Containers.

gVisor запускает контейнеры поверх урезанного user-land kernel, написанного на Go, а Kata Containers оборачивает обычные Linux-контейнеры в microVM’ы для дополнительной изоляции.

Естественно, возникла необходимость указывать container runtime на уровне пода. Так и появился ресурс RuntimeClass.

С помощью RuntimeClass можно сообщить Kubernetes, какие container runtime’ы поддерживают ноды кластера. Это позволяет кластеру запускать как традиционные поды на базе Linux-контейнеров, так и более изолированные поды на gVisor или Kata Containers.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx-kata-qemu
spec:
  runtimeClassName: kata-qemu
  containers:
    - name: nginx
      image: nginx:alpine
EOF

Узнайте, как регистрировать новые RuntimeClass’ы и запускать поды с произвольными именами runtime class, в практическом туториале от Márk Sági-Kazár: https://labs.iximiuz.com/tutorials/kubernetes-runtime-class-61506808

👉 DevOps Portal