🥇Kubernetes 1.17: přehled hlavních inovací

Včera, 9. prosince, odehrál se další vydání Kubernetes - 1.17. Podle tradice, která se pro náš blog rozvinula, hovoříme o nejvýznamnějších změnách v nové verzi.

Informace použité k přípravě tohoto materiálu jsou převzaty z oficiálního oznámení, Tabulky sledování vylepšení Kubernetes, ZMĚNA-1.17 a související problémy, žádosti o stažení a návrhy vylepšení Kubernetes (KEP). Tak co je nového?..

Směrování s ohledem na topologii

Komunita Kubernetes na tuto funkci dlouho čekala – Směrování služeb s ohledem na topologii. Pokud KEP pochází z října 2018 a oficiální zvýšení — Před 2 lety obvyklé problémy (jako to) - a ještě o pár let starší...

Obecnou myšlenkou je poskytnout možnost implementovat „místní“ směrování pro služby umístěné v Kubernetes. „Lokalita“ v tomto případě znamená „stejná topologická úroveň“ (úroveň topologie), což může být:

uzel identický pro služby,
stejný serverový rack,
stejný region
stejný poskytovatel cloudu,
...

Příklady použití této funkce:

úspora provozu v cloudových instalacích s více zónami dostupnosti (multi-AZ) - viz. svěží ilustrace pomocí příkladu provozu ze stejného regionu, ale různých AZ v AWS;
nižší latence výkonu/lepší propustnost;
sdílená služba, která má místní informace o uzlu v každém datovém fragmentu;
umístění fluentd (nebo analogů) na stejný uzel s aplikacemi, jejichž logy jsou shromažďovány;
...

Takové směrování, které „ví“ o topologii, se také nazývá síťová afinita – analogicky s afinita uzlu, pod afinita/anti-afinita nebo se objevil ne tak dávno Plánování svazků s ohledem na topologii (a Poskytování objemu). Současná úroveň implementace ServiceTopology v Kubernetes - alfa verze.

Podrobnosti o tom, jak funkce funguje a jak ji již můžete používat, si přečtěte tento článek od jednoho z autorů.

Podpora duálního zásobníku IPv4/IPv6

Výrazný pokrok pevný v další síťové funkci: současná podpora dvou IP stacků, která byla poprvé představena v K8s 1.16. Nové vydání přineslo zejména následující změny:

v kube-proxy implementováno možnost současného provozu v obou režimech (IPv4 a IPv6);
в Pod.Status.PodIPs se objevil podpora downward API (současně jako v /etc/hosts nyní vyžadují, aby hostitel přidal adresu IPv6);
podpora dvou stohů DRUH (Kubernetes IN Docker) a kubeadm;
aktualizované testy e2e.

Ilustrace pomocí dual stack IPV4/IPv6 v KIND

Pokrok na CSI

Prohlášen za stabilní podpora topologie pro úložiště založené na CSI, poprvé představeno v K8s 1.12.

Iniciativa pro migrace volume pluginů do CSI - CSI Migrace - dosáhl beta verze. Tato funkce je kritická pro překlad existujících zásuvných modulů úložiště (ve stromu) na moderní rozhraní (CSI, mimo strom) neviditelné pro koncové uživatele Kubernetes. Správci klastru budou muset pouze povolit migraci CSI, po které budou stávající stavové prostředky a zátěže nadále „jen fungovat“... ale s použitím nejnovějších ovladačů CSI namísto těch zastaralých, které jsou součástí jádra Kubernetes.

V tuto chvíli je připravena migrace pro ovladače AWS EBS v beta verzi (kubernetes.io/aws-ebs) a GCE PD (kubernetes.io/gce-pd). Prognózy pro další skladovací zařízení jsou následující:

Mluvili jsme o tom, jak „tradiční“ podpora úložiště v K8 přišla do CSI tento článek. A přechodu migrace CSI do beta stavu je věnována samostatná publikace na blogu projektu.

Kromě toho další významná funkce v kontextu CSI, která pochází (alfa implementace) v K1.17s 8, dosáhla stavu beta (tj. ve výchozím nastavení povolena) ve verzi Kubernetes 1.12 - vytváření snímků a zotavení z nich. Mezi změnami provedenými v Kubernetes Volume Snapshot na cestě k vydání beta:

rozdělení postranního vozíku CSI s externím snímkováním na dva ovladače,
přidáno tajemství pro smazání (tajné smazání) jako anotace k obsahu snímku svazku,
nový finalizátor (finalizátor) abyste zabránili odstranění objektu API snímku, pokud existují zbývající připojení.

V době vydání 1.17 je tato funkce podporována třemi ovladači CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver a NetApp Trident CSI Driver. Více podrobností o jeho implementaci a použití naleznete v této publikace na blogu.

Štítky poskytovatele cloudu

Štítky, které automaticky přiřazeny k vytvořeným uzlům a svazkům v závislosti na použitém poskytovateli cloudu, jsou k dispozici v Kubernetes jako beta verze již velmi dlouho - od vydání K8s 1.2 (duben 2016!). Vzhledem k jejich rozšířenému používání po tak dlouhou dobu, vývojáři rozhodl, že je čas prohlásit funkci za stabilní (GA).

Proto byly všechny odpovídajícím způsobem přejmenovány (podle 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

... ale jsou stále dostupné pod svými starými názvy (kvůli zpětné kompatibilitě). Všem správcům se však doporučuje přejít na aktuální štítky. Související dokumentace K8s byl aktualizován.

Strukturovaný výstup kubeadm

Poprvé představeno v alfa verzi strukturovaný výstup pro obslužný program kubeadm. Podporované formáty: JSON, YAML, šablona Go.

Motivace pro implementaci této funkce (podle KEP) je:

Zatímco Kubernetes lze nasadit ručně, de facto (pokud ne de jure) standardem pro tuto operaci je použití kubeadm. Oblíbené nástroje pro správu systémů, jako je Terraform, spoléhají na kubeadm pro nasazení Kubernetes. Plánovaná vylepšení Cluster API zahrnují sestavitelný balíček pro bootstrapping Kubernetes s kubeadm a cloud-init.

Bez strukturovaného výstupu mohou i ty nejnebezpečnější změny na první pohled zlomit Terraform, Cluster API a další software, který využívá výsledky kubeadm.

Naše nejbližší plány zahrnují podporu (ve formě strukturovaného výstupu) pro následující příkazy kubeadm:

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

Ilustrace JSON odpovědi na příkaz 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="
}

Stabilizace dalších inovací

Obecně se vydání Kubernetes 1.17 uskutečnilo pod heslem „Stabilita" To bylo usnadněno skutečností, že mnoho funkcí v něm (jejich celkový počet je 14) obdržel status GA. Mezi nimi:

„označení“ uzlů podle určitých podmínek (TaintNodesByCondition), objevil se v K8s 1.8;
Sledujte Záložky - nový typ událostí, které mají označení, že všechny objekty jsou až do určité verze (resourceVersion) již byly zpracovány hodinkami;
výchozí hodnoty (výchozí) pro vlastní zdroje;
sdílené mezi kontejnery ve jmenných prostorech procesu pod;
ScheduleDaemonSetPods - plánovací moduly v DaemonSet pomocí kube-scheduler (místo řadiče DaemonSet);
dynamické limity na počtu svazků v závislosti na typu uzlu;
podpora proměnných prostředí pro názvy adresářů připojené jako subPath;
Přenos srdečních tepů Kubelet na specializované Lease API;
"ochrana finalizátoru" (Ochrana finalizátoru) pro nástroje pro vyrovnávání zatížení (kontrola odpovídajících prostředků služby před odstraněním prostředků LoadBalancer);
optimalizace kube-apiserver ve výkonu při práci s více hodinkami, které monitorují identické sady objektů – toho je dosaženo tím, že se vyhneme opakované serializaci stejných objektů pro každého pozorovatele.

Další změny

Úplný seznam inovací v Kubernetes 1.17 se samozřejmě neomezuje na ty, které jsou uvedeny výše. Zde jsou některé další (a úplný seznam viz ZMĚNA):

Funkce představená v posledním vydání dosáhla beta verze RunAsUserName pro okna;
podobná změna potkalo se EndpointSlice API (také od K8s 1.16), ale prozatím toto řešení pro zlepšení výkonu/škálovatelnosti Endpoint API není ve výchozím nastavení povoleno;
pody jsou nyní kritické pro provoz clusteru lze vytvořit nejen ve jmenných prostorech kube-system (podrobnosti naleznete v dokumentaci k Omezte spotřebu prioritní třídy);
nová možnost pro kubelet - --reserved-cpus — umožňuje explicitně definovat seznam CPU rezervovaných pro systém;
pro kubectl logs prezentovány nová vlajka --prefix, přidání názvu pod a zdrojového kontejneru do každého řádku protokolu;
в label.Selector přidal RequiresExactMatch;
všechny kontejnery v kube-dns nyní běží s menšími výsadami;
hyperkube odděleny do samostatného úložiště GitHub a již nebudou zahrnuty ve verzích Kubernetes;
hodně zlepšený výkon kube-proxy pro non-UDP porty.

Změny závislostí:

Verze CoreDNS obsažená v kubeadm je 1.6.5;
verze crictl aktualizována na v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
Nejnovější testovaná verze Dockeru upgradována na 19.03;
Minimální verze Go nutná k sestavení Kubernetes 1.17 je 1.13.4.

PS

Přečtěte si také na našem blogu:

Zdroj: www.habr.com

Kubernetes 1.17: Nejdůležitější novinky