Что такое CNI в Kubernetes
Что проверяют
Понимаете ли вы, что сеть в кластере не встроена, а подключается отдельным компонентом, и знаете ли, кто и в какой момент его вызывает. Для разработчика на Go вопрос ещё и про то, что спецификация и почти все плагины реализованы именно на Go, и написать свой плагин вполне реально.
Как отвечать
CNI это спецификация и набор исполняемых файлов, которые настраивают сеть для сетевого пространства имён пода.
Контейнер стартует без сети. Среда выполнения, обычно containerd или CRI-O, создаёт песочницу пода, вызывает бинарь плагина, передаёт конфигурацию в stdin в формате JSON и параметры через переменные окружения (CNI_COMMAND, CNI_NETNS, CNI_IFNAME), а плагин создаёт интерфейс, получает адрес у модуля IPAM, прописывает маршруты и возвращает результат тоже в JSON. Конфигурации лежат в /etc/cni/net.d, бинари в /opt/cni/bin.
Модель сети требует, чтобы у каждого пода был свой адрес и чтобы поды достучались друг до друга без трансляции адресов. Как именно это сделано, решает плагин: маршрутизация, туннель, режим на eBPF. Сетевые политики тоже реализует плагин, ядро Kubernetes только хранит объекты.
Где спотыкаются
Говорят, что плагин вызывает kubelet. После перехода на CRI kubelet просит среду выполнения создать песочницу, а к CNI обращается уже она. Отсюда и знакомый симптом: узел остаётся в состоянии NotReady с жалобой на неинициализированную сеть, пока конфигурация плагина не появилась на этом узле.
Думают, что сеть настраивается каждому контейнеру отдельно. Пространство имён одно на под, все контейнеры в нём делят интерфейс, адрес и localhost, поэтому два контейнера одного пода не могут занять один порт, а обращаться друг к другу могут напрямую.
Ждут, что сетевые политики работают сами по себе. Манифест применится в любом кластере, но если выбранный плагин политики не поддерживает, правило молча ничего не запрещает. Отдельная ловушка: называть в ответе плагин, который давно не развивается, легко нарваться на уточняющий вопрос про поддержку.