🥇Kubernetes 1.16: översikt över de viktigaste innovationerna

Idag, onsdag, kommer att äga rum nästa utgåva av Kubernetes - 1.16. Enligt traditionen som har utvecklats för vår blogg är det tioårsdagen vi talar om de mest betydande förändringarna i den nya versionen.

Information som används för att förbereda detta material är hämtad från Spårningstabeller för Kubernetes-förbättringar, ÄNDRINGSLOGG-1.16 och relaterade frågor, pull-förfrågningar och Kubernetes Enhancement Proposals (KEP). Låt oss gå!..

Knutpunkter

Ett verkligt stort antal anmärkningsvärda innovationer (i alfaversionsstatus) presenteras på sidan av K8s klusternoder (Kubelet).

För det första den sk «tillfälliga behållare» (Efemära behållare), designad för att förenkla felsökningsprocesser i pods. Den nya mekanismen låter dig lansera speciella behållare som börjar i namnutrymmet för befintliga poddar och lever under en kort tid. Deras syfte är att interagera med andra kapslar och behållare för att lösa eventuella problem och felsöka. Ett nytt kommando har implementerats för den här funktionen kubectl debug, liknar i huvudsak kubectl exec: bara istället för att köra en process i en behållare (som i exec) den startar en behållare i en pod. Till exempel kommer detta kommando att ansluta en ny behållare till en pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Detaljer om tillfälliga behållare (och exempel på deras användning) finns i motsvarande KEP. Den nuvarande implementeringen (i K8s 1.16) är en alfaversion, och bland kriterierna för dess överföring till en betaversion är att "testa Ephemeral Containers API för minst 2 versioner av [Kubernetes]."

NB: I sin essens och till och med namnet liknar funktionen ett redan existerande plugin kubectl-debugom vilka vi redan skrivit. Det förväntas att med tillkomsten av tillfälliga behållare kommer utvecklingen av ett separat externt plugin att upphöra.

En annan innovation - PodOverhead - utformad för att ge mekanism för att beräkna omkostnader för kapslar, vilket kan variera mycket beroende på vilken körtid som används. Som ett exempel, författarna denna KEP resultera i Kata Containers, som kräver körning av gästkärnan, kata-agenten, init-systemet, etc. När omkostnaderna blir så stora kan de inte ignoreras, vilket innebär att det måste finnas ett sätt att ta hänsyn till det för ytterligare kvoter, planering etc. Att implementera det i PodSpec fältet har lagts till Overhead *ResourceList (jämför med data i RuntimeClass, om en sådan används).

En annan anmärkningsvärd innovation är nodtopologihanterare (Node Topology Manager), utformad för att förena tillvägagångssättet för att finjustera allokeringen av hårdvaruresurser för olika komponenter i Kubernetes. Detta initiativ drivs av det växande behovet av olika moderna system (från telekommunikation, maskininlärning, finansiella tjänster, etc.) för högpresterande parallellberäkningar och minimera förseningar i utförandet av operationer, för vilka de använder avancerad CPU och hårdvaruaccelerationsmöjligheter. Sådana optimeringar i Kubernetes har hittills uppnåtts tack vare olika komponenter (CPU-hanterare, Enhetshanterare, CNI), och nu kommer de att läggas till ett enda internt gränssnitt som förenar tillvägagångssättet och förenklar anslutningen av nya liknande - så kallad topologi- medveten - komponenter på Kubelet-sidan. Detaljer - in motsvarande KEP.

Topologihanterarens komponentdiagram

Nästa funktion - kontrollera containrar medan de är igång (startsond). För containrar som tar lång tid att lansera är det som bekant svårt att få en uppdaterad status: antingen "dödas" de innan de faktiskt börjar fungera, eller så hamnar de i dödläge under lång tid. Ny kontroll (aktiverad genom funktionsgrind anropad StartupProbeEnabled) avbryter - eller snarare, skjuter upp - effekten av alla andra kontroller tills det ögonblick som podden har slutat köra. Av denna anledning kallades funktionen ursprungligen pod-startup liveness-probe holdoff. För poddar som tar lång tid att starta kan du fråga tillståndet med relativt korta tidsintervall.

Dessutom är en förbättring för RuntimeClass omedelbart tillgänglig i betastatus, och lägger till stöd för "heterogena kluster". C RuntimeClass Schemaläggning Nu är det inte alls nödvändigt för varje nod att ha stöd för varje RuntimeClass: för pods kan du välja en RuntimeClass utan att tänka på klustertopologin. Tidigare, för att uppnå detta - så att pods hamnar på noder med stöd för allt de behöver - var det nödvändigt att tilldela lämpliga regler till NodeSelector och toleranser. I KEP Den talar om exempel på användning och, naturligtvis, implementeringsdetaljer.

Сеть

Två viktiga nätverksfunktioner som dök upp för första gången (i alfaversion) i Kubernetes 1.16 är:

Support dubbel nätverksstack - IPv4/IPv6 - och dess motsvarande "förståelse" på nivån för pods, noder, tjänster. Det inkluderar IPv4-till-IPv4 och IPv6-till-IPv6-kompatibilitet mellan poddar, från poddar till externa tjänster, referensimplementeringar (inom Bridge CNI, PTP CNI och Host-Local IPAM-plugins), samt omvänd kompatibel med Kubernetes-kluster som körs Endast IPv4 eller IPv6. Implementeringsdetaljer finns KEP.
Ett exempel på att visa IP-adresser av två typer (IPv4 och IPv6) i listan över pods:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nytt API för Endpoint - EndpointSlice API. Det löser prestanda/skalbarhetsproblemen för det befintliga Endpoint API som påverkar olika komponenter i kontrollplanet (apiserver, etcd, endpoints-controller, kube-proxy). Det nya API:et kommer att läggas till Discovery API-gruppen och kommer att kunna betjäna tiotusentals backend-slutpunkter på varje tjänst i ett kluster som består av tusentals noder. För att göra detta mappas varje tjänst till N objekt EndpointSlice, som var och en som standard inte har fler än 100 slutpunkter (värdet är konfigurerbart). EndpointSlice API kommer också att ge möjligheter för dess framtida utveckling: stöd för flera IP-adresser för varje pod, nya tillstånd för slutpunkter (inte bara Ready и NotReady), dynamisk underinställning för slutpunkter.

Den som presenterades i den senaste versionen har nått betaversionen slutbehandlare, som heter service.kubernetes.io/load-balancer-cleanup och bifogas varje tjänst med typ LoadBalancer. Vid tidpunkten för borttagning av en sådan tjänst förhindrar den den faktiska raderingen av resursen tills "rensningen" av alla relevanta balanseringsresurser är klar.

API-maskiner

Den verkliga "stabiliseringsmilstolpen" är i området för Kubernetes API-server och interaktion med den. Detta skedde till stor del tack vare överföra till stabil status de som inte behöver särskild introduktion CustomResourceDefinitions (CRD), som har haft betastatus sedan de avlägsna dagarna av Kubernetes 1.7 (och detta är juni 2017!). Samma stabilisering kom till de relaterade funktionerna:

"underresurser" med /status и /scale för CustomResources;
transformation versioner för CRD, baserade på extern webhook;
nyligen presenterat (i K8s 1.15) standardvärden (standard) och automatisk fältborttagning (beskärning) för CustomResources;
möjlighet använder OpenAPI v3-schemat för att skapa och publicera OpenAPI-dokumentation som används för att validera CRD-resurser på serversidan.

En annan mekanism som länge har blivit bekant för Kubernetes-administratörer: antagning webhook - förblev också i betastatus under lång tid (sedan K8s 1.9) och är nu deklarerad stabil.

Två andra funktioner har nått beta: gäller på serversidan и titta på bokmärken.

Och den enda betydande innovationen i alfaversionen var misslyckande från SelfLink — en speciell URI som representerar det angivna objektet och som ingår i ObjectMeta и ListMeta (dvs en del av ett objekt i Kubernetes). Varför överger de det? Motivation på ett enkelt sätt ljud som frånvaron av verkliga (överväldigande) skäl till att detta område fortfarande existerar. Mer formella skäl är att optimera prestanda (genom att ta bort ett onödigt fält) och att förenkla arbetet för den generiska apiservern, som tvingas hantera ett sådant fält på ett speciellt sätt (detta är det enda fältet som är satt precis före objektet är serialiserad). Verklig inkurans (inom beta) SelfLink kommer att ske av Kubernetes version 1.20 och final - 1.21.

Datalagring

Huvudarbetet inom lagringsområdet, som i tidigare utgåvor, observeras i området CSI-stöd. De viktigaste förändringarna här var:

för första gången (i alfaversion) dök Stöd för CSI-plugin för Windows-arbetsnoder: det nuvarande sättet att arbeta med lagring kommer också att ersätta in-tree plugins i Kubernetes kärna och FlexVolume plugins från Microsoft baserade på Powershell;

Schema för implementering av CSI-plugins i Kubernetes för Windows
möjlighet ändra storlek på CSI-volymer, som introducerades tillbaka i K8s 1.12, har vuxit till en betaversion;
En liknande "kampanj" (från alfa till beta) uppnåddes genom möjligheten att använda CSI för att skapa lokala tillfälliga volymer (CSI Inline volymstöd).

Introducerades i den tidigare versionen av Kubernetes volymkloningsfunktion (med befintlig PVC som DataSource att skapa ny PVC) har också nu fått betastatus.

Schemaläggare

Två anmärkningsvärda ändringar av schemaläggning (båda i alfa):

EvenPodsSpreading - möjlighet använd pods istället för logiska applikationsenheter för "rättvis fördelning" av laster (som Deployment och ReplicaSet) och justera denna distribution (som ett hårt krav eller som ett mjukt tillstånd, d.v.s. prioritet). Funktionen kommer att utöka de befintliga distributionsmöjligheterna för planerade pods, för närvarande begränsade av alternativ PodAffinity и PodAntiAffinity, vilket ger administratörer bättre kontroll i denna fråga, vilket innebär bättre hög tillgänglighet och optimerad resursförbrukning. Detaljer - in KEP.
Använd BestFit Policy в RequestedToCapacityRatio Priority Function under kapselplaneringen, vilket kommer att tillåta ansöka soptunna packning ("packa i behållare") för både basresurser (processor, minne) och utökade (som GPU). För mer information, se KEP.

Schemaläggning av pods: innan du använder policyn för bästa passform (direkt via standardschemaläggaren) och med dess användning (via schemaläggarens förlängare)

Dessutom, presenteras möjligheten att skapa dina egna schemaläggarplugins utanför Kubernetes huvudutvecklingsträd (utanför trädet).

Andra förändringar

Även i Kubernetes 1.16-utgåvan kan det noteras initiativ till föra tillgängliga mätvärden i full ordning, eller närmare bestämt i enlighet med officiella föreskrifter till K8s instrumentering. De förlitar sig till stor del på motsvarande Prometheus dokumentation. Inkonsekvenser uppstod av olika anledningar (till exempel skapades vissa mätvärden helt enkelt innan de nuvarande instruktionerna dök upp), och utvecklarna bestämde att det var dags att föra allt till en enda standard, "i linje med resten av Prometheus ekosystem." Den nuvarande implementeringen av detta initiativ är i alfastatus, som successivt kommer att främjas i efterföljande versioner av Kubernetes till beta (1.17) och stabil (1.18).

Dessutom kan följande ändringar noteras:

Windows stöder utveckling с utseende Kubeadm-verktyg för detta operativsystem (alfaversion), möjlighet RunAsUserName för Windows-behållare (alfaversion), förbättring Group Managed Service Account (gMSA) stöd upp till betaversion, Stöd montera/fästa för vSphere-volymer.
Återvunnet datakomprimeringsmekanism i API-svar. Tidigare användes ett HTTP-filter för dessa ändamål, vilket införde ett antal begränsningar som förhindrade att det aktiverades som standard. "Transparent request compression" fungerar nu: klienter skickar Accept-Encoding: gzip i rubriken får de ett GZIP-komprimerat svar om dess storlek överstiger 128 KB. Go-klienter stöder automatiskt komprimering (sänder den nödvändiga rubriken), så de kommer omedelbart att märka en minskning av trafiken. (Små modifieringar kan behövas för andra språk.)
Blev möjligt skala HPA från/till noll pods baserat på externa mätvärden. Om du skalar baserat på objekt/externa mätvärden kan du automatiskt skala till 0 repliker när arbetsbelastningar är inaktiva för att spara resurser. Den här funktionen bör vara särskilt användbar för fall där arbetare begär GPU-resurser och antalet olika typer av lediga arbetare överstiger antalet tillgängliga GPU:er.
Ny kund - k8s.io/client-go/metadata.Client — för "generaliserad" åtkomst till objekt. Den är utformad för att enkelt hämta metadata (dvs. underavsnitt metadata) från klusterresurser och utföra sophämtning och kvotering med dem.
Bygg Kubernetes nu kan du utan äldre (”inbyggda” i trädet) molnleverantörer (alfaversion).
Till kubeadm-verktyget Lagt till experimentell (alfaversion) förmåga att applicera anpassade patchar under operationer init, join и upgrade. Läs mer om hur du använder flaggan --experimental-kustomize, se i KEP.
Ny slutpunkt för apiserver - readyz, - låter dig exportera information om dess beredskap. API-servern har nu också en flagga --maximum-startup-sequence-duration, så att du kan reglera omstarterna.
Två funktioner för Azure förklarat stabil: stöd tillgänglighetszoner (Tillgänglighetszoner) och tvärresursgrupp (RG). Dessutom har Azure lagt till:
- autentiseringsstöd AAD och ADFS;
- abstrakt service.beta.kubernetes.io/azure-pip-name för att specificera den offentliga IP-adressen för lastbalanseraren;
- möjlighet настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS har nu stöd för EBS på Windows och optimerad EC2 API-anrop DescribeInstances.
Kubeadm är nu oberoende migrerar CoreDNS-konfiguration vid uppgradering av CoreDNS-versionen.
Binärer ETCD i motsvarande Docker-bild har gjort world-executable, som låter dig köra den här bilden utan att behöva roträttigheter. Även etcd-migreringsbild upphört etcd2 versionsstöd.
В Cluster Autoscaler 1.16.0 bytte till att använda distroless som basbild, förbättrad prestanda, lagt till nya molnleverantörer (DigitalOcean, Magnum, Packet).
Uppdateringar i använd/beroende programvara: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Läs även på vår blogg:

Källa: will.com

Kubernetes 1.16: översikt över de viktigaste innovationerna