🥡 🚌 🍹 Kubernetes 1.12: ikhtisar inovasi utama 🕴🏻 🕣 🌀

Hari ini tanggal 27 September, yang berarti bahwa selama jam kerja (sesuai dengan zona waktu AS) kita dapat mengharapkan rilis Kubernetes berikutnya - 1,12 (namun, pengumuman resminya terkadang tertunda). Secara umum, saatnya untuk melanjutkan tradisi yang mulia dan memberi tahu tentang perubahan paling signifikan, yang akan kita lakukan berdasarkan informasi publik dari proyek: Kubernet menampilkan tabel pelacakan , CHANGELOG-1.12 , banyak masalah, permintaan tarik dan proposal desain. Jadi apa yang baru di K8 1.12?

Fasilitas penyimpanan

Jika Anda memilih satu hal yang disebutkan lebih sering daripada yang lain di antara semua masalah yang terkait dengan rilis Kubernet 1.12, mungkin itu adalah Container Storage Interface (CSI) , yang sudah kami tulis tentang hari lainnya. Untuk alasan ini, mari kita mulai dengan perubahan pada dukungan penyimpanan.

Dengan demikian , plugin CSI telah mempertahankan status beta dan diharapkan akan stabil untuk rilis Kubernetes berikutnya (1,13). Apa yang baru dalam dukungan CSI?

Pada bulan Februari tahun ini , pengerjaan konsep topologi dimulai pada spesifikasi CSI itu sendiri. Singkatnya, topologi adalah informasi tentang segmentasi cluster (misalnya, oleh "rak" untuk instalasi di tempat atau oleh "wilayah" dan "zona" untuk lingkungan cloud), yang perlu diketahui dan dipertimbangkan oleh sistem orkestrasi. Mengapa Volume yang dialokasikan oleh penyedia penyimpanan tidak harus dapat diakses secara merata di seluruh cluster, dan oleh karena itu pengetahuan tentang topologi diperlukan untuk merencanakan sumber daya secara efisien dan membuat keputusan penyediaan.

Hasil dari munculnya topologi di CSI ( diadopsi dalam spesifikasi pada 1 Juni) adalah dukungan mereka di Kubernetes 1.12:

dukungan seperti itu (pendaftaran informasi topologi volume yang dilaporkan oleh driver CSI) - versi alfa;
dukungan untuk topologi dalam penyediaan dinamis (lihat dokumentasi terperinci dalam proposal desain yang disebut " Penjadwalan Sadar Topologi Volume ") - segera versi beta;
Dukungan topologi GCE PD - versi alfa;
Dukungan Topologi AWS EBS - Beta.

Tetapi ini tidak berakhir dengan pembaruan terkait CSI. Inovasi penting lainnya dalam rilis Kubernetes 1.12 adalah dukungan untuk snapshot untuk CSI (saat dalam status alpha). Snapshots untuk volume seperti itu muncul dalam rilis K8s 1.8 . Implementasi utama, yang mencakup pengontrol dan penyedia (dua binari terpisah), diputuskan untuk ditransfer ke repositori eksternal . Sejak itu, dukungan telah ditambahkan untuk volume GCE PD, AWS EBS, OpenStack Cinder, GlusterFS, dan hostPath hostPath .

Proposal desain baru bertujuan untuk "melanjutkan inisiatif ini dengan menambahkan dukungan snapshot untuk Volume Drivers CSI" (dukungan snapshot dalam spesifikasi CSI dijelaskan di sini ). Karena Kubernetes mematuhi prinsip menyertakan sekumpulan kemampuan minimum dalam API inti, implementasi ini (seperti untuk snapshot dalam Volume Snapshot Controller) menggunakan CRD ( CustomResourceDefinitions ).

Dan beberapa fitur baru untuk driver CSI:

Versi alpha dari kemampuan driver untuk mendaftarkan dirinya di Kubernetes API (untuk memudahkan pengguna menemukan driver yang terinstal di cluster dan memungkinkan driver untuk mempengaruhi proses interaksi Kubernet dengan mereka);
Versi alpha dari kemampuan pengemudi untuk menerima informasi tentang drive yang meminta volume melalui NodePublish .

Diperkenalkan dalam rilis Kubernetes terakhir, mekanisme untuk membatasi volume secara dinamis pada node dipindahkan dari alpha ke beta, menerima ... Anda dapat menebaknya, mendukung CSI, serta Azure.

Akhirnya, fitur propagasi Mount namespace , yang memungkinkan Anda untuk memasang volume sebagai rshared (sehingga semua direktori kontainer yang terpasang terlihat di host) dan memiliki status beta dalam rilis K8s 1.10 , dinyatakan stabil.

Perencana

Dalam penjadwal, Kubernetes 1.12 meningkatkan kinerja berkat versi alfa dari mekanisme pembatasan pencarian dalam kelompok node yang sesuai untuk penjadwalan perapian (node yang layak) . Jika sebelumnya untuk setiap upaya untuk merencanakan setiap pod, kube-scheduler memeriksa ketersediaan semua node dan melewatinya untuk evaluasi, sekarang scheduler hanya akan menemukan sejumlah tertentu, dan kemudian menghentikan kerjanya. Pada saat yang sama, mekanisme menyediakan pemilihan simpul wajib dari berbagai daerah dan zona, serta kebutuhan untuk melihat simpul yang berbeda dalam siklus perencanaan yang berbeda (jangan pilih 100 simpul pertama setiap permulaan). Keputusan untuk menerapkan mekanisme ini dibuat, dipandu oleh hasil analisis data tentang kinerja penjadwal (jika persentil ke-90 menunjukkan waktu 30 ms untuk perapian, maka persentil ke-99 sudah 60 ms).

Selain itu, fitur penjadwal berikut telah jatuh tempo ke versi beta:

Taint node by Condition , yang muncul dalam K8s 1.8 dan memungkinkan menandai sebuah node dengan status tertentu (untuk tindakan lebih lanjut) ketika peristiwa-peristiwa tertentu terjadi: sekarang pengendali siklus hidup node secara otomatis membuat noda, dan scheduler memeriksanya (bukan kondisi );
Penjadwalan perapian di DaemonSet menggunakan kube-scheduler (bukan pengontrol DaemonSet ): ia juga diaktifkan secara default;
menentukan kelas prioritas di ResourceQuota .

Node gugus

Inovasi yang menarik adalah penampilan (dalam status versi alfa) dari RuntimeClass , sumber daya tingkat-cluster baru yang dirancang untuk melayani parameter runtime wadah (container runtime) . RuntimeClasses ditugaskan ke pod melalui bidang yang sama di PodSpec dan mengimplementasikan dukungan untuk menggunakan beberapa lingkungan yang dapat dieksekusi dalam sebuah cluster atau node. Mengapa

“Minat dalam menggunakan runtimes berbeda dalam sebuah cluster tumbuh. Saat ini, motivator utama untuk ini adalah kotak pasir dan keinginan Kata dan wadah gVisor untuk berintegrasi dengan Kubernetes. Model runtime lain seperti wadah Windows atau bahkan lingkungan runtime jarak jauh juga akan memerlukan dukungan di masa depan. RuntimeClass menawarkan cara untuk memilih antara runtime berbeda yang dikonfigurasi dalam sebuah cluster dan mengubah propertinya (baik oleh cluster dan pengguna). "

Untuk memilih di antara konfigurasi yang telah ditentukan, RuntimeHandler diteruskan ke CRI (Container Runtime Interface), yang dimaksudkan untuk menggantikan anotasi perapian saat ini:

Dan konfigurasi di contenterd untuk kata-runtime terlihat seperti ini:

 [plugins.cri.containerd.kata-runtime] runtime_type = "io.containerd.runtime.v1.linux" runtime_engine = "/opt/kata/bin/kata-runtime" runtime_root = ""

Kriteria RuntimeClass untuk versi alpha adalah validasi CRI yang berhasil.

Selain itu, mekanisme untuk mendaftarkan plug-in lokal (termasuk CSI) di Kubelet dan shareProcessNamespace (fitur telah diaktifkan secara default) telah berkembang ke status versi beta.

Jaringan

Berita utama di bagian jaringan Kubernetes adalah versi alpha dari dukungan SCTP (Stream Control Transmission Protocol). Setelah menerima dukungan dalam Pod , Layanan , Endpoint , dan NetworkPolicy , protokol telekomunikasi ini telah bergabung dengan jajaran TCP dan UDP. Dengan fitur baru "aplikasi yang membutuhkan SCTP sebagai protokol L4 untuk antarmuka mereka, akan lebih mudah untuk digunakan pada kluster Kubernetes; misalnya, mereka akan dapat menggunakan penemuan layanan berdasarkan kube-dns , dan interaksinya akan dikendalikan melalui NetworkPolicy . " Detail implementasi tersedia dalam dokumen ini .

Dua fitur jaringan yang diperkenalkan di K8 1.8 juga mencapai status stabil: dukungan untuk kebijakan untuk lalu lintas EgressRules keluar di API NetworkPolicy dan penerapan aturan CIDR untuk sumber / tujuan melalui ipBlockRule .

Scaling

Perbaikan pada Horizontal Pod Autoscaler meliputi:

algoritma yang diperbarui untuk pencapaian lebih cepat dari ukuran yang benar (segera alfa dan beta), untuk detail lebih lanjut tentang yang membaca bagian baru dokumentasi ;
pengembangan metrik khusus / khusus , beta kedua yang menerima API yang dirancang ulang dan dukungan untuk pemilih label.

Skala vertikal perapian , yang sebelum mencapai versi beta tidak memiliki pengujian pengguna, tidak berhenti. Para penulis menganggapnya cukup untuk rilis K8 1.12 dan mengingat bahwa fitur ini lebih mungkin merupakan tambahan untuk Kubernetes (tidak termasuk dalam kernel). Semua pengembangan dilakukan dalam repositori terpisah, di mana rilis beta akan diatur waktunya bersamaan dengan rilis Kubernetes.

Alur kerja Vertikal Pod Autoscaler (VPA) untuk Kubernetes

Akhirnya, K8 1.12 termasuk (dalam bentuk alfa) hasil kerja pada "penyederhanaan instalasi menggunakan ComponentConfig " (sebagai bagian dari siklus sig-cluster-lifecycle), yang telah berlangsung selama hampir dua tahun. Sayangnya, untuk beberapa alasan (pengawasan sederhana?), Akses ke dokumen proposal desain dengan detail ditutup untuk pengguna anonim.

Perubahan lainnya

API

Dua fitur baru diimplementasikan dalam grup mesin api:

dry-run untuk apiserver (versi alpha), yang meniru validasi dan pemrosesan permintaan;
API Kuota Sumber Daya (segera beta), yang menentukan sumber daya yang dibatasi secara default (alih-alih perilaku saat ini ketika konsumsi sumber daya tidak terbatas jika kuota tidak disetel).

Azure

Dinyatakan Stabil:

dukungan untuk Set Skala Mesin Virtual Azure (VMSS);
Dukungan biru di cluster-autoscaler.

Implementasi pertama (versi alpha) ditambahkan:

Dukungan Zona Ketersediaan Azure
dukungan untuk node seperti cross resource group (RG) dan node yang tidak dikelola (on-prem).

Kubectl

Versi alpha dari mekanisme plug-in yang diperbarui telah diimplementasikan, yang memungkinkan Anda untuk menambahkan perintah baru atau menulis ulang sub-perintah yang ada dari setiap level bersarang. Itu dibuat mirip dengan Git dan melihat executable dimulai dengan kubectl- di $PATH . Lihat proposal desain untuk lebih jelasnya.
Versi beta dari gagasan mengisolasi paket pkg/kubectl/genericclioptions dari kubectl ke dalam repositori independen telah diimplementasikan.
Fungsi pencetakan sisi server telah dinyatakan stabil.

Lainnya

Versi alfa dari TTL baru setelah mekanisme selesai , dirancang untuk membatasi masa kerja Jobs dan Pods yang telah selesai dieksekusi, disajikan . Setelah TTL yang ditentukan berakhir, objek akan secara otomatis dibersihkan tanpa perlu campur tangan pengguna.
Pembuatan kunci pribadi dan CSR (TLS Bootstrap) untuk menandatangani sertifikat di tingkat gugus di Kubelet dinyatakan stabil.
Rotasi sertifikat server TLS di Kubelet masuk ke status beta.

Kubernetes 1.12: ikhtisar inovasi utama