Kelola pod pada kluster Kube multi-pool

Selesai

Pengembang Contoso sedang berupaya mengubah aplikasi Windows dan Linux yang dikembangkan secara internal menjadi citra berbasis Docker yang dapat disebarkan menggunakan bagan Helm. Dalam perencanaan Anda untuk mengimplementasikan kluster Kube pada Azure Stack HCI, Anda perlu memastikan dukungan untuk kedua platform sistem operasi tersebut.

Apa itu kumpulan node di kluster Kube pada Azure Stack HCI

AKS di Azure Stack HCI mendukung beberapa kumpulan node di kluster Kube yang sama. Setiap kumpulan terdiri dari VM yang dikonfigurasi secara identik, sesuai dengan pengaturan yang Anda tentukan saat menyediakan kumpulan itu.

Dengan mengelompokkan node ke dalam kumpulan terpisah, Anda dapat menargetkan penyebaran pod ke set VM yang sesuai. Misalnya, Anda mungkin memiliki beban kerja kontainer yang hanya didukung oleh sistem operasi Windows atau memerlukan perangkat keras khusus, seperti unit prosesor grafis.

Kontrol penyebaran pod ke dalam kumpulan node pada kluster Kube pada Azure Stack HCI

Secara default, Kube menjadwalkan provisi beban kerja kontainer pada setiap node pekerja yang tersedia dengan cara yang mengoptimalkan pemanfaatan sumber daya. Untuk mengubah perilaku ini, Anda dapat menerapkan batasan pada pilihan node berdasarkan kriteria kustom yang Anda tentukan. Batasan ini termasuk pemilih node dan taint dan toleransi.

Pemilih simpul

Node Selector adalah pengaturan dalam definisi berbasis YAML pada pod atau penyebaran yang mengidentifikasi node target di mana pod yang sesuai dapat dijadwalkan. Jika niat Anda adalah untuk menunjuk node target berdasarkan sistem operasinya, Anda dapat mengandalkan label bawaan yang secara otomatis ditetapkan ke node oleh Kube. Tergantung pada sistem operasi yang dimaksud, pemilih node akan mengambil bentuk kubernetes.io/os = Windows atau kubernetes.io/os = Linux. Misalnya, manifes pod berbasis YAML berikut menunjuk node Linux sebagai target penyebaran:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    kubernetes.io/os = Linux

Taint dan toleransi

Taint dan toleransi memberikan pendekatan alternatif untuk mengontrol penempatan pod. Dengan pendekatan ini, taint merupakan bagian dari konfigurasi node dan toleransi merupakan bagian dari spesifikasi pod. Dengan tainting node, Anda secara efektif mencegahnya meng-hosting pod apa pun tanpa toleransi khusus taint yang sesuai.

Misalnya, dalam AKS di Azure Stack HCI, jika Anda ingin mengizinkan pod dijadwalkan pada node Windows, Anda harus menambahkan toleransi berikut ke definisinya:

tolerations:
- key: node.kubernetes.io/os
  operator: Equal
  value: Windows
  effect: NoSchedule

Selain itu, Anda perlu menambahkan taint node.kubernetes.io/os=Windows:NoSchedule ke tiap node Windows yang ingin Anda jadikan tersedia secara eksklusif untuk penyebaran pod dengan toleransi yang sesuai. Untuk mencapainya, Anda dapat menggunakan utilitas baris perintah kubectl, dan kemudian, setelah terhubung ke kluster target, jalankan perintah berikut untuk setiap node dalam lingkup (di mana <node_name> tempat penampung menunjuk nama node target):

kubectl taint node <node_name> node.kubernetes.io/os=Windows:NoSchedule

Catatan

Pemilih node memberlakukan penempatan pod pada sekumpulan node tertentu. Toleransi memungkinkan pod untuk berjalan pada set node tainted yang ditunjuk, tetapi tidak mencegah penempatannya pada node tanpa taint.

Uji pengetahuan

1.

Contoso berencana untuk menyebarkan beban kerja kontainer Windows dan Linux ke AKS di Azure Stack HCI. Anda perlu mendokumentasikan prosedur yang akan memastikan bahwa pod berbasis Windows disebarkan ke node kluster Kube yang menjalankan Windows. Anda memutuskan untuk menggunakan taint dan toleransi untuk tujuan ini. Ke komponen kluster mana taint harus Anda terapkan?