Kubernetes. Cобеседование

https://habr.com/ru/company/southbridge/blog/713884/

Что такое Kubernetes?
Расскажите об основных компонентах kubernetes
Чем полезна оркестровка контейнеров?
Как связаны Kubernetes и Docker?
Что такое node в Kubernetes?
Что такое pod в Kubernetes?
Что такое Kubernetes deployment?
Опишите набор действий необходимых для запуска deployment?
Объясните разницу между pod и deployment
Что такое service?
что такое namespace
что такое controller-manager
какие типы controller-manager вы знаете?(endpoints controller, service accounts controller, namespace controller, node controller, token controller, and replication controller)
для чего etcd в kubernetes?
что такое clusterIP?
что такое NodePort?
что такое kubelet?
что такое kube-proxy?

Какие компоненты мастер-узла (Control Plane) Kubernetes и каково их назначение?
Каковы компоненты рабочего узла (worker node) и их назначение?
В чем разница между Init- и Sidecar-контейнерами?
В чем разница между Deployment и StatefulSet?
Перечислите различные типы сервисов и для чего они используются.

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

компоненты мастер-узла (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 — 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.