🥇Kubernetes 1.17: oversigt over de vigtigste innovationer

I går, den 9. december, tog sted næste udgivelse af Kubernetes - 1.17. Ifølge traditionen, der har udviklet sig for vores blog, taler vi om de væsentligste ændringer i den nye version.

Oplysningerne brugt til at udarbejde dette materiale er taget fra den officielle meddelelse, Sporingstabeller for Kubernetes-forbedringer, ÆNDRINGSLOG-1.17 og relaterede problemer, pull-anmodninger og Kubernetes Enhancement Proposals (KEP). Nå, noget nyt?..

Topologi-bevidst routing

Kubernetes-fællesskabet har ventet på denne funktion i lang tid - Topologi-bevidst service routing. hvis KEP den stammer fra oktober 2018, og den officielle ekstraudstyr — 2 år siden, de sædvanlige problemer (synes godt om det) - og nogle flere år ældre...

Den generelle idé er at give mulighed for at implementere "lokal" routing for tjenester, der er bosat i Kubernetes. "Lokalitet" betyder i dette tilfælde "samme topologiske niveau" (topologiniveau), som kan være:

node identisk for tjenester,
det samme serverrack,
samme region
den samme cloud-udbyder,
...

Eksempler på brug af denne funktion:

besparelser på trafik i cloud-installationer med flere tilgængelighedszoner (multi-AZ) - se. frisk illustration ved at bruge eksemplet med trafik fra samme region, men forskellige AZ'er i AWS;
lavere ydelsesforsinkelse/bedre gennemløb;
en shard tjeneste, der har lokal information om knudepunktet i hvert shard;
placering af fluentd (eller analoger) på den samme node med de applikationer, hvis logfiler er indsamlet;
...

Sådan routing, som "kender" til topologien, kaldes også netværksaffinitet - i analogi med node affinitet, pod-affinitet/anti-affinitet eller dukkede op ikke så længe siden Topologibevidst volumenplanlægning (og Volumenforsyning). Nuværende implementeringsniveau ServiceTopology i Kubernetes - alfaversion.

For detaljer om, hvordan funktionen fungerer, og hvordan du allerede kan bruge den, læs denne artikel fra en af forfatterne.

IPv4/IPv6 dual stack understøttelse

Betydelige fremskridt fast i en anden netværksfunktion: samtidig understøttelse af to IP-stakke, som først blev introduceret i K8s 1.16. Især medførte den nye udgivelse følgende ændringer:

i kube-proxy implementeret mulighed for samtidig drift i begge tilstande (IPv4 og IPv6);
в Pod.Status.PodIPs optrådte understøttelse af nedadgående API (på samme tid som i /etc/hosts nu kræver de, at værten tilføjer en IPv6-adresse);
dobbelt stak støtte VENLIG (Kubernetes IN Docker) og kubeadm;
opdaterede e2e-tests.

illustration bruger dual stack IPV4/IPv6 i KIND

Fremskridt med CSI

Erklæret stabil topologi støtte til CSI-baseret lagring, først introduceret i K8s 1.12.

Initiativ til migrering af volumen plugins til CSI — CSI-migrering - nået betaversion. Denne funktion er afgørende for at oversætte eksisterende storage-plugins (i træet) til en moderne grænseflade (CSI, ud af træet) usynlig for Kubernetes slutbrugere. Klyngeadministratorer behøver kun at aktivere CSI-migrering, hvorefter eksisterende stateful ressourcer og arbejdsbelastninger vil fortsætte med at "bare fungere"... men ved at bruge de nyeste CSI-drivere i stedet for de forældede, der er inkluderet i Kubernetes-kernen.

I øjeblikket er migrering til AWS EBS-drivere klar i betaversion (kubernetes.io/aws-ebs) og GCE PD (kubernetes.io/gce-pd). Prognoser for andre lagerfaciliteter er som følger:

Vi talte om, hvordan "traditionel" lagerunderstøttelse i K8'er kom til CSI denne artikel. Og overgangen af CSI-migrering til beta-status er dedikeret til separat udgivelse på projektbloggen.

Derudover nåede en anden væsentlig funktionalitet i forbindelse med CSI, som stammer (alfa-implementering) i K1.17s 8, betastatus (dvs. aktiveret som standard) i Kubernetes 1.12-udgivelsen - skabe snapshots og bedring fra dem. Blandt ændringerne i Kubernetes Volume Snapshot på vej til beta-udgivelse:

opdeling af CSI ekstern-snapshotter sidevogn i to controllere,
tilføjet hemmelighed til sletning (sletningshemmelighed) som en annotation til indholdet af et volumen-øjebliksbillede,
ny finalizer (afslutter) for at forhindre snapshot API-objektet i at blive slettet, hvis der er resterende forbindelser.

På tidspunktet for udgivelse 1.17 understøttes funktionen af tre CSI-drivere: GCE Persistent Disk CSI-driver, Portworx CSI-driver og NetApp Trident CSI-driver. Flere detaljer om dens implementering og brug kan findes i denne udgivelse på bloggen.

Cloud Provider-etiketter

Mærker, der automatisk tildelt til oprettede noder og volumener afhængigt af den anvendte cloud-udbyder, har været tilgængelig i Kubernetes som en betaversion i meget lang tid - siden udgivelsen af K8s 1.2 (april 2016!). I betragtning af deres udbredte brug i så lang tid, udviklere besluttet, at det er tid til at erklære funktionen stabil (GA).

Derfor blev de alle omdøbt i overensstemmelse hermed (af topologi):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... men er stadig tilgængelige under deres gamle navne (for bagudkompatibilitet). Alle administratorer anbefales dog at skifte til nuværende etiketter. Relateret dokumentation K8s er blevet opdateret.

Struktureret output af kubeadm

Præsenteret i alfaversion for første gang struktureret output for kubeadm-værktøjet. Understøttede formater: JSON, YAML, Go skabelon.

Motivation for at implementere denne funktion (ifølge KEP) er:

Mens Kubernetes kan implementeres manuelt, er de facto (hvis ikke de jure) standarden for denne operation at bruge kubeadm. Populære systemadministrationsværktøjer som Terraform er afhængige af kubeadm til Kubernetes-implementering. Planlagte forbedringer af Cluster API inkluderer en komponerbar pakke til Kubernetes bootstrapping med kubeadm og cloud-init.

Uden struktureret output kan selv de mest harmløse ændringer ved første øjekast bryde Terraform, Cluster API og anden software, der bruger resultaterne af kubeadm.

Vores umiddelbare planer inkluderer support (i form af struktureret output) til følgende kubeadm-kommandoer:

alpha certs
config images list
init
token create
token list
upgrade plan
version

Illustration af et JSON-svar på en kommando kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilisering af andre innovationer

Generelt fandt udgivelsen af Kubernetes 1.17 sted under mottoet "Stabilitet" Dette blev lettet af det faktum, at mange funktioner i det (deres samlede antal er 14) modtog GA-status. Blandt dem:

"mærke" noder i henhold til visse betingelser (TaintNodesByCondition), dukkede op i K8s 1.8;
Se bogmærker - en ny type begivenheder, der har en etiket, at alle objekter er op til en bestemt version (resourceVersion) allerede er blevet behandlet af vagt;
Standardværdier (standard) for brugerdefinerede ressourcer;
deles mellem containere i pod-processen navnerum;
ScheduleDaemonSetPods — planlægning af pods i DaemonSet ved at bruge kube-scheduler (i stedet for DaemonSet-controlleren);
dynamiske grænser på antallet af volumener afhængigt af nodetypen;
miljøvariabel støtte for mappenavne monteret som subPath;
Kubelet hjerteslag overførsel til en specialiseret Lease API;
"afslutter beskyttelse" (Finalizer beskyttelse) for belastningsbalancere (kontrol af de tilsvarende serviceressourcer før sletning af LoadBalancer-ressourcer);
kube-apiserver optimering i ydeevne, når der arbejdes med flere ure, der overvåger identiske sæt objekter - opnået ved at undgå gentagen serialisering af de samme objekter for hver observer.

Andre ændringer

Den fulde liste over innovationer i Kubernetes 1.17 er selvfølgelig ikke begrænset til dem, der er anført ovenfor. Her er nogle andre (og for en mere komplet liste, se CHANGELOG):

Funktionen, der blev præsenteret i den seneste udgivelse, har nået betaversionen RunAsUserName Til Windows;
lignende ændring faldt EndpointSlice API (også fra K8s 1.16), men indtil videre er denne løsning til at forbedre ydeevnen/skalerbarheden af Endpoint API'en ikke aktiveret som standard;
pods er nu kritiske for klyngedrift kan oprettes ikke kun i navneområder kube-system (for detaljer, se dokumentationen for Begræns Priority Class-forbrug);
ny mulighed for kubelet - --reserved-cpus — giver dig mulighed for eksplicit at definere listen over CPU'er, der er reserveret til systemet;
for kubectl logs præsenteret nyt flag --prefix, tilføjelse af pod- og kildebeholderens navn til hver linje i loggen;
в label.Selector tilføjet RequiresExactMatch;
alle containere i kube-dns kører nu med færre privilegier;
hyperkube opdelt i et separat GitHub-lager og vil ikke længere være inkluderet i Kubernetes-udgivelser;
meget forbedret ydeevne kube-proxy til ikke-UDP-porte.

Afhængighedsændringer:

CoreDNS version inkluderet i kubeadm er 1.6.5;
crictl version opdateret til v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
Seneste testede Docker-version opgraderet til 19.03;
Den mindste Go-version, der kræves for at bygge Kubernetes 1.17, er 1.13.4.

PS

Læs også på vores blog:

Kilde: www.habr.com

Kubernetes 1.17: Højdepunkter i det nye