{"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/kubernetes","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/kubernetes/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/kubernetes/"},"term":{"en":"Kubernetes","da":"Kubernetes"},"aka":{"en":["K8s"],"da":["K8s"]},"domain":["platform"],"cluster":"containers","layer":"orchestration","status":"current","era":2014,"summary":{"en":"The most widely used open-source system for container orchestration, first built at Google and released in 2014.","da":"Det mest udbredte open source-system til container-orkestrering, oprindeligt bygget hos Google og udgivet i 2014."},"body":{"formal":{"en":"An open-source system that runs containers across a group of machines; users describe the wanted state in files, a control layer keeps working to make the real state match, and pods are the smallest unit it places and runs.","da":"Et open source-system, der kører containere på tværs af en gruppe maskiner; brugerne beskriver den ønskede tilstand i filer, et styringslag arbejder hele tiden på at få den faktiske tilstand til at passe, og pods er den mindste enhed, det placerer og kører."},"plain":{"en":"Like a thermostat for software - you set how many copies should be running, and it keeps adding or removing them until reality matches.","da":"Som en termostat for software - du indstiller, hvor mange kopier der skal køre, og den bliver ved med at tilføje eller fjerne dem, til virkeligheden passer."},"inPractice":{"en":"The operations team at a hospital region asks for three copies of the appointment booking service; when one machine dies at night, Kubernetes restarts the lost copy on another machine before anyone on call wakes up.","da":"Driftsteamet i en region beder om tre kopier af tidsbestillingen; når én maskine dør om natten, genstarter Kubernetes den tabte kopi på en anden maskine, før nogen på vagt er vågnet."},"whyItMatters":{"en":"Many cloud platforms now run on it, and its many settings for access and network are a frequent source of cloud misconfiguration.","da":"Mange cloudplatforme kører nu på det, og dets mange indstillinger for adgang og netværk er en almindelig kilde til fejlkonfiguration i skyen."}},"deepDive":{"en":"Kubernetes is built around a single REST API. Every object has apiVersion, kind, metadata (name, namespace, labels, annotations, a resourceVersion used for optimistic concurrency), a spec written by the user and a status written by controllers. The kube-apiserver is the only component that talks to etcd; every other component - scheduler, kube-controller-manager, cloud-controller-manager, kubelet on each node - is a client that uses list-and-watch streams (wrapped in \"informers\" with local caches) to react to changes. A request passes through authentication (client certificates, bearer tokens, OIDC), authorization (usually RBAC plus the Node authorizer), mutating admission, schema validation and validating admission before it is persisted. Admission is where most policy lives: Pod Security Admission, ValidatingAdmissionPolicy written in CEL, and webhooks such as Kyverno or OPA Gatekeeper.\n\nScheduling happens in two phases: filtering removes nodes that cannot host the pod (insufficient requested CPU or memory, taints, node affinity, volume topology), and scoring ranks the rest before the scheduler writes a binding. The kubelet then asks the container runtime over CRI to create the pod sandbox and containers, while CNI plugins (Calico, Cilium and others) give each pod a routable IP in a flat network. Services provide stable virtual IPs implemented by kube-proxy with iptables, IPVS or nftables rules, or by eBPF in some CNIs; Ingress and the newer Gateway API handle L7 routing. Custom Resource Definitions let anyone add new kinds, and the operator pattern pairs a CRD with a controller that encodes operational knowledge, for example for databases.\n\nThe project ships three minor releases a year, and each minor version receives patches for roughly 14 months, so clusters left unupgraded fall out of support quickly; managed offerings (EKS, AKS, GKE) impose their own support windows. Notable breaking changes include the removal of dockershim in 1.24 and of PodSecurityPolicy in 1.25, replaced by Pod Security Admission with the privileged, baseline and restricted profiles.\n\nDefault settings are permissive in ways that surprise newcomers. Secrets are stored base64-encoded, not encrypted, unless an EncryptionConfiguration (ideally with a KMS provider) is set on the API server; any identity allowed to create pods in a namespace can read every Secret there by mounting it; service-account tokens are mounted into pods unless automountServiceAccountToken is disabled; all pods can reach all pods until a NetworkPolicy selects them; and audit logging is off until an audit policy is supplied. The CIS Kubernetes Benchmark, NSA/CISA Kubernetes Hardening Guidance and NIST SP 800-190 are the usual audit baselines. Kubernetes implements container orchestration but deliberately leaves build, image supply chain, CI and application-level concerns to other tools.","da":"Kubernetes er bygget op om ét REST-API. Hvert objekt har apiVersion, kind, metadata (navn, namespace, labels, annotations og en resourceVersion til optimistisk samtidighedskontrol), en spec skrevet af brugeren og en status skrevet af controllere. kube-apiserver er den eneste komponent, der taler med etcd; alle andre komponenter - planlæggeren, kube-controller-manager, cloud-controller-manager og kubelet på hver node - er klienter, der bruger list-and-watch-strømme (pakket ind i \"informers\" med lokale caches) til at reagere på ændringer. En forespørgsel går gennem autentificering (klientcertifikater, bearer tokens, OIDC), autorisation (normalt RBAC plus Node-autorisatoren), muterende admission, skemavalidering og validerende admission, før den gemmes. Admission er stedet, hvor det meste politik bor: Pod Security Admission, ValidatingAdmissionPolicy skrevet i CEL og webhooks som Kyverno eller OPA Gatekeeper.\n\nPlanlægningen sker i to faser: filtrering fjerner noder, der ikke kan rumme poden (for lidt forespurgt CPU eller hukommelse, taints, node affinity, volumentopologi), og scoring rangerer resten, før planlæggeren skriver en binding. kubelet beder derefter container-runtimen via CRI om at oprette pod-sandkassen og containerne, mens CNI-plugins (Calico, Cilium m.fl.) giver hver pod en routbar IP i et fladt netværk. Services giver stabile virtuelle IP'er, som kube-proxy implementerer med iptables-, IPVS- eller nftables-regler, eller som visse CNI'er løser med eBPF; Ingress og det nyere Gateway API håndterer routing på lag 7. Custom Resource Definitions lader enhver tilføje nye objekttyper, og operator-mønstret kobler en CRD med en controller, der indkoder driftsviden, fx om databaser.\n\nProjektet udgiver tre minor-versioner om året, og hver minor-version får rettelser i cirka 14 måneder, så klynger, der ikke opgraderes, hurtigt falder ud af support; administrerede tjenester (EKS, AKS, GKE) har deres egne supportvinduer. Kendte brud på bagudkompatibilitet er fjernelsen af dockershim i 1.24 og af PodSecurityPolicy i 1.25, som blev afløst af Pod Security Admission med profilerne privileged, baseline og restricted.\n\nStandardindstillingerne er lempelige på måder, der overrasker nye brugere. Secrets gemmes base64-kodet, ikke krypteret, medmindre API-serveren får en EncryptionConfiguration (helst med en KMS-udbyder); enhver identitet, der må oprette pods i et namespace, kan læse alle Secrets dér ved at montere dem; service account-tokens monteres i pods, medmindre automountServiceAccountToken slås fra; alle pods kan nå alle pods, indtil en NetworkPolicy vælger dem; og audit-logning er slået fra, indtil der angives en audit-politik. CIS Kubernetes Benchmark, NSA/CISA's Kubernetes Hardening Guidance og NIST SP 800-190 er de sædvanlige grundlag for revision. Kubernetes implementerer container-orkestrering, men overlader bevidst bygning, image-forsyningskæde, CI og applikationsnære opgaver til andre værktøjer."},"edges":[{"type":"requires","to":"platform/container","confidence":"high","strength":"normal"},{"type":"implements","to":"platform/container-orchestration","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/role-based-access-control","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/microservices","confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/model-serving","why":{"en":"Kubernetes is commonly used to run, scale and restart model-serving containers across many GPU machines.","da":"Kubernetes bruges ofte til at køre, skalere og genstarte model-serving-containere på tværs af mange GPU-maskiner."},"confidence":"medium","strength":"normal"}],"depth":3,"sources":[{"title":"Kubernetes Documentation - Overview","url":"https://kubernetes.io/docs/concepts/overview/","tier":"official-doc","publisher":"The Kubernetes Authors"},{"title":"NIST SP 800-190 - Application Container Security Guide","tier":"standard","publisher":"NIST"}],"draft":true}