All Products
Search

This Product

    Container Service for Kubernetes:FAQ penskalaan workload

    Document Center

    Container Service for Kubernetes:FAQ penskalaan workload

    Last Updated:Apr 25, 2026

    Topik ini menjawab pertanyaan umum dan memberikan solusi untuk masalah yang mungkin Anda temui saat menggunakan fitur penskalaan workload, termasuk Horizontal Pod Autoscaler (HPA) dan CronHPA.

    Daftar Isi

    Mengapa kolom current pada metrik HPA menampilkan unknown?

    Ketika kolom current pada data pemantauan HPA bernilai unknown, hal ini menunjukkan bahwa kube-controller-manager tidak dapat mengakses sumber data pemantauan untuk memperoleh data yang sesuai, sehingga menyebabkan kegagalan penskalaan HPA.

    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 perintah tersebut mengembalikan data. Jika semua Pod tidak mengembalikan data, jalankan kubectl get apiservice untuk memeriksa status sumber data yang menyediakan Resource Metrics. Contoh output yang dikembalikan adalah sebagai berikut.

    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 telah 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 bukan masalah 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: Metrik tidak dapat diambil selama rolling update atau scale-out

    Setelah Pod dibuat atau diperbarui, metrics-server memerlukan waktu untuk mengambil metriknya. Tunggu sekitar dua menit setelah operasi selesai sebelum memeriksa kembali.

    Penyebab 3: Kolom request tidak dikonfigurasi

    Secara default, HPA menggunakan actual utilization/request sebagai nilai utilization. Oleh karena itu, Anda dapat memeriksa apakah kolom resource pada Pod berisi kolom request.

    Penyebab 4: Nama metrik salah

    Periksa apakah nama metrik sudah benar, termasuk penulisannya (huruf besar/kecil). Misalnya, jika Anda salah menulis metrik yang didukung HPA cpu sebagai CPU, maka kolom current pada data pemantauan akan menampilkan unknown.

    Pemecahan masalah kegagalan penskalaan HPA

    Penskalaan HPA dapat gagal karena anomali dalam pengambilan metrik. Saat hal ini terjadi, kolom current pada data pemantauan HPA menampilkan unknown. Akibatnya, HPA tidak dapat memperoleh metrik yang diperlukan untuk pengambilan keputusan penskalaan dan tidak dapat menyesuaikan jumlah Pod. Lihat FAQ Autoscaling Node untuk memecahkan penyebabnya dan menerapkan solusi yang tepat.

    Mengapa HPA membuat Pod tambahan selama rolling update?

    Selama rolling update, kube-controller-manager melaporkan nilai nol untuk Pod yang belum memiliki metrik yang tersedia. Hal ini kadang-kadang menyebabkan HPA membuat lebih banyak Pod daripada yang diperlukan, fenomena yang dikenal sebagai scaling thrashing atau over-scaling. Anda dapat menggunakan konfigurasi berikut untuk mencegah hal ini.

    Konfigurasi tingkat kluster

    Untuk mencegah perilaku ini, upgrade metrics-server yang disediakan ACK ke versi terbaru dan aktifkan parameter startup tertentu.

    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 over-scaling pada workload tertentu, gunakan salah satu metode berikut.

    • Metode 1: Tambahkan anotasi berikut ke templat Pod workload untuk menjeda evaluasi HPA selama rolling update.

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

      Kode contoh

      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 Pod workload untuk menentukan periode pemanasan (warm-up) yang akan diamati HPA setelah aplikasi dimulai.

      # Tambahkan anotasi ini ke spec.template.metadata.annotations workload untuk melewatkan periode pemanasan yang ditentukan.
HPAScaleUpDelay: 3m # 3m adalah contoh. Atur periode sesuai kebutuhan Anda.

      Kode contoh

      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. Pengaturan ini membuat HPA efektif 3 menit setelah Pod 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 tidak hanya mempertimbangkan apakah penggunaan CPU atau memori telah melewati ambang batas. HPA juga menghitung apakah tindakan penskalaan mungkin segera dibalik, yang membantu mencegah scaling thrashing.

    Sebagai contoh, asumsikan ambang batas scale-out Anda adalah 80% dan Anda memiliki dua Pod, masing-masing dengan penggunaan CPU 70%. Dalam kasus ini, HPA tidak akan melakukan scale-in. Hal ini karena HPA menghitung bahwa pengurangan menjadi satu Pod akan memusatkan beban, sehingga mendorong penggunaan CPU melebihi ambang batas scale-out 80% dan segera memicu scale-out baru.

    Cara mengonfigurasi interval pengumpulan metrik HPA

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

    Apakah CronHPA kompatibel dengan HPA? Bagaimana cara kerjanya?

    Ya, CronHPA kompatibel dengan HPA. Di Container Service for Kubernetes (ACK), CronHPA berinteraksi dengan objek HPA dengan mengatur scaleTargetRef-nya agar mengarah ke HPA. CronHPA kemudian menggunakan HPA untuk menemukan target penskalaan aktual. Desain ini membuat CronHPA mengetahui status HPA. CronHPA beroperasi melalui HPA alih-alih langsung menyesuaikan jumlah replika Deployment, sehingga mencegah konflik antara kedua autoscaler tersebut. Untuk informasi lebih lanjut, lihat Aktifkan kolaborasi antara CronHPA dan HPA.

    Cara mencegah over-scaling HPA akibat lonjakan resource awal

    Untuk aplikasi yang ditulis dalam bahasa seperti Java yang memerlukan periode pemanasan, penggunaan CPU dan memori dapat melonjak selama beberapa menit setelah kontainer dimulai. Hal ini dapat menyebabkan HPA memicu scale-out yang tidak perlu. Untuk mencegahnya, upgrade komponen metrics-server yang disediakan ACK ke versi 0.3.9.6 atau lebih baru dan tambahkan anotasi ke spesifikasi Pod Anda untuk mencegah perilaku ini. Untuk instruksi upgrade, lihat Upgrade komponen metrics-server sebelum Anda meningkatkan kluster ke v1.12.

    YAML berikut menunjukkan contoh Deployment yang mencakup anotasi untuk mencegah penskalaan yang tidak diinginkan.

    Contoh YAML

    ## Contoh 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. Pengaturan ini membuat HPA efektif 3 menit setelah Pod 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 melakukan penskalaan meskipun nilai metrik di bawah ambang batas dalam log audit?

    Penyebab

    Horizontal Pod Autoscaler menghitung jumlah replika yang diinginkan berdasarkan rasio antara metrik saat ini dan metrik yang diinginkan menggunakan rumus berikut: jumlah replika yang diinginkan = ceil(jumlah replika saat ini × (metrik saat ini / metrik yang diinginkan)).

    Rumus ini menunjukkan bahwa akurasi jumlah replika yang diinginkan bergantung pada akurasi jumlah replika saat ini, metrik saat ini, dan metrik yang diinginkan. Ambil metrik resource, yang banyak digunakan dalam HPA, sebagai contoh. Untuk mengambil jumlah replika saat ini, HPA pertama-tama memperoleh subresource scale (subResources) dari objek yang didefinisikan oleh scaleTargetRef. Kemudian, HPA mengonversi nilai Selector dari status objek scale menjadi labelselector. Selector ini digunakan sebagai kondisi untuk mencocokkan dan mengambil Pod. Jika pada suatu waktu, Pod yang diambil menggunakan kondisi ini tidak semuanya termasuk dalam objek yang didefinisikan di 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 yang tidak termasuk dalam objek scaleTargetRef memiliki label yang sama. Anda dapat menjalankan perintah berikut untuk memeriksa Pod tersebut:

      kubectl get pods -n {namespace_name} -l {value_of_scale_subresource_status.selector}

    Solusi

    Dapatkah HPA mengontrol urutan scale-in Pod?

    Tidak. HPA hanya menyesuaikan jumlah replika untuk suatu workload; HPA tidak menentukan Pod mana yang akan dihentikan. Controller yang mengelola Pod, seperti Deployment, menentukan urutan penghentian dan periode shutdown yang mulus.

    Namun, di lingkungan campuran dengan jenis node berbeda, seperti instance ECS dan resource ECI tanpa server, atau beberapa kelompok node, Anda dapat memengaruhi prioritas scale-in dengan mengonfigurasi ResourcePolicy kustom. Anda dapat menggunakan HPA dengan Deployment dan ResourcePolicy untuk memprioritaskan scale-in Pod pada node ECI dibandingkan node ECS. Untuk informasi lebih lanjut, lihat Menyesuaikan penjadwalan prioritas resource elastis.

    Apa arti satuan metrik utilization HPA?

    Metrik penggunaan biasanya berupa nilai integer tanpa satuan atau nilai integer dalam satuan m. Rasio konversinya adalah 1000m = 1. Sebagai contoh, ketika tcp_connection_counts bernilai 70000m, nilainya setara dengan 70.

    Apa yang harus saya lakukan jika kolom target menampilkan unknown setelah saya menjalankan kubectl get hpa?

    Ikuti langkah-langkah berikut untuk memecahkan masalah ini.

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

      • Jika kolom Conditions menunjukkan bahwa AbleToScale bernilai False, pastikan Deployment berjalan dengan benar.

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

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

      Jika alibaba-cloud-metrics-adapter berjalan dengan benar, periksa apakah metrik HPA terkait dengan Ingress. Jika iya, Anda harus terlebih dahulu menerapkan komponen Simple Log Service (SLS). Untuk informasi lebih lanjut, lihat Kumpulkan dan analisis log akses Nginx Ingress.

    3. Verifikasi bahwa metrik HPA dimasukkan dengan benar. Nilai sls.ingress.route menggunakan format <namespace>-<svc>-<port>.

      • namespace: Namespace dari Ingress.

      • svc: Nama Service untuk Ingress.

      • port: Nama port untuk Service yang terkait dengan Ingress.

    Cara menemukan metrik yang didukung oleh HPA

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

    Metrik

    Deskripsi

    Parameter tambahan

    sls_ingress_qps

    QPS untuk entri rute Ingress yang ditentukan.

    sls.ingress.route

    sls_alb_ingress_qps

    QPS untuk entri rute ALB Ingress yang ditentukan.

    sls.ingress.route

    sls_ingress_latency_avg

    Latensi rata-rata untuk semua permintaan.

    sls.ingress.route

    sls_ingress_latency_p50

    Latensi persentil ke-50 dari permintaan.

    sls.ingress.route

    sls_ingress_latency_p95

    Latensi persentil ke-95 dari permintaan.

    sls.ingress.route

    sls_ingress_latency_p99

    Latensi persentil ke-99 dari permintaan.

    sls.ingress.route

    sls_ingress_latency_p9999

    Latensi persentil ke-99,99 dari permintaan.

    sls.ingress.route

    sls_ingress_inflow

    Bandwidth masuk dari Ingress.

    sls.ingress.route

    Autoscaling dengan format log Nginx Ingress kustom

    Untuk mempelajari cara menggunakan metrik Ingress SLS untuk penskalaan horizontal Pod, lihat Skala Pod berdasarkan metrik Nginx Ingress. Ini memerlukan pengaktifan dan konfigurasi yang benar untuk pengumpulan log Nginx Ingress ke Simple Log Service (SLS) di kluster Anda.

    • Secara default, Simple Log Service diaktifkan saat Anda membuat kluster. Jika Anda mempertahankan pengaturan default, Anda dapat melihat dasbor analisis log akses dan memantau status real-time Nginx Ingress di Konsol SLS setelah kluster dibuat.

    • Jika Anda menonaktifkan Simple Log Service saat pembuatan kluster, Anda harus mengaktifkan dan mengonfigurasinya kembali untuk menggunakan metrik Ingress SLS dalam penskalaan. Untuk informasi lebih lanjut, lihat Kumpulkan dan analisis log akses Nginx Ingress.

    • Jika Anda perlu menyesuaikan format log Nginx Ingress dan telah mengubah format log akses Controller Ingress, Anda harus memodifikasi bagian processor_regex untuk ekstraksi ekspresi reguler dalam konfigurasi CRD. Hal ini karena CRD AliyunLogConfig yang diterapkan saat Anda pertama kali mengaktifkan Simple Log Service (SLS) di kluster hanya berlaku untuk format log Controller Ingress default di ACK. Untuk informasi lebih lanjut, lihat Kumpulkan log kontainer menggunakan DaemonSet-CRD.

    Cara mengambil metrik QPS sls_ingress_qps menggunakan CLI?

    Anda dapat mengambil metrik sls_ingress_qps dengan menggunakan perintah berikut:

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

    Dalam hal ini, {{SLS_Project}} adalah nama Proyek SLS untuk kluster ACK. Jika Anda tidak menentukan nama kustom, nilai default-nya adalah k8s-log-{{ClusterId}}, dengan {{ClusterId}} sebagai ID kluster.

    Jika perintah mengembalikan error berikut:

    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 melakukan kueri untuk metrik ALB Ingress seperti sls_alb_ingress_qps tanpa memiliki ALB Ingress yang dikonfigurasi.

    Jika perintah mengembalikan hasil seperti berikut:

    {
  "kind": "ExternalMetricValueList",
  "apiVersion": "external.metrics.k8s.io/v1beta1",
  "metadata": {},
  "items": [
    {
      "metricName": "sls_ingress_qps",
      "timestamp": "2025-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 telah diambil, dengan value sebagai nilai QPS.

    Gagal menarik gambar alibaba-cloud-metrics-adapter

    Gejala

    Saat Anda melakukan upgrade komponen ack-alibaba-cloud-metrics-adapter ke versi 1.3.7, penarikan gambar gagal dengan error berikut:

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

    Penyebab

    Komponen ack-alibaba-cloud-metrics-adapter saat ini tidak mendukung upgrade in-place.

    Solusi

    Untuk melakukan upgrade komponen, ikuti langkah-langkah berikut:

    1. Buat cadangan konfigurasi komponen saat ini.

    2. Uninstall versi lama komponen tersebut.

    3. Instal versi terbaru komponen dengan menggunakan konfigurasi yang telah dicadangkan.

    Penting

    Selama proses ini, penskalaan untuk objek HPA terkait dijeda karena pengumpulan metrik berhenti.