Container-orkestrering

Alle orkestreringssystemer løser de samme opgaver: medlemskab og sundhed i klyngen (hvilke noder findes, og er de i live), planlægning (at pakke workloads på noder ud fra ressourceforespørgsler, affinity og anti-affinity, taints og topologispredning), livscyklus (genstart, rullende opdatering, tilbagerulning), service discovery og lastbalancering, fordeling af konfiguration og hemmeligheder, tilkobling af lager samt autoskalering. Det dominerende design, arvet fra Googles Borg (beskrevet i EuroSys-artiklen fra 2015) og efterfølgeren Omega, er deklarativt: operatører sender en ønsket tilstand til et API, den gemmes i et konsistent lager, og uafhængige styringsløkker sammenligner hele tiden ønsket og observeret tilstand og handler på forskellen. Denne niveaustyrede afstemning (level-triggered reconciliation) gør systemet selvhelende - en controller behøver ikke se den hændelse, der ødelagde noget, kun den aktuelle forskel.

Klyngens tilstandslager er den kritiske komponent. Kubernetes gemmer den i etcd, der bruger Raft-konsensus, så et kontrolplan køres normalt med tre eller fem medlemmer for at kunne tåle én eller to fejl og stadig have flertal (quorum). Swarm mode har sit eget Raft-lager indbygget i manager-noderne, og HashiCorp Nomad kører ligeledes Raft mellem sine servere. Mistes quorum, fryses ændringer, men kørende workloads lades normalt i fred, fordi agenterne på noderne (kubelet i Kubernetes) holder de eksisterende containere i live.

Kubernetes er blevet de facto-standarden; Docker Swarm mode lever videre i små opsætninger, Nomad planlægger containere side om side med VM'er og almindelige binærer, og administrerede tjenester som Amazon ECS tilbyder proprietær orkestrering. Planlægningens kvalitet afhænger af ærlige ressourceforespørgsler: uden dem overbooker planlæggeren, og under hukommelsespres smider kubelet pods ud (eviction), begyndende med dem i QoS-klassen BestEffort.

Sikkerhedsproblemerne følger af centraliseringen. Orkestreringens API kan oprette workloads med et vilkårligt image, montere hemmeligheder og - medmindre en admission-politik forhindrer det - starte privilegerede pods, så API-adgang reelt er root på alle noder. NIST SP 800-190 nævner modforanstaltninger for orkestrering som administrativ adgang efter mindste privilegium, adskillelse af workloads med forskellig følsomhed på forskellige værter, krypteret netværkstrafik mellem noder og pålidelig tilmelding af noder. Typiske fejl i praksis er API-servere eller dashboards eksponeret mod internettet, for brede RBAC-bindinger, ukrypterede hemmeligheder i tilstandslageret og flade pod-netværk uden netværkspolitikker. Orkestrering er noget andet end konfigurationsstyring (Ansible, Puppet), der bringer maskiners tilstand på plads, og end GitOps, som er en måde at føde den ønskede tilstand ind i orkestreringen på.