Kubernetes 1.17: një pasqyrë e novacioneve kryesore

Dje, mĂ« 9 dhjetor, u organizua 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.

Kubernetes 1.17: një pasqyrë e novacioneve kryesore

Informacioni i përdorur për përgatitjen e këtij materiali është marrë nga njoftimi zyrtar, tabela e ndjekjes së përmirësimeve të Kubernetes, CHANGELOG-1.17 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 KEP e ka zanafillĂ«n nĂ« tetor 2018, ndĂ«rsa enhancement zyrtar u shfaq 2 vjet mĂ« parĂ«, kurse issues tĂ« zakonshme (si p.sh. kĂ«tĂ«) — 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 ilustrimin e fundit 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 node affinity, pod affinity/anti-affinity ose me tĂ« prezantuar jo shumĂ« kohĂ« mĂ« parĂ« (dhe Topology-Aware Volume SchedulingVolume 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 këto artikuj nga një prej autorëve të saj.

Mbështetje për dual-stack IPv4/IPv6

Përparim i dukshëm është arritur 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ë K8s 1.16. Konkretisht, versioni i ri solli ndryshimet e mëposhtme:

  • nĂ« kube-proxy Ă«shtĂ« implementuar mundĂ«sinĂ« e funksionimit tĂ« njĂ«kohshĂ«m nĂ« tĂ« dyja mĂ«nyrat (IPv4 dhe IPv6);
  • nĂ« Pod.Status.PodIPs ka dalĂ« mbĂ«shtetje pĂ«r downward API (njĂ«kohĂ«sisht, nĂ« /etc/hosts tani kĂ«rkohet qĂ« pĂ«r host-in tĂ« shtohet edhe adresa IPv6);
  • mbĂ«shtetje pĂ«r dy stack-e nĂ« KIND (Kubernetes IN Docker) dhe kubeadm;
  • teste e2e tĂ« pĂ«rditĂ«suara.

Kubernetes 1.17: një pasqyrë e novacioneve kryesore
Ilustrimi përdorimit të stack-ut të dyfishtë IPV4/IPv6 në KIND

Progresi në CSI

U shpall e qëndrueshme mbështetja e topologjive për ruajtjen e bazuar në CSI, e prezantuar për herë të parë në K8s 1.12.

Nisma pĂ«r migrimin e plugin-eve tĂ« volume-ve nĂ« CSI — CSI Migration — 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ë:

Kubernetes 1.17: një pasqyrë e novacioneve kryesore

PĂ«r mĂ«nyrĂ«n se si mbĂ«shtetja “tradicionale” e ruajtjes nĂ« K8s arriti te CSI, kemi folur nĂ« kĂ«to artikuj. NdĂ«rsa kalimit tĂ« CSI Migration nĂ« status beta i kushtohet njĂ« publikim i veçantĂ« 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) — krijimi i snapshot-eve 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ë këtë publikim 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 vendosĂ«n, 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. Dokumentacioni përkatës i K8s është përditësuar.

Dalje e strukturuar e kubeadm

Në format alpha u prezantua për herë të parë dalja e strukturuar për mjetin kubeadm. Formatet e mbështetura: JSON, YAML, shabllon Go.

Arsyetimi për zbatimin e kësaj veçorie (sipas KEP) ë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Ă«:

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. CHANGELOG):

  • funksionaliteti i prezantuar nĂ« versionin e kaluar RunAsUserName pĂ«r Windows;
  • njĂ« ndryshim i ngjashĂ«m ka prekur 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 mund tĂ« krijohen jo vetĂ«m nĂ« namespace-in kube-system (detajet shihni nĂ« dokumentacionin pĂ«r Limit Priority Class consumption);
  • opsioni i ri pĂ«r kubelet — --reserved-cpus — lejon pĂ«rcaktimin e qartĂ« tĂ« listĂ«s sĂ« CPU-ve tĂ« rezervuara pĂ«r sistemin;
  • pĂ«r tani mund tĂ« u paraqit flamuri i ri --prefix, i cili shton emrin e pod-it dhe tĂ« kontejnerit burim nĂ« çdo rresht logu;
  • nĂ« label.Selector shtuan RequiresExactMatch;
  • tĂ« gjithĂ« kontejnerĂ«t nĂ« kube-dns tani nisen me mĂ« pak privilegje;
  • hyperkube Ă«shtĂ« veçuar nĂ« njĂ« depo tĂ« veçantĂ« GitHub dhe nuk do tĂ« pĂ«rfshihet mĂ« nĂ« release-t e Kubernetes;
  • ndjeshĂ«m Ă«shtĂ« pĂ«rmirĂ«suar performanca 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

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster