Tuto noc další release Kubernetes — . Podle tradice našeho blogu se zaměříme na klíčové změny v nové verzi tohoto skvělého Open Source produktu.
Informace použité k přípravě tohoto materiálu byly převzaty z , a příslušných problémů, pull requestů, návrhů na vylepšení Kubernetes (KEP).
Začneme důležitým úvodem od SIG cluster-lifecycle: dynamické vysokDisponibilní clustery Kubernetes (přesněji řečeno self-hosted HA nasazení) nyní pomocí známých (v kontextu clustery s jedním uzlem) příkazů kubeadm (init a připojit). Ve zkratce, pro to:
- certifikáty používané clusterem jsou přesunuty do tajemství;
- pro schopnost používat cluster etcd uvnitř K8s-clusteru (t.j. zbavit se dosavadní vnější závislosti) je použit ;
- doporučené nastavení pro externí vyvažovač zátěže zajišťující vysokou dostupnost (do budoucna se plánuje možnost odmítnutí i této závislosti, ale ne nyní).
Architektura HA clusteru Kubernetes, vytvořeného pomocí kubeadm
Podrobnosti o implementaci naleznete v . Tato funkce byla opravdu očekávaná: alfa verze byla očekávána již v K8s 1.9, ale přišla až nyní.
API
Tým apply a vůbec deklarativní správa objektů z kubectl v apiserveru. Samotní vývojáři stručně vysvětlují své rozhodnutí tím, že kubectl apply je základní součástí práce s konfiguracemi v Kubernetes, nicméně "je plná chyb a obtížně se opravuje", a proto je třeba tuto funkcionalitu přivést do normálního stavu a přesunout do control plane. Jednoduché a názorné příklady existujících problémů dnes:
Podrobnosti o implementaci — v . Aktuální připravenost — alfa verze (přechod na beta je naplánován na příští release Kubernetes).
V alfa verzi se stala dostupnou použití schémy OpenAPI v3 pro tvorbu a publikaci OpenAPI dokumentace pro CustomResources (CR), používané pro validaci (na straně serveru) uživatelských K8s zdrojů (CustomResourceDefinition, CRD). Publikace OpenAPI pro CRD umožňuje klientům (například kubectl) provádět validaci na své straně (v rámci kubectl create a kubectl apply) a poskytovat dokumentaci schematu (kubectl explain). Podrobnosti — v .
Dříve existující logy s příznakem O_APPEND (ne O_TRUNC) aby se předešlo ztrátě logů v některých situacích a pro snadné zpracování logů externími nástroji pro rotaci.
Také v kontextu Kubernetes API lze zmínit, že v PodSandbox a PodSandboxStatus pole runtime_handler pro zachycení informací o RuntimeClass v podu (více informací najdete v textu o , kde tato třída vznikla jako alfa-verze), a v Admission Webhooks možnost určovat, které verze AdmissionReview podporují. Nakonec, v pravidlech Admission Webhooks nyní rozsah jejich použití namespace'y a rámci clusteru.
Úložiště
, která měla status beta-verze od vydání , stabilní (GA): tato funkční brána již nebude vypínána a bude odstraněna v Kubernetes 1.17.
použití proměnných prostředí takzvaného (například názvu podu) pro názvy adresářů, které jsou připojeny jako , dočkala se rozšíření — ve formě nového pole subPathExpr, s jehož pomocí se nyní specifikuje potřebné jméno adresáře. Funkce se původně objevila v Kubernetes 1.11, ale pro 1.14 zůstala v statusu alfa-verze.
Jak v předchozím vydání Kubernetes, jsou představeny mnohé významné změny pro aktivně se rozvíjející CSI (Container Storage Interface):
CSI
se stalo dostupným (v rámci alfa-verze) změny velikosti pro CSI-objemy.Pro její použití je třeba aktivovat funkční bránu s názvem ExpandCSIVolumes, a také, aby konkrétní CSI ovladač podporoval tuto operaci.
Další funkce pro CSI v alfa-verzi — odkazovat přímo (tj. bez použití PV/PVC) na CSI-objemy v rámci specifikace podů. To odstraňuje omezení využití CSI jako výhradně vzdálených úložišť dat, otevírá pro ně dveře do světa Pro použití () je nutné aktivovat CSIInlineVolume funkční bránu.
Objevuje se pokrok i ve „vnitrnostech“ Kubernetes, které jsou spojené s CSI a nejsou tak patrné koncovým uživatelům (systémovým administrátorům)… V současnosti musí vývojáři udržovat dvě verze každého pluginu pro úložiště: jedna — „starší“, uvnitř kódové základny K8s (in-tree), a druhá — v rámci nového CSI (více informací naleznete například v ). To vyvolává pochopitelné nepříjemnosti, které je třeba odstranit, jak se CSI stabilizuje jako takové. Jednoduše vzít a prohlásit aplikační rozhraní vnitřních (in-tree) pluginů za zastaralá (deprecated) se nejeví jako možné kvůli .
Vše to vedlo k tomu, že alpha verze dosáhla interního kódu pluginů, implementovaných jako in-tree, v CSI plugins, díky čemuž budou starosti vývojářů omezeny na podporu jedné verze jejich pluginů, a kompatibilita se starými API zůstane zachována a mohou být prohlášeny za zastaralé běžným scénářem. Očekává se, že do dalšího vydání Kubernetes (1.15) proběhne migrace všech pluginů cloudových poskytovatelů, implementace získá status beta verze a bude aktivována ve standardních instalacích K8s. Podrobnosti viz . Důsledkem této migrace byl také od omezení pro objemy definované konkrétními cloudovými poskytovateli (AWS, Azure, GCE, Cinder).
Kromě toho podpora blokových zařízení s CSI (CSIBlockVolume) do beta verze.
Uzly / Kubelet
Byla představena alpha verze v Kubelet, určeného pro poskytování metrik o základních zdrojích. Obecně platí, že pokud dříve Kubelet získával statistiky o používání kontejnerů z cAdvisor, nyní tyto údaje přicházejí z prováděcího prostředí kontejneru přes CRI (Container Runtime Interface), avšak zachována je i kompatibilita pro práci se starými verzemi Dockeru. Dříve shromážděné statistiky v Kubelet byly poskytovány přes REST API, nyní se pro to používá endpoint umístěný na adrese /metrics/resource/v1alpha1. Dlouhodobá strategie vývojářů je minimalizovat soubor metrik, které Kubelet poskytuje. Mimochodem, samotné tyto metriky ne „core metrics“, ale „resource metrics“, a popisují je jako „first-class resources, such as cpu, and memory“.
Docela zajímavý detail: navzdory zřejmé výhodě v výkonu gRPC endpointu ve srovnání s různými případy použití formátu Prometheus (výsledek jednoho z benchmarků viz níže), autoři dali přednost textovému formátu Prometheus kvůli zřejmému vedení tohoto monitorovacího systému v komunitě.
„gRPC není kompatibilní s hlavními monitorovacími pipeline. Endpoint však bude užitečný pouze pro dodávání metrik do Metrics Server nebo komponent monitorování, které se s ním integrují přímo. Při použití caching v Metrics Server je výkon textového formátu Prometheus dostatečně dobrý. pro nás, abychom upřednostnili Prometheus před gRPC, vzhledem k široké popularitě Prometheus v komunitě. Jakmile formát OpenMetrics bude stabilnější, budeme moci dosáhnout výkonu gRPC pomocí formátu založeného na proto.
Jedním z porovnávacích testů výkonu použití formátů gRPC a Prometheus v novém endpointu Kubelet pro metriky. Více grafů a další podrobnosti naleznete v .
Mezi dalšími změnami:
- Kubelet nyní (jednou) kontejnery ve stavu neznámém (unknown) před restartováním a odstraňováním.
- Při používání nyní init-kontejneru stejné informace jako běžnému kontejneru.
- Kubelet
usageNanoCoresz poskytovatele statistik CRI, a pro uzly a kontejnery v systému Windows síťové statistiky. - Informace o operačním systému a architektuře jsou nyní zapisovány do štítků
kubernetes.io/osakubernetes.io/archobjektů Node (převzato z bety do GA). - Možnost specifikovat konkrétní systémovou skupinu uživatelů pro kontejnery v podu (
RunAsGroup, byla přidána ve ) do beta verze (zapnuta ve výchozím nastavení). - du a find používané v cAdvisor, Go-implementacemi.
CLI
V cli-runtime a kubectl přepínač -k pro integraci s (mimochodem, jeho vývoj nyní probíhá v samostatném repozitáři), tj. pro zpracování dalších YAML souborů ze speciálních adresářů kustomization (podrobnosti o jejich použití viz ):
Příklad jednoduchého použití souboru (možné i složitější aplikace kustomize v rámci )
Kromě toho:
- nový příkaz
kubectl create cronjob, jehož název hovoří sám za sebe. - V
kubectl logsnyní lze přepínače-f(--followpro streamování logů) a-l(--selectorpro label query). - kubectl kopírovat soubory vybírané pomocí wildcard.
- V příkazu
kubectl waitpříznak--allpro výběr všech zdrojů ve vymezeném prostoru názvů pro daný typ zdrojů.
Další
Stabilní (GA) status získaly následující funkce:
- , používaný ve specifikaci podu pro určení dalších podmínek, které se zohledňují při připravenosti podu;
- Podpora velkých stránek (feature gate nazvané );
- ;
- PriorityClass API, .
Další změny představené v Kubernetes 1.14:
- Politika RBAC ve výchozím nastavení již nezajišťuje přístup k API
discoveryaaccess-reviewuživatelům bez autentizace (unauthenticated). - Oficiální podpora CoreDNS pouze pro Linux, proto musí uzly při použití kubeadm pro nasazení (CoreDNS) v clusteru běžet pouze na Linuxu (pro toto omezení se používají nodeSelectors).
- Výchozí konfigurace CoreDNS nyní namísto proxy. Kromě toho, v CoreDNS readinessProbe, která zabraňuje rozložení zátěže na příslušné (nepřipravené k obsluze) pod’y.
- V kubeadm, ve fázích
initneboupload-certs, nahrávat certifikáty potřebné pro připojení nového control-plane k tajemství kubeadm-certs (používá se příznak--experimental-upload-certs). - Pro instalace Windows je k dispozici alpha verze gMSA (Group Managed Service Account) — speciální účty v Active Directory, které mohou používat i kontejnery.
- Pro GCE mTLS šifrování mezi etcd a kube-apiserver.
- Aktualizace ve 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 Docker API je nyní 1.26.
P.S.
Přečtěte si také náš blog:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
