🥇Kubernetes 1.17: přehled hlavních novinek

Včera, 9. prosince, se uskutečnilo byl vydán další release Kubernetes — 1.17. Jak je naším tradičním zvykem, přinášíme vám přehled nejvýznamnějších změn v nové verzi.

Kubernetes 1.17: přehled hlavních novinek

Informace použité k přípravě tohoto materiálu byly převzaty z oficiálního oznámení, tabulka sledování zlepšení Kubernetes, CHANGELOG-1.17 a odpovídajících problémů, pull requestů a také Kubernetes Enhancement Proposals (KEP). Tak co je nového?..

Směrování s ohledem na topologii

Členové komunity Kubernetes na tuto funkci dlouho čekali — Topology-aware service routing. Pokud KEP začíná již v říjnu 2018, a oficiální vylepšení — 2 roky zpátky, zatímco běžné problémy (jako tohoto) — a dokonce ještě starší než pár let…

Celkovou myšlenkou je umožnit realizaci "lokální" směrování pro služby nacházející se v Kubernetes. "Lokálnost" v tomto kontextu znamená "stejnou topologickou úroveň" (topology level), což může znamenat:

stejný uzel pro služby,
stejný rack,
stejný region,
stejný poskytovatel cloudu,
…

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

úspora na provozu v cloudových instalacích s mnoha dostupnostními zónami (multi-AZ) — viz novou ilustraci na příkladu provozu jednoho regionu, ale různých AZ v AWS;
nižší latence v výkonu/lepší propustnost;
šardovaná služba, která má lokální informace o uzlu v každém shardu;
umístění fluentd (nebo obdobných nástrojů) na stejný uzel s aplikacemi, jejichž logy se sbírají;
…

Takové směrování, které bere v úvahu topologii, se také nazývá podobou network affinity — podle analogie s node affinity, pod affinity/anti-affinity nebo nově zavedeným Topology-Aware Volume Scheduling Volume Provisioning (a ). Aktuální úroveň realizaceServiceTopology v Kubernetes — alfa verze. Podrobnosti o tom, jak je funkce navržena a jak ji již využít, naleznete v

od jednoho z autorů. tomto článku Podpora dvoustupňového IPv4/IPv6

Významný pokrok

byl zaznamenán v jiné síťové funkci: současné podpoře dvou IP zásobníků, která byla poprvé představena v K8s 1.16 . Konkrétně nový release přinesl následující změny:v kube-proxy

možnost současného provozu v obou režimech (IPv4 a IPv6); byla implementována Pod.Status.PodIPs
v podpora downward API (ve stejné době v se objevila nyní vyžaduje pro hosta přidat i IPv6 adresu); /etc/hosts podpora dvou zásobníků v
KIND (Kubernetes IN Docker) a aktualizované e2e testy. kubeadm;
aktualizované e2e testy.

Kubernetes 1.17: přehled hlavních novinek
Ilustrace použití dvojitého stohu IPV4/IPv6 v KIND

Pokrok v CSI

Byla oznámena stabilní verze podpora topologií pro úložiště na bázi CSI, poprvé představená v K8s 1.12.

Iniciativa pro migraci pluginů svazků na CSI — Migrace CSI — dosáhla beta verze. Tato funkce je kritická pro převod existujících pluginů úložišť (in-tree) na moderní rozhraní (CSI, out-of-tree) neviditelně pro koncové uživatele Kubernetes. Správci clusterů budou muset pouze aktivovat CSI migraci, po které existující stateful zdroje a pracovní zátěže budou stále fungovat… ale už s použitím aktuálních CSI ovladačů místo zastaralých, které jsou součástí jádra Kubernetes.

V současné době je v beta verzi připravena migrace pro ovladače AWS EBS (kubernetes.io/aws-ebs) a GCE PD (kubernetes.io/gce-pd). Předpovědi pro další úložiště jsou následující:

Kubernetes 1.17: přehled hlavních novinek

O tom, jak "tradiční" podpora úložišť v K8s přešla na CSI, jsme psali v tomto článku. A přechodu migrace CSI do beta verze je věnována samostatná publikace v blogu projektu.

Kromě toho, status beta verze (tj. zapnutí ve výchozím nastavení) v releasu Kubernetes 1.17 dosáhl další významné funkčnosti v kontextu CSI, vznikající (alfa-implementace) v K8s 1.12, — vytváření snapshotů a obnova z nich. Mezi změnami provedenými v Kubernetes Volume Snapshot na cestě k beta release patří:

rozdělení sidecaru CSI external-snapshotter na dva kontrolery,
přidán tajný klíč pro odstranění (deletion secret) jako anotace k obsahu snapshotu svazku,
nový finalizátor (finalizer) pro prevenci odstranění API objektu snapshotu při existenci zbývajících vazeb.

V době vydání 1.17 je funkce podporována třemi CSI ovladači: GCE Persistent Disk CSI Driver, Portworx CSI Driver a NetApp Trident CSI Driver. Více o její implementaci a použití si můžete přečíst v tento příspěvek blogu.

Cloud Provider Labels

Štítky, které jsou automaticky přidělovány vytvářeným uzlům a svazkům v závislosti na používaném cloudovém poskytovateli, byly k dispozici v Kubernetes jako beta verze už velmi dlouho — od vydání K8s 1.2 (duben 2016!). Vzhledem k jejich širokému používání tak dlouho, vývojáři se rozhodli, že nastal čas vyhlásit funkci stabilní (GA).

Proto byly všechny přejmenovány odpovídajícím způsobem (podle topologií):

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 stále jsou k dispozici pod svými starými názvy (kvůli zpětné kompatibilitě). Nicméně, všem administrátorům se doporučuje přejít na aktuální štítky. Příslušná dokumentace K8s byla aktualizována.

Strukturovaný výstup kubeadm

Byl poprvé představen ve formátu alfa verze strukturovaný výstup pro utilitu kubeadm. Podporované formáty: JSON, YAML, Go šablona.

Motivace k implementaci této funkce (podle KEP) je následující:

Ačkoli Kubernetes může být nasazen ručně, de facto (pokud ne de iure) standardem pro tuto operaci je použití kubeadm. Oblíbené nástroje pro správu systémů jako Terraform se opírají o kubeadm pro nasazení Kubernetes. Plánované vylepšení v Cluster API zahrnují sestavitelný balíček pro bootstrapping Kubernetes pomocí kubeadm a cloud-init.
Bez strukturovaného výstupu mohou i ty nejbezpečnější na první pohled změny rozbít Terraform, Cluster API a další software využívající výsledky práce kubeadm.

Na blízkém horizontu je plánována podpora (ve formátu 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": "Výchozí bootstrap token generovaný 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilizace dalších novinek

Celkově byl vydání Kubernetes 1.17 pod heslem „Stabilita“. To bylo usnadněno tím, že mnoho funkcí v něm (celkové množství — 14) získalo status GA. Mezi nimi:

„označení“ uzlů podle určitých podmínek (TaintNodesByCondition), které se objevilo v K8s 1.8;
Watch Bookmarks — nový typ událostí, který má značku, že všechny objekty do určité verze (resourceVersion) již byly zpracovány watch'em;
výchozí hodnoty (defaulting) pro Custom Resources;
sdílené mezi kontejnery v podu s procesními názvy prostorů;
ScheduleDaemonSetPods — plánování podů v DaemonSet použitím kube-scheduler (namísto řadiče DaemonSet);
dynamické limity na počet svazků v závislosti na typu uzlu;
podpora proměnných prostředí pro názvy adresářů, které jsou připojené jako subPath;
přenos Kubelet heartbeats do specializovaného Lease API;
„ochrana finalizátoru“ (Finalizer Protection) pro vyvažovače zátěže (kontrola relevantních zdrojů služby před odstraněním zdrojů LoadBalanceru);
optimalizace kube-apiserveru ve výkonu při práci s mnoha watches sledujícími identické sady objektů – což se dosahuje díky tomu, že se vyhne opakované serializaci stejných objektů pro každého watchera.

Další změny

Úplný seznam novinek v Kubernetes 1.17 samozřejmě nekončí tímto výčtem. Zde je několik dalších z nich (a pro úplnější seznam – viz. CHANGELOG):

do beta verze „vydrážené“ funkce představené v minulém vydání RunAsUserName pro Windows;
podobná změna dostihla EndpointSlice API (také z K8s 1.16), přestože toto řešení pro zlepšení výkonu škálovatelnosti Endpoint API není ve výchozím nastavení aktivováno;
kritické podpodlažky pro práci klastru mohou nyní být vytvořeny nejen v názvech prostorů kube-system (podrobnosti viz dokumentace k Limit Priority Class consumption);
nová možnost pro kubelet — --reserved-cpus — umožňuje jasně definovat seznam CPU rezervovaných pro systém;
pro kubectl logs byl představen nová příznak --prefix, který přidává název podu a zdrojového kontejneru k každému řádku logu;
v label.Selector přidali RequiresExactMatch;
všechny kontejnery v kube-dns nyní běží s menšími oprávněními;
hyperkube byl vyčleněn do samostatného GitHub repozitáře a již nebude součástí vydání Kubernetes;
významně zlepšen výkon kube-proxy pro ne-UDP porty.

Změny v závislostech:

verze CoreDNS součástí kubeadm – 1.6.5;
verze crictl byla aktualizována na v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
poslední ověřená verze Dockeru byla zvýšena na 19.03;
minimální verze Go požadovaná k sestavení Kubernetes 1.17 je 1.13.4.

P.S.

Přečtěte si také náš blog:

Zdroj: habr.com