Kubernetes 1.14: gambaran keseluruhan inovasi utama

Malam ini akan berlaku keluaran Kubernetes seterusnya - 1.14. Mengikut tradisi yang telah dibangunkan untuk blog kami, kami bercakap tentang perubahan utama dalam versi baharu produk Sumber Terbuka yang menarik ini.

Maklumat yang digunakan untuk menyediakan bahan ini diambil daripada Jadual penjejakan peningkatan Kubernetes, CHANGELOG-1.14 dan isu berkaitan, permintaan tarik, Cadangan Peningkatan Kubernetes (KEP).

Mari kita mulakan dengan pengenalan penting daripada kitaran hayat kluster SIG: kelompok failover dinamik Kubernetes (atau lebih tepat lagi, penempatan HA dihoskan sendiri) kini boleh dibuat menggunakan perintah biasa (dalam konteks kluster nod tunggal). kubeadm (init и join). Pendek kata, untuk ini:

• sijil yang digunakan oleh kluster dipindahkan ke rahsia;
• untuk kemungkinan menggunakan kluster etcd di dalam kluster K8s (iaitu menyingkirkan pergantungan luaran yang sedia ada sebelumnya) etcd-operator;
• Mendokumentasikan tetapan yang disyorkan untuk pengimbang beban luaran yang menyediakan konfigurasi tahan kerosakan (pada masa hadapan ia dirancang untuk menghapuskan pergantungan ini, tetapi tidak pada peringkat ini).

Seni bina gugusan Kubernetes HA yang dibuat dengan kubeadm

Butiran pelaksanaan boleh didapati di cadangan reka bentuk. Ciri ini telah lama ditunggu-tunggu: versi alfa dijangka kembali dalam K8s 1.9, tetapi hanya muncul sekarang.

API

Pasukan apply dan secara amnya pengurusan objek deklaratif lulus daripada kubectl dalam apiserver. Pembangun sendiri menerangkan secara ringkas keputusan mereka dengan mengatakan itu kubectl apply - bahagian asas dalam bekerja dengan konfigurasi dalam Kubernetes, walau bagaimanapun, "ia penuh dengan pepijat dan sukar untuk diperbaiki," dan oleh itu fungsi ini perlu dikembalikan kepada normal dan dipindahkan ke satah kawalan. Contoh mudah dan jelas masalah yang wujud hari ini:

Butiran tentang pelaksanaan ada dalam CAP. Kesediaan semasa ialah alfa (promosi kepada beta dirancang untuk keluaran Kubernetes seterusnya).

Dibuat tersedia dalam versi alfa peluang menggunakan skema OpenAPI v3 untuk mencipta dan menerbitkan dokumentasi OpenAPI untuk CustomResources (CR) digunakan untuk mengesahkan (sebelah pelayan) sumber takrif pengguna K8 (CustomResourceDefinition, CRD). Menerbitkan OpenAPI untuk CRD membenarkan pelanggan (cth. kubectl) lakukan pengesahan di sebelah anda (dalam kubectl create и kubectl apply) dan mengeluarkan dokumentasi mengikut skema (kubectl explain). Butiran - dalam CAP.

Log sedia ada kini dibuka dengan bendera O_APPEND (tetapi tidak O_TRUNC) untuk mengelakkan kehilangan log dalam beberapa situasi dan untuk kemudahan memotong log dengan utiliti luaran untuk penggiliran.

Juga dalam konteks API Kubernetes, boleh diperhatikan bahawa dalam PodSandbox и PodSandboxStatus tambah bidang runtime_handler untuk merekod maklumat tentang RuntimeClass dalam pod (baca lebih lanjut mengenainya dalam teks tentang Keluaran Kubernetes 1.12, di mana kelas ini muncul sebagai versi alfa), dan dalam Kemasukan Webhooks dilaksanakan keupayaan untuk menentukan versi yang mana AdmissionReview mereka menyokong. Akhirnya, peraturan Kemasukan Webhooks kini boleh terhad sejauh mana penggunaannya oleh ruang nama dan rangka kerja kelompok.

Bilik kebal

PersistentLocalVolumes, yang mempunyai status beta sejak dikeluarkan K8s 1.10, diumumkan stabil (GA): get ciri ini tidak lagi dilumpuhkan dan akan dialih keluar dalam Kubernetes 1.17.

Peluang menggunakan pembolehubah persekitaran dipanggil API ke bawah (contohnya, nama pod) untuk nama direktori yang dipasang sebagai subPath, dibangunkan - dalam bentuk bidang baru subPathExpr, yang kini digunakan untuk menentukan nama direktori yang dikehendaki. Ciri ini pada mulanya muncul dalam Kubernetes 1.11, tetapi untuk 1.14 ia kekal dalam status versi alfa.

Seperti keluaran Kubernetes sebelumnya, banyak perubahan ketara diperkenalkan untuk CSI (Antara Muka Penyimpanan Kontena) yang sedang giat membangun:

CSI

Menjadi tersedia (sebagai sebahagian daripada versi alfa) menyokong mengubah saiz untuk volum CSI. Untuk menggunakannya, anda perlu mendayakan gerbang ciri yang dipanggil ExpandCSIVolumes, serta ketersediaan sokongan untuk operasi ini dalam pemacu CSI tertentu.

Satu lagi ciri untuk CSI dalam versi alfa - peluang rujuk terus (iaitu tanpa menggunakan PV/PVC) kepada volum CSI dalam spesifikasi pod. ini menghapuskan sekatan ke atas penggunaan CSI sebagai storan data jauh secara eksklusif, membuka pintu kepada dunia untuk mereka isipadu ephemeral tempatan. Untuk kegunaan (contoh dari dokumentasi) mesti didayakan CSIInlineVolume gerbang ciri.

Terdapat juga kemajuan dalam "dalaman" Kubernetes yang berkaitan dengan CSI, yang tidak begitu kelihatan kepada pengguna akhir (pentadbir sistem) ... Pada masa ini, pembangun terpaksa menyokong dua versi setiap pemalam storan: satu - "dalam cara lama”, di dalam pangkalan kod K8s (dalam -tree), dan yang kedua - sebagai sebahagian daripada CSI baharu (baca lebih lanjut mengenainya, sebagai contoh, dalam di sini). Ini menyebabkan kesulitan yang boleh difahami yang perlu ditangani kerana CSI itu sendiri stabil. Tidak mustahil untuk hanya menafikan API pemalam dalaman (dalam pokok) disebabkan oleh dasar Kubernetes yang berkaitan.

Semua ini membawa kepada fakta bahawa versi alfa dicapai proses migrasi kod pemalam dalaman, dilaksanakan sebagai dalam pemalam, dalam pemalam CSI, dengan itu kebimbangan pembangun akan dikurangkan kepada menyokong satu versi pemalam mereka, dan keserasian dengan API lama akan kekal dan ia boleh diisytiharkan usang dalam senario biasa. Menjelang keluaran Kubernetes (1.15) yang seterusnya, semua pemalam penyedia awan akan dipindahkan, pelaksanaan akan menerima status beta dan akan diaktifkan dalam pemasangan K8s secara lalai. Untuk butiran, lihat cadangan reka bentuk. Penghijrahan ini juga mengakibatkan kegagalan daripada had volum yang ditentukan oleh pembekal awan tertentu (AWS, Azure, GCE, Cinder).

Selain itu, sokongan untuk peranti sekat dengan CSI (CSIBlockVolume) dipindahkan kepada versi beta.

Nod/Kubelet

Versi alfa dibentangkan titik akhir baharu dalam Kubelet, direka untuk pulangan metrik pada sumber utama. Secara umumnya, jika sebelum ini Kubelet menerima statistik penggunaan kontena daripada cAdvisor, kini data ini datang daripada persekitaran masa jalan kontena melalui CRI (Container Runtime Interface), tetapi keserasian untuk bekerja dengan versi lama Docker juga dipelihara. Sebelum ini, statistik yang dikumpul dalam Kubelet dihantar melalui API REST, tetapi kini titik akhir terletak di /metrics/resource/v1alpha1. Strategi jangka panjang pemaju ialah adalah untuk meminimumkan set metrik yang disediakan oleh Kubelet. By the way, metrik ini sendiri kini mereka memanggil bukan "metrik teras", tetapi "metrik sumber", dan diterangkan sebagai "sumber kelas pertama, seperti cpu dan memori".

Nuansa yang sangat menarik: walaupun kelebihan prestasi yang jelas bagi titik akhir gRPC berbanding dengan pelbagai kes penggunaan format Prometheus (lihat hasil salah satu penanda aras di bawah), penulis lebih suka format teks Prometheus kerana kepimpinan yang jelas sistem pemantauan ini dalam masyarakat.

“gRPC tidak serasi dengan saluran paip pemantauan utama. Endpoint hanya berguna untuk menghantar metrik ke Pelayan Metrik atau memantau komponen yang berintegrasi secara langsung dengannya. Prestasi format teks Prometheus apabila menggunakan caching dalam Pelayan Metrik cukup bagus untuk kami memilih Prometheus berbanding gRPC memandangkan penggunaan Prometheus yang meluas dalam komuniti. Setelah format OpenMetrics menjadi lebih stabil, kami akan dapat mendekati prestasi gRPC dengan format berasaskan proto."

Salah satu ujian prestasi perbandingan menggunakan format gRPC dan Prometheus dalam titik akhir Kubelet baharu untuk metrik. Lebih banyak graf dan butiran lain boleh didapati dalam CAP.

Antara perubahan lain:

• Kubelet sekarang (satu kali) cuba berhenti bekas dalam keadaan tidak diketahui sebelum memulakan semula dan memadam operasi.
• Apabila menggunakan PodPresets sekarang ke bekas init tambah maklumat yang sama seperti bekas biasa.
• kubelet mula menggunakan usageNanoCores daripada penyedia statistik CRI, dan untuk nod dan bekas pada Windows tambah statistik rangkaian.
• Maklumat sistem pengendalian dan seni bina kini direkodkan dalam label kubernetes.io/os и kubernetes.io/arch Objek nod (dipindahkan daripada beta ke GA).
• Keupayaan untuk menentukan kumpulan pengguna sistem tertentu untuk bekas dalam pod (RunAsGroup, muncul dalam K8s 1.11) maju sebelum beta (didayakan secara lalai).
• du dan cari digunakan dalam cAdvisor, diganti pelaksanaan on Go.

CLI

Dalam cli-runtime dan kubectl tambah -k bendera untuk penyepaduan dengan menyesuaikan (dengan cara ini, pembangunannya kini dijalankan dalam repositori berasingan), i.e. untuk memproses fail YAML tambahan daripada direktori penyesuaian khas (untuk butiran penggunaannya, lihat CAP):

Contoh penggunaan fail mudah penyesuaian (aplikasi kustomize yang lebih kompleks boleh dilakukan dalam overlays)

Di samping itu:

• Ditambah pasukan baru kubectl create cronjob, yang namanya bercakap untuk dirinya sendiri.
• В kubectl logs sekarang kamu boleh Gabung bendera -f (--follow untuk log penstriman) dan -l (--selector untuk pertanyaan label).
• kubectl diajar salin fail yang dipilih oleh kad liar.
• Kepada pasukan kubectl wait tambah bendera --all untuk memilih semua sumber dalam ruang nama jenis sumber yang ditentukan.

Lain

Keupayaan berikut telah menerima status stabil (GA):

• ReadinessGate, digunakan dalam spesifikasi pod untuk menentukan syarat tambahan yang diambil kira dalam kesediaan pod;
• Sokongan untuk halaman besar (pintu ciri dipanggil HugePages);
• CustomPodDNS;
• API PriorityClass Keutamaan Pod & Preemption.

Perubahan lain yang diperkenalkan dalam Kubernetes 1.14:

• Dasar RBAC lalai tidak lagi membenarkan akses API discovery и access-review pengguna tanpa pengesahan (tidak disahkan).
• Sokongan CoreDNS rasmi dipastikan Linux sahaja, jadi apabila menggunakan kubeadm untuk menggunakan ia (CoreDNS) dalam kluster, nod mesti dijalankan pada Linux sahaja (nodeSelectors digunakan untuk had ini).
• Konfigurasi CoreDNS lalai kini kegunaan pemalam ke hadapan bukannya proksi. Juga, dalam CoreDNS tambah ReadinessProbe, yang menghalang pengimbangan beban pada pod yang sesuai (tidak bersedia untuk diservis).
• Dalam kubeadm, pada fasa init atau upload-certs, menjadi mungkin muatkan sijil yang diperlukan untuk menyambung satah kawalan baharu ke rahsia kubeadm-certs (gunakan bendera --experimental-upload-certs).
• Versi alfa telah muncul untuk pemasangan Windows sokongan gMSA (Akaun Perkhidmatan Terurus Kumpulan) - akaun khas dalam Active Directory yang juga boleh digunakan oleh bekas.
• Untuk G.C.E. diaktifkan penyulitan mTLS antara etcd dan kube-apiserver.
• Kemas kini dalam perisian terpakai/bergantung: Pergi 1.12.1, CSI 1.1, CoreDNS 1.3.1, sokongan Docker 18.09 dalam kubeadm dan versi minimum Docker API yang disokong kini ialah 1.26.

PS

Baca juga di blog kami:

• «Kubernetes 1.13: gambaran keseluruhan inovasi utama»;
• «Kubernetes 1.12: gambaran keseluruhan inovasi utama»;
• «Kubernetes 1.11: gambaran keseluruhan inovasi utama»;
• «Kubernetes 1.10: gambaran keseluruhan inovasi utama'.

Sumber: www.habr.com