Kubernetes-лаборатория как код

Зачем

На работе у меня был Docker и docker-compose, а рынок хочет Kubernetes. Я решила не читать про него, а построить кластер так, как это делают в продакшене: всё описано кодом, всё восстанавливается.

Как устроено

• Инфраструктура как код: Terraform и libvirt создают 3 виртуальные машины на KVM.
• Кластер как код: идемпотентный Ansible-плейбук ставит Kubernetes через kubeadm.
• Платформа как код: всё в кластере приходит из Git через ArgoCD — сейчас это 17 приложений.
• Секреты в Git — только зашифрованные, через SealedSecrets.
• Сеть и хранилище: ingress-nginx и MetalLB, тома на Longhorn.
• Наблюдаемость: Prometheus, Grafana, Loki, алерты описаны как код.
• Бэкапы: Velero с копией за пределами кластера — подробнее в кейсе про бэкапы.
• Свои сервисы выкатываются полным циклом: GitHub Actions (тесты, Semgrep, govulncheck, Trivy) → образ в GHCR → CI коммитит тег в GitOps-репозиторий → ArgoCD.

Учения по DR

Я проверила главное: можно ли всё потерять и вернуть. Сценарий: terraform destroy → новые ВМ → кластер с нуля → восстановление из бэкапа. Учения нашли проблемы, о которых я бы не узнала иначе:

• новый контроллер SealedSecrets сгенерировал новый ключ — старые секреты не расшифровывались, пришлось восстанавливать ключ;
• доступ ArgoCD к приватному репозиторию жил только в старом кластере;
• ArgoCD успевал создать PVC раньше, чем Velero их восстанавливал, и данные Postgres не возвращались. Вывод: для баз нужен свой бэкап — pg_dump.

Всё это — в runbook’е и таблице «известные проблемы» в README репозитория.

Чему я научилась

DR, который не проверяли, не существует. И чем больше всего описано кодом, тем меньше в восстановлении ручных шагов, где можно ошибиться в 3 часа ночи.