Kubernetes 1.14: pangkalahatang-ideya ng mga pangunahing inobasyon

Ngayong gabi magaganap susunod na paglabas ng Kubernetes - 1.14. Ayon sa tradisyon na binuo para sa aming blog, pinag-uusapan natin ang mga pangunahing pagbabago sa bagong bersyon ng kahanga-hangang produktong Open Source na ito.

Ang impormasyong ginamit sa paghahanda ng materyal na ito ay kinuha mula sa Mga talahanayan ng pagsubaybay sa mga pagpapahusay ng Kubernetes, CHANGELOG-1.14 at mga kaugnay na isyu, pull request, Kubernetes Enhancement Proposals (KEP).

Magsimula tayo sa isang mahalagang panimula mula sa SIG cluster-lifecycle: mga dynamic na failover cluster Kubernetes (o sa mas tumpak, self-hosted HA deployment) ay ngayon maaaring malikha gamit ang pamilyar (sa konteksto ng mga single-node cluster) na mga utos kubeadm (init и join). Sa madaling salita, para dito:

• ang mga sertipiko na ginamit ng kumpol ay inililipat sa mga lihim;
• para sa posibilidad ng paggamit ng etcd cluster sa loob ng K8s cluster (ibig sabihin, alisin ang dating umiiral na external dependency) etcd-operator;
• Idokumento ang mga inirekumendang setting para sa isang external na load balancer na nagbibigay ng fault-tolerant na configuration (sa hinaharap ay pinlano na alisin ang dependency na ito, ngunit hindi sa yugtong ito).

Arkitektura ng isang Kubernetes HA cluster na ginawa gamit ang kubeadm

Ang mga detalye ng pagpapatupad ay matatagpuan sa panukalang disenyo. Ang tampok na ito ay talagang pinakahihintay: ang alpha na bersyon ay inaasahan pabalik sa K8s 1.9, ngunit ngayon lamang lumitaw.

API

Koponan apply at sa pangkalahatan deklaratibong pamamahala ng bagay pumasa ng kubectl sa apiserver. Ang mga nag-develop mismo ay maikling nagpapaliwanag ng kanilang desisyon sa pamamagitan ng pagsasabi nito kubectl apply - isang pangunahing bahagi ng pagtatrabaho sa mga configuration sa Kubernetes, gayunpaman, "ito ay puno ng mga bug at mahirap ayusin," at samakatuwid ang functionality na ito ay kailangang ibalik sa normal at ilipat sa control plane. Simple at malinaw na mga halimbawa ng mga problema na umiiral ngayon:

Ang mga detalye tungkol sa pagpapatupad ay nasa KEP. Ang kasalukuyang kahandaan ay alpha (pinlano ang promosyon sa beta para sa susunod na paglabas ng Kubernetes).

Ginawang magagamit sa alpha na bersyon pagkakataon gamit ang OpenAPI v3 scheme para sa paggawa at pag-publish ng dokumentasyon ng OpenAPI para sa CustomResources (CR) na ginamit upang patunayan ang (server-side) na mga mapagkukunang tinukoy ng gumagamit ng K8 (CustomResourceDefinition, CRD). Ang pag-publish ng OpenAPI para sa CRD ay nagbibigay-daan sa mga kliyente (hal. kubectl) magsagawa ng pagpapatunay sa iyong panig (sa loob kubectl create и kubectl apply) at mag-isyu ng dokumentasyon ayon sa scheme (kubectl explain). Mga Detalye - sa KEP.

Mga dati nang log ngayon ay nagbubukas may bandila O_APPEND (hindi O_TRUNC) upang maiwasan ang pagkawala ng mga log sa ilang mga sitwasyon at para sa kaginhawaan ng pagputol ng mga log gamit ang mga panlabas na kagamitan para sa pag-ikot.

Gayundin sa konteksto ng Kubernetes API, mapapansin na sa PodSandbox и PodSandboxStatus idinagdag patlang runtime_handler upang magtala ng impormasyon tungkol sa RuntimeClass sa pod (basahin ang higit pa tungkol dito sa teksto tungkol sa Paglabas ng Kubernetes 1.12, kung saan lumabas ang klase na ito bilang alpha version), at sa Admission Webhooks ipinatupad kakayahang matukoy kung aling mga bersyon AdmissionReview sinusuportahan nila. Sa wakas, ang mga panuntunan sa Admission Webhooks ay ngayon na maaaring limitado ang lawak ng kanilang paggamit ng mga namespace at cluster framework.

Imbakan

PersistentLocalVolumes, na may beta status mula noong inilabas K8s 1.10, inihayag stable (GA): hindi na naka-disable ang feature gate na ito at aalisin sa Kubernetes 1.17.

Pagkakataon gamit ang mga variable ng kapaligiran na tinatawag na Pababang API (halimbawa, ang pod name) para sa mga pangalan ng mga direktoryo na naka-mount bilang subPath, ay binuo - sa anyo ng isang bagong larangan subPathExpr, na ngayon ay ginagamit upang matukoy ang nais na pangalan ng direktoryo. Ang feature ay unang lumabas sa Kubernetes 1.11, ngunit para sa 1.14 ay nanatili ito sa alpha version status.

Tulad ng nakaraang paglabas ng Kubernetes, maraming makabuluhang pagbabago ang ipinakilala para sa aktibong pagbuo ng CSI (Container Storage Interface):

CSI

Naging available (bilang bahagi ng alpha version) sinusuportahan pagbabago ng laki para sa mga volume ng CSI. Upang magamit ito kakailanganin mong paganahin ang tampok na gate na tinatawag ExpandCSIVolumes, pati na rin ang pagkakaroon ng suporta para sa operasyong ito sa isang partikular na driver ng CSI.

Isa pang tampok para sa CSI sa alpha na bersyon - pagkakataon direktang sumangguni (i.e. nang hindi gumagamit ng PV/PVC) sa mga volume ng CSI sa loob ng detalye ng pod. Ito inaalis ang paghihigpit sa paggamit ng CSI bilang eksklusibong malayuang imbakan ng data, nagbubukas ng mga pinto sa mundo para sa kanila lokal na ephemeral volume. Para sa paggamit (halimbawa mula sa dokumentasyon) ay dapat na pinagana CSIInlineVolume tampok na gate.

Nagkaroon din ng pag-unlad sa "internals" ng Kubernetes na may kaugnayan sa CSI, na hindi masyadong nakikita ng mga end user (system administrator) ... Sa kasalukuyan, ang mga developer ay napipilitang suportahan ang dalawang bersyon ng bawat storage plugin: isa - "sa old way", sa loob ng K8s codebase (in -tree), at ang pangalawa - bilang bahagi ng bagong CSI (magbasa nang higit pa tungkol dito, halimbawa, sa dito). Nagdudulot ito ng mga naiintindihan na abala na kailangang matugunan habang ang CSI mismo ay nagpapatatag. Hindi posibleng i-deprecate na lang ang API ng mga internal (in-tree) na plugin dahil sa nauugnay na patakaran ng Kubernetes.

Ang lahat ng ito ay humantong sa ang katunayan na ang alpha na bersyon ay umabot proseso ng migrasyon panloob na plugin code, ipinatupad bilang in-tree, sa mga plugin ng CSI, salamat sa kung saan ang mga alalahanin ng mga developer ay mababawasan sa pagsuporta sa isang bersyon ng kanilang mga plugin, at mananatili ang pagiging tugma sa mga lumang API at maaari silang ideklarang lipas na sa karaniwang sitwasyon. Inaasahan na sa susunod na release ng Kubernetes (1.15) lahat ng cloud provider plugin ay maililipat, ang pagpapatupad ay makakatanggap ng beta status at maa-activate sa K8s installation bilang default. Para sa mga detalye, tingnan panukalang disenyo. Nagbunga din ang migrasyon na ito pagkabigo mula sa mga limitasyon ng volume na tinukoy ng mga partikular na provider ng cloud (AWS, Azure, GCE, Cinder).

Bukod pa rito, suporta para sa mga block device na may CSI (CSIBlockVolume) inilipat sa beta na bersyon.

Mga node/Kubelet

Iniharap ang bersyon ng Alpha bagong endpoint sa Kubelet, dinisenyo para sa ibalik ang mga sukatan sa mga pangunahing mapagkukunan. Sa pangkalahatan, kung dati ay nakatanggap ang Kubelet ng mga istatistika sa paggamit ng container mula sa cAdvisor, ngayon ang data na ito ay mula sa container runtime environment sa pamamagitan ng CRI (Container Runtime Interface), ngunit ang compatibility para sa pagtatrabaho sa mga mas lumang bersyon ng Docker ay pinapanatili din. Dati, ang mga istatistikang nakolekta sa Kubelet ay ipinadala sa pamamagitan ng REST API, ngunit ngayon ay isang endpoint na matatagpuan sa /metrics/resource/v1alpha1. Pangmatagalang diskarte ng mga developer ay ay upang mabawasan ang hanay ng mga sukatan na ibinigay ng Kubelet. Siyanga pala, ang mga sukatan na ito mismo ngayon tumawag sila hindi "mga pangunahing sukatan", ngunit "mga sukatan ng mapagkukunan", at inilalarawan bilang "mga mapagkukunan sa unang klase, gaya ng cpu, at memorya."

Isang napaka-kagiliw-giliw na nuance: sa kabila ng malinaw na performance advantage ng gRPC endpoint kumpara sa iba't ibang kaso ng paggamit ng Prometheus format (tingnan ang resulta ng isa sa mga benchmark sa ibaba), ginusto ng mga may-akda ang format ng teksto ng Prometheus dahil sa malinaw na pamumuno ng sistemang ito ng pagsubaybay sa komunidad.

"Ang gRPC ay hindi tugma sa mga pangunahing pipeline ng pagsubaybay. Magiging kapaki-pakinabang lang ang Endpoint para sa paghahatid ng mga sukatan sa Server ng Sukatan o mga bahagi ng pagsubaybay na direktang sumasama dito. Pagganap ng format ng teksto ng Prometheus kapag gumagamit ng caching sa Server ng Sukatan sapat na para mas gusto natin ang Prometheus kaysa sa gRPC dahil sa malawakang pag-aampon ng Prometheus sa komunidad. Kapag naging mas matatag na ang format ng OpenMetrics, magagawa nating lapitan ang pagganap ng gRPC gamit ang proto-based na format."

Isa sa mga comparative performance test ng paggamit ng gRPC at Prometheus na mga format sa bagong Kubelet endpoint para sa mga sukatan. Higit pang mga graph at iba pang mga detalye ang makikita sa KEP.

Kabilang sa iba pang mga pagbabago:

• Kubelet ngayon (isang beses) sinusubukang huminto mga container sa hindi kilalang estado bago i-restart at tanggalin ang mga operasyon.
• Kapag ginagamit ang PodPresets ngayon sa lalagyan ng init Ay dinagdag ang parehong impormasyon tulad ng para sa isang regular na lalagyan.
• kubelet nagsimulang gumamit usageNanoCores mula sa provider ng istatistika ng CRI, at para sa mga node at container sa Windows idinagdag istatistika ng network.
• Ang impormasyon ng operating system at arkitektura ay naitala na ngayon sa mga label kubernetes.io/os и kubernetes.io/arch Mga bagay sa node (inilipat mula beta sa GA).
• Kakayahang tukuyin ang isang partikular na pangkat ng gumagamit ng system para sa mga lalagyan sa isang pod (RunAsGroup, lumabas sa K8s 1.11) advanced bago ang beta (pinagana bilang default).
• du and find ginamit sa cAdvisor, pinalitan sa pagpapatupad ng Go.

CLI

Sa cli-runtime at kubectl dagdag pa -k flag para sa pagsasama sa i-customize (sa pamamagitan ng paraan, ang pag-unlad nito ay isinasagawa na ngayon sa isang hiwalay na imbakan), i.e. upang iproseso ang mga karagdagang YAML file mula sa mga espesyal na direktoryo ng kustomization (para sa mga detalye sa paggamit ng mga ito, tingnan ang KEP):

Halimbawa ng simpleng paggamit ng file pagpapasadya (isang mas kumplikadong aplikasyon ng kustomize ay posible sa loob mga overlay)

Bilang karagdagan:

• Idinagdag bagong team kubectl create cronjob, na ang pangalan ay nagsasalita para sa sarili nito.
• В kubectl logs ngayon kaya mo na upang pagsamahin mga watawat -f (--follow para sa streaming logs) at -l (--selector para sa query sa label).
• kubectl itinuro kopyahin ang mga file na pinili ng wild card.
• Sa team kubectl wait idinagdag bandila --all upang piliin ang lahat ng mga mapagkukunan sa namespace ng tinukoy na uri ng mapagkukunan.

Mga iba

Ang mga sumusunod na kakayahan ay nakatanggap ng stable (GA) status:

• ReadinessGate, ginagamit sa detalye ng pod upang tukuyin ang mga karagdagang kundisyon na isinasaalang-alang sa kahandaan ng pod;
• Suporta para sa malalaking pahina (tinatawag na gate ng tampok HugePages);
• CustomPodDNS;
• PriorityClass API Priyoridad at Preemption ng Pod.

Iba pang mga pagbabago na ipinakilala sa Kubernetes 1.14:

• Hindi na pinapayagan ng default na patakaran ng RBAC ang pag-access sa API discovery и access-review mga gumagamit nang walang pagpapatunay (hindi napatotohanan).
• Opisyal na suporta ng CoreDNS sinigurado Linux lang, kaya kapag gumagamit ng kubeadm para i-deploy ito (CoreDNS) sa isang cluster, dapat lang tumakbo ang mga node sa Linux (ang mga nodeSelectors ay ginagamit para sa limitasyong ito).
• Default na configuration ng CoreDNS ay ngayon gumagamit pasulong na plugin sa halip na proxy. Gayundin, sa CoreDNS idinagdag readinessProbe, na pumipigil sa pagbalanse ng load sa mga angkop (hindi handa para sa serbisyo) na mga pod.
• Sa kubeadm, sa mga phase init o upload-certs, naging posible i-load ang mga certificate na kinakailangan para ikonekta ang bagong control-plane sa kubeadm-certs secret (gamitin ang flag --experimental-upload-certs).
• Isang alpha na bersyon ang lumitaw para sa mga pag-install ng Windows suporta gMSA (Group Managed Service Account) - mga espesyal na account sa Active Directory na maaari ding gamitin ng mga container.
• Para sa G.C.E. activated mTLS encryption sa pagitan ng etcd at kube-apiserver.
• Mga update sa ginamit/umaasa na software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 na suporta sa kubeadm, at ang minimum na sinusuportahang bersyon ng Docker API ay 1.26 na ngayon.

PS

Basahin din sa aming blog:

• «Kubernetes 1.13: pangkalahatang-ideya ng mga pangunahing inobasyon";
• «Kubernetes 1.12: pangkalahatang-ideya ng mga pangunahing inobasyon";
• «Kubernetes 1.11: pangkalahatang-ideya ng mga pangunahing inobasyon";
• «Kubernetes 1.10: pangkalahatang-ideya ng mga pangunahing inobasyon'.

Pinagmulan: www.habr.com