Kamal vs Flux CD: Jednoduchost nebo odolnost — vyberte si

Váš kontejner spadl ve 3 ráno. S Flux CD si toho cluster všiml, restartoval pod a sesynchronizoval požadovaný stav z Gitu. Dozvěděli jste se o tom z notifikace na Slacku u ranní kávy. S Kamalem — nikdo si ničeho nevšiml. Vaše aplikace byla čtyři hodiny nedostupná. První, kdo si toho všiml, byl zákazník, a neposlal bug report. Prostě odešel.

Toto je zásadní rozdíl mezi Kamalem a Flux CD a je důležitější, než většina srovnávacích článků připouští. Nejde o to, který nástroj je “lepší.” Jde o to, zda je váš nasazovací nástroj zodpovědný za to, že vaše aplikace běží, nebo jen za to, že ji tam umístí.

Co dělá Kamal

Kamal (vytvořený Basecampem, dříve MRSK) nasazuje Docker kontejnery na servery přes SSH. Žádný Kubernetes. Žádný cluster. Žádná orchestrační vrstva. Spustíte kamal deploy a on:

1. Sestaví váš Docker image
2. Pushne ho do registru
3. Připojí se přes SSH na vaše servery
4. Stáhne nový image a spustí kontejner
5. Přepne provoz přes Kamal Proxy (rolling deploy bez výpadku)

To je vše. Mentální model je krásně jednoduchý: máte server, máte kontejner, Kamal dá kontejner na server.

# config/deploy.yml
service: my-saas
image: my-saas/app

servers:
  web:
    - 192.168.1.10
    - 192.168.1.11

registry:
  username: deployer
  password:
    - KAMAL_REGISTRY_PASSWORD

proxy:
  ssl: true
  host: app.example.com

kamal deploy    # Nasadit nejnovější verzi
kamal rollback  # Vrátit se na předchozí verzi
kamal app logs  # Zkontrolovat logy

Vývojářský zážitek je vynikající. Pokud jste někdy nasazovali pomocí Capistrana nebo čistých SSH skriptů, Kamal působí jako přirozená evoluce. Je imperativní — řeknete mu, co má udělat, a on to udělá hned.

Co Kamal nedělá

Problém je v tom, že Kamal je nasazovací nástroj, ne runtime supervisor. Jakmile kamal deploy skončí, Kamalova práce je hotová. Nemá žádný trvalý vztah s vašimi běžícími kontejnery.

• Kontejner spadne? Kamal o tom neví. Nikdo ho automaticky nerestartuje (pokud nemáte nastavené Docker restart policies, které zvládnou jednoduché pády, ale ne poškozený image, OOM kill se špatným stavem nebo konfigurační drift).
• Server spadne? Kamal o tom neví. Žádný failover, žádné přeplánování na jiný host.
• Konfigurace se změní? Pokud se někdo připojí přes SSH a něco změní, Kamal to nedetekuje ani neopraví.
• Health checky? Kamal Proxy kontroluje, zda je kontejner zdravý během nasazení, ale po něm žádný průběžný monitoring neprobíhá.

Kamal vaši aplikaci nasadí. Co se stane potom, je váš problém.

Co dělá Flux CD jinak

Flux CD má zásadně odlišný přístup. Místo imperativního pushování nasazení deklarujete požadovaný stav v Git repozitáři a Flux průběžně synchronizuje cluster, aby odpovídal.

# clusters/production/my-saas.yaml
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: my-saas
  namespace: production
spec:
  interval: 5m
  chart:
    spec:
      chart: ./charts/my-saas
      sourceRef:
        kind: GitRepository
        name: my-saas
  values:
    image:
      tag: v1.4.3
    replicas: 3

Pushnete commit, který změní tag image. To je váš deploy. Flux si změny všimne, aplikuje ji na cluster a Kubernetes se postará o rollout. Ale klíčový rozdíl — Flux nepřestane pracovat po nasazení:

• Kontejner spadne? Kubernetes ho okamžitě restartuje. Pokud nová verze padá opakovaně, rollout se automaticky zastaví.
• Někdo ručně změní něco v clusteru? Flux detekuje drift a vrátí stav tak, aby odpovídal Gitu — jedinému zdroji pravdy.
• Server (node) spadne? Kubernetes přeplánuje pody na zdravé nody.
• Chcete rollback? git revert commitu. Flux sesynchronizuje. Cluster odpovídá předchozímu stavu.

Systém se sám opravuje. Vy nejste synchronizační smyčka.

Skutečná cena “jednoduchosti”

Argument pro Kamal zní: “Nepotřebujete Kubernetes. Je příliš složitý. Prostě nasaďte na VPS.”

A pro určitou třídu aplikací je to naprosto správné. Ale tento argument má slepou skvrnu: složitost nezmizí, jen se přesune na vás.

S Kamalem musíte:

• Nastavit vlastní monitoring pro detekci pádu kontejnerů
• Vybudovat vlastní alerting, který vás vzbudí ve 3 ráno
• Ručně se připojit přes SSH a spustit kamal deploy nebo kamal app boot pro restart
• Sami spravovat zdraví serveru, aktualizace a bezpečnostní záplaty
• Ručně řešit failover, pokud server zemře

S Flux + managed Kubernetes (GKE, EKS, AKS):

• Cloud provider spravuje control plane
• Kubernetes řeší restarty, health checky a přeplánování
• Flux řeší detekci driftu a synchronizaci
• Vy spravujete požadovaný stav aplikace v Gitu — to je vše

Otázka není “je Kubernetes složitý?” — ano, je. Otázka je: je být lidským self-healing mechanismem ve 3 ráno jednodušší?

Může si nový SaaS dovolit výpadek?

Panuje běžné přesvědčení, že SaaS v rané fázi může tolerovat výpadky, protože je malý. Logika zní: “Máme jen 50 zákazníků, neřídíme přece banku.”

Tato logika je přesně pozpátku.

Vyspělý SaaS s 10 000 zákazníky dvouhodinový výpadek přežije. Má důvěru značky, náklady na přechod, roční smlouvy a status page, kterou zákazníci trpělivě sledují. Vy nic z toho nemáte.

Managed GKE Autopilot cluster stojí ~70 $/měsíc. Jeden odchozí zákazník na tarifu za 29 $/měsíc to zaplatí za tři měsíce. Kolik jich jste ztratili během toho výpadku ve 4 ráno, o kterém jste nevěděli?

A tady je ta část, o které nikdo nemluví: nikdy se to nedozvíte. Zkušební uživatel, který narazí na 502, nepošle support ticket. Zavře záložku a zaregistruje se u konkurence. Neexistuje žádná metrika pro “zákazníky, kteří by konvertovali, kdyby aplikace běžela.”

“Ale já se nechci učit Kubernetes!”

To je férové. Kubernetes má reálnou křivku učení. Ale zvažte, co “učit se Kubernetes” znamená v roce 2026:

1. Neprovozujete vlastní cluster. Použijte GKE Autopilot, EKS s Fargate nebo AKS. Cloud provider spravuje nody, upgrady a control plane.
2. Píšete YAML manifesty — Deploymenty, Services, Ingress. Možná 5-6 souborů pro typickou SaaS aplikaci.
3. Nainstalujete Flux — flux bootstrap trvá 5 minut.
4. Pushnete do Gitu — to je váš nasazovací workflow od teď.

Ano, je to počáteční investice. Ale porovnejte ji s průběžnou investicí do toho být vlastním orchestrátorem: monitoring, alerting, ruční restarty, údržba serverů, plánování failoveru — to vše Kubernetes řeší za vás.

Křivka učení je jednorázový náklad. Provozní zátěž běhu bez orchestrace je průběžná.

Kde Kamal vyniká

Nic z toho neznamená, že Kamal je špatný nástroj. Je vynikající — pro správné případy použití:

• Home lab a self-hosting — Provozujete Nextcloud, Giteu, Immich nebo Plex na vlastním hardwaru? Kamal je perfektní. Pokud vám přes noc spadne mediální server, nikdo neodejde. Opravíte to v sobotu.
• Interní nástroje — Dashboardy, admin panely, CI runnery — věci používané vaším týmem během pracovní doby. Výpadek je nepohodlný, ne nákladný.
• Prototypy a MVP — Když validujete nápad a ještě nemáte platící zákazníky. Pohybujte se rychle, nasaďte na levný VPS, odolností se zabývejte, až budete mít něco, co stojí za to udržovat v provozu.
• Vedlejší projekty — Váš osobní blog, hobby aplikace, víkendový projekt. Kamal dělá nasazování zase zábavným.

Společný jmenovatel: dopad výpadku dopadá na vás, ne na vaše zákazníky.

Rozhodovací rámec

Závěr

Kamal i Flux CD jsou vynikající nástroje, které slouží různým účelům. Otázka není, který je technicky lepší — ale kdo si všimne, když se něco rozbije.

Pokud je odpověď “já, kdykoli se náhodou podívám” — Kamal je v pořádku. Váš home lab, vaše interní nástroje, vaše vedlejší projekty si ho zamilují.

Pokud odpověď musí být “systém, okamžitě, ve 3 ráno, aniž by někoho vzbudil” — potřebujete Kubernetes a GitOps. Vaši SaaS zákazníci platí za dostupnost. Dejte jim ji.

Nebuďte self-healing mechanismus. To je práce clusteru.

Titulní foto: Christian Stahl na Unsplash.