K8s Q A POD

Что такое POD

Эта страница - часть документации для подготовки к прохождению собеседования

Pod (переводится с английского как стручок) состоит

• одного или нескольких контейнеров
• TODO: init container?
• TODO: sidecar container?
• хранилища (storage)
• отдельного IP-адреса
• опций, которые определяют, как именно контейнер(ы) должны запускаться.

Важно Kubernetes управляет Pod'ами, а не контейнерами напрямую.
В кластере Kubernetes Pod'ы используются двумя способами:
Каждый Pod предназначен для запуска одного экземпляра конкретного приложения. Если есть необходимость горизонтального масштабирования, то можно запустить несколько экземпляров Pod'а - в терминологии Kubernetes это называется репликацией. Реплицированные Pod'ы создаются и управляются как единая группа абстракцией, которая называется контроллер (Controller).
Pod'ы спроектированы для поддержки множества взаимодействующих процессов (например, контейнеров)
Контейнеры внутри Pod'а автоматически размещаются и управляются на одной и той же ноде кластера. Контейнеры в Pod'е могут совместно использовать ресурсы и зависимости, взаимодействовать друг с другом и определять, когда и как они будут завершаться.

Pod'ы предоставляют запущенным внутри контейнерам два типа общих ресурсов: сеть и хранилище.

Сеть

• Каждому Pod'у присваивается уникальный IP-адрес.
• Внутри Pod'а каждый контейнер использует общее пространство имен (namespace) сети, включая IP-адрес и сетевые порты.
• Между собой внутри Pod'а контейнеры взаимодействуют через localhost.
• При взаимодействии с объектами, находящимися за пределами Pod'а, контейнеры “договариваются” между собой и координируют использование общих сетевых ресурсов (таких как порты).

Хранилище

• Pod может определить набор общих томов (volumes) для хранения данных.
• Контейнеры внутри Pod'а могут работать с этими томами и, таким образом, обмениваться данными между собой.
• Благодаря использованию томов, можно сохранить данные, если один из контейнеров Pod'а (которому нужны эти данные для корректной работы) должен быть перезапущен.
• PV?
• ConfigMap ?
• Secret?

Работа POD

Что касается работы в кластере Kubernetes, то редко когда приходится создавать и запускать отдельные Pod'ы вручную (варианты запуска при ознакомлении с Kubernetes мы в расчет не берем). Связано это с тем, что Pod'ы изначально проектировались как эфемерные объекты, минимальные единицы, “строительные блоки” для сущностей более высокого уровня (например, контроллеров). Когда Pod создается (не важно, вручную вами или контроллером), он по плану (за это отвечает scheduler) запускается на одной из нод кластера Kubernetes. На этой ноде Pod остается до тех пор, пока:

• не завершится процесс внутри Pod'а (например, если это одноразовая задача);
• Pod не будет удален вручную;
• Pod не будет “выселен” с ноды из-за нехватки ресурсов;
• нода не выйдет из строя.

Примечание: Перезапуск контейнера внутри Pod'а не следует путать с перезапуском самого Pod'а.
Сами по себе Pod'ы не являются “самолечащимися” (self-healing) объектами. Если запуск Pod'а запланирован на ноде, которая вышла из строя, или сама операция запуска потерпела крах, то Pod удаляется. Точно также, при нехватке ресурсов на ноде (когда Pod'ы “выселяются”) или при переводе ноды в режим обслуживания, Pod'ы не будут запущены на других узлах и удалятся. Для обеспечения запуска на других нодах (и управления Pod'ами в целом) в Kubernetes используются абстракции более высокого уровня, называемые контроллерами - в основном именно с ними и приходится иметь дело.
Контроллер может управлять несколькими экземплярами Pod'ов - в том числе обеспечивать репликацию и самовосстановление в пределах кластера (при выходе из строя ноды, идентичный экземпляр Pod'а будет запущен на другой ноде). Примером контроллера, который содержит в себе один или несколько экземпляров Pod'а могут быть:

• Deployment
• StatefulSet
• DaemonSet

Для обеспечения такого функционала контроллеры используют шаблоны Pod'ов (Pod Templates). Шаблон Pod'а - спецификация, которая используется контроллерами и другими объектами (например, заданиями - Jobs/CronJob) для запуска настоящего, реального Pod'а.
Ниже приведен пример простой спецификации (ее еще иногда называют манифестом), описывающей контейнер, который напечатает сообщение при запуске и “уснет” на час:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

Предложенный манифест (спецификацию) можно сохранить в файле single-example-pod.yml и запустить Pod с помощью утилиты командной строки kubectl:
kubectl create -f single-example-pod.yml

Что происходит, когда вы создаёте Pod в Kubernetes?

Создание Pod в Kubernetes — простая задача. Но под капотом скрывается сложный рабочий процесс, который затрагивает несколько компонентов кластера.

kubectl

Начнем с очевидного: kubectl отправляет определение YAML на сервер API. На этом этапе kubectl:

• Обнаруживает эндпоинты API с помощью OpenAPI (Swagger).
• Согласовывает версию ресурса.
• Проверяет YAML.
• Выдает запрос.

API

Когда запрос попадает к API, он проходит следующие этапы:

• Аутентификация и авторизация.
• Контроллеры допуска. (admission controllers)
• На последнем этапе он сохраняется в etcd.

Scheduler

После этого pod добавляется в очередь планировщика.

• Планировщик фильтрует и оценивает узлы, чтобы найти лучший.
• И, наконец, привязывает pod к ноде.
• Привязка записывается в etcd.

На данный момент pod существует только в etcd в виде записи. Инфраструктура еще не создала ни одного контейнера.

kubelet

Здесь за дело берется kubelet.

Kubelet извлекает Pod definition и приступает к делегированию:

• Создание сети на CNI (например, Cilium).
• Создание контейнера - CRI (например, containerd).
• Создание хранилища - CSI (например, OpenEBS).

Кроме всего прочего, Kubelet будет выполнять проверки Pod и, если Pod запущен, сообщать его IP-адрес в control plane. Этот IP-адрес и порты контейнеров хранятся в etcd как эндпоинты.

Подождите... эндпоинты? В Kubernetes:

• endpoint - это пара 10.0.0.2:3000 (IP:порт).
• Endpoint - это коллекция конечных точек (список пар IP:порт).

Для каждого сервиса в кластере Kubernetes создает объект Endpoint с конечными точками.

Эндпоинты (IP:порт) используются:

• kube-proxy для установки правил iptables.
• CoreDNS для обновления записей DNS.
• Контроллеры входа для настройки нисходящих потоков.
• Сервисные сетки.
• И другие операторы.

Как только добавляется конечная точка, компоненты получают уведомления.
Когда конечная точка (IP:порт) будет передана, вы наконец-то сможете начать использовать Pod!

Что происходит, когда вы удаляете Pod?

Точно такой же процесс, но в обратном порядке. Правильная последовательность такова:

• Приложение перестает принимать соединения.
• Контроллеры (kube-proxy, ingress и т. д.) удаляют конечную точку.
• Приложение сливает существующее соединение.
• Приложение отключается.