GKE, które mały zespół naprawdę utrzyma
Produkcyjny Kubernetes w Google Cloud: klastry, GitOps, sekrety i monitoring, zbudowane tak, żeby programiści wdrażali, a nie pilnowali nodów.
Brzmi znajomo?
- Klaster postawił ktoś, kto już tu nie pracuje, i nikt nie chce go ruszać.
- Wdrożenie to
kubectlz czyjegoś laptopa, a rollback to nadzieja. - Sekrety siedzą w zmiennych środowiskowych, w ustawieniach CI i we wspólnym menedżerze haseł.
- Płacisz za nody, które głównie stoją, albo pody są wyrzucane w najgorszym momencie.
Co dostajesz
Klastry w kodzie
Sieć, node poole, autoskalowanie i Workload Identity, przeglądane jak każda inna zmiana.
GitOps z Argo CD
Każda zmiana to pull request, każdy rollback to revert.
Sekrety bez kluczy
Secret Manager przez External Secrets, bez żadnych kluczy kont serwisowych.
Jeden chart Helm dla wszystkich aplikacji
Autoskalowanie, PodDisruptionBudget i rozłożenie na strefy od razu, żeby każda usługa nie wymyślała tego od nowa.
Monitoring, który ma sens
Dashboardy i alerty, które mówią o problemie, zanim zauważą go użytkownicy.
Runbook
Dokumentacja, z którą Twój zespół poradzi sobie o 3 w nocy, a nie tylko osoba, która to budowała.
Jak to wygląda
Przegląd
Pokazujesz, co działa i gdzie boli. Patrzę na rzeczywistą konfigurację, a nie na slajdy.
Plan
Krótki pisemny plan: co się zmienia, w jakiej kolejności i ile to zajmie.
Wdrożenie
Małe kroki, które da się przejrzeć i cofnąć, najpierw dev, potem prod.
Przekazanie
Dokumentacja i runbook, żeby Twój zespół sam to utrzymał, a jeśli chcesz, zostaję na dyżurze.
Gdzie już to robiłem
- Od zera postawiłem dev i prod na GKE dla startupu B2B SaaS, a potem podłączyłem klaster poza Google Cloud pod saudyjskie wymogi rezydencji danych.
Jak działa część bez kluczy (artykuł po angielsku) → - W InPost utrzymywałem wysokodostępne produkcyjne klastry GKE z autoskalowaniem, z Istio (mTLS) i GitOps.