Сегодня одним из самых популярных в использовании инструментов в стеке техкомпаний является Kubernetes. С момента своего выхода K8s получил массовое распространение, расширив свою экосистему и увеличив количество пользователей. В 2021 году CNCF (Cloud Native Computing Foundation) провел опрос, который показал, что 96% организаций (которые приняли в нём участие) используют или уже пробуют Kubernetes в своем технологическом стеке.

Без сомнения, с внедрением Kubernetes поиск квалифицированного персонала стал более востребованным, чем когда-либо. В этой статье мы рассмотрим наиболее распространенные вопросы, которые задают интервьюеры, и ответы на них.

Итак, давайте ознакомимся с самыми распространенными вопросами интервью по Kubernetes:

1. Какие компоненты мастер-узла (Control Plane) Kubernetes и каково их назначение?

2. Каковы компоненты рабочего узла (worker node) и их назначение?

3. В чем разница между Init- и Sidecar-контейнерами?

4. В чем разница между Deployment и StatefulSet?

5. Перечислите различные типы сервисов и для чего они используются.

Какие компоненты мастер-узла (Control Plane) Kubernetes и каково их назначение?

Узлы Control Plane Kubernetes являются “мозгом” кластера k8s. Узлы Control Plane управляют pod’ами в кластере и рабочими узлами, которые участвуют в кластере.

Control Plane Kubernetes состоит из четырех компонентов в кластере on-prem и пяти в кластерах cloud/hybrid Kubernetes. Как администраторы кластера, мы хотели бы иметь по крайней мере три узла Control Plane в производственной среде по соображениям отказоустойчивости.

Kube-api-server — API-сервер Kubernetes проверяет и настраивает данные для API-объектов, включая pod’ы, сервисы, контроллеры репликации и другие. API-сервер обслуживает REST-операции и предоставляет фронтэнд для общего состояния кластера, через которое взаимодействуют все остальные компоненты.

Kube-controller-manager — Kubernetes controller manager - демон, который реализует основные контуры управления, поставляемые с Kubernetes. В робототехнике и автоматизации контур управления - это непрерывный контур, регулирующий состояние системы. Примерами контроллеров, которые сегодня поставляются с Kubernetes, являются контроллеры replication, endpoints, namespace и serviceaccounts.

Kube-scheduler — Планировщик Kubernetes - это процесс Control Plane, который назначает pod’ы узлам. Планировщик определяет, какие узлы являются допустимыми местами размещения для каждого pod’а в очереди планирования в соответствии с ограничениями и доступными ресурсами. Затем планировщик ранжирует каждый допустимый узел и привязывает pod к подходящему узлу. Планировщиков может быть несколько.

Etcd — распределенное целостное хранилище ключей и данных с открытым исходным кодом, используемое для совместной конфигурации, обнаружения сервисов и координации планировщика распределенных систем или кластеров машин. В Control Plane Kubernetes Etcd используется для хранения и репликации всех состояний кластера k8s.

Cloud-controller-manager (используется в облачных провайдерах) — Cloud-controller-manager обеспечивает интерфейс между кластером Kubernetes и облачными API-сервисами. Диспетчер облачных контроллеров позволяет кластеру Kubernetes обеспечивать, отслеживать и удалять облачные ресурсы, необходимые для рабочих операций кластера.

В сценарии, при котором большинство узлов Control Plane не работает, кластер не сможет обслуживать API-запросы, поэтому кластер будет недоступен. Хотя, если рабочие узлы исправны, pod’ы будут в рабочем состоянии, но не смогут быть перераспределены.

Каковы компоненты рабочего узла (worker node) и их назначение?

Рабочие узлы (worker nodes) отвечают за размещение прикладных pod’ов в кластере. Хотя прикладные pod’ы можно размещать в узлах Control Plane, наилучшей практикой является размещение pod’ов на рабочих узлах по соображениям безопасности.

Рабочие узлы содержат компоненты, которые позволяют им выполнять запросы Control Plane.

Kube-proxy — kube-proxy отвечает за поддержание сетевых правил на ваших узлах. Сетевые правила позволяют осуществлять сетевую связь с вашими pod’ами как внутри, так и за пределами вашего кластера.

Kubelet — Kubelet является агентом, который запускается на каждом узле. Он отвечает за создание pod’ов в соответствии с предоставленной спецификацией YAML, отправку на API-сервер состояния работоспособности pod’ов и предоставление информации о состоянии узла, такой как сеть, дисковое пространство и многое другое.

В чем разница между Init- и Sidecar-контейнерами?

Самый простой pod — это pod, состоящий из одного контейнера. Этот контейнер обеспечивает основные функции приложения, но что, если вы хотите расширить существующую функциональность, не изменяя и не усложняя основной контейнер?

По этой причине pod’ы могут включать в себя несколько контейнеров. Существует шаблон проектирования контейнера, который полезен для различных сценариев, но строительные блоки для этих шаблонов проектирования реализуются с помощью Init-контейнера и sidecar-контейнера.

Init-контейнер — всегда запускается перед Sidecar-контейнером и основным контейнером приложения. Init-контейнер должен быть запущен до успешного завершения, прежде чем смогут начать работу остальные контейнеры. Причиной использования Init-контейнера могут быть разнообразные применения. Например, его можно использовать для проверки наличия зависимостей приложения, настройки основной среды или среды контейнера Sidecar-контейнера, а также многого другого.

Sidecar-контейнер — запускается параллельно основному контейнеру приложения. Существуют различные причины для использования сайдкар контейнеров. Например, в Istio Sidecar-контейнер используется в качестве прокси-сервера для управления входящим трафиком на основной контейнер, его также можно использовать для логгирования, целей мониторинга и многого другого.

Пример контейнеров для Istio для инициализации среды и перехвата контейнерного трафика:

apiVersion: v1
kind: Pod
metadata:
name: example
spec:
# init container section where you can setup your init containers
 initContainers:
 - name: istio-init
   image: istio/proxyv2:1.11.2
 containers:
 - name: hello
   image: alpine
# our sidecar container which will intercept the pod network tarffic
 - name: istio-proxy
   image: istio/proxyv2:1.11.2
   volumeMounts:
   - mountPath: /etc/certs
     name: certs
 volumes:
 - name: certs
   secret:
     secretName: istio-certs

В чем разница между Deployment и StatefulSet?

Один из самых распространенных вопросов, с которым мы столкнемся на собеседовании. Чтобы ответить на этот вопрос, нам нужно будет рассмотреть каждый ресурс и понять их различия.

Deployment — является самым простым и наиболее часто используемым ресурсом для развертывания приложений в кластере Kubernetes. Deployment обычно используются для приложений без состояния, что означает, что данные, находящиеся в pod’е, будут удалены вместе с pod’ом. Если мы используем постоянное хранилище с Deployment,, у нас будет одинPersistence volume claim для всех pod’ов, которые принимают участие в развертывании. Deployment порождает ресурс ReplicaSet, через который идут переключения между разными версиями нашего приложения. Pod’ы, принадлежащие Deployment всегда именуются по следующей схеме: <deployment-name>-<replicaset-id>-<pod-id>.

StatefulSet — ресурс, который стал стабильным в версии Kubernetes 1.9, поскольку сообщество запросило возможность размещения приложений с состоянием в кластере Kubernetes. StatefulSet не использует ReplicaSet в качестве вторичного контроллера, но он управляет pod’ами самостоятельно. Pod’ы StatefulSet’а именуются по следующему шаблону: <Statefulset-name>-0, <Statefulset-name>-1. Соглашение об именовании используется для сетевых идентификаторов и управления обновлением. StatefulSet требует headless-сервис, позволяя обеспечить идентифицкацию в сети и разрешение DNS имен для pod’ов, участвующих в StatefulSet. Каждая реплика в развертывании StatefulSet получает собственную persistent volume clain, так что каждый pod будет иметь свое собственное состояние.

Наконец, эмпирическое правило заключается в том, что приложения без состояния должны разворачиваться через Deployment. Deployment включают в себя другой контроллер, называемый ReplicaSet, для упрощения обновлений и откатов. StatefulSet был создан на основе потребностей сообщества и обычно используется для приложений с состоянием таких как, например, баз данных, где определение других реплик в кластере имеет решающее значение, а обновления должны выполняться корректно.

Перечислите различные типы сервисов. Для чего они используются?

Сервис Kubernetes — это логическая абстракция группы pod’ов, выбранных селектором. Service используется для настройки политики, с помощью которой можно получить доступ к нижележащим pod’ам.

В вашем интервью вас, вероятно, спросят о четырех наиболее распространенных типах сервисов, описанными далее:

ClusterIP — ClusterIP является типом сервиса по умолчанию и наиболее распространенным сервисом в экосистеме Kubernetes. Сервис типа ClusterIP имеет внутрикластерный IP-адрес и доступен только в рамках кластера.

LoadBalancer — тип сервиса LoadBalancer используется для обеспечения доступа внешнего трафика путем выделения loadbalancer. Чтобы использовать этот тип сервиса, необходима поддерживающая это платформа, которая сможет распределять loadbalancer. Loadbalancer будет создан асинхронно, и информация о балансировщике нагрузки будет доступна в сервисе только тогда, когда он будет доступен и присвоен сервису. Тип службы loadbalancer также имеет ClusterIP и выделяет NodePort для доступа к сервису.

NodePort — тип сервиса NodePort обычно используется, когда сервису предоставляется доступ к внешнему трафику, а тип Service LoadBalancer недоступен. С типом Service NodePort вы выбираете порт (в пределах допустимого диапазона от 30000 до 32767), который каждый узел в кластере откроет для приема трафика и переадресации на сервис. Тип службы NodePort также имеет ClusterIP, который позволяет сервису быть доступным из кластера.

Headless — тип сервиса Headless используется, когда требуется прямая связь с pod’ом. В приложениях с состоянием, например, баз данных вторичные pod’ы должны напрямую взаимодействовать с первичными pod’ами для репликации данных между репликами. Headless позволяет DNS разрешать pod’ы и получать к ним доступ по имени pod’а. Headless - это сервис, который настроен иным образом, чем ClusterIP и не имеет отдельного внутрикластерного IP адреса. Для доступа к pod’у через Headless-сервис необходимо будет воспользоваться следующим доменным именем: <pod-name>.<service-name>.<namespace>.svc.cluster.local.

Заключение

Kubernetes сегодня является одной из наиболее часто используемых технологий в IT-отрасли, поэтому организация ищет талантливых сотрудников, обладающих образованием и опытом в этой области. Темы, рассмотренные в этой статье, являются одними из наиболее частых вопросов, задаваемых в интервью. Хотя эта статья ответила на пять основных вопросов, информация, написанная здесь, будет полезна в различных сценариях интервью. 

Заглядываем под капот K8s на курсе «Kubernetes: Мега», старт уже 14 февраля.