Kubernetes (K8s) är en öppen källkodsplattform för containerorkestrering som automatiserar distribution, skalning och hantering av containerapplikationer över ett kluster av maskiner. Google gjorde det till öppen källkod 2014, och Cloud Native Computing Foundation (CNCF) underhåller det idag.
Kubernetes är en öppen källkodsplattform för containerorkestrering som automatiserar distribution, skalning och hantering av containerapplikationer. Google lanserade Kubernetes med öppen källkod i juni 2014, och Cloud Native Computing Foundation (CNCF) har underhållit det sedan 2015. Kubernetes grupperar containrar i poddar, schemalägger poddar över ett kluster av maskiner och startar om misslyckade arbetsbelastningar automatiskt.
Key Takeaways
- Kubernetes schemalägger containrar över ett kluster, startar om misslyckade arbetsbelastningar och skalar applikationer automatiskt. Google gjorde det till öppen källkod i juni 2014, och version 1.0 levererades den 21 juli 2015, då projektet donerades till det nybildade CNCF.
- Ett Kubernetes-kluster har två delar: ett kontrollplan (kube-apiserver, etcd, kube-scheduler och controller managers) som fattar beslut, och arbetsnoder (kubelet, container runtime, kube-proxy) som kör arbetsbelastningarna.
- Projektet levererar tre mindre utgåvor per år, som var och en stöds i ungefär 14 månader. Kubernetes v1.36, släppt den 22 april 2026, är den aktuella versionen.
- Kubernetes Secrets är som standard base64-kodade, inte krypterade. Produktionskluster bör aktivera kryptering i vila; KMS v2-providern har varit stabil sedan v1.29.
- Ingress NGINX-kontrollenheten togs ur bruk i mars 2026 och får inga ytterligare säkerhetsuppdateringar. Gateway API är dess rekommenderade efterföljare.
Hur Kubernetes fungerar
Kubernetes arbetar med en deklarativ modell: du beskriver det tillstånd du vill ha i YAML eller JSON, och kontrollanter avstämmer kontinuerligt klustret mot det tillståndet. Om du deklarerar att en distribution ska köra fem repliker av en tjänst och en kraschar, upptäcker Kubernetes gapet och startar en ersättning utan mänsklig inblandning.
Tänk dig ett företag som kör ett ERP-system med separata moduler för lager, HR och ekonomi. Allt eftersom efterfrågan ökar skalar Kubernetes containrarna bakom varje modul, balanserar trafiken mellan servrar och startar om misslyckade tjänster. Den kör också liveness-sonder (kör applikationen fortfarande?) och beredskapssonder (kan den ta emot trafik än?) så att ohälsosamma containrar startas om eller tas ur rotation innan användarna märker det. Eftersom CNCF upprätthåller Kubernetes som leverantörsneutral öppen källkod, körs samma klusterdefinition lokalt, i alla större molnmiljöer eller i hybridmiljöer.
Kubernetes vs Docker Swarm
Docker Swarm är Dockers inbyggda klusterläge; det är enklare att konfigurera än Kubernetes men täcker en mycket snävare uppsättning orkestreringsbehov.
| Attribut | Docker svärm | Kubernetes |
| Inställning | Inbyggt i Docker; minuter att starta | Brantare inlärningskurva; hanterade tjänster (EKS, AKS, GKE) minskar bördan |
| Förkalkning | Manuell tjänstskalning | Automatisk horisontell skalning med Horizontal Pod Autoscaler (HPA) |
| Självläkande | Startar om misslyckade containrar | Startar om, schemalägger om och ersätter poddar med hjälp av liveness- och beredskapssonder |
| utbyggnader | Löpande uppdateringar, begränsade kontroller | Löpande uppdateringar plus automatisk återställning av misslyckade hälsokontroller |
| Ekosystem | Docker-verktygskedjan | CNCF-ekosystem: Helm, Prometheus, cert-manager, Gateway API-implementeringar |
| Bäst för | Små team, enkla arbetsbelastningar | Produktionssystem i stor skala, mikrotjänster, hybrid- och multimoln |
Nyckelfunktioner i Kubernetes
Kubernetes samlar de operativa uppgifter som team en gång skriptade för hand i inbyggda, deklarativa funktioner.
- Horisontell skalningDen horisontella Pod-autoskalaren lägger till eller tar bort poddar baserat på mätvärden som CPU och minne. Resursförfrågningar och begränsningar låter schemaläggaren packa containrar på noder utan att överbelasta någon enskild maskin.
- Självläkning: Kubelet-enheten startar om containrar som misslyckas med liveness-avsökningar och hindrar trafik från poddar som misslyckas med beredskapsavsökningar.
- Tjänsteidentifiering och lastbalansering: Varje tjänst får ett DNS-namn och en stabil virtuell IP-adress. ClusterIP exponerar en tjänst inuti klustret, NodePort öppnar en port på varje nod och LoadBalancer tillhandahåller en molnbelastningsutjämnare för extern trafik.
- Lagringsorkestrering: PersistentVolumes och PersistentVolumeClaims frikopplar lagring från poddar, och Container Storage Interface (CSI) ansluter backends som AWS EBS, Google Persistent Disk eller NFS med dynamisk provisionering via StorageClasses.
- Hemligheter och konfiguration: ConfigMaps innehåller konfiguration och Secrets innehåller känsliga värden som API-nycklar. Hemligheter är base64-kodade, inte krypterade, som standard; aktivera kryptering i vila och använd KMS v2-providern (stabil sedan v1.29) för att skydda dem med nycklar som lagras i en extern nyckelhanteringstjänst.
- Automatiserade utrullningar och återställningar: Distributioner uppdaterar poddar gradvis medan de övervakar hälsoavsökningar och återställer till den senaste stabila versionen när en uppdatering misslyckas.
- Batch-arbetsbelastningar: Jobb kör uppgifter tills de är klara, och CronJobs kör dem enligt ett schema, till exempel nattliga säkerhetskopior eller analyskörningar.
- Dubbelstacknätverk och utbyggbarhet: Poddar och tjänster kan bära både IPv4- och IPv6-adresser, och anpassade resursdefinitioner utökar Kubernetes API för verktyg som Prometheus-operatorer eller cert-manager.
Kubernetes arkitektur
Ett Kubernetes-kluster delar upp ansvaret mellan ett kontrollplan som fattar globala beslut och arbetsnoder som kör programarbetsbelastningar.
Kontrollplanskomponenter
- kube-apiserver: Klustrets ytterdörr. Varje kubectl-kommando, kontrollenhet och nodinteraktion passerar genom API-servern.
- etc.: Ett konsekvent nyckel-värde-arkiv som innehåller allt klustertillstånd och all konfiguration. Det är sanningskällan: om en kontrollplanskomponent startar om återställer den det aktuella tillståndet från etcd.
- kub-schemaläggare: Tilldelar nyskapade poddar till noder baserat på resursförfrågningar, tillhörighetsregler och begränsningar.
- kube-controller-manager: Kör avstämningslooparna som håller det faktiska tillståndet i linje med önskat tillstånd, till exempel genom att byta ut poddar när en nod misslyckas.
- moln-kontroller-hanterare: Integrerar klustret med en molnleverantörs API:er för lastutjämnare, rutter och nodlivscykel.
Komponenter för arbetsnod
- kubelet: Agenten på varje nod som säkerställer att containrarna som beskrivs i Pod-specifikationerna körs och är felfria.
- Containerkörningstid: Programvaran som faktiskt kör containrar via Container Runtime Interface (CRI), vanligtvis containerd eller CRI-O. Kubernetes tog bort den Docker-specifika dockershim i v1.24 (maj 2022); avbildningar byggda med Docker körs fortfarande oförändrade.
- kub-proxy: Upprätthåller nätverksregler på varje nod så att tjänsttrafiken når rätt poddar.
Kubernetes-objekt
| Ändamålet | Vad den gör | Exempel på användningsfall |
| Pod | Minsta utplacerbara enhet; en eller flera containrar som delar nätverk och lagring | Köra en instans av en Nginx-webbserver |
| Service | Stabil nätverksslutpunkt för en uppsättning poddar | Ansluta ett frontend till ett backend-API |
| konfiguration | Hanterar ReplicaSets, rullande uppdateringar och återställningar | Släpp en ny mikrotjänstversion med noll driftstopp |
| ReplicaSet | Håller ett angivet antal identiska Pods igång | Underhålla fem webbserverreplikor för tillgänglighet |
| Konfigurationskarta / Hemlighet | Hållkonfiguration och känsliga värden | Databasanslutningssträngar; API-inloggningsuppgifter |
| StatefulSet | Stabil identitet och lagring för tillståndskänsliga appar | Köra MongoDB eller MySQL med volymer per instans |
| DaemonSet | Kör en Pod på varje nod | Distribuera en loggnings- eller övervakningsagent i hela kluster |
| Jobb / CronJob | Kör uppgifter en gång eller enligt ett schema | Nattliga säkerhetskopior av databasen |
Nätverk: Från Ingress till Gateway API
Hur extern trafik kommer in i ett Kubernetes-kluster förändrades väsentligt under 2026, och alla team som fortfarande standardiserar Ingress NGINX-kontrollern måste agera.
Ingress API dirigerar extern HTTP- och HTTPS-trafik till tjänster inuti klustret och kan avsluta TLS. Själva API:et förblir en del av Kubernetes men är funktionsfryst. Dess mest populära implementering, Ingress NGINX-kontrollern, pensionerades av Kubernetes-projektet den 24 mars 2026, efter ett tillkännagivande den 12 november 2025; arkivet är skrivskyddat och får inga ytterligare buggfixar eller CVE-patchar.
I ett uttalande den 29 januari 2026 noterade Kubernetes styr- och säkerhetskommittéer att ungefär hälften av molnbaserade miljöer kör Ingress NGINX och uppmanade till omedelbar migrering.
Gateway API, allmänt tillgängligt sedan v1.0 i oktober 2023, är den rekommenderade efterföljaren. Det separerar infrastrukturfrågor (Gateways) från applikationsrouting (HTTPRoutes), stöder mer omfattande trafikkontroller och fungerar konsekvent över implementeringar som Envoy Gateway, Cilium och molnleverantörsgateways.
Verktyget ingress2gateway, som nådde version 1.0 i mars 2026, konverterar befintliga Ingress-resurser till Gateway API-ekvivalenter. Team som föredrar att behålla Ingress API:et kan gå över till en aktivt underhållen tredjepartskontroller som Traefik, HAProxy eller den kommersiella F5 NGINX Ingress Controller.
Kubernetes i DevOps och CI/CD
Kubernetes ger DevOps-team ett distributionsmål och en operativ modell i varje miljö, vilket är anledningen till att det förankrar de flesta moderna CI/CD-pipelines.
Pipelines byggda med Jenkins, GitLab CI eller liknande verktyg bygger en containeravbildning, skickar den till ett register och tillämpar ett uppdaterat manifest på klustret; Kubernetes utför sedan den rullande uppdateringen och återställer automatiskt om hälsokontroller misslyckas.
I GitOps-arbetsflöden övervakar verktyg som Argo CD och Flux ett Git-arkiv och håller klustret synkroniserat med det, så varje ändring är versionskontrollerad och granskningsbar. Eftersom manifest är deklarativa körs samma definitioner identiskt i utveckling, staging och produktion. För den bredare praxis som detta passar in i, se vad DevOps är och hur det fungerar.
PKI och TLS i Kubernetes
Varje Kubernetes-kluster är en fungerande infrastruktur för offentliga nyckelr: X.509-certifikat autentiserar och krypterar nästan alla anslutningar mellan komponenter, oavsett om teamet som kör klustret tänker på certifikat eller inte.
Public Key Infrastructure (PKI) är ramverket för certifikatutfärdare (CA), certifikat och nycklar som etablerar förtroende mellan maskiner. I Kubernetes säkrar Transport Layer Security (TLS)-certifikat API-serverns slutpunkt, kubeletens anslutning till kontrollplanet, etc. peer- och klienttrafik, och alla tjänster som exponeras över HTTPS.
Klientcertifikat autentiserar även användare och komponenter till API-servern. Kluster som startas med kubeadm genererar denna PKI automatiskt, och dess klientcertifikat upphör som standard att gälla efter ett år, så förnyelse måste spåras eller automatiseras innan det orsakar ett avbrott.
För arbetsbelastningscertifikat automatiserar cert-manager utfärdande och förnyelse inuti klustret och uppgraderades som ett CNCF-projekt den 12 november 2024, vilket placerar det på samma mognadsnivå som Kubernetes självt. Certifikat matas vanligtvis in i klustret som Kubernetes-hemligheter refererade av Gateways eller Ingress-resurser; att korrekt generera den underliggande certifikatsigneringsbegäran (CSR) är det första steget i den kedjan.
På företagsnivå bör kluster- och arbetsbelastningscertifikat följa samma livscykelhanteringsprocess som resten av certifikaten, särskilt med tanke på att den maximala giltighetstiden för publika TLS-certifikat sjunker till 47 dagar i mars 2029 enligt CA/Browser Forum-schemat.
Kubernetes säkerhetsrisker och bästa praxis
De flesta Kubernetes-intrång kan spåras tillbaka till en liten uppsättning återkommande svagheter, var och en med en väl förstådd kontroll.
| Risk | Varför det spelar roll | Bästa praxis |
| Felkonfigurerad åtkomstkontroll | Svag eller standard RBAC låter obehöriga användare manipulera klustret | Tillämpa RBAC med lägst behörighet, granska åtkomst regelbundet, tillämpa nätverkspolicyer |
| Sårbara containerbilder | Föråldrade eller overifierade bilder överför kända CVE:er till produktion | Hämta från betrodda register och skanna bilder med verktyg som Trivy |
| Okrypterade hemligheter | Base64-kodade hemligheter kan läsas av alla med etcd- eller API-åtkomst | Aktivera kryptering i vila med KMS v2; begränsa hemlig åtkomst via RBAC |
| Opatchat ingångslager | Pensionerade styrenheter som Ingress NGINX får inga CVE-korrigeringar efter mars 2026 | Migrera till Gateway API eller en underhållen kontrollant |
| Osignerad leveranskedja | Manipulerade bilder och beroenden kommer in i klustret oupptäckta | Signera och verifiera bilder med Sigstore Cosign; tillämpa antagningspolicyer |
| Utgångna certifikat | kubeadm-klientcertifikat upphör att gälla efter ett år och bryter klusterautentiseringen | Övervaka och automatisera certifikatförnyelse över kluster |
För en djupare behandling, se EC:s guider om bästa praxis för Kubernetes-säkerhet , säkra containrar och maskinidentiteter i Kubernetes i en Zero Trust-modell.
Hur krypteringskonsulting hjälper
CertSecure Manager är Encryption Consultings plattform för hantering av certifikatlivscykler. Den upptäcker de certifikat som körs i dina Kubernetes-kluster och resten av din databaser, automatiserar utfärdande och förnyelse genom integrationer inklusive cert-manager, och varnar vid utgångsdatum innan ett avbrott inträffar. Encryption Consultings PKI-tjänster utformar och driver sedan CA-hierarkin som förankrar förtroendet i dina kluster. Stöds av ISO/IEC 27001:2022 och SOC 2-certifierade metoder.
Vanliga frågor om partihandel med mat och dryck
Vad är Kubernetes enkelt uttryckt?
Kubernetes är programvara som kör och hanterar containerbaserade applikationer över en grupp maskiner som kallas ett kluster. Du deklarerar det tillstånd du vill ha, till exempel tre kopior av en webbserver, och Kubernetes startar containrarna, sprider dem över maskiner, ersätter alla som misslyckas och lägger till fler när trafiken ökar.
Vad är skillnaden mellan Kubernetes och Docker?
Docker bygger och kör enskilda containrar på en enda maskin. Kubernetes orkestrerar många containrar över många maskiner och hanterar schemaläggning, skalning, nätverk och återställning. De två fungerar tillsammans: containeravbildningar byggda med Docker körs inuti Kubernetes Pods. Sedan Kubernetes v1.24 tog bort dockershim i maj 2022 kör kluster dessa avbildningar via CRI-körningar som containerd eller CRI-O.
Hur ofta släpps Kubernetes, och vilken version är aktuell?
Kubernetes-projektet levererar tre mindre utgåvor per år, och varje utgåva får ungefär 14 månaders patchsupport. Projektet har stöd för de tre senaste mindre versionerna när som helst. Kubernetes v1.36, släppt den 22 april 2026, är den nuvarande mindre versionen, med v1.37 planerad till den 26 augusti 2026.
Är Kubernetes Secrets krypterade som standard?
Nej. Kubernetes Secrets är base64-kodade, vilket är reversibel kodning, inte kryptering. Vem som helst med åtkomst till etcd eller tillräckliga API-behörigheter kan läsa dem. Produktionskluster bör aktivera kryptering i vila via en EncryptionConfiguration, helst med KMS v2-leverantören, som blev stabil i Kubernetes v1.29 och krypterar Secrets med nycklar som lagras i en extern nyckelhanteringstjänst.
Vad ersatte Ingress NGINX i Kubernetes?
Kubernetes-projektet pensionerade Ingress NGINX-kontrollenheten i mars 2026, och arkivet får inte längre buggfixar eller säkerhetsuppdateringar. Själva Ingress API:et finns fortfarande kvar men har fryst funktioner. Gateway API:et är den rekommenderade efterföljaren för nya distributioner, och ingress2gateway-verktyget konverterar befintliga Ingress-resurser under migreringen.
Varför behöver Kubernetes PKI- och TLS-certifikat?
Varje anslutning mellan Kubernetes-komponenter, inklusive API-servern, etcd, kubelets och controllers, autentiseras och krypteras med X.509-certifikat utfärdade av klustercertifikatutfärdare. Utan denna offentliga nyckelinfrastruktur skulle vilken process som helst kunna imitera en klusterkomponent. Certifikat utfärdade av kubeadm upphör som standard att gälla efter ett år, så förnyelse måste spåras eller automatiseras.
Automatisera certifikatlivscykler i dina kluster
Certifikatfel tar Kubernetes-kluster ner i tysthet. Automatisera certifikatlivscykler med CertSecure Manager , eller generera din nästa CSR på några sekunder med EC:s kostnadsfria CSR-generator.
