Kubernetes 1.14: ikhtisar inovasi utama

Malam ini diselenggarakan rilis Kubernetes berikutnya - 1.14. Menurut tradisi yang telah berkembang di blog kami, kami berbicara tentang perubahan penting dalam versi baru produk Open Source yang luar biasa ini.

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

Mari kita mulai dengan pengenalan penting dari siklus hidup klaster SIG: cluster failover dinamis Kubernetes (atau lebih tepatnya, penerapan HA yang dihosting sendiri) sekarang sudah ada kamu bisa membuat menggunakan perintah yang familiar (dalam konteks cluster node tunggal). kubeadm (init и join). Singkatnya, untuk ini:

• sertifikat yang digunakan oleh cluster ditransfer ke rahasia;
• untuk kemungkinan menggunakan cluster etcd di dalam cluster K8s (yaitu menghilangkan ketergantungan eksternal yang sudah ada sebelumnya) dlld-operator;
• Mendokumentasikan pengaturan yang direkomendasikan untuk penyeimbang beban eksternal yang menyediakan konfigurasi toleransi kesalahan (di masa depan direncanakan untuk menghilangkan ketergantungan ini, tetapi tidak pada tahap ini).

Arsitektur cluster Kubernetes HA yang dibuat dengan kubeadm

Detail implementasinya dapat dilihat di usulan desain. Fitur ini benar-benar sudah lama ditunggu-tunggu: versi alfa diharapkan ada di K8s 1.9, tetapi baru muncul sekarang.

API

Tim apply dan secara umum manajemen objek deklaratif lulus dari kubectl di apiserver. Para pengembang sendiri secara singkat menjelaskan keputusan mereka dengan mengatakan bahwa kubectl apply - bagian mendasar dari bekerja dengan konfigurasi di Kubernetes, namun “penuh dengan bug dan sulit diperbaiki,” dan oleh karena itu fungsi ini perlu dikembalikan ke normal dan ditransfer ke bidang kendali. Contoh sederhana dan jelas permasalahan yang ada saat ini:

Detail implementasinya ada di KEP. Kesiapan saat ini adalah alpha (promosi ke beta direncanakan untuk rilis Kubernetes berikutnya).

Tersedia dalam versi alfa kesempatan menggunakan skema OpenAPI v3 untuk membuat dan menerbitkan dokumentasi OpenAPI untuk CustomResources (CR) digunakan untuk memvalidasi (sisi server) sumber daya yang ditentukan pengguna K8 (CustomResourceDefinition, CRD). Penerbitan OpenAPI untuk CRD memungkinkan klien (mis. kubectl) melakukan validasi di sisi Anda (dalam kubectl create и kubectl apply) dan menerbitkan dokumentasi sesuai skema (kubectl explain). Detail - masuk KEP.

Log yang sudah ada sebelumnya sekarang dibuka dengan bendera O_APPEND (tapi tidak O_TRUNC) untuk menghindari hilangnya log dalam beberapa situasi dan untuk kenyamanan memotong log dengan utilitas eksternal untuk rotasi.

Juga dalam konteks API Kubernetes, dapat dicatat bahwa di PodSandbox и PodSandboxStatus ditambahkan bidang runtime_handler untuk mencatat informasi tentang RuntimeClass di pod (baca lebih lanjut tentang itu di teks tentang Rilis Kubernetes 1.12, di mana kelas ini muncul sebagai versi alfa), dan di Webhook Penerimaan diimplementasikan kemampuan untuk menentukan versi mana AdmissionReview mereka mendukung. Terakhir, aturan Pendaftaran Webhook sekarang dapat dibatasi sejauh mana penggunaannya oleh namespace dan kerangka cluster.

Penyimpanan

PersistentLocalVolumes, yang memiliki status beta sejak dirilis K8 1.10, ое stable (GA): gerbang fitur ini tidak lagi dinonaktifkan dan akan dihapus di Kubernetes 1.17.

Kesempatan menggunakan variabel lingkungan yang disebut API ke bawah (misalnya, nama pod) untuk nama direktori yang dipasang sebagai subPath, dikembangkan - dalam bentuk bidang baru subPathExpr, yang sekarang digunakan untuk menentukan nama direktori yang diinginkan. Fitur ini awalnya muncul di Kubernetes 1.11, namun untuk versi 1.14 tetap dalam status versi alfa.

Seperti rilis Kubernetes sebelumnya, banyak perubahan signifikan yang diperkenalkan untuk CSI (Container Storage Interface) yang sedang berkembang secara aktif:

CSI

Telah tersedia (sebagai bagian dari versi alfa) mendukung mengubah ukuran untuk volume CSI. Untuk menggunakannya, Anda harus mengaktifkan gerbang fitur yang disebut ExpandCSIVolumes, serta adanya dukungan untuk operasi ini di driver CSI tertentu.

Fitur lain untuk CSI dalam versi alpha - kesempatan merujuk secara langsung (yaitu tanpa menggunakan PV/PVC) ke volume CSI dalam spesifikasi pod. Ini menghilangkan pembatasan penggunaan CSI sebagai penyimpanan data jarak jauh secara eksklusif, membuka pintu dunia bagi mereka volume sementara lokal. Untuk digunakan (contoh dari dokumentasi) harus diaktifkan CSIInlineVolume gerbang fitur.

Ada juga kemajuan dalam “internal” Kubernetes yang terkait dengan CSI, yang tidak begitu terlihat oleh pengguna akhir (administrator sistem)... Saat ini, pengembang terpaksa mendukung dua versi dari setiap plugin penyimpanan: satu - “di cara lama”, di dalam basis kode K8 (di -pohon), dan yang kedua - sebagai bagian dari CSI baru (baca lebih lanjut tentang itu, misalnya di di sini). Hal ini menyebabkan ketidaknyamanan yang perlu diatasi seiring dengan stabilnya CSI. Tidak mungkin untuk menghentikan API plugin internal (dalam pohon) begitu saja karena kebijakan Kubernetes yang relevan.

Semua ini mengarah pada fakta bahwa versi alfa telah tercapai proses migrasi kode plugin internal, diimplementasikan sebagai in-tree, di plugin CSI, sehingga kekhawatiran pengembang akan berkurang untuk mendukung satu versi plugin mereka, dan kompatibilitas dengan API lama akan tetap ada dan dapat dinyatakan usang dalam skenario biasa. Diharapkan pada rilis Kubernetes berikutnya (1.15) semua plugin penyedia cloud akan dimigrasikan, implementasinya akan menerima status beta dan akan diaktifkan di instalasi K8 secara default. Untuk detailnya, lihat usulan desain. Migrasi ini juga mengakibatkan kegagalan dari batas volume yang ditentukan oleh penyedia cloud tertentu (AWS, Azure, GCE, Cinder).

Selain itu, dukungan untuk perangkat blok dengan CSI (CSIBlockVolume) ditransfer ke versi beta.

Node/Kubelet

Versi alfa disajikan titik akhir baru di Kubelet, dirancang untuk mengembalikan metrik pada sumber daya utama. Secara umum, jika sebelumnya Kubelet menerima statistik penggunaan container dari cAdvisor, kini data tersebut berasal dari lingkungan runtime container melalui CRI (Container Runtime Interface), namun kompatibilitas untuk bekerja dengan Docker versi lama juga tetap dipertahankan. Sebelumnya, statistik yang dikumpulkan di Kubelet dikirim melalui REST API, tetapi sekarang titik akhir berada di /metrics/resource/v1alpha1. Strategi jangka panjang pengembang terdiri adalah meminimalkan kumpulan metrik yang disediakan oleh Kubelet. Omong-omong, metrik ini sendiri sekarang mereka menelepon bukan “metrik inti”, tetapi “metrik sumber daya”, dan digambarkan sebagai “sumber daya kelas satu, seperti cpu, dan memori”.

Nuansa yang sangat menarik: meskipun titik akhir gRPC memiliki keunggulan kinerja yang jelas dibandingkan dengan berbagai kasus penggunaan format Prometheus (lihat hasil salah satu benchmark di bawah), penulis lebih menyukai format teks Prometheus karena kepemimpinan yang jelas dari sistem pemantauan ini di komunitas.

“gRPC tidak kompatibel dengan pipeline pemantauan utama. Endpoint hanya akan berguna untuk mengirimkan metrik ke Metrics Server atau memantau komponen yang terintegrasi langsung dengannya. Performa format teks Prometheus saat menggunakan caching di Metrics Server cukup baik bagi kami untuk lebih memilih Prometheus daripada gRPC mengingat luasnya adopsi Prometheus di komunitas. Setelah format OpenMetrics menjadi lebih stabil, kami akan dapat mendekati performa gRPC dengan format berbasis proto."

Salah satu uji performa komparatif penggunaan format gRPC dan Prometheus di titik akhir Kubelet baru untuk metrik. Grafik lebih lanjut dan detail lainnya dapat ditemukan di KEP.

Perubahan lainnya antara lain:

• Kubelet sekarang (satu kali) mencoba untuk berhenti kontainer dalam keadaan tidak diketahui sebelum memulai kembali dan menghapus operasi.
• Bila menggunakan PodPresets sekarang ke wadah init ditambahkan informasi yang sama seperti untuk wadah biasa.
• kubelet mulai menggunakan usageNanoCores dari penyedia statistik CRI, dan untuk node dan kontainer di Windows ditambahkan statistik jaringan.
• Informasi sistem operasi dan arsitektur kini dicatat dalam label kubernetes.io/os и kubernetes.io/arch Objek node (ditransfer dari beta ke GA).
• Kemampuan untuk menentukan grup pengguna sistem tertentu untuk container di dalam pod (RunAsGroup, muncul di K8 1.11) canggih sebelum beta (diaktifkan secara default).
• du dan temukan digunakan di cAdvisor, diganti implementasi di Go.

CLI

Di cli-runtime dan kubectl ditambahkan -k tandai untuk integrasi dengan sesuaikan (omong-omong, pengembangannya sekarang dilakukan di repositori terpisah), mis. untuk memproses file YAML tambahan dari direktori kustomisasi khusus (untuk detail penggunaannya, lihat KEP):

Contoh penggunaan file sederhana penyesuaian (aplikasi kustomisasi yang lebih kompleks dimungkinkan di dalamnya hamparan)

Selain itu:

• Ditambahkan tim baru kubectl create cronjob, yang namanya berbicara sendiri.
• В kubectl logs sekarang kamu bisa menggabungkan bendera -f (--follow untuk log streaming) dan -l (--selector untuk permintaan label).
• kubectl diajari salin file yang dipilih dengan wild card.
• Untuk tim kubectl wait ditambahkan bendera --all untuk memilih semua sumber daya di namespace jenis sumber daya yang ditentukan.

Lainnya

Kemampuan berikut telah menerima status stabil (GA):

• ReadinessGate, digunakan dalam spesifikasi pod untuk menentukan kondisi tambahan yang diperhitungkan dalam kesiapan pod;
• Dukungan untuk halaman besar (fitur gerbang disebut HugePages);
• PodDNS Khusus;
• API Kelas Prioritas, Prioritas & Preemption Pod.

Perubahan lain yang diperkenalkan di Kubernetes 1.14:

• Kebijakan RBAC default tidak lagi mengizinkan akses API discovery и access-review pengguna tanpa otentikasi (tidak diautentikasi).
• Dukungan resmi CoreDNS dipastikan Khusus Linux, jadi ketika menggunakan kubeadm untuk menyebarkannya (CoreDNS) dalam sebuah cluster, node hanya boleh berjalan di Linux (nodeSelectors digunakan untuk batasan ini).
• Konfigurasi CoreDNS default sekarang menggunakan plugin maju bukannya proksi. Juga, di CoreDNS ditambahkan kesiapanProbe, yang mencegah penyeimbangan beban pada pod yang sesuai (belum siap untuk diservis).
• Di kubeadm, secara bertahap init или upload-certs, menjadi mungkin muat sertifikat yang diperlukan untuk menghubungkan bidang kontrol baru ke rahasia kubeadm-certs (gunakan flag --experimental-upload-certs).
• Versi alfa telah muncul untuk instalasi Windows mendukung gMSA (Akun Layanan Terkelola Grup) - akun khusus di Direktori Aktif yang juga dapat digunakan oleh kontainer.
• Untuk G.C.E. diaktifkan enkripsi mTLS antara etcd dan kube-apiserver.
• Pembaruan pada 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 Docker API yang didukung sekarang adalah 1.26.

PS

Baca juga di blog kami:

• «Kubernetes 1.13: ikhtisar inovasi utama»;
• «Kubernetes 1.12: ikhtisar inovasi utama»;
• «Kubernetes 1.11: ikhtisar inovasi utama»;
• «Kubernetes 1.10: ikhtisar inovasi utama'.

Sumber: www.habr.com