Эtoй ночью další vydání Kubernetes - . Podle tradice, která se pro náš blog rozvinula, mluvíme o klíčových změnách v nové verzi tohoto úžasného produktu s otevřeným zdrojovým kódem.
Informace použité k přípravě tohoto materiálu jsou převzaty z , a související problémy, žádosti o stažení, návrhy vylepšení Kubernetes (KEP).
Začněme důležitým úvodem ze životního cyklu clusteru SIG: dynamické clustery převzetí služeb při selhání Kubernetes (nebo přesněji řečeno nasazení HA s vlastním hostitelem) je nyní pomocí známých (v kontextu jednouzlových clusterů) příkazů kubeadm (init и join). Zkrátka k tomu:
- certifikáty používané clusterem jsou převedeny do tajných klíčů;
- pro možnost použití clusteru etcd uvnitř clusteru K8s (tj. zbavení se dříve existující externí závislosti) ;
- Dokumentuje doporučená nastavení pro externí nástroj pro vyrovnávání zatížení, který poskytuje konfiguraci odolnou vůči chybám (v budoucnu se plánuje odstranění této závislosti, ale ne v této fázi).
Architektura clusteru Kubernetes HA vytvořeného pomocí kubeadm
Podrobnosti o implementaci najdete v . Tato funkce byla skutečně dlouho očekávaná: alfa verze byla očekávána již v K8s 1.9, ale objevila se až nyní.
API
Tým apply a obecně deklarativní správa objektů z kubectl v apiserveru. Sami vývojáři své rozhodnutí stručně vysvětlují slovy kubectl apply - základní součást práce s konfiguracemi v Kubernetes, nicméně „je plná chyb a těžko se opravuje“, a proto je potřeba tuto funkcionalitu vrátit do normálu a přenést do řídicí roviny. Jednoduché a jasné příklady problémů, které dnes existují:
Podrobnosti o implementaci jsou v . Aktuální připravenost je alfa (povýšení na beta je plánováno pro příští vydání Kubernetes).
K dispozici v alfa verzi pomocí schématu OpenAPI v3 vytváření a publikování dokumentace OpenAPI pro CustomResources (CR) používané k ověření (na straně serveru) uživatelem definovaných zdrojů K8 (CustomResourceDefinition, CRD). Publikování OpenAPI pro CRD umožňuje klientům (např. kubectl) provést ověření na vaší straně (v rámci kubectl create и kubectl apply) a vystavit dokumentaci podle schématu (kubectl explain). Podrobnosti - v .
Již existující protokoly s vlajkou O_APPEND (ne O_TRUNC), aby se předešlo ztrátě protokolů v některých situacích a aby bylo možné protokoly zkrátit pomocí externích nástrojů pro rotaci.
Také v kontextu Kubernetes API lze poznamenat, že v PodSandbox и PodSandboxStatus pole runtime_handler zaznamenávat informace o RuntimeClass v podu (více o tom čtěte v textu o , kde se tato třída objevila jako alfa verze) a v Admission Webhooky schopnost určit, které verze AdmissionReview podporují. Konečně, pravidla Admission Webhooks jsou nyní rozsah jejich využití jmennými prostory a klastrovými frameworky.
Úložný prostor
, který měl od vydání status beta , stabilní (GA): tato brána funkcí již není deaktivována a bude odstraněna v Kubernetes 1.17.
pomocí proměnných prostředí tzv (například název pod) pro názvy adresářů připojených jako , byl vyvinut - v podobě nového oboru subPathExpr, který se nyní používá k určení požadovaného názvu adresáře. Tato funkce se původně objevila v Kubernetes 1.11, ale pro 1.14 zůstala ve stavu alfa verze.
Stejně jako u předchozí verze Kubernetes je zavedeno mnoho významných změn pro aktivně se vyvíjející rozhraní CSI (Container Storage Interface):
CSI
Byl k dispozici (jako součást alfa verze) změna velikosti pro svazky CSI. Chcete-li jej použít, budete muset povolit tzv. bránu funkcí ExpandCSIVolumesa také dostupnost podpory pro tuto operaci v konkrétním ovladači CSI.
Další funkce pro CSI v alfa verzi - odkazují přímo (tj. bez použití PV/PVC) na objemy CSI v rámci specifikace pod. Tento odstraňuje omezení používání CSI jako výlučně vzdáleného úložiště dat, který jim otevírá dveře do světa . K použití () musí být povoleno CSIInlineVolume funkce brána.
Došlo také k pokroku v „vnitřnostech“ Kubernetes souvisejících s CSI, které nejsou tak viditelné pro koncové uživatele (správce systému) ... V současné době jsou vývojáři nuceni podporovat dvě verze každého pluginu úložiště: jednu - „v starý způsob“, uvnitř kódové základny K8s (ve -stromu) a druhý - jako součást nového CSI (více o tom čtěte např ). To způsobuje pochopitelné nepříjemnosti, které je třeba řešit, protože CSI se sama stabilizuje. Není možné jednoduše zavrhnout API interních (in-tree) pluginů z důvodu .
To vše vedlo k tomu, že alfa verze dosáhla interní kód pluginu, implementované jako in-tree, v CSI pluginech, díky čemuž se starosti vývojářů zredukují na podporu jedné verze jejich pluginů a zůstane zachována kompatibilita se starými API a mohou být v běžném scénáři prohlášeny za zastaralé. Očekává se, že do příštího vydání Kubernetes (1.15) budou migrovány všechny pluginy poskytovatelů cloudu, implementace obdrží stav beta a bude standardně aktivována v instalacích K8s. Podrobnosti viz . Tato migrace také vyústila v z objemových limitů definovaných konkrétními poskytovateli cloudu (AWS, Azure, GCE, Cinder).
Navíc podpora pro bloková zařízení s CSI (CSIBlockVolume) do beta verze.
Uzly/Kubelet
Představena alfa verze v Kubelet, určený pro návratnost klíčových zdrojů. Obecně řečeno, pokud dříve Kubelet přijímal statistiky o využití kontejnerů od cAdvisoru, nyní tato data pocházejí z prostředí kontejnerového běhu přes CRI (Container Runtime Interface), ale je zachována i kompatibilita pro práci se staršími verzemi Dockeru. Dříve byly statistiky shromážděné v Kubelet odesílány přes REST API, ale nyní se nachází koncový bod na adrese /metrics/resource/v1alpha1. Dlouhodobá strategie vývojářů je minimalizovat sadu metrik poskytovaných Kubeletem. Mimochodem, tyto metriky samotné nikoli „základní metriky“, ale „metriky zdrojů“ a jsou popsány jako „prvotřídní zdroje, jako je procesor a paměť“.
Velmi zajímavá nuance: i přes jasnou výkonnostní výhodu koncového bodu gRPC ve srovnání s různými případy použití formátu Prometheus (viz výsledek jednoho z benchmarků níže), autoři dali přednost textovému formátu Prometheus z důvodu jasného vedení tohoto monitorovacího systému v komunitě.
„gRPC není kompatibilní s hlavními monitorovacími kanály. Koncový bod bude užitečný pouze pro doručování metrik na Metrics Server nebo monitorování komponent, které se s ním přímo integrují. Výkon textového formátu Prometheus při použití ukládání do mezipaměti na serveru Metrics Server dostatečně dobrý abychom dali přednost Prometheus před gRPC vzhledem k širokému přijetí Promethea v komunitě. Jakmile se formát OpenMetrics stane stabilnějším, budeme se moci přiblížit výkonu gRPC pomocí formátu založeného na protokolech."
Jeden ze srovnávacích testů výkonu používání formátů gRPC a Prometheus v novém koncovém bodu Kubelet pro metriky. Další grafy a další podrobnosti najdete v .
Mezi další změny:
- Kubelet nyní (jednou) kontejnery v neznámém stavu před operacemi restartování a odstranění.
- Při použití nyní k inicializačnímu kontejneru stejné informace jako u běžného kontejneru.
- kubelet
usageNanoCoresod poskytovatele statistik CRI a pro uzly a kontejnery v systému Windows statistiky sítě. - Informace o operačním systému a architektuře jsou nyní zaznamenány ve štítcích
kubernetes.io/osиkubernetes.io/archObjekty uzlů (přenesené z beta do GA). - Možnost zadat konkrétní skupinu uživatelů systému pro kontejnery v pod (
RunAsGroup, objevil se v ) před beta verzí (ve výchozím nastavení povoleno). - du a find použité v cAdvisor, on Go implementace.
CLI
V cli-runtime a kubectl -k příznak pro integraci s (jeho vývoj mimochodem nyní probíhá v samostatném úložišti), tzn. zpracovávat další soubory YAML ze speciálních adresářů kustomizace (podrobnosti o jejich použití viz ):
Příklad jednoduchého použití souboru (složitější aplikace kustomize je možná v rámci )
Navíc:
- nový tým
kubectl create cronjob, jehož jméno mluví samo za sebe. - В
kubectl logsteď můžeš vlajky-f(--followpro protokoly streamování) a-l(--selectorpro dotaz na štítek). - kubectl kopírovat soubory vybrané pomocí zástupného znaku.
- Do týmu
kubectl waitvlajka--allvyberte všechny prostředky v oboru názvů zadaného typu prostředku.
Ostatní
Následující funkce získaly stabilní stav (GA):
- , používané ve specifikaci podu k definování dalších podmínek, které se berou v úvahu při připravenosti podu;
- Podpora velkých stránek (brána funkcí tzv );
- ;
- PriorityClass API .
Další změny zavedené v Kubernetes 1.14:
- Výchozí zásada RBAC již neumožňuje přístup k rozhraní API
discoveryиaccess-reviewuživatelé bez autentizace (neověřeno). - Oficiální podpora CoreDNS Pouze Linux, takže při nasazení kubeadm (CoreDNS) do clusteru musí uzly běžet pouze na Linuxu (k tomuto omezení se používají nodeSelectors).
- Výchozí konfigurace CoreDNS je nyní místo proxy. Také v CoreDNS ReadinessProbe, která zabraňuje vyrovnávání zátěže na vhodných (nepřipravených k provozu) pod.
- V kubeadm, na fázích
initneboupload-certs, načtěte certifikáty potřebné k připojení nové řídicí roviny k tajnému klíči kubeadm-certs (použijte příznak--experimental-upload-certs). - Pro instalace Windows se objevila alfa verze gMSA (Group Managed Service Account) – speciální účty v Active Directory, které mohou využívat i kontejnery.
- Pro G.C.E. mTLS šifrování mezi etcd a kube-apiserver.
- Aktualizace v používaném/závislém softwaru: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, podpora Docker 18.09 v kubeadm a minimální podporovaná verze rozhraní Docker API je nyní 1.26.
PS
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com