TakéContainer orchestration, Kontejnerová orchestrace, Workflow orchestrationPokročilý
Definice
Orchestrace je automatizované řízení mnoha dílčích úloh, kontejnerů nebo služeb tak, aby dohromady tvořily fungující celek. Orchestrátor rozhoduje, co se kde spustí, v jakém pořadí, co se stane při selhání a kdy se má kapacita zvětšit. Typickými nástroji jsou Kubernetes pro kontejnery a Airflow pro datové pipeline.
Nezaměňujte: Orchestrace označuje v IT řízení kontejnerů či workflow, v hudbě naopak úpravu skladby pro orchestr.
Než se na to spolehnete: Konkrétní vlastnosti jednotlivých nástrojů (Airflow, Temporal, Nomad) se mezi verzemi mění; text je proto drží na obecné úrovni. U zdrojů jsem si jistý kořeny dokumentace, nikoli hlubšími cestami.
Proč orchestrace vznikla
Jednu aplikaci na jednom serveru zvládne člověk spravovat ručně. Jakmile ale běží padesát kontejnerů na dvaceti strojích, přestává být lidsky možné hlídat, který proces spadl, kde zbývá paměť a jestli nová verze vůbec naběhla. Orchestrace tuhle práci převádí na software: administrátor popíše cílový stav a orchestrátor se ho snaží nepřetržitě udržet.
Klíčový posun je od imperativních příkazů („spusť tři instance“) k deklarativnímu popisu („chci, aby vždy běžely tři instance“). Rozdíl se projeví ve tři ráno, kdy uzel odejde a orchestrátor bez zásahu člověka rozjede chybějící repliky jinde.
Dvě rodiny orchestrátorů
Orchestrace kontejnerů a infrastruktury
Kubernetes, Nomad nebo Amazon ECS řeší, kam umístit kontejner, jak mu přidělit síť a úložiště, jak ho vystavit ostatním službám a jak provést postupnou výměnu verzí. Součástí bývá průběžná kontrola zdraví (health check), automatické restarty a horizontální škálování podle zátěže. Na tuhle vrstvu obvykle navazuje CI/CD, které do orchestrátoru dodává nové image.
Orchestrace úloh a workflow
Airflow, Dagster, Prefect nebo Temporal řeší jiný problém: závislosti mezi kroky v čase. Úloha B smí startovat až po úspěchu úlohy A, výsledky se ukládají, při selhání se krok opakuje s odstupem a stav běhu je trvale zaznamenaný. Typicky jde o datové pipeline, dávkové reporty nebo dlouhoběžící obchodní procesy.
Orchestrace versus choreografie
Orchestrace má centrální mozek, který ostatním komponentám říká, co dělat. Choreografie žádného dirigenta nemá: služby reagují na události a nikdo nedrží globální plán. Orchestrace je čitelnější a snáz se ladí, protože průběh je na jednom místě; zároveň je centrální bod jednodušší na zahlcení a představuje jasné místo selhání. Choreografie lépe škáluje organizačně, ale vyšetřování, proč objednávka uvízla, bývá bolestivé.
Co orchestrace stojí
Orchestrátor není zadarmo. Kubernetes přidává vlastní řídicí rovinu, síťový model, RBAC, správu tajemství a několik desítek pojmů, které musí tým znát. U jedné malé aplikace bývá levnější prosté PaaS nebo systemd na jednom serveru. Orchestrace se vyplatí, když počet služeb, četnost nasazení nebo požadavek na dostupnost přerostou to, co lidé udrží v hlavě.
Pozor také na bezpečnost: orchestrátor drží přihlašovací údaje k databázím i k registrům obrazů. Tajemství patří do vyhrazeného úložiště a v klidovém stavu je vhodné mít je chráněná šifrováním, ne uložená v repozitáři vedle konfigurace.
Příklady z praxe
Deklarace tří replik v Kubernetes
Tým popíše v manifestu, že služba api má běžet ve třech replikách. Když jeden uzel spadne, řídicí rovina zjistí rozdíl mezi požadovaným a skutečným stavem a chybějící pod naplánuje jinam. Nikdo nemusí ručně nic restartovat.
apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 selector: matchLabels: app: api template: metadata: labels: app: api spec: containers: - name: api image: registry.example.com/api:1.4.2 readinessProbe: httpGet: path: /healthz port: 8080Noční datová pipeline se závislostmi
E-shop stahuje každou noc data z platební brány, čistí je a teprve pak přepočítává report tržeb. Orchestrátor workflow zajistí pořadí kroků, tři opakované pokusy při výpadku API a upozornění do Slacku, když ani třetí pokus neprojde. Report se tak nikdy nespočítá z nekompletních dat.
extract = PythonOperator(task_id="extract_payments", python_callable=fetch, retries=3) transform = PythonOperator(task_id="clean", python_callable=clean) report = PythonOperator(task_id="revenue_report", python_callable=build_report) extract >> transform >> report
Časté omyly
- MýtusOrchestrace je jen jiné slovo pro Kubernetes.
- Ve skutečnostiKubernetes je jeden konkrétní orchestrátor kontejnerů. Orchestrace jako princip zahrnuje i nástroje pro datové pipeline (Airflow, Dagster), dlouhoběžící procesy (Temporal) nebo správu infrastruktury napříč cloudy.
- MýtusKdyž nasadíme orchestrátor, aplikace bude automaticky vysoce dostupná.
- Ve skutečnostiOrchestrátor umí restartovat a přeplánovat instance, ale nespraví aplikaci, která nezvládá běžet ve více kopiích, drží stav v lokálním souboru nebo má jedinou databázi bez repliky. Dostupnost musí podporovat i návrh samotné aplikace.
- MýtusOrchestrace a automatizace jsou totéž.
- Ve skutečnostiAutomatizace řeší jeden úkol bez zásahu člověka, například vytvoření virtuálního serveru. Orchestrace skládá mnoho takových automatizovaných kroků do řízeného celku včetně pořadí, závislostí a reakce na selhání.
Časté dotazy
- Kdy se orchestrace kontejnerů vyplatí a kdy je zbytečná?
- Orchestrace kontejnerů dává smysl od chvíle, kdy počet služeb, četnost nasazování nebo požadavek na dostupnost přesáhnou to, co tým zvládne ručně. Praktickým signálem bývá několik nezávislých služeb, potřeba nasazovat bez výpadku, automatické škálování podle zátěže nebo více prostředí. U jedné aplikace s předvídatelným provozem je levnější spravovaná platforma nebo jediný server, protože provoz orchestrátoru přidává vlastní řídicí rovinu, síťový model a nezanedbatelnou křivku učení celého týmu.
- Jaký je rozdíl mezi orchestrací a nástrojem pro správu konfigurace?
- Správa konfigurace, například Ansible nebo Puppet, uvádí jednotlivé stroje do požadovaného stavu: nainstaluje balíčky, rozdistribuuje konfigurační soubory, nastaví služby. Orchestrace pracuje o úroveň výš a řeší běh celku v čase: kam umístit instanci, kdy ji restartovat, jak provést postupný rollout, jak reagovat na výpadek uzlu. V praxi se obojí kombinuje, konfigurační nástroj připraví uzly a orchestrátor na nich průběžně řídí běžící úlohy.
- Potřebuje orchestrace nutně mikroslužby?
- Orchestrace nevyžaduje mikroslužby. I monolit zabalený do kontejneru profituje z automatického restartu, postupného nasazení nové verze, health checků a horizontálního škálování. Mikroslužby jen výrazně zvyšují počet pohyblivých částí, takže tam se orchestrace stává prakticky nutností. Opačně to ale neplatí: rozdělit aplikaci na desítky služeb jen proto, že tým zavedl Kubernetes, je častá a drahá chyba.
- Co se stane, když orchestrátor sám selže?
- Při výpadku řídicí roviny orchestrátoru už běžící úlohy zpravidla pokračují dál, protože je spouští agent na jednotlivých uzlech. Přestane však fungovat rozhodování: nová nasazení, škálování, přeplánování po pádu uzlu a změny konfigurace. Proto se řídicí rovina provozuje redundantně, se stavovým úložištěm typu etcd ve více instancích a s pravidelnou zálohou. U workflow orchestrátorů je kritická databáze stavu, bez ní se nedá navázat na rozpracované běhy.
Zdroje
- Kubernetes Documentation: Concepts(otevře se v novém okně)
- Docker Compose overview(otevře se v novém okně)
- Amazon Elastic Container Service Documentation(otevře se v novém okně)
- Orchestration (computing)(otevře se v novém okně)
Související pojmy
