How to customize Pod scheduling order - Container Service for Kubernetes

Özel elastik kaynak öncelikli zamanlama, pod'ların farklı kaynak türleri ve düğüm havuzları arasında hangi sırayla zamanlanacağını tanımlamanızı sağlar. Bu sırayı ayarlamak için bir ResourcePolicy oluşturun: Ölçek genişletme sırasında pod'lar tanımladığınız sırada kaynak birimlerine zamanlanır; ölçek daraltma sırasında ise pod'lar ters sırada kaldırılır.

Uyarı

İş yükü etiket seçicilerinde (örneğin, bir Deployment'un spec.selector.matchLabels alanı) alibabacloud.com/compute-class veya alibabacloud.com/compute-qos gibi sistem tarafından ayrılmış etiketleri kullanmayın. Sistem, öncelikli zamanlama sırasında bu etiketleri değiştirebilir; bu durum sık pod yeniden oluşturulmasına neden olarak kararlılığı etkileyebilir.

Ön koşullar

Aşağıdakilerin mevcut olduğundan emin olun:

Sürüm 1,20,11 veya üzeri bir ACK yönetilen küme Pro edition (Küme yükseltme).

ACK küme sürümünüzle uyumlu bir kube-scheduler sürümü (kube-scheduler).

ACK sürümü	Zamanlayıcı sürümü
1,20	v1.20.4-ack-7.0 veya üzeri
1,22	v1.22.15-ack-2.0 veya üzeri
1,24 veya üzeri	Tüm sürümler desteklenir

(ECI kaynakları için gereklidir) Kümenizde ack-virtual-node eklentisi dağıtılmıştır (ACK'de ECI kullanma).

Kullanım notları

En iyi çaba ilkesi: Bu özellik BestEffort ilkesini kullanır. Pod ölçek daraltma işlemleri her durumda zamanlama sırasının tam tersini takip etmeyebilir.
Zamanlayıcı v1.x.x-aliyun-6.4 sürümünden itibaren ignorePreviousPod varsayılan değeri false ve ignoreTerminatingPod değeri true olarak değişmiştir. Mevcut ResourcePolicy nesneleri ve sonraki güncellemeler bundan etkilenmez.
Bu özellik, pod-deletion-cost ile çakışır ve birlikte kullanılamaz.
Bu özellik, ElasticResource aracılığıyla Elastic Container Instance (ECI) elastik zamanlaması ile birlikte kullanılamaz (ECI pod'larının elastik zamanlaması için ElasticResource kullanma).
max alanı yalnızca sürüm 1,22 veya üzeri kümelerde ve zamanlayıcı sürümü 5,0 veya üzerindeyken kullanılabilir.
Elastik düğüm havuzlarıyla birlikte kullanıldığında, bu özellik düğüm havuzlarının geçersiz düğümler oluşturmasına neden olabilir. Bunu önlemek için elastik düğüm havuzunu bir birime dahil edin ve o birim için max ayarlamayın.
Zamanlayıcı sürümünüz 5,0'dan önceyse veya küme sürümünüz 1,20 veya önceki bir sürümse, ResourcePolicy oluşturulmadan önce var olan pod'lar ilk ölçek daraltılan pod'lardır.
Zamanlayıcı sürümünüz 6,1'den önceyse veya küme sürümünüz 1,20 veya önceki bir sürümse, ilişkili pod'lar tamamen silinmemişken bir ResourcePolicy'yi değiştirmeyin.
Otomatik ölçeklendirme ile birlikte kullanıldığında, bu özellik anında esneklik ile birlikte kullanılmalıdır. Aksi takdirde Cluster Autoscaler yanlış düğüm havuzu ölçeklendirmesini tetikleyebilir.

ResourcePolicy oluşturma

Bir ResourcePolicy'yi şu YAML yapısıyla tanımlayın:

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
  # Optional advanced configuration
  preemptPolicy: AfterAllUnits
  ignorePreviousPod: false
  ignoreTerminatingPod: true
  matchLabelKeys:
  - pod-template-hash
  whenTryNextUnits:
    policy: TimeoutOrExceedMax
    timeout: 1m

spec alanları

Alan	Açıklama
`selector`	Aynı ad alanında eşleşen etiketlere sahip pod'ları seçer. Boş bırakılırsa tüm pod'larla eşleşir.
`strategy`	Zamanlama stratejisi. Yalnızca `prefer` desteklenir.
`units`	Sıralı zamanlama birimleri listesi. Ölçek genişletme liste sırasını izler; ölçek daraltma bunu tersine çevirir.

units alanları

Alan	Açıklama
`resource`	Kaynak türü. Geçerli değerler: `ecs`, `eci`, `elastic` (zamanlayıcı 6.4.3+ ile 1.24+ kümeler), `acs` (zamanlayıcı 6.7.1+ ile 1.26+ kümeler).
`nodeSelector`	Bu birimdeki düğümleri etikete göre seçer.
`max`	Bu birim için maksimum pod çoğaltma sayısı. Zamanlayıcı 5,0+ sürümünde kullanılabilir.
`maxResources`	Bu birimdeki pod'lar için maksimum kaynaklar. Zamanlayıcı 6.9.5+ sürümünde kullanılabilir.
`podLabels`	Bu birime zamanlanan pod'lara eklenen etiketler. Yalnızca bu etiketlere sahip pod'lar bu birim için sayılır.
`podAnnotations`	Bu birime zamanlanan pod'lara eklenen açıklamalar. Yalnızca bu açıklamalara sahip pod'lar bu birim için sayılır.

elastic kaynak türü kullanım dışı bırakılmaktadır. Bunun yerine, otomatik ölçeklendirme düğüm havuzlarını kullanmak için podLabels içinde k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" ayarlayın.

acs türü, varsayılan olarak pod'lara alibabacloud.com/compute-class: default ve alibabacloud.com/compute-class: general-purpose etiketlerini ekler. Bunları geçersiz kılmak için podLabels içinde farklı değerler belirtin. Eğer podAnnotations içinde alpha.alibabacloud.com/compute-qos-strategy belirtilmişse, alibabacloud.com/compute-class: default etiketi eklenmez.

acs ve eci türleri, sanal düğüm taint'leri için toleransları varsayılan olarak ekler. Bu toleranslar dahili olarak eklenir; pod spesifikasyonunda görünmezler ve pod'lar ek tolerans yapılandırması olmadan sanal düğümlere zamanlanabilir.

Önemli

6.8.3'ten önceki zamanlayıcı sürümlerinde, birden fazla acs birimini aynı anda kullanamazsınız.

Bir birimin podLabels değeri k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" içeriyorsa veya pod sayısı max değerinin altındaysa, zamanlayıcı bir koşul karşılanana kadar pod'u geçerli birimde tutar. Bekleme süresini whenTryNextUnits içinde ayarlayın. k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" etiketi pod'a uygulanmaz ve pod sayımı için gerekli değildir.

Gelişmiş yapılandırma alanları

Alan	Şuradan itibaren kullanılabilir	Açıklama
`preemptPolicy`	Zamanlayıcı v6.1	Birimler arası öncelik almanın ne zaman deneneceğini kontrol eder. `BeforeNextUnit`: Bir birim başarısız olduğunda her seferinde öncelik alma dener. `AfterAllUnits` (varsayılan): Yalnızca tüm birimler başarısız olduktan sonra öncelik alma dener. ACS için geçerli değildir (Öncelik almayı etkinleştirme).
`ignorePreviousPod`	Zamanlayıcı v6.1	`true` olduğunda, ResourcePolicy oluşturulmadan önce oluşturulan pod'lar pod sayımından hariç tutulur. `max` ile birlikte kullanılmalıdır.
`ignoreTerminatingPod`	Zamanlayıcı v6.1	`true` olduğunda, Sonlandırılıyor (Terminating) durumundaki pod'lar pod sayımından hariç tutulur. `max` ile birlikte kullanılmalıdır.
`matchLabelKeys`	Zamanlayıcı v6.2	Pod'ları etiket değerlerine göre gruplandırır ve grup başına `max` uygular. Bildirilen bir etiketi eksik olan pod'lar reddedilir. `max` ile birlikte kullanılmalıdır.
`whenTryNextUnits`	Küme 1.24+, zamanlayıcı 6.4+	Bir pod'un bir sonraki birime ne zaman taşınacağını tanımlar (whenTryNextUnits ilkeleri).

whenTryNextUnits ilkeleri

İlke	Ne zaman bir sonraki birime taşınır...	En uygun olduğu durum
`LackResourceOrExceedMax` (varsayılan)	Geçerli birim kaynakları bittiğinde veya pod sayısı `max` değerine ulaştığında	Çoğu genel kullanım durumu
`ExceedMax`	`max` ve `maxResources` ayarlanmadığında, pod sayısı `max` değerine ulaştığında veya geçerli pod'un eklenmesi `maxResources` değerini aşacaksa	Düğüm havuzlarının otomatik ölçeklendirmesini ECI'ye göre önceliklendirme
`TimeoutOrExceedMax`	(1) `max` ayarlıysa ve pod sayısı `max` değerinin altındaysa veya `maxResources` ayarlıysa ve geçerli kullanım artı geçerli pod'un kaynakları `maxResources` değerinin altındaysa; veya (2) `max` ayarlı değilse ve `podLabels` değeri `k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true"` içeriyorsa — her iki durumda da, birimde yetersiz kaynak varsa pod, taşınmadan önce en fazla `timeout` süresi kadar bekler	Zaman aşımından sonra ECI yedeklemeli düğüm havuzu ölçek genişletme
`LackResourceAndNoTerminating`	Kaynaklar yetersizse (veya `max` değerine ulaşıldıysa) ve geçerli birimde Sonlandırılıyor (Terminating) durumunda hiç pod yoksa	Rolling güncellemeler — eski pod'lar sonlandırılırken yeni pod'ların bir sonraki birime taşmasını önler

timeout yalnızca policy değeri TimeoutOrExceedMax olduğunda geçerlidir. Varsayılan: 15 dakika. ACS birimleri için desteklenmez (yalnızca max ile sınırlıdır).

Önemli

Otomatik ölçeklendirme düğüm havuzu uzun süre düğüm oluşturamazsa, ExceedMax pod'ların süresiz olarak Beklemede (Pending) kalmasına neden olabilir. Cluster Autoscaler şu anda ResourcePolicy'deki max sınırını dikkate almaz, bu nedenle oluşturulan örneklerin gerçek sayısı max değerini aşabilir. Bu durum gelecekteki bir sürümde ele alınacaktır.

Önemli

TimeoutOrExceedMax ile, zaman aşımı süresi sırasında bir düğüm oluşturulursa ancak henüz Hazır (Ready) değilse ve pod NotReady taint'ini tolere etmiyorsa, pod yine de ECI'ye zamanlanır.

Senaryo örnekleri

Sonuçlar en iyi çaba esasına dayanır; ölçek daraltma sırasında kaldırma işlemi zamanlama sırasını tam olarak tersine çevirmeyebilir.

Bir düğüm havuzunu diğerine göre önceliklendirme

Amaç: Bir Deployment'u iki düğüm havuzuna yayma — önce Havuz A, taşma durumunda Havuz B. Ölçek daraltma sırasında pod'ları önce Havuz B'den kaldırma.

Bu örnekte, cn-beijing.10.0.3.137 ve cn-beijing.10.0.3.138 düğümleri Havuz A'ya, cn-beijing.10.0.6.47 ve cn-beijing.10.0.6.46 düğümleri ise Havuz B'ye aittir. Tüm düğümler 2 vCPU ve 4 GB belleğe sahiptir.

Düğüm havuzu zamanlama sırasını ayarlayan bir ResourcePolicy oluşturun. nodepool-id değerlerini Node Management > Node Pools sayfasındaki gerçek düğüm havuzu ID'lerinizle değiştirin (Düğüm havuzu oluşturma ve yönetme).

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx # Must match the pod label in the Deployment below
  strategy: prefer
  units:
  - resource: ecs
    nodeSelector:
      alibabacloud.com/nodepool-id: np7ec79f2235954e879de07b780058****
  - resource: ecs
    nodeSelector:
      alibabacloud.com/nodepool-id: npab2df797738644e3a7b7cbf532bb****

Bir Deployment oluşturun. Pod etiketi app: nginx ResourcePolicy'deki selector ile eşleşmelidir.

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 # Must match the ResourcePolicy selector
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

Deployment'ı uygulayın ve pod yerleşimini doğrulayın.

YAML dosyalarını uygulayın.

kubectl apply -f nginx.yaml

Beklenen çıktı:

deployment.apps/nginx created

Pod'ların hangi düğümlere zamanlandığını kontrol edin.

kubectl get pods -o wide

Beklenen çıktı:

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>

Beklendiği gibi, her iki pod da Havuz A düğümlerindedir.

Dört çoğaltmaya ölçeklendirin ve Havuz B'ye taşmayı doğrulayın.

Deployment'ı ölçeklendirin.

kubectl scale deployment nginx --replicas 4

Pod yerleşimini kontrol edin.

kubectl get pods -o wide

Beklenen çıktı:

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>

Havuz A kapasitesi dolduğu için iki yeni pod Havuz B düğümlerine taşmıştır.

İki çoğaltmaya ölçek daraltın ve Havuz B pod'larının önce kaldırıldığını doğrulayın.

Deployment'ı ölçeklendirin.

kubectl scale deployment nginx --replicas 2

Pod durumunu kontrol edin.

kubectl get pods -o wide

Beklenen çıktı:

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>

Havuz B pod'ları önce kaldırılır — bu, zamanlama sırasının tersidir.

Önce abonelik ECS, ardından kullandıkça öde ECS, son olarak ECI kullanma

Amaç: Maliyetleri minimize etmek için önce abonelik ECS kapasitesini doldurma, ardından kullandıkça öde ECS ve son olarak ECI kullanma. Ölçek daraltma sırasında pod'ları ters sırada kaldırma: önce ECI, ardından kullandıkça öde ECS, son olarak abonelik ECS.

Bu örnekte, tüm düğümler 2 vCPU ve 4 GB belleğe sahiptir.

Düğümleri faturalandırma türüne göre etiketleyin. Düğüm havuzları kullanıyorsanız, bunun yerine etiketleri düğüm havuzu düzeyinde yapılandırın.

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

Birimleri faturalandırma türüne göre sıralayan bir ResourcePolicy oluşturun.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx # Must match the pod label in the Deployment below
  strategy: prefer
  units:
  - resource: ecs
    nodeSelector:
      paidtype: subscription
  - resource: ecs
    nodeSelector:
      paidtype: pay-as-you-go
  - resource: eci

İki çoğaltmalı bir Deployment oluşturun.

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 # Must match the ResourcePolicy selector
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

Uygulayın ve abonelik düğümlerindeki ilk yerleşimi doğrulayın.

YAML dosyalarını uygulayın.
```
kubectl apply -f nginx.yaml
```

Pod yerleşimini kontrol edin.

kubectl get pods -o wide

Beklenen çıktı:

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>

Her iki pod da abonelik düğümlerindedir.

Kullandıkça öde ECS'ye ve ardından ECI'ye taşmayı doğrulamak için ölçeklendirin.

Dört çoğaltmaya ölçeklendirin ve pod yerleşimini kontrol edin.

kubectl scale deployment nginx --replicas 4

kubectl get pods -o wide

Beklenen çıktı:

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>

Taşan pod'lar kullandıkça öde düğümlerine zamanlanır.

Altı çoğaltmaya ölçeklendirin ve pod yerleşimini kontrol edin.

kubectl scale deployment nginx --replicas 6

kubectl get pods -o wide

Beklenen çıktı:

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>

Tüm ECS kapasitesi tükendiğinde, kalan pod'lar ECI'ye (sanal-kubelet düğümleri) zamanlanır.

Ters kaldırma sırasını doğrulamak için ölçek daraltın.

Dört çoğaltmaya ölçeklendirin. ECI pod'ları önce kaldırılır.

kubectl scale deployment nginx --replicas 4

kubectl get pods -o wide

Beklenen çıktı:

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>

ECI pod'ları önce kaldırılır.

İki çoğaltmaya ölçeklendirin. Kullandıkça öde ECS pod'ları ardından kaldırılır.

kubectl scale deployment nginx --replicas 2

kubectl get pods -o wide

Beklenen çıktı:

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>

Sonlandırma tamamlandıktan sonra yalnızca abonelik ECS pod'ları kalır.

kubectl get pods -o wide

Beklenen çıktı:

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>

Sorun giderme

Bir ResourcePolicy uygulandıktan sonra pod'lar Beklemede (Pending) takılı kalıyor

Zamanlayıcı, ResourcePolicy'yi doğru pod'larla ilişkilendirmeyebilir. selector değerinin iş yükünüzün pod etiketleriyle tam olarak eşleştiğini doğrulayın. Seçici, sistem tarafından ayrılmış bir etiket (alibabacloud.com/compute-class gibi) kullanıyorsa, sistem bunu değiştirebilir ve ilişkilendirme bozulabilir.

Ayrıca kube-scheduler sürümünüzün küme sürümünüz için minimum gereksinimi karşıladığını onaylayın (bkz. Ön koşullar).

Ölçek daraltma beklenen ters sırayı takip etmiyor

Bu özellik en iyi çaba esasına dayanır. Katı ters sıra kaldırma garantisi verilmez — örneğin, öncelik alma etkin olduğunda veya birden çok pod aynı anda kaldırılmaya uygun hale geldiğinde.

Daha katı bir sıralama gerekiyorsa, whenTryNextUnits.policy ayarını kontrol edin ve rolling güncelleme senaryoları için LackResourceAndNoTerminating seçeneğini değerlendirin.

ResourcePolicy, pod-deletion-cost ile çakışıyor

Aynı iş yükündeki pod'larda pod-deletion-cost açıklamaları yapılandırılmışsa, iki özellik çakışır. Bir ResourcePolicy uygulamadan önce pod-deletion-cost açıklamalarını kaldırın.

Elastik düğüm havuzlarıyla kullanıldığında düğüm havuzu beklenmedik düğümler oluşturuyor

Otomatik ölçeklendirme düğüm havuzu max ayarı olan bir birim içindeyken, Cluster Autoscaler ResourcePolicy'den max sınırını okumadığı için max değerinden daha fazla düğüm oluşturabilir. Bundan kaçınmak için elastik düğüm havuzunu bir birime dahil edin ve o birim için max ayarlamayın.

Sonraki adımlar

Yalnızca ECS veya ECI kullanmak ya da ECS yetersiz olduğunda ECI istemek için toleransları ve düğüm uygunluğunu yapılandırın (ECS ve ECI için kaynak tahsisi belirtme).
ACK yönetilen küme Pro edition'da, ECI pod'ları için bölge tabanlı ayrıştırma ve uygunluk zamanlamasını uygulama.

Container Service for Kubernetes:Configure priority-based scheduling for elastic resources

Ön koşullar

Kullanım notları

ResourcePolicy oluşturma

spec alanları

units alanları

Gelişmiş yapılandırma alanları

whenTryNextUnits ilkeleri

Senaryo örnekleri

Bir düğüm havuzunu diğerine göre önceliklendirme

Önce abonelik ECS, ardından kullandıkça öde ECS, son olarak ECI kullanma

Sorun giderme

Bir ResourcePolicy uygulandıktan sonra pod'lar Beklemede (Pending) takılı kalıyor

Ölçek daraltma beklenen ters sırayı takip etmiyor

ResourcePolicy, pod-deletion-cost ile çakışıyor

Elastik düğüm havuzlarıyla kullanıldığında düğüm havuzu beklenmedik düğümler oluşturuyor

Sonraki adımlar

Başvurular