🥇Kubernetes 1.17: përmbledhje e inovacioneve kryesore

Dje, më 9 dhjetor, Ndodhi lëshimi tjetër i Kubernetes - 1.17. Sipas traditës që është zhvilluar për blogun tonë, flasim për ndryshimet më domethënëse në versionin e ri.

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 çështje të ndërlidhura, kërkesat për tërheqje dhe Propozimet e Përmirësimit të Kubernetes (KEP). Pra, çfarë ka të re?..

Drejtimi i ndërgjegjshëm për topologjinë

Komuniteti Kubernetes e ka pritur këtë veçori për një kohë të gjatë - Drejtimi i shërbimit të vetëdijshëm për topologjinë. nëse CEP e ka origjinën në tetor 2018, dhe zyrtari përmirësim - 2 vjet më parë, çështjet e zakonshme (si ajo) - dhe disa vite më e madhe ...

Ideja e përgjithshme është të ofrohet aftësia për të zbatuar rrugëzimin "lokal" për shërbimet që banojnë në Kubernetes. "Lokalitet" në këtë rast do të thotë "i njëjti nivel topologjik" (niveli i topologjisë), e cila mund të jetë:

nyje identike për shërbimet,
i njëjti raft serveri,
të njëjtin rajon
i njëjti ofrues i reve kompjuterike,
...

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

kursimet në trafik në instalimet cloud me zona të shumta disponueshmërie (multi-AZ) - shih. ilustrim i freskët duke përdorur shembullin e trafikut nga i njëjti rajon, por AZ të ndryshme në AWS;
vonesë e performancës më të ulët / xhiros më të mirë;
një shërbim i ndarë që ka informacion lokal për nyjen në çdo copëz;
vendosja e fluentd (ose analoge) në të njëjtën nyje me aplikacionet, regjistrat e të cilëve janë mbledhur;
...

Një rrugëtim i tillë, i cili "di" për topologjinë, quhet gjithashtu afiniteti i rrjetit - për analogji me afiniteti i nyjeve, afinitet/antiafinitet pod ose u shfaq jo shumë kohë më parë Planifikimi i vëllimit të vetëdijshëm për topologjinë (dhe Sigurimi i vëllimit). Niveli aktual i zbatimit ServiceTopology në Kubernetes - version alfa.

Për detaje se si funksionon funksioni dhe si mund ta përdorni tashmë, lexoni Ky artikull nga një prej autorëve.

Mbështetje e dyfishtë IPv4/IPv6

Progres i rëndësishëm fikse në një veçori tjetër të rrjetit: mbështetje e njëkohshme për dy rafte IP, e cila u prezantua për herë të parë në K8s 1.16. Në veçanti, versioni i ri solli ndryshimet e mëposhtme:

në kube-proxy zbatuar mundësia e funksionimit të njëkohshëm në të dy mënyrat (IPv4 dhe IPv6);
в Pod.Status.PodIPs u shfaq mbështetje për API në rënie (në të njëjtën kohë si në /etc/hosts tani ata kërkojnë që hosti të shtojë një adresë IPv6);
mbështetje për pirg të dyfishtë LLOJ (Kubernetes IN Docker) dhe kubeadm;
teste të përditësuara e2e.

ilustrim duke përdorur dual stack IPV4/IPv6 në KIND

Progresi në CSI

Shpallur e qëndrueshme mbështetje topologjie për ruajtjen e bazuar në CSI, e prezantuar për herë të parë në K8s 1.12.

Iniciativa për migrimi i shtojcave të vëllimit në CSI - Migrimi CSI - Arriti versionin beta. Kjo veçori është kritike për të përkthyer shtojcat ekzistuese të ruajtjes (në pemë) në një ndërfaqe moderne (CSI, jashtë pemës) e padukshme për përdoruesit fundorë të Kubernetes. Administratorët e grupeve do të duhet vetëm të aktivizojnë Migracionin CSI, pas së cilës burimet ekzistuese shtetërore dhe ngarkesat e punës do të vazhdojnë "vetëm të funksionojnë"... por duke përdorur drejtuesit më të fundit CSI në vend të atyre të vjetëruar të përfshirë në bërthamën e Kubernetes.

Për momentin, migrimi për drejtuesit AWS EBS është gati në versionin beta (kubernetes.io/aws-ebs) dhe GCE PD (kubernetes.io/gce-pd). Parashikimet për objektet e tjera të magazinimit janë si më poshtë:

Ne folëm se si mbështetja "tradicionale" e ruajtjes në K8 erdhi në CSI Ky artikull. Dhe kalimi i migrimit të CSI në statusin beta i kushtohet botim i veçantë në blogun e projektit.

Për më tepër, një tjetër funksionalitet i rëndësishëm në kontekstin e CSI, i cili ka origjinën (zbatimi alfa) në K1.17s 8, arriti statusin beta (d.m.th. i aktivizuar si parazgjedhje) në versionin Kubernetes 1.12 - krijimi i fotove dhe shërim prej tyre. Ndër ndryshimet e bëra në Kubernetes Volume Snapshot në rrugën drejt lëshimit beta:

ndarjen e karriges anësore të fotografëve të jashtëm CSI në dy kontrollues,
sekret i shtuar për fshirje (sekret i fshirjes) si një shënim për përmbajtjen e një fotografie vëllimi,
finalizues i ri (finalizues) për të parandaluar fshirjen e objektit API të fotografisë nëse ka lidhje të mbetura.

Në kohën e lëshimit 1.17, veçoria mbështetet nga tre drejtues CSI: Drejtuesi i diskut i qëndrueshëm GCE CSI, Portworx CSI Driver dhe NetApp Trident CSI Driver. Më shumë detaje rreth zbatimit dhe përdorimit të tij mund të gjenden në këtë botim në blog.

Etiketat e ofruesve të resë kompjuterike

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

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

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 me emrat e tyre të vjetër (për pajtueshmërinë e pasme). Megjithatë, të gjithë administratorët rekomandohen të kalojnë në etiketat aktuale. Dokumentacioni përkatës K8s është përditësuar.

Prodhimi i strukturuar i kubeadm

Prezantohet në versionin alfa për herë të parë prodhim i strukturuar për mjetin kubeadm. Formatet e mbështetura: shabllon JSON, YAML, Go.

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

Ndërsa Kubernetes mund të vendoset manualisht, standardi de fakto (nëse jo de jure) për këtë operacion është përdorimi i kubeadm. Mjetet popullore të menaxhimit të sistemeve si Terraform mbështeten në kubeadm për vendosjen e Kubernetes. Përmirësimet e planifikuara për API-në e Cluster përfshijnë një paketë të kompozueshme për bootstrapping Kubernetes me kubeadm dhe cloud-init.

Pa dalje të strukturuar, edhe ndryshimet më të padëmshme në shikim të parë mund të thyejnë Terraform, Cluster API dhe programe të tjera që përdorin rezultatet e kubeadm.

Planet tona të menjëhershme përfshijnë mbështetje (në formën e prodhimit të strukturuar) 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 risive 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 shumë veçori në të (numri i tyre i përgjithshëm është 14) mori statusin GA. Midis tyre:

"shënjimi" i nyjeve sipas kushteve të caktuara (TaintNodesByCondition), u shfaq në K8s 1.8;
Shiko faqeshënuesit - një lloj i ri i ngjarjeve që kanë një etiketë që të gjitha objektet janë deri në një version të caktuar (resourceVersion) janë përpunuar tashmë nga ora;
vlerat e paracaktuara (default) për Burimet e personalizuara;
ndahet midis kontejnerëve në hapësirat e emrave të procesit të pod;
ScheduleDaemonSetPods - planifikimi i grupeve në DaemonSet duke përdorur kube-scheduler (në vend të kontrolluesit DaemonSet);
kufijtë dinamikë në numrin e vëllimeve në varësi të llojit të nyjës;
mbështetje për variablat e mjedisit për emrat e drejtorive të montuara si subPath;
Transferimi i rrahjeve të zemrës Kubelet në një API të specializuar të qirasë;
"mbrojtja e finalizuesit" (Mbrojtja e finalizuesit) për balancuesit e ngarkesës (kontrollimi i burimeve përkatëse të Shërbimit përpara se të fshini burimet e LoadBalancer);
optimizimi i kube-apiserver në performancën kur punoni me orë të shumta monitorimi i grupeve identike të objekteve - arrihet duke shmangur serializimin e përsëritur të të njëjtave objekte për secilin vëzhgues.

Ndryshime të tjera

Lista e plotë e risive në Kubernetes 1.17, natyrisht, nuk kufizohet vetëm në ato të listuara më sipër. Këtu janë disa të tjera (dhe për një listë më të plotë, shihni changelog):

Veçoria e paraqitur në versionin e fundit ka arritur në versionin beta RunAsUserName për dritare;
ndryshim i ngjashëm ka ndodhur EndpointSlice API (gjithashtu nga K8s 1.16), megjithatë tani për tani kjo zgjidhje për të përmirësuar performancën/shkallëzueshmërinë e API-së Endpoint nuk është aktivizuar si parazgjedhje;
pods tani janë kritike për funksionimin e grupimeve mund të krijohen jo vetëm në hapësirat e emrave kube-system (për detaje, shihni dokumentacionin për Kufizoni konsumin e klasës prioritare);
opsion i ri për kubelet - --reserved-cpus — ju lejon të përcaktoni në mënyrë eksplicite listën e CPU-ve të rezervuara për sistemin;
për kubectl logs prezantuar flamur i ri --prefix, duke shtuar emrin e pod dhe kontejnerit burim në çdo rresht të regjistrit;
в label.Selector shtuar RequiresExactMatch;
të gjithë kontejnerët në kube-dns tani po vrapojnë me më pak privilegje;
hiperkube ndarë në një depo të veçantë GitHub dhe nuk do të përfshihet më në publikimet e Kubernetes;
shumë performanca e përmirësuar kube-proxy për portet jo-UDP.

Ndryshimet e varësisë:

Versioni CoreDNS i përfshirë në kubeadm është 1.6.5;
versioni crictl i përditësuar në v1.16.1;
CSI 1.2.0;
etjd 3.4.3;
Versioni i fundit i testuar i Docker i përmirësuar në 19.03;
Versioni minimal Go që kërkohet për të ndërtuar Kubernetes 1.17 është 1.13.4.

PS

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Kubernetes 1.17: përmbledhje e inovacioneve kryesore