👊🏻 ↩️ ㊙️ Kubernetes 1.17: Tinjauan Umum Inovasi-inovasi Utama 🎿 👨‍🍳 🔽

Kemarin, 9 Desember, rilis Kubernetes berikutnya - 1,17. Menurut tradisi untuk blog kami, kami berbicara tentang perubahan paling signifikan dalam versi baru.

Informasi yang digunakan untuk mempersiapkan bahan ini diambil dari pengumuman resmi, tabel pelacakan perangkat tambahan Kubernet , CHANGELOG-1.17 dan masalah terkait, permintaan tarik, serta Kubernetes Enhancement Proposals (KEP). Jadi, apa yang baru?

Routing Berbasis Topologi

Untuk waktu yang lama, komunitas Kubernetes telah menunggu fitur ini - Routing layanan yang sadar topologi . Jika KEP didasarkan pada Oktober 2018, dan peningkatan resmi adalah 2 tahun yang lalu, maka masalah biasa (seperti ini ) bahkan beberapa tahun lebih tua ...

Gagasan umum bermula untuk menyediakan kemampuan untuk mengimplementasikan perutean “lokal” untuk layanan yang berlokasi di Kubernetes. "Lokalitas" dalam hal ini berarti "tingkat topologi yang sama" (tingkat topologi) , yang mungkin:

simpul yang sama untuk layanan,
rak server yang sama
wilayah yang sama
penyedia cloud yang sama
...

Contoh penggunaan fitur seperti itu:

menghemat lalu lintas di instalasi cloud dengan beberapa zona ketersediaan (multi-AZ) - lihat ilustrasi terbaru tentang contoh lalu lintas dari satu wilayah, tetapi AZ berbeda di AWS;
kurang latensi dalam kinerja / throughput yang lebih baik;
layanan berjuntai yang memiliki informasi simpul lokal di setiap beling;
menempatkan fluentd (atau analog) pada satu node dengan aplikasi yang lognya dikumpulkan;
...

Rute ini, "mengetahui" tentang topologi, juga disebut afinitas afinitas jaringan - mirip dengan afinitas simpul , afinitas pod / anti-afinitas atau Penjadwalan Volume Topologi-Sadar yang baru - baru ini diperkenalkan (dan Penyediaan Volume ). Level implementasi ServiceTopology di Kubernetes saat ini adalah versi alpha.

Untuk detail tentang bagaimana fitur diatur dan bagaimana fitur itu sudah dapat digunakan, baca artikel ini dari salah satu penulis.

Dukungan dual stack IPv4 / IPv6

Kemajuan yang signifikan dicatat dalam fitur jaringan lain: dukungan simultan dari dua tumpukan IP, yang pertama kali diperkenalkan pada K8 1.16 . Secara khusus, rilis baru membawa perubahan berikut:

kube-proxy mengimplementasikan kemungkinan operasi simultan di kedua mode (IPv4 dan IPv6);
dukungan untuk API ke bawah telah muncul di Pod.Status.PodIPs (pada saat yang sama, /etc/hosts sekarang memerlukan penambahan alamat IPv6 untuk host);
dukungan untuk dua tumpukan di JENIS (Kubernetes IN Docker) dan kubeadm ;
Tes e2e yang diperbarui.

JENIS IPV4 / IPv6 Ilustrasi Tumpukan Ganda

Kemajuan CSI

Dukungan topologi untuk repositori berbasis CSI, pertama kali diperkenalkan pada K8 1.12, telah dinyatakan stabil .

Inisiatif Plugin Volume Migrasi CSI - Migrasi CSI - Mencapai Beta. Fitur ini sangat penting untuk mentransfer plug-in in -tree yang ada ke antarmuka modern (CSI, out-of-tree) tanpa disadari oleh pengguna akhir Kubernetes. Administrator cluster akan cukup untuk mengaktifkan Migrasi CSI, setelah itu sumber daya dan beban kerja stateful yang ada masih akan "hanya bekerja" ... tetapi menggunakan driver CSI saat ini alih-alih yang sudah ketinggalan zaman termasuk dalam kernel Kubernetes.

Saat ini, status migrasi untuk driver AWS EBS ( kubernetes.io/aws-ebs ) dan GCE PD ( kubernetes.io/gce-pd ) siap dalam status beta. Ramalan untuk repositori lain adalah sebagai berikut:

Bagaimana dukungan penyimpanan "tradisional" di K8 datang ke CSI, kami bicarakan di artikel ini . Transisi ke migrasi CSI dalam status beta didedikasikan untuk publikasi terpisah di blog proyek.

Selain itu, status versi beta (mis., Penyertaan secara default) di rilis Kubernetes 1.17 dicapai oleh fungsionalitas signifikan lainnya dalam konteks CSI, yang berasal dari (implementasi alpha) di K8 1.12 - membuat snapshot dan memulihkan dari mereka . Di antara perubahan yang dibuat di Kubernetes Volume Snapshot dalam perjalanan ke rilis beta:

membagi sespan CSI eksternal-snapshotter menjadi dua pengendali,
menambahkan rahasia penghapusan sebagai penjelasan pada isi snapshot volume,
Finalizer baru untuk mencegah penghapusan objek API snapshot jika ada koneksi yang tersisa.

Pada saat rilis 1.17, fitur ini didukung oleh tiga driver CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver dan NetApp Trident CSI Driver. Anda dapat membaca lebih lanjut tentang penerapan dan penggunaannya dalam posting blog ini .

Label Penyedia Cloud

Label yang secara otomatis ditetapkan untuk node dan volume yang dibuat tergantung pada penyedia cloud yang digunakan telah tersedia di Kubernet sebagai beta untuk waktu yang sangat lama - dimulai dengan rilis K8 1.2 (April 2016!) . Mengingat penggunaannya yang tersebar luas untuk waktu yang lama, para pengembang memutuskan sudah waktunya untuk menyatakan fitur stable (GA).

Oleh karena itu, mereka semua diganti namanya (berdasarkan topologi):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... tetapi masih tersedia dengan nama lama mereka (untuk kompatibilitas ke belakang). Namun, semua administrator disarankan untuk beralih ke label saat ini. Dokumentasi K8 yang relevan telah diperbarui.

Output kubus terstruktur

Dalam format alfa, output terstruktur untuk utilitas kubeadm disajikan untuk pertama kalinya. Format yang didukung: JSON, YAML, Go-template.

Motivasi untuk menerapkan fitur ini (menurut KEP ) adalah sebagai berikut:

Meskipun Kubernetes dapat digunakan secara manual, standar de facto (jika tidak de jure) untuk operasi ini adalah menggunakan kubeadm. Alat manajemen sistem yang populer seperti Terraform mengandalkan kubeadm untuk penyebaran Kubernetes. Peningkatan terjadwal untuk API Cluster mencakup paket komposable untuk bootstrap Kubernet dengan kubeadm dan cloud-init.

Tanpa output terstruktur, bahkan perubahan sekilas yang paling tidak berbahaya dapat merusak Terraform, Cluster API, dan perangkat lunak lain yang menggunakan hasil kubeadm.

Dalam waktu dekat, dukungan muncul (dalam bentuk output terstruktur) untuk perintah kubeadm berikut:

alpha certs
config images list
init
token create
token list
upgrade plan
version

Ilustrasi respons JSON terhadap perintah kubeadm init -o json :

 { "node0": "192.168.20.51:443", "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3", "token": { "id": "5ndzuu.ngie1sxkgielfpb1", "ttl": "23h", "expires": "2019-05-08T18:58:07Z", "usages": [ "authentication", "signing" ], "description": "The default bootstrap token generated by 'kubeadm init'.", "extraGroups": [ "system:bootstrappers:kubeadm:default-node-token" ] }, "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c=" }

Stabilisasi inovasi lainnya

Secara umum, rilis Kubernetes 1.17 diadakan di bawah moto " Stabilitas ". Ini difasilitasi oleh fakta bahwa begitu banyak fitur di dalamnya (jumlah totalnya adalah 14 ) menerima status GA. Di antara mereka:

"Menandai" node dalam kondisi tertentu ( TaintNodesByCondition ), yang muncul di K8 1.8 ;
Tonton Penanda - jenis peristiwa baru dengan label yang semua objek hingga versi tertentu ( resourceVersion ) telah diproses oleh arloji;
nilai default untuk Sumber Daya Kustom;
dibagi di antara kontainer di ruang nama proses pod;
ScheduleDaemonSetPods - penjadwalan pod di DaemonSet menggunakan kube-scheduler (bukan pengontrol DaemonSet);
batas dinamis pada jumlah volume tergantung pada jenis node;
dukungan untuk variabel lingkungan untuk nama direktori yang dipasang sebagai subPath ;
memindahkan detak jantung Kubelet ke API Sewa khusus;
“ Perlindungan Finalizer ” untuk penyeimbang beban (memeriksa sumber daya Layanan yang sesuai sebelum menghapus sumber daya LoadBalancer);
mengoptimalkan kube-apiserver dalam kinerja ketika bekerja dengan beberapa jam tangan yang memonitor set objek yang identik dicapai dengan menghindari serialisasi berulang dari objek yang sama untuk setiap pengamat.

Perubahan lainnya

Daftar lengkap inovasi di Kubernetes 1.17, tentu saja, tidak terbatas pada yang tercantum di atas. Berikut ini beberapa di antaranya (dan untuk daftar yang lebih lengkap - lihat CHANGELOG ):

Versi beta RunAsUserName untuk Windows yang disajikan dalam rilis sebelumnya telah berkembang ke versi beta;
perubahan yang serupa menimpa EndpointSlice API (juga dari K8s 1.16), tetapi sejauh ini solusi untuk meningkatkan kinerja / skalabilitas Endpoint API ini belum diaktifkan secara default;
pod kritis untuk operasi klaster sekarang dapat dibuat tidak hanya di ruang nama kube-system (lihat dokumentasi untuk konsumsi Kelas Prioritas Batas untuk perincian) ;
opsi baru untuk kubelet - --reserved-cpus - memungkinkan Anda untuk secara eksplisit menentukan daftar CPU yang disediakan untuk sistem;
untuk kubectl logs bendera baru disajikan - awalan, menambahkan nama pod dan sumber wadah untuk setiap baris log;
dalam label.Selector ditambahkan RequiresExactMatch ;
semua kontainer di kube-dns sekarang dijalankan dengan privilege yang lebih sedikit;
hyperkube dialokasikan ke repositori GitHub yang terpisah dan tidak akan lagi disertakan dalam rilis Kubernetes;
secara signifikan meningkatkan kinerja proxy kubus untuk port non-UDP.

Perubahan Ketergantungan:

Versi CoreDNS di kubeadm - 1.6.5;
versi crictl diperbarui ke v1.16.1;
CSI 1.2.0;
dll 3.4.3;
Versi teruji terbaru dari Docker telah ditingkatkan ke 03/19;
versi Go minimum yang diperlukan untuk membangun Kubernetes 1.17 adalah 1.13.4.

Kubernetes 1.17: Tinjauan Umum Inovasi-inovasi Utama