All Products
Search

This Product

    Container Service for Kubernetes:FAQ penskalaan workload

    Document Center

    Container Service for Kubernetes:FAQ penskalaan workload

    Last Updated:Aug 21, 2026

    Topik ini menjelaskan masalah umum dan solusi yang mungkin Anda temui saat menggunakan fitur penskalaan workload, termasuk Horizontal Pod Autoscaler (HPA), CronHPA, dan Vertical Pod Autoscaler (VPA).

    Dalam topik ini

    Mengapa field current pada metrik HPA menampilkan unknown?

    Jika field current pada data pemantauan HPA bernilai unknown, penskalaan HPA gagal karena kube-controller-manager tidak dapat mengakses sumber data pemantauan untuk mengambil metrik yang sesuai.

    Name:                                                  kubernetes-tutorial-deployment
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           <none>
CreationTimestamp:                                     Mon, 10 Jun 2019 11:46:48  0530
Reference:                                             Deployment/kubernetes-tutorial-deployment
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  <unknown> / 2%
Min replicas:                                          1
Max replicas:                                          4
Deployment pods:                                       1 current / 0 desired
Conditions:
  Type           Status  Reason                   Message
  ----           ------  ------                   -------
  AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
  ScalingActive  False   FailedGetResourceMetric  the HPA was unable to compute the replica count: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server is currently unable to handle the request (get pods.metrics.k8s.io)
Events:
  Type     Reason                   Age                      From                       Message
  ----     ------                   ----                     ----                       -------
  Warning  FailedGetResourceMetric  3m3s (x1009 over 4h18m)  horizontal-pod-autoscaler  unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server is currently unable to handle the request (get pods.metrics.k8s.io)

    Penyebab 1: Sumber data metrik resource tidak tersedia

    Pertama, jalankan perintah kubectl top pod untuk memeriksa apakah data dikembalikan. Jika tidak ada data yang dikembalikan untuk semua Pod, jalankan kubectl get apiservice untuk memeriksa status sumber data yang menyediakan Resource Metrics. Contoh output sebagai berikut.

    Tampilkan contoh output

    NAME                                   SERVICE                      AVAILABLE   AGE
v1.                                    Local                        True        29h
v1.admissionregistration.k8s.io        Local                        True        29h
v1.apiextensions.k8s.io                Local                        True        29h
v1.apps                                Local                        True        29h
v1.authentication.k8s.io               Local                        True        29h
v1.authorization.k8s.io                Local                        True        29h
v1.autoscaling                         Local                        True        29h
v1.batch                               Local                        True        29h
v1.coordination.k8s.io                 Local                        True        29h
v1.monitoring.coreos.com               Local                        True        29h
v1.networking.k8s.io                   Local                        True        29h
v1.rbac.authorization.k8s.io           Local                        True        29h
v1.scheduling.k8s.io                   Local                        True        29h
v1.storage.k8s.io                      Local                        True        29h
v1alpha1.argoproj.io                   Local                        True        29h
v1alpha1.fedlearner.k8s.io             Local                        True        5h11m
v1beta1.admissionregistration.k8s.io   Local                        True        29h
v1beta1.alicloud.com                   Local                        True        29h
v1beta1.apiextensions.k8s.io           Local                        True        29h
v1beta1.apps                           Local                        True        29h
v1beta1.authentication.k8s.io          Local                        True        29h
v1beta1.authorization.k8s.io           Local                        True        29h
v1beta1.batch                          Local                        True        29h
v1beta1.certificates.k8s.io            Local                        True        29h
v1beta1.coordination.k8s.io            Local                        True        29h
v1beta1.events.k8s.io                  Local                        True        29h
v1beta1.extensions                     Local                        True        29h
...
[v1beta1.metrics.k8s.io                 kube-system/metrics-server   True        29h]
...
v1beta1.networking.k8s.io              Local                        True        29h
v1beta1.node.k8s.io                    Local                        True        29h
v1beta1.policy                         Local                        True        29h
v1beta1.rbac.authorization.k8s.io      Local                        True        29h
v1beta1.scheduling.k8s.io              Local                        True        29h
v1beta1.storage.k8s.io                 Local                        True        29h
v1beta2.apps                           Local                        True        29h
v2beta1.autoscaling                    Local                        True        29h
v2beta2.autoscaling                    Local                        True        29h

    Jika API Service untuk v1beta1.metrics.k8s.io bukan kube-system/metrics-server, periksa apakah layanan tersebut ditimpa oleh instalasi Prometheus Operator. Jika iya, Anda dapat memulihkan layanan tersebut dengan menerapkan templat YAML berikut.

    apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100

    Jika masalah tidak disebabkan oleh hal tersebut, buka halaman Operations > Add-ons untuk kluster Anda dan pastikan komponen metrics-server telah diinstal. Untuk informasi lebih lanjut, lihat metrics-server.

    Penyebab 2: Data tidak dapat diambil selama rolling update atau scale-out

    Secara default, interval pengumpulan metrics-server adalah 1 menit. Setelah scale-out atau pembaruan, metrics-server tidak dapat mengambil metrik untuk periode singkat. Periksa metrik sekitar 2 menit setelah penskalaan atau pembaruan selesai.

    Penyebab 3: Field request tidak dikonfigurasi

    Secara default, HPA menggunakan actual usage/request sebagai nilai utilisasi. Oleh karena itu, pastikan field resource pada Pod berisi field request.

    Penyebab 4: Nama metrik salah

    Verifikasi bahwa nama metrik benar, termasuk penulisannya (case-sensitive). Misalnya, jika Anda salah mengetik metrik cpu yang didukung oleh HPA menjadi CPU, field current pada data pemantauan akan menampilkan unknown.

    Apa yang harus saya lakukan jika penskalaan HPA gagal karena kesalahan pengumpulan metrik?

    Penskalaan HPA dapat gagal jika terjadi masalah dalam pengambilan metrik. Dalam kasus ini, field current pada data pemantauan HPA akan menampilkan unknown. Hal ini mencegah HPA mendapatkan metrik yang diperlukan untuk membuat keputusan penskalaan, sehingga tidak dapat menyesuaikan jumlah Pod. Lihat FAQ Autoscaling Node untuk memecahkan masalah dan menemukan solusi.

    Mengapa HPA membuat Pod tambahan selama rolling update?

    Selama rolling update, controller manager komunitas mengisi nilai nol untuk Pod yang tidak memiliki data metrik. Hal ini kadang-kadang menyebabkan HPA membuat lebih banyak Pod daripada yang diperlukan. Untuk mencegah perilaku ini, gunakan salah satu konfigurasi berikut.

    Konfigurasi tingkat kluster

    Upgrade metrics-server ACK ke versi terbaru dan tambahkan parameter startup berikut.

    Ini adalah pengaturan global yang memengaruhi semua workload terkait dalam kluster.

    # Tambahkan opsi berikut ke parameter startup metrics-server.
--enable-hpa-rolling-update-skipped=true

    Konfigurasi tingkat workload

    Untuk mencegah perilaku ini pada workload tertentu, gunakan salah satu metode berikut.

    • Metode 1: Tambahkan anotasi berikut ke templat workload target. Ini akan menangguhkan evaluasi HPA sementara selama rolling update.

      # Tambahkan anotasi ini ke spec.template.metadata.annotations untuk menangguhkan sementara evaluasi HPA selama rolling update.
HPARollingUpdateSkipped: "true"

      Tampilkan contoh kode

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-basic
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template: 
    metadata:
      labels:
        app: nginx
      annotations:
        HPARollingUpdateSkipped: "true"  # Melewatkan evaluasi HPA selama rolling update.
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

    • Metode 2: Tambahkan anotasi berikut ke templat workload target. Ini memberi tahu HPA untuk mengabaikan Pod selama periode pemanasan (warm-up) tertentu setelah Pod dimulai.

      # Tambahkan anotasi ini ke spec.template.metadata.annotations untuk melewatkan evaluasi HPA selama periode pemanasan tertentu.
HPAScaleUpDelay: 3m # Nilai 3m hanya contoh. Atur durasi sesuai kebutuhan Anda.

      Tampilkan contoh kode

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-basic
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template: 
    metadata:
      labels:
        app: nginx
      annotations:
        HPAScaleUpDelay: 3m  # 'm' berarti menit. Artinya HPA akan mulai mengevaluasi Pod 3 menit setelah dibuat. Satuan yang didukung adalah s (detik) dan m (menit).
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

    Mengapa HPA tidak melakukan penskalaan meskipun ambang batas telah tercapai?

    HPA memicu penskalaan berdasarkan lebih dari sekadar apakah penggunaan CPU atau memori berada di atas atau di bawah ambang batas. HPA juga mempertimbangkan apakah tindakan scale-out atau scale-in mungkin langsung memicu tindakan sebaliknya, yang membantu mencegah fluktuasi cepat, juga dikenal sebagai thrashing.

    Sebagai contoh, asumsikan ambang batas scale-out Anda diatur ke 80% dan Anda memiliki dua Pod, masing-masing dengan penggunaan CPU 70%. Dalam kasus ini, HPA tidak akan melakukan scale-in. Jika dilakukan, penggunaan CPU Pod yang tersisa kemungkinan besar akan melebihi 80%, langsung memicu scale-out dan menyebabkan thrashing.

    Bagaimana cara mengonfigurasi interval pengumpulan metrik HPA?

    Untuk versi metrics-server yang lebih baru dari v0.2.1-b46d98c-aliyun, atur parameter startup --metric-resolution, seperti --metric-resolution=15s.

    Apakah CronHPA kompatibel dengan HPA?

    Ya, CronHPA kompatibel dengan HPA. Di Container Service for Kubernetes (ACK), CronHPA mengatur scaleTargetRef-nya ke objek HPA. Kemudian, CronHPA menggunakan objek HPA tersebut untuk menemukan scaleTargetRef aktual. Hal ini memungkinkan CronHPA mengetahui status terkini HPA. CronHPA tidak secara langsung menyesuaikan jumlah replika Deployment. Sebaliknya, CronHPA beroperasi melalui HPA, yang mencegah konflik antara kedua pengontrol tersebut. Untuk informasi lebih lanjut, lihat Koordinasikan CronHPA dan HPA.

    Bagaimana cara mencegah HPA membuat Pod tambahan akibat lonjakan CPU atau memori saat startup?

    Untuk aplikasi yang memerlukan periode pemanasan (warm-up), seperti aplikasi berbasis Java, penggunaan CPU dan memori dapat melonjak selama beberapa menit setelah kontainer dimulai. Hal ini dapat menyebabkan HPA melakukan scale-out yang tidak perlu. Untuk mengatasi hal ini, upgrade komponen metrics-server yang disediakan oleh ACK ke versi 0.3.9.6 atau lebih baru dan tambahkan anotasi ke Pod Anda untuk mencegah pemicuan palsu. Untuk informasi lebih lanjut tentang cara mengupgrade komponen metrics-server, lihat Upgrade komponen metrics-server sebelum mengupgrade kluster ke Kubernetes 1.12.

    YAML berikut memberikan contoh cara menambahkan anotasi tersebut.

    Tampilkan contoh kode

    ## Contoh ini menggunakan Deployment.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-basic
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        HPAScaleUpDelay: 3m # 'm' berarti menit. Artinya HPA akan mulai mengevaluasi Pod 3 menit setelah dibuat. Satuan yang didukung adalah s (detik) dan m (menit).
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9 # Ganti dengan <image_name:tags> yang tepat.
        ports:
        - containerPort: 80

    Mengapa HPA menskalakan workload saya meskipun metrik dalam log audit tidak mencapai ambang batas?

    Penyebab

    Horizontal Pod Autoscaler menghitung rasio penskalaan berdasarkan metrik saat ini dan metrik target, dengan rumus jumlah replika yang diinginkan = ceil(jumlah replika saat ini × (metrik saat ini / metrik target)).

    Rumus ini menunjukkan bahwa akurasi jumlah replika yang diinginkan ditentukan oleh akurasi jumlah replika saat ini, metrik saat ini, dan metrik target. Ambil contoh metrik resource yang umum digunakan dalam HPA. Saat HPA mengambil jumlah replika saat ini, pertama-tama HPA mendapatkan subresource scale (subResources) dari objek yang didefinisikan oleh scaleTargetRef. Kemudian, HPA mengonversi nilai Selector dalam status objek scale menjadi labelselector dan menggunakannya sebagai kondisi untuk mencocokkan dan mengambil Pod. Jika pada waktu tertentu, Pod yang diambil dengan kondisi ini tidak secara eksklusif milik objek yang didefinisikan dalam scaleTargetRef, jumlah replika yang diinginkan yang dihitung mungkin salah (misalnya, melakukan scale-up meskipun metrik real-time berada di bawah ambang batas).

    Alasan umum ketidakakuratan jumlah Pod meliputi:

    • Rolling update sedang berlangsung.

    • Pod lain yang tidak termasuk dalam objek scaleTargetRef memiliki label yang sama. Jalankan perintah berikut untuk memeriksa Pod semacam itu:

      kubectl get pods -n {your-namespace} -l {value-of-status.selector}

    Solusi

    Dapatkah saya mengontrol urutan terminasi Pod selama scale-in HPA?

    HPA secara otomatis menambah atau mengurangi jumlah Pod berdasarkan metrik yang ditentukan, tetapi tidak secara langsung menentukan Pod mana yang dihentikan terlebih dahulu. Urutan terminasi Pod dan periode shutdown yang mulus ditentukan oleh pengontrol yang mengelola Pod tersebut, seperti Deployment.

    Dalam skenario di mana Anda menggunakan campuran sumber daya komputasi, seperti Instance ECS dan Instance ECI tanpa server atau beberapa kelompok node, Anda dapat menentukan prioritas scale-in dengan mengonfigurasi ResourcePolicy kustom untuk aplikasi Anda. Dengan menggunakan HPA bersama Deployment dan ResourcePolicy kustom, Anda dapat memprioritaskan terminasi Pod pada node ECI tanpa server daripada node ECS. Untuk informasi lebih lanjut, lihat Penjadwalan sumber daya elastis berbasis prioritas kustom.

    Apa arti satuan metrik utilisasi HPA?

    Metrik penggunaan biasanya berupa bilangan bulat tanpa satuan atau bilangan bulat yang menggunakan m sebagai satuan, dengan rasio konversi 1000m=1. Misalnya, ketika tcp_connection_counts bernilai 70000m, nilainya setara dengan 70.

    Apa yang harus saya lakukan jika perintah kubectl get hpa menampilkan unknown pada kolom TARGETS?

    Ikuti langkah-langkah berikut untuk menyelesaikan masalah ini.

    1. Jalankan perintah kubectl describe hpa <hpa_name> untuk menentukan penyebab kegagalan HPA.

      • Jika field Conditions menunjukkan bahwa AbleToScale bernilai False, verifikasi bahwa Deployment telah diterapkan dengan benar.

      • Jika field Conditions menunjukkan bahwa ScalingActive bernilai False, lanjutkan ke langkah berikutnya.

    2. Jalankan kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/". Jika perintah mengembalikan Error from server (NotFound): the server could not find the requested resource, periksa status alibaba-cloud-metrics-adapter.

      Jika alibaba-cloud-metrics-adapter berjalan dengan baik, periksa apakah metrik HPA terkait dengan Ingress. Jika iya, pertama-tama terapkan komponen Log Service. Untuk informasi lebih lanjut, lihat Kumpulkan dan analisis log akses NGINX Ingress.

    3. Verifikasi bahwa metrik HPA ditentukan dengan benar. Nilai sls.ingress.route harus dalam format <namespace>-<svc>-<port>.

      • namespace: Namespace tempat Ingress berada.

      • svc: Nama Service yang sesuai dengan Ingress.

      • port: Nama port pada Service yang dipetakan oleh Ingress.

    Bagaimana cara mengetahui metrik yang didukung oleh HPA?

    Untuk daftar metrik yang didukung, lihat Metrik HPA Alibaba Cloud. Tabel berikut menjelaskan beberapa metrik yang umum digunakan.

    Nama metrik

    Deskripsi

    Parameter tambahan

    sls_ingress_qps

    Permintaan per detik (QPS) untuk rute Ingress tertentu.

    sls.ingress.route

    sls_alb_ingress_qps

    QPS untuk rute ALB Ingress.

    sls.ingress.route

    sls_ingress_latency_avg

    Latensi rata-rata semua permintaan.

    sls.ingress.route

    sls_ingress_latency_p50

    Latensi permintaan persentil ke-50.

    sls.ingress.route

    sls_ingress_latency_p95

    Latensi permintaan persentil ke-95.

    sls.ingress.route

    sls_ingress_latency_p99

    Latensi permintaan persentil ke-99.

    sls.ingress.route

    sls_ingress_latency_p9999

    Latensi permintaan persentil ke-99,99.

    sls.ingress.route

    sls_ingress_inflow

    Bandwidth masuk Ingress.

    sls.ingress.route

    Bagaimana cara menggunakan HPA setelah menyesuaikan format log NGINX Ingress?

    Untuk menskalakan Pod berdasarkan metrik NGINX Ingress dari Log Service, aktifkan dan konfigurasikan dengan benar pengumpulan log NGINX Ingress untuk kluster Anda. Untuk informasi lebih lanjut, lihat Skalakan Pod berdasarkan metrik NGINX Ingress.

    • Saat Anda membuat kluster, Log Service diaktifkan secara default. Jika Anda mempertahankan pengaturan default, Anda dapat melihat laporan analisis log akses NGINX Ingress dan memantau status real-time NGINX Ingress Anda di Konsol Log Service setelah kluster dibuat.

    • Jika Anda secara manual menonaktifkan Log Service saat membuat kluster, aktifkan kembali atau konfigurasikan agar dapat menggunakan metrik Ingress Log Service untuk penskalaan Pod. Untuk informasi lebih lanjut, lihat Kumpulkan dan analisis log akses NGINX Ingress.

    • CRD AliyunLogConfig yang diterapkan saat Anda pertama kali mengaktifkan Log Service dalam kluster hanya berlaku untuk format log Controller Ingress ACK default. Jika Anda mengubah format log akses Controller Ingress, Anda juga harus mengubah bagian processor_regex dalam konfigurasi CRD. Untuk informasi lebih lanjut, lihat Kumpulkan log kontainer menggunakan konfigurasi DaemonSet-CRD.

    Bagaimana cara mendapatkan metrik sls_ingress_qps dari command line?

    Gunakan perintah berikut untuk mengkueri metrik sls_ingress_qps:

    kubectl get --raw  "/apis/external.metrics.k8s.io/v1beta1/namespaces/*/sls_ingress_qps?labelSelector=sls.project={{SLS_Project}},sls.logstore=nginx-ingress"

    Di sini, {{SLS_Project}} adalah nama Proyek SLS untuk kluster ACK. Jika Anda tidak menentukan nama khusus, nilai default-nya adalah k8s-log-{{ClusterId}}, dengan {{ClusterId}} sebagai ID kluster.

    Jika hasilnya:

    Error from server: {
    "httpCode": 400,
    "errorCode": "ParameterInvalid",
    "errorMessage": "key (slb_pool_name) is not config as key value config,if symbol : is  in your log,please wrap : with quotation mark \"",
    "requestID": "xxxxxxx"
}

    Hal ini menunjukkan bahwa tidak ada data yang tersedia untuk metrik ini. Hal ini dapat terjadi jika Anda mengkueri metrik sls_alb_ingress_qps tetapi tidak menggunakan ALB Ingress.

    Jika hasilnya mirip dengan berikut:

    {
  "kind": "ExternalMetricValueList",
  "apiVersion": "external.metrics.k8s.io/v1beta1",
  "metadata": {},
  "items": [
    {
      "metricName": "sls_ingress_qps",
      "timestamp": "2023-02-26T16:45:00Z", 
      "value": "50",   # Nilai QPS
      "metricLabels": {
        "sls.project": "your-sls-project-name",
        "sls.logstore": "nginx-ingress"
      }
    }
  ]
}

    Hal ini menunjukkan bahwa metrik eksternal Kubernetes QPS berhasil diambil, dengan value sebagai nilai QPS.

    Gagal menarik gambar alibaba-cloud-metrics-adapter

    Gejala

    Saat Anda mengupgrade add-on ack-alibaba-cloud-metrics-adapter ke versi 1.3.7, penarikan gambar gagal. Pesan errornya mirip dengan berikut:

    Gagal menarik gambar "registry-<region-id>-vpc.ack.aliyuncs.com/acs/alibaba-cloud-metrics-adapter-amd64:v0.2.9-ba634de-aliyun".

    Penyebab

    Add-on ack-alibaba-cloud-metrics-adapter tidak mendukung upgrade in-place.

    Solusi

    Upgrade add-on dengan mengikuti langkah-langkah berikut:

    1. Buat cadangan konfigurasi add-on saat ini.

    2. Uninstal versi lama add-on.

    3. Instal versi terbaru add-on menggunakan konfigurasi yang telah dicadangkan.

    Penting

    Selama proses uninstalasi dan instalasi ulang, HPA terkait akan menjeda penskalaan karena pengumpulan metrik terhenti.