Kubernetes 1.17: overzicht van de belangrijkste vernieuwingen

Gisteren, 9 december, heeft plaatsgevonden was er weer een release van Kubernetes — 1.17. Zoals gebruikelijk in onze blog, bespreken we de belangrijkste wijzigingen in deze nieuwe versie.

De informatie die voor het opstellen van dit materiaal is gebruikt, is afkomstig uit de officiële aankondiging, de Kubernetes enhancements tracking tabel, CHANGELOG-1.17 en de bijbehorende issues, pull requests, evenals Kubernetes Enhancement Proposals (KEP). Dus, wat is er nieuw?..

Routering met inachtneming van topologie

De Kubernetes-gemeenschap wacht al lange tijd op deze functie — Topology-aware service routing. Als KEP die zijn oorsprong vindt in oktober 2018, met de officiële enhancement — 2 jaar geleden, terwijl gewone issues (zoals dit) — zelfs nog enkele jaren ouder zijn…

Het algemene idee is om de mogelijkheid te bieden om "lokale" routering te implementeren voor services binnen Kubernetes. "Lokaliteit" betekent in dit geval "dezelfde topologische laag" (topology level), die kan zijn:

• dezelfde knoop voor services,
• hetzelfde serverrack,
• dezelfde regio,
• dezelfde cloudprovider,
• …

Voorbeelden van het gebruik van deze functie:

• besparing op verkeer in cloudinstallaties met meerdere beschikbaarheidszones (multi-AZ) — zie. de recente illustratie aan de hand van het verkeer van één regio, maar verschillende AZ's in AWS;
• minder prestatievertragingen/betere doorvoersnelheid;
• een gesharded service die lokale informatie over de knoop heeft in elke shard;
• het plaatsen van fluentd (of gelijksoortigen) op dezelfde knoop als de applicaties waarvan de logs worden verzameld;
• …

Deze routering, die bekend is met de topologie, wordt ook wel network affinity genoemd — in analogie met node affinity, pod affinity/anti-affinity of de onlangs geïntroduceerde Topology-Aware Volume Scheduling Volume Provisioning (en ). Het huidige niveau van implementatieServiceTopology in Kubernetes is alpha-versie. Voor details over hoe de functie werkt en hoe je deze al kunt gebruiken, lees je in

van een van de auteurs. dit artikel Ondersteuning voor dubbel IPv4/IPv6-stacks

Er is aanzienlijke vooruitgang

vermeld in een andere netwerkfunctie: gelijktijdige ondersteuning voor twee IP-stacks, die voor het eerst werd gepresenteerd in K8s 1.16. In het bijzonder heeft de nieuwe release de volgende wijzigingen gebracht:in kube-proxy

• de mogelijkheid om gelijktijdig in beide modi (IPv4 en IPv6) te werken; geïmplementeerd Pod.Status.PodIPs
• in ondersteuning van downward API (tegelijkertijd met dit vereisen hosts nu ook om een IPv6-adres toe te voegen); in de testbuild Canary, en is onlangs overgebracht naar de release. Om het te activeren, moet u naar het gedeelte flags chrome://flags gaan, het vlag 'Filesystem API in Incognito' zoeken via de zoekfunctie en deze inschakelen. Na het opnieuw opstarten van de browser zal de incognito-modus volledig functioneren. ondersteuning van beide stacks in /etc/hosts (Kubernetes IN Docker) en
• bijgewerkte e2e-tests. KIND (Kubernetes IN Docker) en kubeadm;
• geüpdatete e2e-tests.

Victoria Dimitrakopoulos gebruik van de dubbele stack IPV4/IPv6 in KIND

Vooruitgang voor CSI

Aangekondigd als stabiel ondersteuning voor topologieën voor opslag op basis van CSI, voor het eerst gepresenteerd in K8s 1.12.

Initiatief voor migratie van volume-plugins naar CSI — CSI Migratie — heeft de bètaversie bereikt. Deze functie is cruciaal voor het migreren van bestaande opslag-plugins (in-tree) naar de moderne interface (CSI, out-of-tree) zonder dat eindgebruikers van Kubernetes hier iets van merken. Clusterbeheerders hoeven alleen CSI Migratie in te schakelen, waarna bestaande stateful-resources en workloads "gewoon blijven werken"... maar nu met de actuele CSI-drivers in plaats van verouderde, ingebouwde drivers van Kubernetes.

Op dit moment is de migratie voor AWS EBS-drivers (kubernetes.io/aws-ebs) en GCE PD (kubernetes.io/gce-pd) klaar in bètaversie. Prognoses voor andere opslag zijn als volgt:

We hebben in dit artikeluitgelegd hoe de "traditionele" ondersteuning voor opslag in K8s bij CSI is gekomen. De overgang van CSI-migratie naar bètaversie is gewijd aan een aparte publicatie op de blog van het project.

Bovendien heeft een andere significante functionaliteit binnen CSI, die zijn (alpha-implementatie) heeft in K8s 1.12, de status van bètaversie (d.w.z. standaard inschakeling) bereikt in de release van Kubernetes 1.17 — snapshotcreatie en herstel daaruit. Onder de wijzigingen in Kubernetes Volume Snapshot op weg naar de bètarelease:

• de sidecar van de CSI external-snapshotter is opgesplitst in twee controllers,
• een geheim voor verwijdering (deletion secret) is toegevoegd als annotatie op de inhoud van de volumesnapshot,
• een nieuwe finalizer voor het voorkomen van verwijdering van het API-object van de snapshot met bestaande relaties. Bij de release van 1.17 wordt deze functie ondersteund door drie CSI-drivers: GCE Persistent Disk CSI Driver, Portworx CSI Driver en NetApp Trident CSI Driver. Meer informatie over de implementatie en gebruik kan gelezen worden in

de blog. deze publicatie Cloud Provider Labels

Labels die automatisch

worden toegewezen aan de gemaakte knooppunten en volumes, afhankelijk van de gebruikte cloudprovider , waren al zeer lang beschikbaar in Kubernetes als bètaversie — sinds de release van K8s 1.2(april 2016!) . Gezien hun brede toepassing gedurende zo lange tijd, hebben de ontwikkelaars, dat het tijd was om de functie stabiel (GA) te verklaren. hebben beslotenDaarom zijn ze allemaal overeenkomstig hernoemd (volgens topologieën):

beta.kubernetes.io/instance-type

• node.kubernetes.io/instance-type → topology.kubernetes.io/zone
• failure-domain.beta.kubernetes.io/zone → failure-domain.beta.kubernetes.io/region
• topology.kubernetes.io/region → topology.kubernetes.io/region

… maar ze blijven beschikbaar onder hun oude namen (voor de achterwaartse compatibiliteit). Toch wordt alle beheerders aangeraden over te schakelen naar de actuele labels. Bijbehorende documentatie K8s is bijgewerkt.

Gestructureerde uitvoer van kubeadm

Voor het eerst gepresenteerd in de alfa-versie gestructureerde uitvoer voor de kubeadm tool. Ondersteunde formaten: JSON, YAML, Go-sjabloon.

De motivatie voor de implementatie van deze functie (volgens KEP) is als volgt:

Hoewel Kubernetes handmatig kan worden uitgerold, is de de facto standaard (indien niet de jure) voor deze operatie het gebruik van kubeadm. Populaire systeembeheertools zoals Terraform vertrouwen op kubeadm voor het implementeren van Kubernetes. Geplande verbeteringen in het Cluster API omvatten een samengestelde package voor het bootstrappen van Kubernetes met kubeadm en cloud-init.

Zonder gestructureerde uitvoer kunnen zelfs de schijnbaar onschadelijke wijzigingen Terraform, Cluster API en andere software die gebruikmaakt van de uitvoer van kubeadm breken.

Ondersteuning (in de vorm van gestructureerde uitvoer) voor de volgende kubeadm-commando's staat op de agenda:

• alpha certs
• config images list
• , wat erg handig is. Bovendien kunnen meerdere configuraties worden geschreven: ontwikkelen op de standaardconfiguratie, en daarna implementeren met het commando
• token create
• token list
• upgrade plan
• version

Illustratie van de JSON-respons op het commando 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": "Het standaard bootstrap token dat is gegenereerd door 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilisatie van andere innovaties

Over het algemeen werd de release van Kubernetes 1.17 gekenmerkt door de slogan "Stabiliteit”. Dit werd bevorderd door het feit dat veel functies daarin (in totaal 14) de status GA hebben gekregen. Onder deze bevinden zich:

• het ‘labelen’ van knooppunten op basis van bepaalde voorwaarden (TaintNodesByCondition), geïntroduceerd in K8s 1.8;
• Watch Bookmarks — een nieuw type gebeurtenis die een label heeft dat alle objecten tot een bepaalde versie (resourceVersion) al zijn verwerkt door de watcher;
• standaardwaarden (defaulting) voor Custom Resources;
• gedeeld tussen containers in de pod process namespaces;
• ScheduleDaemonSetPods — het plannen van pods in een DaemonSet met behulp van kube-scheduler (in plaats van de DaemonSet-controller);
• dynamische limieten voor het aantal volumes afhankelijk van het type knooppunt;
• ondersteuning voor omgevingsvariabelen voor de namen van directories die gemonteerd worden als subPath;
• de overdracht van Kubelet heartbeats naar de gespecialiseerde Lease API;
• «finalizer bescherming» (Finalizer Protection) voor load balancers (controle van de relevante Service-resources voordat de LoadBalancer-resources worden verwijderd);
• optimalisatie van kube-apiserver in de prestaties bij het werken met meerdere watches die identieke sets objecten observeren — dit wordt bereikt door de herhaalde serialisatie van dezelfde objecten voor elke watcher te vermijden.

Overige wijzigingen

De volledige lijst met nieuwigheden in Kubernetes 1.17 is natuurlijk niet beperkt tot de bovengenoemde. Hier zijn enkele andere (en voor een completere lijst — zie CHANGELOG):

• de beta-versie ‘bereikte’ de functie die in de vorige release werd gepresenteerd RunAsUserName voor Windows;
• een overeenkomstige wijziging bereikte EndpointSlice API (ook uit K8s 1.16), maar deze oplossing voor prestatie- / schaalverbetering van de Endpoint API is nog niet standaard geactiveerd;
• kritieke pods voor de werking van de cluster kunnen nu niet alleen in namespaces (details zie de documentatie over kube-system Limit Priority Class consumption een nieuwe optie voor kubelet —);
• --reserved-cpus — stelt je in staat om expliciet een lijst van CPU's te definiëren die zijn gereserveerd voor het systeem; een nieuwe vlag
• voor kubectl logs is gepresenteerd , die de naam van de pod en de container-bron aan elke regel van de log toevoegt; --prefixlabel.Selector
• in RequiresExactMatch toegevoegd alle containers in kube-dns;
• worden nu uitgevoerd met minder privileges; is apart gemaakt in een GitHub-repository en zal niet meer worden opgenomen in Kubernetes-releases;
• hyperkube de prestaties
• significant van kube-proxy voor niet-UDP-poorten is verbeterd. Wijzigingen in afhankelijkheden:

de versie van CoreDNS in kubeadm is 1.6.5;

• de versie van crictl is bijgewerkt naar v1.16.1;
• CSI 1.2.0;
• etcd 3.4.3;
• de laatste goedgekeurde Docker-versie is verhoogd naar 19.03;
• de minimale versie van Go die nodig is om Kubernetes 1.17 te bouwen is 1.13.4.
• Gisteren, 9 december, vond de laatste release van Kubernetes - 1.17 - plaats.

P.S.

Lees ook op onze blog:

• «Kubernetes 1.16: overzicht van de belangrijkste vernieuwingen»;
• «Kubernetes 1.12: overzicht van belangrijke nieuwe functies»;
• «Kubernetes 1.14: overzicht van de belangrijkste vernieuwingen»;
• «🥇Kubernetes 1.16: overzicht van belangrijke nieuwe functies | ProHoster».

Bron: habr.com