Cara menyebarkan pod berbasis Elastic Container Instance di seluruh zona dan mengonfigurasi afinitas - Elastic Container Instance

Ketersediaan tinggi dan performa tinggi sangat penting untuk pekerjaan terdistribusi. Di dalam kluster Container Service for Kubernetes (ACK) Pro atau ACK Serverless Pro, Anda dapat menyebarkan tugas terdistribusi di seluruh zona menggunakan semantik penjadwalan asli Kubernetes. Anda juga dapat mengonfigurasi afinitas untuk menerapkan tugas terdistribusi pada zona tertentu. Ini meningkatkan efisiensi penerapan tugas. Topik ini menjelaskan cara menyebarkan pod berbasis Elastic Container Instance di seluruh zona dan mengonfigurasi afinitas.

Informasi latar belakang

Dalam skenario tertentu, Anda mungkin perlu menyebarkan pod di beberapa zona atau ke zona tertentu untuk mencapai ketersediaan tinggi atau performa tinggi. Dalam kasus seperti itu, Anda dapat menggunakan fitur penjadwalan asli Kubernetes, seperti kendala penyebaran topologi pod (topologySpreadConstraints), afinitas node (nodeAffinity), dan afinitas pod (podAffinity).

Penting

Pod berbasis Elastic Container Instance hanya dapat disebarkan di seluruh zona atau dikonfigurasi afinitasnya ketika parameter nodeAffinity, podAffinity, topologySpreadConstraints dikonfigurasi untuk pod, atau ketika pod sesuai dengan kebijakan sumber daya yang ada.

Untuk informasi lebih lanjut, lihat dokumentasi resmi Kubernetes berikut:

Prasyarat

Kluster ACK Pro atau kluster ACK Serverless Pro telah dibuat dan memenuhi persyaratan berikut:
- Versi Kubernetes kluster adalah 1.22 atau lebih baru.
- Versi komponen ACK Virtual Node di dalam kluster adalah 2.10.0 atau lebih baru.
- Versi komponen kube-scheduler di dalam kluster adalah 5.9 atau lebih baru, dan fitur penjadwalan pod berbasis node virtual telah diaktifkan. Untuk informasi lebih lanjut, lihat Aktifkan kebijakan penjadwalan pod berbasis node virtual untuk kluster ACK.
Beberapa zona (vSwitches) ditentukan dalam eci-profile. Pod dapat dijadwalkan ke beberapa zona. Untuk informasi lebih lanjut, lihat Konfigurasikan beberapa zona untuk membuat pod.

Catatan penggunaan

Anda harus menyetel 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 menetapkan kebijakan penanganan kesalahan pod menjadi fail-fast.

Contoh konfigurasi

Pada bagian berikut, sebuah kluster ACK Serverless Pro dengan versi Kubernetes 1.22 digunakan untuk menjelaskan cara menyebarkan pod di seluruh zona dan mengonfigurasi afinitas.

Contoh 1: Gunakan topologySpreadConstraints untuk menyebarkan pod di seluruh zona

Catatan

Contoh berikut menunjukkan cara mengonfigurasi kendala penyebaran topologi. Secara default, Scheduler menjadwalkan semua pod secara merata ke semua zona, tetapi tidak mempertimbangkan hasil produksi pod. Untuk informasi lebih lanjut, lihat Penyebaran topologi pod berbasis Elastic Container Instance yang ketat.

Tambahkan kendala penyebaran topologi ke konfigurasi beban kerja.

Lakukan langkah-langkah berikut untuk menentukan kendala penyebaran topologi dalam parameter Spec dalam konfigurasi pod atau dalam 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 seterusnya.
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # Parameter ini opsional dan berada dalam fase Beta di Kubernetes 1.27 dan seterusnya.
      nodeAffinityPolicy: [Honor|Ignore] # Parameter ini opsional dan berada dalam fase Beta di Kubernetes 1.26 dan seterusnya.
      nodeTaintsPolicy: [Honor|Ignore] # Parameter ini opsional dan berada dalam fase Beta di Kubernetes 1.26 dan seterusnya.

Dalam contoh ini, sebuah Deployment yang pod-nya didistribusikan secara merata ke beberapa zona dibuat. Untuk informasi lebih lanjut tentang parameter, lihat bidang topologySpreadConstraints. 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:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: with-pod-topology-spread
      containers:
      - name: with-pod-topology-spread
        image: registry.k8s.io/pause:2.0
        resources:
          requests:
            cpu: "1"
            memory: "256Mi"

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

Verifikasi hasil penjadwalan beban kerja.

Jalankan perintah berikut untuk menanyakan node tempat Deployment menyebarkan 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: Gunakan nodeAffinity dan podAffinity untuk menyebarkan pod ke zona tertentu

Tambahkan afinitas ke konfigurasi beban kerja.

Dalam contoh ini, sebuah Deployment yang pod-nya diterapkan di satu zona dibuat. Untuk informasi lebih lanjut tentang parameter, lihat Node affinity. 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
      containers:
      - name: with-affinity
        image: registry.k8s.io/pause:2.0

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

Blok kode berikut menunjukkan contoh kode yang berisi parameter nodeAffinity. Pod hanya diterapkan di Zona A Beijing.

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:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - cn-beijing-a
      containers:
      - name: with-affinity
        image: registry.k8s.io/pause:2.0

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

Verifikasi hasil penjadwalan beban kerja.

Jalankan perintah berikut untuk menanyakan node tempat Deployment menyebarkan 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 menerapkan 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 ketika parameter maxSkew disetel 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 kendala yang ditentukan oleh parameter maxSkew.

Di dalam kluster ACK Serverless Pro, 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 sampai pod yang dijadwalkan dibuat, seperti yang ditunjukkan pada gambar berikut.

Meskipun Pod A1 telah dibuat, pod yang tertunda tidak dijadwalkan. Ini karena jika pod di Zona B atau Zona C gagal dibuat, kendala 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 Definisi kendala penyebaran.