🥇Kubernetes 1.17: ikhtisar inovasi utama

Kemarin, 9 Desember, terjadi rilis Kubernetes berikutnya - 1.17. Sesuai dengan tradisi yang berkembang di blog kami, kami membicarakan tentang perubahan paling signifikan di versi baru.

Informasi yang digunakan untuk menyiapkan materi ini diambil dari pengumuman resmi, Tabel pelacakan penyempurnaan Kubernetes, PERUBAHANLOG-1.17 dan masalah terkait, permintaan penarikan, dan Proposal Peningkatan Kubernetes (KEP). Jadi, apa yang baru?..

Perutean sadar topologi

Komunitas Kubernetes sudah lama menantikan fitur ini - Perutean layanan yang sadar topologi. Jika KEP itu berasal pada Oktober 2018, dan resmi peningkatan — 2 tahun lalu, masalah biasa (menyukai ini) - dan beberapa tahun lagi lebih tua...

Ide umumnya adalah untuk menyediakan kemampuan untuk mengimplementasikan perutean “lokal” untuk layanan yang berada di Kubernetes. “Lokalitas” dalam hal ini berarti “tingkat topologi yang sama” (tingkat topologi), yang mungkin:

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

Contoh penggunaan fitur ini:

penghematan lalu lintas di instalasi cloud dengan beberapa zona ketersediaan (multi-AZ) - lihat. ilustrasi segar menggunakan contoh lalu lintas dari wilayah yang sama, tetapi AZ berbeda di AWS;
latensi kinerja lebih rendah/throughput lebih baik;
layanan shard yang memiliki informasi lokal tentang node di setiap shard;
penempatan fluentd (atau analognya) pada node yang sama dengan aplikasi yang lognya dikumpulkan;
...

Perutean seperti itu, yang “mengetahui” tentang topologi, juga disebut afinitas jaringan - dengan analogi dengan afinitas simpul, afinitas/anti-afinitas pod atau muncul belum lama ini Penjadwalan Volume Sadar Topologi (dan Penyediaan Volume). Tingkat implementasi saat ini ServiceTopology di Kubernetes - versi alfa.

Untuk detail tentang cara kerja fitur ini dan cara Anda dapat menggunakannya, baca Artikel ini dari salah satu penulis.

Dukungan tumpukan ganda IPv4/IPv6

Kemajuan yang signifikan tetap di fitur jaringan lainnya: dukungan simultan untuk dua tumpukan IP, yang pertama kali diperkenalkan pada K8 1.16. Secara khusus, rilis baru ini membawa perubahan berikut:

di kube-proxy diimplementasikan kemungkinan operasi simultan di kedua mode (IPv4 dan IPv6);
в Pod.Status.PodIPs muncul dukungan untuk API ke bawah (bersamaan dengan di /etc/hosts sekarang mereka mengharuskan host untuk menambahkan alamat IPv6);
dukungan tumpukan ganda JENIS (Kubernetes DI Docker) dan kubeadm;
tes e2e yang diperbarui.

Ilustrasi menggunakan dual stack IPV4/IPv6 di KIND

Kemajuan pada CSI

Dinyatakan stabil dukungan topologi untuk penyimpanan berbasis CSI, pertama kali diperkenalkan pada K8 1.12.

Inisiatif untuk migrasi plugin volume ke CSI - Migrasi CSI - mencapai versi beta. Fitur ini sangat penting untuk menerjemahkan plugin penyimpanan yang ada (di dalam pohon) ke antarmuka modern (CSI, di luar pohon) tidak terlihat oleh pengguna akhir Kubernetes. Administrator klaster hanya perlu mengaktifkan Migrasi CSI, setelah itu sumber daya dan beban kerja stateful yang ada akan terus “berfungsi”... tetapi menggunakan driver CSI terbaru dan bukan driver lama yang disertakan dalam inti Kubernetes.

Saat ini, migrasi untuk driver AWS EBS sudah siap dalam versi beta (kubernetes.io/aws-ebs) dan PD GCE (kubernetes.io/gce-pd). Perkiraan untuk fasilitas penyimpanan lainnya adalah sebagai berikut:

Kami berbicara tentang bagaimana dukungan penyimpanan “tradisional” di K8 hadir di CSI Artikel ini. Dan transisi migrasi CSI ke status beta didedikasikan untuknya publikasi terpisah di blog proyek.

Selain itu, fungsi penting lainnya dalam konteks CSI, yang berasal (implementasi alfa) di K1.17s 8, mencapai status beta (yaitu diaktifkan secara default) di rilis Kubernetes 1.12 - membuat snapshot dan pemulihan dari mereka. Di antara perubahan yang dilakukan pada Kubernetes Volume Snapshot menjelang rilis beta:

membagi sespan snapshotter eksternal CSI menjadi dua pengontrol,
menambahkan rahasia untuk dihapus (rahasia penghapusan) sebagai anotasi pada konten snapshot volume,
finalis baru (penyempurna) untuk mencegah objek API snapshot dihapus jika masih ada koneksi yang tersisa.

Pada saat rilis 1.17, fitur ini didukung oleh tiga driver CSI: Driver CSI Disk Persisten GCE, Driver CSI Portworx, dan Driver CSI NetApp Trident. Rincian lebih lanjut tentang implementasi dan penggunaannya dapat ditemukan di publikasi ini di blog.

Label Penyedia Cloud

Labeli itu secara otomatis ditugaskan ke node dan volume yang dibuat tergantung pada penyedia cloud yang digunakan, telah tersedia di Kubernetes sebagai versi beta sejak lama - sejak rilis K8s 1.2 (April 2016!). Mengingat penggunaannya yang luas begitu lama, para pengembang diputuskan, saatnya untuk mendeklarasikan fitur stabil (GA).

Oleh karena itu, semuanya 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 (untuk kompatibilitas ke belakang). Namun, semua administrator disarankan untuk beralih ke label saat ini. Dokumentasi Terkait K8 telah diperbarui.

Keluaran terstruktur dari kubeadm

Disajikan dalam versi alpha untuk pertama kalinya keluaran terstruktur untuk utilitas kubeadm. Format yang didukung: JSON, YAML, templat Go.

Motivasi untuk mengimplementasikan fitur ini (menurut KEP) adalah:

Meskipun Kubernetes dapat diterapkan secara manual, standar de facto (jika bukan de jure) untuk operasi ini adalah menggunakan kubeadm. Alat manajemen sistem populer seperti Terraform mengandalkan kubeadm untuk penerapan Kubernetes. Perbaikan yang direncanakan pada Cluster API mencakup paket composable untuk bootstrapping Kubernetes dengan kubeadm dan cloud-init.

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

Rencana jangka pendek kami mencakup dukungan (dalam bentuk keluaran terstruktur) untuk perintah kubeadm berikut:

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

Ilustrasi respons JSON terhadap suatu 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 berlangsung dengan moto “Stabilitas" Ini difasilitasi oleh fakta bahwa banyak fitur di dalamnya (jumlah totalnya adalah 14) menerima status GA. Diantara mereka:

“menandai” node menurut kondisi tertentu (TaintNodesByCondition), muncul di K8 1.8;
Tonton Bookmark - jenis peristiwa baru yang memiliki label bahwa semua objek hingga versi tertentu (resourceVersion) sudah diproses oleh jam tangan;
nilai dasar (default) untuk Sumber Daya Kustom;
dibagikan antar kontainer di namespace proses pod;
ScheduleDaemonSetPods - menjadwalkan pod di DaemonSet menggunakan kube-scheduler (bukan pengontrol DaemonSet);
batas dinamis pada jumlah volume tergantung pada jenis node;
dukungan variabel lingkungan untuk nama direktori dipasang sebagai subPath;
Transfer detak jantung Kubelet ke API Sewa khusus;
"perlindungan finalis" (Perlindungan Finalisator) untuk penyeimbang beban (memeriksa sumber daya Layanan terkait sebelum menghapus sumber daya LoadBalancer);
optimasi kube-apiserver dalam kinerja ketika bekerja dengan beberapa jam tangan yang memantau kumpulan 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 saja. Berikut beberapa lainnya (dan untuk daftar lebih lengkap, lihat CHANGELOG):

Fitur yang dihadirkan pada rilis terakhir sudah mencapai versi beta RunAsUserName untuk jendela;
perubahan serupa menimpa EndpointSlice API (juga dari K8s 1.16), namun untuk saat ini solusi untuk meningkatkan kinerja/skalabilitas Endpoint API tidak diaktifkan secara default;
pod sekarang sangat penting untuk operasi cluster dapat dibuat tidak hanya di namespace kube-system (untuk detailnya, lihat dokumentasi untuk Batasi konsumsi Kelas Prioritas);
opsi baru untuk kubelet - --reserved-cpus — memungkinkan Anda menentukan secara eksplisit daftar CPU yang dicadangkan untuk sistem;
untuk kubectl logs disajikan bendera baru --prefix, menambahkan nama pod dan container sumber ke setiap baris log;
в label.Selector ditambahkan RequiresExactMatch;
semua container di kube-dns sekarang sedang berjalan dengan hak istimewa yang lebih sedikit;
hiperkube dipisahkan ke dalam repositori GitHub terpisah dan tidak lagi disertakan dalam rilis Kubernetes;
banyak layanan terbaik kube-proxy untuk port non-UDP.

Perubahan ketergantungan:

Versi CoreDNS yang disertakan dalam kubeadm adalah 1.6.5;
versi crictl diperbarui ke v1.16.1;
CSI 1.2.0;
dll 3.4.3;
Versi Docker terbaru yang diuji ditingkatkan ke 19.03;
Versi Go minimum yang diperlukan untuk membangun Kubernetes 1.17 adalah 1.13.4.

Kubernetes 1.17: ikhtisar inovasi utama