Obchodní algoritmy na Kubernetes: migrace za plného provozu a GitOps

Obchodní strategie běží nepřetržitě, data z trhu přicházejí každou minutu a každé nasazení nové verze je malý hazard. Tento článek ukazuje, jak takové prostředí převést na Kubernetes a GitOps tak, aby obchodování ani na den nestálo – a aby provoz přestal záviset na jednom člověku.

Příběh sleduje modelovou firmu a postup, který pro podobná prostředí navrhujeme. Nejde o zákaznickou případovou studii; čísla a časy jsou ilustrativní.

Výchozí stav

Představme si menšího obchodníka s elektřinou. Nakupuje a prodává na krátkodobém trhu a velkou část obchodů zadávají algoritmy: strategie vyhodnocují ceny, předpovědi počasí a výrobu a posílají pokyny na burzu. Firma má dvanáct lidí, z toho tři vývojáře strategií. Servery spravuje jeden z nich vedle své hlavní práce.

Prostředí vznikalo postupně a dává to znát:

• Tři virtuální servery u lokálního poskytovatele. Na každém běží několik procesů spuštěných ručně v tmux, část úloh pouští cron. Po restartu serveru je musí někdo znovu nastartovat – a vědět, v jakém pořadí.
• Nasazení je kopírování souborů a restart. Nová verze strategie se nahraje na server a proces se restartuje. Předchozí verze se nikam neukládá, takže návrat zpět znamená hledat ji v něčím notebooku.
• Přístupové údaje k burze leží v konfiguračních souborech na serverech a ve sdílené složce.

Z toho plynou tři problémy, které firmu skutečně bolí:

1. Provoz stojí na jednom člověku. Když je na dovolené, nové strategie se nenasazují a výpadek se řeší telefonem. Obecně jsme o tom psali v článku Když infrastruktura stojí na jednom člověku.
2. Každé nasazení je riziko. Chyba v nové verzi se projeví až na trhu a cesta zpět není vyzkoušená.
3. Chybí přehled. Když se zasekne zdroj cenových dat, strategie dál obchodují nad starými čísly. Přijde se na to, až si obchodník všimne, že se ceny na obrazovce nehýbou.

Firma nechtěla „přejít do cloudu“ jako cíl sám o sobě. Chtěla nasazovat bezpečně, vidět, co se děje, a nemít celý provoz v hlavě jednoho kolegy.

Co jsme postavili

Cílová platforma běží v Google Cloud. Všechno, co ji tvoří, je popsané v Gitu: infrastruktura v Terraformu, aplikace v manifestech pro Kubernetes, upozornění a postupy pro jejich řešení vedle nich. [1]

Kubernetes zde není samoúčelný. Firma provozuje přes dvacet samostatných procesů – strategie, sběr dat, výpočet předpovědí, odesílání pokynů a reporty – a jejich počet roste. Pro dva nebo tři procesy by stačil virtuální server se službami pod systemd, nastavený přes Ansible. Tam, kde procesů přibývá a mění se každý týden, se jednotný způsob nasazení a restartů vyplatí.

Jak jsme migrovali

Migrace samotná není cíl. Prostředí jsme nejdřív standardizovali – zmapovali, popsali v IaC a dostali hesla a klíče (secrets) pod kontrolu – a teprve pak přesouvali. Obchodování přitom nesmělo stát.

1. Zmapování a standardizace

Sepsali jsme každý proces: co dělá, jaká data čte a zapisuje, s kým komunikuje a co se stane, když spadne. U několika procesů jsme teprve tak zjistili, že na sobě závisejí – reportní skript například četl soubor, který zapisovala jedna ze strategií.

Každý proces dostal container image a konfiguraci oddělenou od kódu. Hesla a klíče se přesunuly do Secret Manageru a přístupové klíče k burze se při té příležitosti vyměnily, protože ty staré ležely na příliš mnoha místech.

2. Souběžný provoz

Nová platforma běžela vedle starých serverů nad stejnými daty. Strategie na ní pracovaly v režimu „paper“: počítaly pokyny, ale neposílaly je na burzu. Rozhodnutí obou prostředí se denně porovnávala.

Shodu jsme neměřili vlastními metrikami, ale reporty, kterým firma věří – stejnými, podle kterých obchodníci každý den hodnotí výsledky strategií. Rozdíly se dohledávaly jeden po druhém. Většinou šlo o drobnosti, jako jiné časové pásmo v kontejneru nebo pořadí zpracování dvou zpráv se stejným časovým razítkem.

3. Plánované přepnutí

Když se výsledky po dohodnutou dobu shodovaly v předem stanovené toleranci, přišlo přepnutí v okně s nejnižším objemem obchodů. Staré servery zůstaly několik týdnů připravené v záloze. Návrat zpět znamenal jedinou změnu: které prostředí drží přístupové údaje pro odesílání pokynů.

Pravidla souběžného provozu

1. Pokyny na burzu smí posílat vždy jen jedno prostředí. Druhé nemá k přístupovým údajům pro obchodování vůbec přístup. Dvojí pokyn by byl dražší než jakýkoli výpadek.
2. Shoda se měří čísly firmy, ne našimi. Rozhoduje report, kterému věří obchodníci.
3. Kritéria přepnutí jsou dohodnutá předem. Tolerance, délka souběhu a kdo přepnutí schvaluje.
4. Cesta zpět je vyzkoušená, ne jen popsaná. Návrat na staré servery jsme jednou nacvičili na testovacím účtu burzy.

Doručení změny: od commitu do produkce

Po přepnutí přišel na řadu GitOps. Jeho principy shrnuje projekt OpenGitOps: požadovaný stav je popsaný deklarativně, verzovaný v Gitu, nástroj si ho sám stahuje a průběžně srovnává se skutečností. [6]

flowchart LR
    A["Merge request<br/>se změnou strategie"] --> B["CI: testy, sestavení<br/>a sken obrazu"]
    B --> C["Kontrola a schválení"]
    C --> D["Nová verze obrazu<br/>v GitOps repozitáři"]
    D --> E["Argo CD: testovací<br/>prostředí automaticky"]
    E --> F["Povýšení do produkce<br/>dalším merge requestem"]

V praxi to znamená šest kroků:

1. Vývojář změní kód strategie nebo její konfiguraci a otevře merge request.
2. CI spustí testy, včetně přehrání vzorku historických dat, sestaví obraz a zkontroluje známé zranitelnosti.
3. Změnu zkontroluje druhý člověk.
4. Po sloučení CI zapíše novou verzi obrazu do GitOps repozitáře.
5. Argo CD ji automaticky nasadí do testovacího prostředí.
6. Do produkce jde stejná verze dalším, krátkým merge requestem; Argo CD ověří, že nové procesy naběhly v pořádku.

Návrat k předchozí verzi je git revert. Argo CD ve výchozím nastavení nemaže objekty odstraněné z Gitu ani nevrací ruční změny v clusteru; obě chování jsme zapnuli vědomě, aby cluster vždy odpovídal repozitáři. [4]

Nová strategie jedním souborem

Vývojáři chtěli hlavně jedno: přidat novou strategii bez čekání na správce serverů. Každá strategie je proto popsaná jedním souborem s hodnotami pro společnou šablonu Helm: [7]

# apps/strategie/intraday-spread-cz-de/values.yaml
strategy:
  name: intraday-spread-cz-de
  image: strategy-runner:1.14.2
  mode: paper          # paper | live
  markets: [CZ, DE]
  limits:
    maxPositionMW: 5
    maxOrderMW: 1

exchangeCredentials: desk-2   # odkaz na tajný údaj v Secret Manageru, ne jeho hodnota

resources:
  requests: { cpu: 250m, memory: 512Mi }
  limits: { memory: 1Gi }

Nová strategie vždy začíná v režimu paper. Přepnutí na live a změna limitů pozic vyžadují schválení vedoucího obchodu; v GitLabu to hlídá soubor CODEOWNERS. Obchodní pravidlo tak není jen v dokumentu, ale přímo v postupu, kterým změna vzniká.

Šablona za vývojáře doplní všechno ostatní: požadavky na zdroje, kontroly stavu, síťová pravidla, identitu pro přístup k tajným údajům i výchozí upozornění. Požadavky na CPU a paměť nejsou formalita – podle nich Kubernetes rozmisťuje procesy a bez nich nejde rozumně plánovat kapacitu. [8]

Provoz

Převzetí provozu začalo až nad standardizovaným prostředím. Všechno, co k provozu patří, je v repozitáři, a tím pádem i v rukou firmy.

Upozornění, která něco znamenají

Kromě technických signálů – restartující se proces, plný disk, pomalá databáze – sledujeme i obchodní:

• zdroj cenových dat neposlal novou hodnotu déle, než je pro daný trh obvyklé,
• strategie v režimu live během obchodní doby nezadala žádný pokyn,
• odmítnutých pokynů je víc než obvykle,
• otevřená pozice se blíží limitu.

Každé pravidlo má v Gitu odkaz na krátký postup: co upozornění znamená, co zkontrolovat a kdy volat obchodníka. Alertmanager je směruje podle závažnosti: technická upozornění k nám, obchodní souběžně i do kanálu obchodu. [5]

Aktualizace Kubernetes bez nervů

Každá minor verze Kubernetes dostává opravy zhruba rok. [9] GKE nabízí čtrnáctiměsíční standardní podporu a clustery v release channelu aktualizuje automaticky; kdy se to smí stát, určují okna údržby a výjimky. [10] Okna jsme nastavili mimo hlavní obchodní hodiny a testovací cluster dostává novou verzi dřív než produkční.

Aby aktualizace uzlů nevypnula všechny instance jedné služby najednou, mají kritické procesy nastavené PodDisruptionBudget. [11] Zdroje dat běží ve dvou instancích, odesílání pokynů v jedné s rychlým převzetím – dvě instance posílající stejné pokyny si firma dovolit nemůže.

Bezpečnost

• Žádné statické klíče ke cloudu. Aplikace se ke Google Cloud přihlašují přes Workload Identity Federation, každá pod vlastní identitou s nejmenšími potřebnými právy. [3]
• Hesla a klíče mimo Git i servery. External Secrets Operator je načítá ze Secret Manageru do clusteru; v Gitu je jen odkaz. [2]
• Omezené kontejnery a síť. Jmenné prostory vynucují profil restricted z Pod Security Standards. [12] Síťová pravidla povolují spojení na burzu jen službě, která odesílá pokyny; strategie s burzou přímo nemluví. [13]
• Dohledatelné změny. Kdo, co a kdy změnil, je vidět v historii Gitu a merge requestů. Pokud firma spadá pod nový zákon o kybernetické bezpečnosti, je to i užitečný podklad – viz NIS2 pro menší firmy.

Náklady

Kubernetes sám o sobě nešetří. Úspora vzniká jinde:

• Konsolidace. Původní servery byly dimenzované na nejhorší den a většinu času běžely naprázdno. Procesy s nastavenými požadavky na zdroje se vejdou na menší počet uzlů.
• Testovací prostředí jen když je potřeba. Testovací cluster se mimo pracovní dobu zmenšuje.
• Závazky na stálý základ. Část výkonu, která běží nepřetržitě, lze pokrýt slevou za závazné využití. [14]

Je ale potřeba počítat i s náklady navíc. GKE účtuje poplatek za správu clusteru 0,10 USD za hodinu. Bezplatný kredit 74,40 USD měsíčně na fakturační účet pokryje jeden zónový nebo Autopilot cluster, regionální už ne. [15] K tomu se přidává úložiště metrik a logů. A hlavně čas lidí: platforma, kterou nikdo nespravuje, zastará rychleji než tři servery v tmux.

Pro naši modelovou firmu vycházejí měsíční náklady na infrastrukturu nižší než dřív, hlavně díky konsolidaci. Větší přínos ale vidí jinde: nová strategie se dostane do testu během dne a nasazení přestalo být událostí.

Výsledek: před a po

Typický průběh takového projektu:

Co dál

• Pravidelný test obnovy. Databáze má zálohy i obnovu k danému okamžiku; jistotu ale dá až vyzkoušená obnova s naměřeným časem. Proč na tom záleží, popisujeme v článku Jak poznat, že vaše zálohy opravdu fungují.
• Náklady po strategiích. Štítky na procesech umožní rozpočítat náklady na infrastrukturu na jednotlivé strategie a porovnat je s jejich výsledky.
• Postupné nasazování strategií. Nová verze nejdřív dostane jen část objemu obchodů a teprve po kontrole výsledků celý.

Kubernetes a GitOps nejsou cílem. Cílem je, aby nasazení nové strategie bylo nudné, výpadek datového zdroje viditelný dřív než na obchodním výsledku a aby provoz zvládl i někdo jiný než jediný kolega. Platforma je jen způsob, jak toho dosáhnout opakovatelně.

Zdroje

1. HashiCorp — What is Terraform? Infrastruktura popsaná v konfiguračních souborech, plán a aplikace změn.
2. External Secrets Operator. Načítání hesel a klíčů z Google Secret Manageru, HashiCorp Vault a dalších do Kubernetes.
3. Google Cloud — Workload Identity Federation for GKE. Přístup aplikací v GKE ke Google Cloud API bez servisních klíčů.
4. Argo CD — Automated Sync Policy. Automatická synchronizace z Gitu; mazání (prune) a samoopravu (self-heal) je třeba zapnout.
5. Prometheus — Alertmanager. Seskupování, směrování a umlčování upozornění.
6. OpenGitOps — Principles. Čtyři principy GitOps: deklarativní, verzovaný, automaticky stahovaný a průběžně srovnávaný stav.
7. Argo CD — Helm. Nasazení šablon Helm s vlastními soubory hodnot.
8. Kubernetes — Resource Management for Pods and Containers. Požadavky a limity CPU a paměti.
9. Kubernetes — Releases. Podpora posledních tří minor verzí, přibližně rok oprav pro každou.
10. Google Cloud — GKE release channels. Automatické aktualizace, čtrnáctiměsíční standardní podpora, okna údržby a výjimky.
11. Kubernetes — Disruptions. PodDisruptionBudget při plánované údržbě uzlů.
12. Kubernetes — Pod Security Standards. Profily privileged, baseline a restricted.
13. Kubernetes — Network Policies. Omezení síťové komunikace mezi pody a ven z clusteru.
14. Google Cloud — Committed use discounts. Slevy za závazek využití výpočetního výkonu.
15. Google Cloud — GKE pricing. Poplatek za správu clusteru a bezplatný kredit pro zónové a Autopilot clustery.

Firma, její procesy, časový průběh a srovnání nákladů jsou ilustrativní. Nejde o výsledky konkrétního zákazníka. Funkce produktů a ceny jsou popsány podle dokumentace ověřené 27. října 2026.