Kubernetes 1.16: gambaran keseluruhan inovasi utama

Hari ini, Rabu, akan berlaku keluaran seterusnya Kubernetes - 1.16. Mengikut tradisi yang telah dibangunkan untuk blog kami, ini adalah ulang tahun kesepuluh kami bercakap tentang perubahan paling ketara dalam versi baharu.

Maklumat yang digunakan untuk menyediakan bahan ini diambil daripada Jadual penjejakan peningkatan Kubernetes, CHANGELOG-1.16 dan isu berkaitan, permintaan tarik dan Cadangan Peningkatan Kubernetes (KEP). Jadi, jom!..

Nod

Sebilangan besar inovasi ketara (dalam status versi alfa) dibentangkan pada sisi nod kluster K8s (Kubelet).

Pertama, apa yang dipanggil «bekas yang tidak kekal» (Bekas Ephemeral), direka untuk memudahkan proses penyahpepijatan dalam pod. Mekanisme baharu ini membolehkan anda melancarkan bekas khas yang bermula dalam ruang nama pod sedia ada dan hidup untuk masa yang singkat. Tujuan mereka adalah untuk berinteraksi dengan pod dan bekas lain untuk menyelesaikan sebarang masalah dan nyahpepijat. Perintah baharu telah dilaksanakan untuk ciri ini kubectl debug, sama pada dasarnya dengan kubectl exec: hanya daripada menjalankan proses dalam bekas (seperti dalam exec) ia melancarkan bekas dalam pod. Sebagai contoh, arahan ini akan menyambungkan bekas baharu ke pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Butiran tentang bekas fana (dan contoh penggunaannya) boleh didapati di KEP yang sepadan. Pelaksanaan semasa (dalam K8s 1.16) ialah versi alfa dan antara kriteria untuk pemindahannya kepada versi beta ialah "menguji API Kontena Ephemeral untuk sekurang-kurangnya 2 keluaran [Kubernetes]."

NB: Pada dasarnya dan juga namanya, ciri ini menyerupai pemalam yang sedia ada kubectl-debugtentang yang kita sudah menulis. Dijangkakan bahawa dengan kemunculan bekas yang tidak kekal, pembangunan pemalam luaran yang berasingan akan terhenti.

Satu lagi inovasi - PodOverhead - direka untuk menyediakan mekanisme untuk mengira kos overhed untuk pod, yang boleh berbeza-beza bergantung pada masa jalan yang digunakan. Sebagai contoh, penulis KEP ini menghasilkan Kata Containers, yang memerlukan menjalankan kernel tetamu, ejen kata, sistem init, dsb. Apabila overhed menjadi begitu besar, ia tidak boleh diabaikan, yang bermaksud perlu ada cara untuk mengambil kiranya untuk kuota, perancangan, dsb. Untuk melaksanakannya dalam PodSpec medan ditambah Overhead *ResourceList (bandingkan dengan data dalam RuntimeClass, jika satu digunakan).

Satu lagi inovasi yang ketara ialah pengurus topologi nod (Pengurus Topologi Nod), direka untuk menyatukan pendekatan untuk memperhalusi peruntukan sumber perkakasan untuk pelbagai komponen dalam Kubernetes. Inisiatif ini didorong oleh keperluan yang semakin meningkat bagi pelbagai sistem moden (dari bidang telekomunikasi, pembelajaran mesin, perkhidmatan kewangan, dll.) untuk pengkomputeran selari berprestasi tinggi dan meminimumkan kelewatan dalam pelaksanaan operasi, yang mana mereka menggunakan CPU termaju dan keupayaan pecutan perkakasan. Pengoptimuman sedemikian dalam Kubernetes setakat ini telah dicapai terima kasih kepada komponen yang berbeza (pengurus CPU, Pengurus Peranti, CNI), dan kini mereka akan ditambah antara muka dalaman tunggal yang menyatukan pendekatan dan memudahkan sambungan baru yang serupa - yang dipanggil topologi- sedar - komponen di sebelah Kubelet. Butiran - dalam KEP yang sepadan.

Rajah Komponen Pengurus Topologi

Ciri seterusnya - memeriksa bekas semasa ia berjalan (siasatan permulaan). Seperti yang anda ketahui, bagi bekas yang mengambil masa yang lama untuk dilancarkan, adalah sukar untuk mendapatkan status terkini: ia sama ada "dibunuh" sebelum ia benar-benar mula berfungsi, atau ia berakhir dalam kebuntuan untuk masa yang lama. Semakan baharu (didayakan melalui gerbang ciri dipanggil StartupProbeEnabled) membatalkan - atau lebih tepat, menangguhkan - kesan sebarang semakan lain sehingga saat pod telah selesai dijalankan. Atas sebab ini, ciri ini pada asalnya dipanggil penahanan pod-startup liveness-probe. Untuk pod yang mengambil masa yang lama untuk dimulakan, anda boleh meninjau negeri dalam selang masa yang agak singkat.

Di samping itu, peningkatan untuk RuntimeClass tersedia serta-merta dalam status beta, menambah sokongan untuk "kelompok heterogen". C Penjadualan RuntimeClass Kini tidak perlu sama sekali untuk setiap nod mempunyai sokongan untuk setiap RuntimeClass: untuk pod anda boleh memilih RuntimeClass tanpa memikirkan topologi kluster. Sebelum ini, untuk mencapai ini - supaya pod berakhir pada nod dengan sokongan untuk semua yang mereka perlukan - adalah perlu untuk menetapkan peraturan yang sesuai kepada NodeSelector dan toleransi. DALAM CAP Ia bercakap tentang contoh penggunaan dan, sudah tentu, butiran pelaksanaan.

Сеть

Dua ciri rangkaian penting yang muncul buat kali pertama (dalam versi alfa) dalam Kubernetes 1.16 ialah:

• Sokongan susunan rangkaian dwi - IPv4/IPv6 - dan "pemahaman" yang sepadan pada tahap pod, nod, perkhidmatan. Ia termasuk kesalingoperasian IPv4-ke-IPv4 dan IPv6-ke-IPv6 antara pod, daripada pod kepada perkhidmatan luaran, pelaksanaan rujukan (dalam pemalam Bridge CNI, PTP CNI dan IPAM Host-Local), serta serasi terbalik dengan gugusan Kubernetes yang berjalan IPv4 atau IPv6 sahaja. Butiran pelaksanaan ada dalam CAP.

  Contoh memaparkan alamat IP dua jenis (IPv4 dan IPv6) dalam senarai pod:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• API baharu untuk Endpoint - API EndpointSlice. Ia menyelesaikan isu prestasi/skala API Endpoint sedia ada yang mempengaruhi pelbagai komponen dalam satah kawalan (pelayan api, dll, pengawal titik akhir, proksi kube). API baharu akan ditambahkan pada kumpulan Discovery API dan akan dapat menyampaikan puluhan ribu titik akhir hujung belakang pada setiap perkhidmatan dalam kelompok yang terdiri daripada beribu-ribu nod. Untuk melakukan ini, setiap Perkhidmatan dipetakan ke N objek EndpointSlice, setiap satunya secara lalai tidak mempunyai lebih daripada 100 titik akhir (nilai boleh dikonfigurasikan). EndpointSlice API juga akan menyediakan peluang untuk pembangunan masa depannya: sokongan untuk berbilang alamat IP untuk setiap pod, keadaan baharu untuk titik akhir (bukan sahaja Ready и NotReady), subset dinamik untuk titik akhir.

Yang dibentangkan dalam keluaran terakhir telah mencapai versi beta pemenang akhir, bernama service.kubernetes.io/load-balancer-cleanup dan dilampirkan pada setiap perkhidmatan dengan jenis LoadBalancer. Pada masa memadamkan perkhidmatan sedemikian, ia menghalang pemadaman sebenar sumber sehingga "pembersihan" semua sumber pengimbang yang berkaitan selesai.

Jentera API

"Pencapaian penstabilan" sebenar adalah dalam bidang pelayan API Kubernetes dan interaksi dengannya. Ini berlaku sebahagian besarnya terima kasih kepada memindahkan kepada status stabil mereka yang tidak memerlukan pengenalan khas CustomResourceDefinitions (CRD), yang mempunyai status beta sejak zaman jauh Kubernetes 1.7 (dan ini adalah Jun 2017!). Penstabilan yang sama datang kepada ciri yang berkaitan:

• "subsumber" dengan /status и /scale untuk CustomResources;
• penukaran versi untuk CRD, berdasarkan webhook luaran;
• baru-baru ini dibentangkan (dalam K8s 1.15) nilai lalai (lalai) dan penyingkiran medan automatik (pemangkasan) untuk CustomResources;
• peluang menggunakan skema OpenAPI v3 untuk mencipta dan menerbitkan dokumentasi OpenAPI yang digunakan untuk mengesahkan sumber CRD di bahagian pelayan.

Satu lagi mekanisme yang telah lama dikenali oleh pentadbir Kubernetes: webhook kemasukan - juga kekal dalam status beta untuk masa yang lama (sejak K8s 1.9) dan kini diisytiharkan stabil.

Dua ciri lain telah mencapai beta: digunakan sebelah pelayan и tonton penanda buku.

Dan satu-satunya inovasi penting dalam versi alfa ialah kegagalan daripada SelfLink — URI khas yang mewakili objek yang ditentukan dan menjadi sebahagian daripada ObjectMeta и ListMeta (iaitu sebahagian daripada sebarang objek dalam Kubernetes). Mengapa mereka meninggalkannya? Motivasi dengan cara yang mudah bunyi kerana ketiadaan sebab-sebab yang nyata (yang luar biasa) untuk bidang ini masih wujud. Sebab yang lebih formal adalah untuk mengoptimumkan prestasi (dengan mengalih keluar medan yang tidak perlu) dan untuk memudahkan kerja generik-apiserver, yang terpaksa mengendalikan medan sedemikian dengan cara yang istimewa (ini adalah satu-satunya medan yang ditetapkan tepat sebelum objek adalah bersiri). Keusangan sebenar (dalam beta) SelfLink akan berlaku oleh Kubernetes versi 1.20, dan akhir - 1.21.

Simpanan data

Kerja utama di kawasan penyimpanan, seperti dalam keluaran sebelumnya, diperhatikan di kawasan itu sokongan CSI. Perubahan utama di sini ialah:

• buat kali pertama (dalam versi alfa) muncul Sokongan pemalam CSI untuk nod pekerja Windows: cara semasa bekerja dengan storan juga akan menggantikan pemalam dalam pokok dalam teras Kubernetes dan pemalam FlexVolume daripada Microsoft berdasarkan Powershell;

  
  Skim untuk melaksanakan pemalam CSI dalam Kubernetes untuk Windows

• peluang mengubah saiz volum CSI, yang diperkenalkan semula dalam K8s 1.12, telah berkembang kepada versi beta;
• "Promosi" yang serupa (daripada alfa kepada beta) dicapai dengan keupayaan untuk menggunakan CSI untuk mencipta volum sementara tempatan (Sokongan Volum Sebaris CSI).

Diperkenalkan dalam versi Kubernetes sebelumnya fungsi pengklonan volum (menggunakan PVC sedia ada sebagai DataSource untuk mencipta PVC baharu) juga kini telah menerima status beta.

Penjadual

Dua perubahan ketara pada penjadualan (kedua-duanya dalam alfa):

• EvenPodsSpreading - peluang gunakan pod dan bukannya unit aplikasi logik untuk "agihan adil" beban (seperti Deployment dan ReplicaSet) dan melaraskan pengedaran ini (sebagai keperluan keras atau sebagai keadaan lembut, iaitu keutamaan). Ciri ini akan mengembangkan keupayaan pengedaran sedia ada pod yang dirancang, yang kini dihadkan oleh pilihan PodAffinity и PodAntiAffinity, memberikan pentadbir kawalan yang lebih baik dalam perkara ini, yang bermaksud ketersediaan tinggi yang lebih baik dan penggunaan sumber yang dioptimumkan. Butiran - dalam CAP.
• Gunakan Dasar BestFit в Fungsi Keutamaan RequestedToCapacityNisbah semasa perancangan pod, yang akan membolehkan untuk memohon pembungkusan tong sampah (“membungkus dalam bekas”) untuk kedua-dua sumber asas (pemproses, memori) dan sumber lanjutan (seperti GPU). Untuk butiran lanjut, lihat CAP.

  
  Pod penjadualan: sebelum menggunakan dasar paling sesuai (secara langsung melalui penjadual lalai) dan dengan penggunaannya (melalui pelanjut penjadual)

Tambahan pula, diwakili oleh keupayaan untuk mencipta pemalam penjadual anda sendiri di luar pokok pembangunan Kubernetes utama (di luar pokok).

Perubahan lain

Juga dalam keluaran Kubernetes 1.16 ia boleh diperhatikan inisiatif untuk membawa metrik tersedia dalam susunan penuh, atau lebih tepat lagi, selaras dengan peraturan rasmi kepada instrumentasi K8s. Mereka sebahagian besarnya bergantung pada yang sepadan dokumentasi Prometheus. Ketidakkonsistenan timbul atas pelbagai sebab (contohnya, beberapa metrik hanya dibuat sebelum arahan semasa muncul), dan pembangun memutuskan bahawa sudah tiba masanya untuk membawa segala-galanya kepada satu standard, "selaras dengan ekosistem Prometheus yang lain." Pelaksanaan semasa inisiatif ini adalah dalam status alfa, yang akan dinaikkan secara progresif dalam versi Kubernetes seterusnya kepada beta (1.17) dan stabil (1.18).

Di samping itu, perubahan berikut boleh diperhatikan:

• Pembangunan sokongan Windows с penampilan Utiliti Kubeadm untuk OS ini (versi alfa), peluang RunAsUserName untuk bekas Windows (versi alfa), penambahbaikan Akaun Perkhidmatan Terurus Kumpulan (gMSA) menyokong sehingga versi beta, sokongan lekapkan/pasang untuk volum vSphere.
• Dikitar semula mekanisme pemampatan data dalam tindak balas API. Sebelum ini, penapis HTTP telah digunakan untuk tujuan ini, yang mengenakan beberapa sekatan yang menghalangnya daripada didayakan secara lalai. "Mampatan permintaan telus" kini berfungsi: pelanggan menghantar Accept-Encoding: gzip dalam pengepala, mereka menerima respons termampat GZIP jika saiznya melebihi 128 KB. Pelanggan Go secara automatik menyokong pemampatan (menghantar pengepala yang diperlukan), jadi mereka akan segera melihat pengurangan trafik. (Pengubahsuaian sedikit mungkin diperlukan untuk bahasa lain.)
• Menjadi mungkin menskalakan HPA daripada/kepada sifar pod berdasarkan metrik luaran. Jika anda menskalakan berdasarkan objek/metrik luaran, maka apabila beban kerja melahu anda boleh menskalakan secara automatik kepada 0 replika untuk menjimatkan sumber. Ciri ini sepatutnya berguna terutamanya untuk kes di mana pekerja meminta sumber GPU dan bilangan jenis pekerja terbiar yang berbeza melebihi bilangan GPU yang tersedia.
• Pelanggan baru - k8s.io/client-go/metadata.Client — untuk akses "umum" kepada objek. Ia direka bentuk untuk mendapatkan semula metadata dengan mudah (iaitu subseksyen metadata) daripada sumber kluster dan melaksanakan kutipan sampah dan operasi kuota dengan mereka.
• Bina Kubernetes sekarang kamu boleh tanpa pembekal awan (“terbina dalam” dalam pokok) warisan (versi alfa).
• Kepada utiliti kubeadm tambah keupayaan percubaan (versi alfa) untuk menggunakan tampung tersuai semasa operasi init, join и upgrade. Ketahui lebih lanjut tentang cara menggunakan bendera --experimental-kustomize, lihat dalam CAP.
• Titik akhir baharu untuk apiserver - readyz, - membolehkan anda mengeksport maklumat tentang kesediaannya. Pelayan API juga kini mempunyai bendera --maximum-startup-sequence-duration, membolehkan anda mengawal selia permulaan semulanya.
• Dua ciri untuk Azure diisytiharkan stabil: sokongan zon ketersediaan (Zon Ketersediaan) dan kumpulan sumber silang (RG). Di samping itu, Azure telah menambah:
  • sokongan pengesahan AAD dan ADFS;
  • penjelasan service.beta.kubernetes.io/azure-pip-name untuk menentukan IP awam pengimbang beban;
  • peluang tetapan LoadBalancerName и LoadBalancerResourceGroup.
• AWS kini mempunyai menyokong untuk EBS pada Windows dan dioptimumkan Panggilan API EC2 DescribeInstances.
• Kubeadm kini bebas berhijrah Konfigurasi CoreDNS apabila menaik taraf versi CoreDNS.
• binari dll dalam imej Docker yang sepadan selesai boleh laku dunia, yang membolehkan anda menjalankan imej ini tanpa memerlukan hak root. Juga, imej migrasi etcd berhenti sokongan versi etcd2.
• В Kluster Autoscaler 1.16.0 beralih kepada menggunakan distroless sebagai imej asas, meningkatkan prestasi, menambah penyedia awan baharu (DigitalOcean, Magnum, Packet).
• Kemas kini dalam perisian terpakai/bergantung: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Baca juga di blog kami:

• «Kubernetes 1.15: gambaran keseluruhan inovasi utama»;
• «Kubernetes 1.14: gambaran keseluruhan inovasi utama»;
• «Kubernetes 1.13: gambaran keseluruhan inovasi utama»;
• «Kubernetes 1.12: gambaran keseluruhan inovasi utama'.

Sumber: www.habr.com