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

Tegnap, december 9-én került sor A Kubernetes következő kiadása - 1.17. A blogunkhoz kialakult hagyomány szerint az új verzióban a legjelentősebb változásokról beszélünk.

Az anyag elkészítéséhez felhasznált információk a hivatalos közleményből származnak, Kubernetes fejlesztések nyomkövetési táblái, VÁLTOZTATÁS-1.17 és a kapcsolódó problémák, lehívási kérések és Kubernetes fejlesztési javaslatok (KEP). Szóval mi újság?..

Topológia-tudatos útválasztás

A Kubernetes közösség már régóta vár erre a funkcióra - Topológia-tudatos szolgáltatás-útválasztás... Ha SAPKA 2018 októberéből származik, és a hivatalos fokozás — 2 évvel ezelőtt a szokásos kérdések (mint azt) - és még néhány évvel idősebb...

Az általános elképzelés az, hogy a Kubernetesben található szolgáltatások „helyi” útválasztásának megvalósítását biztosítsák. A „helység” ebben az esetben „ugyanolyan topológiai szintet” jelent. (topológia szint), ami lehet:

a szolgáltatásokhoz azonos csomópont,
ugyanaz a szerver rack,
ugyanaz a régió
ugyanaz a felhőszolgáltató,
...

Példák a funkció használatára:

forgalom megtakarítása több rendelkezésre állási zónával (multi-AZ) rendelkező felhőtelepítéseknél – lásd. friss illusztráció az azonos régióból származó forgalom példájával, de az AWS-ben különböző AZ-okkal;
alacsonyabb teljesítmény késleltetés/jobb áteresztőképesség;
egy megosztott szolgáltatás, amely minden egyes shardban helyi információkat tartalmaz a csomópontról;
a fluentd (vagy analógok) elhelyezése ugyanazon a csomóponton azokkal az alkalmazásokkal, amelyek naplóit gyűjtik;
...

Az ilyen útválasztást, amely „tud” a topológiáról, hálózati affinitásnak is nevezik - analógiája szerint csomópont-affinitás, pod affinitás/antiaffinitás vagy megjelent nem olyan régen Topológia-tudatos kötetütemezés (és Kötetkiosztás). A megvalósítás jelenlegi szintje ServiceTopology Kubernetesben - alfa verzió.

A funkció működésével és használatának módjával kapcsolatos részletekért olvassa el ezt a cikket az egyik szerzőtől.

IPv4/IPv6 kettős verem támogatás

Jelentős előrelépés rögzített egy másik hálózati szolgáltatásban: két IP-verem egyidejű támogatása, amelyet először ben vezettek be K8s 1.16. Az új kiadás különösen a következő változásokat hozta magával:

kube-proxyban végrehajtva egyidejű működés lehetősége mindkét módban (IPv4 és IPv6);
в Pod.Status.PodIPs megjelent a lefelé irányuló API támogatása (ugyanakkor /etc/hosts most megkövetelik a gazdagéptől egy IPv6-cím hozzáadását);
kettős verem támogatás KEDVES (Kubernetes IN Docker) és kubeadm;
frissített e2e tesztek.

ábra kettős verem IPV4/IPv6 használatával

Haladás a CSI-n

Stabilnak nyilvánították topológia támogatás CSI-alapú tároláshoz, először bevezetve K8s 1.12.

Kezdeményezés a kötet-bővítmények migrációja CSI-re - CSI migráció - elérte a béta verziót. Ez a funkció kritikus fontosságú a meglévő tárolóbővítmények lefordításához (fában) egy modern felületre (CSI, fán kívüli) láthatatlan a Kubernetes végfelhasználók számára. A fürt adminisztrátorainak csak engedélyezniük kell a CSI-áttelepítést, ami után a meglévő állapotalapú erőforrások és munkaterhelések továbbra is „csak működnek”... de a Kubernetes magban lévő elavultok helyett a legújabb CSI-illesztőprogramokat használják.

Jelenleg az AWS EBS illesztőprogramok migrációja készen áll a béta verzióban (kubernetes.io/aws-ebs) és GCE PD (kubernetes.io/gce-pd). Az egyéb tárolóhelyekre vonatkozó előrejelzések a következők:

Beszélgettünk arról, hogy a K8s „hagyományos” tárolási támogatása hogyan került a CSI-be ezt a cikket. És a CSI-migráció béta állapotba való átállása a cél külön kiadvány a projekt blogján.

Ezenkívül a CSI kontextusában egy másik jelentős funkció, amely a K1.17s 8-ből származik (alfa implementáció), a Kubernetes 1.12 kiadásban elérte a béta állapotot (azaz alapértelmezés szerint engedélyezve van) pillanatképek készítése és gyógyulást belőlük. A Kubernetes Volume Snapshotban a bétaverzió megjelenése során végrehajtott módosítások között szerepel:

a CSI külső pillanatfelvételi oldalkocsi két vezérlőre osztása,
hozzáadva a törléshez szükséges titkot (titkos törlés) megjegyzésként egy kötet pillanatfelvétel tartalmához,
új véglegesítő (véglegesítő) hogy megakadályozza a pillanatkép API objektum törlését, ha vannak még kapcsolatok.

Az 1.17-es kiadás idején a funkciót három CSI-illesztőprogram támogatja: GCE Persistent Disk CSI Driver, Portworx CSI Driver és NetApp Trident CSI Driver. A megvalósításról és használatáról bővebben itt olvashat ez a kiadvány a blogon.

Felhőszolgáltató címkéi

Automatikusan felcímkézi hozzárendelve a létrehozott csomópontokhoz és kötetekhez a használt felhőszolgáltatótól függően, már nagyon régóta elérhetőek Kubernetesben béta verzióként - a K8s 1.2 megjelenése óta (2016. április!). Tekintettel arra, hogy olyan régóta széles körben használták őket, a fejlesztők határozott, hogy itt az ideje stabilnak (GA) nyilvánítani.

Ezért mindegyiket ennek megfelelően (topológia szerint) nevezték át:

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 a régi nevükön (a visszafelé kompatibilitás érdekében). Javasoljuk azonban, hogy minden rendszergazdának váltson az aktuális címkékre. Kapcsolódó dokumentáció A K8s frissítve lett.

A kubeadm strukturált kimenete

Alfa verzióban mutatták be először strukturált kimenet a kubeadm segédprogramhoz. Támogatott formátumok: JSON, YAML, Go sablon.

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

Míg a Kubernetes manuálisan is telepíthető, a művelet de facto (ha nem de jure) szabványa a kubeadm használata. A népszerű rendszerkezelő eszközök, például a Terraform a kubeadm-re támaszkodnak a Kubernetes telepítéséhez. A Cluster API tervezett fejlesztései közé tartozik egy összeállítható csomag a Kubernetes rendszerindításhoz kubeadm és cloud-init segítségével.

Strukturált kimenet nélkül az első pillantásra a legártalmatlanabb változtatások is összetörhetik a Terraformot, a Cluster API-t és más olyan szoftvereket, amelyek a kubeadm eredményeit használják.

Közvetlen terveink között szerepel a következő kubeadm parancsok támogatása (strukturált kimenet formájában):

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

Parancsra adott JSON-válasz 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": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Egyéb innovációk stabilizálása

Általában a Kubernetes 1.17 kiadása a következő mottóval zajlottstabilitás" Ezt megkönnyítette az a tény, hogy sok funkció van benne (az összesített számuk 14) GA állapotot kapott. Közöttük:

csomópontok „jelölése” bizonyos feltételeknek megfelelően (TaintNodesByCondition), megjelent K8s 1.8;
Nézd meg a Könyvjelzőket - új típusú események, amelyek címkével rendelkeznek, hogy minden objektum egy bizonyos verzióig (resourceVersion) már feldolgozta őket az óra;
alapértelmezett értékek (alapértelmezett) az egyéni erőforrásokhoz;
konténerek között megosztva a pod folyamat névtereiben;
ScheduleDaemonSetPods - ütemezése a DaemonSetben kube-scheduler használatával (a DaemonSet vezérlő helyett);
dinamikus korlátok a kötetek számáról a csomópont típusától függően;
környezeti változó támogatás a következőként csatolt könyvtárnevekhez subPath;
Kubelet szívverések átvitele speciális Lease API-hoz;
"véglegesítő védelem" (Véglegesítő védelem) a terheléselosztókhoz (a megfelelő szolgáltatási erőforrások ellenőrzése a LoadBalancer erőforrások törlése előtt);
kube-apiserver optimalizálás teljesítményben, ha több órával dolgozunk, azonos objektumkészleteket figyelünk meg – ez úgy érhető el, hogy elkerüljük ugyanazon objektumok ismételt sorozatosítását minden egyes megfigyelőnél.

Egyéb változások

A Kubernetes 1.17 innovációinak teljes listája természetesen nem korlátozódik a fent felsoroltakra. Íme néhány másik (és a teljesebb listát lásd VÁLTOZÁSI NAPLÓ):

A legutóbbi kiadásban bemutatott funkció elérte a béta verziót RunAsUserName ablakokhoz;
hasonló változás történt EndpointSlice API (szintén a K8s 1.16-ból), azonban jelenleg ez a megoldás az Endpoint API teljesítményének/skálázhatóságának javítására alapértelmezés szerint nincs engedélyezve;
A podok most kritikusak a fürt működéséhez létre lehet hozni nem csak a névterekben kube-system (a részletekért lásd a dokumentációt Korlátozza a Priority Class fogyasztást);
új lehetőség a kubelethez - --reserved-cpus — lehetővé teszi a rendszer számára fenntartott CPU-k listájának explicit meghatározását;
a kubectl logs bemutatott új zászló --prefix, hozzáadva a pod és a forrástároló nevét a napló minden sorához;
в label.Selector - tette hozzá RequiresExactMatch;
minden konténer a kube-dns-ben most futnak kevesebb előjoggal;
hyperkube külön GitHub-tárolóba különül el, és a továbbiakban nem szerepel a Kubernetes-kiadásokban;
sok jobb teljesítmény kube-proxy nem UDP portokhoz.

Függőségi változások:

A kubeadmben található CoreDNS verzió 1.6.5;
crictl verzió 1.16.1-re frissítve;
CSI 1.2.0;
etcd 3.4.3;
A legutóbbi tesztelt Docker verzió 19.03-ra frissítve;
A Kubernetes 1.17 elkészítéséhez szükséges minimális Go verzió az 1.13.4.

PS

Olvassa el blogunkon is:

Forrás: will.com

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