🥇Kubernetes 1.17: oorsig van die belangrikste innovasies

Gister, 9 Desember, plaasgevind volgende weergawe van Kubernetes - 1.17. Volgens die tradisie wat vir ons blog ontwikkel het, praat ons oor die belangrikste veranderinge in die nuwe weergawe.

Die inligting wat gebruik word om hierdie materiaal voor te berei is geneem uit die amptelike aankondiging, Kubernetes-verbeteringsopsporingstabelle, VERANDERINGSLOG-1.17 en verwante kwessies, trekversoeke en Kubernetes Enhancement Proposals (KEP). So wat is nuut?..

Topologie-bewuste roetering

Die Kubernetes-gemeenskap wag al lank vir hierdie kenmerk - Topologie-bewuste diensroetering. indien Kep dit ontstaan in Oktober 2018, en die amptelike verbetering — 2 jaar gelede, die gewone kwessies (soos van hierdie) - en nog 'n paar jaar ouer...

Die algemene idee is om die vermoë te bied om "plaaslike" roetering te implementeer vir dienste wat in Kubernetes woon. "Lokaliteit" in hierdie geval beteken "dieselfde topologiese vlak" (topologie vlak), wat kan wees:

nodus identies vir dienste,
dieselfde bedienerrek,
dieselfde streek
dieselfde wolkverskaffer,
...

Voorbeelde van die gebruik van hierdie kenmerk:

besparings op verkeer in wolkinstallasies met veelvuldige beskikbaarheidsones (multi-AZ) - sien. vars illustrasie gebruik die voorbeeld van verkeer van dieselfde streek, maar verskillende AZ'e in AWS;
laer prestasie-latensie/beter deurset;
'n versnipperde diens wat plaaslike inligting oor die nodus in elke skerf het;
plasing van vloeiende (of analoë) op dieselfde nodus met die toepassings waarvan die logs versamel word;
...

Sulke roetering, wat "weet" van die topologie, word ook netwerkaffiniteit genoem - na analogie van nodus affiniteit, peulaffiniteit/anti-affiniteit of verskyn het nie so lank gelede nie Topologie-bewuste volumeskedulering (en Volumevoorsiening). Huidige vlak van implementering ServiceTopology in Kubernetes - alfa weergawe.

Vir besonderhede oor hoe die kenmerk werk en hoe jy dit reeds kan gebruik, lees Hierdie artikel van een van die skrywers.

IPv4/IPv6 dubbele stapel ondersteuning

Beduidende vordering vasgestel in 'n ander netwerkfunksie: gelyktydige ondersteuning vir twee IP-stapels, wat die eerste keer in K8s 1.16. Die nuwe vrystelling het veral die volgende veranderinge meegebring:

in kube-proxy geïmplementeer moontlikheid van gelyktydige werking in beide modusse (IPv4 en IPv6);
в Pod.Status.PodIPs verskyn ondersteuning vir afwaartse API (terselfdertyd as in /etc/hosts nou vereis hulle dat die gasheer 'n IPv6-adres byvoeg);
dubbele stapel ondersteuning KIND (Kubernetes IN Docker) en kubeadm;
opgedateerde e2e-toetse.

illustrasie gebruik dubbelstapel IPV4/IPv6 in KIND

Vordering op CSI

Stabiel verklaar topologie ondersteuning vir CSI-gebaseerde berging, die eerste keer bekendgestel in K8s 1.12.

Inisiatief vir migrasie van volume plugins na CSI - CSI Migrasie - Beta-weergawe bereik. Hierdie kenmerk is van kritieke belang om bestaande stoor-inproppe te vertaal (in-boom) na 'n moderne koppelvlak (CSI, buite-boom) onsigbaar vir Kubernetes eindgebruikers. Klusteradministrateurs sal slegs CSI-migrasie hoef te aktiveer, waarna bestaande statige hulpbronne en werkladings sal voortgaan om "net te werk" ... maar die nuutste CSI-drywers gebruik in plaas van die verouderde ingesluit in die Kubernetes-kern.

Op die oomblik is migrasie vir AWS EBS-bestuurders gereed in beta-weergawe (kubernetes.io/aws-ebs) en GCE PD (kubernetes.io/gce-pd). Voorspellings vir ander bergingsfasiliteite is soos volg:

Ons het gepraat oor hoe "tradisionele" bergingondersteuning in K8's na CSI gekom het Hierdie artikel. En die oorgang van CSI-migrasie na beta-status word toegewy aan aparte publikasie op die projekblog.

Daarbenewens het 'n ander beduidende funksionaliteit in die konteks van CSI, wat ontstaan (alfa-implementering) in K1.17s 8, beta-status bereik (dit wil sê by verstek geaktiveer) in die Kubernetes 1.12-vrystelling - die skep van momentopnames en herstel van hulle. Onder die veranderinge wat aan Kubernetes Volume Snapshot gemaak is op pad na beta-vrystelling:

die CSI eksterne-snapshotter-syspan in twee beheerders te verdeel,
geheim bygevoeg vir verwydering (skrap geheim) as 'n aantekening by die inhoud van 'n volume momentopname,
nuwe finaliseerder (finaliseerder) om te verhoed dat die snapshot API-voorwerp uitgevee word as daar oorblywende verbindings is.

Ten tyde van vrystelling 1.17 word die kenmerk ondersteun deur drie CSI-bestuurders: GCE Persistent Disk CSI Driver, Portworx CSI Driver en NetApp Trident CSI Driver. Meer besonderhede oor die implementering en gebruik daarvan kan gevind word in hierdie publikasie op die blog.

Wolkverskaffer-etikette

Etikette wat outomaties toegewys aan geskepde nodusse en volumes, afhangende van die wolkverskaffer wat gebruik word, is al baie lank in Kubernetes as 'n beta-weergawe beskikbaar - sedert die vrystelling van K8s 1.2 (April 2016!). Gegewe hul wydverspreide gebruik vir so lank, ontwikkelaars besluit, dat dit tyd is om die kenmerk stabiel (GA) te verklaar.

Daarom is hulle almal dienooreenkomstig hernoem (volgens topologie):

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

... maar is steeds beskikbaar onder hul ou name (vir terugwaartse versoenbaarheid). Alle administrateurs word egter aanbeveel om oor te skakel na huidige etikette. Verwante dokumentasie K8s is opgedateer.

Gestruktureerde uitset van kubeadm

Vir die eerste keer in alfa-weergawe aangebied gestruktureerde uitset vir die kubeadm-hulpprogram. Ondersteunde formate: JSON, YAML, Go-sjabloon.

Motivering vir die implementering van hierdie kenmerk (volgens Kep) is:

Terwyl Kubernetes met die hand ontplooi kan word, is die de facto (indien nie de jure) standaard vir hierdie operasie om kubeadm te gebruik. Gewilde stelselbestuurnutsmiddels soos Terraform maak staat op kubeadm vir Kubernetes-ontplooiing. Beplande verbeterings aan die Cluster API sluit 'n saamstelbare pakket vir Kubernetes-selflaai met kubeadm en cloud-init in.

Sonder gestruktureerde uitvoer, kan selfs die mees onskadelike veranderinge met die eerste oogopslag Terraform, Cluster API en ander sagteware wat die resultate van kubeadm gebruik, breek.

Ons onmiddellike planne sluit ondersteuning (in die vorm van gestruktureerde uitvoer) vir die volgende kubeadm-opdragte in:

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

Illustrasie van 'n JSON-reaksie op 'n opdrag 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 van ander innovasies

Oor die algemeen het die vrystelling van Kubernetes 1.17 plaasgevind onder die leuse "stabiliteit" Dit is vergemaklik deur die feit dat baie kenmerke daarin (hul totale aantal is 14) GA-status ontvang het. Tussen hulle:

"merk" nodusse volgens sekere voorwaardes (TaintNodesByCondition), verskyn in K8s 1.8;
Kyk Boekmerke - 'n nuwe tipe gebeurtenisse wat 'n etiket het dat alle voorwerpe tot 'n sekere weergawe is (resourceVersion) reeds deur horlosie verwerk is;
verstekwaardes (verstek) vir Pasgemaakte Hulpbronne;
tussen houers gedeel in die peulproses naamruimtes;
ScheduleDaemonSetPods - skedulering van peule in DaemonSet gebruik van kube-skeduleerder (in plaas van die DaemonSet-beheerder);
dinamiese grense op die aantal volumes afhangende van die nodus tipe;
omgewingsveranderlike ondersteuning vir gidsname gemonteer as subPath;
Kubelet hartklop oordrag na 'n gespesialiseerde huur-API;
"finaliseerder beskerming" (Finaliseerderbeskerming) vir lasbalanseerders (kontroleer die ooreenstemmende Dienshulpbronne voordat LoadBalancer-hulpbronne uitgevee word);
kube-apiserver-optimering in prestasie wanneer daar met veelvuldige horlosies gewerk word wat identiese stelle voorwerpe moniteer - bereik deur herhaalde serialisering van dieselfde voorwerpe vir elke kyker te vermy.

Ander veranderinge

Die volledige lys innovasies in Kubernetes 1.17 is natuurlik nie beperk tot dié wat hierbo gelys is nie. Hier is 'n paar ander (en vir 'n meer volledige lys, sien Changelog):

Die kenmerk wat in die laaste weergawe aangebied is, het die beta-weergawe bereik RunAsUserName vir vensters;
soortgelyke verandering oorgekom het EndpointSlice API (ook vanaf K8s 1.16), maar vir nou is hierdie oplossing om die werkverrigting/skaalbaarheid van die Endpoint API te verbeter nie by verstek geaktiveer nie;
peule is nou van kritieke belang vir groepwerk geskep kan word nie net in naamruimtes nie kube-system (vir besonderhede, sien die dokumentasie vir Beperk Prioriteitsklasverbruik);
nuwe opsie vir kubelet - --reserved-cpus - laat jou toe om die lys van SVE's wat vir die stelsel gereserveer is, eksplisiet te definieer;
vir kubectl logs aangebied nuwe vlag --prefix, die naam van die peul en bronhouer by elke reël van die log te voeg;
в label.Selector bygevoeg RequiresExactMatch;
alle houers in kube-dns loop nou met minder voorregte;
hiperkube geskei in 'n aparte GitHub-bewaarplek en sal nie meer by Kubernetes-vrystellings ingesluit word nie;
baie verbeterde prestasie kube-proxy vir nie-UDP-poorte.

Afhanklikheidsveranderinge:

CoreDNS weergawe ingesluit in kubeadm is 1.6.5;
crictl weergawe opgedateer na v1.16.1;
CSI 1.2.0;
ens 3.4.3;
Jongste getoetste Docker-weergawe opgegradeer na 19.03;
Die minimum Go-weergawe wat nodig is om Kubernetes 1.17 te bou, is 1.13.4.

Kubernetes 1.17: Hoogtepunte van wat nuut is