Архитектура, Pods, ReplicaSet и Deployments
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) — "Мозги" кластера
- kube-apiserver: Центральный узел. Все компоненты общаются только через него.
- etcd: Распределенное хранилище "ключ-значение". База данных кластера.
- Важно: Для отказоустойчивости (High Availability) требуется нечетное количество мастеров (3, 5), чтобы соблюдался Quorum.
- kube-scheduler: Решает, на какой воркер-ноде запустить под (исходя из ресурсов CPU/RAM).
- kube-controller-manager: Следит за соблюдением желаемого состояния (Desired State).
Worker Nodes — "Рабочие лошадки"
- kubelet: Агент на каждой ноде. Следит, чтобы контейнеры были запущены и здоровы.
- kube-proxy: Сетевой помощник. Обеспечивает доступ к подам через IP и порты.
- 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-инженера:
- Labels (Метки): Это "клей" в Kubernetes. Деплоймент находит свои поды только благодаря совпадению меток в
selectorиtemplate.metadata.labels. - Immutable Pods: Мы не правим конфиги внутри запущенного пода. Мы меняем YAML-файл и делаем
kubectl apply, после чего Deployment пересоздает поды. - Dry Run: Чтобы быстро получить шаблон YAML, используй:
kubectl create deployment my-dep --image=nginx --dry-run=client -o yaml > deploy.yaml