Sebarkan Pod Berbasis Elastic Container Instance di Seluruh Zona dan Konfigurasikan Afinitas

Ketersediaan tinggi dan performa tinggi sangat penting untuk pekerjaan terdistribusi. Dalam ACK managed Pro cluster, Anda dapat menggunakan semantik penjadwalan Kubernetes asli untuk menyebarkan pekerjaan terdistribusi di seluruh zona demi ketersediaan tinggi. Anda juga dapat menggunakan semantik penjadwalan Kubernetes asli untuk menerapkan pod berbasis Elastic Container Instance di zona tertentu berdasarkan pengaturan afinitas untuk ketersediaan tinggi dan performa tinggi.

Prasyarat

Sebuah ACK Serverless Pro cluster telah dibuat dan kluster tersebut memenuhi persyaratan berikut:
- Kluster menjalankan Kubernetes versi 1.22 atau yang lebih baru.
- Versi komponen ACK Virtual Node dalam kluster adalah 2.10.0 atau yang lebih baru.
- Versi komponen kube-scheduler dalam kluster adalah 5.9 atau yang lebih baru, dan fitur penjadwalan pod berbasis node virtual telah diaktifkan untuk kluster tersebut. Untuk informasi lebih lanjut, lihat Aktifkan kebijakan penjadwalan pod berbasis node virtual untuk kluster ACK.
Beberapa zona (vSwitches) ditentukan dalam eci-profile sehingga pod dapat dijadwalkan ke beberapa zona. Untuk informasi lebih lanjut, lihat Konfigurasikan eci-profile.
Pastikan bahwa parameter nodeAffinity, podAffinity, dan topologySpreadConstraints dikonfigurasi untuk pod yang ingin Anda jadwalkan atau pod sesuai dengan kebijakan sumber daya yang ada.
Catatan
Jika Anda ingin menjadwalkan pod ke node virtual berbasis ARM, tentukan toleransi untuk menoleransi taint dari node virtual dalam parameter
tolerations konfigurasi pod.

Prasyarat

Sebuah ACK managed Pro cluster yang memenuhi persyaratan berikut telah dibuat:
- Kluster menjalankan Kubernetes 1.22 atau yang lebih baru.
- Versi komponen ACK Virtual Node dalam kluster adalah 2.10.0 atau yang lebih baru.
- Versi komponen kube-scheduler dalam kluster adalah 5.9 atau yang lebih baru. Selain itu, kebijakan penjadwalan pod berbasis node virtual telah diaktifkan untuk kluster tersebut..
Saat mengonfigurasi pod berbasis Elastic Container Instance, beberapa zona (vSwitches) ditentukan dalam eci-profile yang sesuai.
Bidang nodeAffinity, podAffinity, dan topologySpreadConstraints ditentukan dalam konfigurasi pod. Sebagai alternatif, ResourcePolicy dikonfigurasi untuk pod.
Catatan
Jika Anda ingin menjadwalkan pod ke node virtual berbasis ARM, Anda harus menambahkan toleransi spesifik yang sesuai dengan taint dari node ke pod.

Catatan Penggunaan

Anda harus mengatur parameter topologyKey menjadi topology.kubernetes.io/zone.
Fitur yang dibahas dalam topik ini tidak akan berlaku dalam skenario berikut:
- Anotasi k8s.aliyun.com/eci-schedule-strategy: "VSwitchOrdered" digunakan untuk mendeklarasikan strategi penjadwalan multi-zona untuk pod yang mengikuti urutan vSwitch tertentu.
- Anotasi k8s.aliyun.com/eci-fail-strategy: "fail-fast" digunakan untuk mengatur kebijakan penanganan kesalahan pod menjadi fail-fast.

Contoh berikut menunjukkan cara menyebarkan pod berbasis Elastic Container Instance di seluruh zona dan mengonfigurasi afinitas dalam ACK Pro cluster yang menjalankan Kubernetes 1.22.

Contoh 1: Gunakan kendala penyebaran topologi untuk menyebarkan pod berbasis Elastic Container Instance di seluruh zona

Tambahkan kendala penyebaran topologi ke konfigurasi beban kerja.

Lakukan langkah-langkah berikut untuk menentukan kendala penyebaran topologi dalam parameter Spec dalam konfigurasi pod atau parameter Spec dalam konfigurasi beban kerja, seperti Deployment atau Job.

  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # Parameter ini opsional dan berada dalam fase Beta di Kubernetes 1.25 dan yang lebih baru.
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # Parameter ini opsional dan berada dalam fase Beta di Kubernetes 1.27 dan yang lebih baru.
      nodeAffinityPolicy: [Honor|Ignore] # Parameter ini opsional dan berada dalam fase Beta di Kubernetes 1.26 dan yang lebih baru.
      nodeTaintsPolicy: [Honor|Ignore] # Parameter ini opsional dan berada dalam fase Beta di Kubernetes 1.26 dan yang lebih baru.

Dalam contoh ini, sebuah Deployment yang pod-nya didistribusikan secara merata ke beberapa zona dibuat. Blok kode berikut menunjukkan template YAML dari Deployment:

Tampilkan Konten YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-pod-topology-spread
  labels:
    app: with-pod-topology-spread
spec:
  replicas: 10
  selector:
    matchLabels:
      app: with-pod-topology-spread
  template:
    metadata:
      labels:
        app: with-pod-topology-spread
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: with-pod-topology-spread
      tolerations:
        - key: "virtual-kubelet.io/provider"
          operator: "Exists"
          effect: "NoSchedule"
      containers:
      - name: with-pod-topology-spread
        image: registry.k8s.io/pause:2.0
        resources:
          requests:
            cpu: "1"
            memory: "256Mi"

Parameter

Deskripsi

preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
  preference:
    matchExpressions:
    - key: type
      operator: NotIn
      values:
      - virtual-kubelet

Konfigurasi menentukan bahwa pod diprioritaskan untuk dijadwalkan ke node Elastic Compute Service (ECS).

Untuk informasi lebih lanjut tentang parameter, lihat Node affinity.

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: with-pod-topology-spread

Konfigurasi menentukan bahwa pod diterapkan secara merata di beberapa zona.

Untuk informasi lebih lanjut tentang parameter, lihat topologySpreadConstraints field.

tolerations:
  - key: "virtual-kubelet.io/provider"
    operator: "Exists"
    effect: "NoSchedule"

kube-scheduler mentolerir taint dari node virtual untuk menjadwalkan pod ke node virtual.

Untuk informasi lebih lanjut tentang parameter, lihat Taints and Tolerations.

Catatan

Jika Anda ingin menjadwalkan pod ke node virtual berbasis ARM, Anda harus menambahkan toleransi ke pod untuk mentolerir taint dari node virtual berbasis ARM.

Buat beban kerja.
Buat file bernama deployment.yaml dan salin template YAML sebelumnya ke file tersebut. Kemudian, jalankan perintah berikut untuk membuat Deployment di kluster:
```
kubectl apply -f deployment.yaml
```

Verifikasi hasil penjadwalan beban kerja.

Jalankan perintah berikut untuk menanyakan node tempat Deployment menerapkan pod:

kubectl get po -lapp=with-pod-topology-spread -ocustom-columns=NAME:.metadata.name,NODE:.spec.nodeName --no-headers | grep -v "<none>"

Jalankan perintah berikut untuk menanyakan jumlah pod yang dibuat oleh Deployment di setiap zona:

kubectl get po -lapp=with-pod-topology-spread -ocustom-columns=NODE:.spec.nodeName --no-headers | grep -v "<none>" | xargs -I {} kubectl get no {} -ojson | jq '.metadata.labels["topology.kubernetes.io/zone"]' | sort | uniq -c

Contoh 2: Konfigurasikan afinitas pod dan afinitas node untuk menerapkan pod di zona tertentu

Tambahkan afinitas ke konfigurasi beban kerja.

Dalam contoh ini, sebuah Deployment yang pod-nya diterapkan di satu zona dibuat. Blok kode berikut menunjukkan template YAML dari Deployment:

Tampilkan Konten YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-affinity
  labels:
    app: with-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: with-affinity
  template:
    metadata:
      labels:
        app: with-affinity
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - with-affinity
            topologyKey: topology.kubernetes.io/zone
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
      tolerations:
        - key: "virtual-kubelet.io/provider"
          operator: "Exists"
          effect: "NoSchedule"
      containers:
      - name: with-affinity
        image: registry.k8s.io/pause:2.0

Parameter

Deskripsi

podAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchExpressions:
      - key: app
        operator: In
        values:
        - with-affinity
		topologyKey: topology.kubernetes.io/zone

Konfigurasi menentukan bahwa semua pod diterapkan di satu zona.

Untuk informasi lebih lanjut tentang parameter, lihat Node affinity.

nodeAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 1
    preference:
      matchExpressions:
      - key: type
        operator: NotIn
        values:
        - virtual-kubelet

Konfigurasi menentukan bahwa pod diprioritaskan untuk dijadwalkan ke node ECS.

Untuk informasi lebih lanjut tentang parameter, lihat Node affinity.

tolerations:
  - key: "virtual-kubelet.io/provider"
    operator: "Exists"
    effect: "NoSchedule"

kube-scheduler mentolerir taint dari node virtual untuk menjadwalkan pod ke node virtual.

Untuk informasi lebih lanjut tentang parameter, lihat Taints and Tolerations.

Jika Anda ingin menerapkan pod di zona tertentu, hapus parameter podAffinity dan tambahkan batasan berikut ke parameter nodeAffinity: Konfigurasi berikut menentukan bahwa pod harus diterapkan di Zona A Beijing.

requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  - matchExpressions:
    - key: topology.kubernetes.io/zone
      operator: In
      values:
      - cn-beijing-a

Buat beban kerja.
Buat file bernama deployment.yaml dan salin template YAML sebelumnya ke file tersebut. Kemudian, jalankan perintah berikut untuk membuat Deployment di kluster:
```
kubectl apply -f deployment.yaml
```

Verifikasi hasil penjadwalan beban kerja.

Jalankan perintah berikut untuk menanyakan node tempat Deployment menerapkan pod:

kubectl get po -lapp=with-affinity -ocustom-columns=NAME:.metadata.name,NODE:.spec.nodeName --no-headers | grep -v "<none>"

Jalankan perintah berikut untuk menanyakan jumlah pod yang dibuat oleh Deployment di setiap zona:

kubectl get po -lapp=with-affinity -ocustom-columns=NODE:.spec.nodeName --no-headers | grep -v "<none>" | xargs -I {} kubectl get no {} -ojson | jq '.metadata.labels["topology.kubernetes.io/zone"]' | sort | uniq -c

Penyebaran topologi pod berbasis Elastic Container Instance yang ketat

Secara default, jika Anda memaksa sistem untuk menyebarkan pod berbasis Elastic Container Instance di seluruh zona, kube-scheduler akan mendistribusikan pod dari beban kerja secara merata di semua zona. Namun, pod berbasis Elastic Container Instance mungkin gagal dibuat di beberapa zona. Gambar berikut menunjukkan hasil penjadwalan saat parameter maxSkew diatur ke 1. Untuk informasi lebih lanjut tentang maxSkew, lihat maxSkew.

Jika pod berbasis Elastic Container Instance di Zona B dan Zona C gagal dibuat, dua pod berbasis Elastic Container Instance berjalan di Zona A, dan tidak ada pod berbasis Elastic Container Instance yang berjalan di Zona B atau Zona C. Ini melanggar batasan yang ditentukan oleh parameter maxSkew.

Anda dapat mengaktifkan penyebaran topologi pod berbasis Elastic Container Instance yang ketat untuk memastikan bahwa pod benar-benar tersebar di seluruh zona. Setelah Anda mengaktifkan penyebaran topologi pod berbasis Elastic Container Instance yang ketat, kube-scheduler pertama-tama menjadwalkan pod ke masing-masing Zona A, Zona B, dan Zona C. kube-scheduler tidak menjadwalkan pod yang tertunda hingga pod yang dijadwalkan dibuat, seperti yang ditunjukkan pada gambar berikut.

Meskipun Pod A1 telah dibuat, pod yang tertunda tidak dijadwalkan. Hal ini karena jika pod di Zona B atau Zona C gagal dibuat, batasan yang ditentukan oleh parameter maxSkew dilanggar. Setelah Pod B1 dibuat, kube-scheduler menjadwalkan pod ke Zona C. Pod dengan shading hijau telah dibuat.

Jika Anda ingin menonaktifkan penyebaran topologi pod berbasis Elastic Container Instance yang ketat, atur parameter whenUnsatisfiable menjadi ScheduleAnyway. Untuk informasi lebih lanjut, lihat Spread constraint definition.