Peuting ieu release salajengna tina Kubernetes - . Numutkeun tradisi anu dimekarkeun pikeun blog urang, urang ngobrol ngeunaan parobahan konci dina versi anyar produk Open Source éndah ieu.
Inpormasi anu dianggo pikeun nyiapkeun bahan ieu dicandak tina , jeung masalah patali, requests tarikan, Kubernetes Enhancement Usulan (KEP).
Hayu urang mimitian ku bubuka penting tina SIG cluster-lifecycle: klaster failover dinamis Kubernetes (atawa janten langkung tepat, deployments HA timer hosted) ayeuna ngagunakeun paréntah akrab (dina konteks klaster-titik tunggal). kubeadm (init и join). Pondokna, pikeun ieu:
- sertipikat dipaké ku klaster ditransferkeun ka Rahasia;
- pikeun kamungkinan ngagunakeun kluster etcd jero kluster K8s (ie meunang leupas tina kagumantungan éksternal saméméhna aya) ;
- Dokumén setélan anu disarankeun pikeun pangimbang beban éksternal anu nyayogikeun konfigurasi toleran-lepat (kahareupna direncanakeun pikeun ngaleungitkeun kagumantungan ieu, tapi henteu dina tahap ieu).
Arsitéktur klaster Kubernetes HA dijieun ku kubeadm
Rincian palaksanaan tiasa dipendakan dina . fitur ieu sabenerna lila-tunggu: versi alfa ieu diperkirakeun balik dina K8s 1.9, tapi ngan mucunghul ayeuna.
API
regu apply jeung umumna disebutkeun manajemén objék déklaratif ti kubectl dina apiserver. Pamekar sorangan ngajelaskeun sakeudeung kaputusanna ku nyarios éta kubectl apply - bagian dasar tina gawé bareng konfigurasi di Kubernetes, kumaha oge, "éta pinuh ku bug jeung hésé ngalereskeun," sarta ku kituna pungsi ieu kudu dibawa deui ka normal tur dipindahkeun ka pesawat kontrol. conto basajan tur jelas masalah anu aya kiwari:
Rincian ngeunaan palaksanaan aya dina . Kesiapan ayeuna nyaéta alfa (promosi ka béta direncanakeun pikeun sékrési Kubernetes salajengna).
Disadiakeun dina versi alfa ngagunakeun skéma OpenAPI v3 pikeun nyieun jeung medarkeun dokuméntasi OpenAPI pikeun CustomResources (CR) dipaké pikeun sangkan méré konfirmasi (server-sisi) K8s sumberdaya-diartikeun pamaké (CustomResourceDefinition, CRD). Publishing OpenAPI pikeun CRD ngamungkinkeun klien (misalna. kubectl) ngalakukeun validasi di sisi anjeun (dina kubectl create и kubectl apply) jeung ngaluarkeun dokuméntasi nurutkeun skéma (kubectl explain). Rincian - di .
Log anu tos aya kalawan bandéra O_APPEND (tapi henteu O_TRUNC) pikeun ngahindarkeun leungitna log dina sababaraha kaayaan sareng pikeun genah motong log kalayan utilitas éksternal pikeun rotasi.
Ogé dina konteks API Kubernetes, éta tiasa dicatet yén dina PodSandbox и PodSandboxStatus sawah runtime_handler pikeun ngarekam informasi ngeunaan RuntimeClass dina pod (baca langkung seueur ngeunaan éta dina téks ngeunaan , dimana kelas ieu muncul salaku versi alfa), sarta dina Webhooks Grendeng kamampuhan pikeun nangtukeun mana versi AdmissionReview aranjeunna ngarojong. Tungtungna, aturan Admission Webhooks ayeuna extent pamakéan maranéhanana ku namespaces na frameworks klaster.
Panyimpenan
, nu miboga status béta saprak release , stabil (GA): Gerbang fitur ieu henteu deui ditumpurkeun sareng bakal dihapus dina Kubernetes 1.17.
ngagunakeun variabel lingkungan disebut (Contona, ngaran pod) pikeun ngaran directories dipasang salaku , dikembangkeun - dina bentuk widang anyar subPathExpr, anu ayeuna dianggo pikeun nangtukeun nami diréktori anu dipikahoyong. Fitur ieu mimitina muncul dina Kubernetes 1.11, tapi pikeun 1.14 tetep dina status versi alfa.
Sapertos pelepasan Kubernetes sateuacana, seueur parobihan anu penting diwanohkeun pikeun CSI (Container Storage Interface) anu aktip berkembang.
CSI
Janten sayogi (salaku bagian tina versi alfa) ngarobah ukuran pikeun volume CSI. Pikeun ngagunakeun éta anjeun kedah ngaktipkeun gerbang fitur anu disebut ExpandCSIVolumes, kitu ogé ayana rojongan pikeun operasi ieu dina supir CSI husus.
Fitur séjén pikeun CSI dina versi alfa - rujuk langsung (nyaéta tanpa nganggo PV / PVC) kana volume CSI dina spésifikasi pod. Ieu ngaluarkeun larangan dina pamakéan CSI salaku gudang data éksklusif jauh, muka panto dunya pikeun aranjeunna . Pikeun pamakéan () kudu diaktipkeun CSIInlineVolume Gerbang fitur.
Aya ogé kamajuan dina "internals" Kubernetes patali jeung CSI, nu teu jadi katingali ku pamaké tungtung (administrator sistem) ... Ayeuna, pamekar kapaksa ngarojong dua versi unggal plugin gudang: hiji - "dina cara heubeul", jero K8s codebase (dina -tangkal), sarta kadua - salaku bagian tina CSI anyar (baca langkung seueur ngeunaan éta, contona, dina ). Ieu ngabalukarkeun inconveniences kaharti nu kudu kajawab sakumaha CSI sorangan stabilizes. Teu mungkin mun saukur deprecate API tina internal (dina-tangkal) plugins alatan .
Sadaya ieu nyababkeun kanyataan yén versi alfa ngahontal kode plugin internal, dilaksanakeun sakumaha dina-tangkal, dina plugins CSI, hatur nuhun nu worries of pamekar bakal diréduksi jadi ngarojong hiji versi plugins maranéhanana, sarta kasaluyuan jeung API heubeul bakal tetep sarta aranjeunna bisa dinyatakeun luntur dina skenario biasa. Ieu diperkirakeun yén ku release saterusna Kubernetes (1.15) kabéh plugins panyadia awan bakal hijrah, palaksanaan bakal nampa status béta sarta bakal diaktipkeun dina pamasangan K8s sacara standar. Pikeun detil, tingali . Migrasi ieu ogé nyababkeun ti wates volume ditetepkeun ku panyadia awan husus (AWS, Azure, GCE, Cinder).
Salaku tambahan, pangrojong pikeun alat blokir nganggo CSI (CSIBlockVolume) kana versi béta.
Nodes/Kubelet
Vérsi alfa dibere di Kubelet, dirancang pikeun balik metrics on sumberdaya konci. Sacara umum, upami sateuacana Kubelet nampi statistik ngeunaan panggunaan wadahna ti cAdvisor, ayeuna data ieu asalna tina lingkungan runtime wadahna via CRI (Container Runtime Interface), tapi kompatibilitas pikeun damel sareng versi Docker anu langkung lami ogé dilestarikan. Saméméhna, statistik nu dikumpulkeun dina Kubelet dikirim ngaliwatan REST API, tapi ayeuna titik tungtung lokasina di /metrics/resource/v1alpha1. Strategi jangka panjang pamekar nyaéta pikeun ngaleutikan set métrik anu disayogikeun ku Kubelet. Ku jalan kitu, metrics ieu sorangan sanes "métrik inti", tapi "métrik sumberdaya", sareng didadarkeun salaku "sumber daya kelas munggaran, sapertos CPU, sareng mémori".
Nuansa anu pikaresepeun pisan: sanaos kauntungan kinerja anu jelas tina titik tungtung gRPC dibandingkeun sareng sababaraha kasus ngagunakeun format Prometheus. (tingali hasil tina salah sahiji tolok ukur di handap), pangarang leuwih milih format téks Prometheus alatan kapamimpinan jelas sistem monitoring ieu di masarakat.
"gRPC henteu cocog sareng pipa ngawaskeun utama. Endpoint ngan bakal kapaké pikeun ngirimkeun métrik ka Métrik Server atanapi ngawaskeun komponén anu ngahijikeun langsung sareng éta. Kinerja format téks Prometheus nalika nganggo cache dina Metrics Server cukup alus pikeun urang leuwih milih Prometheus tinimbang gRPC dibere nyoko nyebar Prometheus di masarakat. Sakali format OpenMetrics janten langkung stabil, urang bakal tiasa ngadeukeutan kinerja gRPC ku format basis proto."
Salah sahiji tés kinerja komparatif ngagunakeun format gRPC sareng Prometheus dina titik akhir Kubelet anyar pikeun métrik. Langkung grafik sareng detil sanésna tiasa dipendakan dina .
Diantara parobahan séjénna:
- Kubelet ayeuna (hiji waktos) wadahna dina kaayaan anu teu dipikanyaho sateuacan balikan deui sareng ngahapus operasi.
- Ngagunakeun ayeuna kana wadah init inpormasi anu sami sareng wadah biasa.
- kubelet
usageNanoCoresti panyadia statistik CRI, sareng pikeun titik sareng wadah dina Windows statistik jaringan. - Inpormasi sistem operasi sareng arsitéktur ayeuna kacatet dina labél
kubernetes.io/osиkubernetes.io/archObyék titik (ditransfer tina béta ka GA). - Kamampuhan pikeun nangtukeun grup pangguna sistem khusus pikeun wadah dina pod (
RunAsGroup, mucunghul di ) sateuacan béta (diaktipkeun sacara standar). - du jeung manggihan dipaké dina cAdvisor, dina palaksanaan Go.
CLI
Dina cli-runtime sareng kubectl -k bandéra pikeun integrasi jeung (Ku jalan kitu, perkembangannya ayeuna dilumangsungkeun dina gudang misah), i.e. pikeun ngolah file YAML tambahan tina diréktori kustomisasi khusus (pikeun detil ngeunaan ngagunakeunana, tingali ):
Conto pamakéan file basajan (aplikasi kustomize nu leuwih kompleks mungkin dina )
Sajaba:
- tim anyar
kubectl create cronjob, anu ngaranna nyarita keur dirina. - В
kubectl logsayeuna anjeun tiasa bandéra-f(--followpikeun log streaming) jeung-l(--selectorpikeun pamundut labél). - kubectl salinan file dipilih ku kartu liar.
- Ka tim
kubectl waitbandéra--allpikeun milih sadaya sumber dina spasi ngaran tina tipe sumberdaya nu ditangtukeun.
nu lain
Kamampuhan di handap ieu parantos nampi status stabil (GA):
- , dipaké dina spésifikasi pod pikeun nangtukeun kaayaan tambahan dicokot kana akun dina kesiapan pod urang;
- Rojongan pikeun halaman ageung (gerbang fitur disebut );
- ;
- PriorityClass API .
Parobihan sanés anu diwanohkeun dina Kubernetes 1.14:
- Kabijakan RBAC standar henteu ngamungkinkeun aksés API deui
discoveryиaccess-reviewpamaké tanpa auténtikasi (teu dioténtikasi). - Rojongan CoreDNS resmi Linux wungkul, janten nalika nganggo kubeadm pikeun nyebarkeun éta (CoreDNS) dina kluster, node ngan ukur kedah dijalankeun dina Linux (nodeSelectors dianggo pikeun watesan ieu).
- Konfigurasi CoreDNS standar ayeuna tinimbang proxy. Ogé, dina CoreDNS readinessProbe, nu nyegah beban balancing on luyu (teu siap pikeun layanan) pods.
- Dina kubeadm, dina fase
initatawaupload-certs, muatkeun sertipikat anu dipikabutuh pikeun nyambungkeun pesawat kontrol anyar kana rusiah kubeadm-certs (nganggo bandéra--experimental-upload-certs). - Versi alfa parantos muncul pikeun pamasangan Windows gMSA (Group Managed Service Account) - akun husus dina Active Directory nu ogé bisa dipaké ku peti.
- Pikeun G.C.E. enkripsi mTLS antara etcd jeung kube-apiserver.
- Pembaruan dina parangkat lunak anu dianggo / gumantung: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, dukungan Docker 18.09 dina kubeadm, sareng versi Docker API anu dirojong minimum ayeuna 1.26.
PS
Baca ogé dina blog urang:
- «";
- «";
- «";
- «".
sumber: www.habr.com