18. augusta 2026 Ako sme automatizovali OpenShift klaster cez tri dátové centrá

Nasadenie Kubernetes klastra v cloude je dnes rutina. Nasadenie produkčného Red Hat OpenShift klastra na desiatky fyzických serverov v troch geograficky oddelených dátových centrách – s load balancermi, VLAN-mi, bondingom a firewallmi – je podstatne zložitejšia úloha.

Pre nášho zákazníka, veľkú organizáciu s vysokými nárokmi na dostupnosť a bezpečnosť, sme celé nasadenie implementovali ako jednu GitLab CI pipeline. Pipeline pokrýva celý proces od prázdnych serverov s pripojeným management rozhraním až po plne funkčný OpenShift klaster a je opakovateľne spustiteľná bez manuálneho zásahu.

V článku popisujeme architektúru klastra, jednotlivé fázy pipeline a problémy, na ktoré sme počas implementácie narazili, spolu s ich riešeniami.

Prečo bare-metal a prečo agent-based installer

Zákazník sa rozhodol pre OpenShift priamo na fyzických serveroch – bez virtualizačnej medzivrstvy. Dôvody boli pragmatické. OpenShift subscription sa na bare-metal počíta na fyzické sockety, takže sa dal vypočítať optimálny pomer ceny za licencie a hardware. K tomu sa pridal plný výkon pre software-defined storage Red Hat OpenShift Data Foundation (ODF) postavený na Ceph a NVMe diskoch, podpora Red Hat OpenShift Virtualization pre budúce VM workloady a o jedna prevádzková vrstva menej.

Pre inštaláciu sme zvolili agent-based installer – režim, v ktorom sa z konfigurácie vygeneruje inštalačné ISO; po naštartovaní serverov automaticky prebehne discovery, servery sformujú klaster a nainštalujú OpenShift. Nie je potrebný provisioning node ani externá inštalačná infraštruktúra. Zostávalo vyriešiť, ako dostať toto ISO na 40+ serverov automaticky a čo najrýchlejšie.

Jeden klaster cez tri dátové centrá

• Než sa dostaneme k automatizácii, najprv krátko k cieľovému stavu, pretože ani ten nie je bežný. Nejde o tri klastre s replikáciou, ale o jeden OpenShift klaster synchrónne roztiahnutý cez tri fyzicky oddelené dátové centrá (DC), prepojené dark fiber trasami s kapacitou 2×400 Gb/s a latenciou do 5 ms medzi dátovými centrami, ktorá umožňuje synchrónnu replikáciu:
• Control plane s jedným master nodom v každom dátovom centre – etcd kvórum prežije výpadok celého DC.
• Úložisko ODF/Ceph s trojnásobnou synchrónnou replikáciou, jedna replika v každom DC. Každý zápis je potvrdený vo všetkých troch lokalitách, čo znamená Recovery Point Objective (RPO) = 0 – pri výpadku celého dátového centra nedôjde k strate dát.
• Klaster je dimenzovaný tak, aby 100 % produkčnej záťaže bežalo na 66 % kapacity – teda bola zabezpečená plná prevádzka aj po strate celého DC.

Ako Container Network Interface (CNI) beží Cilium v natívnom routing režime (bez overlay siete, s eBPF namiesto kube-proxy), vkladané do klastra už ako day-1 manifest priamo v inštalačnom ISO.

Štandardom sú dve lokality plus arbiter node na kvórum. Plnohodnotný aktívny stretch klaster cez tri dátové centrá so synchrónnym Cephom patrí medzi menej bežné nasadenia – a práve preto musela byť inštalácia plne reprodukovateľná, pretože pri tomto počte serverov a sieťovej zložitosti nie je manuálny postup opakovateľný.

Šesť krokov od Gitu po klaster

Celý životný cyklus riadi GitLab CI pipeline nad Terraform kódom, rozdelená do na seba nadväzujúcich fáz:

Kľúčové fázy v detaile:

• apply-base – Terraform nakonfiguruje F5 BIG-IP load balancery (VLAN-y, self-IP adresy, virtuálne servery pre API, ingress a DNS, health monitory, SNAT pooly) vrátane zostavenia F5 HA klastra.
• create-agent-image – z Git konfigurácie sa vygenerujú install-config.yaml a agent-config.yaml (vrátane MAC adries, bondingu a VLAN-ov pre každý server), pribalia sa day-1 manifesty (Cilium) a openshift-install vytvorí bootovacie ISO.

apply-boot – Terraform cez management rozhrania serverov (Dell iDRAC, protokol Redfish) namountuje inštalačné ISO alebo nastaví HTTP boot, prepne one-time boot a reštartuje servery. Od tohto momentu beží inštalácia sama.
Každé prostredie (produkcia, lab, dev) má vlastné tfvars a spúšťa sa vlastným Git tagom, takže sa použije rovnaký kód len s inými parametrami.

Day-2: klaster ďalej spravuje ArgoCD

• Úloha Terraformu končí funkčným klastrom. Všetko, čo beží nad ním, už spravuje ArgoCD. Nasadí sa na klaster (spravuje aj samo seba) a z Git repozitára deklaratívne nasadí infraštruktúrne aplikácie vrátane kritických komponentov:
• Úložisko – local storage operator a ODF/Ceph klaster s trojnásobnou replikáciou cez tri DC. Aj samotné produkčné úložisko vzniká ako GitOps aplikácia.
• Sieť – day-2 konfigurácia Ciliumu a BGP peering, NMState policies pre sieťové rozhrania, F5 Container Ingress Services (CIS) na automatickú publikáciu služieb na F5 load balancery a cert-manager pre certifikáty.
• Bezpečnosť – Keycloak ako OpenID Connect (OIDC) provider a Kyverno policies. Secrets sa do manifestov injektujú z Vaultu cez ArgoCD Vault Plugin, takže v Gite nie je ani jedno heslo.
• Observabilita – Prometheus, Grafana, Loki, Tempo, Alloy.

Backup a virtualizácia – OpenShift API for Data Protection (OADP) pre zálohovanie a OpenShift Virtualization pre VM workloady.

Rovnako ako pri infraštruktúre je želaný stav klastra definovaný v Gite a ArgoCD ho priebežne vynucuje (self-heal, prune) – manuálny zásah priamo v klastri sa automaticky vráti do deklarovaného stavu.

Vybrané problémy z implementácie

Niekoľko problémov, na ktoré sme počas implementácie narazili a ktoré dokumentácia nepokrýva:

1. GitLab Package Registry ako boot server

HTTP boot cez iPXE sme uprednostnili pred bootom z iDRAC virtuálneho média (namountovaného cez HTTPS z GitLabu) kvôli rýchlosti. Bootovacie artefakty sa sťahujú cez 100 Gb/s ethernet porty servera, takže inštalácia sa inicializuje mnohonásobne rýchlejšie ako cez iDRAC, ktorého rozhranie má len 1 Gb/s. Pre HTTP boot cez iPXE je potrebný web server, z ktorého si servery stiahnu kernel, initrd a root filesystem. Namiesto inštalovania ďalšieho komponentu sme použili GitLab Package Registry, ktorá už bola súčasťou infraštruktúry. Pipeline po vygenerovaní ISO rozbalí jeho obsah a pushne bootovacie artefakty do GitLabu, ten potom funguje ako PXE/HTTP boot server.

Artefakty v registry sú však chránené autentifikáciou a sťahujú ich postupne dvaja klienti, každý s inými možnosťami. UEFI HTTP boot firmware servera nevie poslať prihlasovacie údaje v HTTP hlavičke – token mu treba odovzdať ako query parameter v URL. iPXE naopak podporuje klasickú basic auth v tvare user:pass@host. V konfigurácii je preto len jedna spoločná URL a Terraform z nej pre firmware vygeneruje URL s tokenom v query parametri a pre iPXE URL s vloženými prihlasovacími údajmi.

2. Vlastné iPXE s vložením VLAN tagu

Pri UEFI HTTP boote cez tagovanú VLAN iPXE síce zdedí IP adresu z firmwaru, ale nie VLAN tag – a v tom momente stratí konektivitu. Riešením bolo v GitLab pipeline skompilovať vlastný ipxe.efi s vloženým skriptom, ktorý si VLAN interface znovu vytvorí (vcreate --tag …) a až potom cez chainload stiahne kernel, initrd a Ignition config. Pri alternatívnom boote z iDRAC virtuálneho média zas do kernel parametrov pridávame coreos.liveiso.fromram, aby live systém bežal celý z RAM a médium bolo možné bezpečne odpojiť ešte počas inštalácie.

3. Redfish cez curl namiesto Terraform providera

Kritické operácie boot orchestrácie – virtual media, boot override a BIOS konfiguráciu – sme implementovali ako shell skript, ktorý volá Redfish REST API priamo cez curl. Skript je idempotentný a funguje ako stavový automat. Porovná aktuálnu BIOS konfiguráciu s cieľovou, aplikuje len rozdiely, detekuje už rozbehnuté konfiguračné joby (takže prerušený beh možno bezpečne zopakovať), počká na dokončenie a výsledok overí. V logoch pritom dôsledne maskuje tokeny.
Rovnaký princíp – každá akcia sa opakovane kontroluje, kým nedosiahne overený koncový stav (médium pripojené, boot override potvrdený, server beží) – platí pre celú boot orchestráciu. Pri desiatkach serverov je toto overovanie nevyhnutné, pretože úspešný beh pipelinesám osebe nezaručuje, že sa klaster skutočne nainštaloval.

4. Bonding odolný voči výpadku sieťovej karty aj switchu

Každý server má dve dvojportové 100 Gb/s sieťové karty v samostatných PCIe slotoch a nad nimi dva LACP bondy. Bond0 nesie klastrovú prevádzku (API, pody, Ceph public), bond1 je dedikovaný pre internú replikáciu Ceph úložiska. Porty do bondov však nie sú spárované v rámci jednej karty – každý bond kombinuje jeden port z prvej a jeden port z druhej karty, a zároveň sú jeho porty zapojené do dvoch rôznych leaf switchov.

Výpadok celej sieťovej karty ani výpadok celého switchu tak žiadny bond nezhodí – oba bondy len zdegradujú na polovičnú priepustnosť a server ostáva plne dostupný.

Čo tým zákazník získal

• Opakovateľnosť – celý klaster je popísaný v Gite. Nové prostredie znamená nové tfvars a spustenie pipeline, ručná konfigurácia je tým eliminovaná úplne.
• Disaster recovery ako pipeline – obnova nestojí na záložnej lokalite, ale na princípe „preinštaluj z Gitu“. Terraform postaví infraštruktúru, GitOps (ArgoCD) vráti aplikácie, zálohy doplnia dáta.
• Konzistenciu prostredí – lab, dev a prod vznikajú z identického kódu, takže to, čo je otestované v labe, platí aj v produkcii.
• Auditovateľnosť – každá zmena infraštruktúry je commit s históriou. V regulovanom prostredí to už je dnes nutnosť, aby bolo dohľadateľné, kto, kedy a čo zmenil.

Projekt ukázal, že fyzickú infraštruktúru možno riadiť rovnako ako cloud – deklaratívne, z Gitu, jednou pipeline-ou. Stačí na to kombinácia agent-based installera, Terraformu, Redfish API a vlastného riešenia tam, kde hotové nástroje nestačia. Výsledkom je klaster roztiahnutý cez tri dátové centrá, ktorý prežije výpadok ktoréhokoľvek z nich bez straty dát.

Alanata a. s. je Red Hat Premier partner – nasadenia ako toto staviame na oficiálne podporovaných technológiách Red Hat portfólia a v úzkej spolupráci s výrobcom, od návrhu architektúry až po produkčnú prevádzku.