Обновление кластера, StatefulSet, Автомасштабирование и Ingress

Обновление — это ответственный процесс, требующий строгого порядка действий.

Резервное копирование (Backup): Перед любым обновлением обязателен бэкап ETCD. Это "мозг" кластера; если что-то пойдет не так, только из него можно восстановить состояние.
Очередность:
1. Master-ноды: Обновляются первыми (API Server, Controller Manager и т.д.).
2. Worker-ноды: Обновляются следом.
Команды управления узлом:
- cordon: Помечает ноду как недоступную для новых подов.
- drain: Безопасно выселяет (evict) все поды с ноды перед её обслуживанием или обновлением.
Версионность: Всегда следите за разницей версий между kubeadm, kubelet и kubectl. Обычно поддерживается разница в +/- одну минорную версию.

Используется для приложений, которым важна идентичность и сохранность данных (Databases: Postgres, Redis, MySQL).

Особенности:
- Поды получают стабильные имена (pod-0, pod-1) и сохраняют их после перезагрузки.
- У каждого пода свой собственный Persistent Volume (PV). При масштабировании данные не перемешиваются.
Headless Service: Необходим для StatefulSet, чтобы каждый под имел свой DNS-адрес. Это позволяет подам внутри кластера находить друг друга напрямую (например, для репликации БД), не используя Round Robin сервиса.
Завершение работы (Graceful Shutdown):
- По умолчанию дается 30 секунд. Если БД нужно больше времени на закрытие транзакций, используется параметр terminationGracePeriodSeconds или preStop hook'и.

Kubernetes поддерживает три вида масштабирования:

HPA (Horizontal Pod Autoscaler): Изменяет количество реплик (подов) в зависимости от нагрузки (CPU/RAM).
VPA (Vertical Pod Autoscaler): Изменяет ресурсы (CPU/Memory) выделенные конкретному поду. Важно:VPA обычно требует перезагрузки пода для применения новых лимитов. Не рекомендуется использовать HPA и VPA вместе по одной метрике (CPU/RAM).
Cluster Autoscaler: Добавляет или удаляет сами физические/виртуальные ноды в облаке.

Metric Server: Для работы HPA в кластере обязательно должен быть установлен metrics-server, который собирает данные о потреблении ресурсов.
Custom Metrics: Если нужно масштабироваться не по CPU, а по количеству запросов (HTTP requests), используются внешние инструменты, такие как Prometheus с адаптером (prometheus-adapter).

По умолчанию в Kubernetes "все могут общаться со всеми". Network Policy позволяют это ограничить.

Ingress: Правила для входящего трафика в под.
Egress: Правила для исходящего трафика из пода.
Логика: Как только вы применяете хотя бы одну политику к поду, он переходит в режим "изоляции" — всё, что не разрешено явно, запрещается.
Использование меток (Labels): Доступ можно разрешать на основе меток подов или целых Namespace.

Это инструменты для проверки манифестов перед их созданием в API Server.

Зачем нужно? Чтобы запретить разработчикам создавать "плохие" объекты.
Примеры политик:
- Запретить запуск подов под пользователем root.
- Обязать указывать requests и limits по ресурсам.
- Запретить использование образов (Images) из непроверенных реестров (Registry).

Если NodePort или LoadBalancer предоставляют доступ на уровне IP/Port, то Ingress работает на уровне L7 (HTTP/HTTPS).

Ingress Controller (например, Nginx Ingress): Это сам софт (прокси), который слушает трафик.
Ingress Object: Это манифест с правилами (какой домен на какой сервис направить).
Path-based routing: Маршрутизация по путям (например, /api идет в один сервис, а /static — в другой).
TLS/SSL: Ingress позволяет централизованно управлять SSL-сертификатами (через Secret типа kubernetes.io/tls).

Contents