🥇Kubernetes 1.16: översikt över huvudnyheterna

Idag, onsdag, ska en ny version av Kubernetes — 1.16. I enlighet med traditionen för vår blogg berättar vi, för tionde gången — vårt jubileum — om de mest betydelsefulla förändringarna i den nya versionen.

Informationen som användes för att förbereda detta material har tagits från tabellen för spårning av förbättringar i Kubernetes, CHANGELOG-1.16 och relevanta ärenden, pull requests samt Kubernetes Enhancement Proposals (KEP). Så låt oss börja! ..

Noder

Ett verkligt stort antal märkbara nyheter (i alfa-version) presenteras på nodsidan av K8s-kluster (Kubelet).

Först och främst introduceras de så kallade «efemära containrar» (Ephemeral Containers), som syftar till att förenkla felsökningsprocesser i poddar. Den nya mekanismen gör det möjligt att starta speciella containrar som körs i namnområdet för befintliga poddar och lever under en kort tid. Deras syfte är att interagera med andra poddar och containrar för att lösa problem och felsöka. För denna funktion har ett nytt kommando implementerats kubectl debug, som liknar kubectl exec: men istället för att starta en process i containern (som i fallet med exec) startar det en container i podden. Till exempel, detta kommando skulle koppla en ny container till podden:

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

Detaljer om de efemära containrarna (och exempel på deras användning) finns i den relevanta KEP. Den nuvarande implementeringen (i K8s 1.16) är i alfa-version, och bland kriterierna för att gå över till beta-version anges "testning av Ephemeral Containers API i minst 2 releaser [Kubernetes]".

NB: I sin kärna och till och med i namnet påminner funktionen om den redan existerande pluginen kubectl-debug, om vilken vi redan skrivit. Det förutses att utvecklingen av den separata externa pluginen kommer att upphöra med införandet av de efemära containrarna.

En annan innovation — PodOverhead — syftar till att tillhandahålla ett mekanism för att räkna overheadkostnader för poddar, som kan skilja sig avsevärt beroende på den använda körmiljön (runtime). Som exempel tar författarna denna KEP framhåller Kata Containers, vilka kräver att starta ett värdkärna, kata-agent, init-system etc. När overhead blir så stort kan det inte ignoreras, vilket innebär att ett sätt att ta hänsyn till det för framtida kvotering, planering etc. behövs. För att implementera detta har PodSpec fått ett fält Overhead *ResourceList (matchas med data i RuntimeClass, om sådana används).

En annan märkbar nyhet är nodtopologihanteraren (Node Topology Manager), som syftar till att enhetliggöra tillvägagångssättet för finjustering av tilldelning av hårdvaruresurser för olika komponenter i Kubernetes. Denna initiativ har uppkommit på grund av det växande behovet hos olika moderna system (från telekommunikation, maskininlärning, finanstjänster osv.) av högpresterande parallellberäkningar och att minimera latens vid utförande av operationer, där de använder avancerade funktioner hos CPU och hårdvaruacceleration. Sådana optimeringar i Kubernetes har hittills uppnåtts genom olika komponenter (CPU manager, Device manager, CNI), och nu tillkommer en enhetlig intern gränssnitt som enhetliggör tillvägagångssättet och förenklar anslutningen av nya liknande — så kallade topology-aware — komponenter på Kubelet-sidan. Mer information finns i den relevanta KEP.

Topologihanterarens komponentdiagram

Nästa funktion är kontroll av behållare vid start (startup probe). Det är känt att för behållare som tar lång tid att starta är det svårt att få aktuell status: de antingen "dödas" innan de verkligen börjar fungera, eller så fastnar de i deadlock under lång tid. Den nya kontrollen (aktiveras via en feature gate kallad StartupProbeEnabled) avbryter — eller snarare skjuter upp — effekten av andra kontroller tills podden har avslutat sin uppstart. Av denna anledning kallades funktionen ursprungligen pod-startup liveness-probe holdoff. För poddar som startar långsamt kan statusfrågor göras med relativt korta tidsintervall.

Dessutom presenteras en förbättring för RuntimeClass direkt i beta-status, som lägger till stöd för "heterogena kluster". Med RuntimeClass Scheduling är det nu inte längre nödvändigt att varje nod har stöd för varje RuntimeClass: för poddar kan RuntimeClass väljas utan att tänka på klustrets topologi. Tidigare krävdes det att motsvarande regler angavs i NodeSelector och tolerations för att säkerställa att poddar placerades på noder med fullt stöd för vad de behöver. I KEP beskrivs exempel på användning och självklart detaljerna kring implementeringen.

Nätverk

Två betydande nätverksfunktioner som först dök upp (i alpha-versionen) i Kubernetes 1.16 är:

Support dubbel nätverksstack — IPv4/IPv6 — och den motsvarande "förståelsen" på pod-, nod- och tjänstenivå. Detta inkluderar IPv4-till-IPv4 och IPv6-till-IPv6 interaktion mellan poddar, från poddar till externa tjänster, referensimplementationer (inom ramarna för Bridge CNI, PTP CNI och Host-Local IPAM), samt bakåtkompatibilitet med Kubernetes-kluster som enbart använder IPv4 eller IPv6. Detaljer om implementationen finns i KEP.
Exempel på IP-adresser av två typer (IPv4 och IPv6) i en lista med poddar:
```
kube-master# kubectl get pods -o wide
NAMN               KLAR     STATUS     ÅTERSTARTADE   ÅLDER       IP                           NOD
nginx-controller   1/1       Kör        0             20m        fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Ny API för Endpoint — EndpointSlice API. Det löser prestanda-/skaleringsproblem med den befintliga Endpoint API, som påverkar olika komponenter i control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Den nya API:n kommer att läggas till API-gruppen Discovery och kan hantera tiotusentals backend-endpointar på varje tjänst i ett kluster med tusentals noder. För detta kommer varje Service att översättas till N objekt EndpointSlice, där varje normalt har högst 100 endpointar (detta värde är konfigurerbart). I EndpointSlice API:n kommer det även att finnas möjligheter för framtida utveckling: stöd för flera IP-adresser per pod, nya tillstånd för endpointar (inte bara Redo och NotReady), dynamisk delmängdning för endpointar.

Framsteg har gjorts till beta-versionen av den som presenterades i den senaste utgåvan finalizer, kallad service.kubernetes.io/load-balancer-cleanup och kopplad till varje tjänst av typen LoadBalancer. Vid borttagning av en sådan tjänst förhindrar den faktiskt borttagning av resursen tills "städningen" av alla relevanta lastbalanserarresurser är slutförd.

API Machinery

Den verkliga "stabiliseringens milstolpe" har registrerats inom Kubernetes API-server och dess interaktion. Mycket av detta har skett tack vare övergången till stabil status för de som inte kräver särskild representation CustomResourceDefinitions (CRD), som haft beta-status sedan långt tillbaka, Kubernetes 1.7 (det vill säga juni 2017!). Samma stabilisering har också kommit till de relaterade funktionerna:

"subresources" med /status och /scale för CustomResources;
konvertering versioner för CRD, baserat på en extern webhook;
nyligen presenterade (i K8s 1.15) standardvärden (defaulting) och automatisk borttagning av fält (pruning) för CustomResources;
att tillämpning av OpenAPI v3-schema för skapande och publicering av OpenAPI-dokumentation, som används för validering av CRD-resurser på serversidan.

Ytterligare en mekanism som länge har blivit vanligt för Kubernetes-administratörer: admission webhook — har också länge haft beta-status (sedan K8s 1.9) och är nu officiellt stabil.

Två andra funktioner har nått beta-version: server-side apply och watch bookmarks.

Och den enda betydande nyheten i alpha-versionen var avskaffande från SelfLink — en speciell URI som representerar det angivna objektet och är en del av ObjectMeta och ListMeta (dvs. en del av varje objekt i Kubernetes). Varför avskaffas det? Motivationen ‘i enkelhet’ låter som att det saknas verkliga (oöverkomliga) anledningar för att detta fält fortfarande ska existera. Mer formella anledningar är att optimera prestandan (genom att ta bort onödigt fält) och förenkla arbetet för generic-apiserver, som är tvungen att hantera ett sådant fält på särskilt sätt (detta är det enda fält som sätts precis innan objektet serialiseras). Den verkliga ‘avskrivningen’ (inom beta-versionen) SelfLink kommer att ske med Kubernetes version 1.20, och den slutgiltiga — 1.21.

Databevarande

Det huvudsakliga arbetet inom lagring, precis som i tidigare versioner, observeras inom stöd för CSI. De viktigaste förändringarna här har varit:

för första gången (i alpha-versionen) har det tillkommit stöd för CSI-pluginer för arbetsnoder med Windows: en aktuell metod för att arbeta med lagringslösningar som kommer att ersätta in-tree-pluginer i kärnan av Kubernetes och FlexVolume-pluginer från Microsoft baserat på Powershell;

Schema för implementation av CSI-pluginer i Kubernetes för Windows
att ändring av storlek på CSI-volymer, presenterat i K8s 1.12, har nått beta-version;
en liknande ‘uppgradering’ (från alpha- till beta-version) har också uppnåtts med möjligheten att använda CSI för att skapa lokala temporära volymer (CSI Inline Volume Support).

Funktionen för volymkloning som dök upp i föregående version av Kubernetes (användning av befintliga PVC som DataSource för att skapa nya PVC) har också nu fått beta-status.

Schemaläggare

Två märkbara förändringar i schemaläggningen (båda i alpha-version):

EvenPodsSpreading — möjligheten att använda pods för ‘rättvis fördelning’ av belastningar istället för logiska enheter av applikationen (såsom Deployment och ReplicaSet) och justeringen av denna fördelning (som ett strikt krav eller som en mjuk förutsättning, dvs. prioritet). Denna funktion kommer att utöka de befintliga fördelningsmöjligheterna för schemalagda pods, som nu är begränsade av alternativen PodAffinity och PodAntiAffinity, vilket ger administratörer mer finjusterad kontroll över detta område, vilket i sin tur ger bättre tillgänglighet och optimerad resursanvändning. Mer information finns i KEP.
Användning BestFit Policy på RequestedToCapacityRatio Priority Function vid planering av poddar, vilket gör det möjligt att tillämpa bin packing ("container packing") både för grundläggande resurser (processor, minne) och för utökade resurser (som GPU). Mer information finns i KEP.

Planering av poddar: före användning av best fit policy (direkt via default scheduler) och med dess användning (genom scheduler extender)

Dessutom, presenterades möjligheten att skapa egna plugins för schemaläggaren utanför huvudutvecklingsträdet för Kubernetes (out-of-tree).

Övriga förändringar

Det kan också nämnas i Kubernetes 1.16 initiativet för att ordna de existerande mätvärdena, eller mer exakt — i enlighet med de officiella riktlinjerna som rör instrumentering av K8s. De bygger i huvudsak på motsvarande Prometheus-dokumentation. Inkonsekvenserna har uppstått av olika anledningar (till exempel skapades vissa mätvärden innan aktuella instruktioner fanns), och utvecklarna har beslutat att det är dags att föra allt i linje med en gemensam standard, "i enlighet med resten av Prometheus-ekosystemet". Den aktuella implementeringen av detta initiativ har statuset alfa-version, som successivt kommer att uppgraderas i kommande versioner av Kubernetes till beta (1.17) och stabil (1.18).

Dessutom kan följande förändringar nämnas:

Utveckling av stöd för Windows med genom introduktionen av Kubeadm-verktyget för detta operativsystem (alfa-version), möjligheten RunAsUserName för Windows-containrar (alfa-version), förbättring stöd för Group Managed Service Account (gMSA) till beta-version, stödet mount/attach för vSphere-volymer.
Omstrukturerad mekanism för data komprimering i API-svar. Tidigare användes en HTTP-filter för dessa ändamål, som satte upp vissa begränsningar som hindrade dess aktivering som standard. Nu fungerar "transparent komprimering av förfrågningar": klienter som skickar Accept-Encoding: gzip i rubriken får ett gzip-komprimerat svar om dess storlek överstiger 128 KB. Klienter på Go stöder automatiskt komprimering (skickar rätt rubrik), så de kommer direkt att märka en minskning av trafik. (För andra språk kan små justeringar krävas.)
Det har blivit möjligt att skala HPA upp/ned till noll poddar baserat på externa mätvärden. Om skalning görs på objekt/externa mätvärden kan man automatiskt skala till 0 repliker när arbetslasterna är inaktiva för att spara resurser. Denna funktion bör vara särskilt användbar vid situationer där arbetare begär GPU-resurser och antalet olika typer av inaktiva arbetare överstiger antalet tillgängliga GPU:er.
Ny kund — k8s.io/client-go/metadata.Client — för "generell" åtkomst till objekt. Den är avsedd för att enkelt få tag på metadata (d.v.s. underavdelning metadata) från klusterresurser och utföra operationer såsom skräpinsamling och kvotering.
Kubernetes kan nu användas utan föråldrade ("inbyggda" i tree) molnleverantörer (alpha-version).
I verktyget kubeadm lagt till har den experimentella (alpha-version) möjligheten att applicera kustomize-patchar under operationer init, join och upgrade. Mer information om hur man använder flaggan --experimental-kustomize, finns i KEP.
Ny endpoint för apiserver — readyz, — som tillåter export av information om dess beredskap (readiness). Dessutom har API-servern fått en flagga --maximum-startup-sequence-duration, vilket tillåter att reglera dess omstarter.
Två funktioner för Azure har blivit stabila: stöd för tillgänglighetszoner (Availability Zones) och cross resource group (RG). Dessutom har Azure lagt till:
- stöd för autentisering AAD och ADFS;
- annotering service.beta.kubernetes.io/azure-pip-name för att ange offentlig IP för lastbalanseraren;
- att inställningar LoadBalancerName och LoadBalancerResourceGroup.
AWS har fått stöd för för EBS på Windows och har optimerat API-anrop för EC2 DescribeInstances.
Kubeadm migrerar nu självständigt konfigurationen av CoreDNS vid uppgradering av CoreDNS-versionen. Binärfiler
etcd i den motsvarande Docker-bilden är världsexekverbara, vilket möjliggör körning av denna bild utan behov av root-behörighet. Dessutom har etcd-migrationsbilden gjort slutat stötta versionen etcd2. Cluster Autoscaler 1.16.0
I har övergått till att använda distroless som basbild, förbättrat prestandan och lagt till nya molnleverantörer (DigitalOcean, Magnum, Packet). Uppdateringar i den använda/beroende programvaran: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
Kubernetes 1.15: översikt över huvudnyheterna

P.S.

Läs även i vår blogg:

Källa: habr.com

Kubernetes 1.16: en översikt över de viktigaste nyheterna