Jadwalkan pod berdasarkan prioritas menggunakan ResourcePolicy untuk mengoptimalkan penempatan ECI - ACK

Penjadwalan prioritas sumber daya elastis kustom memungkinkan Anda menentukan urutan penjadwalan pod di berbagai jenis resource dan kelompok node. Buat ResourcePolicy untuk mengatur urutan ini: saat skala keluar (scale-out), pod dijadwalkan ke unit resource sesuai urutan yang Anda tentukan; saat skala-masuk (scale-in), 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 kustom, menyebabkan controller sering membangun ulang pod dan memengaruhi stabilitas aplikasi.

Prasyarat

Sebelum memulai, pastikan Anda telah:

Kluster ACK yang dikelola edisi Pro versi 1.20.11 atau lebih baru. Untuk langkah peningkatan, lihat Tingkatkan kluster secara manual.
Versi kube-scheduler yang memenuhi persyaratan untuk versi kluster ACK Anda. Lihat kube-scheduler untuk daftar lengkap fitur yang didukung per versi.
Versi ACK Versi Scheduler
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 resource ECI) Komponen ack-virtual-node telah diterapkan di kluster Anda. Lihat Gunakan ECI di ACK.

Versi ACK	Versi Scheduler
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

Catatan penggunaan

Pengurutan Best-effort: Fitur ini menggunakan kebijakan BestEffort. Skala-masuk pod tidak selalu mengikuti urutan terbalik dari urutan penjadwalan dalam semua kasus.
Mulai dari versi scheduler v1.x.x-aliyun-6.4, nilai default ignorePreviousPod diubah menjadi false, dan ignoreTerminatingPod diubah 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) yang diimplementasikan melalui ElasticResource. Lihat 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 kelompok node membuat node yang tidak valid. Untuk mencegah hal ini, masukkan kelompok node elastis ke dalam suatu unit dan jangan atur bidang 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 saat pod terkait belum sepenuhnya dihapus.
Saat digunakan dengan auto-scaling, fitur ini harus digunakan dengan instant elasticity. Jika tidak, Cluster Autoscaler dapat memicu penskalaan kelompok node yang salah.

Buat ResourcePolicy

Tentukan 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 yang memiliki label yang sesuai dalam namespace yang sama. Jika kosong, berlaku untuk semua pod di namespace tersebut.
`strategy`	Strategi penjadwalan. Hanya `prefer` yang didukung.
`units`	Daftar terurut unit penjadwalan. Pod dijadwalkan sesuai urutan daftar saat skala keluar dan dihapus dalam urutan terbalik saat skala-masuk.

Bidang units

Bidang	Deskripsi
`resource`	Jenis resource untuk unit ini. Nilai yang didukung: `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 mereka.
`max`	Jumlah maksimum replika pod yang dapat dijadwalkan ke unit ini. Tersedia di versi scheduler 5.0 atau lebih baru.
`maxResources`	Jumlah maksimum resource yang dapat dijadwalkan ke pod dalam unit ini. Tersedia di versi scheduler 6.9.5 atau lebih baru.
`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 resource elastic sedang ditinggalkan. Sebagai gantinya, gunakan kelompok node auto-scaling 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 terhadap taint node virtual ke pod. Scheduler menambahkan toleransi ini secara internal — tidak muncul di spesifikasi pod, sehingga pod dapat dijadwalkan ke node virtual tanpa konfigurasi toleransi taint tambahan.

Penting

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

Jika podLabels suatu unit mencakup k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true", atau jika jumlah pod dalam unit tersebut kurang dari nilai max, scheduler menahan pod di unit saat ini hingga kondisi tertentu terpenuhi. Atur durasi tunggu maksimum 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. Lihat Aktifkan preemption.
`ignorePreviousPod`	Scheduler v6.1	Saat `true`, pod yang dibuat sebelum ResourcePolicy dikecualikan dari penghitungan pod. Harus digunakan dengan `max`.
`ignoreTerminatingPod`	Scheduler v6.1	Saat `true`, pod dalam status Terminating dikecualikan dari penghitungan pod. Harus digunakan dengan `max`.
`matchLabelKeys`	Scheduler v6.2	Mengelompokkan pod berdasarkan nilai label dan menerapkan `max` per kelompok. Pod yang tidak memiliki label yang dideklarasikan ditolak oleh scheduler. Harus digunakan dengan `max`.
`whenTryNextUnits`	Kluster 1.24+, scheduler 6.4+	Menentukan kapan pod diperbolehkan pindah ke unit berikutnya. Lihat kebijakan whenTryNextUnits di bawah.

Kebijakan whenTryNextUnits

Kebijakan	Pindah ke unit berikutnya saat...	Paling cocok untuk
`LackResourceOrExceedMax` (default)	Unit saat ini kehabisan resource, atau jumlah pod mencapai `max`	Kasus penggunaan paling umum
`ExceedMax`	`max` dan `maxResources` tidak diatur, atau jumlah pod mencapai `max`, atau resource yang digunakan di unit saat ini ditambah resource pod saat ini 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 resource 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 resource, pod menunggu hingga `timeout` sebelum pindah	Skala keluar kelompok node dengan fallback ke ECI setelah timeout
`LackResourceAndNoTerminating`	Resource tidak mencukupi (atau `max` tercapai) dan tidak ada pod di unit saat ini yang berstatus Terminating	Pembaruan rolling — mencegah pod baru melimpah ke unit berikutnya selama pod lama dihentikan

Bidang timeout hanya berlaku saat policy adalah TimeoutOrExceedMax. Nilai default-nya adalah 15 menit. Tidak didukung untuk unit ACS (yang 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 diatasi dalam rilis mendatang.

Penting

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

Contoh skenario

Skenario-skenario ini menghasilkan hasil best-effort. Urutan penghapusan pod saat skala-masuk mungkin tidak selalu mengikuti urutan terbalik dari penjadwalan dalam semua kondisi.

Memprioritaskan satu kelompok node daripada yang lain

Tujuan: Terapkan 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 serta cn-beijing.10.0.6.46 termasuk dalam Pool B. Semua node memiliki 2 vCPU dan memori 4 GB.

Buat ResourcePolicy yang mengatur urutan penjadwalan kelompok node. Ganti nilai nodepool-id dengan ID kelompok node aktual Anda, yang dapat ditemukan di halaman Node Management > Node Pools. Lihat 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****

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

Terapkan Deployment dan verifikasi penempatan pod.

Terapkan file YAML.

kubectl apply -f nginx.yaml

Output yang diharapkan:

deployment.apps/nginx created

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.

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

Skalakan Penyebaran.

kubectl scale deployment nginx --replicas 4

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.

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

Lakukan skalasi Penyebaran.

kubectl scale deployment nginx --replicas 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, yang merupakan 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 akhirnya 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.

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

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

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

Terapkan dan verifikasi penempatan awal di node langganan.

Terapkan file YAML.
```
kubectl apply -f nginx.yaml
```

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.

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

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.

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>

Saat semua kapasitas ECS habis, pod yang tersisa dijadwalkan ke ECI (node virtual-kubelet).

Skala-masuk untuk memverifikasi urutan penghapusan terbalik.

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 adalah yang pertama dihapus.

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>

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

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

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. Scheduler tidak menjamin penghapusan dalam urutan terbalik yang ketat dalam semua kasus — 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 rolling.

ResourcePolicy bertentangan dengan pod-deletion-cost

Jika Anda telah mengonfigurasi anotasi pod-deletion-cost pada pod di workload yang sama, kedua fitur ini bertentangan dan tidak dapat digunakan bersamaan. Hapus anotasi pod-deletion-cost sebelum menerapkan ResourcePolicy.

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

Saat kelompok node auto-scaling dimasukkan dalam suatu unit dengan bidang max diatur, Cluster Autoscaler dapat membuat lebih banyak node daripada nilai max, karena saat ini 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 berikutnya

Untuk menyatakan bahwa hanya resource ECS atau ECI yang digunakan, atau untuk secara otomatis meminta ECI saat ECS tidak mencukupi, konfigurasikan toleransi dan afinitas node. Lihat Tentukan alokasi sumber daya untuk ECS dan ECI.
Untuk diskretisasi berbasis zona dan penjadwalan afinitas pod ECI di edisi Pro kluster ACK yang dikelola, lihat Implementasikan diskretisasi berbasis zona dan penjadwalan afinitas untuk pod ECI.

Container Service for Kubernetes:Penjadwalan sumber daya elastis berbasis prioritas kustom

Prasyarat

Catatan penggunaan

Buat ResourcePolicy

Bidang spec

Bidang units

Bidang konfigurasi lanjutan

Kebijakan whenTryNextUnits

Contoh skenario

Memprioritaskan satu kelompok node daripada yang lain

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

Pemecahan masalah

Pod terjebak dalam status Pending setelah menerapkan ResourcePolicy

Skala-masuk tidak mengikuti urutan terbalik yang diharapkan

ResourcePolicy bertentangan dengan pod-deletion-cost

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

Langkah berikutnya

Referensi