🥇Kubernetes 1.17: oversigt over de vigtigste nyheder

I går, den 9. december, tog sted blev endnu en version af Kubernetes — 1.17. I vores blogs tradition fortæller vi om de mest markante ændringer i den nye version.

Kubernetes 1.17: overview of key innovations

Informationen brugt til at forberede dette materiale er taget fra den officielle meddelelse, Kubernetes enhancements tracking tabel, CHANGELOG-1.17 og de tilhørende issues, pull requests, samt Kubernetes Enhancement Proposals (KEP). Så, hvad er nyt?..

Ruteplanlægning med topologisk bevidsthed

Det har længe været ventet i Kubernetes-fællesskabet — Topology-aware service routing. Hvis KEP som har taget sin begyndelse i oktober 2018, og den officielle enhancement — for 2 år siden, så almindelige issues (som denne) — er endda ældre med flere år...

Den overordnede idé er at give mulighed for at implementere "lokal" ruteplanlægning for tjenester, der findes i Kubernetes. "Lokalitet" i denne forbindelse betyder "samme topologiske niveau" (topology level), hvilket kan være:

den samme node for tjenester,
den samme serverrack,
den samme region,
den samme cloududbyder,
…

Eksempler på brug af en sådan funktion:

besparelser på trafik i cloud-installationer med mange tilgængelighedszoner (multi-AZ) — se. den seneste illustration med hensyn til trafik i én region, men forskellige AZ i AWS;
lavere latens i ydeevne/better throughput;
et sharded service, der har lokal information om noden i hver shard;
placering af fluentd (eller alternativer) på én node med de applikationer, hvis logs indsamles;
…

En sådan ruteplanlægning, der "kender" til topologien, kaldes også en form for network affinity — sammenlignet med node affinity, pod affinity/anti-affinity eller den nyligt introducerede Topology-Aware Volume Scheduling Volume Provisioning (og ). Det nuværende niveau for implementeringServiceTopology i Kubernetes er en alpha-version. Detaljer om, hvordan funktionen er opbygget, og hvordan man allerede kan bruge den, kan læses i

af en af forfatterne. denne artikel Understøttelse af dobbelt IPv4/IPv6-stak

Betydelig fremgang

er blevet registreret i en anden netværksfunktion: samtidig understøttelse af to IP-stakke, som først blev præsenteret i K8s 1.16 . I særdeleshed bragte den nye version følgende ændringer:i kube-proxy

mulighed for samtidig drift i begge tilstande (IPv4 og IPv6); er implementeret Pod.Status.PodIPs
i understøttelse af downward API (samtidig kræver dette nu for host at tilføje også en IPv6-adresse); er der kommet understøttelse af to stakke i /etc/hosts (Kubernetes IN Docker) og
opdaterede e2e-tests. KIND opdaterede e2e-tests. kubeadm;
opdaterede e2e-tests.

Kubernetes 1.17: overview of key innovations
Illustration brug af dobbeltstak IPV4/IPv6 i KIND

Fremskridt med CSI

Er erklæret stabil understøttelse af topologier til lager baseret på CSI, først præsenteret i K8s 1.12.

Initiativet for migration af volumenplugins til CSI — CSI Migration — er nået beta-status. Denne funktion er kritisk for at overføre eksisterende lagerplugins (in-tree) til et moderne interface (CSI, out-of-tree) usynligt for slutbrugerne af Kubernetes. Clusteradministratorer skal blot aktivere CSI Migration, hvorefter eksisterende stateful-ressourcer og arbejdsbelastninger fortsat vil "bare fungere"... men med de aktuelle CSI-drivere i stedet for de forældede, der er indbygget i Kubernetes-kernen.

I øjeblikket er beta-migrationen klar for AWS EBS-drivere (kubernetes.io/aws-ebs) og GCE PD (kubernetes.io/gce-pd). Forudsigelser for andre lagre er som følger:

Kubernetes 1.17: overview of key innovations

Om hvordan "traditionel" lagerunderstøttelse i K8s nåede CSI, har vi beskrevet i denne artikel. Overgangen af CSI-migration til beta-status er dedikeret til et separat publikation i blogprojektet.

Derudover nåede en anden vigtig funktionalitet i forhold til CSI beta-status (dvs. aktivering som standard) i Kubernetes 1.17, som har sin oprindelse (alpha-implementering) i K8s 1.12 — oprettelse af snapshots og gendannelse fra dem. Blandt ændringerne foretaget i Kubernetes Volume Snapshot på vej til beta-udgivelsen:

opdeling af sidecar’en CSI external-snapshotter i to controllere,
tilføjet hemmelighed til sletning (deletion secret) som en annotation til indholdet af volumenets snapshot,
ny finalizer til forhindring af sletning af API-objektet af snapshotet ved tilbageblevne relationer. Ved udgivelsen af 1.17 understøttes denne funktion af tre CSI-drivere: GCE Persistent Disk CSI Driver, Portworx CSI Driver og NetApp Trident CSI Driver. For mere information om dens implementering og brug kan du læse i

denne publikation i bloggen. Cloud Provider Labels

Labels, der automatisk

tildeles til oprettede noder og volume afhængigt af den anvendte skyudbyder , har længe været tilgængelige i Kubernetes som beta - siden K8s 1.2 udgivelsen(april 2016!) . I betragtning af deres brede anvendelse i så lang tid, besluttede udviklerne, at det var tid til at erklære funktionen stabil (GA). Derfor blev de alle omdøbt i overensstemmelse hermed (efter topologier):beta.kubernetes.io/instance-type

node.kubernetes.io/instance-type

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

… men stadig er tilgængelige under deres gamle navne (for bagudkompatibilitet). Dog anbefales det, at alle administratorer overgår til de aktuelle labels. Den relevante dokumentation K8s er blevet opdateret.

Struktureret output fra kubeadm

Første gang præsenteret i alfa-format struktureret output til kubeadm-værktøjet. Understøttede formater: JSON, YAML, Go-skabelon.

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

Selvom Kubernetes kan implementeres manuelt, er det de facto (hvis ikke de jure) standarden for denne operation at bruge kubeadm. Populære systemadministrationsværktøjer som Terraform benytter kubeadm til deployment af Kubernetes. Planlagte forbedringer i Cluster API omfatter et modulært pakke til bootstrapping af Kubernetes med kubeadm og cloud-init.
Uden struktureret output kan selv de mest harmløse ændringer ved første øjekast ødelægge Terraform, Cluster API og anden software, der bruger output fra kubeadm.

De nærmeste planer inkluderer støtte (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 JSON-svaret på kommandoen 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": "Det standard bootstrap-token, der genereres af 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilisering af andre nyskabelser

Generelt udkom Kubernetes 1.17 under sloganet «Stabilitet». Dette blev fremmet af det faktum, at mange funktioner i den (i alt 14) fik GA-status. Blandt dem:

»mærkning« af noder under bestemte forhold (TaintNodesByCondition), introduceret i K8s 1.8;
Watch Bookmarks — en ny type begivenheder, der har etikette, som angiver, at alle objekter op til en bestemt version (resourceVersion) allerede er blevet behandlet af watch;
standardværdier (defaulting) for Custom Resources;
delte process namespaces mellem containerne i en pod;
ScheduleDaemonSetPods — planlægning af pods i DaemonSet ved hjælp af kube-scheduler (i stedet for DaemonSet-controlleren);
dynamiske begrænsninger på antallet af volumener afhængigt af typen af node;
understøttelse af miljøvariabler til katalognavne, der er monteret som subPath;
overførsel af Kubelet heartbeat-signal i det specialiserede Lease API;
„finalizer beskyttelse“ (Finalizer Protection) for load balancere (kontrol af de relevante ressourcer til tjenesten før fjernelse af LoadBalancer-ressourcer);
optimering af kube-apiserver i ydelsen, når der arbejdes med mange watches, der overvåger identiske sæt af objekter — opnås ved at undgå at reserialisere de samme objekter for hver watcher.

Andre ændringer

Den komplette liste over nyheder i Kubernetes 1.17 er selvfølgelig ikke begrænset til dem, der er nævnt ovenfor. Her er nogle andre (og for en mere omfattende liste — se. CHANGELOG):

det, der blev præsenteret i sidste udgave, har nået beta-version; RunAsUserName til Windows.;
en tilsvarende ændring har ramt EndpointSlice API (også fra K8s 1.16), men denne løsning til forbedring af ydeevne/skalerbarhed for Endpoint API er ikke aktiveret som standard;
kritiske pod'er for klyngens drift kan nu oprettes ikke kun i navnerum kube-system (se dokumentationen for Limit Priority Class forbrug);
ny mulighed for kubelet — --reserved-cpus — tillader klar definition af listen over CPU'er, der er reserveret til systemet;
for kombineres præsenteret ny flag --prefix, der tilføjer navnet på pod'en og kilden til containeren til hver loglinje;
i label.Selector tilføjet RequiresExactMatch;
alle containere i kube-dns kører nu med lavere privilegier;
hyperkube er blevet udskilt til et separat GitHub-repository og vil ikke længere blive inkluderet i Kubernetes-udgivelser;
væsentligt forbedret ydeevne kube-proxy for non-UDP-porte.

Ændringer i afhængigheder:

CoreDNS-versionen i kubeadm — 1.6.5;
versionen af crictl er opdateret til v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
den sidste verificerede version af Docker er hævet til 19.03;
den mindste version af Go, der kræves for at bygge Kubernetes 1.17, er 1.13.4.

P.S.

Læs også på vores blog:

Kilde: habr.com