Kubectl apply v produkci? To snad ne. V roce 2026 je GitOps de facto standard pro deployment do Kubernetes. A progressive delivery strategie zajišťují, že i chybný release nezabije produkci. Jak to celé funguje v praxi?
Co je GitOps a proč vyhrál¶
GitOps je operační model, kde Git je single source of truth pro infrastrukturu i aplikační konfiguraci. Deklarativní stav v Gitu je automaticky synchronizován s cílovým prostředím. Žádné imperative příkazy, žádné ruční zásahy.
Principy GitOps jsou jednoduché: deklarativní popis celého systému, verzovaný a immutable stav v Gitu, automatická aplikace schváleného stavu, a software agenti zajišťující konvergenci a alerting při driftu.
V roce 2026 GitOps adoptovalo přes 70 % organizací provozujících Kubernetes. Důvod je jasný — audit trail, rollback jedním git revert, a eliminace „kdo co kde změnil”.
Argo CD vs Flux — volba nástroje¶
Dva dominantní GitOps kontroléry pro Kubernetes:
- Argo CD: Bohaté UI, application-centric model, silná vizualizace dependency grafu. Lepší pro týmy, které potřebují přehled a self-service portál. CNCF graduated projekt.
- Flux v2: Controller-based architektura, modulární (source, kustomize, helm, notification controllers). Lepší pro platformní týmy budující interní developer platformu. Nativní podpora OCI artefaktů.
V praxi: Argo CD pro application teams (vizuální přehled, sync status, rollback v UI), Flux pro platform teams (composable, API-first, integrace s Terraform). Oboje funguje skvěle.
Repository strategie¶
Jak organizovat Git repozitáře pro GitOps? Tři osvědčené patterny:
- Monorepo: Vše v jednom repozitáři — app code + manifesty. Jednodušší pro malé týmy. Ale: CI/CD pipeline se komplikuje s růstem.
- Separate config repo: Aplikační kód v jednom repo, Kubernetes manifesty v druhém. CI pipeline buildí image → aktualizuje config repo → GitOps agent synchronizuje. Nejčastější pattern v enterprise.
- Repo per environment: Separátní repozitáře pro dev, staging, production. Maximální izolace, ale vyšší správní overhead. Vhodné pro regulované prostředí.
Naše doporučení: separate config repo s branch-per-environment nebo directory-per-environment strukturou. Kustomize overlays pro environment-specifické konfigurace.
Progressive delivery — beyond blue-green¶
GitOps zajistí, že deployment je reprodukovatelný a auditovatelný. Progressive delivery zajistí, že je bezpečný. Strategie od nejjednodušší po nejsofistikovanější:
- Blue-green deployment: Dvě identické prostředí. Traffic se přepne najednou. Rychlý rollback, ale vyžaduje dvojnásobek resources.
- Canary deployment: Nová verze dostává postupně rostoucí procento traffic (1% → 5% → 25% → 100%). Metriky rozhodují o pokračování nebo rollbacku.
- A/B testing: Různé verze pro různé segmenty uživatelů. Vyžaduje traffic splitting na úrovni service mesh.
- Feature flags: Kód je nasazen, ale funkce je skrytá za flag. Gradual rollout bez nového deploymentu. Nejflexibilnější, ale vyžaduje disciplínu ve správě flags.
Canary v praxi s Argo Rollouts¶
Argo Rollouts je Kubernetes controller, který nahrazuje standardní Deployment resource a přidává progressive delivery strategie. Typický canary flow:
- Krok 1: Nová verze se nasadí s 5 % traffic. Automatická analýza metrik (success rate, latence, error rate) po dobu 5 minut.
- Krok 2: Pokud metriky vyhovují, traffic se zvýší na 25 %. Další analýza.
- Krok 3: 50 % traffic. V tomto bodě je vhodný human approval gate pro kritické služby.
- Krok 4: 100 % traffic. Canary se stává novou stable verzí.
Klíčové: automatická analýza metrik rozhoduje o promotion nebo rollbacku. Argo Rollouts se integruje s Prometheus, Datadog, New Relic a dalšími. Pokud error rate překročí threshold, rollback proběhne automaticky — bez zásahu člověka.
Service mesh a traffic management¶
Pro sofistikovaný traffic splitting potřebujete service mesh nebo ingress controller s odpovídajícími schopnostmi:
- Istio: Nejkompletnější řešení. VirtualService pro traffic splitting, DestinationRule pro load balancing. Ale: vysoká komplexita a resource overhead.
- Linkerd: Lightweight alternativa. Rust-based proxy, nízká latence. Traffic splitting přes SMI (Service Mesh Interface) nebo HTTPRoute.
- Gateway API + NGINX/Envoy: Bez full service mesh. Kubernetes Gateway API standard s traffic splitting podporou. Nejjednodušší cesta pro canary.
Feature flags — deployment ≠ release¶
Oddělení deploymentu od releasu je game changer. S feature flags můžete:
- Trunk-based development: Vše jde do main, nehotové features jsou za flagem. Žádné dlouhé feature branches.
- Gradual rollout: Feature zapnete pro 1 % uživatelů, měříte dopad, postupně rozšiřujete.
- Kill switch: Problémová feature se vypne okamžitě, bez nového deploymentu.
- Targeting: Feature pro konkrétní zákaznický segment, region nebo environment.
Nástroje: LaunchDarkly (enterprise), Unleash (open-source, self-hosted), OpenFeature (vendor-neutral SDK standard). Pro české firmy často doporučujeme Unleash — self-hosted, GDPR friendly, dostatečně robustní.
Observability-driven deployment¶
Progressive delivery bez observability je jako řídit auto se zavřenýma očima. Minimální setup:
- Zlaté signály: Latence, traffic, error rate, saturace — pro každou službu.
- SLO-based promotion: Canary pokračuje, pouze pokud SLO drží. Burn rate alerting odhalí degradaci dříve než threshold-based alerty.
- Deployment markers: Anotace v Grafana/Datadog ukazují, kdy proběhl deployment. Korelace s metrikami je okamžitě viditelná.
- Automated rollback: Pokud SLO burn rate překročí limit, Argo Rollouts automaticky vrátí na předchozí verzi.
Deploy often, deploy safely¶
GitOps + progressive delivery = nasazujte častěji s nižším rizikem. Automatická synchronizace z Gitu eliminuje konfigurační drift. Canary a feature flags zajistí, že chybný release zasáhne minimum uživatelů.
Náš tip: Začněte GitOps pro non-production prostředí. Když si tým zvykne na workflow, rozšiřte na production s canary deploymentem. Feature flags přidejte tam, kde potřebujete oddělení release od deploy cyklu.