🥇Kubernetes 1.16: ikhtisar inovasi utama

Hari ini, Rabu, diselenggarakan rilis Kubernetes berikutnya - 1.16. Menurut tradisi yang berkembang di blog kami, ini adalah ulang tahun kesepuluh kami berbicara tentang perubahan paling signifikan dalam versi baru.

Informasi yang digunakan untuk menyiapkan bahan ini diambil dari Tabel pelacakan penyempurnaan Kubernetes, PERUBAHANLOG-1.16 dan masalah terkait, permintaan penarikan, dan Proposal Peningkatan Kubernetes (KEP). Jadi ayo pergi!..

Node

Sejumlah besar inovasi penting (dalam status versi alfa) disajikan di sisi node cluster K8s (Kubelet).

Pertama, yang disebut «wadah sementara» (Wadah Ephemeral), dirancang untuk menyederhanakan proses debugging di pod. Mekanisme baru ini memungkinkan Anda meluncurkan container khusus yang dimulai di namespace pod yang ada dan aktif dalam waktu singkat. Tujuannya adalah untuk berinteraksi dengan pod dan container lain untuk menyelesaikan masalah dan melakukan debug. Perintah baru telah diterapkan untuk fitur ini kubectl debug, pada dasarnya mirip dengan kubectl exec: saja alih-alih menjalankan proses dalam wadah (seperti pada exec) ia meluncurkan sebuah container di dalam sebuah pod. Misalnya, perintah ini akan menghubungkan container baru ke sebuah pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Detail tentang wadah sementara (dan contoh penggunaannya) dapat ditemukan di KEP yang sesuai. Implementasi saat ini (di K8s 1.16) adalah versi alfa, dan salah satu kriteria untuk mentransfernya ke versi beta adalah “menguji API Kontainer Ephemeral untuk setidaknya 2 rilis [Kubernetes].”

NB: Pada intinya dan bahkan namanya, fitur tersebut menyerupai plugin yang sudah ada kubectl-debugtentang yang kita sudah menulis. Diharapkan dengan munculnya wadah sementara, pengembangan plugin eksternal terpisah akan berhenti.

Inovasi lain - PodOverhead - dirancang untuk menyediakan mekanisme untuk menghitung biaya overhead untuk pod, yang bisa sangat bervariasi tergantung pada runtime yang digunakan. Sebagai contoh, penulis KEP ini menghasilkan Kata Containers, yang memerlukan menjalankan kernel tamu, agen kata, sistem init, dll. Ketika overhead menjadi sangat besar, hal ini tidak dapat diabaikan, yang berarti perlu ada cara untuk memperhitungkannya untuk kuota selanjutnya, perencanaan, dan lain-lain. Untuk menerapkannya di PodSpec lapangan ditambahkan Overhead *ResourceList (bandingkan dengan data di RuntimeClass, jika ada yang digunakan).

Inovasi penting lainnya adalah manajer topologi simpul (Manajer Topologi Node), dirancang untuk menyatukan pendekatan dalam menyempurnakan alokasi sumber daya perangkat keras untuk berbagai komponen di Kubernetes. Inisiatif ini didorong oleh meningkatnya kebutuhan berbagai sistem modern (dari bidang telekomunikasi, pembelajaran mesin, layanan keuangan, dll.) akan komputasi paralel berkinerja tinggi dan meminimalkan penundaan dalam pelaksanaan operasi, yang mana mereka menggunakan CPU canggih dan kemampuan akselerasi perangkat keras. Pengoptimalan seperti itu di Kubernetes sejauh ini telah dicapai berkat komponen-komponen yang berbeda (CPU manager, Device manager, CNI), dan sekarang mereka akan ditambahkan satu antarmuka internal yang menyatukan pendekatan dan menyederhanakan koneksi baru yang serupa - yang disebut topologi- sadar - komponen di sisi Kubelet. Detail - masuk KEP yang sesuai.

Diagram Komponen Manajer Topologi

Fitur berikutnya - memeriksa kontainer saat sedang berjalan (pemeriksaan permulaan). Seperti yang Anda ketahui, untuk container yang membutuhkan waktu lama untuk diluncurkan, sulit untuk mendapatkan status terkini: container tersebut “terbunuh” sebelum benar-benar mulai berfungsi, atau mengalami kebuntuan dalam waktu yang lama. Pemeriksaan baru (diaktifkan melalui gerbang fitur yang disebut StartupProbeEnabled) membatalkan - atau lebih tepatnya, menunda - efek dari pemeriksaan lainnya hingga pod selesai berjalan. Karena alasan inilah, fitur ini awalnya disebut penundaan pemeriksaan keaktifan pod-startup. Untuk pod yang memerlukan waktu lama untuk memulai, Anda dapat melakukan polling status dalam interval waktu yang relatif singkat.

Selain itu, peningkatan untuk RuntimeClass segera tersedia dalam status beta, menambahkan dukungan untuk “klaster heterogen”. C Penjadwalan Kelas Runtime Sekarang setiap node tidak perlu memiliki dukungan untuk setiap RuntimeClass: untuk pod Anda dapat memilih RuntimeClass tanpa memikirkan topologi cluster. Sebelumnya, untuk mencapai hal ini - agar pod berakhir di node dengan dukungan untuk semua yang mereka butuhkan - perlu untuk menetapkan aturan dan toleransi yang sesuai ke NodeSelector. DI DALAM KEP Ini berbicara tentang contoh penggunaan dan, tentu saja, detail implementasi.

Сеть

Dua fitur jaringan penting yang muncul pertama kali (dalam versi alfa) di Kubernetes 1.16 adalah:

Dukungan tumpukan jaringan ganda - IPv4/IPv6 - dan “pemahaman” terkait di tingkat pod, node, layanan. Ini mencakup interoperabilitas IPv4-ke-IPv4 dan IPv6-ke-IPv6 antar pod, dari pod ke layanan eksternal, implementasi referensi (dalam plugin Bridge CNI, PTP CNI dan Host-Local IPAM), serta kebalikannya Kompatibel dengan cluster Kubernetes yang berjalan Hanya IPv4 atau IPv6. Detail implementasi ada di KEP.
Contoh menampilkan dua jenis alamat IP (IPv4 dan IPv6) dalam daftar pod:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
API baru untuk Titik Akhir - API EndpointSlice. Ini memecahkan masalah kinerja/skalabilitas API Endpoint yang ada yang mempengaruhi berbagai komponen di bidang kendali (apiserver, dll, endpoints-controller, kube-proxy). API baru akan ditambahkan ke grup Discovery API dan akan mampu melayani puluhan ribu titik akhir backend pada setiap layanan dalam sebuah cluster yang terdiri dari ribuan node. Untuk melakukan hal ini, setiap Layanan dipetakan ke N objek EndpointSlice, yang masing-masing secara default tidak memiliki 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 и NotReady), subsetting dinamis untuk titik akhir.

Yang dihadirkan pada rilisan terakhir sudah mencapai versi beta finalis, bernama service.kubernetes.io/load-balancer-cleanup dan dilampirkan ke setiap layanan dengan tipe LoadBalancer. Pada saat menghapus layanan tersebut, ini mencegah penghapusan sumber daya yang sebenarnya hingga “pembersihan” semua sumber daya penyeimbang yang relevan selesai.

Mesin API

“Tonggak stabilisasi” sebenarnya ada di area server API Kubernetes dan interaksi dengannya. Hal ini terjadi sebagian besar berkat mentransfer ke status stabil mereka yang tidak memerlukan pengenalan khusus Definisi Sumber Daya Kustom (CRD), yang telah berstatus beta sejak masa Kubernetes 1.7 (dan ini adalah Juni 2017!). Stabilisasi yang sama terjadi pada fitur terkait:

"subsumber daya" dengan /status и /scale untuk Sumber Daya Kustom;
konversi versi untuk CRD, berdasarkan webhook eksternal;
baru-baru ini disajikan (di K8s 1.15) nilai default (gagal bayar) dan penghapusan bidang otomatis (pemangkasan) untuk Sumber Daya Kustom;
kesempatan menggunakan skema OpenAPI v3 untuk membuat dan menerbitkan dokumentasi OpenAPI yang digunakan untuk memvalidasi sumber daya CRD di sisi server.

Mekanisme lain yang sudah lama dikenal oleh administrator Kubernetes: webhook penerimaan - juga tetap dalam status beta untuk waktu yang lama (sejak K8s 1.9) dan sekarang dinyatakan stabil.

Dua fitur lainnya telah mencapai versi beta: berlaku di sisi server и menonton bookmark.

Dan satu-satunya inovasi signifikan dalam versi alpha adalah kegagalan dari SelfLink — URI khusus yang mewakili objek tertentu dan menjadi bagiannya ObjectMeta и ListMeta (yaitu bagian dari objek apa pun di Kubernetes). Mengapa mereka meninggalkannya? Motivasi dengan cara yang sederhana terdengar karena tidak adanya alasan nyata (yang luar biasa) mengapa bidang ini masih ada. Alasan yang lebih formal adalah untuk mengoptimalkan kinerja (dengan menghapus bidang yang tidak perlu) dan untuk menyederhanakan pekerjaan apiserver generik, yang dipaksa untuk menangani bidang tersebut dengan cara khusus (ini adalah satu-satunya bidang yang disetel tepat sebelum objek diserialkan). Keusangan sejati (dalam versi beta) SelfLink akan terjadi pada Kubernetes versi 1.20, dan final - 1.21.

Penyimpanan data

Pekerjaan utama di area penyimpanan, seperti pada rilis sebelumnya, diamati di area tersebut dukungan CSI. Perubahan utama di sini adalah:

untuk pertama kalinya (dalam versi alfa) muncul Dukungan plugin CSI untuk node pekerja Windows: cara bekerja dengan penyimpanan saat ini juga akan menggantikan plugin in-tree di inti Kubernetes dan plugin FlexVolume dari Microsoft berdasarkan Powershell;

Skema implementasi plugin CSI di Kubernetes untuk Windows
kesempatan mengubah ukuran volume CSI, diperkenalkan kembali di K8s 1.12, telah berkembang menjadi versi beta;
"Promosi" serupa (dari alfa ke beta) dicapai dengan kemampuan menggunakan CSI untuk membuat volume sementara lokal (Dukungan Volume Sebaris CSI).

Diperkenalkan di Kubernetes versi sebelumnya fungsi kloning volume (menggunakan PVC yang ada sebagai DataSource untuk membuat PVC baru) kini juga telah menerima status beta.

Penjadwal

Dua perubahan penting pada penjadwalan (keduanya dalam versi alfa):

EvenPodsSpreading - peluang gunakan pod alih-alih unit aplikasi logis untuk “distribusi muatan yang adil”. (seperti Deployment dan ReplicaSet) dan menyesuaikan distribusi ini (sebagai persyaratan keras atau sebagai kondisi lunak, yaitu prioritas). Fitur ini akan memperluas kemampuan distribusi pod yang direncanakan, yang saat ini dibatasi oleh pilihan PodAffinity и PodAntiAffinity, memberikan administrator kontrol yang lebih baik dalam hal ini, yang berarti ketersediaan tinggi yang lebih baik dan konsumsi sumber daya yang dioptimalkan. Detail - masuk KEP.
Menggunakan Kebijakan BestFit в Fungsi Prioritas RequestedToCapacityRatio selama perencanaan pod, yang memungkinkan untuk mendaftar kemasan tempat sampah (“mengemas dalam wadah”) untuk sumber daya dasar (prosesor, memori) dan sumber daya tambahan (seperti GPU). Untuk lebih jelasnya, lihat KEP.

Menjadwalkan pod: sebelum menggunakan kebijakan yang paling sesuai (langsung melalui penjadwal default) dan dengan penggunaannya (melalui pemanjang penjadwal)

Selain itu, diwakili oleh kemampuan untuk membuat plugin penjadwal Anda sendiri di luar pohon pengembangan utama Kubernetes (di luar pohon).

Perubahan lainnya

Hal ini juga dapat diperhatikan pada rilis Kubernetes 1.16 inisiatif untuk membawa metrik yang tersedia dalam urutan lengkap, atau lebih tepatnya, sesuai dengan peraturan resmi ke instrumentasi K8. Mereka sangat bergantung pada hal-hal terkait Dokumentasi Prometheus. Inkonsistensi muncul karena berbagai alasan (misalnya, beberapa metrik dibuat sebelum instruksi saat ini muncul), dan pengembang memutuskan bahwa sudah waktunya untuk membawa semuanya ke satu standar, “sejalan dengan ekosistem Prometheus lainnya.” Implementasi inisiatif ini saat ini berada dalam status alfa, yang akan dipromosikan secara bertahap di versi Kubernetes berikutnya ke beta (1.17) dan stabil (1.18).

Selain itu, perubahan berikut dapat diperhatikan:

Pengembangan dukungan Windows с penampilan Utilitas Kubeadm untuk OS ini (versi alfa), kesempatan RunAsUserName untuk wadah Windows (versi alfa), peningkatan Akun Layanan Terkelola Grup (gMSA) mendukung hingga versi beta, mendukung pasang/lampirkan untuk volume vSphere.
Daur ulang mekanisme kompresi data dalam respons API. Sebelumnya, filter HTTP digunakan untuk tujuan ini, yang memberlakukan sejumlah batasan sehingga tidak dapat diaktifkan secara default. "Kompresi permintaan transparan" sekarang berfungsi: pengiriman klien Accept-Encoding: gzip di header, mereka menerima respons terkompresi GZIP jika ukurannya melebihi 128 KB. Klien Go secara otomatis mendukung kompresi (mengirimkan header yang diperlukan), sehingga mereka akan segera melihat pengurangan lalu lintas. (Sedikit modifikasi mungkin diperlukan untuk bahasa lain.)
Menjadi mungkin menskalakan HPA dari/ke nol pod berdasarkan metrik eksternal. Jika Anda menskalakan berdasarkan objek/metrik eksternal, maka saat beban kerja tidak aktif, Anda dapat secara otomatis menskalakan ke 0 replika untuk menghemat sumber daya. Fitur ini akan sangat berguna ketika pekerja meminta sumber daya GPU, dan jumlah berbagai jenis pekerja yang menganggur melebihi jumlah GPU yang tersedia.
Klien baru - k8s.io/client-go/metadata.Client — untuk akses “umum” ke objek. Ini dirancang untuk dengan mudah mengambil metadata (yaitu subbagian metadata) dari sumber daya cluster dan melakukan pengumpulan sampah dan operasi kuota dengan sumber daya tersebut.
Bangun Kubernet sekarang kamu bisa tanpa penyedia cloud lama (“bawaan” dalam pohon) (versi alfa).
Ke utilitas kubeadm ditambahkan kemampuan eksperimental (versi alfa) untuk menerapkan tambalan khusus selama operasi init, join и upgrade. Pelajari lebih lanjut tentang cara menggunakan bendera --experimental-kustomize, lihat di KEP.
Titik akhir baru untuk apiserver - readyz, - memungkinkan Anda mengekspor informasi tentang kesiapannya. Server API kini juga memiliki sebuah bendera --maximum-startup-sequence-duration, memungkinkan Anda mengatur permulaan ulangnya.
Dua fitur untuk Azure dinyatakan stabil: dukungan zona ketersediaan (Zona Ketersediaan) dan kelompok lintas sumber daya (RG). Selain itu, Azure telah menambahkan:
- dukungan otentikasi AAD dan ADFS;
- abstrak service.beta.kubernetes.io/azure-pip-name untuk menentukan IP publik penyeimbang beban;
- kesempatan pengaturan LoadBalancerName и LoadBalancerResourceGroup.
AWS sekarang memilikinya mendukung untuk EBS di Windows dan dioptimalkan Panggilan API EC2 DescribeInstances.
Kubeadm sekarang mandiri bermigrasi Konfigurasi CoreDNS saat mengupgrade versi CoreDNS.
Biner dll di gambar Docker yang sesuai selesai world-executable, yang memungkinkan Anda menjalankan image ini tanpa memerlukan hak root. Juga, gambar migrasi dll berhenti dukungan versi etcd2.
В Penskala Otomatis Klaster 1.16.0 beralih menggunakan distroless sebagai gambar dasar, peningkatan kinerja, penambahan penyedia cloud baru (DigitalOcean, Magnum, Packet).
Pembaruan pada perangkat lunak yang digunakan/tergantung: Go 1.12.9, dll 3.3.15, CoreDNS 1.6.2.

Kubernetes 1.16: ikhtisar inovasi utama