Tady je pět věcí, které musíte mít v pořádku. Pokud je nemáte, je otázkou času, kdy vás to doběhne.
Princip nejmenších oprávnění zní jako samozřejmost, ale v praxi to málokdo dodržuje. Typický scénář: vývojář potřebuje nasadit aplikaci, něco nefunguje, admin mu dá cluster-admin práva „dočasně". Za půl roku má cluster-admin práva polovina firmy a nikdo neví "Jak se to mohlo stát?".
Security Context Constraints jsou na tom ještě hůř. SCC definují, co kontejner smí a nesmí – jestli může běžet jako root, jestli má přístup k host síti, jestli může měnit UID. Spousta adminů SCC buď ignoruje, nebo nastaví příliš volně, protože „jinak to nefunguje". To je přesně ten anti-pattern, který se vrátí jako bezpečnostní incident.
Správný přístup: nastavit RBAC granulárně od začátku. Každý tým má přístup jen do svých projektů. SCC nastavit co nejrestriktivněji a uvolňovat jen tam, kde je to opodstatněné a zdokumentované. Ano, stojí to víc práce na začátku. Ale stojí to mnohem méně než bezpečnostní audit, který odhalí, že každý kontejner ve vašem clusteru běží jako root.
Bez resource limitů může jeden Pod spotřebovat veškeré prostředky nodu. Celý. CPU, paměť, všechno. A tím shodit všechny ostatní Pody na tom samém nodu. Viděl jsem to v praxi mnohokrát – vývojář nasadí aplikaci s memory leakem, žádné limity, a za dvě hodiny je celý node v OOMKill spirále.
LimitRange definuje default a maximální limity na úrovni namespace – tedy pro jednotlivé Pody. ResourceQuota omezuje celkovou spotřebu všech Podů v namespace dohromady. Potřebujete obojí.
Správné nastavení requests a limits je samo o sobě téma na delší diskusi. Request je kolik zdrojů Pod potřebuje pro normální běh – podle toho scheduler rozhoduje, kam Pod umístí. Limit je maximum, které nesmí překročit. Nejčastější chyba: request příliš nízký (scheduler umístí víc Podů na node, než unese) nebo limit příliš vysoký (jeden Pod sežere všechno). Druhou nejčastější chybou je nenastavit limity vůbec.
Výchozí stav v OpenShift clusteru: každý Pod může komunikovat s každým jiným Podem. Napříč projekty, napříč namespace. To je jako mít firmu, kde má každý zaměstnanec klíče od všech místností včetně serverovny.
Network policies umožňují mikrosegmentaci – definujete, kdo s kým smí komunikovat. Projekt A vidí jen své Pody a databázový service v projektu B. Nic jiného. Egress traffic je omezený jen na povolené cíle.
V praxi to znamená napsat pár YAML manifestů. Není to složité, ale vyžaduje to rozmyšlení architektury dopředu. Na kurzech to procházíme hands-on – účastníci si nastaví network policies na reálném clusteru a vidí, co se stane, když Pod zkusí komunikovat s něčím, co nemá povolené.
OpenShift přichází s integrovaným monitoringem – Prometheus, Grafana, alertmanager. To je skvělý základ, ale samo o sobě to nestačí. Výchozí alerty pokrývají zdraví clusteru, ale ne vaše specifické provozní potřeby.
Co monitorovat nad rámec defaultu: expiraci certifikátů (ne až když vyprší, ale s dostatečným předstihem), využití persistent volumes (plný disk v produkci je noční můra), custom metriky vašich aplikací, stav operátorů a jejich reconciliation loop.
A hlavně – monitoring musí být napojený na váš existující alerting. Jestli máte Graylog, Grafana stack, PagerDuty – propojte to. Alert, který nikdo nevidí, je stejně užitečný jako žádný alert.
Tohle je téma, které opakuju na každém kurzu, protože to lidi pořád dělají špatně. A důsledky jsou vždy stejné – provozní problémy, které se špatně diagnostikují a ještě hůř řeší.
Network-based storage v kontejnerech – NFS, iSCSI přes síť – má vysokou latenci a nízké IOPS. Pro webserver nebo API to nevadí, protože tam žádná data nejsou. Pro databázi je to katastrofa. Pomalé query, timeouty, lock contention.
Alternativa je lokální disk nebo Fiber Channel – tam máte výkon, ale ztrácíte vysokou dostupnost. Když odstavíte node (údržba, aktualizace, výpadek), odstavíte i aplikaci, která na tom disku závisí. A tím ztrácíte jednu z hlavních výhod kontejnerové platformy – schopnost přesouvat workloady mezi nody bez výpadku.
Pragmatický přístup, který funguje:
Pokud chcete tohle všechno projít systematicky a hands-on, OpenShift Admin kurzy v Pumpedu pokrývají přesně tyhle témata – a desítky dalších. Od autentizace přes networking, bezpečnost, monitoring, logging, troubleshooting až po automatizaci. Jste-li začátečník, je pro Vás ideální školení Úvod do OpenShiftu, na to navazuje čtyřdenní školení OpenShift administrace 1, OpenShift administrace 2 a OpenShift administrace 3 pro enterprise provoz.
Další návazná školení jsou OpenShift instalace a OpenShift post-instalace.
Pro vývojáře je samostatná Learning path, kterou najdete v článku Vývojář v OpenShiftu: Jak nasadit aplikaci tak, aby přežila produkci
