🥇Kubernetes 1.17: berrikuntza nagusien ikuspegi orokorra

Atzo, abenduak 9, ospatu Kubernetes-en hurrengo bertsioa - 1.17. Gure blogerako garatu den tradizioaren arabera, bertsio berriaren aldaketa esanguratsuenei buruz hitz egiten dugu.

Material hau prestatzeko erabilitako informazioa iragarki ofizialetik hartua da, Kubernetesen hobekuntzak jarraitzeko taulak, ALDAKETAK-1.17 eta lotutako gaiak, tira-eskaerak eta Kubernetes Hobekuntza-Proposamenak (KEP). Orduan, zer berri?...

Topologiari buruzko bideratzea

Kubernetes komunitatea denbora luzez egon da funtzio honen zain - Topologiari buruzko zerbitzuen bideraketa. bada CAP 2018ko urrian du jatorria, eta ofiziala hobekuntza — Duela 2 urte, ohiko gaiak (adibidez da) - eta urte batzuk gehiago...

Ideia orokorra Kubernetesen bizi diren zerbitzuetarako bideratze "tokikoa" ezartzeko gaitasuna eskaintzea da. "Lokalitatea" kasu honetan "maila topologiko bera" esan nahi du (topologia maila), hau izan daiteke:

zerbitzuetarako nodo berdina,
zerbitzariaren rack bera,
eskualde bera
hodeiko hornitzaile bera,
...

Ezaugarri hau erabiltzeko adibideak:

trafikoan aurreztea erabilgarritasun-eremu anitzekin hodeiko instalazioetan (AZ anitza) - ikus. ilustrazio freskoa Eskualde bereko trafikoaren adibidea erabiliz, baina AZ desberdinak AWSn;
errendimendu-latentzia txikiagoa / errendimendu hobea;
zati bakoitzean nodoari buruzko informazio lokala duen zerbitzu zatikatua;
Fluentd (edo analogoak) nodo berean kokatzea erregistroak biltzen diren aplikazioekin;
...

Bideratze horri, topologiari buruz "dakiena", sare-afinitatea ere deitzen zaio -ekin analogiaz. nodo afinitatea, pod afinitate/anti-afinity edo agertu duela ez hainbeste Topologiari buruzko bolumenaren programazioa (eta Bolumen hornidura). Egungo ezarpen-maila ServiceTopology Kubernetes-en - alfa bertsioa.

Funtzioak nola funtzionatzen duen eta dagoeneko erabil dezakezun xehetasunak lortzeko, irakurri Artikulu honetan egileetako baten eskutik.

IPv4/IPv6 pila bikoitzeko euskarria

Aurrerapen nabarmena finkoa sareko beste ezaugarri batean: bi IP pilaren aldibereko euskarria, lehen urtean sartu zena K8ak 1.16. Bereziki, bertsio berriak aldaketa hauek ekarri zituen:

kube-proxy-n ezarrita bi moduetan aldi berean funtzionatzeko aukera (IPv4 eta IPv6);
в Pod.Status.PodIPs agertu beheranzko APIrako laguntza (aldi berean /etc/hosts orain ostalariari IPv6 helbide bat gehitzea eskatzen diote);
pila bikoitzeko euskarria NAZIOA (Kubernetes IN Docker) eta kubeadm;
e2e proba eguneratuak.

Ilustrazioa IPV4/IPv6 pila bikoitza erabiliz KIND

CSIn aurrerapena

Egonkor deklaratua topologia euskarria CSIn oinarritutako biltegiratzerako, lehenengo urtean sartu zen K8ak 1.12.

Ekimena bolumen-pluginak CSIra migratzea - CSI Migrazioa - beta bertsiora iritsi da. Ezaugarri hau funtsezkoa da lehendik dauden biltegiratze-pluginak itzultzeko (zuhaitz barruan) interfaze moderno batera (CSI, zuhaitzetik kanpo) Kubernetes azken erabiltzaileentzat ikusezina. Klusterreko administratzaileek CSI migrazioa gaitu besterik ez dute egin beharko, eta, ondoren, lehendik dauden egoera-baliabideek eta lan-kargak "funtzionatzen" jarraituko dute... baina azken CSI kontrolatzaileak erabiliz Kubernetes nukleoan sartutako zaharkituak ordez.

Momentuz, AWS EBS kontrolatzaileentzako migrazioa prest dago beta bertsioan (kubernetes.io/aws-ebs) eta GCE PD (kubernetes.io/gce-pd). Beste biltegietarako aurreikuspenak hauek dira:

K8s-en biltegiratze-laguntza "tradizionala" CSIra nola iritsi zenari buruz hitz egin genuen Artikulu honetan. Eta CSI migrazioaren trantsizioa beta egoerara dedikatzen da argitalpen bereizia proiektuaren blogean.

Horrez gain, CSIren testuinguruko beste funtzionalitate esanguratsu bat, K1.17s 8-n (alfa inplementazioa) sortzen dena, beta egoerara iritsi zen (hau da, lehenespenez gaituta) Kubernetes 1.12 bertsioan - argazkiak sortuz eta haiengandik berreskuratzea. Beta kaleratzeko bidean Kubernetes Volume Snapshot-en egindako aldaketen artean:

CSI kanpoko snapshotter sidecar bi kontrolagailutan zatitzea,
ezabatzeko sekretua gehitu da (ezabatzeko sekretua) bolumenaren argazki baten edukiari buruzko ohar gisa,
Finalizatzaile berria (finalizatzailea) snapshot API objektua ezabatzeko gainerako konexioak badaude.

1.17 bertsioa argitaratu zenean, funtzioa hiru CSI kontrolatzailek onartzen dute: GCE Persistent Disk CSI Driver, Portworx CSI Driver eta NetApp Trident CSI Driver. Bere ezarpenari eta erabilerari buruzko xehetasun gehiago hemen aurki daitezke argitalpen hau blogean.

Hodeiko hornitzaileen etiketak

Hori automatikoki etiketatzen du sortutako nodoei eta bolumenei esleituta, erabilitako hodei-hornitzailearen arabera, Kubernetesen eskuragarri egon dira beta bertsio gisa denbora luzez - K8s 1.2 kaleratu zenetik. (2016ko apirila!). Hainbeste denboran erabilera hedatua ikusita, garatzaileak erabaki zuen, ezaugarria egonkorra (GA) deklaratzeko garaia dela.

Hori dela eta, denak horren arabera aldatu ziren (topologiaren arabera):

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

... baina oraindik eskuragarri daude beren izen zaharrekin (atzerako bateragarritasunerako). Hala ere, administratzaile guztiei uneko etiketetara aldatzea gomendatzen zaie. Lotutako dokumentazioa K8s eguneratu da.

Kubeadm-en irteera egituratua

Alpha bertsioan aurkeztu da lehen aldiz kubeadm utilitaterako irteera egituratua. Onartutako formatuak: JSON, YAML, Go txantiloia.

Ezaugarri hau ezartzeko motibazioa (arabera CAP) hau da:

Kubernetes eskuz inplementa daitekeen arren, eragiketa honen de facto (ez bada de jure) estandarra kubeadm erabiltzea da. Terraform bezalako sistema kudeatzeko tresna ezagunek kubeadm-n oinarritzen dira Kubernetes inplementatzeko. Cluster APIan aurreikusitako hobekuntzak Kubernetes abiarazterako pakete konposagarri bat dira kubeadm eta cloud-init-ekin.

Irteera egituratu gabe, lehen begiratuan kalterik gabeko aldaketak ere apur ditzakete Terraform, Cluster API eta kubeadm-en emaitzak erabiltzen dituen beste software batzuk.

Gure berehalako planek kubeadm komando hauetarako laguntza (irteera egituratu moduan) barne hartzen dute:

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

Komando bati JSON erantzun baten ilustrazioa 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="
}

Beste berrikuntza batzuen egonkortzea

Oro har, Kubernetes 1.17 kaleratzea lemapean egin zen.egonkortasuna" Hori erraztu zen bertan ezaugarri asko egoteak (guztira kopurua da 14) GA egoera jaso du. Haien artean:

nodoak "markatzea" baldintza batzuen arabera (TaintNodesByCondition), urtean agertu zen K8ak 1.8;
Ikusi Laster-markak - Objektu guztiak bertsio jakin batera dauden etiketa duten gertaera mota berri bat (resourceVersion) dagoeneko erloju bidez prozesatu dira;
balio lehenetsiak Baliabide pertsonalizatuetarako (lehenetsia);
edukiontzien artean partekatua pod prozesuko izen-espazioetan;
ScheduleDaemonSetPods - pods programatzea DaemonSet-en kube-scheduler erabiliz (DaemonSet kontroladorearen ordez);
muga dinamikoak bolumen kopurua nodo motaren arabera;
ingurune aldagaien euskarria gisa muntatutako direktorio-izenetarako subPath;
Kubelet-en taupadak transferitzea Lease API espezializatu batera;
"finalizatzaileen babesa" (Finalizatzaileen babesa) karga-orekatzaileetarako (LoadBalancer baliabideak ezabatu aurretik dagozkion Zerbitzu-baliabideak egiaztatu);
kube-apiserver optimizazioa errendimenduan erloju anitzekin lan egiten denean objektu-multzo berdinak kontrolatzen dituztenean - begirale bakoitzarentzat objektu berdinen behin eta berriz serializazioa saihestuz lortzen da.

Beste aldaketa batzuk

Kubernetes 1.17-ko berrikuntzen zerrenda osoa, noski, ez da goian zerrendatutakoetara mugatzen. Hona hemen beste batzuk (eta zerrenda osatuagoa lortzeko, ikus ALDAKETA):

Azken bertsioan aurkeztutako funtzioa beta bertsiora iritsi da RunAsUserName leihoetarako;
antzeko aldaketa gertatu zen EndpointSlice APIa (K8s 1.16-tik ere bai), baina oraingoz Endpoint APIaren errendimendua/eskalakortasuna hobetzeko irtenbide hau ez dago lehenespenez gaituta;
lekak funtsezkoak dira orain kluster funtzionatzeko sor daitezke ez bakarrik izen-espazioetan kube-system (Xehetasunetarako, ikusi dokumentazioa Mugatu Lehentasunezko Klaseko kontsumoa);
kubelet-en aukera berria - --reserved-cpus — sistemarako erreserbatutako CPUen zerrenda esplizituki definitzeko aukera ematen du;
egiteko kubectl logs aurkeztu bandera berria --prefix, erregistroko lerro bakoitzean lekaren eta iturburu-edukiontziaren izena gehituz;
в label.Selector gehitu du RequiresExactMatch;
ontzi guztiak kube-dns-en orain martxan daude pribilegio gutxiagorekin;
hiperkube GitHub biltegi bereizi batean banatuta eta jada ez da Kubernetesen bertsioetan sartuko;
askoz errendimendua hobetu kube-proxy UDP ez diren ataketarako.

Mendekotasun-aldaketak:

Kubeadm-en barne dagoen CoreDNS bertsioa 1.6.5 da;
crictl bertsioa v1.16.1 eguneratu da;
CSI 1.2.0;
etcd 3.4.3;
Probatutako azken Docker bertsioa 19.03ra eguneratu da;
Kubernetes 1.17 eraikitzeko behar den Go bertsio minimoa 1.13.4 da.

PS

Irakurri ere gure blogean:

Iturria: www.habr.com

Kubernetes 1.17: berritasunaren aipagarrienak