Ma éjjel a Kubernetes következő kiadása - . A blogunkhoz kialakult hagyomány szerint ennek a csodálatos nyílt forráskódú terméknek az új verziójában a legfontosabb változásokról beszélünk.
Az anyag elkészítéséhez használt információk innen származnak , és a kapcsolódó problémák, lehívási kérések, Kubernetes fejlesztési javaslatok (KEP).
Kezdjük egy fontos bevezetővel a SIG-fürt életciklusából: dinamikus feladatátvételi fürtök A Kubernetes (pontosabban, saját üzemeltetésű HA-telepítések) most ismert (egycsomópontos klaszterek kontextusában) parancsok használatával kubeadm (init и join). Röviden ehhez:
- a fürt által használt tanúsítványok titkosításra kerülnek;
- az etcd klaszter K8s klaszteren belüli használatának lehetőségéért (azaz a korábban meglévő külső függőségtől való megszabaduláshoz) ;
- Dokumentálja a hibatűrő konfigurációt biztosító külső terheléselosztó javasolt beállításait (a jövőben tervezik ennek a függőségének megszüntetését, de ebben a szakaszban nem).
A kubeadm-mel létrehozott Kubernetes HA-fürt felépítése
A megvalósítás részleteit a . Ezt a funkciót valóban régóta várták: az alfa verziót már a K8s 1.9-ben várták, de csak most jelent meg.
API
Csapat apply és általában véve deklaratív objektumkezelés A kubectl apiserverben. Maguk a fejlesztők röviden ezzel indokolják döntésüket kubectl apply - A Kubernetes konfigurációival való munka alapvető része, azonban „tele van hibákkal és nehezen javítható”, ezért ezt a funkciót vissza kell állítani a normál állapotba, és át kell vinni a vezérlősíkra. Egyszerű és világos példák a mai problémákra:
A megvalósítás részletei itt találhatók . A jelenlegi készenléti állapot alfa (a következő Kubernetes-kiadásnál a béta verzióra való előléptetést tervezik).
Alfa verzióban elérhető az OpenAPI v3 séma használatával OpenAPI dokumentáció létrehozása és közzététele a CustomResources számára (CR) a (kiszolgálóoldali) K8s felhasználó által definiált erőforrásainak (CustomResourceDefinition, CRD) érvényesítésére szolgál. Az OpenAPI for CRD közzététele lehetővé teszi az ügyfelek számára (pl. kubectl) hajtsa végre az érvényesítést az Ön oldalán (azon belül kubectl create и kubectl apply) és dokumentációt állít ki a séma szerint (kubectl explain). Részletek - in .
Már meglévő naplók zászlóval O_APPEND (de nem O_TRUNC).
A Kubernetes API-val összefüggésben is megjegyezhető, hogy in PodSandbox и PodSandboxStatus mező runtime_handler információt rögzíteni arról RuntimeClass a hüvelyben (erről bővebben a következő szövegben olvashat). , ahol ez az osztály alfa verzióként jelent meg), és a Felvételi Webhooksban képes meghatározni, hogy mely verziók AdmissionReview támogatják. Végezetül a Belépés Webhooks szabályai már érvényesek névterek és fürtkeretrendszerek általi használatuk mértéke.
Tárolás
, amely megjelenése óta béta állapotú , stabil (GA): ez a funkciókapu már nincs letiltva, és a Kubernetes 1.17-ben el lesz távolítva.
nevű környezeti változók segítségével (például a pod neve) a következőként csatolt könyvtárak nevéhez , alakult ki - új terület formájában subPathExpr, amely most a kívánt könyvtárnév meghatározására szolgál. A funkció kezdetben a Kubernetes 1.11-ben jelent meg, de az 1.14-es verzióban alfa verzióban maradt.
Az előző Kubernetes-kiadáshoz hasonlóan számos jelentős változás történt az aktívan fejlődő CSI-ben (Container Storage Interface):
CSI
Elérhetővé vált (az alfa verzió részeként) átméretezés a CSI kötetekhez. Használatához engedélyeznie kell a nevezett funkció kaput ExpandCSIVolumes, valamint a művelet támogatásának megléte egy adott CSI-illesztőprogramban.
Egy másik funkció a CSI számára az alfa verzióban - közvetlenül (azaz PV/PVC használata nélkül) hivatkozzon a CSI-kötetekre a pod specifikáción belül. Ez megszünteti a CSI kizárólag távoli adattárolóként való használatára vonatkozó korlátozást, ajtókat nyitva számukra a világ felé . Használatra () engedélyezni kell CSIInlineVolume jellemző kapu.
Előrelépés történt a Kubernetes CSI-vel kapcsolatos „belső részeiben” is, amelyek nem annyira láthatóak a végfelhasználók (rendszergazdák) számára... Jelenleg a fejlesztők kénytelenek minden egyes tárolóbővítmény két verzióját támogatni: egyet - „a old way”, a K8s kódbázisán belül (-tree), a második pedig az új CSI részeként (erről bővebben olvashat pl ). Ez érthető kellemetlenségeket okoz, amelyeket kezelni kell, mivel maga a CSI stabilizálódik. A belső (fán belüli) beépülő modulok API-ját nem lehet egyszerűen megszüntetni .
Mindez oda vezetett, hogy az alfa verzió elérte belső plugin kód, in-tree-ként, CSI-bővítményekben implementálva, aminek köszönhetően a fejlesztők gondja a bővítményeik egy-egy verziójának támogatására csökken, és megmarad a kompatibilitás a régi API-kkal, és a szokásos forgatókönyv szerint elavulttá nyilváníthatók. Várhatóan a Kubernetes (1.15) következő kiadására az összes felhőszolgáltató beépülő modul áttelepül, a megvalósítás béta állapotot kap, és alapértelmezés szerint aktiválódik a K8s telepítéseiben. A részletekért lásd . Ez a migráció azt is eredményezte adott felhőszolgáltatók (AWS, Azure, GCE, Cinder) által meghatározott mennyiségi korlátokból.
Ezenkívül a blokkeszközök támogatása CSI-vel (CSIBlockVolume) béta verzióra.
Nodes/Kubelet
Bemutatták az alfa verziót a Kubeletben, erre tervezték a kulcsfontosságú erőforrásokra vonatkozó mérőszámokat. Általánosságban elmondható, hogy ha korábban a Kubelet konténerhasználati statisztikákat kapott a cAdvisortól, most ezek az adatok a konténer futási környezetéből származnak a CRI-n (Container Runtime Interface) keresztül, de a kompatibilitás a Docker régebbi verzióival is megmarad. Korábban a Kubeletben gyűjtött statisztikákat a REST API-n keresztül küldték el, de most egy végpont a címen található /metrics/resource/v1alpha1. A fejlesztők hosszú távú stratégiája célja a Kubelet által biztosított mérőszámok minimalizálása. Egyébként maguk ezek a mutatók nem „alapmutatók”, hanem „erőforrás-metrikák”, és „első osztályú erőforrások, például CPU és memória”ként írják le őket.
Egy nagyon érdekes árnyalat: annak ellenére, hogy a gRPC végpont egyértelmű teljesítményelőnye a Prometheus formátum használatának különböző eseteihez képest (lásd alább az egyik benchmark eredményét), a szerzők a Prometheus szöveges formátumát részesítették előnyben, mivel ez a megfigyelőrendszer egyértelműen vezet a közösségben.
„A gRPC nem kompatibilis a főbb felügyeleti csővezetékekkel. A végpont csak akkor lesz hasznos, ha metrikákat szállít a Metrics Serverre, vagy olyan komponenseket figyel, amelyek közvetlenül integrálódnak vele. Prometheus szövegformátum teljesítménye gyorsítótárazás használatakor a Metrics Serverben elég jó hogy előnyben részesítsük a Prometheust a gRPC-vel szemben, mivel a Prometheus széles körben elterjedt a közösségben. Amint az OpenMetrics formátum stabilabbá válik, meg tudjuk közelíteni a gRPC teljesítményét egy proto-alapú formátummal.”
A gRPC és Prometheus formátumok használatának egyik összehasonlító teljesítménytesztje a metrikák új Kubelet-végpontjában. További grafikonok és egyéb részletek itt találhatók .
Többek között a változások:
- Kubelet most (egyszer) ismeretlen állapotú tárolók újraindítása és törlése előtt.
- Ha a most az init tárolóba ugyanaz az információ, mint egy normál konténernél.
- kubelet
usageNanoCoresa CRI statisztikai szolgáltatótól, valamint a Windows csomópontjaihoz és tárolóihoz hálózati statisztikák. - Az operációs rendszerre és az architektúrára vonatkozó információk mostantól címkéken vannak rögzítve
kubernetes.io/osиkubernetes.io/archCsomópont objektumok (béta verzióból GA-ba átvitel). - Lehetőség egy adott rendszer felhasználói csoport megadására a podban lévő tárolókhoz (
RunAsGroup, megjelent ) béta előtt (alapértelmezés szerint engedélyezve van). - du és find a cAdvisorban használatos, on Go megvalósítás.
CLI
A cli-runtime és a kubectl -k jelző a következővel való integrációhoz (egyébként a fejlesztését ma már külön tárolóban végzik), i.e. további YAML-fájlok feldolgozásához speciális kustomizációs könyvtárakból (a használatukkal kapcsolatos részletekért lásd: ):
Példa egyszerű fájlhasználatra (a kustomize bonyolultabb alkalmazása is lehetséges )
Ezen kívül:
- új csapat
kubectl create cronjob, akinek a neve magáért beszél. - В
kubectl logsmost már tudod zászlókat-f(--follownaplók streameléséhez) és-l(--selectorcímkelekérdezéshez). - kubectl helyettesítő karakterrel kiválasztott fájlok másolása.
- A csapatnak
kubectl waitzászló--allhogy kijelölje az összes erőforrást a megadott erőforrástípus névterében.
Egyéb
A következő képességek kaptak stabil (GA) állapotot:
- , amelyet a hüvely specifikációjában használnak a hüvely készenléte során figyelembe vett további feltételek meghatározására;
- Támogatás a nagy oldalakhoz (funkciókapu hívják );
- ;
- PriorityClass API .
A Kubernetes 1.14-ben bevezetett egyéb változtatások:
- Az alapértelmezett RBAC-házirend már nem teszi lehetővé az API-hozzáférést
discoveryиaccess-reviewhitelesítés nélküli felhasználók (nem hitelesített). - Hivatalos CoreDNS támogatás Csak Linux, tehát ha a kubeadm-et használja a telepítéshez (CoreDNS) egy fürtben, a csomópontok csak Linuxon futhatnak (ehhez a korlátozáshoz a csomópontválasztók használatosak).
- Az alapértelmezett CoreDNS konfiguráció most proxy helyett. A CoreDNS-ben is ReadinessProbe, amely megakadályozza a terheléselosztást a megfelelő (szolgáltatásra nem kész) podokon.
- Kubeadm-ben, fázisokon
initvagyupload-certs, töltse be az új vezérlősíknak a kubeadm-certs titkoshoz való csatlakoztatásához szükséges tanúsítványokat (használja a jelzőt--experimental-upload-certs). - Megjelent egy alfa verzió a Windows telepítésekhez gMSA (Group Managed Service Account) – speciális fiókok az Active Directoryban, amelyeket tárolók is használhatnak.
- A G.C.E. mTLS titkosítás 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, Docker 18.09 támogatás a kubeadm-ben, és a minimálisan támogatott Docker API verzió most 1.26.
PS
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com