🥇Kubernetes 1.17: oversikt over de viktigste nyvinningene

I går, 9. desember, fant sted neste utgivelse av Kubernetes - 1.17. I henhold til tradisjonen som har utviklet seg for bloggen vår, snakker vi om de viktigste endringene i den nye versjonen.

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

Topologi-bevisst ruting

Kubernetes-fellesskapet har ventet på denne funksjonen i lang tid - Topologi-bevisst tjeneste ruting. om KEP den har sin opprinnelse i oktober 2018, og den offisielle ekstrautstyr — 2 år siden, de vanlige problemene (som det) - og noen flere år eldre...

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

node identisk for tjenester,
samme serverrack,
samme region
samme skyleverandør,
...

Eksempler på bruk av denne funksjonen:

besparelser på trafikk i skyinstallasjoner med flere tilgjengelighetssoner (multi-AZ) - se. fersk illustrasjon ved å bruke eksemplet med trafikk fra samme region, men forskjellige AZ-er i AWS;
lavere ytelsesforsinkelse/bedre gjennomstrømning;
en shard tjeneste som har lokal informasjon om noden i hvert shard;
plassering av fluentd (eller analoger) på samme node med applikasjonene hvis logger er samlet inn;
...

Slik ruting, som "vet" om topologien, kalles også nettverksaffinitet - i analogi med node affinitet, pod-affinitet/anti-affinitet eller dukket opp Ikke så lenge siden Topologi-bevisst volumplanlegging (og Volumtilførsel). Nåværende implementeringsnivå ServiceTopology i Kubernetes - alfaversjon.

For detaljer om hvordan funksjonen fungerer og hvordan du allerede kan bruke den, les denne artikkelen fra en av forfatterne.

Støtte for IPv4/IPv6 dual stack

Betydelig fremgang fikset i en annen nettverksfunksjon: samtidig støtte for to IP-stabler, som først ble introdusert i K8s 1.16. Spesielt brakte den nye utgivelsen følgende endringer:

i kube-proxy implementert mulighet for samtidig drift i begge modusene (IPv4 og IPv6);
в Pod.Status.PodIPs dukket opp støtte for nedover API (samtidig som i /etc/hosts nå krever de at verten legger til en IPv6-adresse);
støtte for dobbel stabel SNILL (Kubernetes IN Docker) og kubeadm;
oppdaterte e2e-tester.

illustrasjon ved å bruke dual stack IPV4/IPv6 i Slag

Fremgang på CSI

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

Initiativ til migrering av volumplugins til CSI - CSI-migrering - nådd betaversjon. Denne funksjonen er kritisk for å oversette eksisterende lagringsplugins (i treet) til et moderne grensesnitt (CSI, utenfor treet) usynlig for Kubernetes sluttbrukere. Klyngeadministratorer trenger bare å aktivere CSI-migrering, hvoretter eksisterende stateful ressurser og arbeidsbelastninger vil fortsette å "bare fungere"... men bruke de nyeste CSI-driverne i stedet for de utdaterte som er inkludert i Kubernetes-kjernen.

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

Vi snakket om hvordan "tradisjonell" lagringsstøtte i K8-er kom til CSI denne artikkelen. Og overgangen av CSI-migrering til betastatus er dedikert til egen utgivelse på prosjektbloggen.

I tillegg nådde en annen betydelig funksjonalitet i sammenheng med CSI, som har sin opprinnelse (alfa-implementering) i K1.17s 8, betastatus (dvs. aktivert som standard) i Kubernetes 1.12-utgivelsen - lage øyeblikksbilder og bedring fra dem. Blant endringene som er gjort i Kubernetes Volume Snapshot på vei til beta-utgivelse:

dele CSI eksternt snapshotter sidevogn i to kontrollere,
lagt til hemmelighet for sletting (sletting hemmelig) som en merknad til innholdet i et volum-øyeblikksbilde,
ny sluttbehandler (avslutter) for å forhindre at snapshot API-objektet slettes hvis det er gjenværende tilkoblinger.

På tidspunktet for utgivelse 1.17 støttes funksjonen av tre CSI-drivere: GCE Persistent Disk CSI-driver, Portworx CSI-driver og NetApp Trident CSI-driver. Flere detaljer om implementeringen og bruken finner du i denne publikasjonen på bloggen.

Skyleverandøretiketter

Merker som automatisk tilordnet opprettede noder og volumer avhengig av skyleverandøren som brukes, har 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 så lenge, utviklere besluttet, at det er på tide å erklære funksjonen stabil (GA).

Derfor ble de alle omdøpt tilsvarende (av 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 tilgjengelig under deres gamle navn (for bakoverkompatibilitet). Imidlertid anbefales alle administratorer å bytte til gjeldende etiketter. Relatert dokumentasjon K8s har blitt oppdatert.

Strukturert utgang av kubeadm

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

Motivasjon for å implementere denne funksjonen (ifølge KEP) er:

Mens Kubernetes kan distribueres manuelt, er de facto (hvis ikke de jure) standarden for denne operasjonen å bruke kubeadm. Populære systemadministrasjonsverktøy som Terraform er avhengige av kubeadm for Kubernetes-distribusjon. Planlagte forbedringer av Cluster API inkluderer en komponerbar pakke for Kubernetes bootstrapping med kubeadm og cloud-init.

Uten strukturert utgang kan selv de mest ufarlige endringene ved første øyekast bryte Terraform, Cluster API og annen programvare som bruker resultatene av kubeadm.

Våre umiddelbare planer inkluderer støtte (i form av strukturert utgang) for følgende kubeadm-kommandoer:

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

Illustrasjon av 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 av andre innovasjoner

Generelt fant utgivelsen av Kubernetes 1.17 sted under mottoet "stabilitet" Dette ble forenklet av det faktum at mange funksjoner i den (deres totale antall er 14) mottok GA-status. Blant dem:

"merke" noder i henhold til visse betingelser (TaintNodesByCondition), dukket opp i K8s 1.8;
Se bokmerker - en ny type hendelser som har en etikett på at alle objekter er opp til en viss versjon (resourceVersion) har allerede blitt behandlet av watch;
standardverdier (standard) for tilpassede ressurser;
delt mellom containere i pod-prosessen navneområder;
ScheduleDaemonSetPods - planlegge pods i DaemonSet bruke kube-scheduler (i stedet for DaemonSet-kontrolleren);
dynamiske grenser på antall volumer avhengig av nodetype;
støtte for miljøvariabel for katalognavn montert som subPath;
Kubelet hjerteslagoverføring til en spesialisert Lease API;
"avslutningsbeskyttelse" (Beskyttelse av ferdiggjører) for lastbalansere (sjekke de tilsvarende tjenesteressursene før du sletter LoadBalancer-ressurser);
kube-apiserver-optimalisering i ytelse når du arbeider med flere klokker som overvåker identiske sett med objekter - oppnås ved å unngå gjentatt serialisering av de samme objektene for hver overvåker.

Andre endringer

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

Funksjonen presentert i den siste utgivelsen har nådd betaversjonen RunAsUserName for vinduer;
lignende endring skjedde EndpointSlice API (også fra K8s 1.16), men foreløpig er denne løsningen for å forbedre ytelsen/skalerbarheten til Endpoint API ikke aktivert som standard;
pods er nå kritiske for klyngedrift kan opprettes ikke bare i navneområder kube-system (for detaljer, se dokumentasjonen for Begrens Priority Class-forbruk);
nytt alternativ for kubelet - --reserved-cpus — lar deg eksplisitt definere listen over CPUer reservert for systemet;
for kubectl logs presentert nytt flagg --prefix, legge til navnet på poden og kildebeholderen til hver linje i loggen;
в label.Selector la til RequiresExactMatch;
alle containere i kube-dns kjører nå med mindre privilegier;
hyperkube separert i et eget GitHub-depot og vil ikke lenger være inkludert i Kubernetes-utgivelser;
mye forbedret ytelse kube-proxy for ikke-UDP-porter.

Avhengighetsendringer:

CoreDNS-versjonen inkludert i kubeadm er 1.6.5;
crictl-versjon oppdatert til v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
Siste testet Docker-versjon oppgradert til 19.03;
Minimum Go-versjon som kreves for å bygge Kubernetes 1.17 er 1.13.4.

PS

Les også på bloggen vår:

Kilde: www.habr.com

Kubernetes 1.17: oversikt over de viktigste nyvinningene