Cara menyesuaikan urutan penjadwalan pod - Container Service for Kubernetes

Penjadwalan prioritas resource elastis kustom adalah kebijakan penjadwalan elastis yang disediakan oleh Alibaba Cloud. Selama penerapan aplikasi atau skala keluar, Anda dapat menentukan ResourcePolicy untuk mengatur urutan penjadwalan pod instans aplikasi ke berbagai jenis node resource. Selama skala-masuk, pod dihapus dalam urutan terbalik dari penjadwalannya.

Peringatan

Jangan gunakan label yang dicadangkan sistem, seperti alibabacloud.com/compute-class atau alibabacloud.com/compute-qos, dalam pemilih label workload, seperti bidang spec.selector.matchLabels pada Deployment. Label-label ini mungkin dimodifikasi oleh sistem selama penjadwalan prioritas kustom, yang menyebabkan controller sering membangun ulang pod dan memengaruhi stabilitas aplikasi.

Prasyarat

Kluster ACK managed cluster Pro edition versi 1.20.11 atau lebih baru telah dibuat. Untuk meningkatkan kluster, lihat Tingkatkan kluster secara manual.
Versi scheduler harus memenuhi persyaratan berikut untuk versi kluster ACK yang berbeda. Untuk informasi selengkapnya tentang fitur yang didukung setiap versi scheduler, lihat kube-scheduler.
Versi ACK
Versi Penjadwal
1.20
v1.20.4-ack-7.0 atau versi lebih baru
1.22
v1.22.15-ack-2.0 atau versi lebih baru
1.24 atau versi lebih baru
Semua versi didukung
Untuk menggunakan resource ECI, komponen ack-virtual-node harus diterapkan. Untuk informasi selengkapnya, lihat Gunakan ECI di ACK.

Perhatian

Mulai dari versi scheduler v1.x.x-aliyun-6.4, nilai default bidang ignorePreviousPod untuk prioritas resource elastis kustom diubah menjadi False, dan ignoreTerminatingPod diubah menjadi True. Objek ResourcePolicy yang sudah ada dan pembaruan selanjutnya tidak terpengaruh.
Fitur ini bertentangan dengan pod-deletion-cost dan tidak dapat digunakan secara bersamaan.
Fitur ini tidak dapat digunakan bersamaan dengan penjadwalan elastis ECI yang diimplementasikan melalui ElasticResource. Untuk informasi selengkapnya, lihat Gunakan ElasticResource untuk penjadwalan elastis pod ECI.
Fitur ini menggunakan kebijakan BestEffort dan tidak menjamin bahwa pod diskala-masukkan secara ketat dalam urutan terbalik.
Bidang max hanya tersedia di kluster versi 1.22 atau lebih baru dengan versi scheduler 5.0 atau lebih baru.
Saat digunakan bersama kelompok node elastis, fitur ini dapat menyebabkan kelompok node membuat node yang tidak valid. Untuk mencegah hal ini, sertakan kelompok node elastis dalam satu unit dan jangan atur bidang max untuk unit tersebut.
Jika versi scheduler Anda lebih awal dari 5.0 atau versi kluster Anda 1.20 atau lebih awal, perhatikan bahwa pod yang sudah ada sebelum pembuatan ResourcePolicy akan menjadi yang pertama diskala-masukkan.
Jika versi scheduler Anda lebih awal dari 6.1 atau versi kluster Anda 1.20 atau lebih awal, jangan ubah ResourcePolicy selama pod yang terkait belum sepenuhnya dihapus.

Penggunaan

Buat ResourcePolicy untuk menentukan prioritas resource elastis:

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: test
  namespace: default
spec:
  selector:
    key1: value1
  strategy: prefer
  units:
  - nodeSelector:
      unit: first
    podLabels:
      key1: value1
    podAnnotations:
      key1: value1
    resource: ecs
  - nodeSelector:
      unit: second
    max: 10
    resource: ecs
  - resource: eci
  # Konfigurasi Lanjutan Opsional
  preemptPolicy: AfterAllUnits
  ignorePreviousPod: false
  ignoreTerminatingPod: true
  matchLabelKeys:
  - pod-template-hash
  whenTryNextUnits:
    policy: TimeoutOrExceedMax
    timeout: 1m

selector: Menentukan bahwa ResourcePolicy berlaku untuk pod yang memiliki label key1=value1 dalam namespace yang sama. Jika selector kosong, kebijakan berlaku untuk semua pod dalam namespace tersebut.
strategy: Strategi penjadwalan. Saat ini, hanya prefer yang didukung.
units: Unit penjadwalan yang ditentukan pengguna. Selama skala keluar, pod dijadwalkan ke resource sesuai urutan yang ditentukan dalam units. Selama skala-masuk, pod dihapus dalam urutan terbalik.
- resource: Jenis resource elastis. Jenis yang didukung adalah eci, ecs, elastic, dan acs. Tipe elastic tersedia di kluster versi 1.24 atau lebih baru dengan versi scheduler 6.4.3 atau lebih baru. Tipe acs tersedia di kluster versi 1.26 atau lebih baru dengan versi scheduler 6.7.1 atau lebih baru.
  Catatan
  Tipe elastic sedang ditinggalkan. Anda dapat menggunakan kelompok node autoscaling dengan mengatur k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" dalam `podLabels`.
  Catatan
  Secara default, tipe acs menambahkan label alibabacloud.com/compute-class: default dan alibabacloud.com/compute-class: general-purpose ke pod. Anda dapat menimpa nilai default ini dengan menentukan nilai berbeda dalam `podLabels`. Namun, jika alpha.alibabacloud.com/compute-qos-strategy ditentukan dalam `podAnnotations`, label alibabacloud.com/compute-class: default tidak ditambahkan.
  Catatan
  Tipe acs dan eci secara default menambahkan toleransi terhadap taint node virtual ke pod. Scheduler menambahkan toleransi ini secara internal dan tidak tercermin dalam spesifikasi pod. Pod dapat dijadwalkan ke node virtual tanpa memerlukan konfigurasi toleransi taint tambahan.
  Penting
  Pada versi scheduler sebelum 6.8.3, Anda tidak dapat menggunakan beberapa unit tipe acs secara bersamaan.
- nodeSelector: Mengidentifikasi node dalam unit penjadwalan ini menggunakan label pada node.
- max (Tersedia di versi scheduler 5.0 atau lebih baru): Jumlah maksimum replika pod yang dapat dijadwalkan dalam unit ini.
- maxResources (Tersedia di versi scheduler 6.9.5 atau lebih baru): Jumlah maksimum resource yang dapat dijadwalkan untuk pod dalam unit ini.
- podAnnotations: Tipenya adalah map[string]string{}. Pasangan kunci-nilai yang dikonfigurasi dalam podAnnotations diperbarui ke pod oleh scheduler. Hanya pod dengan pasangan kunci-nilai ini yang dihitung saat menghitung jumlah pod dalam unit.
- podLabels: Tipenya adalah map[string]string{}. Pasangan kunci-nilai yang dikonfigurasi dalam podLabels diperbarui ke pod oleh scheduler. Hanya pod dengan pasangan kunci-nilai ini yang dihitung saat menghitung jumlah pod dalam unit.
  Catatan
  Jika `podLabels` suatu unit mencakup label k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true", atau jika jumlah pod dalam unit saat ini kurang dari nilai `max`, scheduler menjaga pod dalam keadaan menunggu di unit saat ini. Anda dapat mengatur waktu tunggu dalam whenTryNextUnits. Label k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" tidak diterapkan ke pod dan tidak diperlukan untuk penghitungan pod.
  Catatan
  Saat ResourcePolicy digunakan bersama autoscaling, harus digunakan dengan elastisitas instan. Jika tidak, cluster-autoscaler dapat memicu penskalaan kelompok node yang salah.
preemptPolicy: Menentukan kebijakan preemption ketika `ResourcePolicy` berisi beberapa unit. `BeforeNextUnit` menunjukkan bahwa scheduler mencoba preemption setiap kali gagal menjadwalkan suatu unit. `AfterAllUnits` menunjukkan bahwa scheduler hanya mencoba preemption setelah gagal menjadwalkan unit terakhir. Nilai default adalah `AfterAllUnits`. Parameter ini tersedia untuk scheduler v6.1 atau lebih baru dan tidak berlaku untuk ACS.
Anda dapat mengaktifkan preemption dengan mengonfigurasi parameter ACK Scheduler. Untuk informasi selengkapnya, lihat Aktifkan preemption.
ignorePreviousPod (Tersedia di versi scheduler 6.1 atau lebih baru): Harus digunakan bersama max dalam units. Jika nilainya true, pod yang dijadwalkan sebelum pembuatan ResourcePolicy diabaikan selama penghitungan pod.
ignoreTerminatingPod (Tersedia di versi scheduler 6.1 atau lebih baru): Harus digunakan bersama max dalam units. Jika nilainya true, pod dalam status Terminating diabaikan selama penghitungan pod.
matchLabelKeys (Tersedia di versi scheduler 6.2 atau lebih baru): Harus digunakan bersama max dalam units. Pod dikelompokkan berdasarkan nilai labelnya. Batas max diterapkan secara terpisah untuk setiap kelompok pod. Jika sebuah pod tidak memiliki label yang dideklarasikan dalam matchLabelKeys, pod tersebut ditolak oleh scheduler.
whenTryNextUnits (Tersedia di kluster versi 1.24 atau lebih baru dengan versi scheduler 6.4 atau lebih baru): Menjelaskan kondisi di mana pod diizinkan menggunakan resource dari unit berikutnya.
- policy: Kebijakan yang digunakan oleh pod. Nilai yang valid adalah ExceedMax, LackResourceAndNoTerminating, TimeoutOrExceedMax, dan LackResourceOrExceedMax (default).
  - ExceedMax: Mengizinkan pod menggunakan resource dari unit berikutnya jika bidang `max` dan `maxResources` tidak diatur untuk unit saat ini, atau jika jumlah pod dalam unit saat ini lebih besar dari atau sama dengan nilai `max`, atau jika resource yang digunakan dalam unit saat ini ditambah resource pod saat ini melebihi nilai `maxResources`. Kebijakan ini dapat digunakan bersama autoscaling dan ECI untuk memprioritaskan autoscaling kelompok node.
    Penting
    Perhatikan bahwa jika kelompok node autoscaling tidak dapat membuat node dalam waktu lama, kebijakan ini dapat menyebabkan pod tetap dalam status Pending.
    Saat ini, Cluster Autoscaler tidak mengetahui batas max dalam ResourcePolicy. Jumlah instans yang sebenarnya dibuat mungkin lebih besar dari nilai max. Masalah ini akan dioptimalkan di versi mendatang.
  - TimeoutOrExceedMax: Ketika salah satu kondisi berikut terpenuhi:
    - Bidang max unit saat ini diatur dan jumlah pod dalam unit kurang dari nilai max, atau bidang maxResources diatur dan resource yang dijadwalkan ditambah resource pod saat ini kurang dari nilai maxResources.
    - Bidang max untuk unit saat ini tidak diatur, dan podLabels unit saat ini berisi k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true".
    Jika unit saat ini tidak memiliki cukup resource untuk menjadwalkan pod, pod menunggu di unit saat ini selama durasi maksimum yang ditentukan oleh timeout. Kebijakan ini dapat digunakan bersama autoscaling dan ECI untuk memprioritaskan skala keluar kelompok node dan secara otomatis menggunakan ECI setelah timeout.
    Penting
    Perhatikan bahwa jika node dibuat selama periode timeout tetapi tidak dalam status Ready, dan pod tidak mentolerir taint NotReady, pod tetap dijadwalkan ke ECI.
  - LackResourceOrExceedMax: Mengizinkan pod menggunakan resource dari unit berikutnya jika jumlah pod dalam unit saat ini lebih besar dari atau sama dengan nilai `max`, atau jika unit saat ini kehabisan resource. Ini adalah kebijakan default dan cocok untuk sebagian besar kebutuhan dasar.
  - LackResourceAndNoTerminating: Mengizinkan pod menggunakan resource dari unit berikutnya jika unit saat ini kekurangan resource yang tersedia atau telah mencapai jumlah maksimum pod (`max`), dan tidak ada pod dalam unit saat ini yang berada dalam status `Terminating`. Kebijakan ini cocok untuk strategi rolling update karena mencegah pod baru dijadwalkan ke unit berikutnya selama pod dalam unit saat ini sedang terminating.
- timeout (Parameter ini tidak didukung untuk unit ACS, yang hanya dibatasi oleh `max`): Durasi timeout ketika `policy` diatur ke TimeoutOrExceedMax. Jika bidang ini kosong, nilai default adalah 15 menit.

Contoh skenario

Scenario 1: Schedule based on node pool priority

Anda perlu menerapkan Deployment. Kluster memiliki dua kelompok node: Kelompok Node A dan Kelompok Node B. Anda ingin menjadwalkan pod ke Kelompok Node A terlebih dahulu. Jika Kelompok Node A kekurangan resource, jadwalkan pod ke Kelompok Node B. Saat skala-masuk, Anda ingin menghapus pod dari Kelompok Node B terlebih dahulu, lalu dari Kelompok Node A. Dalam contoh ini, cn-beijing.10.0.3.137 dan cn-beijing.10.0.3.138 termasuk dalam Kelompok Node A. cn-beijing.10.0.6.47 dan cn-beijing.10.0.6.46 termasuk dalam Kelompok Node B. Semua node memiliki 2 vCPU dan memori 4 GB. Langkah-langkah berikut menjelaskan cara menjadwalkan berdasarkan prioritas kelompok node:

Gunakan konten YAML berikut untuk membuat ResourcePolicy guna menyesuaikan urutan penjadwalan kelompok node.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx # Ini harus dikaitkan dengan label pod yang akan Anda buat nanti.
  strategy: prefer
  units:
  - resource: ecs
    nodeSelector:
      alibabacloud.com/nodepool-id: np7ec79f2235954e879de07b780058****
  - resource: ecs
    nodeSelector:
      alibabacloud.com/nodepool-id: npab2df797738644e3a7b7cbf532bb****

Catatan

Anda dapat memperoleh ID kelompok node dari halaman Node Management > Node Pools kluster. Untuk informasi selengkapnya, lihat Buat dan kelola kelompok node.

Gunakan konten YAML berikut untuk membuat Deployment dengan dua pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx # Ini harus dikaitkan dengan selector ResourcePolicy yang dibuat pada langkah sebelumnya.
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

Buat aplikasi Nginx dan lihat hasil penerapannya.

Jalankan perintah berikut untuk membuat aplikasi Nginx.
```
kubectl apply -f nginx.yaml
```
Output yang diharapkan:
```
deployment.apps/nginx created
```

Jalankan perintah berikut untuk melihat hasil penerapannya.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-b****   1/1     Running   0          17s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
nginx-9cdf7bbf9-k****   1/1     Running   0          17s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>

Output menunjukkan bahwa dua pod pertama dijadwalkan ke node di Kelompok Node A.

Lakukan skala keluar pod.

Jalankan perintah berikut untuk melakukan skala keluar pod menjadi empat replika.

kubectl scale deployment nginx --replicas 4

Output yang diharapkan:

deployment.apps/nginx scaled

Jalankan perintah berikut untuk memeriksa status pod.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS    RESTARTS   AGE    IP               NODE                    NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-b****   1/1     Running   0          101s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
nginx-9cdf7bbf9-k****   1/1     Running   0          101s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>
nginx-9cdf7bbf9-m****   1/1     Running   0          18s    172.29.113.156   cn-beijing.10.0.6.47    <none>           <none>
nginx-9cdf7bbf9-x****   1/1     Running   0          18s    172.29.113.89    cn-beijing.10.0.6.46    <none>           <none>

Output menunjukkan bahwa ketika node di Kelompok Node A tidak memiliki sumber daya yang cukup, pod baru dijadwalkan ke node di Kelompok Node B.

Lakukan scale-in pada Pod.

Jalankan perintah berikut untuk melakukan skala-masuk pod dari empat replika menjadi dua.
```
kubectl scale deployment nginx --replicas 2
```
Output yang diharapkan:
```
deployment.apps/nginx scaled
```

Jalankan perintah berikut untuk memeriksa status pod.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-b****   1/1     Running       0          2m41s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
nginx-9cdf7bbf9-k****   1/1     Running       0          2m41s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>
nginx-9cdf7bbf9-m****   0/1     Terminating   0          78s     172.29.113.156   cn-beijing.10.0.6.47    <none>           <none>
nginx-9cdf7bbf9-x****   0/1     Terminating   0          78s     172.29.113.89    cn-beijing.10.0.6.46    <none>           <none>

Output menunjukkan bahwa pod di Kelompok Node B dihapus terlebih dahulu, yang merupakan kebalikan dari urutan penjadwalan.

Scenario 2: Hybrid scheduling of ECS and ECI

Anda perlu menerapkan Deployment. Kluster memiliki tiga jenis resource: instans ECS langganan, instans ECS bayar sesuai penggunaan, dan instans ECI. Untuk mengurangi biaya resource, Anda ingin penerapan layanan mengikuti urutan prioritas ini: ECS langganan, ECS bayar sesuai penggunaan, lalu ECI. Saat skala-masuk, Anda ingin menghapus pod dari instans ECI terlebih dahulu, lalu dari instans ECS bayar sesuai penggunaan, dan terakhir dari instans ECS langganan. Dalam contoh ini, node memiliki 2 vCPU dan memori 4 GB. Langkah-langkah berikut menjelaskan cara melakukan penjadwalan hibrid ECS dan ECI:

Jalankan perintah berikut untuk menambahkan label berbeda ke node dengan metode penagihan berbeda. Anda juga dapat menggunakan fitur kelompok node untuk secara otomatis menambahkan label.

kubectl label node cn-beijing.10.0.3.137 paidtype=subscription
kubectl label node cn-beijing.10.0.3.138 paidtype=subscription
kubectl label node cn-beijing.10.0.6.46 paidtype=pay-as-you-go
kubectl label node cn-beijing.10.0.6.47 paidtype=pay-as-you-go

Gunakan konten YAML berikut untuk membuat ResourcePolicy guna menyesuaikan urutan penjadwalan kelompok node.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx # Ini harus dikaitkan dengan label pod yang akan Anda buat nanti.
  strategy: prefer
  units:
  - resource: ecs
    nodeSelector:
      paidtype: subscription
  - resource: ecs
    nodeSelector:
      paidtype: pay-as-you-go
  - resource: eci

Gunakan konten YAML berikut untuk membuat Deployment dengan dua pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx # Ini harus dikaitkan dengan selector ResourcePolicy yang dibuat pada langkah sebelumnya.
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

Buat aplikasi Nginx dan lihat hasil penerapannya.

Jalankan perintah berikut untuk membuat aplikasi Nginx.
```
kubectl apply -f nginx.yaml
```
Output yang diharapkan:
```
deployment.apps/nginx created
```

Jalankan perintah berikut untuk melihat hasil penerapannya.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-b****   1/1     Running   0          66s   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
nginx-9cdf7bbf9-r****   1/1     Running   0          66s   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

Output menunjukkan bahwa dua pod pertama dijadwalkan ke node dengan label paidtype=subscription.

Lakukan skala keluar pod.

Jalankan perintah berikut untuk melakukan skala keluar pod menjadi empat replika.
```
kubectl scale deployment nginx --replicas 4
```
Output yang diharapkan:
```
deployment.apps/nginx scaled
```

Jalankan perintah berikut untuk memeriksa status pod.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS    RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-4****   1/1     Running   0          16s     172.29.113.155   cn-beijing.10.0.6.47    <none>           <none>
nginx-9cdf7bbf9-b****   1/1     Running   0          3m48s   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
nginx-9cdf7bbf9-f****   1/1     Running   0          16s     172.29.113.88    cn-beijing.10.0.6.46    <none>           <none>
nginx-9cdf7bbf9-r****   1/1     Running   0          3m48s   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

Output menunjukkan bahwa ketika node dengan label paidtype=subscription kekurangan resource, pod baru dijadwalkan ke node dengan label paidtype=pay-as-you-go.

Jalankan perintah berikut untuk melakukan skala keluar pod menjadi enam replika.
```
kubectl scale deployment nginx --replicas 6
```
Output yang diharapkan:
```
deployment.apps/nginx scaled
```

Jalankan perintah berikut untuk memeriksa status pod.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS    RESTARTS   AGE     IP               NODE                           NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-4****   1/1     Running   0          3m10s   172.29.113.155   cn-beijing.10.0.6.47           <none>           <none>
nginx-9cdf7bbf9-b****   1/1     Running   0          6m42s   172.29.112.215   cn-beijing.10.0.3.137          <none>           <none>
nginx-9cdf7bbf9-f****   1/1     Running   0          3m10s   172.29.113.88    cn-beijing.10.0.6.46           <none>           <none>
nginx-9cdf7bbf9-r****   1/1     Running   0          6m42s   172.29.113.23    cn-beijing.10.0.3.138          <none>           <none>
nginx-9cdf7bbf9-s****   1/1     Running   0          36s     10.0.6.68        virtual-kubelet-cn-beijing-j   <none>           <none>
nginx-9cdf7bbf9-v****   1/1     Running   0          36s     10.0.6.67        virtual-kubelet-cn-beijing-j   <none>           <none>

Output menunjukkan bahwa ketika sumber daya ECS tidak mencukupi, pod baru dijadwalkan ke sumber daya ECI.

Turunkan skala Pod.

Jalankan perintah berikut untuk melakukan skala-masuk pod dari enam replika menjadi empat.
```
kubectl scale deployment nginx --replicas 4
```
Output yang diharapkan:
```
deployment.apps/nginx scaled
```

Jalankan perintah berikut untuk memeriksa status pod.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                           NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-4****   1/1     Running       0          4m59s   172.29.113.155   cn-beijing.10.0.6.47           <none>           <none>
nginx-9cdf7bbf9-b****   1/1     Running       0          8m31s   172.29.112.215   cn-beijing.10.0.3.137          <none>           <none>
nginx-9cdf7bbf9-f****   1/1     Running       0          4m59s   172.29.113.88    cn-beijing.10.0.6.46           <none>           <none>
nginx-9cdf7bbf9-r****   1/1     Running       0          8m31s   172.29.113.23    cn-beijing.10.0.3.138          <none>           <none>
nginx-9cdf7bbf9-s****   1/1     Terminating   0          2m25s   10.0.6.68        virtual-kubelet-cn-beijing-j   <none>           <none>
nginx-9cdf7bbf9-v****   1/1     Terminating   0          2m25s   10.0.6.67        virtual-kubelet-cn-beijing-j   <none>           <none>

Output menunjukkan bahwa pod pada instans ECI dihapus terlebih dahulu, yang merupakan kebalikan dari urutan penjadwalan.

Jalankan perintah berikut untuk melakukan skala-masuk pod dari empat replika menjadi dua.
```
kubectl scale deployment nginx --replicas 2
```
Output yang diharapkan:
```
deployment.apps/nginx scaled
```

Jalankan perintah berikut untuk memeriksa status pod.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-4****   0/1     Terminating   0          6m43s   172.29.113.155   cn-beijing.10.0.6.47    <none>           <none>
nginx-9cdf7bbf9-b****   1/1     Running       0          10m     172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
nginx-9cdf7bbf9-f****   0/1     Terminating   0          6m43s   172.29.113.88    cn-beijing.10.0.6.46    <none>           <none>
nginx-9cdf7bbf9-r****   1/1     Running       0          10m     172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

Output menunjukkan bahwa pod pada node dengan label paidtype=pay-as-you-go dihapus berikutnya, yang merupakan kebalikan dari urutan penjadwalan.

Jalankan perintah berikut untuk memeriksa status pod.

kubectl get pods -o wide

Output yang diharapkan:

NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
nginx-9cdf7bbf9-b****   1/1     Running   0          11m   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
nginx-9cdf7bbf9-r****   1/1     Running   0          11m   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

Output menunjukkan bahwa hanya pod pada node dengan label paidtype=subscription yang tersisa.

Referensi

Saat menerapkan layanan di kluster ACK, Anda dapat menggunakan toleransi dan afinitas node untuk menyatakan bahwa hanya resource elastis ECS atau ECI yang digunakan, atau untuk secara otomatis meminta resource ECI ketika resource ECS tidak mencukupi. Dengan mengonfigurasi kebijakan penjadwalan, Anda dapat memenuhi berbagai kebutuhan resource elastis dalam berbagai skenario workload. Untuk informasi selengkapnya, lihat Tentukan alokasi resource untuk ECS dan ECI.
Ketersediaan tinggi (HA) dan kinerja tinggi adalah persyaratan penting untuk menjalankan tugas terdistribusi. Di ACK managed cluster Pro edition, Anda dapat menggunakan semantik penjadwalan Kubernetes native untuk mendiskretisasi tugas terdistribusi di berbagai zona guna memenuhi persyaratan penerapan HA. Anda juga dapat menggunakan semantik penjadwalan Kubernetes native untuk menerapkan penyebaran berbasis afinitas tugas terdistribusi di zona tertentu guna memenuhi persyaratan penerapan berkinerja-tinggi. Untuk informasi selengkapnya, lihat Implementasikan penjadwalan diskretisasi dan afinitas berbasis zona untuk pod ECI.

Versi ACK	Versi Penjadwal
1.20	v1.20.4-ack-7.0 atau versi lebih baru
1.22	v1.22.15-ack-2.0 atau versi lebih baru
1.24 atau versi lebih baru	Semua versi didukung