🥇Kubernetes 1.17: oversikt over de viktigste nyvinningene

I går, 9. desember, fant sted Den nyeste utgivelsen av Kubernetes er 1.17. I tråd med vår bloggtradisjon forteller vi deg om de viktigste endringene i den nye versjonen.

Kubernetes 1.17: oversikt over de viktigste nyvinningene

Informasjonen som ble brukt til å utarbeide dette materialet ble hentet fra den offisielle kunngjøringen, Sporingstabeller for Kubernetes-forbedringer, ENDRINGSLOGG-1.17 og relaterte problemer, pull-forespørsler og Kubernetes Enhancement Proposals (KEP-er). Så, hva er nytt?

Topologibevisst ruting

Kubernetes-fellesskapet har ventet på denne funksjonen lenge - Topologibevisst tjenesteruting. om KEP det startet i oktober 2018, og den offisielle ekstrautstyr — for 2 år siden, så de vanlige problemene (like det) – og enda noen år eldre ...

Den generelle ideen er å gi muligheten til å implementere «lokal» ruting for tjenester som ligger i Kubernetes. «Lokal» betyr i dette tilfellet «samme topologiske nivå». (topologinivå), som kan være:

samme node for tjenester,
det samme serverracket,
samme region,
den samme skyleverandøren,
...

Eksempler på bruk av denne funksjonen:

spare trafikk i skyinstallasjoner med flere tilgjengelighetssoner (multi-AZ) – se fersk illustrasjon ved å bruke eksemplet med trafikk fra én region, men forskjellige AZ-er i AWS;
lavere ytelseslatens/bedre gjennomstrømning;
en sharded-tjeneste som har lokal informasjon om noden i hver shard;
plassere fluentd (eller lignende) på samme node som applikasjonene hvis logger samles inn;
...

Denne typen ruting, «bevisst» på topologien, kalles også en slags nettverksaffinitet – analogt med nodetilhørighet, pod-affinitet/anti-affinitet eller dukket opp ikke så lenge siden Topologibevisst volumplanlegging (og VolumprovisjoneringNåværende implementeringsnivå ServiceTopology i Kubernetes – alfaversjon.

Les mer om hvordan funksjonen fungerer og hvordan du allerede kan bruke den i denne artikkelen fra en av forfatterne.

Støtte for IPv4/IPv6 dobbel stack

Betydelig fremgang registrert i en annen nettverksfunksjon: samtidig støtte for to IP-stabler, som først ble introdusert i K8s 1.16Den nye utgivelsen medførte spesielt følgende endringer:

i kube-proxy implementert muligheten til å jobbe samtidig i begge moduser (IPv4 og IPv6);
в Pod.Status.PodIPs dukket opp nedadgående API-støtte (samtidig i /etc/hosts nå krever de at du legger til en IPv6-adresse for verten);
støtte for dobbel stack SNILL (Kubernetes IN Docker) og kubeadm;
oppdaterte e2e-tester.

Kubernetes 1.17: oversikt over de viktigste nyvinningene
illustrasjon Bruk av Dual Stack IPV4/IPv6 i KIND

Fremgang på CSI

Erklært stabil topologistøtte for CSI-basert lagring, først introdusert i K8s 1.12.

Initiativ om Migrering av volumpluginer til CSI - CSI-migrering — har nådd betanivå. Denne funksjonen er avgjørende for å oversette eksisterende lagringspluginer (i treet) til et moderne grensesnitt (CSI, utenfor treet) sømløst for Kubernetes-sluttbrukere. Klyngeadministratorer trenger bare å aktivere CSI-migrering, og eksisterende tilstandsfulle ressurser og arbeidsbelastninger vil fortsette å «bare fungere» ... men ved å bruke de nyeste CSI-driverne i stedet for de eldre som er inkludert i Kubernetes-kjernen.

For øyeblikket er migreringen for AWS EBS-drivere klar i betastatus (kubernetes.io/aws-ebs) og GCE PD (kubernetes.io/gce-pdPrognoser for andre lagringsanlegg er som følger:

Kubernetes 1.17: oversikt over de viktigste nyvinningene

Vi snakket om hvordan «tradisjonell» lagringsstøtte i K8-er kom til CSI i denne artikkelenOg overgangen av CSI-migrering til betaversjonsstatus er dedikert separat publikasjon i prosjektbloggen.

I tillegg nådde en annen viktig funksjon i forbindelse med CSI, som oppsto (alfaimplementert) i K1.17s 8, betastatus (dvs. aktivert som standard) i Kubernetes 1.12-utgivelsen: lage øyeblikksbilder og gjenoppretting fra demBlant endringene som ble gjort i Kubernetes Volume Snapshot på vei til betaversjonen:

dele CSI eksternt snapshot-sidevogn i to kontrollere,
lagt til hemmelighet for sletting (slettingshemmelighet) som en merknad til innholdet i et volumsnapshot,
ny sluttbehandler (sluttbehandler) for å forhindre at snapshot API-objektet slettes hvis det finnes gjenværende lenker.

Ved utgivelse 1.17 støttes funksjonen av tre CSI-drivere: GCE Persistent Disk CSI Driver, Portworx CSI Driver og NetApp Trident CSI Driver. Du finner mer informasjon om implementering og bruk i denne publikasjonen i bloggen.

Etiketter for skyleverandører

Etiketter som automatisk tilordnet de opprettede nodene og volumene avhengig av hvilken skyleverandør som brukeshar vært tilgjengelig i Kubernetes som en betaversjon i svært lang tid – siden utgivelsen av K8s 1.2 (april 2016!)Gitt deres utbredte bruk over så lang tid, utviklere besluttet, at det er på tide å erklære funksjonen stabil (GA).

Derfor ble de alle omdøpt tilsvarende (etter 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 fortsatt tilgjengelige under sine gamle navn (for bakoverkompatibilitet). Alle administratorer anbefales imidlertid å bytte til de nåværende etikettene. Relevant dokumentasjon K8s har blitt oppdatert.

Strukturert utdata fra kubeadm

Presentert for første gang i alfaversjon strukturert utdata for kubeadm-verktøyetStøttede formater: JSON, YAML, Go-mal.

Motivasjon for å implementere denne funksjonen (i henhold til KEP) er som følger:

Selv om Kubernetes kan distribueres manuelt, er de facto (om ikke de jure) standarden for denne operasjonen å bruke kubeadm. Populære systemadministrasjonsverktøy som Terraform er avhengige av kubeadm for å distribuere Kubernetes. Planlagte forbedringer av Cluster API inkluderer en komponerbar pakke for oppstart av Kubernetes med kubeadm og cloud-init.
Uten strukturert utdata kan selv de mest tilsynelatende uskyldige endringene ødelegge Terraform, Cluster API og annen programvare som bruker resultatene fra kubeadm.

De umiddelbare planene inkluderer støtte (i form av strukturert utdata) for følgende kubeadm-kommandoer:

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

Illustrasjon av JSON-respons på 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 av andre innovasjoner

Generelt sett foregikk utgivelsen av Kubernetes 1.17 under mottoet «stabilitet"Dette ble muliggjort av det faktum at mange av funksjonene i den (det totale antallet er 14) har fått GA-status. Blant disse er:

"merking" av noder i henhold til visse betingelser (TaintNodesByCondition), som dukket opp i K8s 1.8;
Bokmerker for klokke — en ny type hendelser som har en etikett som viser alle objekter opp til en viss versjon (resourceVersion) har allerede blitt behandlet av Watch;
standardverdier (standard) for tilpassede ressurser;
delt mellom containere i navnerom for pod-prosesser;
ScheduleDaemonSetPods - planlegging av pods i DaemonSet bruker kube-scheduler (i stedet for DaemonSet-kontrolleren);
dynamiske grenser etter antall volumer avhengig av nodetypen;
støtte for miljøvariabler for katalognavn montert som subPath;
Kubelet hjerteslagoverføring inn i et spesialisert Lease-API;
"beskyttelse av sluttbehandler" (Beskyttelse mot sluttbehandling) for lastbalansering (sjekker de tilsvarende tjenesteressursene før LoadBalancer-ressurser slettes);
kube-apiserver-optimalisering i ytelse når man arbeider med flere klokker som observerer identiske sett med objekter - oppnådd ved å unngå reserialisering av de samme objektene for hver observatør.

Andre endringer

Den fullstendige listen over nye funksjoner i Kubernetes 1.17 er selvfølgelig ikke begrenset til de som er nevnt ovenfor. Her er noen andre (og for en mer fullstendig liste, se CHANGELOG):

funksjonen som ble presentert i forrige utgivelse har nå modnet til betaversjonen RunAsUserName for Windows;
lignende endring rammet EndpointSlice API (også fra K8s 1.16), men denne løsningen for å forbedre ytelse/skalerbarhet for Endpoint API er ikke aktivert som standard ennå;
poder som er kritiske for klyngeoperasjonen er nå kan opprettes ikke bare i navnerom kube-system (for detaljer, se dokumentasjonen på Begrens forbruket av prioritetsklasse);
nytt alternativ for kubelet — --reserved-cpus - lar deg eksplisitt definere listen over CPU-er som er reservert for systemet;
for kubectl logs presentert nytt flagg --prefix, som legger til navnet på poden og kildebeholderen til hver logglinje;
в label.Selector la til RequiresExactMatch;
alle containere i kube-dns nå begynner de med færre privilegier;
hyperkube har blitt separert i et separat GitHub-repository og vil ikke lenger bli inkludert i Kubernetes-utgivelser;
mye forbedret ytelse kube-proxy for ikke-UDP-porter.

Endringer i avhengigheter:

Versjonen av CoreDNS som er inkludert i kubeadm er 1.6.5;
crictl-versjonen er oppdatert til v1.16.1;
CSI 1.2.0;
osv. 3.4.3;
Den nyeste testede versjonen av Docker er oppgradert til 19.03;
Minimum Go-versjonen som kreves for å bygge Kubernetes 1.17 er 1.13.4.

PS

Les også på bloggen vår:

Kilde: www.habr.com