🥇Kubernetes 1.16: overzicht van de belangrijkste vernieuwingen

Vandaag, op woensdag, plaatsvinden is er een nieuwe release van Kubernetes — 1.16. Volgens de traditie van onze blog vertellen we voor de tiende keer over de meest significante veranderingen in de nieuwe versie.

De informatie die is gebruikt voor de voorbereiding van dit materiaal, is afkomstig van de Kubernetes enhancements tracking tabel, CHANGELOG-1.16 en de bijbehorende issues, pull requests, evenals de Kubernetes Enhancement Proposals (KEP). Dus laten we beginnen!..

Nodes

Er zijn echt veel opvallende innovaties (in alfa-status) gepresenteerd aan de kant van de nodes van de K8s-clusters (Kubelet).

Ten eerste zijn er zogenaamde «ephemeral containers» (Ephemeral Containers), die zijn ontworpen om het debuggen in pods te vereenvoudigen.Een nieuw mechanisme maakt het mogelijk om speciale containers te starten die draaien in de naamruimte van bestaande pods en voor een korte tijd leven. Hun doel is interactie met andere pods en containers om problemen op te lossen en te debuggen. Voor deze functionaliteit is er een nieuwe opdracht geïmplementeerd, kubectl debug, die in wezen vergelijkbaar is met kubectl exec: maar in plaats van een proces in een container te starten (zoals in het geval van exec) start het een container in een pod. Bijvoorbeeld, de volgende opdracht verbindt een nieuwe container met een pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Details over ephemeral containers (en voorbeelden van hun gebruik) zijn te vinden in de bijbehorende KEP.De huidige implementatie (in K8s 1.16) is een alfa-versie, en onder de criteria voor de overgang naar beta-status staat "het testen van de Ephemeral Containers API gedurende ten minste 2 releases [Kubernetes]."

NB: In wezen doet de functie denken aan de al bestaande plugin kubectl-debug, waar we al eerder over hebben geschreven.Het wordt verwacht dat met de komst van ephemeral containers de ontwikkeling van een afzonderlijke externe plugin zal stoppen.

Een andere vernieuwing — PodOverhead — is ontworpen om te voorzien in een mechanisme voor het berekenen van overhead voor pods, die aanzienlijk kan variëren afhankelijk van de gebruikte runtime-omgeving. Als voorbeeld geven de auteurs van deze KEP Kata Containers, die een gastkernel, kata-agent, init-systeem, etc. vereisen. Wanneer de overhead zo groot wordt, kan deze niet worden genegeerd, en dus is er een manier nodig om deze te kunnen meenemen voor toekomstige quota, planning, enz. Voor de implementatie daarvan is er in PodSpec een veld toegevoegd, Overhead *ResourceList (overeenkomstig met de gegevens in RuntimeClass, indien van toepassing).

Een andere opvallende innovatie is de knooppunt topologiebeheerder (Node Topology Manager), die is ontworpen om de aanpak van het fijn afstemmen van de distributie van hardwarebronnen voor verschillende componenten in Kubernetes te uniformiseren. Deze initiatieven zijn voortgekomen uit de groeiende behoefte van verschillende moderne systemen (op het gebied van telecommunicatie, machine learning, financiële diensten, enz.) aan krachtige parallelle berekeningen en het minimaliseren van latentie bij de uitvoering van operaties, waarvoor ze gebruikmaken van geavanceerde mogelijkheden van CPU en hardwareversnelling. Dergelijke optimalisaties in Kubernetes werden tot nu toe bereikt via losse componenten (CPU manager, Device manager, CNI), en nu wordt er een enkele interne interface aan toegevoegd die de aanpak uniformiseert en de aansluiting van nieuwe soortgelijke componenten, de zogenaamde topology-aware componenten, aan de Kubelet-kant vereenvoudigt. Meer details zijn te vinden in de bijbehorende KEP..

Het componentdiagram van de Topology Manager

De volgende functie is de controle van containers tijdens hun opstart (startup probe). Zoals bekend is het voor containers die lang opstarten moeilijk om de actuele status te verkrijgen: ze worden ofwel 'gedood' voordat ze daadwerkelijk functioneren, of ze komen lange tijd in deadlock terecht. De nieuwe controle (geactiveerd via een feature gate genaamd StartupProbeEnabled) stelt de uitvoering van andere controles uit totdat de pod zijn opstart heeft voltooid. Om deze reden werd de functie oorspronkelijk aangeduid als pod-startup liveness-probe holdoff. Voor pods die lang opstarten, kan de statuscontrole op relatief korte tijdsintervallen plaatsvinden.

Bovendien wordt er direct in de bètafase een verbetering voor RuntimeClass gepresenteerd, die ondersteuning voor 'heterogene clusters' toevoegt. C RuntimeClass Scheduling is het nu niet langer noodzakelijk dat elke knoop ondersteuning heeft voor elke RuntimeClass: voor pods kan RuntimeClass worden gekozen zonder rekening te houden met de cluster topologie. Eerder moesten er bij het verkrijgen van dit doel regels voor NodeSelector en tolerations worden toegewezen, zodat pods op knopen met de ondersteuning voor alles wat ze nodig hadden terechtkwamen. In KEP worden voorbeelden van gebruik beschreven en uiteraard ook de details van de implementatie.

Netwerk

Twee significante netwerkwijzen die voor het eerst zijn geïntroduceerd (in de alfa-versie) in Kubernetes 1.16 zijn:

Ondersteuning dubbele netstack - IPv4/IPv6 — en de bijbehorende 'begrip' op het niveau van pod's, knooppunten, services. Het omvat de interactie tussen IPv4-naar-IPv4 en IPv6-naar-IPv6 tussen pod's, van pod's naar externe services, referentie-implementaties (binnen de plug-ins Bridge CNI, PTP CNI en Host-Local IPAM), evenals backward compatibility met Kubernetes-clusters die alleen op IPv4 of IPv6 werken. Details van de implementatie zijn te vinden in KEP.
Voorbeeld van de uitvoer van IP-adressen van twee soorten (IPv4 en IPv6) in de lijst met pod's:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nieuwe API voor Endpoint — EndpointSlice API. Het lost prestatie-/schaalbaarheidsproblemen van de bestaande Endpoint API op, die verschillende componenten in het control-plane (apiserver, etcd, endpoints-controller, kube-proxy) aangaan. De nieuwe API zal worden toegevoegd aan de API-groep Discovery en kan tienduizenden backend endpoints op elke service in een cluster, bestaande uit duizenden knooppunten, bedienen. Hiervoor wordt elke Service weergegeven in N objecten EndpointSlice, waarvan er standaard niet meer dan 100 endpoints per stuk zijn (de waarde is configureerbaar). De EndpointSlice API zal ook mogelijkheden voor toekomstige ontwikkelingen bevatten: ondersteuning voor meerdere IP-adressen per pod, nieuwe statussen voor endpoints (niet alleen Klaar en NotReady), dynamische subsettering voor endpoints.

Tot de bètaversie is het geïntroduceerde in de vorige release finalizer, genaamd service.kubernetes.io/load-balancer-cleanup en gekoppeld aan elke service van het type LoadBalancer. Bij het verwijderen van een dergelijke service voorkomt het feitelijke verwijdering van de resource totdat de 'opruiming' van alle bijbehorende load balancer-resources is voltooid.

API Machinery

Een echte 'mijlpaal in stabilisatie' is vastgelegd op het gebied van de Kubernetes API-server en de interactie daarmee. Dit is voor een groot deel te danken aan de overgang naar de status stabiel van resources die geen bijzondere presentatie vereisen CustomResourceDefinitions (CRD), die sinds ver terug in Kubernetes 1.7 (dat is juni 2017!) de status bètaversie hadden. Eenzelfde stabilisatie is ook gekomen voor de gerelateerde functies:

subresources voor /status en /scale CustomResources;
versieconversie voor CRD, gebaseerd op een externe webhook;
recentelijk geïntroduceerde (in K8s 1.15) standaardwaarden (defaulting) en automatische verwijdering van velden (pruning) CustomResources;
de mogelijkheid toepassing van het OpenAPI v3-schema voor het creëren en publiceren van OpenAPI-documentatie, die wordt gebruikt voor de validatie van CRD-resources aan de serverzijde.

Een ander mechanisme dat al lang gebruikelijk is voor Kubernetes-beheerders: toegangs-webhook was ook lange tijd in de bètastatus (vanaf K8s 1.9) en is nu als stabiel verklaard.

Twee andere functies hebben de bètaversie bereikt: server-side toepassen en bewakings-bladwijzers.

En de enige significante vernieuwing in de alfaversie was afschaffing van SelfLink een speciale URI die het genoemde object vertegenwoordigt en een onderdeel is van ObjectMeta en ListMeta (d.w.z. een onderdeel van elk object in Kubernetes). Waarom wordt het afgeschaft? De motivatie eenvoudigweg is dat er geen echte (onoverkomelijke) redenen zijn om dit veld nog te laten bestaan. Formeelere redenen zijn een prestatieoptimalisatie (door het onnodige veld te verwijderen) en het vereenvoudigen van het werk van de generic-apiserver, die met dit veld op een bijzondere manier moet omgaan (dit is het enige veld dat direct vóór de serialisatie van het object wordt ingesteld). De daadwerkelijke "veroudering" (in de bètaversie) SelfLink zullen plaatsvinden in versie Kubernetes 1.20, en de definitieve in 1.21.

Gegevensopslag

Het belangrijkste werk op het gebied van opslag, zoals in eerdere releases, wordt waargenomen in het gebied van ondersteuning voor CSI. De belangrijkste wijzigingen hier zijn:

voor het eerst (in de alfaversie) 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 voor CSI-plugins voor werkknopen met Windows: de actuele manier om met opslag te werken, zal hier de in-tree-plugins in de kernel van Kubernetes en de FlexVolume-plugins van Microsoft op basis van Powershell vervangen;

Het schema voor de implementatie van CSI-plugins in Kubernetes voor Windows
de mogelijkheid de mogelijkheid om CSI-volumes te wijzigen, voorgesteld in K8s 1.12, heeft de bètaversie bereikt;
evenzo heeft de mogelijkheid om CSI te gebruiken voor het maken van lokale ephemeral volumes (CSI Inline Volume Support).

De functie voor het klonen van volumes ontstaan in de vorige versie van Kubernetes (gebruik van bestaande PVC's als DataSource voor het creëren van nieuwe PVC's) heeft nu ook de status bètaversie gekregen.

Scheduler

Twee belangrijke wijzigingen in het plannen (allebei in de alfaversie):

EvenPodsSpreading - de mogelijkheid om voor een "eerlijkere verdeling" van belastingen pods in plaats van logische eenheden van de applicatie te gebruiken (zoals Deployment en ReplicaSet) en het reguleren van deze verdeling (als harde eis of als zachte voorwaarde, dat wil zeggen prioriteit). Deze functie zal de bestaande mogelijkheden voor het verdelen van geplande pods uitbreiden, die nu beperkt zijn tot de opties PodAffinity en PodAntiAffinity, waardoor beheerders betere controle over deze kwestie hebben, wat resulteert in een hogere beschikbaarheid en een geoptimaliseerd verbruik van middelen. Meer details zijn te vinden in KEP.
Gebruik van BestFit-beleid in RequestedToCapacityRatio Prioriteitsfunctie tijdens het plannen van pods, wat het mogelijk maakt toepassen bin packing ("containerverpakking") zowel voor basisbronnen (processor, geheugen) als uitgebreide bronnen (zoals GPU). Meer informatie is te vinden in KEP.

Pod-planning: vóór het gebruik van het best fit-beleid (direct via de standaard scheduler) en met gebruikmaking hiervan (via de scheduler extender)

Daarnaast aangeboden de mogelijkheid om eigen plug-ins voor de planner te creëren buiten de hoofdontwikkelingsstructuur van Kubernetes (out-of-tree).

Andere veranderingen

Daarnaast kunnen we in Kubernetes 1.16 de volgende inspanningen opmerken om te zorgen voor een volledige herstructurering van de bestaande metrics, meer specifiek — in overeenstemming met officiële richtlijnen voor K8s-instrumentatie. Ze zijn in feite gebaseerd op de bijbehorende Prometheus-documentatie. De inconsistenties zijn om verschillende redenen ontstaan (bijvoorbeeld, sommige metrics zijn simpelweg gecreëerd voordat de huidige instructies verschenen), en de ontwikkelaars hebben besloten dat het tijd was om alles naar een uniforme standaard te brengen, "in overeenstemming met de rest van het Prometheus-ecosysteem". De huidige implementatie van deze inspanning heeft de status van een alpha-versie, die geleidelijk zal worden opgewaardeerd in latere Kubernetes-versies naar beta (1.17) en stabiel (1.18).

Daarnaast kunnen we de volgende wijzigingen opmerken:

De ontwikkeling van ondersteuning voor Windows met met de komst van de Kubeadm-tool voor dit OS (alpha-versie), de mogelijkheid RunAsUserName voor Windows-containers (alpha-versie), verbetering ondersteuning voor Group Managed Service Account (gMSA) tot aan de beta-versie, ondersteuning voor mount/attach voor vSphere-volumes.
Hernieuwd mechanisme voor gegevenscompressie in API-antwoorden. Eerder werd hiervoor een HTTP-filter gebruikt, dat een aantal beperkingen oplegde die het onmogelijk maakten om dit standaard in te schakelen. Nu werkt "transparante compressie van aanvragen": klanten die Accept-Encoding: gzip in de header verzenden, krijgen een GZIP-gecomprimeerd antwoord, als de grootte daarvan meer dan 128 kb bedraagt. Klanten in Go ondersteunen automatisch compressie (verzenden de benodigde header), zodat ze direct een vermindering van het verkeer zullen opmerken. (Voor andere talen kunnen kleine aanpassingen nodig zijn.)
Het is nu mogelijk om HPA-schaalvergroting van/naar nul pods op basis van externe metricsAls schaling plaatsvindt op basis van objecten/externe metrics, kan het aantal replica's automatisch teruggebracht worden tot 0 wanneer workloads inactief zijn, om zo middelen te besparen. Deze functie is vooral nuttig in situaties waarin workers GPU-bronnen aanvragen, en het aantal verschillende types inactieve workers groter is dan het aantal beschikbare GPU's.
Nieuwe klant — k8s.io/client-go/metadata.Client — voor 'algemene' toegang tot objecten. Het is bedoeld om eenvoudig metadata te verkrijgen (d.w.z. onderverdeling metadata) uit clusterbronnen en ermee operaties uit te voeren zoals opschonen en quota-beheer.
Kubernetes verzamelen kan nu zonder verouderde ('in-bomen') cloudproviders (alpha-versie).
In de kubeadm-tool toegevoegd is er een experimentele (alpha-versie) mogelijkheid toegevoegd om kustomize-patches toe te passen tijdens de , wat erg handig is. Bovendien kunnen meerdere configuraties worden geschreven: ontwikkelen op de standaardconfiguratie, en daarna implementeren met het commando, join en upgrade. Meer informatie over hoe de vlag --experimental-kustomize, kan worden gebruikt, kijk in KEP.
Nieuwe endpoint voor apiserver — readyz, — die het mogelijk maakt om informatie over zijn gereedheid (readiness) te exporteren. Ook heeft de API-server een vlag gekregen --maximum-startup-sequence-duration, die het mogelijk maakt om zijn herstarts te reguleren.
Twee functies voor Azure zijn nu stabiel: ondersteuning voor beschikbaarheidzones (Availability Zones) en cross resource group (RG). Daarnaast zijn er in Azure toegevoegd:
- ondersteuning voor authenticatie AAD en ADFS;
- annotatie service.beta.kubernetes.io/azure-pip-name voor het opgeven van een openbaar IP voor de load balancer;
- de mogelijkheid het instellen van LoadBalancerName en LoadBalancerResourceGroup.
AWS heeft nu ondersteuning voor voor EBS in Windows en geoptimaliseerde API-aanroepen EC2 DescribeInstances.
Kubeadm migreert nu automatisch de CoreDNS-configuratie bij een versie-upgrade van CoreDNS. Binaries
in het relevante Docker-image etcd zijn world-executable gemaakt, wat het mogelijk maakt om deze afbeelding zonder root-rechten uit te voeren. Bovendien heeft het etcd-migratie-image de ondersteuning voor etcd2 stopgezet. Cluster Autoscaler 1.16.0 heeft overgeschakeld naar het gebruik van distroless als basisimage, de prestaties verbeterd en nieuwe cloudproviders (DigitalOcean, Magnum, Packet) toegevoegd.
In Updates in de gebruikte/afhankelijke software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2. Kubernetes 1.15: overzicht van belangrijke nieuwe functies
Kubernetes 1.13: overzicht van belangrijke nieuwe functies

Kubernetes 1.16: overzicht van de belangrijkste vernieuwingen