🥇Kubernetes 1.17: oersjoch fan 'e wichtichste ynnovaasjes

Juster, 9 desimber, barde folgjende release fan Kubernetes - 1.17. Neffens de tradysje dy't ús blog ûntwikkele hat, prate wy oer de wichtichste feroaringen yn 'e nije ferzje.

Kubernetes 1.17: oersjoch fan 'e wichtichste ynnovaasjes

De ynformaasje dy't brûkt wurdt om dit materiaal te meitsjen is nommen út 'e offisjele oankundiging, Kubernetes ferbetterings tracking tabellen, CHANGELOG-1.17 en relatearre problemen, pull-oanfragen, en Kubernetes Enhancement Proposals (KEP). Dus, wat is nij? ..

Topology-bewuste routing

De Kubernetes-mienskip hat in lange tiid op dizze funksje wachte - Topology-bewuste tsjinst routing. As HOED it ûntstiet yn oktober 2018, en de offisjele ferbetterjen - 2 jier lyn, de gewoane problemen (lykas it) - en noch in pear jier âlder...

It algemiene idee is om de mooglikheid te jaan om "lokale" routing út te fieren foar tsjinsten dy't yn Kubernetes wenje. "Lokaasje" betsjut yn dit gefal "itselde topologysk nivo" (topologynivo), dat kin wêze:

knooppunt identyk foar tsjinsten,
itselde serverrek,
deselde regio
deselde cloud provider,
...

Foarbylden fan it brûken fan dizze funksje:

besparring op ferkear yn wolk ynstallaasjes mei meardere beskikberens sônes (multi-AZ) - sjoch. farske yllustraasje mei it foarbyld fan ferkear út deselde regio, mar ferskillende AZ's yn AWS;
legere prestaasjes latency / bettere trochslach;
in sharded tsjinst dy't lokale ynformaasje hat oer it knooppunt yn elke shard;
pleatsing fan fluentd (as analogen) op deselde knooppunt mei de applikaasjes wêrfan logs wurde sammele;
...

Sokke routing, dy't "wit" oer de topology, wurdt ek wol netwurkaffiniteit neamd - nei analogy mei node affiniteit, pod affiniteit / anty-affiniteit of ferskynde net sa lang lyn Topology-Aware Volume Scheduling (en Volume foarsjenning). Aktuele nivo fan útfiering ServiceTopology yn Kubernetes - alfa ferzje.

Foar details oer hoe't de funksje wurket en hoe't jo it al kinne brûke, lês dit artikel fan ien fan de skriuwers.

IPv4 / IPv6 dual stack stipe

Signifikante foarútgong fêst yn in oare netwurkfunksje: simultane stipe foar twa IP-stacks, dy't earst yntrodusearre yn K8s 1.16. Benammen de nije release brocht de folgjende feroarings:

yn kube-proxy útfierd mooglikheid fan simultane operaasje yn beide modi (IPv4 en IPv6);
в Pod.Status.PodIPs ferskynde stipe foar downward API (tagelyk as yn /etc/hosts no hawwe se de host nedich om in IPv6-adres ta te foegjen);
dual stack stipe SOART (Kubernetes IN Docker) en kubeadm;
bywurke e2e tests.

Kubernetes 1.17: oersjoch fan 'e wichtichste ynnovaasjes
Yllustraasje mei help fan dual stack IPV4 / IPv6 yn KIND

Foarútgong op CSI

Stabyl ferklearre topology stipe foar CSI-basearre opslach, earst yntrodusearre yn K8s 1.12.

Inisjatyf foar migraasje fan folume plugins nei CSI - CSI Migraasje - berikte beta ferzje. Dizze funksje is kritysk foar it oersetten fan besteande opslach-plugins (yn beam) nei in moderne ynterface (CSI, out-of-tree) ûnsichtber foar Kubernetes ein brûkers. Klusterbehearders sille allinich CSI-migraasje moatte ynskeakelje, wêrnei't besteande steatlike boarnen en wurkloads sille trochgean "gewoan te wurkjen" ... mar mei de lêste CSI-bestjoerders ynstee fan 'e ferâldere opnaam yn' e Kubernetes-kearn.

Op it stuit is migraasje foar AWS EBS-bestjoerders klear yn beta-ferzje (kubernetes.io/aws-ebs) en GCE PD (kubernetes.io/gce-pd). Prognosen foar oare opslachfoarsjenningen binne as folget:

Kubernetes 1.17: oersjoch fan 'e wichtichste ynnovaasjes

Wy prate oer hoe't "tradisjonele" opslachstipe yn K8's nei CSI kaam dit artikel. En de oergong fan CSI-migraasje nei beta-status is wijd oan aparte publikaasje op it projektblog.

Derneist berikte in oare wichtige funksjonaliteit yn 'e kontekst fan CSI, dy't ûntstiet (alfa-ymplemintaasje) yn K1.17s 8, beta-status (dus standert ynskeakele) yn' e Kubernetes 1.12-release - it meitsjen fan snapshots en herstel fan harren. Under de wizigingen makke oan Kubernetes Volume Snapshot op 'e wei nei beta-release:

it splitsen fan de CSI eksterne-snapshotter-sidecar yn twa controllers,
tafoege geheim foar wiskjen (wiskje geheim) as annotaasje foar de ynhâld fan in folume momintopname,
nije finalizer (finalisator) om foar te kommen dat it snapshot API-objekt wurdt wiske as der oerbleaune ferbinings binne.

Op it momint fan frijlitting 1.17 wurdt de funksje stipe troch trije CSI-bestjoerders: GCE Persistent Disk CSI Driver, Portworx CSI Driver en NetApp Trident CSI Driver. Mear details oer de ymplemintaasje en gebrûk dêrfan kinne fûn wurde yn dizze publikaasje op it blog.

Cloud Provider Labels

Labels dat automatysk tawiisd oan oanmakke knopen en folumes ôfhinklik fan de brûkte wolkprovider, binne beskikber yn Kubernetes as in beta-ferzje foar in heul lange tiid - sûnt de frijlitting fan K8s 1.2 (april 2016!). Sjoen har wiidferspraat gebrûk sa lang, ûntwikkelders besletten, dat it tiid is om de funksje stabyl (GA) te ferklearjen.

Dêrom waarden se allegear omneamd (troch topology):

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

... mar binne noch beskikber ûnder har âlde nammen (foar efterútkompatibiliteit). Alle behearders wurde lykwols oanrikkemandearre om te wikseljen nei aktuele labels. Related Documentation K8s is bywurke.

Strukturearre útfier fan kubeadm

Presintearre yn alfa ferzje foar de earste kear strukturearre útfier foar it kubeadm-hulpprogramma. Stipe formaten: JSON, YAML, Go-sjabloan.

Motivaasje foar it útfieren fan dizze funksje (neffens HOED) is:

Wylst Kubernetes mei de hân ynset wurde kin, is de de facto (as net de jure) standert foar dizze operaasje om kubeadm te brûken. Populêre ark foar systeembehear lykas Terraform fertrouwe op kubeadm foar Kubernetes-ynset. Plande ferbetterings oan 'e Cluster API omfetsje in komponibel pakket foar Kubernetes bootstrapping mei kubeadm en cloud-init.
Sûnder strukturearre útfier kinne sels de meast ûnskuldige feroaringen op it earste each Terraform, Cluster API en oare software brekke dy't de resultaten fan kubeadm brûkt.

Us direkte plannen omfetsje stipe (yn 'e foarm fan strukturearre útfier) foar de folgjende kubeadm-kommando's:

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

Yllustraasje fan in JSON-antwurd op in 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="
}

Stabilisaasje fan oare ynnovaasjes

Yn 't algemien fûn de frijlitting fan Kubernetes 1.17 plak ûnder it motto "Stabiliteit" Dit waard fasilitearre troch it feit dat in protte funksjes dêryn (harren totale oantal is 14) krige GA-status. Under harren:

"markearje" knopen neffens bepaalde betingsten (TaintNodesByCondition), ferskynde yn K8s 1.8;
Sjoch Blêdwizers - in nij type eveneminten dy't in label hawwe dat alle objekten oant in bepaalde ferzje binne (resourceVersion) binne al ferwurke troch horloazje;
standert wearden (standert) foar oanpaste boarnen;
dield tusken konteners yn it podproses nammeromten;
ScheduleDaemonSetPods - planning pods yn DaemonSet mei help fan kube-scheduler (ynstee fan de DaemonSet-controller);
dynamyske grinzen op it oantal folumes ôfhinklik fan it knooppunt type;
omjouwingsfariabele stipe foar triemtafelnammen mounted as subPath;
Kubelet heartbeats oerdracht nei in spesjalisearre Lease API;
"finalizer beskerming" (Finalizer beskerming) foar load balancers (kontrolearje de oerienkommende tsjinstboarnen foardat jo LoadBalancer-boarnen wiskje);
kube-apiserver optimalisaasje yn prestaasjes by it wurkjen mei meardere horloazjes dy't identike sets fan objekten kontrolearje - berikt troch it foarkommen fan werhelle serialisaasje fan deselde objekten foar elke watcher.

Oare feroarings

De folsleine list mei ynnovaasjes yn Kubernetes 1.17 is fansels net beheind ta de hjirboppe neamde. Hjir binne guon oaren (en foar in mear folsleine list, sjoch CHANGELOG):

De funksje presintearre yn 'e lêste release hat de beta-ferzje berikt RunAsUserName foar Windows;
ferlykbere feroaring befallen EndpointSlice API (ek fan K8s 1.16), lykwols foar no is dizze oplossing om de prestaasjes / skaalberens fan 'e Endpoint API te ferbetterjen net standert ynskeakele;
pods binne no kritysk foar klusteroperaasje kinne makke wurde net allinnich yn nammeromten kube-system (foar details, sjoch de dokumintaasje foar Limit Priority Class konsumpsje);
nije opsje foar kubelet - --reserved-cpus - lit jo de list mei CPU's reservearre foar it systeem eksplisyt definiearje;
foar kubectl logs presintearre nije flagge --prefix, tafoegjen fan de namme fan 'e pod en boarne kontener oan elke rigel fan it log;
в label.Selector tafoege RequiresExactMatch;
alle konteners yn kube-dns rinne no mei minder privileezjes;
hyperkube skieden yn in aparte GitHub-repository en sil net mear wurde opnommen yn Kubernetes-releases;
folle ferbettere prestaasjes kube-proxy foar net-UDP-poarten.