Informasi yang digunakan untuk mempersiapkan materi ini diambil dari tabel pelacakan peningkatan Kubernetes , CHANGELOG-1.19 , ikhtisar Sysdig , serta masalah terkait, permintaan penarikan, Kubernetes Enhancement Proposals (KEP).
Mari kita mulai dengan beberapa inovasi besar yang sifatnya cukup umum ...
Dengan dirilisnya Kubernetes 1.19, "jendela dukungan" untuk versi Kubernetes telah ditingkatkan dari 9 bulan (yaitu 3 rilis terakhir) menjadi 1 tahun (yaitu 4 rilis). Mengapa?
Ternyata karena kecepatan tinggi pengembangan proyek (rilis besar yang sering), administrator kluster Kubernetes tidak punya waktu untuk memperbarui penginstalan mereka. Penulis KEP terkait mengacu pada survei yang dilakukan oleh kelompok kerja pada awal tahun lalu dan menunjukkan bahwa sekitar sepertiga pengguna Kubernetes berurusan dengan rilis K8 usang yang sedang diproduksi:
(Pada saat survei, versi Kubernetes saat ini adalah 1,13, yaitu semua pengguna K8s 1.9 dan 1.10 bekerja dengan rilis yang tidak lagi didukung pada saat itu.)
Dengan demikian, diasumsikan bahwa perpanjangan 3 bulan dari periode dukungan untuk rilis Kubernetes - rilis tambalan yang memperbaiki masalah yang ditemukan dalam kode - akan memungkinkan lebih dari 80% pengguna untuk bekerja pada versi K8 yang didukung (alih-alih diasumsikan 50-60% saat ini ).
Perkembangan besar lainnya: standar untuk log terstruktur telah dikembangkan ... Sistem logging saat ini di bidang kontrol tidak menjamin struktur tunggal untuk pesan dan referensi objek di Kubernetes, yang memperumit pemrosesan log tersebut. Untuk mengatasi masalah ini, struktur baru untuk pesan di log diperkenalkan, di mana pustaka klog telah diperluas dengan metode baru yang menyediakan antarmuka terstruktur untuk menghasilkan log, serta metode tambahan untuk mengidentifikasi objek K8 di log.
Bersamaan dengan migrasi ke klog v2, transisi ke format baru untuk mengeluarkan log di JSON dilakukan, yang akan menyederhanakan eksekusi permintaan ke log dan pemrosesannya. Untuk ini, sebuah bendera muncul
--logging-format, yang secara default menggunakan format teks lama.
Karena repositori Kubernetes sangat besar dan pembuatnyaPenebangan Kayu Terstruktur KEP adalah realis dan akan memfokuskan upaya mereka untuk menghidupkan ide-ide baru pada pesan yang paling umum.
Ilustrasi logging menggunakan metode baru di klog:
klog.InfoS("Pod status updated", "pod", "kubedns", "status", "ready")
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kubedns"klog.InfoS("Pod status updated", "pod", klog.KRef("kube-system", "kubedns"), "status", "ready")
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"klog.ErrorS(err, "Failed to update pod status")
E1025 00:15:15.525108 1 controller_utils.go:114] "Failed to update pod status" err="timeout"Menggunakan format JSON:
pod := corev1.Pod{Name: "kubedns", Namespace: "kube-system", ...}
klog.InfoS("Pod status updated", "pod", klog.KObj(pod), "status", "ready"){
"ts": 1580306777.04728,
"v": 4,
"msg": "Pod status updated",
"pod":{
"name": "nginx-1",
"namespace": "default"
},
"status": "ready"
}Inovasi penting lainnya (dan sangat relevan) adalah mekanisme untuk menginformasikan tentang API yang tidak berlaku lagi , diterapkan segera sebagai versi beta (yaitu, aktif dalam penginstalan secara default). Seperti dijelaskan oleh penulis, dalam banyak Kubernetes kapasitas terus usang, tinggal di negara yang berbeda dan dengan waktu yang berbeda s prospek mi. Melacaknya, membaca dengan cermat semua Catatan Rilis dan membersihkan konfigurasi / pengaturan secara manual, hampir tidak mungkin.
Untuk mengatasi masalah ini, sekarang ketika menggunakan API yang tidak digunakan lagi, sebuah header ditambahkan ke tanggapannya
Warning, yang dikenali di sisi klien (client-go) dengan kemungkinan respons berbeda: abaikan, hapus duplikat, log. Dalam utilitas kubectl, mereka mengajarkan bagaimana mengeluarkan pesan-pesan ini ke stderr, menyorot pesan di konsol dengan warna, dan juga menambahkan sebuah flag --warnings-as-errorsdengan nama yang jelas .
Selain itu, metrik khusus telah ditambahkan untuk melaporkan penggunaan API yang tidak digunakan lagi dan anotasi audit.
Terakhir, para pengembang menghadiri kemajuan fitur Kubernetes dari versi beta . Seperti yang ditunjukkan oleh pengalaman proyek, beberapa fitur dan perubahan baru di API "terhenti" dalam status Beta karena telah diaktifkan secara otomatis (secara default) dan tidak memerlukan tindakan lebih lanjut dari pengguna.
Untuk mencegah hal ini terjadi, disarankan secara otomatis mengirim ke daftar penghentian fitur-fitur yang telah dalam versi beta selama 6 bulan (dua rilis) dan tidak memenuhi salah satu kondisi berikut:
- memenuhi kriteria GA dan sedang dipromosikan ke status stabil;
- memiliki versi beta baru yang menggantikan versi beta sebelumnya.
Dan sekarang untuk perubahan lain di Kubernetes 1.19, dikategorikan berdasarkan SIG masing-masing.
Vaults
Objek CSIStorageCapacity yang baru dimaksudkan untuk meningkatkan proses penjadwalan untuk pod yang menggunakan volume CSI: objek tersebut tidak akan ditempatkan pada node yang telah kehabisan ruang penyimpanan. Untuk ini, informasi tentang ruang disk yang tersedia akan disimpan di server API dan tersedia untuk driver CSI dan penjadwal. Status implementasi saat ini adalah versi alfa; lihat KEP untuk detailnya .
Inovasi lain dalam versi alfa adalah kemampuan untuk menentukan volume ephemeral secara langsung dalam spesifikasi pod, volume inline ephemeral generik ( KEP). Volume singkat dibuat untuk pod tertentu pada saat mereka bertelur dan dihapus saat keluar. Mereka dapat didefinisikan sebelumnya (termasuk secara langsung dalam spesifikasi, yaitu dengan metode inline), tetapi pendekatan yang ada, setelah membuktikan konsistensi dari fitur itu sendiri, tidak mencakup semua kasus penggunaannya.
Mekanisme baru ini menawarkan API sederhana untuk menentukan volume singkat bagi driver apa pun dengan dukungan penyediaan dinamis (sebelumnya, ini akan memerlukan modifikasi driver). Ini memungkinkan Anda untuk bekerja dengan volume singkat apa pun (baik CSI dan in-tree, seperti
EmptyDir), dan juga menyediakan dukungan untuk fitur baru lainnya (dijelaskan di atas) - melacak ruang penyimpanan yang tersedia.
Contoh objek Kubernetes level tinggi yang menggunakan volume efemeral baru (sebaris umum):
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
volumeMounts:
- name: varlog
mountPath: /var/log
- name: scratch
mountPath: /scratch
volumes:
- name: varlog
hostPath:
path: /var/log
- name: scratch
ephemeral:
metadata:
labels:
type: fluentd-elasticsearch-volume
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "scratch-storage-class"
resources:
requests:
storage: 1GiDi sini pengontrol DaemonSet membuat pod dengan nama tampilan
fluentd-elasticsearch-b96sd, setelah itu PersistentVolumeClaim akan ditambahkan untuk pod tersebut fluentd-elasticsearch-b96sd-scratch.
Dan fitur penyimpanan yang benar-benar baru, diperkenalkan sebagai versi alfa, adalah bidang baru
csidriver.spec.SupportsFSGroupbagi driver CSI untuk menunjukkan dukungan untuk izin berbasis FSGroup ( KEP ). Motivasi: perubahan kepemilikan untuk volume CSI dilakukan sebelum dipasang di wadah, namun, tidak semua jenis penyimpanan mendukung operasi semacam itu (misalnya, NFS), itulah sebabnya sekarang dapat menyebabkan kesalahan.
Hingga versi beta (yaitu inklusi default):
- CSI- Azure vSphere ( , Kubernetes);
- Secrets ConfigMaps.
/ Kubelet
Seccomp telah dinyatakan stabil (GA) . Secara khusus, pekerjaan ini mengarah pada transisi ke kolom untuk seccomp di API alih-alih anotasi yang dinyatakan usang (Kubelet baru mengabaikan anotasi), dan memengaruhi PodSecurityPolicy .
Sebuah field baru telah ditambahkan ke PodSpec
fqdnInHostnameuntuk memungkinkan Anda mengatur FQDN (Fully Qualified Domain Name) untuk pod host . Tujuannya adalah meningkatkan dukungan untuk aplikasi lama di Kubernetes. Berikut cara penulis menjelaskan maksud mereka:
« Unix Linux-, Red Hat CentOS, FQDN- hostname. , , Kubernetes, . ».
Standarnya akan
falsemempertahankan perilaku lama (untuk Kubernetes). Status fitur - versi alfa, yang rencananya akan dinyatakan stabil pada rilis berikutnya (1.20).
Diputuskan untuk mengabaikan Metrik Akselerator yang dikumpulkan oleh Kubelet . Diusulkan untuk mengumpulkan metrik tersebut oleh agen pemantau eksternal melalui PodResources API. API ini sendiri dibuat dengan tujuan untuk menghapus semua metrik khusus perangkat dari repositori Kubernetes utama, memungkinkan vendor untuk mengimplementasikannya tanpa membuat perubahan pada inti Kubernetes. PodResources API masih dalam versi beta (gerbang fitur bertanggung jawab untuk itu
KubeletPodResources) dan akan segera stabil. Untuk rilis saat ini, proses pengabaian dalam status alfa, detailnya ada di KEP .
Mulai sekarang, Kubelet dapat dibangun tanpa Docker : dengan kata "tanpa" ini, penulis berarti tidak adanya kode khusus Docker dan ketergantungan pada paket Golang
docker/docker. Tujuan akhir dari inisiatif ini adalah untuk mencapai Kubelet yang sepenuhnya "tanpa buruh pelabuhan" (yaitu, tidak ada ketergantungan Docker). Anda dapat membaca lebih lanjut tentang motivasi, seperti biasa, di KEP . Peluang ini langsung mendapat status GA.
Manajer Topologi Node, yang mencapai versi beta pada rilis K8 terakhir, sekarang memiliki kemampuan untuk menaikkan level sumber daya pada level pod.
Penjadwal
Kembali ke Kubernetes 1.18, kami menulis tentang konfigurasi global untuk distribusi pod genap (Even Pod Spreading) , tetapi kemudian diputuskan untuk menunda fitur ini berdasarkan hasil pengujian performa. Dia sekarang di Kubernetes (dalam status alfa).
Inti dari inovasi ini adalah penambahan batasan global (
DefaultConstraints), yang memungkinkan pengaturan aturan untuk mendistribusikan pod di tingkat yang lebih tinggi - di tingkat cluster, dan tidak hanya di PodSpec(melalui topologySpreadConstraints), seperti sebelumnya. Konfigurasi default akan serupa dengan plugin saat ini DefaultPodTopologySpread:
defaultConstraints:
- maxSkew: 3
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: ScheduleAnyway
- maxSkew: 5
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnywayDetail ada di KEP .
Fitur lain yang terkait dengan Even Pod Spreading: distribusi sekelompok pod berdasarkan domain kegagalan (region, zona, node, dll.), - ditransfer dari alfa ke beta (diaktifkan secara default).
Tiga fitur lain di penjadwal telah mencapai "peningkatan" yang serupa:
- Profil perencanaan (Penjadwalan Profil) , disajikan dalam 1.18;
- opsi untuk mengaktifkan / menonaktifkan preemption pod di PriorityClasses;
- file konfigurasi kube-scheduler ComponentConfig .
Jaringan
Sumber daya Ingress akhirnya dinyatakan stabil dan memiliki versi
v1di API. Dalam hal ini, beberapa pembaruan telah disajikan dalam dokumentasi terkait. Perhatian khusus harus diberikan pada perubahan yang terlihat oleh pengguna dari PR ini : misalnya, ada penggantian nama seperti spec.backend→ spec.defaultBackend, serviceName→ service.name, servicePort→ service.port.number...
Bidang AppProtocol untuk Layanan dan Titik Akhir, serta API EndpointSlice (kube-proxy di Linux dimulai gunakan EndpointSlices secara default, tetapi tetap dalam alfa untuk Windows) dan dukungan SCTP .
kubeadm.dll
Dua fitur baru (dalam versi alfa) diperkenalkan untuk utilitas kubeadm.
Yang pertama adalah menggunakan tambalan untuk memodifikasi manifes yang dihasilkan oleh kubeadm. Ini adalah sudah dimungkinkan untuk mengubah mereka menggunakan Kustomize (alpha), namun pengembang kubeadm memutuskan bahwa menggunakan patch teratur adalah cara yang lebih disukai (karena Kustomize menjadi ketergantungan yang tidak perlu, yang tidak diterima).
Sekarang dimungkinkan untuk menerapkan tambalan mentah (melalui sebuah bendera
--experimental-patches) untuk perintah kubeadm init, joindan upgrade, juga fase mereka. Implementasi berbasis Kustomize (flag --experimental-kustomize) tidak akan digunakan lagi dan dihapus.
Fitur kedua adalah pendekatan baru untuk bekerja dengan konfigurasi komponenyang digunakan kubeadm. Utilitas ini menghasilkan, memvalidasi, menetapkan nilai default, menyimpan konfigurasi (dalam bentuk ConfigMaps) untuk komponen klaster Kubernetes seperti Kubelet dan kube-proxy. Seiring waktu, menjadi jelas bahwa hal ini membawa sejumlah kesulitan: bagaimana membedakan antara konfigurasi yang dibuat oleh kubeadm atau dikirimkan oleh pengguna (dan jika tidak, lalu apa yang harus dilakukan dengan migrasi konfigurasi)? Bidang mana dengan nilai default yang dibuat secara otomatis, dan mana yang sengaja disetel? ..
Untuk mengatasi masalah ini, sejumlah besar perubahan disajikan , termasuk: penolakan untuk menyetel nilai default (ini harus dilakukan oleh komponen itu sendiri), pendelegasian validasi konfigurasi itu sendiri komponen, menandatangani setiap ConfigMap yang dihasilkan, dll.
Dan fitur lain yang kurang signifikan untuk kubeadm adalah gerbang fitur yang disebut
PublicKeysECDSA, yang mencakup kemampuan untuk membuat cluster [melalui kubeadm init] dengan sertifikat ECDSA. Memperbarui sertifikat yang ada (melalui kubeadm alpha certs renew) juga tersedia, tetapi tidak ada mekanisme untuk beralih dengan mudah antara RSA dan ECDSA.
Perubahan lainnya
- Status GA menerima 3 fitur di bidang otentikasi: API CertificateSigningRequest , membatasi akses node ke API tertentu (melalui plugin masuk
NodeRestriction), bootstrap dan pembaruan otomatis sertifikat klien Kubelet. - API Peristiwa baru juga dinyatakan stabil dengan pendekatan yang diubah ke deduplikasi (untuk menghindari membebani cluster dengan peristiwa).
- (kube-apiserver, kube-scheduler, etcd )
debiandistroless. : , ( — KEP). - Kubelet Docker runtime target-,
TargetContainerNameEphemeralContainer ( ). - « »
.status.conditions, API . - kube-proxy IPv6DualStack Windows ( feature gate).
- Gerbang fitur dengan nama yang cukup jelas
CSIMigrationvSphere(migrasi dari plug-in - in-tree - built-in untuk vSphere ke driver CSI) telah dipindahkan ke versi beta. - Untuk bendera
kubectl runtambahan--privileged. - Titik ekstensi baru telah ditambahkan ke penjadwal - , - yang dimulai setelah fase .
PostFilterFilter - Dukungan Cri-containerd pada Windows telah mencapai beta.
Perubahan ketergantungan:
- versi CoreDNS termasuk dalam kubeadm - 1.7.0;
- cri-tools 1.18.0;
- CNI (Container Networking Interface) 0.8.6;
- etcd 3.4.9;
- versi Go yang digunakan adalah 1.15.0-rc.1.
PS
Baca juga di blog kami: