🥇Kubernetes 1.17: a fő újítások bemutatása

Tegnap, december 9-én, megtörtént megjelenésre került a Kubernetes 1.17. A hagyományokhoz híven, most is beszámolunk a legfontosabb változásokról az új verzióban.

Kubernetes 1.17: A főbb újdonságok áttekintése

Az ennek a anyagnak az elkészítéséhez használt információk a hivatalos bejelentésből származnak, Kubernetes enhancements tracking táblázat, CHANGELOG-1.17 valamint a megfelelő issues, pull requestek és a Kubernetes Enhancement Proposals (KEP) összegyűjtéséből. Szóval, mi újság?..

Topológia-tudatos útvonaltervezés

A Kubernetes közösség már régóta várta ezt a funkciót — Topology-aware service routing. Ha KEP amely 2018 októberében kezdődött, és a hivatalos enhancement — 2 évvel ezelőtt, míg a szokásos issue-k (mint például ez) — még ennél is több éves…

Az alapötlet az, hogy lehetővé tegyük a »helyi« útvonaltervezést a Kubernetesben működő szolgáltatások számára. A »helyi« kifejezés ebben az esetben azt jelenti, hogy »ugyanazon a topológiai szinten« (topology level), amely lehet:

ugyanazon a noden lévő szolgáltatások,
ugyanazon a szerver rack-en,
ugyanazon a régión,
ugyanazon a felhőszolgáltatónál.
…

A funkció használatának példái:

költségmegtakarítás a sok elérhetőségi zónával (multi-AZ) rendelkező felhős telepítésekben — lásd. a friss ábrát egy régió forgalmának példáján, de különböző AZ-ekben az AWS-ben;
csökkentett késleltetés a teljesítményben/javított sávszélesség;
shardolt szolgáltatás, amely helyi információt tartalmaz a nodéről minden shardban;
a fluentd (vagy hasonlók) elhelyezése egy node-ra az alkalmazásokkal, melyek logjait gyűjtik;
…

Ezt a topológia-tudatos útvonaltervezést még a network affinity-hez hasonlítják — hasonlóan a node affinity, pod affinity/anti-affinity vagy a nemrég megjelenő Topology-Aware Volume Scheduling Volume Provisioning (és ). A jelenlegi implementációs szintServiceTopology a Kubernetesben — alfa verzió. A funkcióról és arról, hogyan használható már, olvasson el egy cikket

az egyik szerzőtől. cikkben Kettős IPv4/IPv6 hibaállás-támogatás

Jelentős előrelépések

történtek egy másik hálózati funkciónál: a két IP-stack egyidejű támogatásánál, ami először a K8s 1.16-ban került bemutatásra. Különösen az új kiadás a következő változásokat hozta:Kube-proxy-ban

a két üzemmódban (IPv4 és IPv6) való egyidejű működés lehetősége; megvalósítva Pod.Status.PodIPs
be. támogatja a downward API-t (eközben a megjelenik mostantól megköveteli, hogy a hoszt IPv6 címet is adjon hozzá); /etc/hosts két stack támogatása a
KIND (Kubernetes IN Docker) és frissített e2e tesztek. kubeadm;
Ábra

Kubernetes 1.17: A főbb újdonságok áttekintése
Ábra az IPV4/IPv6 dupla verem használata KIND

CSI előrehaladás

Stabilnak nyilvánítva topológiák támogatása CSI-alapú tárolók számára, először bemutatva a K8s 1.12-ben.

kezdeményezés a tárolópluginek CSI-re történő migrációjára — CSI Migráció — elérte a béta verziót. Ez a funkció kulcsfontosságú a meglévő tárolópluginek migrálásához (in-tree) a modern interfészre (CSI, out-of-tree) észrevétlenül a Kubernetes végfelhasználói számára. A klaszteradminisztrátoroknak elegendő aktiválni a CSI migrációt, ezután a meglévő állapot-alapú erőforrások és munka terhelések továbbra is "egyszerűen működnek"… de már a legfrissebb CSI-meghajtókkal, a Kubernetes magjába épített elavultak helyett.

Jelenleg béta státuszban van a migráció az AWS EBS meghajtók számára (kubernetes.io/aws-ebs) és a GCE PD (kubernetes.io/gce-pd). A többi tárolóval kapcsolatos előrejelzések a következőképpen alakulnak:

Kubernetes 1.17: A főbb újdonságok áttekintése

Arról, hogyan jutott el a "hagyományos" tárolótámogatás a K8s-ben a CSI-hoz, már beszélgettünk a cikkben. A CSI migráció béta státuszba való átmenetéről szóló külön cikk a projekt blogjában.

Ezenkívül a Kubernetes 1.17-es kiadásában egy másik jelentős funkció, amely a CSI kontextusában több mint egy évvel korábban (alfaverzió) K8s 1.12-ben kezdődött, elérte a béta státuszt — snapshotok készítése és azokból való helyreállítás.A Kubernetes Volume Snapshot béta kiadásának előkészítése során végrehajtott változások között szerepel:

a CSI external-snapshotter oldalsó vezérlőjének kettéosztása két vezérlőre,
törlési titok hozzáadása (deletion secret) a volume snapshot tartalmának annotációjaként,
új véglegesítő (finalizer) a snapshot API-objektum törlésének megakadályozására a fennmaradó referenciák esetén.

A 1.17-es kiadás időpontjában a funkciót három CSI-meghajtó támogatja: GCE Persistent Disk CSI Driver, Portworx CSI Driver és NetApp Trident CSI Driver. A megvalósításáról és használatáról bővebben olvashatsz a cikkünkben a blogon.

Felhőszolgáltató címkék

Címkék, amelyeket automatikusan rendelnek a létrehozott nódokhoz és volume-okhoz, a használt felhőszolgáltató alapján, már nagyon régóta elérhetőek Kubernetes-ként béta verzióban — a K8s 1.2-es kiadása óta (2016 áprilisától!). Tekintettel arra, hogy ennyire régóta széles körben használják őket, a fejlesztők úgy döntöttek, hogy itt az idő, hogy a funkciót stabilnak (GA) nyilvánítsák.

Ezért mindegyiket a megfelelő módon (a topológiák szerint) átnevezték:

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io\/zone
failure-domain.beta.kubernetes.io\/region → topology.kubernetes.io\/region

… de továbbra is elérhetők régi nevükön (visszamenőleges kompatibilitás céljából). Mindazonáltal minden adminisztrátornak ajánlott az aktuális címkék használatára váltani. A megfelelő dokumentáció A K8s frissítve lett.

A kubeadm strukturált kimenete

Alpha verzió formátumban debütált a kubeadm eszközhöz készült strukturált kimenet. Támogatott formátumok: JSON, YAML, Go sablon.

A funkció megvalósításának motivációja (szerint KEP) a következő:

Bár a Kubernetes manuálisan is telepíthető, de a szabványos eljárás (de facto, ha nem de jure) a kubeadm használata. Az olyan népszerű rendszerkezelő eszközök, mint a Terraform, a kubeadm-ra támaszkodnak a Kubernetes telepítéséhez. A Cluster API jövőbeli fejlesztései között szerepel egy összeállítható csomag a Kubernetes kubeadm és cloud-init segítségével történő bootstrapping-jához.
A strukturált kimenet hiányában még a legártalmatlanabbnak tűnő változtatások is elronthatják a Terraformot, a Cluster API-t és más szoftvereket, amelyek a kubeadm által biztosított eredményeket használják.

A közeljövőben a kubeadm következő parancsaihoz fog támogatást nyújtani (strukturált kimenet formájában):

alpha certs
config images list
init
token create
token list
upgrade plan
version

A kubeadm init -o json parancs JSON válaszának illusztrációja kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "A 'kubeadm init' által generált alapértelmezett bootstrap token.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

A többi új funkció stabilizálása

Általában a Kubernetes 1.17-es kiadására az a szlogen volt, hogy „Stabilitás”. Ennek oka, hogy nagyon sok funkció benne (a számuk összesen - 14) GA státuszt kapott. Az ilyenek között szerepel:

A csomók „címkézése” bizonyos feltételek szerint (TaintNodesByCondition), mely a K8s 1.8-ban jelent meg. Watch Bookmarks;
— egy új eseménytípus, amely címkézi, hogy minden objektum egy adott verzióig ( resourceVersion) már feldolgozásra került a watch által;alapértelmezett értékek
(defaulting) a Custom Resources számára; megosztott a konténerek között
a pod-ban lévő process namespaces; ScheduleDaemonSetPods
a pod-ok ütemezése DaemonSet-ben — a kube-scheduler segítségével (a DaemonSet vezérlő helyett); dinamikus korlátok
a csomópont típusa szerint változó mennyiségű kötetre; a kötetek számától az adott csomópont típusa szerint;
környezeti változók támogatása könyvtárnevekhez, amelyek úgy vannak csatolva, mint subPath;
Kubelet szívverések átvitele a specializált Lease API-n keresztül;
az "finalizáló védelem" (Finalizer Protection) a terheléselosztók számára (a LoadBalancer erőforrások törlése előtt a Service megfelelő erőforrásainak ellenőrzése);
a kube-apiserver teljesítményének optimalizálása sok watch esetén, amelyek az azonos objektumkészleteket figyelik — mindezt elkerülve az átírást ugyanazon objektumok esetében minden egyes watcher számára.

nem tekinthetők

A Kubernetes 1.17 teljes újításlistája természetesen nem korlátozódik a fent említettekre. Íme néhány másik (a teljesebb lista érdekében lásd: CHANGELOG):

a bétaverzióra "növekedett" a múltkori kiadásban bemutatott funkció RunAsUserName Windows számára;
hasonló változás elérte EndpointSlice API (szintén a K8s 1.16-ból), azonban ez a megoldás a teljesítmény/méretarányosság javítására az Endpoint API esetében alapértelmezettként még nem aktív;
a klaszter működéséhez kritikus pod-ok most már létrehozhatók nemcsak a névtérben kube-system (további részletek a dokumentációban találhatók a Limit Priority Class consumption);
új opció a kubelet számára — --reserved-cpus — lehetővé teszi, hogy kifejezetten meghatározza a rendszer számára fenntartott CPU-k listáját;
a A kubectl logs bemutatva új zászló --prefix, amely hozzáadja a pod és a forrástömb neveit minden naplóbejegyzéshez;
be. label.Selector csapathoz hozzáadtuk RequiresExactMatch;
minden konténer a kube-dns-ben mostantól alacsonyabb jogosultságokkal indul; hyperkube
külön GitHub-repozitóriumba került, és többé nem fog szerepelni a Kubernetes kiadásokban; javították a teljesítményt
jelentősen a kube-proxy számára nem-UDP portokon. A függőségekben történt változások:

a kubeadm részeként a CoreDNS verziója — 1.6.5;

a crictl verziója frissítve lett v1.16.1-re;
CSI 1.2.0;
etcd 3.4.3;
a legutolsó tesztelt Docker verziót 19.03-ra emelték;
a Kubernetes 1.17 buildeléséhez szükséges minimális Go verzió — 1.13.4.
Kubernetes 1.15: a fontos újítások áttekintése

P.S.

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

Forrás: habr.com