Hari ini, pada hari Rabu, rilis Kubernetes berikutnya
akan diadakan - 1.16. Menurut tradisi yang telah dikembangkan untuk blog kita, untuk kesepuluh kalinya, kita berbicara tentang perubahan paling signifikan dalam versi baru.
Informasi yang digunakan untuk mempersiapkan bahan ini diambil dari
tabel pelacakan perangkat tambahan Kubernet ,
CHANGELOG-1.16 dan masalah terkait, permintaan tarik, serta Kubernetes Enhancement Proposals (KEP). Jadi ayo pergi! ..
Simpul
Sejumlah besar inovasi penting (dalam status versi alfa) disajikan di sisi node-cluster K8s (Kubelet).
Pertama, apa yang disebut
" wadah ephemeral " (Ephemeral Containers) disajikan
, dirancang untuk menyederhanakan proses debugging di pod . Mekanisme baru memungkinkan Anda untuk menjalankan wadah khusus yang dimulai di namespace pod yang ada dan hidup untuk waktu yang singkat. Tujuannya adalah untuk berinteraksi dengan pod dan wadah lain untuk menyelesaikan masalah dan debugging. Untuk fitur ini, perintah
kubectl debug baru
kubectl debug , intinya mirip dengan
kubectl exec : hanya alih-alih memulai proses dalam wadah (seperti dalam kasus
exec ) itu mulai kontainer di pod. Misalnya, perintah seperti itu akan menghubungkan wadah baru ke pod:
kubectl debug -c debug-shell --image=debian target-pod -- bash
Rincian tentang wadah sementara (dan contoh penggunaannya) dapat ditemukan di
KEP terkait . Implementasi saat ini (dalam K8 1.16) adalah versi alpha, dan di antara kriteria untuk transfernya ke versi beta adalah "menguji API Wadah Ephemeral untuk setidaknya 2 rilis [Kubernetes]".
NB : Intinya dan bahkan nama fitur menyerupai plugin kubectl-debug yang sudah ada, yang sudah kami tulis . Diasumsikan bahwa dengan munculnya wadah sementara, pengembangan plug-in eksternal yang terpisah akan berhenti.Inovasi lain,
PodOverhead dirancang untuk menyediakan
mekanisme untuk menghitung biaya overhead pod , yang dapat sangat bervariasi tergantung pada runtime yang digunakan. Sebagai contoh, penulis
KEP ini mengutip Kata Containers, yang mengharuskan peluncuran kernel tamu, agen kata, sistem init, dll. Ketika biaya overhead menjadi begitu besar, itu tidak dapat diabaikan, yang berarti bahwa cara diperlukan untuk memperhitungkan kuota, perencanaan, dll. Untuk mengimplementasikannya, bidang
Overhead *ResourceList telah ditambahkan ke
PodSpec (dibandingkan dengan data di
RuntimeClass , jika digunakan).
Inovasi penting lainnya adalah
Node Topology Manager , yang dirancang untuk menyatukan pendekatan untuk menyempurnakan alokasi sumber daya perangkat keras untuk berbagai komponen di Kubernetes. Inisiatif ini disebabkan oleh meningkatnya permintaan berbagai sistem modern (dari bidang telekomunikasi, pembelajaran mesin, layanan keuangan, dll.) Untuk komputasi paralel berkinerja tinggi dan meminimalkan penundaan dalam menjalankan operasi, di mana mereka menggunakan kemampuan canggih CPU dan akselerasi perangkat keras. Optimalisasi di Kubernetes sejauh ini telah dicapai berkat komponen yang berbeda (manajer CPU, Manajer perangkat, CNI), dan sekarang mereka akan menambahkan antarmuka internal tunggal yang menyatukan pendekatan dan menyederhanakan koneksi komponen baru yang serupa - yang disebut topologi-sadar - di sisi Kubelet. Detail ada di
KEP terkait .
Diagram Komponen Manajer TopologiFitur selanjutnya adalah
memeriksa wadah selama startup ( penyelidikan startup ) . Seperti yang Anda ketahui, untuk wadah yang beroperasi untuk waktu yang lama, sulit untuk mendapatkan status saat ini: mereka "terbunuh" sebelum dimulainya operasi, atau berakhir di jalan buntu untuk waktu yang lama. Pemeriksaan baru (diaktifkan melalui gerbang fitur yang disebut
StartupProbeEnabled ) membatalkan - atau lebih tepatnya,
StartupProbeEnabled - tindakan pemeriksaan lainnya hingga saat pod selesai peluncurannya. Untuk alasan ini, fitur ini awalnya disebut
pod-startup liveness-probe holdoff . Untuk pod yang membutuhkan waktu lama untuk memulai, Anda dapat memilih status dalam interval waktu yang relatif singkat.
Selain itu, segera dalam status beta peningkatan untuk RuntimeClass ditambahkan, menambahkan dukungan untuk "cluster heterogen". Dengan
Penjadwalan RuntimeClass, sekarang tidak perlu untuk setiap node memiliki dukungan untuk setiap RuntimeClass: untuk pod, Anda dapat memilih RuntimeClass tanpa memikirkan topologi cluster. Sebelumnya, untuk mencapai ini - agar pod muncul di node dengan dukungan untuk semua yang mereka butuhkan - mereka harus menetapkan aturan yang sesuai untuk NodeSelector dan toleransi.
KEP berbicara tentang contoh penggunaan dan, tentu saja, detail implementasi.
Jaringan
Dua fitur jaringan signifikan yang pertama kali muncul (dalam versi alpha) di Kubernetes 1.16 adalah:
- Dukungan untuk tumpukan jaringan ganda - IPv4 / IPv6 - dan "pemahaman" terkait di tingkat pod, node, layanan. Ini termasuk interaksi IPv4-ke-IPv4 dan IPv6-ke-IPv6 antara pod, dari pod ke layanan eksternal, implementasi referensi (dalam kerangka Bridge CNI, PTP CNI dan plug-in IPAM Host-Lokal), serta sebaliknya Kompatibel dengan kluster Kubernet yang hanya berfungsi pada IPv4 atau IPv6. Detail implementasi ada di KEP .
Contoh output dari dua jenis alamat IP (IPv4 dan IPv6) dalam daftar pod:
kube-master
- API baru untuk Endpoint adalah API EndpointSlice . Ini memecahkan masalah API Endpoint yang ada dengan kinerja / skalabilitas yang memengaruhi berbagai komponen dalam bidang kontrol (apiserver, etcd, endpoint-controller, kube-proxy). API baru akan ditambahkan ke grup Discovery API dan akan dapat melayani puluhan ribu titik akhir backend pada setiap layanan dalam sebuah cluster yang terdiri dari seribu node. Untuk melakukan ini, setiap Layanan dipetakan ke objek N
EndpointSlice , yang masing-masing secara default memiliki tidak lebih dari 100 titik akhir (nilainya dapat dikonfigurasi). API EndpointSlice juga akan memberikan peluang untuk pengembangannya di masa depan: dukungan untuk beberapa alamat IP untuk setiap pod, status baru untuk titik akhir (tidak hanya Ready dan NotReady ), subset dinamis untuk titik akhir.
Finalizer yang disajikan dalam rilis terakhir disebut
service.kubernetes.io/load-balancer-cleanup dan dilampirkan ke setiap layanan dengan tipe
LoadBalancer maju ke versi beta. Pada saat penghapusan layanan seperti itu, ia mencegah penghapusan sumber daya yang sebenarnya sampai "pembersihan" semua sumber daya yang sesuai dari penyeimbang selesai.
Mesin API
"Tonggak stabilisasi" yang sebenarnya telah diperbaiki di area server API Kubernetes dan berinteraksi dengannya. Dalam banyak hal, ini terjadi karena
transfer ke status stabil CustomResourceDefinitions (CRD) yang
tidak memerlukan presentasi khusus , yang berstatus beta sejak Kubernetes 1.7 yang jauh (dan ini adalah Juni 2017!). Stabilisasi yang sama datang ke fitur yang berkaitan dengan mereka:
- "Subresources" dengan
/status dan /scale untuk CustomResources; - konversi versi untuk CRD, berdasarkan pada webhook eksternal;
- baru-baru ini diperkenalkan (dalam K8s 1.15) nilai-nilai default (default) dan penghapusan bidang otomatis (pemangkasan) untuk CustomResources;
- kemungkinan menggunakan skema OpenAPI v3 untuk membuat dan menerbitkan dokumentasi OpenAPI yang digunakan untuk memvalidasi sumber daya CRD di sisi server.
Mekanisme lain yang telah lama dikenal oleh administrator Kubernetes:
webhook masuk - juga telah dalam status beta untuk waktu yang lama (sejak K8 1.9) dan sekarang telah dinyatakan stabil.
Dua fitur lainnya mencapai beta:
sisi server berlaku dan
lihat bookmark .
Dan satu-satunya inovasi signifikan dalam versi alpha adalah
penolakan SelfLink - URI khusus yang mewakili objek yang ditentukan dan merupakan bagian dari
ObjectMeta dan
ListMeta (mis., Bagian dari objek apa pun di Kubernetes). Kenapa menolaknya? Motivasi "sederhana"
terdengar seperti tidak adanya alasan yang nyata (tidak dapat diatasi) untuk bidang ini terus ada. Alasan yang lebih formal adalah untuk mengoptimalkan kinerja (menghapus bidang yang tidak perlu) dan menyederhanakan pekerjaan apiserver generik, yang dipaksa untuk memproses bidang tersebut dengan cara khusus (ini adalah satu-satunya bidang yang ditetapkan tepat sebelum objek tersebut serial). "Usang" nyata (dalam versi beta) dari
SelfLink akan terjadi pada Kubernetes versi 1.20, dan yang terakhir - 1.21.
Penyimpanan data
Pekerjaan utama di bidang penyimpanan, seperti dalam rilis sebelumnya, diamati di bidang
dukungan untuk CSI . Perubahan utama di sini adalah:
- untuk pertama kalinya (dalam versi alpha) , dukungan untuk plug-in CSI untuk node kerja Windows telah muncul : cara saat ini untuk bekerja dengan repositori akan menggantikan plug-in di pohon di inti Kubernetes dan plug-in FlexVolume berbasis Powershell dari Microsoft;
Skema Implementasi Plugin Kubernetes Windows CSI
- kemampuan untuk mengubah ukuran volume CSI , diperkenalkan dalam K8 1.12, telah berkembang ke versi beta;
- kemungkinan menggunakan CSI untuk membuat volume ephemeral lokal ( Dukungan Volume Inline CSI ) telah mencapai "peningkatan" yang serupa (dari alpha ke beta).
Fungsi untuk volume kloning yang muncul di versi Kubernetes sebelumnya (menggunakan PVC yang ada sebagai
DataSource untuk membuat PVC baru) juga sekarang telah menerima status beta.
Perencana
Dua perubahan penting dalam perencanaan (keduanya dalam versi alpha):
EvenPodsSpreading adalah kemampuan untuk menggunakan EvenPodsSpreading untuk "mendistribusikan secara adil" banyak unit alih-alih unit logis aplikasi (seperti Deployment dan ReplicaSet) dan menyesuaikan distribusi ini (sebagai persyaratan ketat atau sebagai kondisi ringan, mis. Prioritas). Fitur ini akan memperluas kapabilitas distribusi yang ada dari pod yang direncanakan, sekarang dibatasi oleh opsi PodAffinity dan PodAntiAffinity , memberikan administrator kontrol yang lebih baik dalam hal ini, yang berarti aksesibilitas yang lebih baik dan konsumsi sumber daya yang dioptimalkan. Detailnya ada di KEP .- Menggunakan Kebijakan BestFit dalam Fungsi Prioritas RequestedToCapacityRatio selama penjadwalan pod, yang memungkinkan pengemasan bin ("pengemasan dalam wadah") untuk digunakan baik untuk sumber daya inti (prosesor, memori) dan diperluas (seperti GPU). Lihat KEP untuk lebih jelasnya.
Penjadwalan pod: sebelum menggunakan kebijakan yang paling sesuai (langsung melalui penjadwal default) dan menggunakannya (melalui penjadwal penjadwal)
Selain itu, kesempatan
disajikan untuk membuat plugin Anda sendiri untuk penjadwal di luar pohon pengembangan Kubernetes utama (out-of-tree).
Perubahan lainnya
Juga dalam rilis Kubernetes 1.16, Anda dapat mencatat
inisiatif untuk membawa metrik yang ada dalam urutan penuh , atau lebih tepatnya, sesuai dengan
persyaratan resmi untuk instrumentasi K8. Mereka pada dasarnya mengandalkan
dokumentasi Prometheus yang relevan. Ketidakkonsistenan terbentuk karena berbagai alasan (misalnya, beberapa metrik dibuat sebelum instruksi saat ini muncul), dan para pengembang memutuskan bahwa sudah waktunya untuk membawa semuanya ke standar tunggal, "sejalan dengan seluruh ekosistem Prometheus." Implementasi inisiatif ini saat ini memiliki status versi alpha, yang secara bertahap akan meningkat di versi masa depan Kubernetes menjadi beta (1,17) dan stabil (1,18).
Selain itu, perubahan berikut dapat dicatat:
- Pengembangan dukungan Windows dengan munculnya utilitas Kubeadm untuk OS ini (versi alpha), kemungkinan
RunAsUserName untuk wadah Windows (versi alpha), peningkatan dukungan untuk Akun Layanan Grup yang Dikelola (gMSA) ke versi beta, pasang / pasang dukungan untuk volume vSphere. - Mekanisme kompresi data yang dirancang ulang dalam respons API . Sebelumnya, filter HTTP digunakan untuk tujuan ini, yang memberlakukan sejumlah pembatasan yang mencegah penyertaannya secara default. Sekarang "kompresi permintaan transparan" berfungsi: klien yang mengirim
Accept-Encoding: gzip di header menerima respons terkompresi di GZIP jika ukurannya melebihi 128 Kb. Klien on Go secara otomatis mendukung kompresi (mengirim tajuk yang diinginkan), sehingga mereka segera melihat penurunan traffic. (Untuk bahasa lain, modifikasi minor mungkin diperlukan.) - Menjadi mungkin untuk menskala HPA dari / ke nol polong berdasarkan metrik eksternal . Jika penskalaan didasarkan pada objek / metrik eksternal, maka ketika beban kerja idle, Anda dapat secara otomatis skala ke 0 replika untuk menghemat sumber daya. Fitur ini harus sangat berguna untuk kasus-kasus ketika pekerja meminta sumber daya GPU, dan jumlah berbagai jenis pekerja menganggur melebihi jumlah GPU yang tersedia.
- Klien baru -
k8s.io/client-go/metadata.Client - untuk akses "umum" ke objek. Ia dirancang untuk dengan mudah memperoleh metadata (mis., Subbagian metadata ) dari sumber daya cluster dan melakukan operasi bersamanya dari kategori pengumpulan sampah dan kuota. - Kubernet sekarang dapat dibangun tanpa penyedia cloud yang ketinggalan jaman ("built-in") (versi alpha).
- Kemampuan eksperimental (versi alpha) untuk menerapkan tambalan khusus selama
init , join dan upgrade operasi telah ditambahkan ke utilitas kubeadm. Untuk detail tentang cara menggunakan --experimental-kustomize , lihat KEP . - Titik akhir baru untuk apiserver adalah
readyz , yang memungkinkan Anda untuk mengekspor informasi kesiapan. Server API juga memiliki flag --maximum-startup-sequence-duration , yang memungkinkan Anda untuk menyesuaikan restart. - Dua fitur untuk Azure dinyatakan stabil: Dukungan untuk Zona Ketersediaan dan grup lintas sumber daya (RG). Selain itu, Azure menambahkan:
- AWS memiliki dukungan untuk EBS di Windows dan panggilan EC2 API yang dioptimalkan
DescribeInstances . - Kubeadm sekarang memigrasikan konfigurasi CoreDNS-nya sendiri ketika meningkatkan ke CoreDNS.
- Binari, dll, dalam gambar Docker yang sesuai menjadikannya dapat dieksekusi-dunia, yang memungkinkan Anda untuk menjalankan gambar ini tanpa memerlukan hak akses root. Selain itu, gambar migrasi etcd telah menjatuhkan dukungan untuk versi etcd2.
- Cluster Autoscaler 1.16.0 beralih menggunakan distroless sebagai gambar dasar, meningkatkan kinerja, dan menambahkan penyedia cloud baru (DigitalOcean, Magnum, Packet).
- Pembaruan dalam perangkat lunak yang digunakan / tergantung: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
PS
Baca juga di blog kami: