Kubernetes 1.18: Tinjauan Umum Inovasi-inovasi Utama

Kemarin, 25 Maret yang rilis berikutnya dari Kubernetes - 1,18. Menurut tradisi untuk blog kami, kami berbicara tentang perubahan paling signifikan dalam versi baru.



Informasi yang digunakan untuk mempersiapkan bahan ini diambil dari pengumuman resmi, tabel pelacakan perangkat tambahan Kubernet , CHANGELOG-1.18 , ulasan dari SUSE dan Sysdig , serta masalah terkait, permintaan tarik, Kubernetes Enhancement Proposals (KEP) ...

Rilis Kubernetes 1.18 menerima logo resminya, yang intinya dikurangi untuk membandingkan proyek dengan Large Hadron Collider. Seperti LHC, yang merupakan hasil karya ribuan ilmuwan dari seluruh dunia, Kubernet menyatukan ribuan pengembang dari ratusan organisasi, dan semuanya bekerja pada tujuan bersama: "meningkatkan komputasi awan di semua aspek."



Sementara itu, penggemar dari tim SUSE menyiapkan kata cloud berdasarkan catatan rilis untuk 3412 komitmen yang dibuat untuk K8 1.18. Dan ternyata seperti ini:



Sekarang - tentang apa yang ada di balik kata-kata ini, dalam bentuk yang lebih dimengerti oleh pengguna.

Penjadwal


Inovasi utama di sini - Perencanaan profil (Penjadwalan Profil) . Hal ini terkait dengan fakta bahwa semakin heterogennya beban kerja di cluster, semakin cepat kebutuhan akan pendekatan yang berbeda untuk perencanaan mereka muncul.

Untuk mengatasi masalah ini, penulis mengusulkan bahwa penjadwal menggunakan konfigurasi berbeda yang ditugaskan untuk penjadwal dan disebut profil. Memulai, penjadwal-kubus memindai semua profil yang tersedia dan menyimpannya dalam registri. Jika tidak ada profil dalam konfigurasi, opsi default ( default-scheduler) dipilih . Setelah pod berada dalam antrian, kube-scheduler melakukan perencanaannya dengan mempertimbangkan penjadwal yang dipilih.

Perencanaan kebijakan Sami berdasarkan predikat ( PodFitsResources, PodMatchNodeSelector,PodToleratesNodeTaintsdll) dan prioritas ( SelectorSpreadPriority, InterPodAffinityPriority, MostRequestedPriority, EvenPodsSpreadPrioritydll). Implementasi segera menyediakan sistem plugin sehingga semua profil ditambahkan melalui kerangka kerja khusus.

Struktur konfigurasi saat ini (akan segera diubah):

type KubeSchedulerConfiguration struct {
   ...
   SchedulerName string
   AlgorithmSource SchedulerAlgorithmSource
   HardPodAffinitySymmetricWeight
   Plugins *Plugins
   PluginConfig []PluginConfig
   ...
}

... dan contoh konfigurasi:

profiles:
  - schedulerName: 'default-scheduler'
    pluginConfig:
      - name: 'InterPodAffinity'
      - args:
          hadPodAffinityWeight: <value>

Dengan rilis K8 berikutnya, fitur ini diharapkan akan diterjemahkan ke dalam beta, dan setelah dua lagi - stabilisasi. Untuk informasi lebih lanjut tentang profil untuk penjadwal, lihat KEP yang sesuai .

Inovasi lain yang muncul dalam status versi alfa adalah aturan default untuk pemerataan pod (Even Pod Spreading) . Saat ini, aturan didefinisikan PodSpecdan dilampirkan ke pod, dan sekarang telah dimungkinkan untuk mengatur konfigurasi global di tingkat cluster. Detailnya ada di KEP .

Pada saat yang sama, fitur Penyebaran Topologi Pod itu sendiri (gerbang fiturnya - EvenPodsSpread), yang memungkinkan pendistribusian pod secara merata di seluruh kluster multi-zona, telah diterjemahkan ke dalam status beta.

Selain itu, stabilisasi Penggusuran Berbasis Taint telah diumumkan , dirancang untuk menambahkan noda pada simpul ketika kondisi tertentu terjadi. Untuk pertama kalinya, fitur ini muncul dalam rilis K8s 1.8 yang sudah jauh , dan menerima status beta di 1,13 .

Kecepatan penskalaan khusus HPA


Selama lebih dari setahun, fitur menarik yang disebut Kecepatan skala yang dapat dikonfigurasi untuk HPA telah mendekam di tungku perangkat tambahan Kubernetes , yaitu. kecepatan zoom horizontal yang dapat disesuaikan. (Ngomong-ngomong, rekan kami memprakarsai pengembangannya .) Dalam rilis baru, ia dibawa ke tahap pertama penggunaan massal - itu tersedia dalam versi alpha.

Seperti yang Anda ketahui, Horizontal Pod Autoscaler (HPA) di Kubernetes mengukur jumlah pod untuk sumber daya apa pun yang mendukung sub-sumber dayascaleberdasarkan konsumsi CPU atau metrik lainnya. Fitur baru memungkinkan Anda untuk mengontrol kecepatan terjadinya penskalaan ini, dan di kedua arah. Sampai sekarang, dimungkinkan untuk mengaturnya hingga batas yang sangat terbatas (lihat, misalnya, parameter global untuk kluster --horizontal-pod-autoscaler-downscale-stabilization-window).

Motivasi utama untuk memperkenalkan kecepatan penskalaan kustom adalah kemampuan untuk memisahkan beban kerja kluster sesuai dengan kepentingannya untuk bisnis, memungkinkan satu aplikasi (yang memproses lalu lintas paling kritis) untuk memiliki kecepatan peningkatan maksimum dalam ukuran dan kecepatan roll-up yang rendah (karena ledakan beban baru dapat terjadi), dan untuk orang lain - untuk mengukur sesuai dengan kriteria lain (untuk menghemat uang, dll.).

Solusi yang Diusulkan - Objek yang Ditambahkan untuk Konfigurasi HPAbehavior, memungkinkan Anda menentukan aturan untuk mengontrol penskalaan di kedua arah ( scaleUpdan scaleDown). Sebagai contoh, konfigurasi:

behavior:
  scaleUp:
    policies:
    - type: percent
      value: 900%

... akan mengarah pada kenyataan bahwa jumlah pod yang saat ini berjalan akan meningkat sebesar 900%. Yaitu, jika aplikasi dimulai sebagai satu pod, jika perlu untuk menskalakannya akan mulai tumbuh sebagai 1 β†’ 10 β†’ 100 β†’ 1000. Untuk

contoh dan detail implementasi lainnya, lihat KEP .

Simpul


Kemajuan dalam mendukung hugepage ( KEP total untuk fiche ): versi alpha mengimplementasikan dukungan untuk halaman-halaman ini pada level kontainer dan kemampuan untuk meminta halaman dengan ukuran berbeda.

Node Topology Manager ( Node the Topology Manager ) , yang dirancang untuk menyatukan pendekatan untuk menyempurnakan alokasi sumber daya perangkat keras ke berbagai komponen di Kubernetes, ditransfer ke status beta.

Status versi beta untuk mendapatkan ide menjadi fitur K8 1.16 PodOverhead , mekanisme yang diusulkan untuk menghitung overhead pod'y.

kubectl


Versi alpha dari perintah debug kubectl ( KEP ) telah ditambahkan , yang mengembangkan konsep " wadah sementara ". Mereka pertama kali diperkenalkan di K8 1.16 dengan tujuan menyederhanakan debugging di pod. Untuk melakukan ini, di pod kanan, wadah sementara (mis., Hidup untuk waktu singkat) diluncurkan yang berisi alat yang diperlukan untuk debugging. Seperti kita sudah menulis, perintah ini pada dasarnya identik dengan kubectl debug plug-in yang ada sejauh ( meninjau ).

Ilustrasi Pekerjaan kubectl debug:

% kubectl help debug
Execute a container in a pod.

Examples:
  # Start an interactive debugging session with a debian image
  kubectl debug mypod --image=debian

  # Run a debugging session in the same namespace as target container 'myapp'
  # (Useful for debugging other containers when shareProcessNamespace is false)
  kubectl debug mypod --target=myapp

Options:
  -a, --attach=true: Automatically attach to container once created
  -c, --container='': Container name.
  -i, --stdin=true: Pass stdin to the container
  --image='': Required. Container image to use for debug container.
  --target='': Target processes in this container name.
  -t, --tty=true: Stdin is a TTY

Usage:
  kubectl debug (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

Tim lain, kubectl diff , yang pertama kali muncul di K8 1.9 dan menerima status beta di 1.13, akhirnya dinyatakan stabil. Sesuai namanya, ini memungkinkan Anda untuk membandingkan konfigurasi cluster. Pada kesempatan fitur stabilisasi, dia muncul KEP , dan telah diperbarui dengan semua situs Kubernetes dokumentasi yang relevan.

Selain itu, bendera kubectl --dry-lari menambahkan dukungan untuk nilai yang berbeda dari ( client, server, none), yang memungkinkan Anda mencoba untuk menjalankan perintah hanya pada sisi client atau server. Untuk implementasinya pada sisi server mengimplementasikan dukungan untuk tim-tim besar termasuk create,apply, patchdan lainnya.

Jaringan


Sumber daya Ingress mulai bergerak dari grup API ( extensions.v1beta1) saat ini networking.v1beta1ke, diikuti oleh stabilisasi dalam tampilan v1. Serangkaian perubahan ( KEP ) direncanakan untuk ini . Saat ini - sebagai bagian dari versi beta di K8 1.18 - Ingress telah menerima dua inovasi signifikan :

  • bidang baru pathTypeyang memungkinkan Anda untuk menentukan dengan prinsip apa jalan akan dibandingkan ( Exact, Prefixatau ImplementationSpecific; perilaku terakhir ditentukan dalam IngressClass);
  • sumber daya baru IngressClassdan bidang baru (tidak berubah) Classdalam definisi IngressSpecyang menunjukkan pengontrol mana yang mengimplementasikan sumber daya Ingress. Perubahan ini menggantikan anotasi kubernetes.io/ingress.class, yang penggunaannya akan usang.

Untuk banyak fitur jaringan, status ketersediaan telah ditingkatkan:

  • plugin NodeLocal DNS Cache telah menjadi stabil , yang meningkatkan kinerja DNS dengan menggunakan agen untuk cache DNS pada node cluster;
  • stabil dan menyatakan bidang AppProtocolyang mendefinisikan protokol aplikasi untuk setiap port layanan (sumber daya ServicePortdan EndpointPort);
  • Dukungan IPv6 diakui cukup stabil untuk menerjemahkannya ke versi beta;
  • Secara default, EndpointSlices API sekarang diaktifkan (sebagai bagian dari versi beta) , bertindak sebagai pengganti yang lebih skalabel dan dapat diperluas untuk Endpoint biasa.

Fasilitas penyimpanan


Versi alfa menyediakan dasar untuk membuat volume dengan data yang dimuat sebelumnya - Generic Data Populators ( KEP ). Sebagai implementasi, diusulkan untuk melemahkan validasi lapangan DataSourcesehingga objek tipe sewenang-wenang dapat menjadi sumber data.

Sebelum mengikat volume ke dalam wadah, hak untuk semua file diubah sesuai dengan nilainya fsGroup. Operasi ini dapat memutus kerja beberapa aplikasi (misalnya, DBMS populer), dan juga membutuhkan banyak waktu (untuk volume besar - lebih dari 1 TB). Bidang baruPermissionChangePolicy untuk PersistentVolumeClaimVolumeSource memungkinkan Anda menentukan apakah Anda ingin mengubah pemilik untuk konten volume. Implementasi saat ini adalah versi alfa, detailnya ada diKEP .

Untuk objek Secrets, bidang baru telah ConfigMaps ditambahkan , menjadikannya tidak berubah. Sebagai aturan, objek-objek ini digunakan dalam pods sebagai file. Setiap perubahan dalam file-file ini dengan cepat (setelah sekitar satu menit) berlaku untuk semua pod yang me-mount file. Dengan demikian, pembaruan rahasia atau ConfigMap yang tidak berhasil dapat menyebabkan kegagalan seluruh aplikasi. Para penulis fitur mengatakan bahwa bahkan dalam kasus memperbarui aplikasi dengan metode yang direkomendasikan - melalui peningkatan bergulir - mungkin ada kegagalan yang disebabkan oleh pembaruan rahasia / ConfigMaps yang tidak berhasil. Selain itu, proses memperbarui objek-objek ini dalam menjalankan pod rumit dalam hal kinerja dan skalabilitas (setiap kubelet dipaksa untuk terus-menerus memonitor setiap rahasia unik / CM).immutable



Dalam implementasi saat ini, dilakukan agar setelah sumber daya ditandai sebagai tidak dapat diubah, perubahan ini tidak dapat dibatalkan. Anda tidak hanya perlu menghapus objek dan membuatnya lagi, tetapi juga membuat ulang pod yang menggunakan rahasia jarak jauh. Versi - alfa, detail - KEP .

Dinyatakan stabil:


Perubahan lainnya


Di antara inovasi lain di Kubernetes 1.18 (untuk daftar yang lebih lengkap, lihat CHANGELOG ) :

  • JWT- Kubernetes service accounts (KSA) Kubernetes API. - . API- discovery-, OIDC (OpenID Connect) . OIDC (.. K8s-) KCA-, API-. β€” KEP.
  • - Priority and Fairness API (KEP) β€” API- ( max-in-flight). . ( FlowSchema) ( RequestPriority). kubectl:

    kind: RequestPriority
    meta:
      name: workload-high
    spec:
      assuredConcurrencyShares: 30
      queues: 128
      handSize: 6
      queueLengthLimit: 100
    
    kind: FlowSchema
    meta:
      name: workload-high
    spec:
      requestPriority:
        name: workload-high
      flowDistinguisher:
        source: namespace
        # no transformation in this case
      match:
      - and: # users using kubectl
        - notPatternMatch:
          field: user
          pattern: system:serviceaccount:.*
  • CertificateSigningRequest API, x509- Certificate Authority. K8s 1.4 - 1.6.
  • Sejumlah peningkatan signifikan dalam bekerja dengan Windows: dukungan CRI-ContainerD (versi alpha), implementasi RuntimeClass (versi alpha), dukungan driver CSI melalui proksi CSI (versi alpha), versi stabil dukungan GMSA (Akun Layanan Dikelola Grup) dan RunAsUserName .

Perubahan Ketergantungan:

  • Versi CoreDNS di kubeadm - 1.6.7;
  • cri-tools 1.17.0;
  • CNI (Container Networking Interface) 0.8.5, Calico 3.8.4;
  • Versi Go yang digunakan adalah 1.13.8.

Apa yang sudah ketinggalan zaman?


  • API Server tidak melayani API usang: semua sumber daya apps/v1beta1dan extensions/v1beta1kebutuhan untuk bergerak apps/v1, dan memperhatikan dengan sumber daya tertentu daemonsets, deployments, replicasets, networkpolicies, podsecuritypolicies;
  • titik akhir untuk metrik /metrics/resource/v1alpha1 tidak dilayani - sekarang sebagai gantinya /metrics/resource;
  • semua generator tim kubectl run dihapus kecuali yang bertanggung jawab untuk pembuatan pod.

PS


Baca juga di blog kami:


All Articles