🥇Kubernetes 1.17: översikt över de viktigaste innovationerna

Igår, den 9 december, ägde rum nästa utgåva av Kubernetes - 1.17. Enligt traditionen som har utvecklats för vår blogg talar vi om de viktigaste förändringarna i den nya versionen.

Informationen som används för att förbereda detta material är hämtad från det officiella tillkännagivandet, Spårningstabeller för Kubernetes-förbättringar, ÄNDRINGSLOGG-1.17 och relaterade frågor, pull-förfrågningar och Kubernetes Enhancement Proposals (KEP). Så vad är nytt?..

Topologimedveten routing

Kubernetes-communityt har väntat på den här funktionen länge - Topologi-medveten tjänst routing. om KEP det har sitt ursprung i oktober 2018, och den officiella förbättring — 2 år sedan, de vanliga frågorna (tycka om av detta) - och några år äldre...

Den allmänna idén är att tillhandahålla möjligheten att implementera "lokal" routing för tjänster som finns i Kubernetes. "Lokalitet" betyder i detta fall "samma topologiska nivå" (topologinivå), vilket kan vara:

nod identisk för tjänster,
samma serverrack,
samma region
samma molnleverantör,
.

Exempel på hur du använder den här funktionen:

besparingar på trafik i molninstallationer med flera tillgänglighetszoner (multi-AZ) - se. färsk illustration använder exemplet med trafik från samma region, men olika AZ i AWS;
lägre prestandalatens/bättre genomströmning;
en fragmenterad tjänst som har lokal information om noden i varje fragment;
placering av fluentd (eller analoger) på samma nod med de applikationer vars loggar samlas in;
.

Sådan routing, som "vet" om topologin, kallas också nätverksaffinitet - i analogi med nodaffinitet, podaffinitet/antiaffinitet eller dök upp inte så länge sedan Topologi-medveten volymschemaläggning (och Volymförsörjning). Aktuell implementeringsnivå ServiceTopology i Kubernetes - alfaversion.

Läs mer om hur funktionen fungerar och hur du redan kan använda den den här artikeln från en av författarna.

Stöd för dubbla stack för IPv4/IPv6

Betydande framsteg fast i en annan nätverksfunktion: samtidigt stöd för två IP-stackar, som först introducerades i K8s 1.16. I synnerhet medförde den nya utgåvan följande ändringar:

i kube-proxy genomförs möjlighet till samtidig drift i båda lägena (IPv4 och IPv6);
в Pod.Status.PodIPs dök stöd för nedåtgående API (samtidigt som i /etc/hosts nu kräver de att värden lägger till en IPv6-adress);
stöd för dubbla stack SNÄLL (Kubernetes IN Docker) och kubeadm;
uppdaterade e2e-tester.

illustration använder dual stack IPV4/IPv6 i KIND

Framsteg på CSI

Förklarad stabil topologistöd för CSI-baserad lagring, introducerades först i K8s 1.12.

Initiativ till migrering av volyminsticksprogram till CSI - CSI-migrering - nått betaversion. Denna funktion är avgörande för att översätta befintliga lagringsplugin (i trädet) till ett modernt gränssnitt (CSI, utanför trädet) osynlig för Kubernetes slutanvändare. Klusteradministratörer behöver bara aktivera CSI-migrering, varefter befintliga tillståndsbaserade resurser och arbetsbelastningar kommer att fortsätta att "bara fungera"... men med de senaste CSI-drivrutinerna istället för de föråldrade som ingår i Kubernetes-kärnan.

För tillfället är migreringen för AWS EBS-drivrutiner klar i betaversion (kubernetes.io/aws-ebs) och GCE PD (kubernetes.io/gce-pd). Prognoser för andra lagringsanläggningar är följande:

Vi pratade om hur "traditionellt" lagringsstöd i K8s kom till CSI den här artikeln. Och övergången av CSI-migrering till betastatus är tillägnad separat publicering på projektbloggen.

Dessutom nådde en annan betydande funktionalitet i CSI-sammanhang, som har sitt ursprung (alfa-implementering) i K1.17s 8, betastatus (dvs. aktiverad som standard) i Kubernetes 1.12-utgåvan - skapa ögonblicksbilder och återhämtning från dem. Bland ändringarna som gjorts i Kubernetes Volume Snapshot på väg till betaversion:

dela upp CSI extern-snapshotter sidovagn i två kontroller,
lagt till hemlighet för radering (raderingshemlighet) som en kommentar till innehållet i en volymöversiktsbild,
ny finaliserare (avslutare) för att förhindra att snapshot-API-objektet tas bort om det finns kvarstående anslutningar.

Vid tidpunkten för release 1.17 stöds funktionen av tre CSI-drivrutiner: GCE Persistent Disk CSI Driver, Portworx CSI Driver och NetApp Trident CSI Driver. Mer information om dess implementering och användning finns i denna publikation på bloggen.

Etiketter för molnleverantörer

Märker som automatiskt tilldelas skapade noder och volymer beroende på vilken molnleverantör som används, har varit tillgängliga i Kubernetes som en betaversion under mycket lång tid - sedan lanseringen av K8s 1.2 (april 2016!). Med tanke på deras utbredda användning så länge, utvecklare bestämt, att det är dags att förklara funktionen stabil (GA).

Därför döptes de alla om i enlighet med detta (genom 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 är fortfarande tillgängliga under sina gamla namn (för bakåtkompatibilitet). Alla administratörer rekommenderas dock att byta till nuvarande etiketter. Relaterad dokumentation K8s har uppdaterats.

Strukturerad utdata av kubeadm

Presenteras i alfaversion för första gången strukturerad utdata för kubeadm-verktyget. Format som stöds: JSON, YAML, Go mall.

Motivation för att implementera denna funktion (enligt KEP) är:

Även om Kubernetes kan distribueras manuellt, är de facto (om inte de jure) standarden för denna operation att använda kubeadm. Populära systemhanteringsverktyg som Terraform förlitar sig på kubeadm för Kubernetes-distribution. Planerade förbättringar av Cluster API inkluderar ett komponerbart paket för Kubernetes bootstrapping med kubeadm och cloud-init.

Utan strukturerad utdata kan även de mest ofarliga ändringarna vid första anblicken bryta Terraform, Cluster API och annan programvara som använder resultaten av kubeadm.

Våra omedelbara planer inkluderar stöd (i form av strukturerad utdata) för följande kubeadm-kommandon:

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

Illustration av ett JSON-svar på ett 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 andra innovationer

I allmänhet skedde lanseringen av Kubernetes 1.17 under mottot "stabilitet" Detta underlättades av det faktum att många funktioner i den (deras totala antal är 14) fick GA-status. Bland dem:

"markera" noder enligt vissa villkor (TaintNodesByCondition), framträdde i K8s 1.8;
Titta på bokmärken - en ny typ av händelser som har en etikett att alla objekt är upp till en viss version (resourceVersion) har redan bearbetats av watch;
ursprungliga värden (standard) för anpassade resurser;
delas mellan containrar i podprocessen namnutrymmen;
ScheduleDaemonSetPods - schemalägga pods i DaemonSet använda kube-scheduler (istället för DaemonSet-kontrollern);
dynamiska gränser på antalet volymer beroende på nodtyp;
stöd för miljövariabel för katalognamn monterade som subPath;
Kubelet hjärtslagsöverföring till ett specialiserat Lease API;
"avslutarskydd" (Finalizer-skydd) för lastbalanserare (kontrollera motsvarande tjänstresurser innan du tar bort LoadBalancer-resurser);
kube-apiserver optimering prestanda när man arbetar med flera klockor som övervakar identiska uppsättningar av objekt - uppnås genom att undvika upprepad serialisering av samma objekt för varje tittare.

Andra förändringar

Den fullständiga listan över innovationer i Kubernetes 1.17 är naturligtvis inte begränsad till de som anges ovan. Här är några andra (och för en mer komplett lista, se ÄNDRING):

Funktionen som presenterades i den senaste versionen har nått betaversionen RunAsUserName för fönster;
liknande förändring hände EndpointSlice API (även från K8s 1.16), men för närvarande är denna lösning för att förbättra prestanda/skalbarhet för Endpoint API inte aktiverad som standard;
poddar är nu kritiska för klusterdrift kan skapas inte bara i namnutrymmen kube-system (för detaljer, se dokumentationen för Begränsa Priority Class-förbrukning);
nytt alternativ för kubelet - --reserved-cpus — låter dig uttryckligen definiera listan över processorer reserverade för systemet;
för kubectl logs presenteras ny flagga --prefix, lägga till namnet på podden och källbehållaren till varje rad i loggen;
в label.Selector Lagt till RequiresExactMatch;
alla containrar i kube-dns är nu igång med mindre privilegier;
hyperkube separeras i ett separat GitHub-förråd och kommer inte längre att inkluderas i Kubernetes-utgåvor;
mycket förbättrad prestanda kube-proxy för icke-UDP-portar.

Beroendeändringar:

CoreDNS-versionen som ingår i kubeadm är 1.6.5;
crictl version uppdaterad till v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
Senaste testade Docker-versionen uppgraderad till 19.03;
Den minsta Go-version som krävs för att bygga Kubernetes 1.17 är 1.13.4.

PS

Läs även på vår blogg:

Källa: will.com

Kubernetes 1.17: översikt över de viktigaste innovationerna