🥇Kubernetes 1.16: oversikt over de viktigste nyvinningene

I dag, onsdag, vil finne sted neste utgivelse av Kubernetes - 1.16. I følge tradisjonen som har utviklet seg for bloggen vår, er dette tiårsdagen vi snakker om de viktigste endringene i den nye versjonen.

Informasjon som brukes til å utarbeide dette materialet er hentet fra Sporingstabeller for Kubernetes-forbedringer, ENDRINGSLOGG-1.16 og relaterte problemer, pull-forespørsler og Kubernetes Enhancement Proposals (KEP). Så la oss gå!..

Noder

Et virkelig stort antall bemerkelsesverdige innovasjoner (i alfa-versjonsstatus) presenteres på siden av K8s klyngenoder (Kubelet).

For det første den såkalte «flyktige beholdere» (Efemere beholdere), designet for å forenkle feilsøkingsprosesser i pods. Den nye mekanismen lar deg lansere spesielle beholdere som starter i navnerommet til eksisterende pods og lever i kort tid. Deres formål er å samhandle med andre pods og beholdere for å løse eventuelle problemer og feilsøke. En ny kommando er implementert for denne funksjonen kubectl debug, i hovedsak lik kubectl exec: bare i stedet for å kjøre en prosess i en beholder (som i exec) den lanserer en beholder i en pod. For eksempel vil denne kommandoen koble en ny beholder til en pod:

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

Detaljer om flyktige beholdere (og eksempler på deres bruk) kan finnes i tilsvarende KEP. Den nåværende implementeringen (i K8s 1.16) er en alfaversjon, og blant kriteriene for overføring til en betaversjon er "testing av Ephemeral Containers API for minst 2 utgivelser av [Kubernetes]."

NB: I sin essens og til og med navnet, ligner funksjonen en allerede eksisterende plugin kubectl-debugsom vi allerede skrevet. Det forventes at utviklingen av en separat ekstern plugin vil opphøre med bruken av flyktige beholdere.

En annen innovasjon - PodOverhead - designet for å gi mekanisme for å beregne overheadkostnader for pods, som kan variere mye avhengig av kjøretiden som brukes. Som et eksempel, forfatterne denne KEP resultere i Kata Containers, som krever kjøring av gjestekjernen, kata-agenten, init-systemet osv. Når overhead blir så stort, kan det ikke ignoreres, noe som betyr at det må være en måte å ta hensyn til for videre kvoter, planlegging osv. Å implementere det i PodSpec felt lagt til Overhead *ResourceList (sammenligner med data i RuntimeClass, hvis en brukes).

En annen bemerkelsesverdig innovasjon er node topologi leder (Node Topology Manager), designet for å forene tilnærmingen til å finjustere allokeringen av maskinvareressurser for ulike komponenter i Kubernetes. Dette initiativet er drevet av det økende behovet til ulike moderne systemer (fra telekommunikasjon, maskinlæring, finansielle tjenester, etc.) for høyytelses parallell databehandling og minimalisering av forsinkelser i utførelsen av operasjoner, som de bruker avansert CPU og maskinvareakselerasjonsmuligheter. Slike optimaliseringer i Kubernetes har så langt blitt oppnådd takket være forskjellige komponenter (CPU manager, Device manager, CNI), og nå vil de bli lagt til et enkelt internt grensesnitt som forener tilnærmingen og forenkler tilkoblingen av nye lignende - såkalt topologi- klar over - komponenter på Kubelet-siden. Detaljer - inn tilsvarende KEP.

Komponentdiagram for topologileder

Neste funksjon - sjekke containere mens de kjører (oppstartssonde). Som du vet, for containere som tar lang tid å lansere, er det vanskelig å få en oppdatert status: De blir enten «drept» før de faktisk begynner å fungere, eller så havner de i fastlåst tilstand i lang tid. Ny sjekk (aktivert gjennom funksjonsgate kalt StartupProbeEnabled) kansellerer - eller rettere sagt, utsetter - effekten av andre kontroller til det øyeblikket poden er ferdig å kjøre. Av denne grunn ble funksjonen opprinnelig kalt pod-startup liveness-probe holdoff. For pods som bruker lang tid på å starte, kan du spørre tilstanden i relativt korte tidsintervaller.

I tillegg er en forbedring for RuntimeClass umiddelbart tilgjengelig i betastatus, og legger til støtte for "heterogene klynger". C RuntimeClass-planlegging Nå er det slett ikke nødvendig for hver node å ha støtte for hver RuntimeClass: for pods kan du velge en RuntimeClass uten å tenke på klyngetopologien. Tidligere, for å oppnå dette – slik at pods havner på noder med støtte for alt de trenger – var det nødvendig å tildele passende regler til NodeSelector og tolerasjoner. I KEP Den snakker om eksempler på bruk og selvfølgelig implementeringsdetaljer.

nettverk

To viktige nettverksfunksjoner som dukket opp for første gang (i alfaversjon) i Kubernetes 1.16 er:

Støtte dobbel nettverksstabel - IPv4/IPv6 - og dens tilsvarende "forståelse" på nivået av pods, noder, tjenester. Den inkluderer IPv4-til-IPv4 og IPv6-til-IPv6 interoperabilitet mellom poder, fra poder til eksterne tjenester, referanseimplementeringer (innenfor Bridge CNI, PTP CNI og Host-Local IPAM-plugins), samt omvendt kompatibel med Kubernetes-klynger som kjører Kun IPv4 eller IPv6. Implementeringsdetaljer er inne KEP.
Et eksempel på visning av IP-adresser av to typer (IPv4 og IPv6) i 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 for endepunkt - EndpointSlice API. Den løser ytelses-/skalerbarhetsproblemene til den eksisterende Endpoint API som påvirker ulike komponenter i kontrollplanet (apiserver, etcd, endpoints-controller, kube-proxy). Den nye APIen vil bli lagt til Discovery API-gruppen og vil kunne betjene titusenvis av backend-endepunkter på hver tjeneste i en klynge bestående av tusenvis av noder. For å gjøre dette tilordnes hver tjeneste til N objekter EndpointSlice, som hver som standard ikke har mer enn 100 endepunkter (verdien kan konfigureres). EndpointSlice API vil også gi muligheter for fremtidig utvikling: støtte for flere IP-adresser for hver pod, nye tilstander for endepunkter (ikke bare Ready и NotReady), dynamisk underinnstilling for endepunkter.

Den som ble presentert i den siste utgivelsen har nådd betaversjonen sluttbehandler, navngitt service.kubernetes.io/load-balancer-cleanup og knyttet til hver tjeneste med type LoadBalancer. På tidspunktet for sletting av en slik tjeneste, forhindrer den faktisk sletting av ressursen inntil "oppryddingen" av alle relevante balanseringsressurser er fullført.

API-maskineri

Den virkelige "stabiliseringsmilepælen" er i området til Kubernetes API-serveren og interaksjon med den. Dette skjedde i stor grad takket være overføre til stabil status de som ikke trenger spesiell introduksjon CustomResourceDefinitions (CRD), som har hatt betastatus siden de fjerne dagene av Kubernetes 1.7 (og dette er juni 2017!). Den samme stabiliseringen kom til de relaterte funksjonene:

"underressurser" med /status и /scale for CustomResources;
transformasjon versjoner for CRD, basert på ekstern webhook;
nylig presentert (i K8s 1.15) standardverdier (standard) og automatisk feltfjerning (beskjæring) for CustomResources;
mulighet bruke OpenAPI v3-skjemaet til å lage og publisere OpenAPI-dokumentasjon som brukes til å validere CRD-ressurser på serversiden.

En annen mekanisme som lenge har blitt kjent for Kubernetes-administratorer: opptakswebhook - har også vært i betastatus i lang tid (siden K8s 1.9) og er nå erklært stabil.

To andre funksjoner har nådd beta: gjelder på serversiden и se bokmerker.

Og den eneste vesentlige nyvinningen i alfaversjonen var svikt fra SelfLink — en spesiell URI som representerer det spesifiserte objektet og er en del av ObjectMeta и ListMeta (dvs. en del av ethvert objekt i Kubernetes). Hvorfor forlater de det? Motivasjon på en enkel måte lyder som fraværet av reelle (overveldende) grunner til at dette feltet fortsatt eksisterer. Mer formelle grunner er å optimere ytelsen (ved å fjerne et unødvendig felt) og for å forenkle arbeidet til den generiske apiserveren, som er tvunget til å håndtere et slikt felt på en spesiell måte (dette er det eneste feltet som er satt rett før objektet er serialisert). Ekte foreldelse (innen beta) SelfLink vil skje av Kubernetes versjon 1.20, og endelig - 1.21.

Datalagring

Hovedarbeidet i lagringsområdet, som i tidligere utgivelser, er observert i området CSI-støtte. De viktigste endringene her var:

for første gang (i alfaversjon) dukket opp CSI-plugin-støtte for Windows-arbeidernoder: den nåværende måten å jobbe med lagring på vil også erstatte in-tree plugins i Kubernetes core og FlexVolume plugins fra Microsoft basert på Powershell;

Opplegg for implementering av CSI-plugins i Kubernetes for Windows
mulighet endre størrelse på CSI-volumer, introdusert tilbake i K8s 1.12, har vokst til en betaversjon;
En lignende "promotering" (fra alfa til beta) ble oppnådd ved muligheten til å bruke CSI til å lage lokale flyktige volumer (CSI Inline volumstøtte).

Introdusert i forrige versjon av Kubernetes volumkloningsfunksjon (ved å bruke eksisterende PVC som DataSource å lage ny PVC) har også nå fått betastatus.

Planlegger

To bemerkelsesverdige endringer i planlegging (begge i alfa):

EvenPodsSpreading - mulighet bruk pods i stedet for logiske applikasjonsenheter for "rettferdig fordeling" av laster (som Deployment og ReplicaSet) og justere denne distribusjonen (som et hardt krav eller som en myk tilstand, dvs. prioritet). Funksjonen vil utvide de eksisterende distribusjonsmulighetene til planlagte pods, for øyeblikket begrenset av alternativer PodAffinity и PodAntiAffinity, som gir administratorer bedre kontroll i denne saken, noe som betyr bedre høy tilgjengelighet og optimalisert ressursforbruk. Detaljer - inn KEP.
Bruk BestFit-policy в RequestedToCapacity Ratio Priority Function under pod planlegging, som vil tillate gjelder søppelpakking ("pakking i containere") for både grunnleggende ressurser (prosessor, minne) og utvidede (som GPU). For flere detaljer, se KEP.

Planlegging av pods: før du bruker best tilpasningspolicy (direkte via standardplanlegger) og med bruk (via planleggerforlenger)

I tillegg, representert av muligheten til å lage dine egne planlegger-plugins utenfor hovedutviklingstreet for Kubernetes (utenfor treet).

Andre endringer

Også i Kubernetes 1.16-utgivelsen kan det noteres initiativ til bringe tilgjengelige beregninger i full rekkefølge, eller mer presist, i henhold til offisielle forskrifter til K8s instrumentering. De stoler i stor grad på tilsvarende Prometheus dokumentasjon. Inkonsekvenser oppsto av forskjellige grunner (for eksempel ble noen beregninger ganske enkelt opprettet før de nåværende instruksjonene dukket opp), og utviklerne bestemte at det var på tide å bringe alt til en enkelt standard, "i tråd med resten av Prometheus-økosystemet." Den nåværende implementeringen av dette initiativet er i alfastatus, som gradvis vil bli promotert i påfølgende versjoner av Kubernetes til beta (1.17) og stabil (1.18).

I tillegg kan følgende endringer noteres:

Windows-støtteutvikling с utseende Kubeadm-verktøy for dette operativsystemet (alfaversjon), mulighet RunAsUserName for Windows-beholdere (alfaversjon), forbedring Group Managed Service Account (gMSA) støtte opp til betaversjon, Brukerstøtte montere/feste for vSphere-volumer.
Resirkulert datakomprimeringsmekanisme i API-svar. Tidligere ble et HTTP-filter brukt til disse formålene, som påla en rekke begrensninger som forhindret at det ble aktivert som standard. "Transparent forespørselskomprimering" fungerer nå: klienter sender Accept-Encoding: gzip i overskriften mottar de et GZIP-komprimert svar hvis størrelsen overstiger 128 KB. Go-klienter støtter automatisk komprimering (sender den nødvendige overskriften), slik at de umiddelbart vil merke en reduksjon i trafikken. (Små endringer kan være nødvendig for andre språk.)
Ble mulig skalere HPA fra/til null pods basert på eksterne beregninger. Hvis du skalerer basert på objekter/eksterne beregninger, kan du automatisk skalere til 0 replikaer når arbeidsbelastninger er inaktive for å spare ressurser. Denne funksjonen bør være spesielt nyttig for tilfeller der arbeidere ber om GPU-ressurser, og antallet forskjellige typer ledige arbeidere overstiger antallet tilgjengelige GPUer.
Ny klient - k8s.io/client-go/metadata.Client – for "generalisert" tilgang til objekter. Den er designet for enkelt å hente metadata (dvs. underseksjon metadata) fra klyngeressurser og utføre søppelinnsamling og kvoteoperasjoner med dem.
Bygg Kubernetes nå kan du uten eldre («innebygd» i tre) skyleverandører (alfaversjon).
Til kubeadm-verktøyet la til eksperimentell (alfaversjon) evne til å bruke tilpassede patcher under operasjoner init, join и upgrade. Lær mer om hvordan du bruker flagget --experimental-kustomize, se inn KEP.
Nytt endepunkt for apiserver - readyz, - lar deg eksportere informasjon om dens beredskap. API-serveren har nå også et flagg --maximum-startup-sequence-duration, slik at du kan regulere omstartene.
to funksjoner for Azure erklært stabil: støtte tilgjengelighetssoner (Tilgjengelighetssoner) og kryss ressursgruppe (RG). I tillegg har Azure lagt til:
- støtte for autentisering AAD og ADFS;
- kommentar service.beta.kubernetes.io/azure-pip-name å spesifisere den offentlige IP-en til lastbalanseren;
- mulighet настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS har nå støtte for EBS på Windows og optimalisert EC2 API-kall DescribeInstances.
Kubeadm er nå uavhengig migrerer CoreDNS-konfigurasjon ved oppgradering av CoreDNS-versjonen.
Binære filer osv i det tilsvarende Docker-bildet laget world-executable, som lar deg kjøre dette bildet uten behov for rotrettigheter. Også etcd migrasjonsbilde opphørt etcd2 versjonsstøtte.
В Cluster Autoscaler 1.16.0 byttet til å bruke distroless som basisbilde, forbedret ytelse, lagt til nye skyleverandører (DigitalOcean, Magnum, Packet).
Oppdateringer i brukt/avhengig programvare: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Les også på bloggen vår:

Kilde: www.habr.com

Kubernetes 1.16: oversikt over de viktigste nyvinningene