All Products
Search

This Product

    Container Service for Kubernetes:FAQ penskalaan workload

    Document Center

    Container Service for Kubernetes:FAQ penskalaan workload

    Last Updated:Aug 29, 2026

    Selesaikan masalah umum terkait HPA dan CronHPA, termasuk kegagalan pengambilan metrik, over-scaling, serta perilaku ambang batas.

    Daftar Isi

    Mengapa bidang current pada metrik HPA menampilkan unknown?

    Ketika bidang current pada HPA menampilkan unknown, kube-controller-manager tidak dapat mengakses sumber data metrik, 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

    Jalankan kubectl top pod untuk memeriksa apakah data dikembalikan. Jika tidak ada Pod yang mengembalikan data, jalankan kubectl get apiservice untuk memeriksa status sumber data Resource Metrics. Contoh output:

    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, kemungkinan telah ditimpa oleh Prometheus Operator. Pulihkan dengan menerapkan 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 ini bukan penyebabnya, buka Operations > Add-ons untuk kluster Anda dan pastikan metrics-server telah diinstal.

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

    Setelah Pod dibuat atau diperbarui, metrics-server memerlukan waktu untuk mengumpulkan metrik. Tunggu sekitar dua menit sebelum memeriksa kembali.

    Penyebab 3: Bidang request tidak dikonfigurasi

    Secara default, HPA menggunakan actual utilization/request sebagai nilai utilization. Periksa apakah bidang resource pada Pod berisi bidang request.

    Penyebab 4: Nama metrik salah

    Periksa apakah nama dan penulisan huruf metrik sudah benar. Misalnya, menulis cpu sebagai CPU menyebabkan bidang current menampilkan unknown.

    Pemecahan masalah kegagalan penskalaan HPA

    Saat pengambilan metrik gagal, bidang current pada HPA menampilkan unknown dan penskalaan berhenti. Lihat FAQ Autoscaling Node untuk pemecahan masalah.

    Mengapa HPA membuat Pod tambahan selama rolling update?

    Selama rolling update, controller-manager melaporkan nilai nol untuk Pod tanpa metrik, yang dapat menyebabkan HPA membuat Pod berlebihan (over-scaling). Gunakan konfigurasi berikut untuk mencegah hal ini.

    Konfigurasi tingkat kluster

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

    Konfigurasi ini memengaruhi semua workload 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.

    • Jeda evaluasi HPA selama rolling update dengan menambahkan anotasi berikut ke templat Pod:

      # 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

    • Tetapkan periode pemanasan setelah aplikasi dimulai dengan menambahkan anotasi berikut ke templat Pod:

      # 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 berlaku 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 melakukan penskalaan berdasarkan apakah CPU atau memori melewati ambang batas. HPA juga memeriksa apakah tindakan penskalaan akan segera dibalik, untuk mencegah thrashing.

    Sebagai contoh, dengan ambang batas scale-out 80% dan dua Pod masing-masing pada CPU 70%, HPA tidak akan melakukan scale-in karena mengurangi menjadi satu Pod akan mendorong CPU di atas 80% dan langsung memicu scale-out.

    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. Contohnya: --metric-resolution=15s.

    Apakah CronHPA kompatibel dengan HPA? Bagaimana cara kerjanya?

    Ya. Di ACK, CronHPA mengatur scaleTargetRef-nya ke HPA dan melakukan penskalaan melaluinya, bukan langsung menyesuaikan jumlah replika Deployment, sehingga mencegah konflik antara kedua autoscaler tersebut. Lihat Aktifkan kolaborasi antara CronHPA dan HPA.

    Bagaimana mencegah over-scaling HPA akibat lonjakan resource awal?

    Aplikasi dalam bahasa seperti Java dapat mengalami lonjakan CPU dan memori selama pemanasan setelah kontainer dimulai, yang memicu scale-out HPA yang tidak perlu. Untuk mencegah hal ini, upgrade metrics-server ACK ke versi 0.3.9.6 atau lebih baru dan tambahkan anotasi ke spesifikasi Pod Anda. Lihat Upgrade komponen metrics-server sebelum Anda meningkatkan kluster ke v1.12.

    Contoh Deployment dengan anotasi:

    YAML contoh

    ## 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 berlaku 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)).

    Jumlah replika yang diinginkan bergantung pada jumlah replika saat ini, metrik saat ini, dan metrik yang diinginkan. Untuk metrik resource, HPA memperoleh subresource scale (subResources) dari objek scaleTargetRef dan mengonversi Selector dari status objek scale menjadi labelselector untuk mencocokkan Pod. Jika Pod yang cocok tidak semuanya termasuk dalam objek scaleTargetRef, jumlah replika yang dihitung mungkin salah (misalnya, melakukan scale-up meskipun metrik di bawah ambang batas).

    Alasan umum ketidakakuratan jumlah Pod meliputi:

    • Rolling update sedang berlangsung.

    • Pod di luar objek scaleTargetRef memiliki label yang sama. Periksa 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, bukan Pod mana yang akan dihentikan. Controller yang mengelola (seperti Deployment) menentukan urutan penghentian dan shutdown yang mulus.

    Namun, di lingkungan campuran dengan jenis node seperti ECS, ACS, dan ECI, atau beberapa kelompok node, gunakan ResourcePolicy untuk mengontrol prioritas scale-in — misalnya, scale-in Pod ECI sebelum Pod ECS. Lihat Menyesuaikan penjadwalan prioritas resource elastis.

    Apa arti satuan metrik utilization HPA?

    Metrik penggunaan berupa bilangan bulat tanpa satuan atau bilangan bulat dalam satuan m (1000m = 1). Sebagai contoh, 70000m sama dengan 70.

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

    Untuk pemecahan masalah:

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

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

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

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

      Jika alibaba-cloud-metrics-adapter berjalan dengan benar, periksa apakah metrik HPA terkait Ingress. Jika iya, terapkan komponen SLS terlebih dahulu. Lihat Kumpulkan dan analisis log akses Nginx Ingress.

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

      • namespace: Namespace dari Ingress.

      • svc: Nama layanan Ingress.

      • port: Nama port layanan Ingress.

    Bagaimana cara menemukan metrik yang didukung oleh HPA?

    Lihat Metrik HPA Alibaba Cloud untuk daftar lengkapnya. Metrik umum:

    Metric

    Description

    Additional parameter

    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 menggunakan metrik Ingress SLS dalam penskalaan horizontal Pod, lihat Skala Pod berdasarkan metrik Nginx Ingress. Pengumpulan log Nginx Ingress ke SLS harus diaktifkan di kluster Anda.

    • SLS diaktifkan secara default saat pembuatan kluster. Dengan pengaturan default, dasbor log akses dan pemantauan Nginx Ingress tersedia di Konsol SLS.

    • Jika Anda menonaktifkan SLS saat pembuatan kluster, aktifkan dan konfigurasikan ulang. Lihat Kumpulkan dan analisis log akses Nginx Ingress.

    • Jika Anda menyesuaikan format log Nginx Ingress, perbarui bagian processor_regex dalam konfigurasi CRD. CRD AliyunLogConfig default hanya cocok dengan format log default Ingress Controller. Lihat Kumpulkan log kontainer menggunakan DaemonSet-CRD.

    Bagaimana cara mengambil metrik QPS sls_ingress_qps menggunakan CLI?

    Ambil 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"

    {{SLS_Project}} adalah nama Proyek SLS untuk kluster ACK. Default: k8s-log-{{ClusterId}}, dengan {{ClusterId}} sebagai ID kluster.

    Jika error berikut dikembalikan:

    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"
}

    Artinya tidak ada data yang tersedia untuk metrik tersebut, yang terjadi saat mengkueri metrik ALB Ingress (seperti sls_alb_ingress_qps) tanpa ALB Ingress yang dikonfigurasi.

    Jika hasil seperti berikut dikembalikan:

    {
  "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"
      }
    }
  ]
}

    Ini mengonfirmasi metrik berhasil diambil. value adalah nilai QPS.

    Gagal menarik gambar alibaba-cloud-metrics-adapter

    Gejala

    Saat Anda meningkatkan 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

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

    Solusi

    Untuk melakukan upgrade:

    1. Buat cadangan konfigurasi komponen saat ini.

    2. Uninstall versi lama komponen tersebut.

    3. Instal versi terbaru dengan konfigurasi yang telah dicadangkan.

    Penting

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