🥇Kubernetes 1.17: gambaran keseluruhan inovasi utama

Semalam, 9 Disember, mengambil tempat keluaran seterusnya Kubernetes - 1.17. Menurut tradisi yang telah dibangunkan untuk blog kami, kami bercakap tentang perubahan paling ketara dalam versi baharu.

Maklumat yang digunakan untuk menyediakan bahan ini diambil daripada pengumuman rasmi, Jadual penjejakan peningkatan Kubernetes, CHANGELOG-1.17 dan isu berkaitan, permintaan tarik dan Cadangan Peningkatan Kubernetes (KEP). Jadi, apa yang baru?..

Penghalaan sedar topologi

Komuniti Kubernetes telah lama menunggu ciri ini - Penghalaan perkhidmatan sedar topologi. Jika CAP ia bermula pada Oktober 2018, dan rasmi Penambahbaikan — 2 tahun lalu, isu biasa (seperti ia) - dan beberapa tahun lagi lebih tua...

Idea umum adalah untuk menyediakan keupayaan untuk melaksanakan penghalaan "tempatan" untuk perkhidmatan yang berada di Kubernetes. "Lokaliti" dalam kes ini bermaksud "tahap topologi yang sama" (tahap topologi), yang mungkin:

nod yang sama untuk perkhidmatan,
rak pelayan yang sama,
wilayah yang sama
pembekal awan yang sama,
...

Contoh penggunaan ciri ini:

penjimatan pada trafik dalam pemasangan awan dengan berbilang zon ketersediaan (berbilang AZ) - lihat. ilustrasi segar menggunakan contoh trafik dari rantau yang sama, tetapi AZ berbeza dalam AWS;
kependaman prestasi yang lebih rendah/kemampuan yang lebih baik;
perkhidmatan sharded yang mempunyai maklumat setempat tentang nod dalam setiap shard;
penempatan fluentd (atau analog) pada nod yang sama dengan aplikasi yang lognya dikumpulkan;
...

Penghalaan sedemikian, yang "tahu" tentang topologi, juga dipanggil pertalian rangkaian - dengan analogi dengan pertalian nod, pertalian pod/anti pertalian atau muncul tidak lama dahulu Penjadualan Isipadu Sedar Topologi (dan Peruntukan Jilid). Tahap pelaksanaan semasa ServiceTopology dalam Kubernetes - versi alfa.

Untuk butiran tentang cara ciri ini berfungsi dan cara anda sudah boleh menggunakannya, baca artikel ini daripada salah seorang pengarang.

Sokongan dwi tindanan IPv4/IPv6

Kemajuan yang ketara tetap dalam ciri rangkaian lain: sokongan serentak untuk dua tindanan IP, yang pertama kali diperkenalkan pada K8s 1.16. Khususnya, keluaran baharu membawa perubahan berikut:

dalam kube-proxy dilaksanakan kemungkinan operasi serentak dalam kedua-dua mod (IPv4 dan IPv6);
в Pod.Status.PodIPs muncul sokongan untuk API menurun (pada masa yang sama seperti dalam /etc/hosts kini mereka memerlukan hos untuk menambah alamat IPv6);
sokongan dwi timbunan KIND (Kubernetes IN Docker) dan kubeadm;
ujian e2e yang dikemas kini.

Ilustrasi menggunakan dwi tindanan IPV4/IPv6 dalam KIND

Kemajuan pada CSI

Diisytiharkan stabil sokongan topologi untuk storan berasaskan CSI, pertama kali diperkenalkan pada K8s 1.12.

Inisiatif untuk penghijrahan pemalam volum kepada CSI - Migrasi CSI - mencapai versi beta. Ciri ini penting untuk menterjemah pemalam storan sedia ada (dalam pokok) kepada antara muka moden (CSI, di luar pokok) tidak kelihatan kepada pengguna akhir Kubernetes. Pentadbir kluster hanya perlu mendayakan CSI Migration, selepas itu sumber dan beban kerja yang sedia ada akan terus "berfungsi"... tetapi menggunakan pemacu CSI terkini dan bukannya pemacu lapuk yang disertakan dalam teras Kubernetes.

Pada masa ini, migrasi untuk pemacu AWS EBS sedia dalam versi beta (kubernetes.io/aws-ebs) dan GCE PD (kubernetes.io/gce-pd). Ramalan untuk kemudahan penyimpanan lain adalah seperti berikut:

Kami bercakap tentang bagaimana sokongan storan "tradisional" dalam K8 datang kepada CSI artikel ini. Dan peralihan penghijrahan CSI kepada status beta dikhususkan untuk penerbitan berasingan di blog projek.

Selain itu, satu lagi fungsi penting dalam konteks CSI, yang berasal (pelaksanaan alfa) dalam K1.17s 8, mencapai status beta (iaitu didayakan secara lalai) dalam keluaran Kubernetes 1.12 - mencipta syot kilat dan pemulihan daripada mereka. Antara perubahan yang dibuat pada Gambar Volume Kubernetes dalam perjalanan ke keluaran beta:

membelah kereta sampingan snapshotter luaran CSI kepada dua pengawal,
menambah rahsia untuk pemadaman (rahsia pemadaman) sebagai anotasi kepada kandungan syot kilat volum,
pemuktamad baru (penyelesaikan) untuk mengelakkan objek API snapshot daripada dipadamkan jika terdapat sambungan yang tinggal.

Pada masa keluaran 1.17, ciri ini disokong oleh tiga pemacu CSI: Pemacu GCE Persistent Disk CSI, Pemacu CSI Portworx dan Pemacu CSI NetApp Trident. Butiran lanjut tentang pelaksanaan dan penggunaannya boleh didapati dalam penerbitan ini di blog.

Label Pembekal Awan

Label itu secara automatik diperuntukkan kepada nod dan volum yang dicipta bergantung pada pembekal awan yang digunakan, telah tersedia dalam Kubernetes sebagai versi beta untuk masa yang sangat lama - sejak keluaran K8s 1.2 (April 2016!). Memandangkan penggunaan meluas mereka untuk sekian lama, pemaju memutuskan, bahawa sudah tiba masanya untuk mengisytiharkan ciri stabil (GA).

Oleh itu, mereka semua dinamakan semula dengan sewajarnya (mengikut 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 di bawah nama lama mereka (untuk keserasian ke belakang). Walau bagaimanapun, semua pentadbir disyorkan untuk beralih kepada label semasa. Dokumentasi Berkaitan K8s telah dikemas kini.

Output berstruktur kubeadm

Dibentangkan dalam versi alfa buat kali pertama output berstruktur untuk utiliti kubeadm. Format yang disokong: JSON, YAML, templat Go.

Motivasi untuk melaksanakan ciri ini (mengikut CAP) ialah:

Walaupun Kubernetes boleh digunakan secara manual, standard de facto (jika tidak de jure) untuk operasi ini adalah menggunakan kubeadm. Alat pengurusan sistem popular seperti Terraform bergantung pada kubeadm untuk penggunaan Kubernetes. Pembaikan terancang pada API Kluster termasuk pakej boleh gubah untuk bootstrap Kubernetes dengan kubeadm dan cloud-init.

Tanpa output berstruktur, walaupun perubahan yang paling tidak berbahaya pada pandangan pertama boleh memecahkan Terraform, API Kluster dan perisian lain yang menggunakan hasil kubeadm.

Pelan segera kami termasuk sokongan (dalam bentuk output berstruktur) untuk arahan kubeadm berikut:

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

Ilustrasi tindak balas JSON kepada arahan 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="
}

Penstabilan inovasi lain

Secara umum, keluaran Kubernetes 1.17 berlaku di bawah moto “Kestabilan" Ini difasilitasi oleh fakta bahawa banyak ciri di dalamnya (jumlahnya ialah 14) menerima status GA. Antaranya:

"menanda" nod mengikut syarat tertentu (TaintNodesByCondition), muncul dalam K8s 1.8;
Tonton Penanda Halaman - jenis acara baharu yang mempunyai label bahawa semua objek terpulang kepada versi tertentu (resourceVersion) telah diproses oleh jam tangan;
nilai lalai (lalai) untuk Sumber Tersuai;
dikongsi antara bekas dalam ruang nama proses pod;
ScheduleDaemonSetPods - pod penjadualan dalam DaemonSet menggunakan kube-scheduler (bukan pengawal DaemonSet);
had dinamik pada bilangan volum bergantung pada jenis nod;
sokongan pembolehubah persekitaran untuk nama direktori yang dipasang sebagai subPath;
Pemindahan degupan jantung Kubelet kepada API Pajakan khusus;
"perlindungan akhir" (Perlindungan Penyempurna) untuk pengimbang beban (menyemak sumber Perkhidmatan yang sepadan sebelum memadamkan sumber LoadBalancer);
pengoptimuman kube-apiserver dalam prestasi apabila bekerja dengan berbilang jam tangan memantau set objek yang serupa - dicapai dengan mengelakkan siri berulang objek yang sama untuk setiap pemerhati.

Perubahan lain

Senarai penuh inovasi dalam Kubernetes 1.17, sudah tentu, tidak terhad kepada yang disenaraikan di atas. Berikut adalah beberapa yang lain (dan untuk senarai yang lebih lengkap, lihat BAHASA MELAYU):

Ciri yang dibentangkan dalam keluaran terakhir telah mencapai versi beta RunAsUserName untuk tingkap;
perubahan serupa menimpa API EndpointSlice (juga daripada K8s 1.16), namun buat masa ini penyelesaian untuk meningkatkan prestasi/skala API Endpoint tidak didayakan secara lalai;
pod kini kritikal untuk operasi kelompok boleh dibuat bukan sahaja dalam ruang nama kube-system (untuk butiran, lihat dokumentasi untuk Hadkan penggunaan Kelas Keutamaan);
pilihan baharu untuk kubelet - --reserved-cpus — membolehkan anda mentakrifkan secara eksplisit senarai CPU yang dikhaskan untuk sistem;
untuk kubectl logs dibentangkan bendera baru --prefix, menambah nama pod dan bekas sumber pada setiap baris log;
в label.Selector tambah RequiresExactMatch;
semua bekas dalam kube-dns kini sedang berjalan dengan keistimewaan yang kurang;
hyperkube dipisahkan ke dalam repositori GitHub yang berasingan dan tidak lagi akan disertakan dalam keluaran Kubernetes;
banyak prestasi yang bertambah baik kube-proxy untuk port bukan UDP.

Perubahan kebergantungan:

Versi CoreDNS yang disertakan dalam kubeadm ialah 1.6.5;
versi crictl dikemas kini kepada v1.16.1;
CSI 1.2.0;
dsb 3.4.3;
Versi Docker yang diuji terkini dinaik taraf kepada 19.03;
Versi Go minimum yang diperlukan untuk membina Kubernetes 1.17 ialah 1.13.4.

Kubernetes 1.17: gambaran keseluruhan inovasi utama