Архитектура, Pods, ReplicaSet и Deployments

From wiki.baghirzade.pro
Jump to navigation Jump to search

1. Почему Kubernetes? (Orchestration vs Docker)

При переходе от тестирования к Production-среде одного Docker становится недостаточно. Основные проблемы, которые решает Kubernetes:

  • Self-healing (Самолечение): Если контейнер падает, K8s его перезапускает. Если падает целая нода — переносит поды на живые сервера.
  • Auto-scaling: Автоматическое масштабирование количества копий приложения в зависимости от нагрузки.
  • Service Discovery & Load Balancing: K8s дает единый IP для группы контейнеров и сам распределяет трафик между ними.
  • Automated Rollouts/Rollbacks: Управление обновлениями версий без простоя (Downtime).

2. Архитектура Кластера (Control Plane & Workers)

Кластер делится на две основные части:

Control Plane (Master Nodes) — "Мозги" кластера

  1. kube-apiserver: Центральный узел. Все компоненты общаются только через него.
  2. etcd: Распределенное хранилище "ключ-значение". База данных кластера.
    • Важно: Для отказоустойчивости (High Availability) требуется нечетное количество мастеров (3, 5), чтобы соблюдался Quorum.
  3. kube-scheduler: Решает, на какой воркер-ноде запустить под (исходя из ресурсов CPU/RAM).
  4. kube-controller-manager: Следит за соблюдением желаемого состояния (Desired State).

Worker Nodes — "Рабочие лошадки"

  1. kubelet: Агент на каждой ноде. Следит, чтобы контейнеры были запущены и здоровы.
  2. kube-proxy: Сетевой помощник. Обеспечивает доступ к подам через IP и порты.
  3. Container Runtime: Среда запуска контейнеров (обычно containerd).

3. Основные объекты Kubernetes

3.1 Pod (Под)

Самая маленькая единица в K8s.

  • Под может содержать один или несколько контейнеров.
  • Все контейнеры внутри одного Пода делят один IP-адрес и localhost.
  • Sidecar Pattern: Использование вспомогательного контейнера рядом с основным (например, для сбора логов или проксирования трафика через Vault/Istio).

3.2 ReplicaSet (RS)

Контроллер, который гарантирует, что в кластере запущено именно то количество копий (реплик) пода, которое вы указали.

  • Если под удален вручную или упал — ReplicaSet создаст новый.
  • Ограничение: RS не умеет обновлять версии приложений без ручных манипуляций.

3.3 Deployment (Деплоймент)

Самый важный объект для управления приложениями. Он стоит над ReplicaSet.

  • Функции: Обновление приложения (Rolling Update), откат изменений (Rollback), пауза/возобновление деплоя.
  • При обновлении Deployment создает новый ReplicaSet с новой версией и постепенно переносит нагрузку на него, удаляя старые поды.

4. Шпаргалка по командам (Cheat Sheet)

Команда Описание
kubectl get nodes Проверка статуса серверов кластера
kubectl get pods -o wide Список подов с их IP и нодами
kubectl describe pod <name> Глубокий анализ пода (Events покажут ошибки)
kubectl logs -f <name> Просмотр логов контейнера в реальном времени
kubectl exec -it <name> -- bash Вход внутрь контейнера
kubectl apply -f <file.yaml> Создание/обновление объекта из файла
kubectl get rs Просмотр статуса репликасетов
kubectl get deploy Просмотр статуса деплойментов
kubectl rollout history deploy/<name> История версий (апдейтов) приложения
kubectl rollout undo deploy/<name> Откат к предыдущей версии

5. Примеры манифестов (YAML)

Deployment (Рекомендуемый способ запуска)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 # Количество копий
  selector:
    matchLabels:
      app: nginx # Находит поды с этим лейблом
  template: # Шаблон самого пода
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

💡 Важные заметки для DevOps-инженера:

  1. Labels (Метки): Это "клей" в Kubernetes. Деплоймент находит свои поды только благодаря совпадению меток в selector и template.metadata.labels.
  2. Immutable Pods: Мы не правим конфиги внутри запущенного пода. Мы меняем YAML-файл и делаем kubectl apply, после чего Deployment пересоздает поды.
  3. Dry Run: Чтобы быстро получить шаблон YAML, используй: kubectl create deployment my-dep --image=nginx --dry-run=client -o yaml > deploy.yaml
Retrieved from "https://wiki.baghirzade.pro/index.php?title=Архитектура,_Pods,_ReplicaSet_и_Deployments&oldid=204"