Какой компонент в Kubernetes непосредственно отвечает за запуск и управление контейнерами?

Непосредственно за запуск, остановку и управление жизненным циклом контейнеров в Kubernetes отвечает контейнерный рантайм (Container Runtime), который взаимодействует с kubelet через стандартизированный Container Runtime Interface (CRI).

Как это работает:

1. Kubelet (агент на ноде) получает инструкции от API-сервера о том, какие поды нужно запустить.
2. Kubelet обращается к CRI-плагину (например, dockershim, cri-o, containerd), который реализует протокол CRI.
3. CRI-плагин транслирует запросы в команды для низкоуровневого контейнерного рантайма.

Популярные контейнерные рантаймы в экосистеме Kubernetes:

• containerd: Стал стандартом де-факто. Это высокоуровневый рантайм, который изначально был частью Docker, а теперь — самостоятельный проект CNCF. Он управляет полным жизненным циклом контейнера, но не умеет собирать образы (это делает buildkit).
• CRI-O: Легковесная реализация, специально созданная для Kubernetes. Его философия — «делать только то, что нужно для K8s». Он напрямую работает с образами из OCI-репозиториев.

Пример в манифесте Pod: Контейнерный рантайм получает спецификацию контейнера из манифеста и исполняет её.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app-container
    image: myregistry/app:v1.2.3 # Рантайм скачает этот OCI-образ
    command: ["/app/start.sh"]
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m" # Рантайм передаст эти лимиты в cgroups ядра

Важно: Сам Docker больше не является поддерживаемым рантаймом в Kubernetes. Современные дистрибутивы (kubeadm, k3s, EKS, GKE) по умолчанию используют containerd, который является тем же движком, что и внутри Docker, но без его клиента и демона.