Container runtime (containerd, CRI-O)
Тема дорожной карты · Kubernetes
Container Runtime Interface (CRI) — это gRPC API, который kubelet Kubernetes использует для делегирования операций жизненного цикла контейнеров и образов нижележащему контейнерному рантайму, абстрагируясь от деталей реализации создания, запуска и остановки контейнеров. Containerd — наиболее широко используемый CRI-рантайм — управляет загрузкой OCI-образов, кэшированием слоёв, настройкой пространств имён контейнеров и интегрируется с профилями безопасности контейнеров через ресурсы RuntimeClass, ссылающиеся на containerd-шимы, такие как kata-containers или gvisor. CRI-O — лёгкая альтернатива, созданная специально для Kubernetes и реализующая только поверхность CRI без дополнительных возможностей демона; является рантаймом по умолчанию в OpenShift. Когда kubelet планирует Pod, он вызывает RPC-методы RunPodSandbox, CreateContainer и StartContainer на CRI-сокете (обычно /run/containerd/containerd.sock для containerd), после чего CNI-плагин подключает сетевой интерфейс для завершения запуска Pod'а.
Как это работает
Container runtime (containerd, CRI-O) структурирован вокруг control plane и node plane Kubernetes. В control plane: API-сервер, etcd (хранилище состояния кластера), scheduler и controller-manager. В node plane: kubelet (агент, исполняющий pods), kube-proxy (сетевой слой) и container runtime. Решения по Container runtime (containerd, CRI-O) идут от API-сервера через контроллеры и применяются на нодах.
Когда применять
Понимание Container runtime (containerd, CRI-O) важно когда (а) вы отлаживаете проблемы кластера и нужно знать, какой компонент виноват, (б) sизируете кластер и решаете control-plane vs worker ресурсы, (в) проектируете HA-топологию (multi-master, etcd quorum), (г) выбираете между managed K8s (EKS/GKE/AKS) и self-managed. Без этого фундамента ошибки kubectl становятся гаданием.
Типичные ошибки
Архитектурные ловушки с Container runtime (containerd, CRI-O): single-master control plane в production (один etcd-отказ = outage кластера), under-sizing control plane для размера кластера (1000+ pods требуют больше CPU API-сервера, чем дефолты), допущение что режимы kube-proxy (iptables vs IPVS) не важны — они важны на масштабе. Относитесь к control plane как к critical infrastructure со своим мониторингом и DR.