Dje, mĂ« 9 dhjetor, u publikua versioni i radhĂ«s i Kubernetes â 1.17. Sipas traditĂ«s sĂ« krijuar nĂ« blogun tonĂ«, po ndajmĂ« ndryshimet mĂ« tĂ« rĂ«ndĂ«sishme tĂ« versionit tĂ« ri.

Informacioni i përdorur për përgatitjen e këtij materiali është marrë nga njoftimi zyrtar, , si dhe nga issues, pull requests përkatëse dhe Kubernetes Enhancement Proposals (KEP). Pra, çfarë ka të re?..
Routimi me vetëdije për topologjinë
Prej kohĂ«sh, komuniteti Kubernetes e priste kĂ«tĂ« veçori â Topology-aware service routing. NĂ«se e ka zanafillĂ«n nĂ« tetor 2018, ndĂ«rsa zyrtar u shfaq 2 vjet mĂ« parĂ«, kurse issues tĂ« zakonshme (si p.sh. ) â janĂ« edhe disa vite mĂ« tĂ« vjetraâŠ
Ideja kryesore Ă«shtĂ« tĂ« ofrohet mundĂ«sia pĂ«r tĂ« zbatuar routim âlokalâ pĂ«r shĂ«rbimet qĂ« ndodhen nĂ« Kubernetes. âLokalâ nĂ« kĂ«tĂ« rast do tĂ« thotĂ« âi njĂ«jti nivel topologjikâ (topology level), i cili mund tĂ« jetĂ«:
- e njëjta nyje për shërbimet,
- i njëjti rack serverësh,
- i njëjti rajon,
- i njëjti ofrues cloud,
- âŠ
Shembuj përdorimi për këtë veçori:
- kursim nĂ« trafikun e rrjetit nĂ« instalime cloud me shumĂ« zona disponueshmĂ«rie (multi-AZ) â shihni me shembullin e trafikut brenda tĂ« njĂ«jtit rajon, por mes AZ-ve tĂ« ndryshme nĂ« AWS;
- vonesa më të ulëta / throughput më i mirë;
- një shërbim i sharduar që ka informacion lokal për nyjen në çdo shard;
- vendosja e fluentd (ose alternativave të ngjashme) në një nyje me aplikacionet, log-et e të cilave mblidhen;
- âŠ
Ky lloj routimi, qĂ« âe njehâ topologjinĂ«, quhet edhe njĂ« formĂ« network affinity â nĂ« analogji me , ose me (dhe Volume Provisioning). Niveli aktual i implementimit tĂ« ServiceTopology nĂ« Kubernetes Ă«shtĂ« alpha-version.
Më shumë hollësi mbi mënyrën si funksionon kjo veçori dhe si mund ta përdorni që tani, lexoni në materialin nga një prej autorëve të saj.
Mbështetje për dual-stack IPv4/IPv6
Përparim i dukshëm edhe në një tjetër veçori të rrjetit: mbështetja e njëkohshme për dy IP stack-e, e prezantuar për herë të parë në . Konkretisht, versioni i ri solli ndryshimet e mëposhtme:
- në kube-proxy mundësinë e funksionimit të njëkohshëm në të dyja mënyrat (IPv4 dhe IPv6);
- në
Pod.Status.PodIPsmbështetje për downward API (njëkohësisht, në/etc/hoststani kërkohet që për host-in të shtohet edhe adresa IPv6); - mbështetje për dy stack-e në (Kubernetes IN Docker) dhe ;
- teste e2e të përditësuara.

përdorimit të stack-ut të dyfishtë IPV4/IPv6 në KIND
Progresi në CSI
U shpall e qëndrueshme për ruajtjen e bazuar në CSI, e prezantuar për herë të parë në .
Nisma pĂ«r migrimin e plugin-eve tĂ« volume-ve nĂ« CSI â â ka arritur nĂ« versionin beta. Kjo veçori Ă«shtĂ« kritike pĂ«r tĂ« kaluar plugin-et ekzistuese tĂ« ruajtjes (in-tree) nĂ« ndĂ«rfaqen moderne (CSI, out-of-tree) pa u vĂ«nĂ« re nga pĂ«rdoruesit fundorĂ« tĂ« Kubernetes. AdministratorĂ«ve tĂ« klasterĂ«ve do tâu mjaftojĂ« tĂ« aktivizojnĂ« CSI Migration, pas sĂ« cilĂ«s burimet ekzistuese stateful dhe ngarkesat e punĂ«s do tĂ« vazhdojnĂ« thjesht tĂ« funksionojnë⊠por tashmĂ« duke pĂ«rdorur driver-at aktualĂ« CSI nĂ« vend tĂ« atyre tĂ« vjetruar, tĂ« integruar nĂ« bĂ«rthamĂ«n e Kubernetes.
Aktualisht, në status beta është gati migrimi për driver-at AWS EBS (kubernetes.io/aws-ebs) dhe GCE PD (kubernetes.io/gce-pd). Parashikimet për ruajtjet e tjera janë si më poshtë:

PĂ«r mĂ«nyrĂ«n se si mbĂ«shtetja âtradicionaleâ e ruajtjes nĂ« K8s arriti te CSI, kemi folur nĂ« . NdĂ«rsa kalimit tĂ« CSI Migration nĂ« status beta i kushtohet njĂ« nĂ« blogun e projektit.
PĂ«rveç kĂ«saj, nĂ« versionin Kubernetes 1.17 njĂ« funksionalitet tjetĂ«r i rĂ«ndĂ«sishĂ«m nĂ« kontekstin e CSI, qĂ« e ka zanafillĂ«n e tij (implementimin alfa) nĂ« K8s 1.12, arriti statusin beta (domethĂ«nĂ« aktivizohet si parazgjedhje) â dhe rikthimi prej tyre. NdĂ«r ndryshimet e bĂ«ra nĂ« Kubernetes Volume Snapshot nĂ« rrugĂ«n drejt versionit beta:
- ndarja e sidecar-it CSI external-snapshotter në dy kontrollues,
- u shtua sekreti i fshirjes (deletion secret) si anotim për përmbajtjen e snapshot-it të volumit,
- një finalizer i ri (finalizer) për të parandaluar fshirjen e objektit API të snapshot-it nëse kanë mbetur lidhje ekzistuese.
Në momentin e publikimit të versionit 1.17, veçoria mbështetet nga tre driver-a CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver dhe NetApp Trident CSI Driver. Më shumë rreth implementimit dhe përdorimit të saj mund të lexoni në blog.
Cloud Provider Labels
Etiketat qĂ« automatikisht u caktohen nyjeve dhe volume-ve tĂ« krijuara nĂ« varĂ«si tĂ« ofruesit cloud tĂ« pĂ«rdorur, kanĂ« qenĂ« tĂ« disponueshme nĂ« Kubernetes si version beta prej shumĂ« kohĂ«sh â qĂ« nga versioni K8s 1.2 (prill 2016!). Duke marrĂ« parasysh pĂ«rdorimin e tyre kaq tĂ« gjerĂ« pĂ«r kaq gjatĂ«, zhvilluesit , se kishte ardhur koha pĂ«r ta shpallur kĂ«tĂ« veçori tĂ« qĂ«ndrueshme (GA).
Për këtë arsye, të gjitha u riemërtuan 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 edhe me emrat e tyre të vjetër (për pajtueshmëri të prapambetur). Megjithatë, të gjithë administratorëve u rekomandohet të kalojnë te labels-et aktuale. i K8s është përditësuar.
Dalje e strukturuar e kubeadm
Në format alpha u prezantua për herë të parë . Formatet e mbështetura: JSON, YAML, shabllon Go.
Arsyetimi për zbatimin e kësaj veçorie (sipas ) është si më poshtë:
Megjithëse Kubernetes mund të vendoset edhe manualisht, standardi de facto (nëse jo de jure) për këtë proces është përdorimi i kubeadm. Mjete të njohura të menaxhimit të sistemeve si Terraform mbështeten te 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 dalje të strukturuar, edhe ndryshimet që në pamje të parë duken krejt të padëmshme mund të prishin Terraform, Cluster API dhe programe të tjera që përdorin rezultatet e kubeadm.
Në planet më të afërta parashikohet mbështetje (në formën e daljes së strukturuar) për komandat e mëposhtme të kubeadm:
-
alpha certs -
config images list -
init -
token create -
token list -
upgrade plan -
version
Ilustrim i përgjigjes JSON për komandën 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, versioni Kubernetes 1.17 u publikua nĂ«n moton âStabilitetiâ. KĂ«tĂ« e favorizoi fakti qĂ« shumĂ« veçori nĂ« tĂ« (numri i tyre i pĂ«rgjithshĂ«m â 14) morĂ«n statusin GA. Midis tyre janĂ«:
- âshĂ«njimiâ i nyjeve sipas kushteve tĂ« caktuara (), i shfaqur nĂ« ;
- â njĂ« lloj i ri ngjarjesh qĂ« kanĂ« shenjĂ«n se tĂ« gjitha objektet deri nĂ« njĂ« version tĂ« caktuar (
resourceVersion) tashmë janë përpunuar nga watch; - (defaulting) për Custom Resources;
- në pod process namespaces;
-
ScheduleDaemonSetPodsâ me kube-scheduler (nĂ« vend tĂ« kontrolluesit DaemonSet); - pĂ«r numrin e volume-ve nĂ« varĂ«si tĂ« llojit tĂ« nyjes;
- për emrat e direktorive që montohen si
subPath; - në Lease API të specializuar;
- âmbrojtja e finalizer-itâ () pĂ«r balancuesit e ngarkesĂ«s (verifikimi i burimeve pĂ«rkatĂ«se tĂ« Service pĂ«rpara fshirjes sĂ« burimeve tĂ« LoadBalancer);
- në performancë gjatë punës me shumë watches që monitorojnë grupe identike objektesh, arrihet duke shmangur riserializimin e të njëjtave objekte për çdo watcher.
Ndryshime të tjera
Lista e plotë e risive në Kubernetes 1.17, sigurisht, nuk kufizohet vetëm me ato të përmendura më sipër. Ja disa të tjera prej tyre (për një listë më të plotë, shihni. ):
- funksionaliteti i prezantuar në versionin e kaluar ;
- një ndryshim i ngjashëm EndpointSlice API (gjithashtu nga K8s 1.16), megjithatë kjo zgjidhje për përmirësimin e performancës/shkallëzueshmërisë së Endpoint API ende nuk është aktivizuar si parazgjedhje;
- pod-et kritike për funksionimin e klasterit tani jo vetëm në namespace-in
kube-system(detajet shihni nĂ« dokumentacionin pĂ«r ); - opsioni i ri pĂ«r kubelet â â lejon pĂ«rcaktimin e qartĂ« tĂ« listĂ«s sĂ« CPU-ve tĂ« rezervuara pĂ«r sistemin;
- për
tani mund tëflamuri i ri--prefix, i cili shton emrin e pod-it dhe të kontejnerit burim në çdo rresht logu; - në
label.SelectorRequiresExactMatch; - të gjithë kontejnerët në kube-dns me më pak privilegje;
- është veçuar në një depo të veçantë GitHub dhe nuk do të përfshihet më në release-t e Kubernetes;
- ndjeshëm e kube-proxy për portet jo-UDP.
Ndryshimet në varësi:
- versioni i CoreDNS i pĂ«rfshirĂ« nĂ« kubeadm â 1.6.5;
- versioni i crictl është përditësuar në v1.16.1;
- CSI 1.2.0;
- etcd 3.4.3;
- versioni i fundit i testuar i Docker është rritur në 19.03;
- versioni minimal i Go i kërkuar për ndërtimin e Kubernetes 1.17 është 1.13.4.
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
