全部产品
Search

搜索本产品

    Container Service for Kubernetes：FAQ penskalaan workload

    文档中心

    Container Service for Kubernetes：FAQ penskalaan workload

    更新时间：Dec 25, 2025

    Topik ini membahas masalah umum dan menyediakan solusi untuk fitur penskalaan workload, yang mencakup Horizontal Pod Autoscaler (HPA) dan CronHPA.

    Indeks

    Mengapa kolom current untuk data pemantauan HPA menampilkan unknown?

    Jika kolom current untuk data pemantauan HPA menampilkan unknown, berarti kube-controller-manager tidak dapat mengakses sumber data pemantauan untuk mengambil data yang diperlukan. Akibatnya, penskalaan HPA akan 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

    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. Berikut adalah contoh output.

    Klik untuk melihat 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 yang sesuai dengan v1beta1.metrics.k8s.io bukan kube-system/metrics-server, periksa apakah hal ini disebabkan oleh penimpaan selama instalasi operator prometheus. Jika masalah disebabkan oleh penimpaan, Anda dapat menerapkan templat YAML berikut untuk memulihkan layanan tersebut.

    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 penyebab tersebut, pastikan komponen metrics-server telah diinstal pada halaman Component Management di bawah Operations Management di Konsol kluster. Untuk informasi lebih lanjut, lihat metrics-server.

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

    Periode pengumpulan data default untuk metrics-server adalah 1 menit. Untuk waktu singkat setelah scale-out atau pembaruan, metrics-server tidak dapat mengambil data pemantauan. Periksa kembali sekitar 2 menit setelah scale-out atau pembaruan.

    Penyebab 3: Kolom request tidak dikonfigurasi

    Secara default, HPA menghitung nilai penggunaan menggunakan rumus actual utilization/request. Periksa apakah kolom resource pada Pod berisi kolom request.

    Penyebab 4: Nama metrik salah

    Periksa apakah nama metrik benar, termasuk huruf kapitalnya. Misalnya, jika Anda salah mengeja metrik yang didukung HPA cpu menjadi CPU, kolom current untuk data pemantauan akan menampilkan unknown.

    Apa yang harus saya lakukan jika penskalaan HPA gagal dan pengambilan metrik tidak normal?

    Penskalaan HPA dapat gagal jika pengambilan metrik tidak normal. Dalam kasus ini, kolom current untuk data pemantauan HPA akan menampilkan unknown. HPA tidak dapat mengambil metrik yang diperlukan untuk membuat keputusan penskalaan dan tidak dapat menyesuaikan jumlah Pod. Untuk informasi lebih lanjut tentang cara memecahkan masalah dan menemukan solusi, lihat FAQ autoscaling node.

    Mengapa HPA melakukan scale out Pod tambahan selama pembaruan bergulir?

    Selama penyebaran bergulir, Controller Manager komunitas mengisi nol untuk data pemantauan Pod yang tidak memiliki data. Hal ini kadang-kadang menyebabkan HPA melakukan scale out Pod tambahan, suatu masalah yang dikenal sebagai jitter penskalaan. Anda dapat menggunakan konfigurasi berikut untuk mencegah hal ini.

    Konfigurasi tingkat kluster

    Anda dapat meningkatkan ke versi terbaru metrics-server yang disediakan oleh ACK dan mengaktifkan sakelar dalam parameter startup metrics-server untuk mencegah jitter penskalaan.

    Ini adalah sakelar global. Setelah Anda mengaturnya, ini akan memengaruhi semua workload terkait dalam kluster.

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

    Konfigurasi tingkat workload

    Jika Anda hanya ingin mencegah jitter penskalaan untuk workload tertentu, Anda dapat menggunakan 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 ini ke spec.template.metadata.annotations workload untuk sementara menjeda evaluasi HPA selama penyebaran bergulir.
HPARollingUpdateSkipped: "true"

      Klik untuk melihat 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 ditentukan pada awal penerapan aplikasi.

      # Tambahkan anotasi ini ke spec.template.metadata.annotations workload untuk melewati periode ramp-up yang ditentukan pada awal penerapan aplikasi.
HPAScaleUpDelay: 3m # 3m adalah contoh. Atur periode sesuai kebutuhan.

      Klik untuk melihat 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 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?

    HPA memicu peristiwa penskalaan berdasarkan lebih dari sekadar penggunaan CPU atau memori yang melebihi ambang batas. HPA juga mempertimbangkan apakah tindakan scale-out atau scale-in akan segera memicu tindakan penskalaan sebaliknya untuk mencegah jitter penskalaan.

    Misalnya, asumsikan ambang batas scale-out Anda diatur ke 80%. Jika Anda memiliki dua Pod dan keduanya berada pada penggunaan CPU 70%, HPA tidak akan melakukan scale-in. Hal ini karena scale-in menjadi satu Pod kemungkinan besar akan mendorong penggunaan CPU-nya di atas 80%, yang kemudian akan memicu scale-out. Ini mencegah penskalaan bolak-balik yang cepat.

    Bagaimana cara mengonfigurasi periode pengumpulan data 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. Contohnya: --metric-resolution=15s.

    Apakah CronHPA kompatibel dengan HPA? Bagaimana cara membuatnya kompatibel?

    CronHPA kompatibel dengan HPA. Di Container Service for Kubernetes (ACK), scaleTargetRef dalam objek CronHPA diatur ke objek HPA. CronHPA kemudian menemukan scaleTargetRef aktual melalui objek HPA, sehingga mengetahui status terkini HPA. CronHPA tidak langsung menyesuaikan jumlah replika dalam deployment. Sebaliknya, CronHPA beroperasi pada deployment melalui HPA. Hal ini mencegah konflik antara CronHPA dan HPA. Untuk informasi lebih lanjut tentang mengkoordinasikan CronHPA dan HPA, lihat Koordinasikan CronHPA dan HPA.

    Bagaimana cara mengatasi masalah scale out Pod tambahan akibat penggunaan CPU atau memori yang tinggi saat HPA dimulai?

    Untuk bahasa dan framework yang memerlukan periode pemanasan, seperti Java, penggunaan CPU dan memori dapat melonjak selama beberapa menit saat kontainer dimulai. Hal ini dapat menyebabkan HPA terpicu secara salah. Untuk mengatasi masalah ini, tingkatkan komponen metrics-server di ACK ke versi 0.3.9.6 atau lebih baru dan tambahkan anotasi ke Pod untuk mencegah pemicuan palsu. Untuk informasi lebih lanjut tentang peningkatan komponen metrics-server, lihat Tingkatkan komponen metrics-server sebelum meningkatkan kluster ke v1.12.

    Berikut adalah contoh file YAML untuk deployment yang mencakup anotasi untuk mencegah pemicuan palsu.

    Klik untuk melihat contoh YAML

    ## Contoh untuk 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 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> Anda.
        ports:
        - containerPort: 80

    Mengapa HPA melakukan penskalaan meskipun nilai dalam log audit tidak mencapai ambang batas?

    Penyebab

    HPA menghitung jumlah replika yang diinginkan berdasarkan nilai metrik saat ini dan yang diinginkan menggunakan rumus berikut: desiredReplicas = ceil(currentReplicas × (currentMetricValue / desiredMetricValue)).

    Rumus ini menunjukkan bahwa akurasi jumlah replika yang diinginkan bergantung pada akurasi jumlah replika saat ini, nilai metrik saat ini, dan nilai metrik yang diinginkan. Misalnya, pertimbangkan metrik resource, yang banyak digunakan dalam HPA. Untuk mendapatkan jumlah replika saat ini, HPA pertama-tama mengambil subResources scale subResources dari objek yang didefinisikan dalam scaleTargetRef. HPA kemudian mengonversi nilai Selector dari status objek scale menjadi labelselector dan menggunakan selektor tersebut untuk mencocokkan serta mengambil Pod. Jika beberapa Pod yang diambil tidak termasuk dalam objek yang didefinisikan dalam scaleTargetRef, jumlah replika yang diinginkan yang dihitung mungkin tidak akurat. Misalnya, HPA mungkin melakukan scale-out meskipun nilai metrik real-time berada di bawah ambang batas.

    Alasan umum jumlah Pod yang cocok tidak akurat meliputi:

    • Penyebaran bergulir.

    • Label yang sama diterapkan pada Pod yang tidak termasuk dalam objek di scaleTargetRef. Anda dapat menjalankan perintah berikut untuk menentukan apakah Pod lain dengan label ini ada.

      kubectl get pods -n {namespace_name} -l {value_of_status.Selector_for_scale_subresource}

    Solusi

    • Untuk solusi terkait penyebaran bergulir, lihat FAQ autoscaling node.

    • Jika masalah disebabkan oleh Pod lain yang menggunakan label yang sama, temukan Pod tersebut. Ubah labelnya jika masih diperlukan, atau hapus jika tidak diperlukan.

    Dapatkah saya mengontrol urutan scale-in Pod saat HPA melakukan penskalaan turun?

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

    Dalam skenario seperti penerapan campuran ECS dan ACS/ECI atau kelompok node ganda, Anda dapat menentukan prioritas scale-in dengan mengonfigurasi ResourcePolicy untuk aplikasi. HPA dapat bekerja sama dengan deployment dan ResourcePolicy untuk melepaskan sumber daya node ACS/ECI terlebih dahulu, lalu sumber daya ECS, selama scale-in. Untuk informasi lebih lanjut, lihat Sesuaikan prioritas penjadwalan sumber daya elastis.

    Apa arti satuan untuk metrik penggunaan HPA?

    Metrik penggunaan biasanya berupa bilangan bulat, yang bisa tanpa satuan atau menggunakan m sebagai satuan. Dalam kasus terakhir, 1000m sama dengan 1. Misalnya, nilai tcp_connection_counts sebesar 70000m setara dengan 70.

    Apa yang harus saya lakukan jika perintah kubectl get hpa mengembalikan target sebagai unknown?

    Ikuti langkah-langkah berikut untuk mengatasi masalah ini.

    1. Jalankan perintah kubectl describe hpa <hpa_name> untuk menemukan penyebab kegagalan Horizontal Pod Autoscaler (HPA).

      • Jika kolom Conditions menunjukkan bahwa AbleToScale bernilai False, verifikasi bahwa deployment benar.

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

    2. Jalankan perintah 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 komponen alibaba-cloud-metrics-adapter.

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

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

      • namespace: Namespace dari Ingress.

      • svc: Nama layanan Ingress.

      • port: Nama port layanan 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

    Queries per second (QPS) untuk IngressRoute yang ditentukan.

    sls.ingress.route

    sls_alb_ingress_qps

    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 Ingress.

    sls.ingress.route

    Bagaimana cara menyesuaikan sistem setelah menyesuaikan format log Nginx Ingress?

    Untuk informasi lebih lanjut tentang cara menggunakan metrik Ingress Simple Log Service (SLS) untuk penskalaan otomatis pod horizontal, lihat Gunakan metrik dari komponen Alibaba Cloud untuk penskalaan otomatis pod horizontal. Anda harus mengaktifkan dan mengonfigurasi pengumpulan log Nginx Ingress untuk SLS 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.

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

    • Untuk menyesuaikan format log Nginx Ingress, Anda harus memodifikasi bagian processor_regex dari ekspresi reguler dalam konfigurasi Custom Resource Definition (CRD). Hal ini karena CRD AliyunLogConfig, yang diterapkan saat Anda mengaktifkan Simple Log Service di kluster, hanya mendukung format log default dari controller Ingress ACK. Untuk informasi lebih lanjut, lihat Gunakan DaemonSet CRD untuk mengumpulkan log kontainer.

    Bagaimana cara mendapatkan metrik QPS sls_ingress_qps dari command line?

    Anda dapat mengkueri metrik dari command line. Contoh berikut menunjukkan cara 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

    Dalam perintah tersebut, {{SLS_Project}} menentukan nama proyek SLS yang sesuai dengan kluster ACK Anda. Jika Anda belum menyesuaikan konfigurasi, nama defaultnya adalah k8s-log-{{ClusterId}}, di mana {{ClusterId}} adalah ID kluster Anda.

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

    Hasil ini menunjukkan bahwa tidak ada data yang tersedia untuk metrik tersebut. Hal ini mungkin karena Anda mengkueri metrik `sls_alb_ingress_qps` tetapi belum mengonfigurasi ALB Ingress.

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

    Hasil ini menunjukkan bahwa metrik eksternal Kubernetes untuk QPS ditemukan. Kolom value merepresentasikan nilai QPS.

    Gagal menarik citra alibaba-cloud-metrics-adapter

    Gejala

    Saat Anda meningkatkan komponen ack-alibaba-cloud-metrics-adapter ke versi 1.3.7, terjadi kesalahan saat menarik citra. Pesan kesalahan sebagai berikut:

    Gagal menarik citra "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 peningkatan langsung.

    Solusi

    Ikuti langkah-langkah berikut untuk meningkatkan komponen.

    1. Buat cadangan konfigurasi komponen saat ini.

    2. Uninstal versi lama komponen.

    3. Instal versi terbaru komponen menggunakan konfigurasi cadangan.

    Penting

    Selama proses uninstall dan reinstall komponen, perilaku penskalaan HPA yang terkait dijeda karena pengambilan data pemantauan dihentikan.