Kubernetes -
1.14 akan dirilis malam ini. Menurut tradisi yang telah dikembangkan untuk blog kami, kami berbicara tentang perubahan kunci dalam versi baru dari produk Open Source yang luar biasa ini.
Informasi yang digunakan untuk mempersiapkan bahan ini diambil dari
tabel pelacakan perangkat tambahan Kubernet ,
CHANGELOG-1.14 dan masalah terkait, permintaan tarik, Proposal Peningkatan Kubernetes (KEP).
UPDATE (26 Maret):
Pengumuman rilis resmi juga muncul di blog K8s.
Mari kita mulai dengan pengantar penting dari siklus-kluster SIG: kluster
failover dinamis Kubernetes (dan lebih tepatnya, penerapan HA yang di-host-sendiri) sekarang
dapat dibuat menggunakan perintah biasa (dalam konteks kluster node tunggal)
kubeadm (
init dan
join ) perintah. Singkatnya, untuk ini:
- sertifikat yang digunakan oleh cluster ditransfer ke rahasia;
- untuk kemungkinan menggunakan cluster etcd di dalam cluster K8s (mis., menyingkirkan ketergantungan eksternal yang telah ada sejauh ini), operator etcd digunakan ;
- Pengaturan yang disarankan untuk penyeimbang beban eksternal yang menyediakan konfigurasi toleran-kesalahan didokumentasikan (di masa depan, direncanakan untuk menolak ketergantungan ini, tetapi tidak pada tahap ini).
Arsitektur cluster Kubernetes HA dibangun dengan kubeadmRincian implementasi dapat ditemukan dalam
proposal desain . Fitur ini sangat lama ditunggu-tunggu: versi alpha diharapkan kembali di K8 1.9, tetapi hanya muncul sekarang.
API
Perintah
apply dan umumnya
manajemen objek deklaratif dipindahkan dari
kubectl ke apiserver. Pengembang sendiri menjelaskan secara singkat keputusan mereka dengan mengatakan bahwa
kubectl apply adalah bagian mendasar dari bekerja dengan konfigurasi di Kubernetes, namun, "penuh dengan bug dan sulit untuk diperbaiki", dan oleh karena itu fungsi ini perlu dikembalikan ke normal dan ditransfer ke bidang kontrol. Contoh sederhana dan ilustratif dari masalah saat ini:
Rincian implementasi ada di
KEP . Ketersediaan saat ini adalah versi alpha (promosi ke beta direncanakan untuk rilis Kubernetes berikutnya).
Dalam versi alpha,
kemampuan untuk menggunakan skema OpenAPI v3 untuk
membuat dan menerbitkan dokumentasi OpenAPI pada CustomResources (CR) yang digunakan untuk memvalidasi (sisi server) sumber daya K8 yang ditentukan pengguna (CustomResourceDefinition, CRD) telah tersedia. Menerbitkan OpenAPI untuk CRD memungkinkan klien (misalnya,
kubectl ) untuk melakukan validasi di pihak mereka (sebagai bagian dari
kubectl create dan
kubectl apply ) dan menerbitkan dokumentasi sesuai dengan skema (
kubectl explain ). Detailnya ada di
KEP .
Log yang sudah ada
sekarang terbuka dengan bendera
O_APPEND (bukan
O_TRUNC ) untuk menghindari hilangnya log dalam beberapa situasi dan untuk kenyamanan log truncate dengan utilitas rotasi eksternal.
Juga dalam konteks API Kubernetes, dapat dicatat bahwa di
PodSandbox dan
PodSandboxStatus bidang
PodSandboxStatus runtime_handler untuk mempertimbangkan informasi akun tentang
RuntimeClass di pod (baca lebih lanjut tentang hal itu dalam teks tentang
rilis Kubernetes 1.12 , di mana kelas ini muncul sebagai versi alpha), dan di Admission Webhooks
menerapkan kemampuan untuk menentukan versi
AdmissionReview mereka dukung. Akhirnya, dalam aturan Admission Webhooks,
Anda sekarang
dapat membatasi cakupan aplikasi mereka ke lingkup namespace dan cluster.
Fasilitas penyimpanan
PersistentLocalVolumes yang memiliki status beta sejak rilis
K8s 1.10 dinyatakan stabil (GA): gerbang fitur ini tidak lagi dinonaktifkan dan akan dihapus di Kubernetes 1.17.
Kemampuan untuk menggunakan variabel lingkungan dari apa yang disebut
Downward API (misalnya, nama pod) untuk nama direktori yang dipasang sebagai
subPath telah dikembangkan - dalam bentuk bidang
subPathExpr baru, yang dengannya nama direktori yang diinginkan sekarang ditentukan. Awalnya, fitur ini muncul di Kubernetes 1.11, tetapi untuk 1.14 tetap dalam status versi alpha.
Seperti rilis Kubernet sebelumnya, banyak perubahan signifikan diperkenalkan untuk CSI (Container Storage Interface) yang berkembang pesat:
CSI
Dukungan untuk mengubah ukuran dukungan untuk volume CSI telah tersedia (sebagai bagian dari versi alfa). Untuk menggunakannya, Anda harus mengaktifkan gerbang fitur yang disebut
ExpandCSIVolumes , serta keberadaan dukungan untuk operasi ini dalam driver CSI tertentu.
Fitur lain untuk CSI dalam versi alpha adalah
kemampuan untuk merujuk langsung (mis., Tanpa menggunakan PV / PVC) ke volume CSI sebagai bagian dari spesifikasi pod. Ini
menghilangkan pembatasan penggunaan CSI sebagai gudang data jarak jauh yang eksklusif , membuka pintu bagi mereka ke dunia
volume singkat lokal . Untuk menggunakan (
contoh dari dokumentasi ), Anda harus mengaktifkan gerbang fitur
CSIInlineVolume .
Ada kemajuan dalam "internal" Kubernet yang terkait dengan CSI, yang tidak begitu terlihat oleh pengguna akhir (administrator sistem) ... Saat ini, pengembang dipaksa untuk mendukung dua versi setiap plugin penyimpanan: satu "dengan mode lama", di dalam basis kode K8 (di -tree), dan yang kedua - sebagai bagian dari CSI baru
(baca lebih lanjut, misalnya, di sini ) . Hal ini menyebabkan ketidaknyamanan yang dapat dimengerti yang perlu diatasi karena CSI menjadi stabil. Cukup menghentikan API yang sudah tidak digunakan dari plug-in in-tree tidak dimungkinkan karena
kebijakan Kubernetes yang sesuai .
Semua ini mengarah pada fakta bahwa versi alpha mencapai
proses migrasi kode internal plug-in yang diimplementasikan sebagai in-tree ke plugin CSI, karena kekhawatiran pengembang akan berkurang untuk mendukung satu versi plug-in mereka, dan kompatibilitas dengan API lama akan dipertahankan dan mereka dapat dipertahankan. menyatakan usang seperti biasa. Diharapkan pada rilis Kubernetes berikutnya (1,15), semua plugin penyedia cloud akan dimigrasi, implementasinya akan menerima status beta dan akan diaktifkan di instalasi K8 default. Lihat
proposal desain untuk detailnya. Migrasi ini juga menghasilkan
penolakan pembatasan untuk volume yang ditentukan oleh penyedia cloud tertentu (AWS, Azure, GCE, Cinder).
Selain itu, dukungan untuk perangkat blok CSI (
CSIBlockVolume ) telah
dikonversi ke beta.
Nodes / Kubelet
Memperkenalkan versi alfa dari
titik akhir baru di Kubelet, yang dirancang untuk
mengembalikan metrik untuk sumber daya utama . Secara umum, jika Kubelet digunakan untuk mendapatkan statistik tentang penggunaan kontainer dari cAdvisor, sekarang data ini berasal dari runtime kontainer melalui CRI (Container Runtime Interface), tetapi kompatibilitas dengan versi lama Docker tetap dipertahankan. Sebelumnya, statistik yang dikumpulkan di Kubelet disediakan melalui REST API, tetapi sekarang menggunakan titik akhir yang terletak di
/metrics/resource/v1alpha1 . Strategi jangka panjang para pengembang
adalah meminimalkan set metrik yang disediakan oleh Kubelet.
Omong-omong, metrik ini sendiri sekarang disebut bukan "metrik inti", tetapi "metrik sumber daya", dan digambarkan sebagai "sumber daya kelas satu, seperti cpu, dan memori".Nuansa yang sangat menarik: terlepas dari keuntungan yang jelas dalam kinerja endpoint gRPC dibandingkan dengan kasus yang berbeda menggunakan format Prometheus
(hasil dari salah satu benchmark'ov lihat di bawah) , penulis lebih suka format teks Prometheus karena kepemimpinan yang jelas dari sistem pemantauan ini di masyarakat.
“GRPC tidak kompatibel dengan jaringan pipa pemantauan utama. Endpoint hanya akan berguna untuk mengirimkan metrik ke Server Metrik atau memonitor komponen yang terintegrasi langsung dengannya. Saat menggunakan caching di Metrics Server, kinerja format teks Prometheus cukup baik bagi kami untuk lebih memilih Prometheus daripada gRPC, mengingat penggunaan Prometheus yang luas di komunitas. Ketika format OpenMetrics menjadi lebih stabil, kita bisa lebih dekat dengan kinerja gRPC dengan format berbasis proto. "
Salah satu tes kinerja komparatif menggunakan format gRPC dan Prometheus di titik akhir Kubelet baru untuk metrik. Lebih banyak grafik dan detail lainnya dapat ditemukan di KEP .Di antara perubahan lainnya:
- Kubelet sekarang menerima parameter
pid=<number> dalam opsi --system-reserved dan --kube-reserved , memastikan bahwa PID yang ditentukan akan dicadangkan untuk keseluruhan sistem atau daemon sistem Kubernetes, masing-masing. Fitur ini diaktifkan ketika gerbang fitur diaktifkan, yang disebut SupportNodePidsLimit . - Kubelet sekarang (sekali) mencoba untuk menghentikan kontainer dalam keadaan yang tidak diketahui sebelum memulai kembali dan menghapus operasi.
- Saat menggunakan
PodPresets , informasi yang sama sekarang ditambahkan ke wadah init sebagai wadah biasa. - Kubelet mulai menggunakan
usageNanoCores penggunaan dari penyedia statistik CRI, dan statistik jaringan ditambahkan untuk node dan wadah pada Windows. - Informasi tentang sistem operasi dan arsitektur sekarang direkam dalam
kubernetes.io/os dan kubernetes.io/arch dari objek Node (ditransfer dari beta ke GA). - Kemampuan untuk menentukan grup pengguna sistem tertentu untuk kontainer di pod (
RunAsGroup , muncul di K8 1.11 ) telah berkembang ke versi beta (diaktifkan secara default). - du dan temukan yang digunakan dalam cAdvisor digantikan oleh implementasi Go.
CLI
Bendera -k telah
ditambahkan ke cli-runtime dan kubectl untuk integrasi dengan
kustomize (omong-omong, ini sekarang sedang dikembangkan di repositori terpisah), yaitu untuk memproses file YAML tambahan dari direktori kustomisasi khusus (untuk detail tentang penggunaannya, lihat
KEP ):
Contoh penggunaan sederhana dari file kustomisasi (penggunaan kustomisasi yang lebih rumit dalam overlay juga dimungkinkan )Selain itu:
- Logo kubectl dan dokumentasinya telah diperbarui - lihat kubectl.docs.kubernetes.io .
kubectl create cronjob baru kubectl create cronjob perintah kubectl create cronjob telah kubectl create cronjob , nama yang berbicara untuk dirinya sendiri.- Dalam
kubectl logs Anda sekarang dapat menggabungkan flag -f ( --follow untuk streaming log) dan -l ( --selector untuk kueri label). - kubectl diajarkan untuk menyalin file yang dipilih dengan kartu liar.
- Bendera
--all ditambahkan ke perintah kubectl wait untuk memilih semua sumber daya di namespace dari jenis sumber daya yang ditentukan. - Menyatakan mekanisme plugin stabil untuk kubectl .
Lainnya
Status Stabil (GA) menerima fitur-fitur berikut:
- Dukungan untuk node Windows (termasuk Windows Server 2019), yang menyiratkan kemungkinan merencanakan kontainer Windows Server di Kubernetes (lihat juga KEP );
ReadinessGate digunakan dalam spesifikasi pod untuk menentukan kondisi tambahan yang dipertimbangkan dalam kesiapan pod;- Dukungan untuk halaman besar (gerbang fitur yang disebut
HugePages ); - CustomPodDNS ;
- API PriorityClass, Prioritas Pod & Preemption .
Perubahan lain yang diperkenalkan di Kubernetes 1.14:
- Kebijakan RBAC default tidak lagi menyediakan akses ke API
discovery dan ulasan access-review untuk pengguna yang tidak diauthentikasi. - Dukungan resmi untuk CoreDNS disediakan hanya untuk Linux, jadi ketika menggunakan kubeadm untuk penyebarannya (CoreDNS) dalam sebuah cluster, node harus bekerja hanya di Linux (nodeSelector digunakan untuk batasan ini).
- Konfigurasi CoreDNS default sekarang menggunakan plugin forward bukan proxy. Selain itu, readinessProbe telah ditambahkan ke CoreDNS, yang mencegah load balancing pada pod yang sesuai (tidak siap untuk layanan).
- Di kubeadm, dalam
upload-certs init atau upload-certs , dimungkinkan untuk mengunggah sertifikat yang diperlukan untuk menghubungkan bidang kontrol baru ke rahasia kubeadm-certs ( --experimental-upload-certs digunakan). - Untuk instalasi Windows, versi alpha dukungan untuk gMSA (Group Managed Service Account) - akun khusus di Active Directory, yang dapat digunakan oleh kontainer, telah muncul.
- Untuk GCE , enkripsi mTLS diaktifkan antara etcd dan kube-apiserver.
- Pembaruan dalam perangkat lunak yang digunakan / tergantung: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, dukungan Docker 18.09 di kubeadm, dan versi minimum yang didukung dari Docker API adalah 1.26.
PS
Baca juga di blog kami: