🥇Kubernetes 1.16: a főbb újítások áttekintése

Ma, szerdán, kerül sor A Kubernetes következő kiadása - 1.16. A blogunkhoz kialakult hagyomány szerint immár tizedik évfordulója, amikor az új verzió legjelentősebb változásairól beszélünk.

Az anyag elkészítéséhez használt információk innen származnak Kubernetes fejlesztések nyomkövetési táblái, VÁLTOZTATÁS-1.16 és a kapcsolódó problémák, lehívási kérések és Kubernetes fejlesztési javaslatok (KEP). Akkor gyerünk!..

Csomópontok

A K8s fürtcsomópontjainak (Kubelet) oldalán valóban nagyszámú figyelemre méltó újítás (alfa verzió státuszban) jelenik meg.

Először is az ún «efemer konténerek» (Efemer konténerek), amelynek célja a podokban történő hibakeresési folyamatok egyszerűsítése. Az új mechanizmus lehetővé teszi speciális konténerek elindítását, amelyek a meglévő podok névterében indulnak és rövid ideig élnek. Céljuk, hogy kölcsönhatásba lépjenek más podokkal és konténerekkel a problémák megoldása és a hibakeresés érdekében. Ehhez a funkcióhoz egy új parancs került bevezetésre kubectl debug, lényegében hasonló kubectl exec: csak ahelyett, hogy egy folyamatot egy tárolóban futtatnának (mint pl exec) egy tokban lévő konténert indít. Például ez a parancs egy új tárolót csatlakoztat egy podhoz:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Az efemer tartályokkal kapcsolatos részletek (és példák felhasználásukra) itt találhatók megfelelő KEP. A jelenlegi megvalósítás (a K8s 1.16-ban) egy alfa verzió, és a bétaverzióba való átvitel feltételei között szerepel „az Ephemeral Containers API tesztelése a [Kubernetes] legalább 2 kiadásához”.

NB: Lényegében és még a nevében is a funkció egy már létező bővítményre hasonlít kubectl-debugamiről mi már írt. Várhatóan az efemer konténerek megjelenésével egy különálló külső plugin fejlesztése megszűnik.

Egy másik újítás - PodOverhead - biztosítására tervezték a hüvelyek rezsiköltségeinek kiszámítására szolgáló mechanizmus, amely a használt futásidőtől függően nagymértékben változhat. Példaként a szerzők ez a KEP Kata-tárolókat eredményez, amelyekhez a vendég kernel, kata ügynök, init rendszer stb. futtatása szükséges. Amikor a rezsi ilyen nagy lesz, nem lehet figyelmen kívül hagyni, ami azt jelenti, hogy módot kell adni arra, hogy figyelembe vegyék a további kvóták, tervezés stb. A megvalósításhoz PodSpec mező hozzáadva Overhead *ResourceList (összehasonlítva az alábbi adatokkal RuntimeClass, ha van ilyen).

Egy másik figyelemre méltó újítás az csomópont topológia menedzser (Csomópont-topológiakezelő), amelynek célja, hogy egységesítse a hardver erőforrások elosztásának finomhangolását a Kubernetes különböző összetevőihez. Ezt a kezdeményezést a különböző modern rendszerek (telekommunikáció, gépi tanulás, pénzügyi szolgáltatások stb. területéről) növekvő igénye vezérli a nagy teljesítményű párhuzamos számítástechnika és a műveletek végrehajtási késésének minimalizálása iránt, amelyhez fejlett CPU-t, ill. hardveres gyorsítási képességek. A Kubernetes ilyen optimalizálásai eddig az eltérő komponenseknek (CPU-kezelő, Eszközkezelő, CNI) köszönhetően valósultak meg, most pedig egyetlen belső interfésszel egészül ki, amely egységesíti a megközelítést és leegyszerűsíti az új, hasonló - úgynevezett topológiás - összekapcsolását. aware - komponensek a Kubelet oldalon. Részletek - in megfelelő KEP.

Topológiakezelő komponens diagram

Következő funkció - konténerek ellenőrzése futás közben (indítási szonda). Mint ismeretes, a hosszú ideig tartó konténereknél nehéz naprakész állapotot kapni: vagy „megölik”, mielőtt ténylegesen működésbe lépnének, vagy hosszú időre holtpontra kerülnek. Új ellenőrzés (engedélyezve a funkciókapun keresztül StartupProbeEnabled) törli – vagy inkább elhalasztja – minden egyéb ellenőrzés hatását addig a pillanatig, amíg a pod futni be nem fejeződik. Emiatt a funkciót eredetileg hívták pod-startup liveness-probe holdoff. Azoknál a pod-oknál, amelyek indulása hosszú ideig tart, viszonylag rövid időközönként lekérdezheti az állapotot.

Ezenkívül a RuntimeClass fejlesztése azonnal elérhető béta állapotban, amely támogatja a „heterogén fürtöket”. C RuntimeClass ütemezés Most már egyáltalán nem szükséges, hogy minden csomópont támogassa az egyes RuntimeClass-okat: a pod-ok esetében kiválaszthat egy RuntimeClass-t anélkül, hogy a fürt topológiájára gondolna. Korábban ennek eléréséhez – hogy a pod-ok olyan csomópontokra kerüljenek, amelyek támogatják mindazt, amire szükségük van – megfelelő szabályokat kellett hozzárendelni a NodeSelectorhoz és a tűrésekhez. BAN BEN SAPKA Szól a felhasználási példákról és természetesen a megvalósítás részleteiről.

Hálózat

Két jelentős hálózati funkció, amely először (alfa verzióban) jelent meg a Kubernetes 1.16-ban:

támogatás kettős hálózati verem - IPv4/IPv6 - és ennek megfelelő „megértése” a podok, csomópontok, szolgáltatások szintjén. Tartalmazza az IPv4-ről IPv4-re és IPv6-ról IPv6-ra való interoperabilitást a pod-ok között, a podoktól a külső szolgáltatásokig, a referencia implementációkat (a Bridge CNI-n, a PTP CNI-n és a Host-Local IPAM-bővítményeken belül), valamint a fordított kompatibilitást a futó Kubernetes-fürtökkel. Csak IPv4 vagy IPv6. A megvalósítás részletei megtalálhatók SAPKA.
Példa kétféle IP-cím (IPv4 és IPv6) megjelenítésére a pod-listában:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Új API a végponthoz - EndpointSlice API. Megoldja a meglévő Endpoint API teljesítmény/skálázhatósági problémáit, amelyek a vezérlősík különböző összetevőit érintik (apiserver, etcd, endpoints-controller, kube-proxy). Az új API hozzáadásra kerül a Discovery API csoporthoz, és több tízezer háttér-végpontot tud majd kiszolgálni minden szolgáltatáson egy több ezer csomópontból álló fürtben. Ehhez minden szolgáltatás N objektumra van leképezve EndpointSlice, amelyek alapértelmezés szerint nem tartalmaznak 100-nál több végpontot (az érték konfigurálható). Az EndpointSlice API a jövőbeni fejlesztésére is lehetőséget biztosít: több IP-cím támogatása minden podhoz, új állapotok a végpontokhoz (nem csak Ready и NotReady), dinamikus részhalmaz a végpontokhoz.

Az utolsó kiadásban bemutatott elérte a béta verziót véglegesítő, nevezett service.kubernetes.io/load-balancer-cleanup és minden szolgáltatáshoz típussal csatolva LoadBalancer. Egy ilyen szolgáltatás törlésekor megakadályozza az erőforrás tényleges törlését mindaddig, amíg az összes releváns kiegyenlítő erőforrás „tisztítása” be nem fejeződik.

API gépek

Az igazi „stabilizációs mérföldkő” a Kubernetes API szerver és a vele való interakció területén van. Ez nagyrészt annak köszönhető stabil státuszba helyezése azokat, akik nem szorulnak különösebb bemutatásra CustomResourceDefinitions (CRD), amelyek a Kubernetes 1.7 távoli napjai óta (és ez 2017 júniusa!) béta állapotúak. Ugyanez a stabilizáció jött létre a kapcsolódó funkcióknál is:

"alforrások" -val /status и /scale a CustomResources számára;
transzformáció külső webhook-on alapuló CRD-verziók;
nemrég bemutatott (K8s 1.15-ben) alapértelmezett értékek (alapértelmezett) és automatikus mezőeltávolítás (metszés) a CustomResources számára;
alkalom Az OpenAPI v3 séma használatával létrehozhat és közzétehet OpenAPI-dokumentációt, amely a kiszolgálóoldali CRD-erőforrások érvényesítésére szolgál.

Egy másik mechanizmus, amely már régóta ismerős a Kubernetes rendszergazdáknak: felvételi webhook - szintén béta státuszban maradt sokáig (a K8s 1.9 óta), és most stabilnak nyilvánították.

Két másik funkció is elérte a béta verziót: szerveroldali érvényes и nézze meg a könyvjelzőket.

És az egyetlen jelentős újítás az alfa verzióban az volt hiba -tól SelfLink — egy speciális URI, amely a megadott objektumot képviseli és annak része ObjectMeta и ListMeta (azaz bármely objektum része a Kubernetesben). Miért hagyják el? Motiváció egyszerű módon hangok mint a valódi (elsöprő) okok hiánya annak, hogy ez a terület továbbra is fennáll. Formálisabb okok a teljesítmény optimalizálása (egy szükségtelen mező eltávolításával) és a generic-apiserver munkájának egyszerűsítése, amely egy ilyen mezőt speciális módon kénytelen kezelni (ez az egyetlen mező, amely közvetlenül az objektum előtt van beállítva szerializálva van). Valódi elavulás (béta verzión belül) SelfLink a Kubernetes 1.20-as verziójával, a végleges pedig az 1.21-es verzióval fog megtörténni.

Adattárolás

A tárolás területén a fő munka, mint a korábbi kiadásoknál is, a területen zajlik CSI támogatás. A főbb változások itt a következők voltak:

először (alfa verzióban) megjelent CSI beépülő modul támogatása a Windows dolgozói csomópontokhoz: a tárolás jelenlegi módja a Kubernetes magban található fán belüli beépülő modulokat és a Microsoft Powershell alapú FlexVolume bővítményeit is felváltja;

Séma a CSI-bővítmények megvalósításához a Kubernetes for Windows rendszerben
alkalom a CSI kötetek átméretezése, amelyet még a K8s 1.12-ben vezettek be, béta verzióvá nőtte ki magát;
Hasonló "promóciót" (alfáról béta verzióra) ért el az a lehetőség, hogy CSI-t lehetett használni helyi átmeneti kötetek létrehozására (CSI Inline Volume támogatás).

A Kubernetes előző verziójában került bevezetésre kötet klónozás funkció (meglévő PVC felhasználásával, mint DataSource új PVC létrehozására) szintén béta állapotot kapott.

Ütemező

Két jelentős változás az ütemezésben (mindkettő alfa):

EvenPodsSpreading - lehetőség használjon podokat a logikai alkalmazási egységek helyett a terhelések „méltányos elosztásához”. (mint például a Deployment és a ReplicaSet) és ennek a disztribúciónak a módosítása (mint kemény követelmény vagy puha feltétel, azaz prioritás). A funkció kibővíti a tervezett pod-ok meglévő terjesztési lehetőségeit, amelyeket jelenleg az opciók korlátoznak PodAffinity и PodAntiAffinity, ami finomabb ellenőrzést biztosít a rendszergazdáknak ebben a kérdésben, ami jobb magas rendelkezésre állást és optimalizált erőforrás-felhasználást jelent. Részletek - in SAPKA.
Használat BestFit szabályzat в RequestedToCapacityRatio prioritási függvény a pod tervezés során, ami lehetővé teszi alkalmaz szemetes csomagolás ("csomagolás konténerekbe") mind az alapvető erőforrásokhoz (processzor, memória), mind a kiterjesztett erőforrásokhoz (például GPU). További részletekért lásd SAPKA.

Pods ütemezése: a legjobb illeszkedés házirend használata előtt (közvetlenül az alapértelmezett ütemezőn keresztül) és annak használatával (ütemező bővítőn keresztül)

Továbbá, bemutatott saját ütemező beépülő modulok létrehozásának lehetősége a fő Kubernetes fejlesztési fán kívül (fán kívül).

Egyéb változások

A Kubernetes 1.16 kiadásban is meg lehet jegyezni számára kezdeményezés hozva elérhető mérőszámok teljes sorrendben, pontosabban annak megfelelően hatósági előírásokat a K8s műszerekhez. Nagyrészt a megfelelőre támaszkodnak Prometheus dokumentáció. Különböző okok miatt következetlenségek adódtak (például néhány mérőszámot egyszerűen létrehoztak a jelenlegi utasítások megjelenése előtt), és a fejlesztők úgy döntöttek, hogy itt az ideje, hogy mindent egyetlen szabványra hozzanak, „a Prometheus ökoszisztéma többi részével összhangban”. A kezdeményezés jelenlegi megvalósítása alfa státuszban van, amelyet a Kubernetes következő verzióiban fokozatosan béta (1.17) és stabil (1.18) állapotba hoznak.

Ezenkívül a következő változások figyelhetők meg:

Windows támogatás fejlesztés с megjelenés Kubeadm segédprogramok ehhez az operációs rendszerhez (alfa verzió), lehetőség RunAsUserName Windows-tárolókhoz (alfa verzió), javulás Csoportfelügyelt szolgáltatásfiók (gMSA) támogatása a béta verzióig, támogatás mount/csatolás vSphere kötetekhez.
Újrahasznosított adattömörítési mechanizmus az API-válaszokban. Korábban HTTP-szűrőt használtak erre a célra, amely számos korlátozást írt elő, amelyek megakadályozták, hogy alapértelmezés szerint engedélyezzék. Az "átlátszó kéréstömörítés" most működik: az ügyfelek küldik Accept-Encoding: gzip a fejlécben GZIP-tömörített választ kapnak, ha annak mérete meghaladja a 128 KB-ot. A Go kliensek automatikusan támogatják a tömörítést (a szükséges fejléc elküldését), így azonnal észreveszik a forgalom csökkenését. (Más nyelveknél kisebb módosításokra lehet szükség.)
Lehetővé vált a HPA skálázása nulláról/nullára a külső mérőszámok alapján. Ha objektumok/külső metrikák alapján skáláz, akkor amikor a munkaterhelések tétlen, automatikusan 0 replikára méretezheti az erőforrások megtakarítása érdekében. Ez a funkció különösen hasznos lehet olyan esetekben, amikor a dolgozók GPU-erőforrásokat igényelnek, és a különböző típusú tétlen dolgozók száma meghaladja az elérhető GPU-k számát.
Új ügyfél - k8s.io/client-go/metadata.Client – az objektumokhoz való „általánosított” hozzáféréshez. Úgy tervezték, hogy könnyen lekérje a metaadatokat (azaz alszakaszokat metadata) klaszter erőforrásokból, és szemétgyűjtési és kvótaműveleteket végezzen velük.
Build Kubernetes most már tudod örökölt („beépített” in-tree) felhőszolgáltatók nélkül (alfa verzió).
A kubeadm segédprogramhoz - tette hozzá kísérleti (alfa verzió) képesség testreszabott javítások alkalmazására a műveletek során init, join и upgrade. További információ a zászló használatáról --experimental-kustomize, lásd be SAPKA.
Új végpont az apiserverhez - readyz, - lehetővé teszi a készenléti adatok exportálását. Az API-kiszolgálónak is van jelzője --maximum-startup-sequence-duration, amely lehetővé teszi az újraindítások szabályozását.
két funkciók az Azure számára stabilnak nyilvánított: támogatás elérhetőségi zónák (Rendelkezésre állási zónák) és kereszt erőforráscsoport (RG). Ezenkívül az Azure a következőket is hozzáadta:
- hitelesítés támogatása AAD és ADFS;
- annotáció service.beta.kubernetes.io/azure-pip-name a terheléselosztó nyilvános IP-címének megadása;
- alkalom beállítások LoadBalancerName и LoadBalancerResourceGroup.
Az AWS most megvan támogatás EBS-hez Windowson és optimalizált EC2 API hívások DescribeInstances.
Kubeadm immár független vándorol CoreDNS konfiguráció a CoreDNS verzió frissítésekor.
Binárisok stb a megfelelő Docker-képben megtettem world-executable, amely lehetővé teszi a kép futtatását root jogok nélkül. Továbbá, etcd migrációs kép megszűnt etcd2 verzió támogatása.
В Cluster Autoscaler 1.16.0 átváltott a distroless használatára alapképként, javult a teljesítmény, új felhőszolgáltatók kerültek be (DigitalOcean, Magnum, Packet).
Frissítések a használt/függő szoftverekben: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Olvassa el blogunkon is:

Forrás: will.com

Kubernetes 1.16: a főbb újítások áttekintése