Az 2019-es Helm Summit öt legfontosabb következtetése Amsterdamban

Ezéjjel éjjel lesz a Kubernetes következő kiadása — 1.14. Blogunk hagyományai szerint bemutatjuk a legfontosabb változásokat ezen csodálatos nyílt forráskódú termék új verziójában.

A cikk előkészítéséhez használt információk a következő forrásból származnak: Kubernetes enhancements tracking táblázat, CHANGELOG-1.14 és az ahhoz kapcsolódó problémák, pull requestek, Kubernetes Enhancement Proposals (KEP).

Kezdjük egy fontos bevezetéssel a SIG cluster-lifecycle-tól: dinamikus hibatűrő klaszterek A Kubernetes (pontosabban a self-hosted HA telepítések) most már létrehozhatók a megszokott (egyes egységű klaszterek esetén) parancsok segítségével kubeadm (init és join). Röviden szólva ehhez:

• a klaszter által használt tanúsítványokat titkokba helyezik;
• az etcd klaszter használatának lehetősége érdekében a K8s klaszterben (azaz megszabadulva a korábbinál külső függőségtől) bevezetésre került a etcd-operator;
• a külső terheléselosztó javasolt beállításait dokumentálják, ami biztosítja a hibatűrő konfigurációt (előreláthatólag ez a függőség is eltávolítható lesz, de nem ezen a szakaszon).

A kubeadm-mel létrehozott HA Kubernetes klaszter architektúrája

A megvalósítás részletei a következő címen érhetők el: design proposal. Ez a funkció igazán régóta várt: az alfa verziót már a K8s 1.9-ben várták, de csak most vált elérhetővé.

API

A parancs apply és egyáltalán deklaratív objektumkezelés átkerült a kubectl az apiserverbe. A fejlesztők röviden azzal indokolják a döntésüket, hogy kubectl apply — a Kubernetes konfigurációkkal végzett munka alapvető része, azonban „tele van hibákkal és nehezen javítható”, ezért ezt a funkcionalitást normál állapotba kell hozni és át kell helyezni a control plane-be. Néhány meglevő probléma egyszerű és szemléletes példái:

A megvalósítás részletei — a KEP. Jelenlegi állapot — alfa verzió (a bétára való áttérés a következő Kubernetes kiadásra van tervezve).

Az alfa verzióban elérhetővé vált a lehetőség az OpenAPI v3 séma használatára OpenAPI-dokumentáció létrehozásához és közzétételéhez a CustomResources (CR), amelyeket a felhasználó által meghatározott K8s erőforrások érvényesítésére használnak (CustomResourceDefinition, CRD). Az OpenAPI közzététele a CRD-hez lehetővé teszi a kliensek számára (például kubectl) hogy saját oldalon érvényesítést végezzenek (a kubectl create és kubectl apply) és séma dokumentációt biztosítsanak (kubectl explain). Részletek a következő címen találhatóak: KEP.

A korábban létezett naplók most megnyílnak zászlóval O_APPEND (a nem O_TRUNC) a naplók elvesztésének elkerülése érdekében bizonyos helyzetekben és a naplók külső segédprogramokkal való levágásának megkönnyítése érdekében.

A Kubernetes API kontextusában érdemes megjegyezni, hogy a PodSandbox és PodSandboxStatus hozzáadva mező runtime_handler az információ figyelembevételére a RuntimeClass pod-ban (további részletekért olvassa el a Kubernetes 1.12 kiadással kapcsolatos szöveget, ahol ez a osztály alpha verzióként jelent meg), valamint a Felvételi Webhookoklehetőség a támogatott verziók meghatározására, megvalósítva amelyeket az AdmissionReview támogatnak. Végül a Felvételi Webhookok szabályaiban most korlátozhatók a névterek és a klaszter keretek használatával.

A tárolók

Állandó Helyi Tárhelyek, amelyek a K8s 1.10 kiadása óta bétaverzióban voltak,, bejelentették stabilnak (GA): ez a funkciós kapu többé nem kapcsolható ki, és a Kubernetes 1.17-ben el fog tűnni.

Lehetőség a környezeti változók használata, úgynevezett Downward API (például a pod neve) könyvtárak neveinek meghatározására, amelyek mint subPath, fejlődést kaptak — új mezőként, subPathExpr, amellyel most a megfelelő könyvtár nevét határozzák meg. E funkció eredetileg a Kubernetes 1.11-ben jelent meg, de az 1.14-nek is megmaradt alpha verzióban.

Mint a Kubernetes előző kiadásában, számos jelentős változás történt a folyamatosan fejlődő CSI (Container Storage Interface) terén:

CSI

Alpha verzióban elérhetővé vált a CSI-tárolók méretének módosítása. Passkey . Ehhez a funkciós kapu engedélyezése szükséges,ExpandCSIVolumes , valamint a konkrét CSI-illesztőprogram támogatásának megléte.Egy újabb alpha verziós funkció a CSI esetében —

közvetlenül (azaz PV/PVC használata nélkül) hivatkozni a CSI-tárolókra a pod-specifikáció keretein belül. Ez lehetőség eltávolítja azt a korlátot, amely a CSI kizárólag távoli adathordozók használatára vonatkozik, megnyitva előttük ahelyi ephemerális tárolók világát. A használathoz (példa a dokumentációból) engedélyezni kell aCSIInlineVolume funkciós kaput. Különböző fejlődés figyelhető meg a Kubernetes „belső részein”, amelyek nem annyira észlelhetők a végfelhasználók (rendszergazdák) számára... Jelenleg a fejlesztőknek két verziót kell fenntartaniuk minden tároló pluginnal kapcsolatban: az egyiket — a régi módon — a K8s kódalapján belül (in-tree), a másikat — az új CSI keretein belül.

(további részletekért olvassa el például a (további információt róla például itt olvashat) itt)Ez érthető kényelmetlenségeket okoz, amelyeket orvosolni kell a CSI stabilizálásának folyamatában. Nem lehet egyszerűen elavultnak (deprecated) nyilvánítani a belső (in-tree) pluginokat a megfelelő PoliTikája miatt. Kubernetes.

Mindez oda vezetett, hogy az alfa verziók elérték a migrációs folyamatot a pluginok belső kódját, amelyeket in-tree-re valósítottak meg, a CSI pluginokban, így a fejlesztők gondjait egyetlen verzió támogatására csökkentik, és a régi API-k kompatibilitása megmarad, így azokat a megszokott ütemezés szerint elavultnak nyilváníthatják. A várakozások szerint a következő Kubernetes verzióra (1.15) a felhőszolgáltatók összes pluginját migrálni fogják, a megvalósítás béta verziót kap, és alapértelmezés szerint aktiválódik a K8s telepítésekben. Részletek itt találhatók: design proposal. A migráció következményei között szerepel a megszorítások eltörlése a kifejezetten felhőszolgáltatók (AWS, Azure, GCE, Cinder) által meghatározott kötetekre vonatkozóan.

Ezenkívül a CSI által támogatott blokkos eszközök (CSIBlockVolume) béta verzióra került .

Csomópontok / Kubelet

Bemutatkozott az alfa verziója új endpointnak Kubeletben, amely a alapvető erőforrások metrikáit szolgáltatja. Általánosságban elmondható, hogy ha korábban a Kubelet a cAdvisor-ból származó konténerhasználati statisztikákat szerzett, most ezek az adatok a konténer végrehajtási környezetéből érkeznek a CRI (Container Runtime Interface) révén, de a régi Docker verziókkal való kompatibilitás is megmarad. A Kubelet által korábban összegyűjtött statisztikák REST API-n keresztül kerültek bemutatásra, most viszont egy endpoint révén, amely a következő címen található: /metrics/resource/v1alpha1. A fejlesztők hosszú távú stratégiája az, hogy minimalizálják a Kubelet által nyújtott metrikák számát. Egyébként ezek a metrikák mostantól nem "core metrics"-ként, hanem "resource metrics"-ként szerepelnek, és az "elsőszámú erőforrásként, mint a CPU és a memória" írják le. Nagyon érdekes megjegyzés: annak ellenére, hogy a gRPC endpoint teljesítménye egyértelmű előnyben van a Prometheus formátum különböző felhasználási eseteivel szemben,

(az alábbi benchmark egyik eredménye) , a szerzők a Prometheus szöveges formátumát preferálták, mivel ez a monitorozási rendszer egyértelműen dominál a közösségben..

A gRPC nem kompatibilis a központi monitorozási folyamatokkal. Az endpoint hasznos lesz a metrikák Metrics Serverbe vagy olyan monitorozó komponensekbe történő szállításához, amelyek közvetlenül integrálódnak vele. A Metrics Serverben történő gyorsítótárazás során a Prometheus szöveges formátumának teljesítménye elég jó számunkra, hogy előnyben részesítsük a Prometheust a gRPC-vel szemben, figyelembe véve a Prometheus széles körű elterjedtségét a közösségben. Amikor az OpenMetrics formátum stabilabbá válik, a proto-alapú formátummal megközelíthetjük a gRPC teljesítményét.

Az gRPC és Prometheus formátumok teljesítményének összehasonlító tesztje egy új endpointon a Kubeleten a metrikák számára. További grafikonok és részletek találhatók a KEP.

A többi változás között:

• A Kubelet most (egyszer) megpróbálja leállítani a bizonytalan állapotú (unknown) konténereket a újraindítási és törlési műveletek előtt.
• Használat közben PodPresets most az init-konténerhez a szokásos konténerhez hasonló információkat hozzáad.
• A Kubelet most kezdte használni usageNanoCores a CRI statisztikai szolgáltatótól, valamint a Windows csomópontok és konténerek esetében hozzáadva lett hálózati statisztikák.
• Az operációs rendszer és az architektúra információi most a címkékbe kerülnek kubernetes.io/os és kubernetes.io/arch a Node objektumokhoz (beta-ból GA-ba átkerült).
• Lehetővé vált egy konkrét rendszer felhasználói csoport megadása a podban lévő konténerek számára (RunAsGroup), ami a K8s 1.11) előrelépett béta verzióra (alapértelmezés szerint engedélyezve).
• A du és find, amelyeket cAdvisorban használnak, Go-implementációkra lettek cserélve.

CLI

A cli-runtime és a kubectl hozzáadva flag -k az integrációval kapcsolatosan kustomize (mellesleg, a fejlesztése most egy külön repóban zajlik), azaz a kustomization speciális könyvtárakból származó további YAML-fájlok feldolgozásához (a használatuk részleteit lásd a KEP):

Egyszerű példa a kustomization fájl használatára (továbbá bonyolultabb kustomize alkalmazásra is a overlays)

Ezenkívül:

• Hozzáadva új parancsot kubectl create cronjob, amelynek neve önmagáért beszél.
• A A kubectl logs most már kombinálható flagokkal -f (--follow a naplók streamingjéhez) és -l (--selector a label lekérdezéshez).
• kubectl Megtanultunk fájlokat másolni, amelyek wild card segítségével lettek kiválasztva.
• A kubectl wait csapathoz hozzáadtuk a flagot --all minden erőforrás kiválasztásához az adott erőforrás típusú névtérben.

Egyéb

Stabil (GA) státuszt kapott a következő lehetőségek:

• ReadinessGate, amelyet a pod specifikációjában használnak a pod készenlétének figyelembevételére vonatkozó további feltételek meghatározásához;
• Nagyméretű lapok támogatása (feature gate neve HugePages);
• CustomPodDNS;
• PriorityClass API, Pod prioritás és előretoltás.

A Kubernetes 1.14-ben bemutatott egyéb változások:

• Az alapértelmezett RBAC politika többé nem biztosít hozzáférést az API-hoz discovery és access-review felhasználók számára azonosítás nélkül (unauthenticated).
• A CoreDNS hivatalos támogatása biztosítva van csak Linux alatt, ezért a kubeadm használatával a (CoreDNS) klaszterbe történő telepítésekor a csomópontoknak csak Linux-on kell futniuk (e korlátozás érdekében nodeSelectors-t használnak).
• A CoreDNS alapértelmezett konfigurációja most használja forward plugin proxy helyett. Ezen kívül a CoreDNS hozzáadva lett readinessProbe-ot tartalmaz, amely megakadályozza a terheléselosztást a megfelelő (szolgáltatásra nem kész) pod-okra.
• A kubeadm-nál a fázisokban init vagy upload-certs, mostantól lehetséges feltölteni a szükséges tanúsítványokat az új control-plane csatlakoztatásához a kubeadm-certs titkosításhoz (e flag használatával: --experimental-upload-certs).
• Windows telepítésekhez megjelent egy alfa verzió támogatás gMSA (Group Managed Service Account) — speciális fiókok az Active Directory-ban, amelyeket konténerek is használhatnak.
• GCE-hez aktívvá tették mTLS titkosítást az etcd és a kube-apiserver között.
• Frissítések a használt / függő szoftverekben: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, kubeadm által biztosított Docker 18.09 támogatás, a minimálisan támogatott Docker API verzió pedig 1.26 lett.

P.S.

Olvasson további információkat a blogunkban:

• «Kubernetes 1.13: a fő újdonságok áttekintése»;
• «Kubernetes 1.12: a fő újdonságok áttekintése»;
• «Kubernetes 1.11: a fő újdonságok áttekintése»;
• «Kubernetes 1.10: a fő újdonságok áttekintése».

Forrás: habr.com