Как работает Kubernetes?

Как работает Kubernetes

Kubernetes (или **k8s**) — это система оркестрации контейнеров, которая автоматизирует部署 (deployment), масштабирование и управление приложениями, работающими в контейнерах. В основе его работы лежит абстрагирование инфраструктуры и предоставление унифицированного API для управления кластером как единым целым.

Основные архитектурные компоненты

Kubernetes кластер состоит из двух типов узлов:

• Control Plane (Управляющая плоскость) — «мозг» кластера, управляющий состоянием.
• Worker Nodes (Рабочие узлы) — машины, где фактически запускаются контейнеры приложений.

Компоненты Control Plane:

• kube-apiserver: Центральный компонент, предоставляющий API Kubernetes. Все взаимодействия (через kubectl, другие компоненты) происходят через него.
• kube-controller-manager: Запускает различные контроллеры, которые следят за состоянием кластера и выполняют корректирующие действия (например, если Pod упал, контроллер попытается восстановить его).
• kube-scheduler: Определяет, на каком Worker Node запустить новый Pod, учитывая требования к ресурсам, политики и другие ограничения.
• etcd: Высокопроизводительное распределенное хранилище ключ-значение, где хранится вся конфигурация и состояние кластера (единственное состояниеful компонент).

Компоненты Worker Node:

• kubelet: Агент на каждом узле, который взаимодействует с Control Plane и обеспечивает запуск/состояние контейнеров в Pods.
• kube-proxy: Реализует сетевую модель Kubernetes, обеспечивая базовую нагрузку и сетевые правила для Service.
• Container Runtime: Программа для запуска контейнеров (например, Docker, containerd).

Ключевые объекты и их взаимодействие

Kubernetes управляет приложениями через абстракции, представленные как объекты в API:

1. Pod: Базовая единица выполнения. Это группа одного или нескольких контейнеров с shared storage и сетью. Pod — это ephemeral (временный) объект.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: app-container
    image: myapp:latest

1. Deployment: Объект более высокого уровня, который управляет жизненным циклом Pods. Он обеспечивает declarative updates, масштабирование и rollback стратегии.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app-container
        image: myapp:latest

1. Service: Абстракция, которая определяет логический набор Pods и политику доступа к ним (часто как микросервис). Она обеспечивает stable IP адрес и DNS имя, даже если Pods меняются.

2. ConfigMap и Secret: Объекты для управления конфигурацией и чувствительными данными отдельно от кода приложения.

Как происходит запуск приложения

Процесс можно разбить на шаги:

• Пользователь создает или обновляет объект (например, Deployment) через kubectl, который отправляет запрос к kube-apiserver.
• kube-apiserver валидирует запрос и сохраняет новое состояние в etcd.
• Контроллер (например, Deployment controller), работающий в kube-controller-manager, через apiserver наблюдает изменение в состоянии Deployment в etcd.
• Контроллер вычисляет, что необходимо создать новые Pods для соответствия желаемому состоянию (например, replicas: 3). Он создает объекты Pod через apiserver (сохраняя их в etcd).
• kube-scheduler наблюдает новые Pods, которые еще не назначены на узлы. Он анализирует доступные Worker Nodes, учитывая ресурсы (CPU, memory), nodeSelector, taints/tolerations и другие constraints, и выбирает оптимальный узлы. Затем он «привязывает» Pod к узлу через apiserver (обновляет поле nodeName Pod в etcd).
• kubelet на выбранном Worker Node наблюдает (через apiserver), что ему назначен новый Pod. Он взаимодействует с локальным Container Runtime (например, containerd), чтобы запустить контейнеры, определенные в Pod spec.
• kubelet постоянно сообщает о состоянии Pod (Running, Failed) обратно в Control Plane через apiserver (в etcd).
• Если Pod падает, контроллер (ReplicaSet controller) заметит, что фактическое количество Pods меньше желаемого, и создает новый Pod, повторяя процесс.

Сетевые и storage абстракции

• Сеть: Kubernetes предполагает «плоскую» сетевую модель, где каждый Pod получает уникальный IP адрес, и все Pods могут коммуницировать друг с другом без NAT. Это реализуется сетевыми плагинами (CNI), такими как Calico, Flannel.
• Storage: Для сохранения данных вне lifecycle Pod используются PersistentVolumes (PV) и PersistentVolumeClaims (PVC). PV представляет физический ресурс storage в кластере, PVC — запрос на storage от пользователя. kubelet монтирует нужный volume в контейнер.

Краткий пример workflow

# 1. Пользователь декларирует желаемое состояние
kubectl apply -f deployment.yaml

# 2. Control Plane (через контроллеры и scheduler) приводит кластер к этому состоянию
# 3. Pods запускаются на рабочих узлах
# 4. Service предоставляет стабильный endpoint для доступа к этим Pods
# 5. Если один Pod падает, Deployment автоматически создает новый

Таким образом, Kubernetes работает как система с постоянной обратной связью, где Control Plane постоянно наблюдает фактическое состояние кластера (хранящееся в etcd) и через набор контроллеров стремится привести его к желаемому состоянию, объявленному пользователем. Это declarative подход (описываю, что нужно, а не как это сделать) и принцип self-healing лежат в основе его надежности и популярности.

Как работает Kubernetes: архитектура и основные принципы

Kubernetes (K8s) — это платформа для оркестрации контейнерных приложений с открытым исходным кодом. В основе её работы лежит декларативная модель: вы описываете желаемое состояние (например, "должно работать 5 копий приложения Nginx"), а Kubernetes автоматически приводит систему к этому состоянию, управляя развёртыванием, масштабированием, сетевым взаимодействием и отказоустойчивостью.

Архитектура Kubernetes: Master и Worker Nodes

Система строится по модели Master-Worker (Control Plane — Data Plane):

1. Control Plane (Master Node) — мозг кластера

Управляющая плоскость принимает решения о кластере и реагирует на события.

• kube-apiserver: Фронтенд Control Plane. Единственный компонент, с которым взаимодействуют пользователи (через kubectl) и другие компоненты. Принимает REST-запросы, валидирует их и обновляет соответствующие объекты в etcd.
• etcd: Высокодоступное распределённое key-value хранилище. Хранит всю конфигурацию и состояние кластера (желаемое и текущее). Это "единственный источник истины".
• kube-scheduler: Отвечает за распределение подов (Pod) по рабочим узлам. Анализирует ресурсы узлов (CPU, RAM) и ограничения Pod'ов, выбирает оптимальный узел.
• kube-controller-manager: Запускает контроллеры — циклы управления, которые следят за состоянием кластера и вносят изменения для приведения его к желаемому. Например:

    *   *Deployment Controller* следит за ReplicaSet'ами.
    *   *Node Controller* проверяет доступность узлов.
    *   *Service Controller* создаёт облачные балансировщики нагрузки.

2. Data Plane (Worker Nodes) — рабочие лошадки

На этих узлах работают пользовательские приложения.

• kubelet: Агент на каждом узле. Получает спецификации Pod'ов от API-сервера и обеспечивает, чтобы контейнеры в этих Pod'ах были запущены и здоровы. Отчитывается о состоянии обратно.
• kube-proxy: Сетевой прокси. Поддерживает правила сетевых политик на узле, обеспечивая связность Pod'ов и доступ к ним извне через абстракции Service и Ingress.
• Container Runtime: Программное обеспечение для запуска контейнеров (например, containerd или CRI-O). Kubelet взаимодействует с ним через стандартный интерфейс CRI (Container Runtime Interface).

Ключевые абстракции (объекты) Kubernetes

Работа строится вокруг объектов, которые вы создаёте через YAML-манифесты или команды kubectl.

# Пример манифеста Deployment
apiVersion: apps/v1
kind: Deployment          # Тип объекта
metadata:
  name: nginx-deployment
spec:
  replicas: 3             # Желаемое состояние: 3 копии Pod
  selector:
    matchLabels:
      app: nginx
  template:               # Шаблон для создания Pod'ов
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

• Pod: Наименьшая и самая простая единица. Это "обёртка" для одного или нескольких контейнеров, которые разделяют сеть (IP-адрес) и хранилище (volumes).
• Deployment: Контроллер верхнего уровня для управления статическими приложениями. Обеспечивает декларативное обновление, откат и масштабирование Pod'ов через ReplicaSet.
• Service: Абстракция для постоянного доступа к группе динамических Pod'ов. Даёт стабильный IP/DNS-имя и балансировку нагрузки, даже если Pod'ы пересоздаются.
• ConfigMap & Secret: Объекты для хранения конфигурации и чувствительных данных (пароли, токены) отдельно от образов контейнеров. Монтируются в Pod'ы как файлы или переменные окружения.
• Namespace: Виртуальный кластер внутри физического. Позволяет делить ресурсы и изолировать команды/проекты (например, prod, dev).

Принцип работы на примере развёртывания приложения

1. Описание: Вы отправляете манифест (kubectl apply -f deployment.yaml) в kube-apisererver.
2. Сохранение: API-сервер валидирует его и сохраняет новое желаемое состояние (например, "3 Pod'а с Nginx") в etcd.
3. Распознание: Контроллеры (в частности, Deployment Controller) внутри kube-controller-manager замечают через API-сервер изменение в etcd.
4. Создание объектов: Deployment Controller создаёт объект ReplicaSet, который, в свою очередь, создаёт 3 объекта Pod (пока только в etcd, как желаемое состояние).
5. Планирование: kube-scheduler видит новые Pod'ы без назначенного узла. Он фильтрует доступные Worker Nodes по критериям (ресурсы, affinity/anti-affinity правила) и выбирает подходящие. Назначает узел Pod'у, обновляя информацию в etcd через API-сервер.
6. Исполнение: kubelet на выбранном Worker Node видит (опросом API-сервера), что ему назначили Pod. Он скачивает образ через Container Runtime и запускает контейнер(ы) Pod'а.
7. Сетевое взаимодействие: kube-proxy на узле настраивает iptables/IPVS правила, чтобы трафик на Service, связанный с этими Pod'ами, приходил на их актуальные IP-адреса.
8. Наблюдение и поддержание: Kubelet постоянно отчитывается о состоянии Pod'а (Running, Error). Если Pod падает, kube-controller-manager (через ReplicaSet) видит расхождение между желаемым (3) и текущим (2) состоянием и инициирует создание нового Pod'а. Этот цикл reconciliation (согласования) — сердце Kubernetes.

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