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

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

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

1. Каковы компоненты плоскости управления Kubernetes и их назначение?

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

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

4. В чем разница между развертыванием и набором с сохранением состояния?

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

Каковы компоненты плоскости управления Kubernetes и их назначение?

Узлы плоскости управления Kubernetes являются “мозгом” кластерных операций Kubernetes. Они управляют блоками в кластере и рабочими узлами, которые принимают участие в кластере.

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

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

Kube-controller-manager — диспетчер контроллеров Kubernetes. Он встраивает основные контуры управления, поставляемые с Kubernetes. В приложениях робототехники и автоматизации контур управления — это непрерывный контур, который регулирует состояние системы. Примерами контроллеров, которые сегодня поставляются с Kubernetes, являются контроллер репликации, контроллер конечных точек, контроллер пространства имен и контроллер service accounts.

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

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

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

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

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

Рабочие узлы отвечают за размещение модулей приложений в кластере. Хотя прикладные модули можно размещать в узлах плоскости управления, наилучшей практикой является планирование модулей на рабочих узлах по соображениям безопасности. Рабочие узлы содержат компоненты, которые позволяют им выполнять запросы плоскости управления.

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

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

В чем разница между контейнером init и контейнером sidecar?

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

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

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

Контейнер sidecar — контейнер sidecar проходит параллельно основному контейнеру приложения. Причиной использования контейнера sidecar могут быть разные факторы. Например, в истории контейнер 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) — является самым простым и наиболее часто используемым ресурсом для развертывания приложений в кластере Kubernetes. Развертывания обычно используются для приложений без состояния, что означает, что данные, находящиеся в модуле, будут удалены вместе с модулем. Если мы используем постоянное хранилище при развертывании, у нас будет одна заявка на постоянный объем для всех модулей, которые принимают участие в развертывании. Развертывания оборачивают ресурс набора реплик, позволяя ему легко переключаться между версиями. Соглашение об именовании модуля настроено следующим образом <deployment-name>-<replicaset-id>-<pod-id>.

Statefulset — ресурс, который стал стабильным в версии Kubernetes 1.9, поскольку сообщество запросило возможность размещения приложений с отслеживанием состояния в кластере Kubernetes. Statefulset не использует Replicaset в качестве вторичного контроллера, но он управляет блоками самостоятельно. Соглашение об именовании модулей выглядит следующим образом <Statefulset-name>-0, <Statefulset-name>-1.

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

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

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

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

В интервью вас, вероятно, спросят о четырех наиболее распространенных типах услуг, которые заключаются в следующем.

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

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

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

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

Вывод

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

Поток Kubernetes: Мега Для тех, кто уже работал с k8s