🥇Kubernetes 1.16: overzicht van de belangrijkste innovaties

Vandaag, woensdag, состоится volgende release van Kubernetes - 1.16. Volgens de traditie die zich voor onze blog heeft ontwikkeld, is het dit jaar de tiende verjaardag dat we het hebben over de belangrijkste veranderingen in de nieuwe versie.

De informatie die is gebruikt om dit materiaal te bereiden, is afkomstig uit Kubernetes verbetert trackingtabellen, WIJZIGINGSLOG-1.16 en aanverwante problemen, pull-aanvragen en Kubernetes Enhancement Proposals (KEP). Dus laten we gaan!..

Knooppunten

Een werkelijk groot aantal opmerkelijke innovaties (in alfaversiestatus) worden gepresenteerd aan de zijkant van de K8s-clusterknooppunten (Kubelet).

In de eerste plaats de zgn «kortstondige containers» (kortstondige containers), ontworpen om foutopsporingsprocessen in pods te vereenvoudigen. Met het nieuwe mechanisme kun je speciale containers lanceren die beginnen in de naamruimte van bestaande pods en een korte tijd actief zijn. Hun doel is om te communiceren met andere pods en containers om eventuele problemen op te lossen en fouten op te lossen. Voor deze functie is een nieuw commando geïmplementeerd kubectl debug, in wezen vergelijkbaar met kubectl exec: alleen in plaats van een proces in een container uit te voeren (zoals in exec) het lanceert een container in een pod. Met deze opdracht wordt bijvoorbeeld een nieuwe container met een pod verbonden:

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

Details over kortstondige containers (en voorbeelden van hun gebruik) zijn te vinden in overeenkomstige KEP. De huidige implementatie (in K8s 1.16) is een alfaversie, en een van de criteria voor de overdracht naar een bètaversie is “het testen van de Ephemeral Containers API voor ten minste twee releases van [Kubernetes].”

NB: In essentie en zelfs in zijn naam lijkt de functie op een reeds bestaande plug-in kubectl-debugwaarover wij schreef al. De verwachting is dat met de komst van kortstondige containers de ontwikkeling van een aparte externe plug-in zal stoppen.

Nog een innovatie - PodOverhead - ontworpen om te bieden mechanisme voor het berekenen van de overheadkosten voor pods, wat sterk kan variëren, afhankelijk van de gebruikte runtime. Als voorbeeld de auteurs deze KEP resulteren in Kata Containers, waarvoor de gastkernel, kata-agent, init-systeem, enz. vereist is. Wanneer de overhead zo groot wordt, kan deze niet worden genegeerd, wat betekent dat er een manier moet zijn om er rekening mee te houden bij verdere quota, planning, enz. Om het in te implementeren PodSpec veld toegevoegd Overhead *ResourceList (Vergeleken met gegevens in RuntimeClass, als er een wordt gebruikt).

Een andere opmerkelijke innovatie is knooppunttopologiebeheerder (Knooptopologiebeheer), ontworpen om de aanpak voor het verfijnen van de toewijzing van hardwarebronnen voor verschillende componenten in Kubernetes te verenigen. Dit initiatief wordt gedreven door de groeiende behoefte van verschillende moderne systemen (uit de telecommunicatie, machinaal leren, financiële diensten, enz.) aan krachtige parallelle computing en het minimaliseren van vertragingen bij de uitvoering van bewerkingen, waarvoor ze geavanceerde CPU- en mogelijkheden voor hardwareversnelling. Dergelijke optimalisaties in Kubernetes zijn tot nu toe bereikt dankzij ongelijksoortige componenten (CPU-manager, Device Manager, CNI), en nu zal er één enkele interne interface aan worden toegevoegd die de aanpak verenigt en de verbinding van nieuwe, vergelijkbare (zogenaamde topologie) vereenvoudigt. bewust - componenten aan de Kubelet-kant. Details - binnen overeenkomstige KEP.

Componentdiagram van topologiemanager

Volgende functie - het controleren van containers terwijl ze in bedrijf zijn (opstart sonde). Zoals u weet is het voor containers die er lang over doen om te lanceren lastig om een actuele status te krijgen: ze worden óf ‘gedood’ voordat ze daadwerkelijk gaan functioneren, óf ze belanden voor een lange tijd in een impasse. Nieuwe cheque (ingeschakeld via functiepoort genoemd StartupProbeEnabled) annuleert (of beter gezegd, stelt uit) het effect van andere controles tot het moment dat de pod klaar is met werken. Om deze reden werd de functie oorspronkelijk genoemd pod-startup liveness-probe holdoff. Voor pods waarvan het lang duurt om te starten, kunt u de status in relatief korte tijdsintervallen opvragen.

Bovendien is een verbetering voor RuntimeClass onmiddellijk beschikbaar in bètastatus, waardoor ondersteuning wordt toegevoegd voor “heterogene clusters”. C RuntimeClass-planning Nu is het helemaal niet nodig dat elke node ondersteuning heeft voor elke RuntimeClass: voor pods kun je een RuntimeClass selecteren zonder na te denken over de clustertopologie. Om dit te bereiken (zodat pods op knooppunten terechtkomen met ondersteuning voor alles wat ze nodig hebben) was het voorheen nodig om de juiste regels en toleranties toe te wijzen aan NodeSelector. IN KEP Er wordt gesproken over gebruiksvoorbeelden en uiteraard over implementatiedetails.

Сеть

Twee belangrijke netwerkfuncties die voor het eerst (in alfaversie) in Kubernetes 1.16 verschenen zijn:

Ondersteunen dubbele netwerkstack - IPv4/IPv6 - en het bijbehorende “begrip” op het niveau van pods, knooppunten en diensten. Het omvat IPv4-naar-IPv4 en IPv6-naar-IPv6-interoperabiliteit tussen pods, van pods tot externe services, referentie-implementaties (binnen de Bridge CNI-, PTP CNI- en Host-Local IPAM-plug-ins), evenals omgekeerd Compatibel met draaiende Kubernetes-clusters Alleen IPv4 of IPv6. Implementatiedetails zijn binnen KEP.
Een voorbeeld van het weergeven van IP-adressen van twee typen (IPv4 en IPv6) in de lijst met pods:
```
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 eindpunt - EndpointSlice-API. Het lost de prestatie-/schaalbaarheidsproblemen op van de bestaande Endpoint API die verschillende componenten in het besturingsvlak beïnvloeden (apiserver, etcd, endpoints-controller, kube-proxy). De nieuwe API zal worden toegevoegd aan de Discovery API-groep en zal tienduizenden backend-eindpunten kunnen bedienen op elke service in een cluster bestaande uit duizenden knooppunten. Om dit te doen, wordt elke service toegewezen aan N objecten EndpointSlice, die elk standaard niet meer dan 100 eindpunten hebben (de waarde is configureerbaar). De EndpointSlice API zal ook kansen bieden voor de toekomstige ontwikkeling ervan: ondersteuning voor meerdere IP-adressen voor elke pod, nieuwe statussen voor eindpunten (niet alleen Ready и NotReady), dynamische subinstelling voor eindpunten.

Degene die in de laatste release werd gepresenteerd, heeft de bètaversie bereikt finaliseerder, genaamd service.kubernetes.io/load-balancer-cleanup en gekoppeld aan elke service met type LoadBalancer. Op het moment dat een dergelijke service wordt verwijderd, wordt de daadwerkelijke verwijdering van de bron voorkomen totdat het “opschonen” van alle relevante balancerbronnen is voltooid.

API-machines

De echte ‘stabilisatiemijlpaal’ ligt op het gebied van de Kubernetes API-server en de interactie daarmee. Dit gebeurde grotendeels dankzij het overbrengen naar een stabiele status van degenen die geen speciale introductie nodig hebben CustomResourceDefinities (CRD), die een bètastatus hebben sinds de verre dagen van Kubernetes 1.7 (en dit is juni 2017!). Dezelfde stabilisatie kwam tot stand voor de gerelateerde kenmerken:

"subbronnen" met /status и /scale voor CustomResources;
transformatie versies voor CRD, gebaseerd op externe webhook;
onlangs gepresenteerd (in K8s 1.15) standaardwaarden (in gebreke) en automatische veldverwijdering (snoeien) voor CustomResources;
kans het OpenAPI v3-schema gebruiken om OpenAPI-documentatie te maken en te publiceren die wordt gebruikt om CRD-bronnen aan de serverzijde te valideren.

Een ander mechanisme dat al lang bekend is bij Kubernetes-beheerders: toegangswebhook - bleef ook lange tijd in bètastatus (sinds K8s 1.9) en is nu stabiel verklaard.

Twee andere functies hebben de bètafase bereikt: serverzijde van toepassing и kijk naar bladwijzers.

En de enige belangrijke innovatie in de alfaversie was mislukking van SelfLink — een speciale URI die het gespecificeerde object vertegenwoordigt en er deel van uitmaakt ObjectMeta и ListMeta (d.w.z. onderdeel van elk object in Kubernetes). Waarom laten ze het achterwege? Motivatie op een eenvoudige manier klanken als het ontbreken van echte (overweldigende) redenen waarom dit vakgebied nog steeds bestaat. Meer formele redenen zijn het optimaliseren van de prestaties (door een onnodig veld te verwijderen) en het vereenvoudigen van het werk van de generieke apiserver, die gedwongen wordt zo'n veld op een speciale manier te behandelen (dit is het enige veld dat vlak voor het object wordt geplaatst is geserialiseerd). Echte veroudering (binnen bèta) SelfLink zal gebeuren door Kubernetes versie 1.20 en definitief - 1.21.

Data opslag

Het belangrijkste werk op het gebied van opslag wordt, net als in eerdere releases, in het gebied waargenomen CSI-ondersteuning. De belangrijkste veranderingen hier waren:

voor de eerste keer (in alfaversie) verscheen Ondersteuning voor CSI-plug-ins voor Windows-werkknooppunten: de huidige manier van werken met storage gaat ook in-tree plugins in de Kubernetes core en FlexVolume plugins van Microsoft op basis van Powershell vervangen;

Schema voor het implementeren van CSI-plug-ins in Kubernetes voor Windows
kans het formaat van CSI-volumes wijzigen, geïntroduceerd in K8s 1.12, is uitgegroeid tot een bètaversie;
Een soortgelijke "promotie" (van alfa naar bèta) werd bereikt door de mogelijkheid om CSI te gebruiken om lokale kortstondige volumes te creëren (CSI Inline-volumeondersteuning).

Geïntroduceerd in de vorige versie van Kubernetes functie voor het klonen van volumes (gebruik bestaand PVC zoals DataSource om nieuw PVC te creëren) heeft nu ook een bètastatus gekregen.

Планировщик

Twee opmerkelijke wijzigingen in de planning (beide in alfa):

EvenPodsSpreading - mogelijkheid gebruik pods in plaats van logische applicatie-eenheden voor een “eerlijke verdeling” van belastingen (zoals Deployment en ReplicaSet) en het aanpassen van deze verdeling (als harde vereiste of als zachte voorwaarde, d.w.z. prioriteit). De functie zal de bestaande distributiemogelijkheden van geplande pods uitbreiden, momenteel beperkt door opties PodAffinity и PodAntiAffinity, waardoor beheerders hierover een betere controle krijgen, wat een betere hoge beschikbaarheid en een geoptimaliseerd gebruik van hulpbronnen betekent. Details - binnen KEP.
Gebruiken BestFit-beleid в RequestedToCapacityRatio Prioriteitsfunctie tijdens de podplanning, wat dit mogelijk maakt van toepassing zijn bak verpakking (“packing in containers”) voor zowel basisbronnen (processor, geheugen) als uitgebreide bronnen (zoals GPU). Voor meer details, zie KEP.

Pods plannen: voordat u het best passende beleid gebruikt (rechtstreeks via de standaardplanner) en bij gebruik ervan (via de planner-extender)

Bovendien gepresenteerd de mogelijkheid om uw eigen planner-plug-ins te maken buiten de hoofdontwikkelingsboom van Kubernetes (buiten de boom).

Andere wijzigingen

Ook in de Kubernetes 1.16 release is het te merken initiatief voor brengen beschikbare statistieken in volledige volgorde, of beter gezegd, in overeenstemming met officiële regelgeving naar K8s-instrumentatie. Ze vertrouwen grotendeels op de overeenkomstige Prometheus-documentatie. Er ontstonden inconsistenties om verschillende redenen (sommige statistieken werden bijvoorbeeld eenvoudigweg gecreëerd voordat de huidige instructies verschenen), en de ontwikkelaars besloten dat het tijd was om alles naar één standaard te brengen, “in lijn met de rest van het Prometheus-ecosysteem.” De huidige implementatie van dit initiatief bevindt zich in de alfastatus, die in volgende versies van Kubernetes geleidelijk zal worden gepromoveerd tot bèta (1.17) en stabiel (1.18).

Daarnaast kunnen de volgende wijzigingen worden opgemerkt:

Windows ondersteunt ontwikkeling с uiterlijk Kubeadm-hulpprogramma's voor dit besturingssysteem (alfaversie), kans RunAsUserName voor Windows-containers (alfaversie), verbetering Group Managed Service Account (gMSA) ondersteuning tot bètaversie, steun mount/attach voor vSphere-volumes.
Gerecycled mechanisme voor gegevenscompressie in API-reacties. Voorheen werd voor deze doeleinden een HTTP-filter gebruikt, dat een aantal beperkingen oplegde waardoor het niet standaard kon worden ingeschakeld. "Transparante verzoekcompressie" werkt nu: clients verzenden Accept-Encoding: gzip in de header ontvangen ze een GZIP-gecomprimeerd antwoord als de grootte groter is dan 128 KB. Go-clients ondersteunen automatisch compressie (het verzenden van de vereiste header), zodat ze onmiddellijk een vermindering van het verkeer zullen merken. (Voor andere talen kunnen kleine wijzigingen nodig zijn.)
Mogelijk geworden HPA schalen van/naar nulpods op basis van externe statistieken. Als u schaalt op basis van objecten/externe statistieken, kunt u, wanneer de workloads niet actief zijn, automatisch schalen naar 0 replica's om bronnen te besparen. Deze functie zou vooral handig moeten zijn in gevallen waarin werknemers GPU-bronnen aanvragen en het aantal verschillende soorten inactieve werknemers groter is dan het aantal beschikbare GPU's.
Nieuwe klant - k8s.io/client-go/metadata.Client — voor “algemene” toegang tot objecten. Het is ontworpen om gemakkelijk metadata op te halen (d.w.z. subsectie metadata) van clusterbronnen en voer er garbagecollection- en quotabewerkingen mee uit.
Kubernetes bouwen nu kan je zonder oudere (“ingebouwde” in-tree) cloudproviders (alfaversie).
Naar het kubeadm-hulpprogramma toegevoegd experimentele (alfaversie) mogelijkheid om aangepaste patches toe te passen tijdens operaties init, join и upgrade. Meer informatie over het gebruik van de vlag --experimental-kustomize, zien in KEP.
Nieuw eindpunt voor apiserver - readyz, - hiermee kunt u informatie over de gereedheid ervan exporteren. De API-server heeft nu ook een vlag --maximum-startup-sequence-duration, zodat u het opnieuw opstarten ervan kunt regelen.
twee functies voor Azure stabiel verklaard: steun beschikbaarheidszones (Beschikbaarheidszones) en meerdere resourcegroepen (RG). Daarnaast heeft Azure toegevoegd:
- authenticatie ondersteuning AAD en ADFS;
- abstract service.beta.kubernetes.io/azure-pip-name om het openbare IP-adres van de load balancer op te geven;
- kans настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS heeft dat nu ondersteunen voor EBS op Windows en geoptimaliseerd EC2 API-oproepen DescribeInstances.
Kubeadm is nu onafhankelijk migreert CoreDNS-configuratie bij het upgraden van de CoreDNS-versie.
Binaire bestanden enz in de bijbehorende Docker-afbeelding heb gedaan world-executable, waarmee u deze image kunt uitvoeren zonder dat u rootrechten nodig heeft. Ook etcd-migratie-image opgehouden ondersteuning voor etcd2-versies.
В Cluster-autoscaler 1.16.0 overgestapt op het gebruik van distroless als basisimage, verbeterde prestaties, nieuwe cloudproviders toegevoegd (DigitalOcean, Magnum, Packet).
Updates in gebruikte/afhankelijke software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

Kubernetes 1.16: overzicht van de belangrijkste innovaties