# Kubernetes и контейнеры

Ведём кластеры Kubernetes — как поднятые нами, так и доставшиеся по наследству вместе с прежней командой.

![Обслуживание узла Kubernetes при работающих приложениях на соседних узлах](/images/illustrations/part2/06-kubernetes.webp)

## Что входит

- **Обновления версий.** Кластер и его дополнения обновляются по плану, узел за узлом, с проверкой того, что рабочие нагрузки переезжают без простоя.
- **Хранилища.** PersistentVolume и StorageClass, режимы доступа под задачу — ReadWriteOnce для эксклюзивных томов, ReadWriteMany там, где к каталогу ходят несколько реплик. Резервные копии данных приложений, а не только манифестов.
- **Входящий трафик.** Ingress, балансировка, сертификаты и их автоматическое продление.
- **GitOps.** Состояние кластера описано в репозитории: что в ветке — то и в кластере. Правки через merge request, откат — revert коммита.
- **Ресурсы.** requests и limits, HPA и автомасштабирование узлов, вылавливание подов, которые тихо съедают память.
- **Инциденты.** Под не стартует, узел ушёл в NotReady, кончились адреса в pod CIDR, отвалился CoreDNS — это к нам.

## Частая ситуация

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

## Что получает заказчик

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

Как это выглядело на практике — в кейсе [«Кубер, который нельзя было масштабировать»](/cases/kubernetes-migration).