Praktik terbaik untuk fitur penjadwal lanjutan di Azure Kubernetes Service (AKS)

Artikel
08/02/2024

Saat Anda mengelola kluster di Azure Kubernetes Service (AKS), Anda seringkali perlu mengisolasi tim dan beban kerja. Fitur lanjutan yang disediakan oleh penjadwal Kube memungkinkan Anda mengontrol:

Pod mana yang dapat dijadwalkan pada simpul tertentu.
Bagaimana aplikasi multi-Pod dapat didistribusikan dengan tepat di seluruh kluster.

Artikel praktik terbaik ini berfokus pada fitur penjadwalan Kube lanjutan untuk operator kluster. Dalam artikel ini, Anda akan mempelajari cara:

Menggunakan taint dan toleration untuk membatasi pod apa yang dapat dijadwalkan pada simpul.
Memberikan preferensi pada pod untuk dijalankan pada simpul tertentu dengan pemilih simpul atau afinitas simpul.
Memisahkan atau mengelompokkan pod bersama dengan afinitas antar pod atau anti-afinitas.
Batasi penjadwalan beban kerja yang memerlukan GPU hanya pada simpul dengan GPU yang dapat di-scheedulable.

Menyediakan simpul khusus menggunakan taint dan toleration

Panduan praktik terbaik:

Batasi akses untuk aplikasi intensif sumber daya, seperti pengontrol ingress hingga simpul tertentu. Jaga agar sumber daya simpul tetap tersedia untuk beban kerja yang memerlukannya, dan jangan izinkan penjadwalan beban kerja lain pada simpul.

Saat membuat kluster AKS, Anda dapat menyebarkan simpul dengan dukungan GPU atau sejumlah besar CPU yang kuat. Untuk informasi selengkapnya, lihat Menggunakan GPU di AKS. Anda dapat menggunakan simpul ini untuk beban kerja pemrosesan data besar seperti pembelajaran mesin (ML) atau kecerdasan buatan (AI).

Karena perangkat keras sumber daya simpul ini biasanya mahal untuk disebarkan, batasi beban kerja yang dapat dijadwalkan pada simpul ini. Sebagai gantinya, dedikasikan beberapa simpul dalam kluster untuk menjalankan layanan ingress dan mencegah beban kerja lainnya.

Dukungan untuk simpul yang berbeda ini disediakan dengan menggunakan beberapa kumpulan simpul. Kluster AKS mendukung satu atau beberapa kumpulan simpul.

Penjadwal Kube menggunakan taint dan toleration untuk membatasi jenis beban kerja yang dapat berjalan pada simpul.

Terapkan taint ke simpul untuk menunjukkan hanya pod tertentu yang dapat dijadwalkan di sana.
Kemudian terapkan toleration ke pod, yang memungkinkan mereka untuk mentolerir taint simpul.

Saat Anda menyebarkan pod ke kluster AKS, Kube hanya menjadwalkan pod pada simpul yang taint-nya selaras dengan toleration. Taint dan toleransi bekerja sama untuk memastikan bahwa pod tidak dijadwalkan ke simpul yang tidak pantas. Satu atau beberapa taint diterapkan ke simpul, menandai simpul sehingga tidak menerima pod apa pun yang tidak mentolerir taint.

Misalnya, asumsikan Anda menambahkan kumpulan simpul di kluster AKS Anda untuk simpul dengan dukungan GPU. Anda menentukan nama, seperti gpu, lalu nilai untuk penjadwalan. Mengatur nilai ini ke NoSchedule membatasi penjadwal Kube dari penjadwalan pod dengan toleration yang tidak ditentukan pada simpul.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name taintnp \
    --node-taints sku=gpu:NoSchedule \
    --no-wait

Dengan taint yang diterapkan pada simpul di kumpulan simpul, Anda menentukan toleransi dalam spesifikasi pod yang memungkinkan penjadwalan pada simpul. Contoh berikut menentukan sku: gpu dan effect: NoSchedule untuk mentolerir taint yang diterapkan ke kumpulan simpul di langkah sebelumnya:

kind: Pod
apiVersion: v1
metadata:
  name: app
spec:
  containers:
  - name: app
    image: <your-workload>:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  tolerations:
  - key: "sku"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

Saat pod ini disebarkan menggunakan kubectl apply -f gpu-toleration.yaml, Kube berhasil menjadwalkan pod pada simpul dengan taint yang diterapkan. Isolasi logis ini memungkinkan Anda mengontrol akses ke sumber daya dalam kluster.

Saat Anda menerapkan taint, bekerja samalah dengan pengembang dan pemilik aplikasi Anda untuk mengizinkan mereka menentukan toleration yang diperlukan dalam penyebaran mereka.

Untuk informasi selengkapnya tentang cara menggunakan beberapa kumpulan simpul di AKS, lihat Membuat beberapa kumpulan simpul untuk kluster di AKS.

Perilaku taint dan toleration di AKS

Saat Anda meningkatkan kumpulan simpul di AKS, taint dan toleration mengikuti pola yang ditetapkan saat diterapkan ke simpul baru:

Kluster default yang menggunakan Azure Virtual Machine Scale Sets

Anda dapat melakukan taint kumpulan simpul dari API AKS agar simpul yang baru diluaskan skalanya menerima taint simpul yang ditentukan API.

Mari kita asumsikan:

Anda mulai dengan kluster dua simpul: node1 dan node2.
Anda meningkatkan kumpulan simpul.
Dua simpul lain dibuat: node3 dan node4.
Taint tersebut diteruskan masing-masing.
node1 dan node2 asli dihapus.

Kluster tanpa dukungan Virtual Machine Scale Sets

Sekali lagi, mari kita asumsikan:

Anda memiliki kluster dua simpul: node1 dan node2.
Anda meningkatkan kumpulan simpul.
Simpul tambahan dibuat: node3.
Taint dari node1 diterapkan ke node3.
node1 dihapus.
node1 baru dibuat untuk menggantikan node1 asli.
Taint node2 diterapkan ke node1 baru.
node2 dihapus.

Intinya, node1 menjadi node3, dan node2 menjadi node1 baru.

Ketika Anda menskalakan kumpulan simpul di AKS, taint dan toleransi tidak dibawa berdasarkan desain.

Mengontrol penjadwalan pod menggunakan pemilih simpul dan afinitas

Panduan praktik terbaik

Kontrol penjadwalan pod pada simpul menggunakan pemilih simpul, afinitas simpul, atau afinitas antar pod. Pengaturan ini memungkinkan penjadwal Kube untuk mengisolasi beban kerja secara logis, seperti oleh perangkat keras dalam simpul.

Taint dan toleration secara logis mengisolasi sumber daya dengan cut-off keras. Jika pod tidak mentolerir taint simpul, pod tidak dijadwalkan pada simpul.

Atau, Anda dapat menggunakan pemilih simpul. Misalnya, Anda memberi label pada simpul untuk menunjukkan penyimpanan SSD yang terpasang secara lokal atau memori dalam jumlah besar, lalu menentukan pemilih simpul dalam spesifikasi pod. Kube menjadwalkan pod tersebut pada simpul yang cocok.

Tidak seperti toleration, pod tanpa pemilih simpul yang cocok masih dapat dijadwalkan pada simpul berlabel. Perilaku ini memungkinkan sumber daya yang tidak terpakai pada simpul untuk digunakan, tetapi memprioritaskan pod yang menentukan pemilih simpul yang cocok.

Mari kita lihat contoh simpul dengan jumlah memori yang tinggi. Simpul ini memprioritaskan pod yang meminta memori dalam jumlah besar. Untuk memastikan sumber daya tidak diam, simpul juga mengizinkan pod lain untuk dijalankan. Contoh perintah berikut menambahkan kumpulan simpul dengan label hardware=highmem ke myAKSCluster di myResourceGroup. Semua simpul dalam kumpulan simpul tersebut memiliki label ini.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name labelnp \
    --node-count 1 \
    --labels hardware=highmem \
    --no-wait

Spesifikasi pod kemudian menambahkan properti nodeSelector untuk menentukan pemilih simpul yang cocok dengan label yang ditetapkan pada simpul:

kind: Pod
apiVersion: v1
metadata:
  name: app
spec:
  containers:
  - name: app
    image: <your-workload>:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  nodeSelector:
      hardware: highmem

Saat Anda menggunakan opsi penjadwal ini, bekerja samalah dengan pengembang dan pemilik aplikasi Anda untuk mengizinkan mereka menentukan spesifikasi pod mereka dengan benar.

Untuk informasi selengkapnya tentang menggunakan pemilih simpul, lihat Menetapkan Pod ke Simpul.

Afinitas simpul

Pemilih simpul adalah solusi dasar untuk menetapkan pod ke simpul tertentu. Afinitas simpul memberikan lebih banyak fleksibilitas, memungkinkan Anda untuk menentukan apa yang terjadi jika pod tidak dapat dicocokkan dengan simpul. Anda dapat:

Mengharuskan penjadwal Kube mencocokkan pod dengan host berlabel. Atau,
Lebih memilih pertandingan tetapi izinkan pod dijadwalkan pada host yang berbeda jika tidak ada kecocokan yang tersedia.

Contoh berikut mengatur afinitas simpul ke requiredDuringSchedulingIgnoredDuringExecution. Afinitas ini mengharuskan jadwal Kube untuk menggunakan simpul dengan label yang cocok. Jika tidak ada simpul yang tersedia, pod harus menunggu penjadwalan dilanjutkan. Untuk mengizinkan pod dijadwalkan pada node yang berbeda, Anda dapat mengatur nilainya ke lebih memilihDuringSchedulingIgnoreDuringExecution:

kind: Pod
apiVersion: v1
metadata:
  name: app
spec:
  containers:
  - name: app
    image: <your-workload>:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: hardware
            operator: In
            values:
            - highmem

Bagian IgnoredDuringExecution dari pengaturan menunjukkan bahwa pod tidak boleh dikeluarkan dari simpul jika label simpul berubah. Penjadwal Kube hanya menggunakan label simpul yang diperbarui untuk pod baru yang dijadwalkan, bukan pod yang sudah dijadwalkan pada simpul.

Untuk informasi selengkapnya, lihat Afinitas dan anti-afinitas.

Afinitas antar-pod dan anti-afinitas

Salah satu pendekatan terakhir bagi penjadwal Kube untuk mengisolasi beban kerja secara logis adalah menggunakan afinitas atau anti-afinitas antar-pod. Pengaturan ini menentukan bahwa pod tidak boleh atau harus dijadwalkan pada simpul yang sudah memiliki pod yang cocok. Secara default, penjadwal Kube mencoba menjadwalkan beberapa pod dalam replika yang diatur di seluruh simpul. Anda dapat menentukan aturan yang lebih spesifik seputar perilaku ini.

Misalnya, Anda memiliki aplikasi web yang juga menggunakan Azure Cache for Redis.

Anda menggunakan aturan anti-afinitas pod untuk meminta penjadwal Kube mendistribusikan replika di seluruh simpul.
Anda menggunakan aturan afinitas untuk memastikan setiap komponen aplikasi web dijadwalkan pada host yang sama dengan cache yang sesuai.

Distribusi pod di seluruh simpul terlihat seperti contoh berikut:

Simpul 1	Simpul 2	Simpul 3
webapp-1	webapp-2	webapp-3
cache-1	cache-2	cache-3

Afinitas antar-pod dan anti-afinitas memberikan penyebaran yang lebih kompleks daripada selektor simpul atau afinitas simpul. Dengan penyebaran tersebut, Anda secara logis mengisolasi sumber daya dan mengontrol bagaimana Kube menjadwalkan pod pada simpul.

Untuk contoh lengkap aplikasi web ini dengan contoh Azure Cache for Redis, lihat Menempatkan bersama pod pada simpul yang sama.

Langkah berikutnya

Artikel ini berfokus pada fitur penjadwal Kube lanjutan. Untuk informasi selengkapnya tentang operasi kluster di AKS, lihat praktik terbaik berikut:

Bagikan melalui