{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/container-orchestration","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/container-orchestration/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/container-orchestration/"},"term":{"en":"Container orchestration","da":"Container-orkestrering"},"aka":{"en":[],"da":[]},"domain":["platform"],"cluster":"containers","layer":"orchestration","status":"current","era":2014,"summary":{"en":"Letting software run many containers across a group of machines automatically, so nobody has to start and place them by hand.","da":"At lade software drive mange containere automatisk på tværs af en gruppe maskiner, så ingen skal starte og placere dem i hånden."},"body":{"formal":{"en":"The automated running of containers across many hosts from a written description of the wanted state - choosing where each one runs, replacing failed ones, adding copies under load and rolling out new versions.","da":"Automatisk drift af containere på tværs af mange værter ud fra en skriftlig beskrivelse af den ønskede tilstand - at vælge, hvor hver kører, erstatte dem, der fejler, tilføje kopier under belastning og rulle nye versioner ud."},"plain":{"en":"Like the conductor of an orchestra - the musicians play their own parts, but someone decides who plays when, and brings in a stand-in if one falls ill.","da":"Som dirigenten i et orkester - musikerne spiller deres egne stemmer, men nogen bestemmer, hvem der spiller hvornår, og sætter en afløser ind, hvis én bliver syg."},"inPractice":{"en":"When a Danish web shop gets a rush of Black Friday visitors, the orchestration system starts ten more copies of the shop's container and removes them again when traffic drops, while the operations engineer on call sleeps.","da":"Når en dansk webshop får en bølge af besøgende på Black Friday, starter orkestreringssystemet ti ekstra kopier af shoppens container og fjerner dem igen, når trafikken falder, mens driftsvagten sover."},"whyItMatters":{"en":"Without it, running hundreds of containers by hand is not possible; with it, the control system becomes a high-value target whose access must be tightly guarded.","da":"Uden den er det umuligt at drive hundredvis af containere i hånden; med den bliver styringssystemet et værdifuldt mål, hvis adgang skal bevogtes nøje."}},"deepDive":{"en":"Every orchestrator solves the same set of problems: cluster membership and health (which nodes exist and are alive), scheduling (bin-packing workloads onto nodes subject to resource requests, affinity and anti-affinity, taints and topology spread), lifecycle (restart, rolling update, rollback), service discovery and load balancing, configuration and secret distribution, storage attachment, and autoscaling. The dominant design, inherited from Google's Borg (described in the 2015 EuroSys paper) and its successor Omega, is declarative: operators submit a desired state to an API, it is persisted in a consistent store, and independent control loops continuously compare desired and observed state and act on the difference. This level-triggered reconciliation is what makes the system self-healing - a controller does not need to see the event that broke something, only the current gap.\n\nThe cluster state store is the critical component. Kubernetes keeps it in etcd, which uses Raft consensus, so a control plane is usually run as three or five members to tolerate one or two failures while keeping a majority quorum. Swarm mode embeds its own Raft store in the manager nodes; HashiCorp Nomad likewise runs Raft among its servers. Losing quorum freezes changes but normally leaves running workloads untouched, because node agents (kubelet in Kubernetes) keep existing containers alive.\n\nKubernetes has become the de facto standard; Docker Swarm mode survives for small setups, Nomad schedules containers alongside VMs and plain binaries, and managed services such as Amazon ECS provide proprietary orchestration. Scheduling quality depends on honest resource requests: without them the scheduler overcommits, and under memory pressure the kubelet evicts pods, starting with those in the BestEffort QoS class.\n\nSecurity concerns follow from centralisation. The orchestrator API can create workloads with any image, mount secrets and, unless prevented by admission policy, start privileged pods, so API access is effectively root on every node. NIST SP 800-190 lists orchestrator countermeasures such as least-privilege administrative access, separating workloads of different sensitivity onto different hosts, encrypted network traffic between nodes and trustworthy node enrolment. Typical real-world failures include API servers or dashboards exposed to the internet, overly broad RBAC bindings, unencrypted secrets in the state store and flat pod networks without network policy. Orchestration is distinct from configuration management (Ansible, Puppet), which converges machine state, and from GitOps, which is a way of feeding desired state into the orchestrator.","da":"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.\n\nKlyngens 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.\n\nKubernetes 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.\n\nSikkerhedsproblemerne 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å."},"edges":[{"type":"requires","to":"platform/container","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/network","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/gitops","confidence":"high","strength":"normal"}],"depth":3,"sources":[{"title":"CNCF Cloud Native Glossary - Container orchestration","url":"https://glossary.cncf.io/container-orchestration/","tier":"reference","publisher":"CNCF"},{"title":"NIST SP 800-190 - Application Container Security Guide","tier":"standard","publisher":"NIST"}],"draft":true}