Pada awal minggu ini
, rilis Kubernetes berikutnya
terjadi , yang dijuluki "malaikat,"
1,13 . Nama ini dikaitkan dengan angka 113, yang
dianggap "malaikat" dan, menurut pengembang Kubernetes, melambangkan "permulaan baru, transformasi, dan akhir satu bab sebelum membuka yang baru." Tanpa masuk ke analisis lebih lanjut tentang simbolisme dari apa yang terjadi, sesuai dengan tradisi yang telah ditetapkan untuk blog kita, untuk ketujuh kalinya kita akan berbicara tentang perubahan kunci dalam versi baru Kubernetes, yang dirancang untuk menyenangkan DevOps- / SRE-insinyur yang bekerja dengan produk ini.
Sebagai sumber informasi, kami mengoperasikan data dari
pelacakan peningkatan Kubernetes , tabel
CHANGELOG-1.13 dan masalah terkait, permintaan tarik, Proposal Peningkatan Kubernetes (KEP).
GA untuk kubeadm
Salah satu peristiwa utama dari rilis Kubernetes 1.13 adalah pengumuman status stabil (Ketersediaan Umum, GA) untuk utilitas konsol
kubeadm . Blog K8 bahkan telah mendedikasikan
publikasi terpisah untuk ini . Seperti yang diketahui banyak orang, kubeadm adalah alat untuk membuat cluster Kubernetes sesuai dengan praktik terbaik proyek, serta dukungan minimal lebih lanjut. Fitur khusus adalah bahwa pengembang berusaha untuk tetap kompak dan independen dari penyedia / infrastruktur, tidak termasuk solusi untuk masalah-masalah seperti penyediaan infrastruktur, solusi jaringan pihak ketiga, add-on (pemantauan, logging, dll.), Integrasi khusus dengan cloud penyedia layanan.
Status GA menandai kedewasaan kubeadm di area berikut:
- antarmuka konsol stabil yang mengikuti kebijakan usang Kubernetes: perintah dan bendera yang disajikan dalam rilis GA harus didukung selama setidaknya satu tahun setelah mereka ditinggalkan;
- implementasi yang stabil "di bawah tenda" karena fakta bahwa cluster dibuat oleh metode yang tidak akan berubah dalam waktu dekat: bidang kontrol dimulai sebanyak pod statis, token bootstrap digunakan untuk
kubeadm join , dan ComponentConfig digunakan untuk mengkonfigurasi kubelet; - skema konfigurasi dengan API baru (v1beta1), yang memungkinkan mendeskripsikan secara deskriptif hampir semua komponen kluster (GitOps dimungkinkan untuk cluster yang dibuat dengan kubeadm) - upgrade ke versi v1 direncanakan tanpa perubahan atau minimal;
- fase yang disebut (atau antarmuka toolbox ) di kubeadm (
kubeadm init phase ), memungkinkan Anda untuk memilih prosedur inisialisasi yang akan dilakukan; - Tim
kubeadm upgrade menjamin pembaruan cluster antara rilis 1.10.x, 1.11.x, 1.12.x dan 1.13.x (pembaruan etcd, API Server, Controller Manager dan Scheduler); - instalasi aman etcd secara default (menggunakan TLS di mana-mana) dengan kemampuan untuk memperluas ke HA-cluster jika perlu.
Dapat juga dicatat bahwa kubeadm sekarang dengan benar mengenali Docker 18.09.0 dan versi yang lebih baru. Akhirnya, pengembang meminta pengguna kubeadm untuk mengambil
survei online kecil di mana mereka dapat mengekspresikan keinginan mereka tentang penggunaan dan pengembangan proyek.
CoreDNS secara default
CoreDNS, yang menerima status stabil dalam rilis
Kubernetes 1.11 , bahkan melangkah lebih jauh dan
menjadi server DNS default di K8s (bukan kube-dns yang selama ini digunakan). Direncanakan bahwa ini akan terjadi pada awal 1,12, tetapi pengembang dihadapkan dengan kebutuhan untuk optimasi tambahan dalam skalabilitas dan konsumsi memori, yang diselesaikan hanya dengan rilis saat ini.
Dukungan untuk kube-dns akan terus "setidaknya untuk satu rilis berikutnya," tetapi pengembang sedang berbicara tentang perlunya
untuk mulai bermigrasi ke solusi terkini sekarang.
Dari perubahan yang terkait dengan topik CoreDNS di Kubernetes 1.13, plugin
NodeLocal DNS Cache juga
dapat dicatat untuk meningkatkan kinerja DNS. Peningkatan dicapai dengan menjalankan agen pada node cluster untuk cache DNS, yang akan diakses langsung oleh pod dari node ini. Secara default, fungsi ini dinonaktifkan, dan untuk mengaktifkannya, Anda harus menetapkan
KUBE_ENABLE_NODELOCAL_DNS=true .
Fasilitas penyimpanan
Banyak perhatian dalam rilis terbaru Kubernetes diberikan untuk bekerja dengan
Container Storage Interface (CSI), yang dimulai dengan versi alpha CSI di
K8 1.9 , dilanjutkan dengan versi beta di
1.10 ... Namun, kami telah
menulis lebih
dari satu kali . Tonggak sejarah baru yang signifikan telah dicapai dalam K8 1.13:
dukungan CSI dinyatakan stabil (GA).
(Diagram dari artikel " Memahami Antarmuka Penyimpanan Kontainer ")Bersamaan dengan ini, dukungan untuk spesifikasi CSI v1.0.0 muncul dan dukungan untuk versi standar yang lebih lama (0,3 dan yang lebih lama) sudah tidak digunakan lagi. Ini berarti bahwa driver CSI yang lebih lama akan memerlukan peningkatan ke CSI 1.0 (dan pindah ke direktori registrasi plugin Kubelet baru) untuk bekerja di Kubernetes 1.15 dan yang lebih lama. Ngomong-ngomong, dari driver sendiri, perlu diperhatikan
tampilan versi alpha dari antarmuka CSI untuk mengelola siklus hidup volume AWS EBS (Elastic Block Store).
Tambahan baru pada addon manager sekarang secara otomatis menginstal CRI dari CSI jika setidaknya satu dari dua gerbang fitur diaktifkan:
CSIDriverRegistry dan
CSINodeInfo . Ini memiliki status versi alpha, tetapi sebenarnya itu hanya solusi sementara untuk masalah ini, yang dijelaskan secara rinci sebagai
mekanisme instalasi CRD .
Perencanaan volume berdasarkan topologi (
Penjadwalan Volume Sadar Topologi ), yang kami bicarakan dalam konteks rilis
Kubernet 1.10 , telah
menjadi stabil . Singkatnya, penjadwal dalam karyanya memperhitungkan keterbatasan topologi volume pod (misalnya, zona dan simpulnya).
Peluang yang diperkenalkan di
Kubernetes 1.9 untuk menggunakan
perangkat blok mentah (bukan jaringan) karena Volume Persisten
telah diterjemahkan ke dalam beta dan sekarang diaktifkan secara default.
Kami menyimpulkan topik penyimpanan dengan fakta bahwa dukungan untuk GCERegionalPersistentDisk
dinyatakan stabil.
Node gugus
Versi alfa
dukungan untuk plugin pemantauan perangkat pihak ketiga telah diperkenalkan. Gagasan di balik inisiatif ini adalah untuk mengeluarkan pengetahuan khusus perangkat
dari pohon dari Kubelet. Administrator cluster akan menerima metrik yang dilaporkan oleh plugin perangkat di tingkat kontainer, dan produsen akan dapat membuat metrik ini tanpa perlu melakukan perubahan pada inti Kubernetes. Rincian implementasi dapat ditemukan dalam proposal, yang disebut
Kubelet Metadata API .
Dinyatakan stabil,
Kubelet Plugin Watcher (juga dikenal sebagai Pendaftaran Plugin Perangkat Kubelet) memungkinkan plug-in level node (plug-in perangkat, CSI, dan CNI) untuk berkomunikasi dengan Kubelet tentang diri mereka sendiri.
Fitur baru dalam status alpha adalah
NodeLease . Jika sebelumnya "detak jantung" sebuah node ditentukan oleh NodeStatus, maka dengan fitur baru, setiap node memiliki objek
Lease terkait dengannya (dalam ruang nama
kube-node-lease ), yang diperbarui secara berkala oleh node tersebut. "Pulse" sekarang diatur oleh kedua parameter: NodeStatus lama, yang dilaporkan kepada master hanya jika terjadi perubahan atau dengan batas waktu yang tetap (secara default adalah sekali per menit), dan objek baru (sering diperbarui). Karena objek ini sangat kecil, itu akan sangat meningkatkan skalabilitas dan kinerja. Para penulis mulai membuat “pulsa” baru setelah menguji cluster dengan ukuran lebih dari 2.000 node, yang selama pekerjaan mereka dapat bergantung pada batas etcd, untuk lebih jelasnya lihat
KEP-0009 .
type Lease struct { metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata // +optional ObjectMeta metav1.ObjectMeta `json:"metadata,omitempty"` // Specification of the Lease. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status // +optional Spec LeaseSpec `json:"spec,omitempty"` } type LeaseSpec struct { HolderIdentity string `json:"holderIdentity"` LeaseDurationSeconds int32 `json:"leaseDurationSeconds"` AcquireTime metav1.MicroTime `json:"acquireTime"` RenewTime metav1.MicroTime `json:"renewTime"` LeaseTransitions int32 `json:"leaseTransitions"` }
(Spesifikasi ringkas dari objek baru untuk mewakili "pulsa" dari node - Lease - identik dengan LeaderElectionRecord )Keamanan
Versi alpha dari
Dynamic Audit Control mengikuti ide-ide dari Dynamic Admission Control dan menyediakan konfigurasi dinamis dari kemampuan audit tingkat lanjut - untuk ini Anda sekarang dapat mendaftarkan (secara dinamis) webhook yang akan menerima aliran acara. Kebutuhan akan fitur ini dijelaskan oleh fakta bahwa audit Kubernetes menawarkan fitur-fitur yang sangat kuat, tetapi mereka sulit untuk dikonfigurasikan, dan setiap perubahan konfigurasi masih memerlukan restart apiserver.
Enkripsi data dalam etcd (lihat dokumentasi resmi ) telah ditransfer dari status eksperimental ke beta.
kind: EncryptionConfiguration apiVersion: apiserver.config.k8s.io/v1 resources: - resources: - secrets providers: - identity: {} - aesgcm: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - aescbc: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - secretbox: keys: - name: key1 secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
(Contoh konfigurasi dengan data terenkripsi diambil dari dokumentasi .)Di antara inovasi yang kurang signifikan dalam kategori ini:
- Sekarang apiserver dapat dikonfigurasi untuk menolak permintaan yang tidak dapat masuk ke log audit.
- Objek
PodSecurityPolicy ditambahkan dengan dukungan untuk aturan MayRunAs untuk opsi fsGroup dan supplementalGroups , yang memungkinkan mendefinisikan kisaran pengidentifikasi grup yang diperbolehkan (GID) untuk pod / wadah tanpa memaksa GID default. Selain itu, dengan PodSecurityPolicy , strategi RunAsGroup sekarang dimungkinkan dalam spesifikasi RunAsGroup , mis. Anda dapat mengontrol GID utama untuk kontainer. - Untuk kube-scheduler, kami mengganti port tidak aman sebelumnya (10251) dengan port aman baru (10259) dan menyalakannya secara default. Jika tidak ada bendera tambahan yang ditentukan, maka pada saat memuat, sertifikat yang ditandatangani sendiri dibuat untuknya di memori.
CLI
kubectl diff ,
menunjukkan perbedaan antara konfigurasi lokal dan deskripsi saat ini dari objek yang bekerja (berfungsi dan secara rekursif untuk direktori dengan konfigurasi), telah menerima status beta.
Bahkan,
diff "memprediksi" perubahan yang akan dibuat dengan
kubectl apply , dan fitur baru lainnya
digunakan -
APIServer DryRun . Esensinya - awal yang tidak digunakan - harus jelas dari namanya, dan deskripsi yang lebih rinci tersedia dalam
dokumentasi Kubernetes . Omong-omong, dalam rilis 1.13 fungsi DryRun juga "ditingkatkan" ke versi beta dan dihidupkan secara default.
Dan kemajuan lain ke beta di dunia konsol Kubernetes telah memengaruhi
mekanisme plugin baru . Sepanjang jalan, mereka
mengoreksi urutan output dari plugins (
kubectl plugin list ), menghapus penyortiran tambahan dari sana.
Selain itu, output dari sumber daya
penyimpanan sementara digunakan
ditambahkan ke
kubectl describe node , dan volume jenis yang
diproyeksikan ditambahkan ke
kubectl describe pod .
Perubahan lainnya
Fungsi scheduler
Penggusuran Berbasis Taint telah dikonversi ke status beta dan diaktifkan secara default setelah
jeda panjang dalam pengembangan. Tujuannya adalah untuk secara otomatis menambahkan
noda ke node (melalui NodeController atau kubelet) setelah terjadinya kondisi tertentu, seperti, misalnya,
node.kubernetes.io/not-ready , yang sesuai dengan nilai
NodeCondition di
Ready=False .
Anotasi pod kritis untuk pengoperasian cluster -
critical-pod - sudah usang. Sebagai gantinya, diusulkan untuk menggunakan
prioritas (dalam versi beta dengan Kubernet 1.11) .
Untuk AWS untuk pertama kalinya (sebagai bagian dari versi alfa), berikut ini tersedia:
- integrasi untuk AWS ALB (Application Load Balancer) dengan sumber daya Kubernetes Ingress - aws-alb-ingress-controller (proyek ini awalnya dibuat oleh Ticketmaster dan CoreOS untuk memigrasi yang pertama ke awan AWS);
- CCS eksternal (Manajer Kontroler Cloud) AWS - penyedia-cloud-aws - yang bertanggung jawab untuk meluncurkan pengontrol dengan fungsionalitas penyedia spesifik cloud (AWS).
SIG Azure menerapkan dukungan tambahan untuk Azure Disk (Ultra SSD, SSD Standar, dan File Azure Premium) dan mempromosikan
node grup sumber daya Cross ke beta. Selain itu, plugin CNI untuk Windows sekarang memiliki kemampuan untuk mengkonfigurasi DNS dalam sebuah wadah.
Kompatibilitas
- Versi etcd adalah 3.2.24 (belum berubah sejak Kubernetes 1.12).
- Versi terverifikasi Docker - 1.11.1, 1.12.1, 1.13.1, 17.03, 17.06, 17.09, 18.06 (juga tidak berubah).
- Versi Go - 1.11.2, bertepatan dengan minimum yang didukung.
- Versi CNI adalah 0.6.0.
- Versi CSI adalah 1.0.0.
- Versi CoreDNS adalah 1.2.6.
PS
Baca juga di blog kami: