All Products
Search

This Product

    Container Service for Kubernetes:Konfigurasikan penjadwalan berbasis prioritas untuk sumber daya elastis

    Document Center

    Container Service for Kubernetes:Konfigurasikan penjadwalan berbasis prioritas untuk sumber daya elastis

    Last Updated:Jun 24, 2026

    Penjadwalan prioritas sumber daya elastis kustom memungkinkan Anda menentukan urutan penjadwalan pod di berbagai jenis sumber daya dan kelompok node. Buat ResourcePolicy untuk mengatur urutan ini: saat skala keluar, pod dijadwalkan ke unit sumber daya sesuai urutan yang Anda tentukan; saat skala-masuk, pod dihapus dalam urutan terbalik.

    Peringatan

    Jangan gunakan label yang dicadangkan sistem seperti alibabacloud.com/compute-class atau alibabacloud.com/compute-qos dalam pemilih label workload (misalnya, bidang spec.selector.matchLabels pada Deployment). Sistem dapat mengubah label-label ini selama penjadwalan prioritas, menyebabkan rebuild pod secara sering dan memengaruhi stabilitas.

    Prasyarat

    Pastikan Anda telah:

    • Kluster ACK yang dikelola edisi Pro, versi 1.20.11 atau lebih baru (Tingkatkan kluster secara manual).

    • Versi kube-scheduler yang kompatibel dengan versi kluster ACK Anda (kube-scheduler).

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

    • (Diperlukan untuk sumber daya ECI) Komponen add-on ack-virtual-node telah dideploy di kluster Anda (Gunakan ECI di ACK).

    Catatan penggunaan

    • Pengurutan Best-effort: Fitur ini menggunakan kebijakan BestEffort. Penskalaan-masuk pod tidak selalu mengikuti urutan terbalik dari urutan penjadwalan dalam semua kasus.

    • Mulai dari scheduler v1.x.x-aliyun-6.4, nilai default ignorePreviousPod diubah menjadi false dan ignoreTerminatingPod menjadi true. Objek ResourcePolicy yang sudah ada dan pembaruan berikutnya tidak terpengaruh.

    • Fitur ini bertentangan dengan pod-deletion-cost dan tidak dapat digunakan bersamaan.

    • Fitur ini tidak dapat digunakan dengan penjadwalan elastis Elastic Container Instance (ECI) melalui ElasticResource (Gunakan ElasticResource untuk penjadwalan elastis pod ECI).

    • Bidang max hanya tersedia di kluster versi 1.22 atau lebih baru dengan versi scheduler 5.0 atau lebih baru.

    • Saat digunakan dengan kelompok node elastis, fitur ini dapat menyebabkan pembuatan node yang tidak valid. Untuk mencegah hal ini, masukkan kelompok node elastis ke dalam suatu unit dan jangan atur max untuk unit tersebut.

    • Jika versi scheduler Anda sebelum 5.0 atau versi kluster Anda 1.20 atau lebih lama, pod yang sudah ada sebelum ResourcePolicy dibuat akan menjadi yang pertama di-skala-masuk.

    • Jika versi scheduler Anda sebelum 6.1 atau versi kluster Anda 1.20 atau lebih lama, jangan ubah ResourcePolicy selama pod terkait belum sepenuhnya dihapus.

    • Saat digunakan dengan auto-scaling, fitur ini harus digunakan bersamaan dengan elastisitas instan. Jika tidak, Cluster Autoscaler dapat memicu penskalaan kelompok node yang salah.

    Buat ResourcePolicy

    Definisikan ResourcePolicy dengan struktur YAML berikut:

    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

    Bidang spec

    Bidang Deskripsi
    selector Memilih pod dengan label yang sesuai dalam namespace yang sama. Jika kosong, mencocokkan semua pod.
    strategy Strategi penjadwalan. Hanya prefer yang didukung.
    units Daftar terurut unit penjadwalan. Skala keluar mengikuti urutan daftar; skala-masuk membalikkannya.

    Bidang satuan

    Bidang Deskripsi
    resource Jenis sumber daya. Nilai yang valid: ecs, eci, elastic (kluster 1.24+ dengan scheduler 6.4.3+), acs (kluster 1.26+ dengan scheduler 6.7.1+).
    nodeSelector Memilih node dalam unit ini berdasarkan label.
    max Jumlah replika pod maksimum untuk unit ini. Tersedia di scheduler 5.0+.
    maxResources Sumber daya maksimum untuk pod dalam unit ini. Tersedia di scheduler 6.9.5+.
    podLabels Label yang ditambahkan ke pod yang dijadwalkan ke unit ini. Hanya pod dengan label ini yang dihitung untuk unit ini.
    podAnnotations Anotasi yang ditambahkan ke pod yang dijadwalkan ke unit ini. Hanya pod dengan anotasi ini yang dihitung untuk unit ini.
    Jenis sumber daya elastic sedang ditinggalkan. Gunakan kelompok node auto-scaling sebagai gantinya dengan mengatur k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" di podLabels.
    Jenis acs secara default menambahkan label alibabacloud.com/compute-class: default dan alibabacloud.com/compute-class: general-purpose ke pod. Timpa label ini dengan menentukan nilai berbeda di podLabels. Jika alpha.alibabacloud.com/compute-qos-strategy ditentukan di podAnnotations, label alibabacloud.com/compute-class: default tidak ditambahkan.
    Jenis acs dan eci secara default menambahkan toleransi untuk taint node virtual. Toleransi ini ditambahkan secara internal — tidak muncul di spesifikasi pod, dan pod dapat dijadwalkan ke node virtual tanpa konfigurasi toleransi tambahan.
    Penting

    Di versi scheduler sebelum 6.8.3, Anda tidak dapat menggunakan beberapa unit acs secara bersamaan.

    Jika podLabels suatu unit mencakup k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true", atau jika jumlah pod di bawah max, penjadwal menahan pod di unit saat ini hingga kondisi tertentu terpenuhi. Atur durasi tunggu di whenTryNextUnits. Label k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" tidak diterapkan ke pod dan tidak diperlukan untuk penghitungan pod.

    Bidang konfigurasi lanjutan

    Bidang Tersedia mulai dari Deskripsi
    preemptPolicy Scheduler v6.1 Mengontrol kapan preemption dilakukan antar unit. BeforeNextUnit: coba preemption setiap kali suatu unit gagal. AfterAllUnits (default): coba preemption hanya setelah semua unit gagal. Tidak berlaku untuk ACS (Aktifkan preemption).
    ignorePreviousPod Scheduler v6.1 Ketika true, pod yang dibuat sebelum ResourcePolicy dikecualikan dari penghitungan pod. Harus digunakan bersama max.
    ignoreTerminatingPod Scheduler v6.1 Ketika true, pod dalam status Terminating dikecualikan dari penghitungan pod. Harus digunakan bersama max.
    matchLabelKeys Scheduler v6.2 Mengelompokkan pod berdasarkan nilai label dan menerapkan max per kelompok. Pod yang tidak memiliki label yang dideklarasikan ditolak. Harus digunakan bersama max.
    whenTryNextUnits Kluster 1.24+, scheduler 6.4+ Menentukan kapan pod pindah ke unit berikutnya (kebijakan whenTryNextUnits).

    Kebijakan whenTryNextUnits

    Kebijakan Pindah ke unit berikutnya ketika... Paling cocok untuk
    LackResourceOrExceedMax (default) Unit saat ini kehabisan sumber daya, atau jumlah pod mencapai max Sebagian besar kasus penggunaan umum
    ExceedMax max dan maxResources tidak diatur, atau jumlah pod mencapai max, atau penambahan pod saat ini akan melebihi maxResources Memprioritaskan auto-scaling kelompok node daripada ECI
    TimeoutOrExceedMax (1) max diatur dan jumlah pod di bawah max, atau maxResources diatur dan penggunaan saat ini ditambah sumber daya pod saat ini di bawah maxResources; atau (2) max tidak diatur dan podLabels berisi k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" — dalam kedua kasus tersebut, jika unit tidak memiliki cukup sumber daya, pod menunggu hingga timeout sebelum pindah Skala keluar kelompok node dengan fallback ke ECI setelah timeout
    LackResourceAndNoTerminating Sumber daya tidak mencukupi (atau max tercapai) dan tidak ada pod dalam unit saat ini yang berstatus Terminating Pembaruan bergulir — mencegah pod baru melimpah ke unit berikutnya selama pod lama dihentikan

    timeout hanya berlaku ketika policy adalah TimeoutOrExceedMax. Default: 15 menit. Tidak didukung untuk unit ACS (hanya dibatasi oleh max).

    Penting

    Jika kelompok node auto-scaling tidak dapat membuat node dalam waktu lama, ExceedMax dapat menyebabkan pod tetap dalam status Pending tanpa batas. Saat ini, Cluster Autoscaler tidak menghormati batas max dalam ResourcePolicy, sehingga jumlah instans yang dibuat sebenarnya dapat melebihi max. Masalah ini akan diselesaikan dalam rilis mendatang.

    Penting

    Dengan TimeoutOrExceedMax, jika node dibuat selama periode timeout tetapi belum Ready, dan pod tidak mentoleransi taint NotReady, pod tetap dijadwalkan ke ECI.

    Contoh skenario

    Hasilnya bersifat best-effort — penghapusan saat skala-masuk mungkin tidak secara ketat membalikkan urutan penjadwalan.

    Memprioritaskan satu kelompok node daripada yang lain

    Tujuan: Deploy Deployment di dua kelompok node — Pool A terlebih dahulu, Pool B sebagai overflow. Saat skala-masuk, hapus pod dari Pool B terlebih dahulu.

    Dalam contoh ini, node cn-beijing.10.0.3.137 dan cn-beijing.10.0.3.138 termasuk dalam Pool A, dan cn-beijing.10.0.6.47 dan cn-beijing.10.0.6.46 termasuk dalam Pool B. Semua node memiliki 2 vCPU dan memori 4 GB.

    1. Buat ResourcePolicy yang mengatur urutan penjadwalan kelompok node. Ganti nilai nodepool-id dengan ID kelompok node aktual Anda dari halaman Node Management > Node Pools (Buat dan kelola kelompok node).

      apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx # Harus sesuai dengan label pod di Deployment di bawah
  strategy: prefer
  units:
  - resource: ecs
    nodeSelector:
      alibabacloud.com/nodepool-id: np7ec79f2235954e879de07b780058****
  - resource: ecs
    nodeSelector:
      alibabacloud.com/nodepool-id: npab2df797738644e3a7b7cbf532bb****

    2. Buat Deployment. Label pod app: nginx harus sesuai dengan selector di ResourcePolicy.

      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 # Harus sesuai dengan selector ResourcePolicy
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

    3. Terapkan Deployment dan verifikasi penempatan pod.

      1. Terapkan file YAML.

        kubectl apply -f nginx.yaml

        Output yang diharapkan:

        deployment.apps/nginx created

      2. Periksa node tempat pod dijadwalkan.

        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>

        Kedua pod berada di node Pool A, sesuai harapan.

    4. Skala keluar menjadi empat replika dan verifikasi overflow ke Pool B.

      1. Lakukan penskalaan Penyebaran.

        kubectl scale deployment nginx --replicas 4

      2. Periksa penempatan 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>

        Dua pod baru melimpah ke node Pool B, karena kapasitas Pool A telah penuh.

    5. Skala-masuk menjadi dua replika dan verifikasi bahwa pod Pool B dihapus terlebih dahulu.

      1. Lakukan skalasi pada Penyebaran.

        kubectl scale deployment nginx --replicas 2

      2. Periksa 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>

        Pod Pool B dihapus terlebih dahulu — kebalikan dari urutan penjadwalan.

    Gunakan ECS langganan terlebih dahulu, lalu ECS bayar sesuai penggunaan, kemudian fallback ke ECI

    Tujuan: Meminimalkan biaya dengan mengisi kapasitas ECS langganan terlebih dahulu, lalu ECS bayar sesuai penggunaan, dan terakhir ECI. Saat skala-masuk, hapus pod dalam urutan terbalik: ECI terlebih dahulu, lalu ECS bayar sesuai penggunaan, kemudian ECS langganan.

    Dalam contoh ini, semua node memiliki 2 vCPU dan memori 4 GB.

    1. Beri label node berdasarkan jenis penagihan. Jika Anda menggunakan kelompok node, konfigurasikan label di tingkat kelompok node.

      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

    2. Buat ResourcePolicy yang mengurutkan unit berdasarkan jenis penagihan.

      apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx # Harus sesuai dengan label pod di Deployment di bawah
  strategy: prefer
  units:
  - resource: ecs
    nodeSelector:
      paidtype: subscription
  - resource: ecs
    nodeSelector:
      paidtype: pay-as-you-go
  - resource: eci

    3. Buat Deployment dengan dua replika.

      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 # Harus sesuai dengan selector ResourcePolicy
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

    4. Terapkan dan verifikasi penempatan awal di node langganan.

      1. Terapkan file YAML.

        kubectl apply -f nginx.yaml

      2. Periksa penempatan 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          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>

        Kedua pod berada di node langganan.

    5. Skala keluar untuk memverifikasi overflow ke ECS bayar sesuai penggunaan lalu ke ECI.

      1. Skala menjadi empat replika dan periksa penempatan pod.

        kubectl scale deployment nginx --replicas 4
        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>

        Pod overflow dijadwalkan ke node bayar sesuai penggunaan.

      2. Skala menjadi enam replika dan periksa penempatan pod.

        kubectl scale deployment nginx --replicas 6
        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>

        Dengan semua kapasitas ECS habis, pod sisanya dijadwalkan ke ECI (node virtual-kubelet).

    6. Lakukan scale-in untuk memverifikasi bahwa penghapusan instance mengikuti urutan terbalik.

      1. Skala menjadi empat replika. Pod ECI dihapus terlebih dahulu.

        kubectl scale deployment nginx --replicas 4
        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>

        Pod ECI dihapus terlebih dahulu.

      2. Skala menjadi dua replika. Pod ECS bayar sesuai penggunaan dihapus berikutnya.

        kubectl scale deployment nginx --replicas 2
        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>

      3. Setelah penghentian selesai, hanya pod ECS langganan yang tersisa.

        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>

    Pemecahan masalah

    Pod terjebak dalam status Pending setelah menerapkan ResourcePolicy

    Penjadwal mungkin tidak mengaitkan ResourcePolicy dengan pod yang benar. Verifikasi bahwa selector benar-benar sesuai dengan label pod workload Anda. Jika selector menggunakan label yang dicadangkan sistem (seperti alibabacloud.com/compute-class), sistem dapat mengubahnya, sehingga mengganggu asosiasi.

    Juga pastikan versi kube-scheduler Anda memenuhi persyaratan minimum untuk versi kluster Anda (lihat Prasyarat).

    Skala-masuk tidak mengikuti urutan terbalik yang diharapkan

    Fitur ini bersifat best-effort. Penghapusan dalam urutan terbalik yang ketat tidak dijamin — misalnya, saat preemption aktif atau saat beberapa pod memenuhi syarat untuk dihapus secara bersamaan.

    Jika Anda memerlukan pengurutan yang lebih ketat, periksa pengaturan whenTryNextUnits.policy dan pertimbangkan LackResourceAndNoTerminating untuk skenario pembaruan bergulir.

    ResourcePolicy bertentangan dengan pod-deletion-cost

    Jika anotasi pod-deletion-cost dikonfigurasi pada pod dalam workload yang sama, kedua fitur ini bertentangan. Hapus anotasi pod-deletion-cost sebelum menerapkan ResourcePolicy.

    Kelompok node membuat node yang tidak diharapkan saat digunakan dengan kelompok node elastis

    Saat kelompok node auto-scaling berada dalam unit dengan max diatur, Cluster Autoscaler dapat membuat lebih banyak node daripada max karena tidak membaca batas max dari ResourcePolicy. Untuk menghindari hal ini, masukkan kelompok node elastis ke dalam suatu unit dan jangan atur max untuk unit tersebut.

    Langkah selanjutnya

    Referensi