CNI, CRI, CSI интерфейсы
Тема дорожной карты · Kubernetes
CNI (Container Network Interface), CRI (Container Runtime Interface) и CSI (Container Storage Interface) — три основополагающих плагинных API, позволяющих Kubernetes оставаться независимым от конкретных реализаций сети, выполнения контейнеров и хранилища. CNI-плагины — Calico, Cilium и Flannel — вызываются kubelet при создании Pod'а для подключения сетевых интерфейсов и настройки маршрутизации, тогда как CRI-совместимые рантаймы — containerd и CRI-O — управляют загрузкой образов, жизненным циклом контейнеров и выполнением OCI-бандлов через gRPC-эндпоинты RuntimeService и ImageService. CSI-драйверы предоставляют RPC-методы CreateVolume, NodeStageVolume и NodePublishVolume, которые Kubernetes вызывает для подготовки PersistentVolume и монтирования их в Pod'ы, заменяя устаревшие встроенные плагины томов. Совместно CNI, CRI и CSI позволяют K8s-кластерам комбинировать лучшие решения — например, использовать Cilium с сетевыми политиками на базе eBPF, containerd в качестве CRI-рантайма и CSI-драйвер с бэкендом Ceph для stateful-нагрузок — без изменения ядра Kubernetes.
Как это работает
CNI, CRI, CSI интерфейсы структурирован вокруг control plane и node plane Kubernetes. В control plane: API-сервер, etcd (хранилище состояния кластера), scheduler и controller-manager. В node plane: kubelet (агент, исполняющий pods), kube-proxy (сетевой слой) и container runtime. Решения по CNI, CRI, CSI интерфейсы идут от API-сервера через контроллеры и применяются на нодах.
Когда применять
Понимание CNI, CRI, CSI интерфейсы важно когда (а) вы отлаживаете проблемы кластера и нужно знать, какой компонент виноват, (б) sизируете кластер и решаете control-plane vs worker ресурсы, (в) проектируете HA-топологию (multi-master, etcd quorum), (г) выбираете между managed K8s (EKS/GKE/AKS) и self-managed. Без этого фундамента ошибки kubectl становятся гаданием.
Типичные ошибки
Архитектурные ловушки с CNI, CRI, CSI интерфейсы: 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.