Вопросы на собеседовании: Kubernetes-инженер

Kubernetes является платформой управления контейнерными workloads, которая поддерживает объявленное состояние приложений в кластере.

• Он планирует workloads на доступные узлы вместо ручного размещения.
• Controllers заменяют отказавшие экземпляры и согласуют фактическое состояние с желаемым.
• Services предоставляют стабильный доступ, пока Pods могут создаваться и удаляться.
• Kubernetes даёт примитивы оркестрации, но код приложения и container images остаются ответственностью пользователя.

Kubernetes-кластер является группой компонентов control plane и worker nodes, которые совместно запускают workloads и управляют ими.

• Control plane хранит желаемое состояние и принимает решения для всего кластера.
• Worker nodes предоставляют CPU, память, сеть и storage для Pods.
• Компоненты общаются через Kubernetes API, а не работают одним процессом.
• Кластер может содержать один или много узлов в зависимости от назначения и требований доступности.

Контейнеры изолируют процессы и используют общее ядро хоста, а виртуальные машины включают гостевую ОС на виртуализированном оборудовании.

• Container image упаковывает приложение и его user-space зависимости без отдельного ядра.
• Виртуальные машины обычно дают более сильную границу изоляции, но требуют больше ресурсов и запускаются дольше.
• Несколько контейнеров могут работать на одном узле через container runtime.
• Kubernetes планирует контейнеры внутри Pods и не заменяет операционную систему узла.

Pod является наименьшей развёртываемой единицей Kubernetes и содержит один или несколько тесно связанных контейнеров.

• Контейнеры Pod вместе планируются на один узел.
• Они разделяют сетевой namespace Pod, IP-адрес и localhost.
• Они могут совместно использовать volumes, объявленные в спецификации Pod.
• Pods являются расходными объектами, поэтому обычно их создают и заменяют высокоуровневые controllers.

Pod может объединять контейнеры, которым нужно разделять lifecycle, сеть и storage как одной единице приложения.

• Основной контейнер может запускать приложение, а helper выполнять тесно связанную вспомогательную функцию.
• Контейнеры общаются через localhost, потому что разделяют один network namespace.
• Общие volumes позволяют одному контейнеру создавать файлы для другого.
• Несвязанные сервисы обычно должны находиться в отдельных Pods, чтобы независимо масштабироваться и обновляться.

Каждый Pod обычно получает собственный cluster IP address, общий для всех его контейнеров.

• Контейнеры внутри Pod общаются через localhost и разные порты.
• Другие Pods обращаются по Pod IP, если это разрешает сеть кластера.
• Pod IP нестабилен при замене, поэтому клиенты обычно используют Service.
• Сетевая модель Kubernetes предполагает маршрутизацию Pod IP между узлами без port mapping на уровне приложения.

Фаза Pod является общим описанием его жизненного цикла: Pending, Running, Succeeded, Failed или Unknown.

• Pending означает, что Kubernetes принял Pod, но один или несколько контейнеров ещё не готовы к запуску.
• Running означает, что Pod привязан к узлу и хотя бы один контейнер работает, запускается или перезапускается.
• Succeeded и Failed означают завершение всех контейнеров с успехом или хотя бы одной ошибкой соответственно.
• Фаза шире состояния контейнера и не равна условию Ready.

restartPolicy сообщает kubelet, когда перезапускать завершившиеся application containers в том же Pod.

• Always перезапускает завершившийся контейнер независимо от результата выхода.
• OnFailure перезапускает только контейнеры, завершившиеся с ошибкой.
• Never оставляет завершившийся контейнер остановленным.
• Политика применяется к application containers в Pod и не пересоздаёт Pod на другом узле.

Init container выполняется до успешного завершения перед запуском обычных application containers Pod.

• Несколько init containers выполняются последовательно в указанном порядке.
• Каждый должен завершиться успешно до запуска следующего init container или application container.
• Init containers могут использовать отдельные images, commands, security settings и общие volumes.
• Они подходят для предварительной настройки без помещения этой логики в основной application image.

Sidecar является вспомогательным контейнером, работающим рядом с основным application container в одном Pod.

• Он разделяет сеть Pod и может использовать общие с приложением volumes.
• Типичные роли включают proxying, сбор телеметрии или адаптацию файлов для основного процесса.
• Sidecar тесно связан с lifecycle Pod, а не развёртывается и масштабируется как независимый сервис.
• Sidecar увеличивает потребление ресурсов и операционную поверхность Pod, поэтому связанность должна быть осознанной.

Deployment декларативно управляет набором реплицированных application Pods и их обновлениями.

• Его Pod template описывает контейнеры и metadata для новых Pods.
• Поле replicas задаёт число существующих matching Pods.
• Deployment создаёт ReplicaSets и управляет ими, а не владеет Pods напрямую.
• Он предназначен для stateless workloads, Pods которых можно заменить из одного template.

ReplicaSet является controller, который поддерживает заданное число matching Pod replicas.

• Он использует label selector для определения управляемых Pods.
• Если matching Pods слишком мало, он создаёт новые из Pod template.
• Если matching Pods слишком много, он удаляет лишние.
• Пользователи обычно управляют ReplicaSets через Deployments, добавляющие обновления и revisions.

Deployment управляет ReplicaSets, а каждый ReplicaSet поддерживает Pods, созданные из одной revision template.

• Изменение Pod template Deployment приводит к созданию нового ReplicaSet.
• Новый и старый ReplicaSets меняют число replicas согласно стратегии обновления.
• Pods получают owner references, связывающие их с ReplicaSet.
• Такое многоуровневое владение позволяет Kubernetes сохранять желаемое число replicas при замене версии workload.

Поле replicas объявляет желаемое число доступных экземпляров Pod для workload Deployment.

• Deployment и его ReplicaSet постоянно сравнивают желаемое и наблюдаемое количество.
• Отсутствующий Pod заменяется, чтобы число вернулось к объявленному значению.
• Несколько replicas могут распределять application traffic между отдельными экземплярами Pod.
• Replicas дублируют Pod template, но автоматически не делят данные приложения.

Reconciliation является повторяющимся процессом приближения фактического состояния кластера к желаемому состоянию из API.

• Controller наблюдает ресурсы, относящиеся к управляемому им состоянию.
• Он сравнивает объявленную спецификацию с текущими объектами или условиями.
• При различии состояний он создаёт, обновляет или удаляет ресурсы.
• Цикл повторяется, поэтому Kubernetes может исправлять последующий drift, а не выполнять одноразовый скрипт.

Labels являются key-value metadata для идентификации и группировки объектов.

• Они могут описывать application, component, environment или version.
• Selectors используют labels для поиска наборов объектов без опоры на имена.
• Services и workload controllers зависят от точных labels для соединения связанных ресурсов.
• Labels предназначены для идентификации, а большой описательный текст следует хранить в annotations.

Label selector является запросом, сопоставляющим Kubernetes-объекты по их labels.

• Equality selectors соответствуют выражениям вроде app=web или tier!=frontend.
• Set-based selectors выражают принадлежность через операторы In, NotIn и Exists.
• Selector Service определяет, какие Pods становятся его backends.
• Selector controller должен соответствовать labels в его Pod template, чтобы управлять нужными Pods.

Annotations хранят неидентифицирующие metadata, а labels предназначены для выбора и группировки объектов.

• Annotations могут содержать конфигурацию инструментов, ownership links, checksums или описательные детали.
• Selectors не могут запрашивать annotations.
• Значения annotation могут хранить более крупный и менее структурированный текст, чем labels.
• Metadata для определения членства в Service или controller должны находиться в labels, а не annotations.

Namespace создаёт логическую область для многих namespaced resources внутри одного кластера.

• Pods, Deployments, Services, ConfigMaps и Secrets обычно принадлежат Namespace.
• Одинаковое имя ресурса может существовать в разных Namespaces.
• RBAC rules, quotas и policies можно применять по Namespace.
• Namespaces организуют и ограничивают scope ресурсов, но автоматически не являются полной security boundary.

Namespaced resources принадлежат одному Namespace, а cluster-scoped resources существуют для всего кластера.

• Pods, Deployments, Services, ConfigMaps, Secrets и PersistentVolumeClaims являются namespaced.
• Nodes, Namespaces, PersistentVolumes и многие cluster-level RBAC objects являются cluster-scoped.
• Имя namespaced resource должно быть уникальным только внутри его Namespace.
• kubectl использует выбранный Namespace для namespaced resources, но не добавляет его cluster-scoped resources.