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
