Ang koponan sa pag-unlad ng Kubernetes kamakailan ay pinakawalan sa pamamagitan ng anunsyo ang paglabas ng ang bagong bersyon na "Kubernetes 1.18" kung saan binabanggit ng pangkat ng pag-unlad na ito ay isang bersyon na 'akma at natapos'.
Sa bagong bersyon na ito makabuluhang gawain ay nagawa upang mapabuti ang beta at matatag na pagpapaandar upang magarantiya a mas mahusay na karanasan ng gumagamit. Ang isang pantay na pagsisikap ay nagawa upang magdagdag ng mga bagong pagpapaunlad at kapanapanabik na mga bagong tampok na nangangako upang higit na mapahusay ang karanasan ng gumagamit.
Para sa mga hindi nakakaalam Kubernetes, Dapat nilang malaman iyon ay isang bukas na sistema ng mapagkukunan upang awtomatiko ang paglawak, pag-scale at pamamahala ng lalagyan na mga aplikasyon.
Fue orihinal na dinisenyo ng Google, bagaman ang pag-unlad na ito ay kasunod na ipinagkatiwala sa Open Source Cloud Computing Foundation (CNCF), na ngayon ay pinayagan ang teknolohiyang container orchestration na mabilis na mag-mature, salamat sa mga ambag ng mga higante ng teknolohiya.
Ano ang bago sa Kubernetes 1.18?
Ang bagong bersyon ay nakatayo para sa pagkakaroon ng kakayahang gumamit ng mga token sa serbisyo ng account bilang isang pangkalahatang pamamaraan ng pagpapatotoo. Halimbawa, kung nais mo ang isang pod na pamahalaan ang iba pang mga mapagkukunan ng Kubernetes, tulad ng isang pag-deploy o isang serbisyo, maaari itong maiugnay sa isang account sa serbisyo at lumikha ng mga kinakailangang tungkulin at paghihigpit sa papel.
Nagpadala ang mga account ng serbisyo ng Kubernetes (KSA) ng mga token sa web ng JSON (JWT) sa API server upang patunayan. Ginagawa nitong ang server ng API ang tanging mapagkukunan ng pagpapatotoo para sa mga account ng serbisyo.
Kubernetes 1.18pnagbibigay ng isang pagpapaandar ito Pinapayagan ang API server na magbigay ng isang dokumento ng pagtuklas ng OpenID Connect Isang naglalaman ng mga pampublikong key ng token bilang karagdagan sa iba pang metadata.
Ang isa pang pagbabago na namumukod-tangi mula sa Kubernetes 1.81 ay ang kakayahang i-configure ang HPA Velocity para sa mga tiyak na pod. Ginamit ang Horizontal Pod Autoscaler (HPA)a upang payagan ang isang kumpol ng Kubernetes na awtomatikong tumugon sa mataas / mababang trapiko. Sa HPA, maaaring hilingin ng gumagamit sa controller na lumikha ng higit pang mga module bilang tugon sa mga CPU spike, iba pang mga pagsukat, o mga sukat na ibinigay ng application.
Ang Kubernetes 1.18 ay may isang pangkalahatang-ideya ng mga profile upang magpatakbo ng maraming mga pagsasaayos ng tagaplano. Sa pangkalahatan, mayroong dalawang uri ng mga workload sa Kubernetes: mga pangmatagalang serbisyo (halimbawa, mga web server, API, atbp.) At mga gawain na tumatakbo hanggang sa makumpleto (mas kilala sa pangalang Trabaho).
Dahil sa halatang pagkakaiba sa pagitan ng mga uri ng workload, ang ilang mga gumagamit ay gumagamit ng paglikha ng buong mga kumpol para sa iba't ibang mga pangangailangan. Halimbawa, isang kumpol upang pamahalaan ang pagmimina ng data at isa pa upang maghatid ng mga application API.
Ang dahilan ay kailangan nila ang proseso ng desisyon upang magkakaiba. Halimbawa, ang mga setting ng default na tagapag-iskedyul ay nagtataguyod ng mataas na kakayahang magamit.
Sa kabilang banda, mahahanap din natin ang kakayahang tukuyin ang isang patakaran sa pag-broadcast ng pod sa antas ng kumpol, bilang ginawang posible upang matiyak na mai-iskedyul ang mga pod sa mga Zona ng Pag-access (hangga't gumagamit ka ng isang multi-zone cluster) upang matiyak ang maximum na kakayahang magamit at paggamit ng mapagkukunan.
Nagbibigay-daan ang pagpapaandar sa detalye ng topologyS nyebarConstraints, na kinikilala ang mga lugar sa pamamagitan ng paghahanap para sa mga node na may parehong topologyKey na tag. Ang mga node na may parehong TopologyKey tag ay nabibilang sa parehong lugar. Ang pagsasaayos ay upang ipamahagi nang pantay-pantay ang mga pod sa iba't ibang mga lugar. Gayunpaman, ang downside ay ang setting na ito ay dapat na mailapat sa antas ng pod. Ang mga pod na walang pagsasaayos ay hindi pantay na ibabahagi sa mga domain ng kasalanan.
Huling ngunit hindi huli, mahahanap din natin ang kakayahang balewalain ang pagbabago sa dami ng pag-aari. Bilang default, kapag ang isang dami ay naka-mount sa isang lalagyan sa isang kumpol ng Kubernetes, lahat ng mga file at direktoryo sa loob ng dami na ito ay nabago ang kanilang pag-aari sa halagang ibinigay sa pamamagitan ng fsGroup.
Ang lahat ng ito upang payagan ang fsGroup na basahin at isulat ang dami. Gayunpaman, ang pag-uugali na ito ay ipinapakita na hindi kanais-nais sa ilang mga kaso.
Ang bagong bersyon ng Ang Kubernetes ay mayroong maraming mga pagbabago at nabanggit lamang namin ang ilan sa mga pinakamahalaga. Kung nais mong malaman ang kumpletong listahan maaari mo itong gawin sa pamamagitan ng pagbisita sa sumusunod na link.