To noč naslednja izdaja Kubernetesa - . Po tradiciji, ki se je razvila za naš blog, govorimo o ključnih spremembah v novi različici tega čudovitega odprtokodnega izdelka.
Podatki, uporabljeni za pripravo tega gradiva, so vzeti iz , in sorodna vprašanja, zahteve za vleko, predlogi za izboljšavo Kubernetes (KEP).
Začnimo s pomembnim uvodom iz življenjskega cikla gruče SIG: dinamične samodejne gruče Kubernetes (ali če smo natančnejši, samostojne uvedbe HA) je zdaj z uporabo znanih (v kontekstu gruč z enim vozliščem) ukazov kubeadm (init и join). Skratka za tole:
- potrdila, ki jih uporablja grozd, se prenesejo v skrivnosti;
- za možnost uporabe gruče etcd znotraj gruče K8s (t.j. znebite se predhodno obstoječe zunanje odvisnosti) ;
- Dokumentira priporočene nastavitve za zunanji izravnalnik obremenitve, ki zagotavlja konfiguracijo, odporno na napake (v prihodnosti je načrtovana odprava te odvisnosti, vendar ne na tej stopnji).
Arhitektura gruče Kubernetes HA, ustvarjene s kubeadm
Podrobnosti o izvedbi najdete v . Ta funkcija je bila res dolgo pričakovana: alfa različica je bila pričakovana že v K8s 1.9, vendar se je pojavila šele zdaj.
API
Ekipa apply in na splošno deklarativno upravljanje objektov z dne kubectl v apiserverju. Razvijalci sami svojo odločitev na kratko razložijo s tem kubectl apply - temeljni del dela s konfiguracijami v Kubernetesu, vendar je "poln hroščev in ga je težko popraviti," zato je treba to funkcionalnost vrniti v normalno stanje in prenesti v nadzorno ravnino. Preprosti in jasni primeri težav, ki obstajajo danes:
Podrobnosti o izvedbi so v . Trenutna pripravljenost je alfa (napredovanje v beta je načrtovano za naslednjo izdajo Kubernetes).
Na voljo v različici alfa z uporabo sheme OpenAPI v3 za ustvarjanje in objavljanje dokumentacije OpenAPI za CustomResources (CR), ki se uporablja za preverjanje (na strani strežnika) uporabniško definiranih virov K8s (CustomResourceDefinition, CRD). Objava OpenAPI za CRD omogoča odjemalcem (npr. kubectl) izvede preverjanje na vaši strani (znotraj kubectl create и kubectl apply) in izda dokumentacijo po shemi (kubectl explain). Podrobnosti - v .
Že obstoječi dnevniki z zastavo O_APPEND (vendar ne O_TRUNC), da bi se izognili izgubi dnevnikov v nekaterih situacijah in zaradi priročnosti prirezovanja dnevnikov z zunanjimi pripomočki za rotacijo.
Tudi v kontekstu API-ja Kubernetes je mogoče opaziti, da v PodSandbox и PodSandboxStatus polje runtime_handler za beleženje informacij o RuntimeClass v pod (več o tem v besedilu o , kjer se je ta razred pojavil kot različica alfa), in v Admission Webhooks sposobnost določiti, katere različice AdmissionReview podpirajo. Končno so zdaj pravila Admission Webhooks obseg njihove uporabe v imenskih prostorih in ogrodjih gruč.
Shranjevanje
, ki je imel od izdaje status beta , stabilen (GA): ta vrata funkcije niso več onemogočena in bodo odstranjena v Kubernetesu 1.17.
z uporabo okoljskih spremenljivk, imenovanih (na primer ime sklopa) za imena imenikov, nameščenih kot , je bil razvit - v obliki novega področja subPathExpr, ki se zdaj uporablja za določitev želenega imena imenika. Funkcija se je sprva pojavila v Kubernetes 1.11, vendar je za 1.14 ostala v statusu različice alfa.
Tako kot pri prejšnji izdaji Kubernetes, je uvedenih veliko pomembnih sprememb za CSI (Container Storage Interface), ki se aktivno razvija:
CSI
Na voljo (kot del alfa različice) spreminjanje velikosti za nosilce CSI. Če ga želite uporabiti, boste morali omogočiti imenovana vrata funkcije ExpandCSIVolumes, kot tudi prisotnost podpore za to operacijo v določenem gonilniku CSI.
Še ena funkcija za CSI v različici alfa - nanašajte se neposredno (tj. brez uporabe PV/PVC) na prostornine CSI znotraj specifikacije stroka. to odpravlja omejitev uporabe CSI kot izključno oddaljenega shranjevanja podatkov, ki jim odpira vrata v svet . Za uporabo () mora biti omogočeno CSIInlineVolume značilnost vrat.
Napredek je bil dosežen tudi pri »notranjih delih« Kubernetesa, povezanih s CSI, ki niso tako vidni končnim uporabnikom (sistemskim skrbnikom) ... Trenutno so razvijalci prisiljeni podpirati dve različici vsakega vtičnika za shranjevanje: eno - »v old way«, znotraj kodne baze K8s (in -tree), drugi pa kot del novega CSI (več o tem preberite na primer v ). To povzroča razumljive nevšečnosti, ki jih je treba obravnavati, ko se CSI sam stabilizira. API-ja notranjih (v drevesu) vtičnikov ni mogoče preprosto opustiti zaradi .
Vse to je pripeljalo do dejstva, da je različica alfa dosegla notranja koda vtičnika, implementiran kot in-tree, v vtičnike CSI, zaradi česar bodo skrbi razvijalcev zmanjšane na podporo eni različici njihovih vtičnikov, združljivost s starimi API-ji pa bo ostala in jih je mogoče razglasiti za zastarele v običajnem scenariju. Pričakuje se, da bodo do naslednje izdaje Kubernetesa (1.15) vsi vtičniki ponudnikov oblakov preseljeni, izvedba bo prejela status beta in bo privzeto aktivirana v namestitvah K8s. Za podrobnosti glejte . Ta selitev je povzročila tudi od omejitev količine, ki jih določijo določeni ponudniki oblakov (AWS, Azure, GCE, Cinder).
Dodatno podpora za blok naprave s CSI (CSIBlockVolume) na različico beta.
Vozlišča/Kubelet
Predstavljena alfa različica v Kubeletu, namenjen za vrni meritve o ključnih virih. Na splošno, če je prej Kubelet prejemal statistične podatke o uporabi vsebnika od cAdvisorja, zdaj ti podatki prihajajo iz izvajalnega okolja vsebnika prek CRI (Container Runtime Interface), vendar je ohranjena tudi združljivost za delo s starejšimi različicami Dockerja. Prej so bili statistični podatki, zbrani v Kubeletu, poslani prek API-ja REST, zdaj pa končna točka, ki se nahaja na /metrics/resource/v1alpha1. Dolgoročna strategija razvijalcev je zmanjšati nabor meritev, ki jih ponuja Kubelet. Mimogrede, te meritve same ne »osnovne meritve«, ampak »metrike virov« in so opisane kot »prvorazredni viri, kot sta procesor in pomnilnik«.
Zelo zanimiv odtenek: kljub jasni prednosti končne točke gRPC v primerjavi z različnimi primeri uporabe formata Prometheus (glejte rezultat enega od spodnjih meril), so avtorji dali prednost besedilnemu formatu Prometheusa zaradi jasnega vodstva tega sistema spremljanja v skupnosti.
»gRPC ni združljiv z večjimi cevovodi za spremljanje. Končna točka bo uporabna samo za dostavo metrik strežniku Metrics Server ali komponent za spremljanje, ki se neposredno integrirajo z njim. Zmogljivost zapisa besedila Prometheus pri uporabi predpomnjenja v Metrics Server dovolj dobro da imamo raje Prometheus kot gRPC glede na široko sprejetje Prometheusa v skupnosti. Ko bo format OpenMetrics postal stabilnejši, se bomo lahko približali zmogljivosti gRPC s formatom, ki temelji na proto.”
Eden od primerjalnih preizkusov učinkovitosti uporabe formatov gRPC in Prometheus v novi končni točki Kubelet za meritve. Več grafov in drugih podrobnosti najdete v .
Med drugimi spremembami:
- Kubelet zdaj (enkrat) vsebnike v neznanem stanju pred ponovnim zagonom in operacijami brisanja.
- Pri uporabi zdaj v zagonski vsebnik enake informacije kot pri običajni posodi.
- kubelet
usageNanoCoresod ponudnika statistike CRI ter za vozlišča in vsebnike v sistemu Windows statistika omrežja. - Podatki o operacijskem sistemu in arhitekturi so zdaj zabeleženi v oznakah
kubernetes.io/osиkubernetes.io/archObjekti vozlišč (preneseni iz beta v GA). - Zmožnost določitve določene sistemske uporabniške skupine za vsebnike v sklopu (
RunAsGroup, se je pojavil v ) pred različico beta (privzeto omogočeno). - du in poiščite uporabljeno v cAdvisor, on Go implementacija.
CLI
V cli-runtime in kubectl -k zastavica za integracijo z (mimogrede, njegov razvoj se zdaj izvaja v ločenem repozitoriju), tj. za obdelavo dodatnih datotek YAML iz posebnih imenikov za prilagajanje (za podrobnosti o njihovi uporabi glejte ):
Primer preproste uporabe datoteke (možna je bolj zapletena uporaba kustomize znotraj )
Poleg tega:
- nova ekipa
kubectl create cronjob, katerega ime govori samo zase. - В
kubectl logszdaj lahko zastave-f(--followza pretakanje dnevnikov) in-l(--selectorza poizvedbo po oznaki). - kubectl kopirajte datoteke, izbrane z nadomestnim znakom.
- Za ekipo
kubectl waitzastava--allda izberete vse vire v imenskem prostoru navedene vrste vira.
Drugo
Naslednje zmogljivosti so prejele stabilen status (GA):
- , ki se uporablja v specifikaciji stroka za opredelitev dodatnih pogojev, ki se upoštevajo pri pripravljenosti stroka;
- Podpora za velike strani (vrata funkcij, imenovana );
- ;
- PriorityClass API .
Druge spremembe, uvedene v Kubernetes 1.14:
- Privzeti pravilnik RBAC ne dovoljuje več dostopa do API-ja
discoveryиaccess-reviewuporabniki brez avtentikacije (nepreverjeno). - Uradna podpora za CoreDNS Samo za Linux, torej pri uporabi kubeadm za njegovo uvajanje (CoreDNS) v gruči, se morajo vozlišča izvajati samo v Linuxu (za to omejitev se uporabljajo izbirniki vozlišč).
- Privzeta konfiguracija CoreDNS je zdaj namesto proxyja. Tudi v CoreDNS readinessProbe, ki preprečuje uravnoteženje obremenitve na ustreznih (nepripravljenih za uporabo) podih.
- V kubeadmu, na fazah
initaliupload-certs, naložite potrdila, potrebna za povezavo nove nadzorne ravnine s skrivnostjo kubeadm-certs (uporabite zastavico--experimental-upload-certs). - Pojavila se je alfa različica za namestitev sistema Windows gMSA (Group Managed Service Account) - posebni računi v imeniku Active Directory, ki jih lahko uporabljajo tudi kontejnerji.
- Za G.C.E. Šifriranje mTLS med etcd in kube-apiserver.
- Posodobitve uporabljene/odvisne programske opreme: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, podpora za Docker 18.09 v kubeadm in najmanjša podprta različica API-ja Docker je zdaj 1.26.
PS
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «".
Vir: www.habr.com