Hjoed, woansdei, folgjende release fan Kubernetes - 1.16. Neffens de tradysje dy't hat ûntwikkele foar ús blog, dit is de tsiende jubileum tiid dat wy prate oer de meast wichtige feroarings yn de nije ferzje.
Ynformaasje dy't brûkt wurdt om dit materiaal te meitsjen is nommen út , en relatearre problemen, pull-oanfragen, en Kubernetes Enhancement Proposals (KEP). Dus, litte wy gean!..
Knooppunten
In echt grut oantal opmerklike ynnovaasjes (yn alfa ferzje status) wurde presintearre oan 'e kant fan' e K8s kluster knopen (Kubelet).
Foarste plak, de saneamde «» (Efemere konteners), ûntworpen om debuggenprosessen yn pods te ferienfâldigjen. It nije meganisme lit jo spesjale konteners lansearje dy't begjinne yn 'e nammeromte fan besteande pods en libje foar in koarte tiid. Har doel is om te ynteraksje mei oare pods en konteners om problemen op te lossen en te debuggen. In nij kommando is ymplementearre foar dizze funksje kubectl debug, fergelykber yn wêzen mei kubectl exec: allinich ynstee fan in proses út te fieren yn in kontener (lykas yn exec) it lanseart in kontener yn in pod. Dit kommando sil bygelyks in nije kontener ferbine mei in pod:
kubectl debug -c debug-shell --image=debian target-pod -- bashDetails oer efemere konteners (en foarbylden fan har gebrûk) kinne fûn wurde yn . De hjoeddeistige ymplemintaasje (yn K8s 1.16) is in alfa-ferzje, en ûnder de kritearia foar syn oerdracht nei in beta-ferzje is "it testen fan de Ephemeral Containers API foar op syn minst 2 releases fan [Kubernetes]."
NB: Yn syn essinsje en sels syn namme liket de funksje op in al besteande plugin oer dêr't wy . It wurdt ferwachte dat mei de komst fan efemere konteners de ûntwikkeling fan in aparte eksterne plugin sil ophâlde.
In oare ynnovaasje - - ûntwurpen om te foarsjen meganisme foar it berekkenjen fan overheadkosten foar pods, dy't sterk ferskille kinne ôfhinklik fan 'e brûkte runtime. As foarbyld, de skriuwers resultearje yn Kata Containers, dy't de gastkernel, kata-agent, init-systeem, ensfh. As de overhead sa grut wurdt, kin it net negearre wurde, wat betsjut dat d'r in manier wêze moat om it yn rekken te hâlden foar fierdere kwota's, planning, ensfh. Om it yn te fieren PodSpec fjild tafoege Overhead *ResourceList (fergelike mei gegevens yn RuntimeClass, as ien wurdt brûkt).
In oare opmerklike ynnovaasje is node topology manager (Node Topology Manager), ûntworpen om de oanpak te ferienigjen foar it fine-tunen fan de allocaasje fan hardware-boarnen foar ferskate komponinten yn Kubernetes. Dit inisjatyf wurdt dreaun troch it tanimmende ferlet fan ferskate moderne systemen (fan it mêd fan telekommunikaasje, masine learen, finansjele tsjinsten, ensfh.) hardware fersnelling mooglikheden. Sokke optimisaasjes yn Kubernetes binne oant no ta berikt troch ferskate komponinten (CPU-manager, Device manager, CNI), en no sille se in inkele ynterne ynterface tafoege wurde dy't de oanpak ferieniget en de ferbining fan nije ferlykbere - saneamde topology- bewust - komponinten oan de Kubelet kant. Details - yn .
Topology Manager Component Diagram
Folgjende funksje - konteners kontrolearje wylst se rinne (). Lykas jo witte, foar konteners dy't in lange tiid duorje om te lansearjen, is it lestich om in aktuele status te krijen: se wurde of "fermoarde" foardat se werklik begjinne te funksjonearjen, of se einigje foar in lange tiid yn deadlock. Nije kontrôle (ynskeakele fia funksje-poarte neamd StartupProbeEnabled) annuleart - of leaver, útstelt - it effekt fan alle oare kontrôles oant it momint dat de pod klear is mei rinnen. Om dizze reden waard de funksje oarspronklik neamd . Foar pods dy't in lange tiid duorje om te begjinnen, kinne jo de steat yn relatyf koarte tiidintervallen peilje.
Derneist is in ferbettering foar RuntimeClass direkt beskikber yn beta-status, en tafoege stipe foar "heterogene klusters". C No is it hielendal net nedich foar elke knooppunt om stipe te hawwen foar elke RuntimeClass: foar pods kinne jo in RuntimeClass selektearje sûnder te tinken oer de klustertopology. Earder, om dit te berikken - sadat pods op knooppunten einigje mei stipe foar alles wat se nedich binne - wie it nedich om passende regels ta te jaan oan NodeSelector en toleraasjes. YN It praat oer foarbylden fan gebrûk en, fansels, details oer ymplemintaasje.
Netwurk
Twa wichtige netwurkfunksjes dy't foar it earst ferskynden (yn alfa-ferzje) yn Kubernetes 1.16 binne:
- dûbele netwurk stack - IPv4 / IPv6 - en it oerienkommende "begryp" op it nivo fan pods, knopen, tsjinsten. It omfettet IPv4-nei-IPv4- en IPv6-nei-IPv6-ynteroperabiliteit tusken pods, fan pods oant eksterne tsjinsten, referinsjeimplementaasjes (binnen de Bridge CNI, PTP CNI en Host-Local IPAM-plugins), lykas omkearkompatibel mei Kubernetes-klusters dy't rinne Allinnich IPv4 of IPv6. Ymplemintaasje details binne yn .
In foarbyld fan it werjaan fan IP-adressen fan twa soarten (IPv4 en IPv6) yn 'e list mei pods:
kube-master# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-controller 1/1 Running 0 20m fd00:db8:1::2,192.168.1.3 kube-minion-1 kube-master# - Nije API foar Endpoint - . It lost de prestaasjes / skaalberensproblemen fan 'e besteande Endpoint API op dy't ynfloed hawwe op ferskate komponinten yn it kontrôlefleanmasine (apiserver, ensfh, endpoints-controller, kube-proxy). De nije API sil wurde tafoege oan 'e Discovery API-groep en sil yn steat wêze om tsientûzenen backend-einpunten te tsjinjen op elke tsjinst yn in kluster besteande út tûzenen knopen. Om dit te dwaan, wurdt elke tsjinst yn kaart brocht oan N objekten
EndpointSlice, elk fan dat hat standert net mear as 100 einpunten (de wearde is ynstelbere). De EndpointSlice API sil ek kânsen leverje foar syn takomstige ûntwikkeling: stipe foar meardere IP-adressen foar elke pod, nije steaten foar einpunten (net allinichReadyиNotReady), dynamyske subynstelling foar einpunten.
De iene presintearre yn 'e lêste release hat de beta-ferzje berikt neamd service.kubernetes.io/load-balancer-cleanup en hechte oan elke tsjinst mei type LoadBalancer. Op it momint fan it wiskjen fan sa'n tsjinst foarkomt it de eigentlike wiskjen fan 'e boarne oant de "skjinning" fan alle relevante balancer-boarnen is foltôge.
API Machinery
De echte "stabilisaasjemylpeal" is yn it gebiet fan 'e Kubernetes API-tsjinner en ynteraksje dêrmei. Dit barde foar in grut part te tankjen oan oermeitsje nei stabile status dyjingen dy't net nedich spesjale yntroduksje (CRD), dy't sûnt de fiere dagen fan Kubernetes 1.7 beta-status hawwe (en dit is juny 2017!). Deselde stabilisaasje kaam ta de relatearre funksjes:
- со
/statusи/scalefoar CustomResources; - ferzjes foar CRD, basearre op eksterne webhook;
- (yn K8s 1.15) standert wearden (standert) en automatyske fjildferwidering (snoeien) foar CustomResources;
- it OpenAPI v3-skema brûke om OpenAPI-dokumintaasje te meitsjen en te publisearjen dy't brûkt wurdt om CRD-boarnen op 'e serverkant te falidearjen.
In oar meganisme dat al lang bekend wurden is foar Kubernetes-behearders: - bleau ek in beta-status foar in lange tiid (sûnt K8s 1.9) en wurdt no stabyl ferklearre.
Twa oare funksjes hawwe beta berikt: и .
En de ienige wichtige ynnovaasje yn 'e alfa ferzje wie от SelfLink - in spesjale URI dy't it oantsjutte objekt fertsjintwurdiget en diel is fan ObjectMeta и ListMeta (d.w.s. diel fan elk objekt yn Kubernetes). Wêrom ferlitte se it? Motivaasje op in ienfâldige manier as it ûntbrekken fan echte (oerweldigjende) redenen om dit fjild noch te bestean. Mear formele redenen binne om prestaasjes te optimalisearjen (troch in ûnnedich fjild te ferwiderjen) en it wurk fan 'e generyske-apiserver te ferienfâldigjen, dy't twongen is om sa'n fjild op in spesjale manier te behanneljen (dit is it ienige fjild dat krekt foar it objekt ynsteld is is serialisearre). Wiere ferâldering (binnen beta) SelfLink sil barre troch Kubernetes ferzje 1.20, en final - 1.21.
Data opslach
It wichtichste wurk op it mêd fan opslach, lykas yn eardere releases, wurdt waarnommen yn it gebiet . De wichtichste feroarings hjir wiene:
- foar de earste kear (yn alfa ferzje) CSI-plugin-stipe foar Windows-arbeiderknooppunten: de hjoeddeistige manier fan wurkjen mei opslach sil ek yntree-plugins ferfange yn 'e Kubernetes-kearn en FlexVolume-plugins fan Microsoft basearre op Powershell;
Skema foar ymplemintaasje fan CSI-plugins yn Kubernetes foar Windows - kâns , yntrodusearre werom yn K8s 1.12, is útgroeid ta in beta ferzje;
- In ferlykbere "promoasje" (fan alfa nei beta) waard berikt troch de mooglikheid om CSI te brûken om lokale efemere voluminten te meitsjen ().
Yntrodusearre yn 'e foarige ferzje fan Kubernetes (gebrûk fan besteande PVC as DataSource om nije PVC te meitsjen) hat ek no beta-status krigen.
Planner
Twa opmerklike feroarings oan skema (beide yn alfa):
- - kâns brûke pods ynstee fan logyske applikaasje ienheden foar "earlike ferdieling" fan loads (lykas Deployment en ReplicaSet) en it oanpassen fan dizze ferdieling (as in hurde eask of as in sêfte betingst, d.w.s. prioriteit). De funksje sil de besteande distribúsjemooglikheden fan plande pods útwreidzje, op it stuit beheind troch opsjes
PodAffinityиPodAntiAffinity, jaan behearders finere kontrôle yn dizze saak, dat betsjut better hege beskikberens en optimalisearre boarne konsumpsje. Details - yn . - Gebrûk BestFit Belied в RequestedToCapacityRatio Priority Function tidens pod planning, dat sil tastean oanfreegje ("ynpakken yn konteners") foar sawol basisboarnen (prosessor, ûnthâld) as útwreide (lykas GPU). Foar mear details, sjoch .
Planning pods: foardat jo it bêste fit-belied brûke (direkt fia standertplanner) en mei it gebrûk (fia scheduler-extender)
Dêrnjonken, de mooglikheid om jo eigen planner-plugins te meitsjen bûten de wichtichste Kubernetes-ûntwikkelingsbeam (out-of-tree).
Oare feroarings
Ek yn 'e Kubernetes 1.16-release kinne jo notearje inisjatyf foar beskikbere metriken yn folsleine folchoarder, of mear krekter, yn oerienstimming mei oan K8s ynstrumintaasje. Se fertrouwe foar in grut part op it korrespondearjende . Inkonsistinsjes ûntstienen om ferskate redenen (bygelyks guon metriken waarden gewoan makke foardat de hjoeddeistige ynstruksjes ferskynden), en de ûntwikkelders besletten dat it tiid wie om alles op ien standert te bringen, "yn oerienstimming mei de rest fan it Prometheus-ekosysteem." De hjoeddeistige ymplemintaasje fan dit inisjatyf is yn alfa-status, dy't yn folgjende ferzjes fan Kubernetes stadichoan befoardere wurde sil nei beta (1.17) en stabyl (1.18).
Derneist kinne de folgjende wizigingen wurde opmurken:
- Windows stipe ûntwikkeling с Kubeadm-hulpprogramma's foar dit OS (alfa-ferzje),
RunAsUserNamefoar Windows-kontainers (alfa-ferzje), Group Managed Service Account (gMSA) stipe oant beta ferzje, mount / taheakje foar vSphere folumes. - data-kompresjemeganisme yn API-antwurden. Earder waard in HTTP-filter brûkt foar dizze doelen, dy't in oantal beheiningen ynstelde dy't foarkommen dat it standert ynskeakele waard. "Transparante fersykkompresje" wurket no: kliïnten stjoere
Accept-Encoding: gzipyn 'e koptekst krije se in GZIP-komprimearre antwurd as syn grutte grutter is as 128 KB. Go-kliïnten stypje automatysk kompresje (ferstjoere de fereaske koptekst), sadat se fuortendaliks in fermindering fan ferkear fernimme. (Lichte oanpassings kinne nedich wêze foar oare talen.) - skaalfergrutting fan HPA fan / nei nul pods basearre op eksterne metriken. As jo skaalje op basis fan objekten / eksterne metriken, dan kinne jo as workloads idle binne automatysk skaalje nei 0 replika's om boarnen te bewarjen. Dizze funksje soe benammen nuttich wêze moatte foar gefallen dêr't arbeiders GPU-boarnen freegje, en it oantal ferskillende soarten idle arbeiders grutter is as it oantal beskikbere GPU's.
- Nije klant - - foar "generalisearre" tagong ta objekten. It is ûntworpen om maklik metadata op te heljen (dus subseksje
metadata) fan klusterboarnen en útfiere jiskefet- en kwotaoperaasjes mei har. - Kubernetes bouwe sûnder legacy ("ynboude" yn-beam) wolkproviders (alfa-ferzje).
- Nei it kubeadm-hulpprogramma eksperimintele (alfa-ferzje) mooglikheid om oanpasse patches oan te passen tidens operaasjes
init,joinиupgrade. Learje mear oer hoe't jo de flagge brûke kinne--experimental-kustomize,sjo yn . - Nij einpunt foar apiserver - , - kinne jo ynformaasje eksportearje oer syn reewilligens. De API-tsjinner hat no ek in flagge
--maximum-startup-sequence-duration, wêrtroch jo syn opnij starte kinne regelje. - Twa funksjes foar Azure ferklearre stabyl: stipe (Beskikberens Zones) en (RG). Derneist hat Azure tafoege:
- AAD en ADFS;
-
service.beta.kubernetes.io/azure-pip-nameom de iepenbiere IP fan 'e load balancer oan te jaan; - ynstellings
LoadBalancerNameиLoadBalancerResourceGroup.
- AWS hat no foar EBS op Windows en EC2 API oproppen
DescribeInstances. - Kubeadm is no ûnôfhinklik CoreDNS-konfiguraasje by it opwurdearjen fan de CoreDNS-ferzje.
- Binarissen ensfh yn 'e oerienkommende Docker-ôfbylding world-útfierber, wêrtroch jo dizze ôfbylding kinne útfiere sûnder de needsaak foar rootrjochten. Ek, etcd migraasje ôfbylding etcd2 ferzje stipe.
- В oerstapt op it brûken fan distroless as basisôfbylding, ferbettere prestaasjes, tafoege nije wolkproviders (DigitalOcean, Magnum, Packet).
- Updates yn brûkte / ôfhinklike software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
PS
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com