TLDR Что происходит в Kubernetes при запуске kubectl run? by Jamie Hannaford

Пошаговое описание того, что делает каждый компонент k8s после команды kubectl в ~800 словах

kubectl run --image=nginx --replicas=3

kubectl

• Валидирует запрос — проверяет что он понимает что это за запрос.
• Составляет http запрос к apiserver в соответствии с вычисленным типом ресурса — под, деплоймент и прочие разные штуки kube’а.
• Договаривается с apiserver об используемой версии api.
• Аутентифицируется в apiserver — по сертификатам, токену или паролю.

kube-apiserver

• Аутентифицирует клиента разрешенными = указанными при старте способами.
• Авторизует запрос ­ — что вам его можно выполнять. По цепочке авторизаторов — по файлам политик и проч.
• Контроль допуска — проверяет что вообще такого типа запросы на этом кластере разрешены — лимиты, квоты и т.п.
• Формирует соответствующий запросу ресурс — runtime представления заказанного пода, деплоймента и т.п.
• Сохраняет его в etcd через “поставщик хранилища”, но в неинициализированном виде — не ставится галка.
• Поставщик хранилища его сохраняет и get’ает, чтобы проверить успешное сохранение.
• Apiserver отправляет http ответ.
• Поставщик хранилища вызывает post-hooks.

Инициализаторы

Если у вновь записанного типа ресурса есть какие-то предварительные шаги, то на его создание зарегистрированы соответствующие инициалайзеры, как например, ижектеры проксей для пода и т.п.

• Эти инициализаторы записываются в pending список этому ресурсу.
• И начиная с первого выполняются по одному — они подписаны на объекты и если видят себя в голове списка, то отрабатывают.
• Пустой список означает, что ресурс initialized. И он становится доступен контроллерам.

Контроллеры

• Каждый из них считывает состояние каких-то etcd нод, за которые он отвечает. Например, Deployment controller видит, что появился новый деплоймент nginx’ов и его ответственность — создать нужные ReplicaSet’ы. Создать в смысле записать в etcd в нужном виде.
• Когда записаны новые ReplicaSet’ы, то в свою очередь ReplicaSet controller видит, что его понимание о том какие поды существуют не соответствует тому какие ReplicaSet’ы указаны в etcd. И он начинает создавать нужные pod’ы согласно правилам, например, соблюдая ReplicaSet burst count — количество подов создаваемых за раз.
• Контроллеры узнают об изменении в хранилище через Informer’ы — специальный механизм листенеров над etcd.

Шедулер

• Когда все контроллеры отработали и завели все нужные поды, поды будут тем не менее находиться в Pending состоянии, т.к. они еще не были назначены на конкретные ноды.
• Шедулер работает примерно так же как другие контроллеры — он слушает все события про поды и отфильтровывает поды, у которых NodeName пустой и пытается найти им подходящие Ноды.
• Шедулинг происходит так:

1. Прежде всего проверяется цепочка предикатов, которые отфильтровывают неподходящие ноды. Например, если в PodSpec’е указаны CPU ресурс, а на какой-то ноде столько нет.
2. Дальше выполняются функции приоритета, по которым оставшиеся ноды ранжируются. Например, выше ставится нода с большим количеством свободных ресурсов.

• Когда нода выбрана, шедулер создает Binding запрос к apiserver’у — который запишет имя ноды в NodeName PodSpec’и и установит PodScheduled статус в True .

kubelet

• Это компонент запущенный на всех нодах Кубернетес кластера и занимающийся среди прочего жизненным циклом подов на этой ноде — он транслирует все необходимое из абстрации “Под” в реальные контейнеры, volum’ы и т.п.
• kubelet так же как контроллеры и шедулер получает статус всех подов назначеных его ноде от apiserver’а и проверяет, что всё это соответсвует его локальной действительности.
• А если что-то не соответствует, то он пытается отсинхронизовать действительность под желаемые аписервером требования. Вот что он делает:

1. Создает объект PodStatus, в котором отслеживается изменения его состояния, такие как Pending, Running, Succeeded, Failed. Например, определив какие контейнеры надо запустить, кублет понимает, что они еще не созданы, и поэтому Pod находится в Pending состоянии.
2. Затем этот PodStatus отдается статус-менеджеру Пода, который ассинхронно будет записывать обновления в apiserver.
3. Запускаются секьюрити хендлеры, которые, например, проверяют профили Apparmor. Поды не прошедшие эти хендлеры навсегда остаются в состоянии Pending.
4. Если был установлен флаг cgroups-per-qos, то kubelet создает cgroup’ы для пода и ставит туда ограничения ресурсов.
5. Кублет создает дата-директории для пода — /var/run/kubelet/pods/<podID> для самого пода, <podDir>/volumes для вольюмов и<podDir>/plugins для плагинов.
6. Volume manager будет ожидать соответствующих PodSpec’е вольюмов.
7. Кублет получит все соответвующие поду секреты от аписервера, чтобы позже их заинжектить в контейнер.
8. Container runtime запускает контейнер:

ContainerRuntimeInterface

• CRI это абстракция между kubelet’ом и, например, docker’ом, которая нужна, чтобы кубернетес мог работать не только поверх docker’а, но и поверх rkt или вообще вирутальных машин.
• kubelet запускает вызовRunPodSandbox, где “sandbox” это CRI термин обозначающий под. Т.е. это может быть как группа контейнеров, так и виртуалка или что-то подобное.
• В случае docker’а создание sandbox’а соответствует созданию запаузенного (paused) контейнера — родительского контейнера для пода, через который все контейнеры пода будут шарить ресурсы — Linux неймспейсы (IPC, network, PID).

ContainerNetworkInterface

• CNI это тоже интерфейс абстракция, которая позволяет подключать различные провайдеры организации сетей.
• Если у Pod’а был сконфигурирован интерфейс типа bridge:

1. Плагин bridge создаст локальный линуксовый сетевой мост на ноде.
2. Затем вторая пара от veth будет заинжектена внутрь paused родительского контейнера, т.е. в его network namespace.
3. CNI присвоит этому интерфейсу IP и назначит роутинг. Делает это он через ipam (address manager) плагин, который, например, создает host-local конфигурацию.
4. CNI получив информацию о DNS сервере от kublet’а, пропишет ее в resolve.conf контейнеру.

Межнодовое сетевое взаимодействие

Обычно оно организовывается с помощью overlay сети, например, это может быть layer-3 IPv4 межнодовая сеть, которая энкапсюлирует ip пакеты в UDP реальной сети.

Запуск контейнеров

После того как sandbox подготовлен, kubelet запускает уже реальные контейнеры Пода — сначала запускаются init контейнеры, если такие есть в спеке Пода, и только потом основные контейнеры.

1. Pull’ится соответствующий образ.
2. CRI создает контейнер внутри родительского paused контейнера.
3. Если нужно, контейнер регистрируется в CPU manager’е — ему приписывается набор ЦПУ, на которых он будет работать.
4. Контейнера запускается!
5. Запускаются post-start хуки.

Вот и всё.

Спонсор выпуска — okmeter.io мониторинг контейнеров и сервисов.