Kubernetes 1.14: ringkesan saka inovasi utama

bengi iki bakal njupuk Panggonan rilis sabanjure Kubernetes - 1.14. Miturut tradhisi sing wis dikembangake kanggo blog kita, kita ngomong babagan owah-owahan utama ing versi anyar produk Open Source sing apik iki.

Informasi sing digunakake kanggo nyiapake materi iki dijupuk saka Tabel nelusuri paningkatan Kubernetes, CHANGELOG-1.14 lan masalah sing gegandhengan, narik panjalukan, Kubernetes Enhancement Proposals (KEP).

Ayo dadi miwiti karo introduksi penting saka SIG cluster-lifecycle: klompok failover dinamis Kubernetes (utawa luwih tepat, panyebaran HA sing dadi tuan rumah dhewe) saiki sampeyan bisa nggawe nggunakake perintah akrab (ing konteks kluster simpul tunggal). kubeadm (init и join). Ing cendhak, kanggo iki:

• sertifikat sing digunakake dening kluster ditransfer menyang rahasia;
• kanggo kamungkinan nggunakake kluster etcd nang kluster K8s (i.e. nyisihaken saka katergantungan external sadurunge ana) etcd-operator;
• Dokumen setelan sing disaranake kanggo imbangan beban eksternal sing nyedhiyakake konfigurasi fault-tolerant (ing mangsa ngarep direncanakake kanggo ngilangi katergantungan iki, nanging ora ing tahap iki).

Arsitektur kluster Kubernetes HA digawe nganggo kubeadm

Rincian implementasine bisa ditemokake ing proposal desain. Fitur iki pancene ditunggu-tunggu: versi alpha wis samesthine bali ing K8s 1.9, nanging mung katon saiki.

API

tim apply lan umume manajemen obyek deklaratif liwati saka kubectl ing apiserver. Para pangembang dhewe nerangake kanthi ringkes keputusane kanthi ujar kasebut kubectl apply - bagean dhasar nggarap konfigurasi ing Kubernetes, Nanging, "kebak kewan omo lan angel didandani," lan mulane fungsi iki kudu digawa bali menyang normal lan ditransfer menyang bidang kontrol. Conto prasaja lan jelas masalah sing ana saiki:

Rincian babagan implementasine ana ing KAB. Kesiapan saiki yaiku alpha (promosi menyang beta direncanakake kanggo rilis Kubernetes sabanjure).

Digawe kasedhiya ing versi alpha kesempatan nggunakake skema OpenAPI v3 kanggo nggawe lan nerbitake dokumentasi OpenAPI kanggo CustomResources (CR) digunakake kanggo validasi (server-sisih) K8s sumber daya user-ditetepake (CustomResourceDefinition, CRD). Nerbitake OpenAPI kanggo CRD ngidini klien (contone. kubectl) nindakake validasi ing sisih sampeyan (ing kubectl create и kubectl apply) lan ngetokake dokumentasi miturut skema (kubectl explain). Rincian - ing KAB.

Log sing wis ana saiki mbukak karo gendera O_APPEND (nanging ora O_TRUNC) kanggo ngindhari mundhut log ing sawetara kahanan lan supaya gampang ngethok log kanthi utilitas eksternal kanggo rotasi.

Uga ing konteks API Kubernetes, bisa dicathet yen ing PodSandbox и PodSandboxStatus ditambahake lapangan runtime_handler kanggo ngrekam informasi babagan RuntimeClass ing pod (waca liyane babagan ing teks babagan Kubernetes 1.12 release, ngendi kelas iki muncul minangka versi alpha), lan ing Diakoni Webhooks dileksanakake kemampuan kanggo nemtokake versi AdmissionReview padha ndhukung. Pungkasan, aturan Admission Webhooks saiki bisa diwatesi ombone sing nggunakake dening namespaces lan frameworks cluster.

Lumbung

PersistentLocalVolumes, sing nduweni status beta wiwit dirilis K8s 1.10, ngumumake stabil (GA): gapura fitur iki ora dipatèni lan bakal dibusak ing Kubernetes 1.17.

Opportunity nggunakake variabel lingkungan disebut API mudhun (contone, jeneng pod) kanggo jeneng direktori dipasang minangka subPath, dikembangake - ing wangun lapangan anyar subPathExpr, sing saiki digunakake kanggo nemtokake jeneng direktori sing dikarepake. Fitur kasebut wiwitane muncul ing Kubernetes 1.11, nanging kanggo 1.14 tetep ing status versi alpha.

Kaya rilis Kubernetes sadurunge, akeh owah-owahan penting sing dienalake kanggo CSI (Container Storage Interface) sing aktif berkembang.

CSI

Dadi kasedhiya (minangka bagéan saka versi alpha) dhukungan ngowahi ukuran kanggo volume CSI. Kanggo nggunakake, sampeyan kudu ngaktifake gerbang fitur sing diarani ExpandCSIVolumes, uga ana dhukungan kanggo operasi iki ing driver CSI tartamtu.

Fitur liyane kanggo CSI ing versi alpha - kesempatan deleng langsung (i.e. tanpa nggunakake PV/PVC) kanggo volume CSI ing specification pod. Iki mbusak watesan ing nggunakake CSI minangka panyimpenan data eksklusif remot, mbukak lawang kanggo donya kanggo wong-wong mau volume ephemeral lokal. Kanggo nggunakake (conto saka dokumentasi) kudu diaktifake CSIInlineVolume gapura fitur.

Ana uga kemajuan ing "internal" Kubernetes sing ana gandhengane karo CSI, sing ora katon kanggo pangguna pungkasan (administrator sistem) ... Saiki, pangembang dipeksa ndhukung rong versi saben plugin panyimpenan: siji - "ing cara lawas", nang K8s codebase (ing -wit), lan liya - minangka bagéan saka CSI anyar (waca liyane babagan, contone, ing kene). Iki nyebabake inconveniences dingerteni sing kudu ditangani minangka CSI dhewe stabil. Sampeyan ora bisa mung nolak API plugin internal (ing-wit) amarga kawicaksanan Kubernetes cocog.

Kabeh iki mimpin kanggo kasunyatan sing versi alpha tekan proses migrasi kode plugin internal, dileksanakake minangka in-tree, ing plugin CSI, amarga kuwatir para pangembang bakal suda kanggo ndhukung siji versi plugin, lan kompatibilitas karo API lawas bakal tetep lan bisa diumumake lungse ing skenario biasa. Dikarepake yen ing release sabanjure Kubernetes (1.15) kabeh plugin panyedhiya maya bakal migrasi, implementasine bakal nampa status beta lan bakal diaktifake ing instalasi K8s minangka standar. Kanggo rincian, ndeleng proposal desain. Migrasi iki uga nyebabake kegagalan saka watesan volume ditetepake dening panyedhiya maya tartamtu (AWS, Azure, GCE, Cinder).

Kajaba iku, dhukungan kanggo piranti pamblokiran kanthi CSI (CSIBlockVolume) ditransfer kanggo versi beta.

Node/Kubelet

Versi Alpha diwenehi titik pungkasan anyar ing Kubelet, dirancang kanggo bali metrik ing sumber daya utama. Umumé, yen sadurunge Kubelet nampa statistik babagan panggunaan wadhah saka cAdvisor, saiki data iki asale saka lingkungan runtime wadah liwat CRI (Container Runtime Interface), nanging kompatibilitas kanggo nggarap versi lawas saka Docker uga dilestarekake. Sadurunge, statistik sing diklumpukake ing Kubelet dikirim liwat REST API, nanging saiki titik pungkasan sing ana ing /metrics/resource/v1alpha1. Strategi jangka panjang para pangembang punika yaiku kanggo nyilikake set metrik sing diwenehake dening Kubelet. Miturut cara, metrik iki dhewe saiki padha nelpon ora "metrik inti", nanging "metrik sumber daya", lan diterangake minangka "sumber daya kelas kapisan, kayata cpu, lan memori".

Nuansa sing menarik banget: sanajan kauntungan kinerja sing jelas saka titik pungkasan gRPC dibandhingake karo macem-macem kasus nggunakake format Prometheus (ndeleng asil saka salah sawijining pathokan ing ngisor iki), penulis luwih milih format teks Prometheus amarga kepemimpinan sing jelas saka sistem pemantauan iki ing masyarakat.

"gRPC ora kompatibel karo pipa pemantauan utama. Endpoint mung bakal migunani kanggo ngirim metrik menyang Metrics Server utawa ngawasi komponen sing langsung nggabungake. Kinerja format teks Prometheus nalika nggunakake cache ing Server Metrik cukup apik supaya kita luwih seneng Prometheus tinimbang gRPC amarga adopsi Prometheus sing nyebar ing masyarakat. Sawise format OpenMetrics dadi luwih stabil, kita bakal bisa nyedhaki kinerja gRPC kanthi format basis proto.

Salah sawijining tes kinerja komparatif nggunakake format gRPC lan Prometheus ing titik pungkasan Kubelet anyar kanggo metrik. Grafik liyane lan rincian liyane bisa ditemokake ing KAB.

Antarane owah-owahan liyane:

• Kubelet saiki (sepisan) nyoba mandheg wadhah ing negara sing ora dingerteni sadurunge miwiti maneh lan mbusak operasi.
• Nalika nggunakake PodPresets saiki menyang wadhah init ditambahake informasi sing padha kanggo wadhah biasa.
• kubelet wiwit nggunakake usageNanoCores saka panyedhiya statistik CRI, lan kanggo simpul lan wadhah ing Windows ditambahake statistik jaringan.
• Informasi sistem operasi lan arsitektur saiki dicathet ing label kubernetes.io/os и kubernetes.io/arch Objek simpul (ditransfer saka beta menyang GA).
• Kemampuan kanggo nemtokake klompok pangguna sistem tartamtu kanggo wadhah ing pod (RunAsGroup, muncul ing K8s 1.11) majeng sadurunge beta (diaktifake kanthi gawan).
• du lan golek digunakake ing cAdvisor, diganti ing implementasine Go.

CLI

Ing cli-runtime lan kubectl ditambahake -k flag kanggo integrasi karo ngatur (kanthi cara, pangembangane saiki ditindakake ing gudang sing kapisah), yaiku. kanggo ngolah file YAML tambahan saka direktori kustomisasi khusus (kanggo rincian babagan nggunakake, deleng KAB):

Conto panggunaan file sing prasaja kustomisasi (aplikasi kustomize sing luwih rumit bisa ditindakake ing overlay)

Kajaba iku:

• Ditambahake tim anyar kubectl create cronjob, sing jenenge ngomong dhewe.
• В kubectl logs saiki sampeyan bisa gabungke gendéra -f (--follow kanggo log streaming) lan -l (--selector kanggo pitakon label).
• kubectl mulang nyalin file sing dipilih dening kertu alam bébas.
• Kanggo tim kubectl wait ditambahake gendera --all kanggo milih kabeh sumber daya ing namespace saka jinis sumber tartamtu.

Liyane

Kapabilitas ing ngisor iki wis nampa status stabil (GA):

• ReadinessGate, digunakake ing specification pod kanggo netepake kondisi tambahan dijupuk menyang akun ing siyap pod kang;
• Dhukungan kanggo kaca gedhe (gerbang fitur disebut HugePages);
• CustomPodDNS;
• PriorityClass API Pod Prioritas & Preemption.

Owah-owahan liyane ing Kubernetes 1.14:

• Kabijakan RBAC standar ora ngidini akses API maneh discovery и access-review pangguna tanpa otentikasi (ora sah).
• Dhukungan CoreDNS resmi mesthekake Mung Linux, mula nalika nggunakake kubeadm kanggo nyebarake (CoreDNS) ing kluster, node mung kudu mbukak ing Linux (nodeSelectors digunakake kanggo watesan iki).
• Konfigurasi CoreDNS standar saiki nggunakake plugin maju tinimbang proxy. Uga, ing CoreDNS ditambahake ReadinessProbe, sing nyegah imbangan beban ing polong sing cocog (ora siap kanggo layanan).
• Ing kubeadm, ing fase init utawa upload-certs, dadi bisa mbukak sertifikat sing dibutuhake kanggo nyambungake kontrol-pesawat anyar menyang rahasia kubeadm-certs (gunakake gendera --experimental-upload-certs).
• Versi alpha wis muncul kanggo instalasi Windows dhukungan gMSA (Group Managed Service Account) - akun khusus ing Active Directory sing uga bisa digunakake dening wadhah.
• Kanggo G.C.E. diaktifake enkripsi mTLS antarane etcd lan kube-apiserver.
• Nganyari ing piranti lunak sing digunakake / gumantung: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, dhukungan Docker 18.09 ing kubeadm, lan versi Docker API sing didhukung minimal saiki 1.26.

PS

Waca uga ing blog kita:

• «Kubernetes 1.13: ringkesan saka inovasi utama";
• «Kubernetes 1.12: ringkesan saka inovasi utama";
• «Kubernetes 1.11: ringkesan saka inovasi utama";
• «Kubernetes 1.10: ringkesan saka inovasi utama".

Source: www.habr.com