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

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

Что входит

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

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

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

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

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

Как это выглядело на практике — в кейсе «Кубер, который нельзя было масштабировать».