4 частых вопроса на собеседовании по части Kubernetes, с которыми может столкнуться каждый. Часть 103.05.2024 17:00

4e20eeb5c72c5054f27a2dd937910e0e.png

Привет, Хабр!

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

Начнем с основной архитектуры Kubernetes и роли основных компонентов…

Архитектура Kubernetes и компоненты управления

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

Управляющая плоскость отвечает за управление кластером Kubernetes и включает такие компоненты:

  1. kube-apiserver действует как центральный компонент управляющей плоскости. Он обрабатывает все REST запросы, выполняя функции аутентификации, авторизации, а также принимая и обрабатывая API-запросы от различных частей кластера. kube-apiserver может масштабироваться горизонтально. Этот компонент также отвечает за сохранение и извлечение конфигурационных данных кластера из etcd и обеспечивает согласованность и актуальность состояния кластера.

  2. etcd — это распределенная БД ключ-значение, которая используется Kubernetes для хранения всех важных данных конфигурации, состояния кластера и метаданных. Являясь основным хранилищем для всех конфигураций кластера и состояния объектов API, etcd позволяет восстанавливать состояние кластера в случае сбоев или перезапусков узлов.

  3. kube-schedule отвечает за распределение подов по узлам кластера на основе различных факторов, включая доступные ресурсы и требования к политикам распределения.

  4. kube-controller-manager управляет контроллерами, которые, в свою очередь, следят за состоянием кластера. Каждый контроллер работает независимо, стараясь привести текущее состояние кластера в соответствие с желаемым.

  5. cloud-controller-manager позволяет интегрировать кластер Kubernetes с облачными провайдерами, типо AWS, Google Cloud, Azure и т.п. Компонент управляет ресурсами, специфичными для облачных провайдеров: сетевые маршруты, балансировщики и так далее.

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

  • kubelet является агентом, который устанавливается на каждом рабочем узле в кластере Kubernetes. Основная его задача — обеспечить, чтобы контейнеры в подах были запущены и работали в соответствии с описанными в спецификациях подов, которые Kubernetes получает через API. kubelet использует набор предопределенных PodSpecs, контролируя состояние контейнеров и реагируя на различные изменения состояния кластера. Он регулярно отправляет информацию о состоянии рабочего узла и его контейнеров на kube-apiserver, обеспечивая тем самым актуальность данных о состоянии кластера​.

  • kube-proxy работает на каждом рабочем узле и выполняет функции прокси-сервера и балансировщика нагрузки для трафика, поступающего в Kubernetes сервисы, которые основаны на TCP и UDP протоколах. Компонент использует iptables (или аналогичные технологии) для маршрутизации трафика к соответствующим контейнерам. kube-proxy нужен, чтобы внутренняя сетевая связь между сервисами в кластере была оптимизирована и безопасна

  • Container Runtime — это среда выполнения контейнеров, которая отвечает за запуск контейнеров на рабочем узле. Kubernetes поддерживает несколько сред выполнения контейнеров, таких как Docker, containerd, CRI-O, и каждый рабочий узел должен иметь установленную среду выполнения, чтобы запускать контейнеры. Runtime занимается такими задачами, как извлечение образов контейнеров из реестра, их запуск и управление их жизненным циклом

Итак, нужно понимать, что фича архитектуры Kubernetes заключается в том, что она позволяет оптимизировать развертывание и управление приложениями.

Pod

Частенько спрашивают про Pod.

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

Контейнеры внутри Pod работают на одном узле, делят одинаковый IP-адрес, порт и другие ресурсы, что позволяет им легко общаться через localhost.

Pod’ы имеют собственный жизненный цикл; они создаются, запускаются, останавливаются и удаляются независимо друг от друга в рамках одного кластера. При перезапуске узла Pod может быть автоматически пересоздан на другом узле с тем же самым хранилищем/данными, если он использует постоянное хранилище.

Управление Pod’ами осуществляется с помощью контроллеров высшего уровня, таких как ReplicaSet, Deployments и StatefulSets. Кстати, про два из них поговорим немного ниже.

Pod’ы могут разделять тома, что дает возможность обмена данными между контейнерами внутри одного Pod. Kubernetes поддерживает несколько типов томов, таких как local volumes, persistentVolumeClaims (для постоянного хранения) и сетевые хранилища, такие как NFS или cloud-specific storage solutions.

Kubernetes поддерживает различные проверки для контейнеров внутри Pod:

  • Liveness probes: проверяет, работоспособен ли контейнер. Если проверка неудачна, kubelet перезапустит контейнер.

  • Readiness probes: определяет, готов ли контейнер к обслуживанию трафика. Неудачная проверка предотвратит пересылку трафика на контейнер до тех пор, пока проверка снова не станет успешной.

  • Startup probes: используется для определения того, когда приложение в контейнере было запущено успешно.

Сервисы

Обычно если спросят про Pod, то после спрашивают про сервисы.

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

Каждый сервис ClusterIP получает сетевое имя внутри кластера, которое можно использовать другими сервисами или приложениями для обращения к этому сервису.

Каждый сервис получает свой уникальный IP-адрес внутри кластера, который автоматически маскируется за сетевым именем.

Для определения, какие поды принадлежат к сервису ClusterIP, используются метки и селекторы. Сервис привязывается к подам, которые имеют определенные метки.

NodePort — это тип сервиса, который апдейтит ClusterIP, предоставляя доступ к сервису извне кластера через спецом открытый порт на каждом узле.

При создании сервиса NodePort Kubernetes автоматически назначает ему высокий порт (в диапазоне 30000–32767) на каждом узле кластера. Этот порт прослушивается на всех узлах и перенаправляет трафик на соответствующий сервис ClusterIP.

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

LoadBalancer — это тип сервиса, который автоматом предоставляет балансировку нагрузки для сервиса и экспонирует его наружу кластера через внешний IP-адрес.

В облачных окружениях LoadBalancer взаимодействует с облачными провайдерами для автоматического создания и настройки внешних балансировщиков нагрузки.

Kubernetes назначает внешний IP-адрес сервису LoadBalancer, который пользователи могут использовать для доступа к сервису извне кластера.

LoadBalancer автоматически распределяет входящий трафик между подами.

Масштабирование и отказоустойчивость

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

ReplicaSet

ReplicaSet обеспечивает надежное управление масштабированием приложений путем поддержки заданного количества реплик подов. Он гарантирует, что определенное количество подов всегда работает и доступно для обработки запросов.

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

Пример манифеста, который создает ReplicaSet с тремя репликами: 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80

apiVersion и kind определяют тип ресурса — ReplicaSet. metadata содержит метаданные, такие как имя ReplicaSet.

spec определяет желаемое состояние ReplicaSet: replicas: 3 указывает, что должно быть три реплики подов, selector определяет, какие поды управляются этим ReplicaSet, в данном случае это поды с меткой app: my-app, template определяет шаблон для создания подов, внутри него описывается контейнер с образом nginx:latest, который слушает порт 80.

После применения этого манифеста в кластере Kubernetes будет создан ReplicaSet my-replicaset, управляющий тремя подами с контейнером Nginx. Если какой-либо из подов выйдет из строя или будет удален, ReplicaSet автоматически восстановит требуемое количество реплик.

StatefulSet

StatefulSets являются контроллерами, предназначенными для управления состоянием приложений, которым требуется уникальная идентификация, устойчивое хранение данных и гарантированная последовательность операций

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

StatefulSet поддерживает возможность использования постоянного хранилища для хранения данных приложения.

Пример манифеста который создает StatefulSet с тремя подами: 

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-statefulset
spec:
  replicas: 3
  serviceName: "my-service"
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Таким образом будет создан StatefulSet my-statefulset, управляющий тремя подами с контейнером Nginx. Каждый из этих подов будет иметь уникальное стабильное сетевое имя и будет использовать постоянное хранилище объемом 1 Гб для сохранения данных.

А какие вопросы задавали на собеседование по Kubernetes вам?

Если вы считаете, что ими нужно поделиться, добро пожаловать в комментарии!

Больше практических навыков по Kubernetes и не только вы можете получить в рамках практических онлайн-курсов OTUS от экспертов отрасли.

Habrahabr.ru прочитано 2641 раз