All Products
Search

This Product

    Container Service for Kubernetes:FAQ Penskalaan Workload

    Document Center

    Container Service for Kubernetes:FAQ Penskalaan Workload

    Last Updated:Mar 07, 2026

    Topik ini menjelaskan masalah umum dan solusinya saat menggunakan fitur penskalaan workload, yang mencakup Horizontal Pod Autoscaler (HPA), CronHPA, dan metode lainnya.

    Indeks

    Mengapa kolom current pada data pemantauan HPA ditampilkan sebagai unknown?

    Jika kolom current pada data pemantauan HPA menunjukkan unknown, artinya kube-controller-manager tidak dapat mengakses sumber data pemantauan untuk mengambil data tersebut. Akibatnya, penskalaan HPA gagal.

    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 Resource Metrics tidak tersedia

    Jalankan perintah kubectl top pod untuk memeriksa apakah data dikembalikan. Jika tidak ada data yang dikembalikan untuk pod apa pun, jalankan perintah kubectl get apiservice untuk memeriksa status sumber data Resource Metrics. Contoh berikut menunjukkan data yang dikembalikan.

    Perluas untuk melihat contoh data

    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 yang sesuai dengan v1beta1.metrics.k8s.io bukan kube-system/metrics-server, periksa apakah telah ditimpa oleh instalasi Prometheus Operator. Jika iya, Anda dapat menerapkan templat YAML berikut untuk memulihkannya.

    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 tetap berlanjut, pastikan komponen metrics-server telah diinstal melalui halaman Operations > Add-ons kluster Anda. Untuk informasi lebih lanjut, lihat metrics-server.

    Penyebab 2: Data tidak dapat diambil selama penyebaran bergulir atau scale-out

    Secara default, siklus pengumpulan metrics-server adalah 1 menit. Setelah scale-out atau pembaruan, metrics-server tidak dapat mengambil data pemantauan untuk periode singkat. Anda dapat memeriksa kembali sekitar 2 menit setelah scale-out atau pembaruan selesai.

    Penyebab 3: Kolom request tidak dikonfigurasi

    Secara default, HPA menggunakan rumus actual utilization/request untuk menghitung nilai pemanfaatan. Periksa apakah kolom resource pada pod berisi kolom request.

    Penyebab 4: Nama metrik salah

    Periksa kebenaran nama metrik, termasuk huruf kapitalnya. Misalnya, jika Anda memasukkan CPU alih-alih metrik cpu yang didukung HPA, kolom current pada data pemantauan akan menunjukkan unknown.

    Apa yang harus dilakukan jika penskalaan HPA gagal karena pengambilan metrik tidak normal?

    Penskalaan HPA dapat gagal karena pengambilan metrik tidak normal, yang menyebabkan kolom current pada data pemantauan HPA menunjukkan unknown. Dalam kasus ini, HPA tidak dapat memperoleh metrik yang diperlukan untuk keputusan penskalaan dan tidak dapat menyesuaikan jumlah replika. Untuk informasi lebih lanjut tentang cara memecahkan masalah ini, lihat FAQ Auto Scaling Node.

    Mengapa HPA melakukan scale-out pod tambahan selama penyebaran bergulir?

    Selama penyebaran bergulir, Controller Manager komunitas melakukan zero-padding untuk pod yang tidak memiliki data pemantauan. Hal ini dapat menyebabkan HPA melakukan scale-out pod tambahan. Anda dapat menggunakan konfigurasi berikut untuk mencegah masalah ini.

    Konfigurasi tingkat kluster

    Upgrade ke versi terbaru komponen metrics-server yang disediakan oleh ACK dan aktifkan sakelar dalam parameter startup metrics-server untuk mencegah scale-out pod tambahan.

    Sakelar ini bersifat global dan berlaku untuk semua workload terkait dalam kluster setelah diaktifkan.

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

    Konfigurasi tingkat workload

    Jika Anda hanya ingin mencegah scale-out pod tambahan untuk workload tertentu, gunakan salah satu dari dua metode berikut.

    • Metode 1: Tambahkan anotasi berikut ke templat workload yang ditentukan untuk sementara menjeda evaluasi HPA selama penyebaran bergulir.

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

      Perluas untuk melihat detail 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"  # Lewati efek HPA selama penyebaran bergulir.
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

    • Metode 2: Tambahkan anotasi berikut ke templat workload yang ditentukan untuk melewati periode ramp-up yang dikonfigurasi di awal penyebaran aplikasi.

      # Tambahkan anotasi ke spec.template.metadata.annotations workload untuk melewati periode ramp-up yang dikonfigurasi di awal penyebaran aplikasi.
HPAScaleUpDelay: 3m # 3m adalah contoh. Atur periode waktu spesifik sesuai kebutuhan.

      Perluas untuk melihat detail 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 menunjukkan menit. Artinya HPA berlaku 3 menit setelah pod dibuat. Satuan yang valid adalah [s (detik), m (menit)].
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

    Mengapa HPA tidak melakukan penskalaan meskipun ambang batas telah tercapai?

    Penskalaan HPA dipicu ketika penggunaan CPU atau memori melebihi atau turun di bawah ambang batas. HPA juga mempertimbangkan apakah tindakan scale-out atau scale-in akan segera memicu peristiwa penskalaan lainnya guna mengurangi osilasi.

    Misalnya, jika ambang batas scale-out Anda adalah 80% dan dua pod saat ini memiliki penggunaan CPU 70%, HPA tidak akan melakukan scale-in. Hal ini karena scale-in dapat menyebabkan penggunaan CPU satu pod melebihi 80%, yang akan memicu scale-out dan menyebabkan osilasi.

    Bagaimana cara mengonfigurasi siklus pengumpulan HPA?

    Untuk versi metrics-server yang lebih baru dari v0.2.1-b46d98c-aliyun, Anda dapat mengatur parameter --metric-resolution dalam parameter startup metrics-server. Misalnya, atur parameter menjadi --metric-resolution=15s.

    Apakah CronHPA kompatibel dengan HPA? Bagaimana cara membuatnya kompatibel?

    CronHPA kompatibel dengan HPA. Container Service for Kubernetes (ACK) mengatur scaleTargetRef dalam objek CronHPA ke objek HPA. CronHPA kemudian menggunakan objek HPA untuk menemukan scaleTargetRef aktual, sehingga dapat memahami status terkini HPA. CronHPA tidak langsung menyesuaikan jumlah replika untuk deployment, melainkan beroperasi melalui HPA. Pendekatan ini menghindari konflik antara HPA dan CronHPA. Untuk informasi lebih lanjut tentang cara memastikan kompatibilitas CronHPA dan HPA, lihat Mewujudkan kolaborasi CronHPA dan HPA.

    Bagaimana mencegah HPA melakukan scale-out pod tambahan akibat penggunaan CPU atau memori tinggi selama startup?

    Untuk bahasa dan framework yang memerlukan periode ramp-up, seperti Java, penggunaan CPU dan memori dapat melonjak selama beberapa menit saat kontainer dimulai. Hal ini dapat menyebabkan HPA terpicu secara salah. Untuk mencegah pemicuan salah, upgrade komponen metrics-server yang disediakan oleh ACK ke versi 0.3.9.6 atau lebih baru dan tambahkan sakelar ke anotasi pod. Untuk informasi lebih lanjut tentang cara mengupgrade komponen metrics-server, lihat Upgrade komponen metrics-server sebelum Anda mengupgrade kluster ke v1.12.

    File YAML berikut memberikan contoh deployment dengan sakelar yang ditambahkan untuk mencegah pemicuan salah.

    Perluas untuk melihat detail 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 menunjukkan menit. Artinya HPA berlaku 3 menit setelah pod dibuat. Satuan yang valid adalah [s (detik), 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 log audit belum mencapai ambang batas?

    Penyebab

    Controller horizontal pod autoscaler menghitung rasio penskalaan berdasarkan metrik saat ini dan yang diinginkan menggunakan rumus berikut: jumlah replika yang diinginkan = ceil (jumlah replika saat ini × (metrik saat ini / metrik yang diinginkan)).

    Rumus tersebut menunjukkan bahwa akurasi jumlah replika yang diinginkan bergantung pada akurasi jumlah replika saat ini, nilai metrik saat ini, dan nilai metrik yang diinginkan. Ambil metrik resource, yang banyak digunakan dalam HPA, sebagai contoh. Saat HPA mengambil jumlah replika saat ini, pertama-tama HPA memperoleh subresource scale (subResources) dari objek yang didefinisikan oleh scaleTargetRef. Kemudian, HPA mengonversi nilai Selector dalam status dari scale menjadi label selector dan menggunakannya sebagai kondisi untuk mencocokkan pod. Jika pod yang diambil berdasarkan kondisi ini tidak semuanya milik objek yang didefinisikan dalam scaleTargetRef, jumlah replika yang diinginkan yang dihitung mungkin tidak sesuai harapan. Misalnya, scale-out dapat dipicu meskipun metrik real-time berada di bawah ambang batas.

    Daftar berikut menjelaskan alasan umum ketidakakuratan pencocokan pod:

    • Penyebaran bergulir.

    • Pod lain yang tidak termasuk dalam objek yang didefinisikan dalam scaleTargetRef memiliki label yang sama. Anda dapat menjalankan perintah berikut untuk memeriksa pod lain tersebut.

      kubectl get pods -n {nama namespace} -l {nilai status.Selector dari sub-resource scale}

    Solusi

    • Untuk masalah terkait penyebaran bergulir, lihat FAQ Auto Scaling Node.

    • Jika pod lain yang tidak termasuk dalam objek yang didefinisikan dalam scaleTargetRef memiliki label yang sama, identifikasi pod tersebut. Jika masih diperlukan, ubah labelnya; jika tidak, hapus pod tersebut.

    Dapatkah saya menentukan urutan scale-in pod selama HPA melakukan scale-in?

    HPA dapat secara otomatis menambah atau mengurangi jumlah pod berdasarkan metrik yang ditentukan, tetapi tidak dapat menentukan pod mana yang dihentikan terlebih dahulu. Urutan penghentian pod, periode shutdown yang mulus, dan atribut lainnya ditentukan oleh controller yang mengelola pod tersebut.

    Dalam skenario yang melibatkan ECS dan ECI, atau penyebaran hybrid multi-node pool, Anda dapat mengonfigurasi kebijakan resource kustom (ResourcePolicy) untuk aplikasi Anda guna menentukan prioritas scale-in. HPA dapat bekerja sama dengan Deployment dan kebijakan resource kustom (ResourcePolicy) untuk memprioritaskan pelepasan resource node ECI selama scale-in, diikuti oleh resource ECS. Untuk informasi lebih lanjut, lihat Penjadwalan prioritas resource elastis kustom.

    Apa arti satuan metrik pemanfaatan HPA?

    Metrik pemanfaatan biasanya berupa bilangan bulat tanpa satuan atau bilangan bulat dalam satuan m. Konversinya adalah 1000m = 1. Misalnya, nilai tcp_connection_counts sebesar 70000m setara dengan 70.

    Apa yang harus dilakukan jika kolom target menunjukkan unknown setelah menjalankan perintah kubectl get hpa?

    Lakukan langkah-langkah berikut untuk mengatasi masalah ini.

    1. Jalankan perintah kubectl describe hpa <hpa_name> untuk mengidentifikasi penyebab HPA tidak berfungsi.

      • Jika nilai AbleToScale dalam kolom Conditions adalah False, pastikan deployment berjalan normal.

      • Jika nilai ScalingActive dalam kolom Conditions adalah False, lanjutkan ke langkah berikutnya.

    2. Jalankan perintah kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/". Jika responsnya adalah 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 normal, pastikan metrik HPA terkait dengan Ingress. Jika iya, Anda harus terlebih dahulu menerapkan komponen Simple Log Service. Untuk informasi lebih lanjut, lihat Kumpulkan dan analisis log akses Nginx Ingress.

    3. Pastikan metrik HPA dimasukkan dengan benar. Format nilai untuk sls.ingress.route adalah <namespace>-<svc>-<port>.

      • namespace: Namespace tempat Ingress berada.

      • svc: Nama Service yang sesuai dengan Ingress.

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

    Bagaimana cara menemukan nama metrik yang didukung oleh HPA?

    Untuk informasi lebih lanjut, lihat Metrik HPA Alibaba Cloud. Tabel berikut mencantumkan metrik umum.

    Nama metrik

    Deskripsi

    Parameter tambahan

    sls_ingress_qps

    Permintaan per detik (QPS) untuk IngressRoute tertentu

    sls.ingress.route

    sls_alb_ingress_qps

    Permintaan per detik (QPS) untuk IngressRoute data ALB

    sls.ingress.route

    sls_ingress_latency_avg

    Latensi untuk semua permintaan

    sls.ingress.route

    sls_ingress_latency_p50

    Latensi untuk 50% permintaan

    sls.ingress.route

    sls_ingress_latency_p95

    Latensi untuk 95% permintaan

    sls.ingress.route

    sls_ingress_latency_p99

    Latensi untuk 99% permintaan

    sls.ingress.route

    sls_ingress_latency_p9999

    Latensi untuk 99,99% permintaan

    sls.ingress.route

    sls_ingress_inflow

    Bandwidth masuk untuk Ingress

    sls.ingress.route

    Bagaimana Beradaptasi Setelah Menyesuaikan Format Log Nginx Ingress?

    Untuk informasi lebih lanjut tentang cara menggunakan metrik Ingress SLS untuk penskalaan pod horizontal, lihat Penskalaan pod horizontal berdasarkan metrik komponen Nginx Ingress. Anda harus mengaktifkan dan mengonfigurasi log Nginx Ingress agar diingest ke Simple Log Service di kluster Anda.

    • Saat Anda membuat kluster, Simple 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 di Konsol Simple Log Service setelah kluster dibuat.

    • Jika Anda secara manual menonaktifkan Simple Log Service saat membuat kluster dan ingin menggunakan metrik Ingress SLS untuk penskalaan pod horizontal setelah kluster dibuat, Anda harus mengaktifkan ulang atau mengonfigurasi Simple Log Service. Untuk informasi lebih lanjut, lihat Kumpulkan dan analisis log akses Nginx Ingress.

    • Untuk menyesuaikan format log Nginx Ingress, definisi resource kustom (CRD) AliyunLogConfig yang diterapkan saat Simple Log Service pertama kali diaktifkan di kluster hanya berlaku untuk format log di Controller Ingress ACK default. Jika Anda mengubah format log akses Controller Ingress, Anda harus memodifikasi bagian processor_regex dalam ekspresi reguler konfigurasi CRD. Untuk informasi lebih lanjut, lihat Kumpulkan log kontainer menggunakan DaemonSet dan CRD.

    Bagaimana cara mendapatkan metrik sls_ingress_qps melalui command line?

    Anda dapat menjalankan perintah berikut untuk mengkueri data. Metrik permintaan sls_ingress_qps digunakan sebagai contoh.

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

    Dalam perintah di atas, {{SLS_Project}} adalah nama proyek Simple Log Service yang sesuai dengan kluster ACK. Jika Anda tidak menentukan konfigurasi kustom, nama proyek default adalah k8s-log-{{ClusterId}}. {{ClusterId}} adalah ID kluster.

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

    Hal ini menunjukkan bahwa tidak ada data yang tersedia untuk metrik ini. Ini mungkin karena ALB Ingress tidak dikonfigurasi, tetapi metrik sls_alb_ingress_qps digunakan untuk kueri data.

    Jika hasil yang mirip dengan 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"
      }
    }
  ]
}

    Hal ini menunjukkan bahwa permintaan per detik (QPS) metrik eksternal Kubernetes ditemukan. value adalah nilai QPS.

    Gagal menarik gambar alibaba-cloud-metrics-adapter

    Gejala

    Saat Anda mengupgrade komponen ack-alibaba-cloud-metrics-adapter ke versi 1.3.7, terjadi kesalahan saat menarik gambar. Pesan kesalahan sebagai 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 tidak mendukung pembaruan langsung.

    Solusi

    Lakukan langkah-langkah berikut untuk mengupgrade komponen.

    1. Buat cadangan konfigurasi komponen saat ini.

    2. Uninstal versi lama komponen.

    3. Instal versi terbaru komponen menggunakan konfigurasi cadangan.

    Penting

    Selama proses uninstal dan instal ulang komponen, HPA terkait akan menjeda penskalaan karena pengambilan data pemantauan terhenti.