🥇Kubernetes 1.17: përmbledhje e inovacioneve kryesore

Dje, më 9 dhjetor, Ndodhi Versioni më i fundit i Kubernetes është 1.17. Sipas traditës sonë në blog, po nxjerrim në pah ndryshimet më të rëndësishme në versionin e ri.

Kubernetes 1.17: përmbledhje e inovacioneve kryesore

Informacioni i përdorur për përgatitjen e këtij materiali është marrë nga njoftimi zyrtar, Tabelat e gjurmimit të përmirësimeve të Kubernetes, NDRYSHIMI-1.17 dhe problemet përkatëse, kërkesat për tërheqje dhe Propozimet për Përmirësimin e Kubernetes (KEP). Pra, çfarë ka të re?

Rrugëzim i vetëdijshëm për topologjinë

Komuniteti Kubernetes ka kohë që e ka pritur këtë veçori - Rrugëzimi i shërbimit i vetëdijshëm për topologjinë. nëse CEP filloi në tetor 2018, dhe zyrtari përmirësim — 2 vjet më parë, atëherë problemet e zakonshme (si ajo) — dhe madje edhe më i vjetër me disa vite...

Ideja e përgjithshme është të ofrohet mundësia për të zbatuar rrugëzimin "lokal" për shërbimet e vendosura në Kubernetes. "Lokal" në këtë rast do të thotë "i njëjti nivel topologjik". (niveli i topologjisë), të cilat mund të jenë:

e njëjta nyje për shërbimet,
i njëjti raft serverash,
të njëjtin rajon,
i njëjti ofrues i cloud-it,
...

Shembuj të përdorimit të kësaj veçorie:

Kursimi i trafikut në instalimet cloud me zona të shumëfishta disponueshmërie (shumë-AZ) - shih ilustrim i freskët duke përdorur shembullin e trafikut nga një rajon, por AZ të ndryshme në AWS;
vonesë më e ulët e performancës/prodhueshmëri më e mirë;
një shërbim i copëzuar që ka informacion lokal rreth nyjes në secilën copë;
vendosja e fluentd (ose të ngjashme) në të njëjtin nyje si aplikacionet të cilave u mblodhën regjistrat;
...

Ky lloj rrugëzimi, "i vetëdijshëm" për topologjinë, quhet gjithashtu një lloj afiniteti rrjeti - për analogji me afiniteti i nyjeve, afinitet/anti-afinitet për pod-in ose u shfaq jo shumë kohë më parë Planifikimi i Vëllimit i Ndërgjegjshëm për Topologjinë (dhe Furnizimi i vëllimitNiveli aktual i zbatimit ServiceTopology në Kubernetes - versioni alfa.

Për më shumë detaje se si funksionon kjo veçori dhe si mund ta përdorni tashmë, lexoni Ky artikull nga njëri prej autorëve.

Mbështetje e dyfishtë IPv4/IPv6

Përparim i rëndësishëm i regjistruar në një tjetër veçori të rrjetëzimit: mbështetje e njëkohshme për dy pirgje IP, e cila u prezantua për herë të parë në K8s 1.16Në veçanti, versioni i ri sjell ndryshimet e mëposhtme:

në kube-proxy zbatuar aftësia për të vepruar njëkohësisht në të dy mënyrat (IPv4 dhe IPv6);
в Pod.Status.PodIPs u shfaq mbështetje për API-në në rënie (në të njëjtën kohë në /etc/hosts tani ata kërkojnë shtimin e një adrese IPv6 për hostin);
mbështetje me dy shtresa LLOJ (Kubernetes IN Docker) dhe kubeadm;
testet e përditësuara të e2e.

Kubernetes 1.17: përmbledhje e inovacioneve kryesore
ilustrim Përdorimi i Dual Stack IPV4/IPv6 në KIND

Progresi në CSI

I shpallur i qëndrueshëm mbështetje topologjie për ruajtjen e bazuar në CSI, prezantuar për herë të parë në K8s 1.12.

Iniciativa për migrimi i shtojcave të vëllimit në CSI - Migrimi i CSI-së — ka arritur versionin beta. Kjo veçori është kritike për migrimin e shtojcave ekzistuese të ruajtjes së të dhënave. (brenda pemës) në një ndërfaqe moderne (CSI, jashtë pemës) Pa probleme për përdoruesit fundorë të Kubernetes. Administratorët e klusterit do të duhet vetëm të aktivizojnë CSI Migration, pas së cilës burimet ekzistuese me gjendje dhe ngarkesat e punës do të vazhdojnë të "funksionojnë thjesht"... por duke përdorur drajverët më të fundit CSI në vend të atyre të trashëguar të përfshirë në bërthamën e Kubernetes.

Aktualisht, migrimi për drajverët AWS EBS është gati në statusin beta (kubernetes.io/aws-ebs) dhe GCE PD (kubernetes.io/gce-pdParashikimet për objektet e tjera të magazinimit janë si më poshtë:

Kubernetes 1.17: përmbledhje e inovacioneve kryesore

Ne folëm rreth asaj se si mbështetja "tradicionale" e ruajtjes së të dhënave në K8 erdhi në CSI në vitin Ky artikullDhe kalimi i migrimit CSI në statusin e versionit beta është i dedikuar botim i veçantë në blogun e projektit.

Përveç kësaj, një tjetër veçori e rëndësishme në kontekstin e CSI, e cila filloi (në zbatimin alfa) në K8s 1.12, ka arritur statusin beta (domethënë të aktivizuar si parazgjedhje) në versionin Kubernetes 1.17: krijimi i pamjeve të çastit dhe rimëkëmbja prej tyreNdër ndryshimet e bëra në Kubernetes Volume Snapshot në rrugën drejt lëshimit beta:

duke ndarë karrocën anësore të aparatit fotografik të jashtëm CSI në dy kontrollues,
shtoi një sekret për fshirje (sekret fshirjeje) si një shënim për përmbajtjen e një pamjeje të vëllimit,
finalizues i ri (finalizues) për të parandaluar fshirjen e objektit të snapshot API nëse ka lidhje të mbetura.

Që nga versioni 1.17, kjo veçori mbështetet nga tre drajverë CSI: Drajveri CSI i Diskut të Përhershëm GCE, Drajveri CSI i Portworx dhe Drajveri CSI i NetApp Trident. Më shumë detaje mbi zbatimin dhe përdorimin e tij mund të gjenden në këtë botim në blog.

Etiketat e ofruesit të reve kompjuterike

Etiketa që automatikisht i caktuar nyjeve dhe vëllimeve të krijuara në varësi të ofruesit të cloud-it të përdorur, kanë qenë të disponueshme në Kubernetes si një version beta për një kohë shumë të gjatë - që nga publikimi i K8s 1.2 (Prill 2016!)Duke pasur parasysh përdorimin e tyre të gjerë për kaq gjatë, zhvilluesit vendosi, se është koha për të deklaruar karakteristikën të qëndrueshme (GA).

Prandaj, të gjitha u riemëruan në përputhje me rrethanat (sipas topologjive):

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

...por janë ende të disponueshme nën emrat e tyre të vjetër (për pajtueshmëri të prapambetur). Megjithatë, të gjithë administratorëve u këshillohet të kalojnë në etiketat aktuale. Dokumentacioni përkatës K8s është përditësuar.

Prodhim i strukturuar nga kubeadm

Prezantohet për herë të parë në versionin alfa dalje e strukturuar për shërbimin kubeadmFormatet e mbështetura: JSON, YAML, shablloni Go.

Motivimi për zbatimin e kësaj veçorie (sipas CEP) është si më poshtë:

Ndërsa Kubernetes mund të vendoset manualisht, standardi de facto (nëse jo de jure) për këtë operacion është përdorimi i kubeadm. Mjetet e njohura të menaxhimit të sistemeve si Terraform mbështeten në kubeadm për vendosjen e Kubernetes. Përmirësimet e planifikuara në Cluster API përfshijnë një paketë të kompozueshme për bootstrapping të Kubernetes me kubeadm dhe cloud-init.
Pa një dalje të strukturuar, edhe ndryshimet më në dukje të padëmshme mund të prishin Terraform, Cluster API dhe softuerë të tjerë që përdorin daljen kubeadm.

Planet tona të menjëhershme përfshijnë mbështetje (në formën e rezultateve të strukturuara) për komandat e mëposhtme kubeadm:

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

Ilustrim i një përgjigjeje JSON ndaj një komande 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="
}

Stabilizimi i inovacioneve të tjera

Në përgjithësi, lëshimi i Kubernetes 1.17 u zhvillua nën moton "stabilitet" Kjo u lehtësua nga fakti se ka shumë karakteristika (numri i tyre i përgjithshëm është 14) mori statusin e GA. Ndër këto:

"shënimi" i nyjeve sipas kushteve të caktuara (TaintNodesByCondition), i cili u shfaq në K8s 1.8;
Faqeshënuesit e orës - një lloj i ri ngjarjesh që kanë një etiketë që i tregon të gjitha objektet deri në një version të caktuar (resourceVersion) janë përpunuar tashmë nga watch;
vlerat e parazgjedhura (parazgjedhur) për Burimet e Personalizuara;
ndarë midis kontejnerëve në hapësirat e emrave të proceseve pod;
ScheduleDaemonSetPods - planifikimi i pod-eve në DaemonSet duke përdorur kube-scheduler (në vend të kontrolluesit DaemonSet);
kufijtë dinamikë nga numri i vëllimeve në varësi të llojit të nyjes;
mbështetje për variablat e mjedisit për emrat e direktorive të montuara si subPath;
Transferimi i Rrahjeve të Zemrës Kubelet në një API të specializuar të Lease;
"mbrojtje e finalizuesit" (Mbrojtja e Finalizerit) për balancuesit e ngarkesës (duke kontrolluar burimet përkatëse të Shërbimit përpara se të fshihen burimet e LoadBalancer);
optimizimi i serverit kube-apiserver në performancë kur punohet me orë të shumta që vëzhgojnë grupe identike objektesh - arrihet duke shmangur ri-serializimin e të njëjtave objekte për secilin vëzhgues.

Ndryshime të tjera

Lista e plotë e veçorive të reja në Kubernetes 1.17, sigurisht, nuk kufizohet vetëm në ato të listuara më sipër. Ja disa të tjera (dhe për një listë më të plotë, shih changelog):

Funksioni i prezantuar në versionin e mëparshëm ka arritur në versionin beta RunAsUserName për Windows;
ndryshim i ngjashëm ndodhi EndpointSlice API (gjithashtu nga K8s 1.16), megjithatë, kjo zgjidhje për përmirësimin e performancës/shkallëzueshmërisë së Endpoint API nuk është aktivizuar ende si parazgjedhje;
pod-et që janë kritike për funksionimin e klasterit tani janë mund të krijohet jo vetëm në hapësirat e emrave kube-system (për detaje shihni dokumentacionin në Kufizoni konsumin e klasës me përparësi);
opsion i ri për kubelet — --reserved-cpus — ju lejon të përcaktoni në mënyrë të qartë listën e CPU-ve të rezervuara për sistemin;
për kubectl logs prezantuar flamur i ri --prefix, i cili shton emrin e pod-it dhe kontejnerin e burimit në çdo rresht regjistri;
в label.Selector shtuar RequiresExactMatch;
të gjithë kontejnerët në kube-dns tani po fillojnë me më pak privilegje;
hiperkube është ndarë në një depo të veçantë GitHub dhe nuk do të përfshihet më në lëshimet e Kubernetes;
shumë performanca u përmirësua kube-proxy për porta jo-UDP.

Ndryshimet në varësi:

Versioni CoreDNS i përfshirë në kubeadm është 1.6.5;
versioni crictl u përditësua në v1.16.1;
CSI 1.2.0;
etj. 3.4.3;
Versioni më i fundit i testuar i Docker është përditësuar në 19.03;
Versioni minimal i Go i kërkuar për të ndërtuar Kubernetes 1.17 është 1.13.4.

PS

Lexoni edhe në blogun tonë:

Burimi: www.habr.com