🥇Kubernetes 1.17: overzicht van de belangrijkste innovaties

Gisteren, 9 december, vond plaats volgende release van Kubernetes - 1.17. Volgens de traditie die zich voor onze blog heeft ontwikkeld, praten we over de belangrijkste veranderingen in de nieuwe versie.

De informatie die is gebruikt om dit materiaal voor te bereiden is afkomstig uit de officiële aankondiging, Kubernetes verbetert trackingtabellen, WIJZIGINGSLOG-1.17 en aanverwante problemen, pull-aanvragen en Kubernetes Enhancement Proposals (KEP). Dus, wat is er nieuw?..

Topologiebewuste routering

De Kubernetes-gemeenschap wacht al lang op deze functie - Topologiebewuste servicerouting. als KEP het vindt zijn oorsprong in oktober 2018 en is de officiële enhancement — 2 jaar geleden, de gebruikelijke problemen (leuk vinden het) - en nog een paar jaar ouder...

Het algemene idee is om de mogelijkheid te bieden om ‘lokale’ routering te implementeren voor services die zich in Kubernetes bevinden. ‘Lokaliteit’ betekent in dit geval ‘hetzelfde topologische niveau’ (topologieniveau), wat kan zijn:

knooppunt identiek voor services,
hetzelfde serverrack,
dezelfde regio
dezelfde cloudprovider,
...

Voorbeelden van het gebruik van deze functie:

besparingen op verkeer in cloudinstallaties met meerdere beschikbaarheidszones (multi-AZ) - zie. frisse illustratie gebruik makend van het voorbeeld van verkeer uit dezelfde regio, maar verschillende AZ's in AWS;
lagere prestatielatentie/betere doorvoer;
een shard-service die lokale informatie heeft over het knooppunt in elke shard;
plaatsing van vloeiende (of analogen) op hetzelfde knooppunt met de applicaties waarvan de logs worden verzameld;
...

Een dergelijke routering, die de topologie ‘weet’, wordt ook wel netwerkaffiniteit genoemd – naar analogie met knooppuntaffiniteit, pod-affiniteit/anti-affiniteit of verscheen niet zo lang geleden Topologiebewuste volumeplanning (en Volumevoorziening). Huidig implementatieniveau ServiceTopology in Kubernetes - alfaversie.

Voor meer informatie over hoe de functie werkt en hoe u deze al kunt gebruiken, leest u dit artikel van een van de auteurs.

Ondersteuning voor IPv4/IPv6 dual-stack

Aanzienlijke vooruitgang vast in een andere netwerkfunctie: gelijktijdige ondersteuning voor twee IP-stacks, die voor het eerst werd geïntroduceerd in K8s 1.16. In het bijzonder bracht de nieuwe release de volgende wijzigingen met zich mee:

in kube-proxy geïmplementeerd mogelijkheid tot gelijktijdig gebruik in beide modi (IPv4 en IPv6);
в Pod.Status.PodIPs verscheen ondersteuning voor neerwaartse API (tegelijkertijd met in /etc/hosts nu vereisen ze dat de host een IPv6-adres toevoegt);
dubbele stapelondersteuning SOORT (Kubernetes IN Docker) en Kubeadm;
bijgewerkte e2e-tests.

illustratie met behulp van dual-stack IPV4/IPv6 in KIND

Vooruitgang op CSI

Stabiel verklaard topologie ondersteuning voor op CSI gebaseerde opslag, voor het eerst geïntroduceerd in K8s 1.12.

Initiatief voor migratie van volumeplug-ins naar CSI - CSI-migratie - bètaversie bereikt. Deze functie is van cruciaal belang om bestaande opslagplug-ins te vertalen (in-boom) naar een moderne interface (CSI, uit de boom) onzichtbaar voor Kubernetes-eindgebruikers. Clusterbeheerders hoeven alleen maar CSI-migratie in te schakelen, waarna bestaande stateful bronnen en workloads “gewoon blijven werken”… maar dan met behulp van de nieuwste CSI-stuurprogramma’s in plaats van de verouderde stuurprogramma’s die in de Kubernetes-kern zijn opgenomen.

Op dit moment is de migratie voor AWS EBS-stuurprogramma's gereed in bètaversie (kubernetes.io/aws-ebs) en GCE PD (kubernetes.io/gce-pd). De prognoses voor overige opslagfaciliteiten zijn als volgt:

We spraken over hoe ‘traditionele’ opslagondersteuning in K8’s naar CSI kwam dit artikel. En de transitie van CSI-migratie naar bètastatus is gewijd aan aparte publicatie op de projectblog.

Bovendien bereikte een andere belangrijke functionaliteit in de context van CSI, die zijn oorsprong vindt (alfa-implementatie) in K1.17s 8, de bètastatus (d.w.z. standaard ingeschakeld) in de Kubernetes 1.12-release - het maken van momentopnamen en herstel ervan. Onder de wijzigingen die zijn aangebracht in Kubernetes Volume Snapshot op weg naar de bètaversie:

het splitsen van de CSI external-snapshotter zijspan in twee controllers,
geheim toegevoegd voor verwijdering (verwijderingsgeheim) als annotatie bij de inhoud van een volumesnapshot,
nieuwe finalisator (finalist) om te voorkomen dat het snapshot-API-object wordt verwijderd als er resterende verbindingen zijn.

Op het moment van release 1.17 wordt de functie ondersteund door drie CSI-stuurprogramma's: GCE Persistent Disk CSI Driver, Portworx CSI Driver en NetApp Trident CSI Driver. Meer details over de implementatie en het gebruik ervan zijn te vinden in deze publicatie op de blog.

Labels van cloudproviders

Etiketten dat automatisch toegewezen aan gemaakte knooppunten en volumes, afhankelijk van de gebruikte cloudprovider, zijn al heel lang beschikbaar in Kubernetes als bètaversie - sinds de release van K8s 1.2 (april 2016!). Gezien het wijdverbreide gebruik ervan zo lang, hebben ontwikkelaars besloten, dat het tijd is om de functie stabiel (GA) te verklaren.

Daarom zijn ze allemaal dienovereenkomstig hernoemd (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 zijn nog steeds beschikbaar onder hun oude namen (voor achterwaartse compatibiliteit). Alle beheerders wordt echter aangeraden om over te schakelen naar de huidige labels. Gerelateerde documentatie K8s is bijgewerkt.

Gestructureerde uitvoer van kubeadm

Voor het eerst gepresenteerd in alfaversie gestructureerde uitvoer voor het hulpprogramma kubeadm. Ondersteunde formaten: JSON, YAML, Go-sjabloon.

Motivatie voor het implementeren van deze functie (volgens KEP) is:

Hoewel Kubernetes handmatig kan worden geïmplementeerd, is de de facto (zo niet de jure) standaard voor deze bewerking het gebruik van kubeadm. Populaire systeembeheertools zoals Terraform vertrouwen op kubeadm voor de implementatie van Kubernetes. Geplande verbeteringen aan de Cluster API omvatten een samen te stellen pakket voor Kubernetes-bootstrapping met kubeadm en cloud-init.

Zonder gestructureerde uitvoer kunnen zelfs de meest onschadelijke veranderingen op het eerste gezicht Terraform, Cluster API en andere software die de resultaten van kubeadm gebruikt, kapot maken.

Onze onmiddellijke plannen omvatten ondersteuning (in de vorm van gestructureerde uitvoer) voor de volgende kubeadm-opdrachten:

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

Illustratie van een JSON-antwoord op een opdracht 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="
}

Stabilisatie van andere innovaties

Over het algemeen vond de release van Kubernetes 1.17 plaats onder het motto “stabiliteit" Dit werd mogelijk gemaakt door het feit dat er veel functies in zitten (hun totale aantal is 14) kreeg de GA-status. Onder hen:

knooppunten “markeren” volgens bepaalde voorwaarden (TaintNodesByCondition), verscheen in K8s 1.8;
Bekijk Bladwijzers - een nieuw type gebeurtenissen met een label dat alle objecten een bepaalde versie hebben (resourceVersion) zijn al door horloge verwerkt;
standaard waarden (standaard) voor aangepaste bronnen;
gedeeld tussen containers in de pod-procesnaamruimten;
ScheduleDaemonSetPods - planningspods in DaemonSet met behulp van kube-scheduler (in plaats van de DaemonSet-controller);
dynamische grenzen op het aantal volumes afhankelijk van het knooppunttype;
ondersteuning voor omgevingsvariabelen voor mapnamen gemonteerd als subPath;
Kubelet-hartslagen worden overgedragen naar een gespecialiseerde Lease API;
"finalizerbescherming" (Finalizer-bescherming) voor load balancers (controleren van de overeenkomstige servicebronnen voordat LoadBalancer-bronnen worden verwijderd);
kube-apiserver-optimalisatie in prestaties bij het werken met meerdere horloges die identieke sets objecten bewaken - bereikt door herhaalde serialisatie van dezelfde objecten voor elke waarnemer te vermijden.

Andere wijzigingen

De volledige lijst met innovaties in Kubernetes 1.17 is uiteraard niet beperkt tot de hierboven genoemde. Hier zijn enkele andere (en voor een meer complete lijst, zie CHANGELOG):

De functie die in de laatste release werd gepresenteerd, heeft de bètaversie bereikt RunAsUserName voor ramen;
soortgelijke verandering overkwam EndpointSlice API (ook vanaf K8s 1.16), maar voorlopig is deze oplossing om de prestaties/schaalbaarheid van de Endpoint API te verbeteren niet standaard ingeschakeld;
peulen zijn nu van cruciaal belang voor de clusterwerking kan worden gemaakt niet alleen in naamruimten kube-system (voor details, zie de documentatie voor Beperk het Priority Class-verbruik);
nieuwe optie voor kubelet - --reserved-cpus — hiermee kunt u expliciet de lijst met CPU's definiëren die voor het systeem zijn gereserveerd;
voor kubectl logs ingediend nieuwe vlag --prefix, waarbij de naam van de pod en de broncontainer aan elke regel van het logboek wordt toegevoegd;
в label.Selector toegevoegd RequiresExactMatch;
alle containers in kube-dns lopen nu met minder privileges;
hyperkube gescheiden in een aparte GitHub-repository en zal niet langer worden opgenomen in Kubernetes-releases;
veel производительность kube-proxy voor niet-UDP-poorten.

Afhankelijkheidsveranderingen:

CoreDNS-versie opgenomen in kubeadm is 1.6.5;
crictl-versie bijgewerkt naar v1.16.1;
CSI 1.2.0;
enz. 3.4.3;
Laatst geteste Docker-versie geüpgraded naar 19.03;
De minimaal vereiste Go-versie om Kubernetes 1.17 te bouwen is 1.13.4.

Kubernetes 1.17: overzicht van de belangrijkste innovaties