🥇Kubernetes 1.16: oversigt over de vigtigste innovationer

I dag, onsdag, finder sted næste udgivelse af Kubernetes - 1.16. Ifølge traditionen, der har udviklet sig for vores blog, er det ti års jubilæum, hvor vi taler om de mest markante ændringer i den nye version.

Oplysninger brugt til at udarbejde dette materiale er taget fra Sporingstabeller for Kubernetes-forbedringer, ÆNDRINGSLOG-1.16 og relaterede problemer, pull-anmodninger og Kubernetes Enhancement Proposals (KEP). Så lad os gå!..

Knuder

Et virkeligt stort antal bemærkelsesværdige innovationer (i alfa-version status) præsenteres på siden af K8s klynge noder (Kubelet).

For det første den såkaldte «flygtige beholdere» (Efemere containere), designet til at forenkle fejlfindingsprocesser i pods. Den nye mekanisme giver dig mulighed for at lancere specielle beholdere, der starter i navnerummet for eksisterende pods og lever i kort tid. Deres formål er at interagere med andre pods og beholdere for at løse eventuelle problemer og fejlfinde. En ny kommando er blevet implementeret til denne funktion kubectl debug, som i det væsentlige ligner kubectl exec: kun i stedet for at køre en proces i en container (som i exec) den lancerer en beholder i en pod. For eksempel vil denne kommando forbinde en ny beholder til en pod:

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

Detaljer om flygtige beholdere (og eksempler på deres brug) kan findes i tilsvarende KEP. Den nuværende implementering (i K8s 1.16) er en alfaversion, og blandt kriterierne for dens overførsel til en betaversion er "at teste Ephemeral Containers API for mindst 2 udgivelser af [Kubernetes]."

NB: I sin essens og endda sit navn, ligner funktionen et allerede eksisterende plugin kubectl-debugom hvilket vi allerede skrevet. Det forventes, at udviklingen af et separat eksternt plugin vil ophøre med fremkomsten af flygtige beholdere.

Endnu en nyskabelse - PodOverhead - designet til at give mekanisme til beregning af overheadomkostninger for pods, som kan variere meget afhængigt af den anvendte køretid. For eksempel forfatterne denne KEP resultere i Kata Containers, som kræver at køre gæstekernen, kata-agenten, init-systemet osv. Når overhead bliver så stort, kan det ikke ignoreres, hvilket betyder, at der skal være en måde at tage højde for det for yderligere kvoter, planlægning osv. At implementere det i PodSpec felt tilføjet Overhead *ResourceList (sammenligner med data i RuntimeClass, hvis en bruges).

En anden bemærkelsesværdig innovation er node topologi manager (Node Topology Manager), designet til at forene tilgangen til finjustering af allokeringen af hardwareressourcer til forskellige komponenter i Kubernetes. Dette initiativ er drevet af det voksende behov for forskellige moderne systemer (fra telekommunikation, maskinlæring, finansielle tjenester osv.) for højtydende parallel computing og minimering af forsinkelser i udførelsen af operationer, hvortil de bruger avanceret CPU og hardwareaccelerationsmuligheder. Sådanne optimeringer i Kubernetes er indtil videre blevet opnået takket være forskellige komponenter (CPU-manager, Device Manager, CNI), og nu vil de blive tilføjet en enkelt intern grænseflade, der forener tilgangen og forenkler tilslutningen af nye lignende - såkaldt topologi- opmærksom - komponenter på Kubelet-siden. Detaljer - in tilsvarende KEP.

Topology Manager komponentdiagram

Næste funktion - kontrollere containere, mens de kører (opstartssonde). Som bekendt er det for containere, der tager lang tid at lancere, svært at få en opdateret status: De bliver enten "dræbt", før de rent faktisk begynder at fungere, eller også ender de i dødvande i lang tid. Ny check (aktiveret via feature gate kaldet StartupProbeEnabled) annullerer - eller rettere, udsætter - effekten af andre kontroller, indtil det øjeblik, hvor poden er færdig med at køre. Af denne grund blev funktionen oprindeligt kaldt pod-startup liveness-probe holdoff. For pods, der tager lang tid at starte, kan du polle tilstanden i relativt korte tidsintervaller.

Derudover er en forbedring af RuntimeClass umiddelbart tilgængelig i beta-status, der tilføjer understøttelse af "heterogene klynger". C RuntimeClass-planlægning Nu er det slet ikke nødvendigt for hver node at have support for hver RuntimeClass: for pods kan du vælge en RuntimeClass uden at tænke på klyngetopologien. Tidligere var det nødvendigt at tildele passende regler til NodeSelector og tolerationer for at opnå dette - så pods ender på noder med støtte til alt, hvad de har brug for. I KEP Den taler om eksempler på brug og selvfølgelig implementeringsdetaljer.

netværk

To væsentlige netværksfunktioner, der dukkede op for første gang (i alfaversion) i Kubernetes 1.16 er:

Support dobbelt netværksstak - IPv4/IPv6 - og dens tilsvarende "forståelse" på niveau med pods, noder, tjenester. Det inkluderer IPv4-til-IPv4 og IPv6-til-IPv6 interoperabilitet mellem pods, fra pods til eksterne tjenester, referenceimplementeringer (inden for Bridge CNI, PTP CNI og Host-Local IPAM plugins), samt omvendt kompatibel med Kubernetes-klynger, der kører Kun IPv4 eller IPv6. Implementeringsdetaljer er inde KEP.
Et eksempel på visning af IP-adresser af to typer (IPv4 og IPv6) på listen over 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#
```
Ny API til Endpoint — EndpointSlice API. Det løser problemer med ydeevne/skalerbarhed af den eksisterende Endpoint API, der påvirker forskellige komponenter i kontrolplanet (apiserver, etcd, endpoints-controller, kube-proxy). Den nye API vil blive føjet til Discovery API-gruppen og vil være i stand til at betjene titusindvis af backend-endepunkter på hver tjeneste i en klynge bestående af tusindvis af noder. For at gøre dette, er hver tjeneste knyttet til N objekter EndpointSlice, som hver som standard ikke har mere end 100 slutpunkter (værdien kan konfigureres). EndpointSlice API vil også give muligheder for dets fremtidige udvikling: understøttelse af flere IP-adresser for hver pod, nye tilstande for slutpunkter (ikke kun Ready и NotReady), dynamisk underindstilling for endepunkter.

Den, der blev præsenteret i den sidste udgivelse, har nået betaversionen afslutter, som hedder service.kubernetes.io/load-balancer-cleanup og knyttet til hver tjeneste med type LoadBalancer. På tidspunktet for sletning af en sådan tjeneste forhindrer den den faktiske sletning af ressourcen, indtil "oprydningen" af alle relevante balanceringsressourcer er fuldført.

API maskiner

Den virkelige "stabiliseringsmilepæl" er i området for Kubernetes API-serveren og interaktion med den. Dette skete i høj grad takket være overførsel til stabil status af dem, der ikke har behov for særlig introduktion CustomResourceDefinitions (CRD), som har haft beta-status siden de fjerne dage af Kubernetes 1.7 (og det er juni 2017!). Den samme stabilisering kom til de relaterede funktioner:

"underressourcer" med /status и /scale til CustomResources;
transformation versioner til CRD, baseret på ekstern webhook;
for nylig præsenteret (i K8s 1.15) standardværdier (standard) og automatisk feltfjernelse (beskæring) til CustomResources;
lejlighed bruge OpenAPI v3-skemaet til at oprette og udgive OpenAPI-dokumentation, der bruges til at validere CRD-ressourcer på serversiden.

En anden mekanisme, der længe er blevet bekendt for Kubernetes-administratorer: optagelse webhook - forblev også i beta-status i lang tid (siden K8s 1.9) og er nu erklæret stabil.

To andre funktioner er nået til beta: server-side gælder и se bogmærker.

Og den eneste væsentlige nyskabelse i alfaversionen var fiasko fra SelfLink — en speciel URI, der repræsenterer det specificerede objekt og er en del af ObjectMeta и ListMeta (dvs. en del af ethvert objekt i Kubernetes). Hvorfor opgiver de det? Motivation på en enkel måde lyder som fraværet af reelle (overvældende) grunde til, at dette felt stadig eksisterer. Mere formelle grunde er at optimere ydeevnen (ved at fjerne et unødvendigt felt) og for at forenkle arbejdet for den generiske apiserver, som er tvunget til at håndtere et sådant felt på en særlig måde (dette er det eneste felt, der er sat lige før objektet er serialiseret). Ægte forældelse (inden for beta) SelfLink vil ske ved Kubernetes version 1.20, og endelig - 1.21.

Data opbevaring

Hovedarbejdet inden for opbevaringsområdet, som i tidligere udgivelser, observeres i området CSI support. De vigtigste ændringer her var:

for første gang (i alfaversion) optrådte CSI-plugin-understøttelse til Windows-arbejdernoder: den nuværende måde at arbejde med storage på vil også erstatte in-tree plugins i Kubernetes kerne og FlexVolume plugins fra Microsoft baseret på Powershell;

Skema til implementering af CSI-plugins i Kubernetes til Windows
lejlighed ændre størrelse på CSI-volumener, introduceret tilbage i K8s 1.12, er vokset til en betaversion;
En lignende "promovering" (fra alfa til beta) blev opnået ved evnen til at bruge CSI til at skabe lokale flygtige volumener (CSI Inline Volume Support).

Introduceret i den tidligere version af Kubernetes volumenkloningsfunktion (ved at bruge eksisterende PVC som DataSource at skabe ny PVC) har også nu fået betastatus.

Planlægger

To bemærkelsesværdige ændringer til planlægning (begge i alfa):

EvenPodsSpreading - lejlighed brug pods i stedet for logiske applikationsenheder til "fair fordeling" af belastninger (som Deployment og ReplicaSet) og justering af denne fordeling (som et hårdt krav eller som en blød tilstand, dvs. prioritet). Funktionen vil udvide de eksisterende distributionsmuligheder for planlagte pods, som i øjeblikket er begrænset af muligheder PodAffinity и PodAntiAffinity, hvilket giver administratorer bedre kontrol i denne sag, hvilket betyder bedre høj tilgængelighed og optimeret ressourceforbrug. Detaljer - in KEP.
Brug BestFit politik в RequestedToCapacity Ratio Priority Function under pod-planlægning, hvilket vil tillade anvende skraldespandspakning ("pakning i containere") for både grundlæggende ressourcer (processor, hukommelse) og udvidede (som GPU). For flere detaljer, se KEP.

Planlægning af pods: før brug af best fit-politik (direkte via standardplanlægning) og med dens brug (via planlægningsforlænger)

Desuden fremlagde muligheden for at oprette dine egne planlægnings-plugins uden for Kubernetes hovedudviklingstræ (uden for træet).

Andre ændringer

Også i Kubernetes 1.16-udgivelsen kan det bemærkes initiativ til bringe tilgængelige metrics i fuld rækkefølge, eller mere præcist i overensstemmelse med officielle forskrifter til K8s instrumentering. De stoler i høj grad på det tilsvarende Prometheus dokumentation. Uoverensstemmelser opstod af forskellige årsager (for eksempel blev nogle målinger simpelthen oprettet, før de nuværende instruktioner dukkede op), og udviklerne besluttede, at det var på tide at bringe alt til en enkelt standard, "i overensstemmelse med resten af Prometheus-økosystemet." Den nuværende implementering af dette initiativ er i alfa-status, som gradvist vil blive fremmet i efterfølgende versioner af Kubernetes til beta (1.17) og stabil (1.18).

Derudover kan følgende ændringer bemærkes:

Windows understøtter udvikling с udseende Kubeadm-værktøjer til dette OS (alfaversion), lejlighed RunAsUserName til Windows-containere (alfaversion), forbedring Group Managed Service Account (gMSA) support op til betaversion, support montere/vedhæfte til vSphere-volumener.
Genanvendt datakomprimeringsmekanisme i API-svar. Tidligere blev et HTTP-filter brugt til disse formål, som pålagde en række begrænsninger, der forhindrede det i at blive aktiveret som standard. "Transparent anmodningskomprimering" virker nu: klienter sender Accept-Encoding: gzip i headeren modtager de et GZIP-komprimeret svar, hvis dets størrelse overstiger 128 KB. Go-klienter understøtter automatisk komprimering (sender den nødvendige header), så de vil straks bemærke en reduktion i trafikken. (Små ændringer kan være nødvendige for andre sprog.)
Blev muligt skalering af HPA fra/til nul pods baseret på eksterne metrikker. Hvis du skalerer baseret på objekter/eksterne metrikker, kan du automatisk skalere til 0 replikaer, når arbejdsbelastninger er inaktive, for at spare ressourcer. Denne funktion bør især være nyttig i tilfælde, hvor arbejdere anmoder om GPU-ressourcer, og antallet af forskellige typer ledige arbejdere overstiger antallet af tilgængelige GPU'er.
Ny kunde - k8s.io/client-go/metadata.Client — for "generaliseret" adgang til objekter. Det er designet til nemt at hente metadata (dvs. underafsnit metadata) fra klyngressourcer og udføre affaldsindsamling og kvoteoperationer med dem.
Byg Kubernetes nu kan du uden ældre (“indbygget” in-tree) cloud-udbydere (alfaversion).
Til kubeadm-værktøjet tilføjet eksperimentel (alfaversion) evne til at anvende tilpassede patches under operationer init, join и upgrade. Lær mere om, hvordan du bruger flaget --experimental-kustomize, se i KEP.
Nyt slutpunkt til apiserver - readyz, - giver dig mulighed for at eksportere information om dens beredskab. API-serveren har nu også et flag --maximum-startup-sequence-duration, så du kan regulere dens genstarter.
to funktioner til Azure erklæret stabil: støtte tilgængelighedszoner (Tilgængelighedszoner) og tværgående ressourcegruppe (RG). Derudover har Azure tilføjet:
- autentificeringsstøtte AAD og ADFS;
- abstrakt service.beta.kubernetes.io/azure-pip-name at specificere den offentlige IP for belastningsbalanceren;
- lejlighed настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS har nu støtte til EBS på Windows og optimeret EC2 API-kald DescribeInstances.
Kubeadm er nu uafhængig migrerer CoreDNS-konfiguration ved opgradering af CoreDNS-versionen.
Binære osv i det tilsvarende Docker-billede har gjort world-executable, som giver dig mulighed for at køre dette billede uden behov for root-rettigheder. Også, etcd migration billede ophørt etcd2 version support.
В Cluster Autoscaler 1.16.0 skiftet til at bruge distroless som basisbillede, forbedret ydeevne, tilføjet nye cloud-udbydere (DigitalOcean, Magnum, Packet).
Opdateringer i brugt/afhængig software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Læs også på vores blog:

Kilde: www.habr.com

Kubernetes 1.16: Højdepunkter i det nye