Memecahkan masalah penskalaan otomatis Pod horizontal

Jika penskalaan otomatis Pod horizontal tidak berfungsi seperti yang diharapkan di Google Kubernetes Engine (GKE), workload Anda mungkin tidak diskalakan dengan benar. Masalah ini dapat mencegah aplikasi menangani beban, yang dapat menyebabkan masalah performa atau gangguan. Anda mungkin melihat Pod tidak bertambah meskipun CPU tinggi, nilai metrik ditampilkan sebagai <unknown> dalam status HorizontalPodAutoscaler, atau operasi penskalaan tidak terjadi sama sekali.

Gunakan dokumen ini untuk mendiagnosis dan menyelesaikan masalah umum terkait penskalaan otomatis Pod horizontal, mulai dari kesalahan konfigurasi awal pada objek HorizontalPodAutoscaler hingga kegagalan yang lebih kompleks dalam pipeline metrik. Dengan mengikuti langkah-langkah pemecahan masalah ini, Anda dapat membantu memastikan bahwa aplikasi Anda diskalakan secara efisien dan andal berdasarkan permintaan, sehingga memanfaatkan resource HorizontalPodAutoscaler secara efektif.

Informasi ini penting bagi developer Aplikasi yang mengonfigurasi objek HorizontalPodAutoscaler dan perlu memastikan aplikasi mereka diskalakan dengan benar. Fitur ini juga membantu admin dan operator Platform memecahkan masalah pada pipeline metrik atau konfigurasi cluster yang memengaruhi semua workload yang diskalakan otomatis. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami rujuk dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

Sebelum memulai

  • Pastikan Anda menggunakan objek HorizontalPodAutoscaler dengan workload yang dapat diskalakan, seperti Deployment dan StatefulSet. Anda tidak dapat menggunakan penskalaan otomatis Pod horizontal dengan workload yang tidak dapat diskalakan, misalnya, DaemonSets.

  • Untuk mendapatkan izin yang diperlukan guna memecahkan masalah penskalaan otomatis Pod horizontal di GKE, yang mencakup memeriksa objek HorizontalPodAutoscaler dan melihat log cluster, minta administrator untuk memberi Anda peran IAM berikut pada project Anda:

    • Periksa resource GKE: GKE Viewer (roles/container.viewer)
    • Melihat log cluster: Logs Viewer (roles/logging.viewer)

    Untuk mengetahui informasi selengkapnya tentang pemberian peran, lihat Mengelola akses ke project, folder, dan organisasi.

    Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

  • Konfigurasi alat command line kubectl untuk berkomunikasi dengan cluster GKE Anda:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster Anda.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.
    • PROJECT_ID: Google Cloud Project ID Anda.

Mendiagnosis masalah HorizontalPodAutoscaler

Untuk mendiagnosis masalah pada HorizontalPodAutoscaler, periksa status dan konfigurasi menggunakan perintah kubectl atau konsol Google Cloud .

Mendeskripsikan HorizontalPodAutoscaler

Untuk melihat perhitungan real-time dan keputusan penskalaan terbaru, gunakan perintah kubectl describe hpa:

kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

Ganti kode berikut:

  • HPA_NAME: nama objek HorizontalPodAutoscaler Anda.
  • NAMESPACE_NAME: namespace objek HorizontalPodAutoscaler Anda.

Outputnya mirip dengan hal berikut ini:

Name:                                                  php-apache-hpa
Namespace:                                             default
Reference:                                             Deployment/php-apache
Metrics: ( current / target )
  resource cpu on pods (as a percentage of request):   1% (1m) / 50%
Min replicas:                                          1
Max replicas:                                          10
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HorizontalPodAutoscaler was able to successfully calculate a replica count
Events:
  Type     Reason              Age   From                       Message
  ----     ------              ----  ----                       -------
  Normal   SuccessfulRescale   39m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization...
  Normal   SuccessfulRescale   26m   horizontal-pod-autoscaler  New size: 1; reason: cpu resource utilization...

Dalam output, tiga bagian berikut akan membantu Anda mendiagnosis masalah:

  • Metrics: menampilkan nilai metrik saat ini dibandingkan dengan targetnya. Nilai metrik <unknown> menunjukkan bahwa HorizontalPodAutoscaler belum mengambil metrik atau pipeline metrik rusak.
  • Conditions: menunjukkan apakah HorizontalPodAutoscaler dapat mengambil metrik (AbleToScale) dan melakukan penghitungan penskalaan (ScalingActive). Status False dalam salah satu kondisi ini menunjukkan kegagalan.
  • Events: mencatat tindakan penskalaan, peringatan, dan error terbaru dari pengontrol HorizontalPodAutoscaler. Bagian ini sering kali menjadi tempat pertama untuk menemukan pesan atau alasan error tertentu, seperti FailedGetScale atau FailedGetResourceMetric.

Periksa manifes HorizontalPodAutoscaler Anda

Manifes YAML objek HorizontalPodAutoscaler memungkinkan Anda melihat informasi tentang konfigurasinya dan statusnya saat ini.

Untuk melihat manifes YAML, pilih salah satu opsi berikut:

Konsol

  1. Di konsol Google Cloud , buka halaman Object Browser.

    Buka Object Browser

  2. Dalam daftar Object Kinds, centang kotak HorizontalPodAutoscaler lalu klik OK.

  3. Buka grup API autoscaling, lalu klik panah peluas untuk HorizontalPodAutoscaler.

  4. Klik nama objek HorizontalPodAutoscaler yang ingin Anda periksa.

  5. Tinjau bagian YAML, yang menampilkan konfigurasi lengkap objek HorizontalPodAutoscaler.

kubectl

Jalankan perintah berikut:

kubectl get hpa HPA_NAME -n NAMESPACE_NAME -o yaml

Ganti kode berikut:

  • HPA_NAME: nama objek HorizontalPodAutoscaler Anda.
  • NAMESPACE_NAME: namespace objek HorizontalPodAutoscaler Anda.

Setelah mengambil manifes, cari bagian utama berikut:

  • spec (konfigurasi Anda):
    • scaleTargetRef: workload (seperti Deployment) yang dikonfigurasi oleh HorizontalPodAutoscaler untuk diskalakan.
    • minReplicas dan maxReplicas: setelan replika minimum dan maksimum.
    • metrics: metrik yang dikonfigurasi untuk penskalaan (misalnya, penggunaan CPU atau metrik kustom).
  • status (status aktif HorizontalPodAutoscaler):
    • currentMetrics: nilai metrik terbaru yang telah diamati HorizontalPodAutoscaler.
    • currentReplicas dan desiredReplicas: jumlah Pod saat ini dan jumlah yang ingin diskalakan oleh HorizontalPodAutoscaler.
    • conditions: menampilkan kondisi HorizontalPodAutoscaler:
      • AbleToScale: menunjukkan apakah HorizontalPodAutoscaler dapat menemukan target dan metriknya.
      • ScalingActive: menunjukkan apakah HorizontalPodAutoscaler diizinkan untuk menghitung dan melakukan penskalaan.
      • ScalingLimited: menunjukkan apakah HorizontalPodAutoscaler ingin melakukan penskalaan, tetapi dibatasi oleh setelan minReplicas atau maxReplicas Anda.

Melihat log peristiwa

Untuk mendapatkan insight yang lebih mendalam tentang objek HorizontalPodAutoscaler, gunakan jenis log berikut:

  • Melihat peristiwa HorizontalPodAutoscaler di Cloud Logging: gunakan filter log untuk menemukan semua peristiwa HorizontalPodAutoscaler untuk cluster tertentu. Contoh:

    1. Di konsol Google Cloud , buka halaman Logs Explorer.

      Buka Logs Explorer

    2. Di panel kueri, masukkan kueri berikut:

      resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
logName="projects/PROJECT_ID/logs/events"
jsonPayload.involvedObject.kind="HorizontalPodAutoscaler"

      Ganti kode berikut:

      • CLUSTER_NAME: nama cluster tempat HorizontalPodAutoscaler berada.
      • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.
      • PROJECT_ID: project ID Anda.

    3. Klik Run query dan tinjau outputnya.

  • Melihat peristiwa penskalaan otomatis Pod horizontal: log ini memberikan log terstruktur yang mudah dibaca dan menjelaskan cara HorizontalPodAutoscaler menghitung rekomendasi, sehingga memberikan insight mendetail tentang proses pengambilan keputusannya.

Memecahkan masalah error konfigurasi HorizontalPodAutoscaler

Bagian berikut membahas kesalahan konfigurasi dalam manifes HorizontalPodAutoscaler, seperti kolom yang salah ketik, target metrik yang tidak valid, atau konfigurasi yang bertentangan.

Target workload tidak ditemukan

Gejala

Bagian Events memiliki kondisi FailedGetScale dengan pesan yang mirip dengan berikut ini:

the HorizontalPodAutoscaler controller was unable to get the target's current scale: WORKLOAD_TYPE.apps "TARGET_WORKLOAD" not found

Output ini mencakup nilai-nilai berikut:

  • WORKLOAD_TYPE: jenis beban kerja, seperti Deployment atau StatefulSet.
  • TARGET_WORKLOAD: nama workload.

Penyebab

Pengontrol HorizontalPodAutoscaler tidak dapat menemukan workload (seperti Deployment atau StatefulSet) yang dikonfigurasi untuk dikelola. Masalah ini terjadi karena kesalahan konfigurasi di kolom scaleTargetRef dalam manifes HorizontalPodAutoscaler. Resource yang ditentukan mungkin tidak ada, mungkin telah dihapus, atau mungkin salah eja.

Resolusi

Coba solusi berikut:

  1. Verifikasi kolom scaleTargetRef pada manifes HorizontalPodAutoscaler: pastikan nilai name, kind, dan apiVersion di kolom scaleTargetRef sama persis dengan metadata yang sesuai dari target workload Anda. Jika nama beban kerja salah, perbarui kolom scaleTargetRef HorizontalPodAutoscaler untuk mengarah ke nama yang benar.
  2. Konfirmasi bahwa workload ada: verifikasi bahwa workload target ada di namespace yang sama dengan HorizontalPodAutoscaler. Anda dapat memeriksanya dengan perintah seperti kubectl get deployment DEPLOYMENT_NAME. Jika Anda menghapus beban kerja secara sengaja, hapus objek HorizontalPodAutoscaler yang sesuai untuk membersihkan cluster Anda. Jika Anda perlu membuat ulang workload, HorizontalPodAutoscaler akan otomatis menemukannya setelah tersedia, dan error akan teratasi.
  3. Periksa apakah HorizontalPodAutoscaler dan workload berada di namespace yang sama: HorizontalPodAutoscaler dan target workload-nya harus berada di namespace yang sama. Jika Anda lupa menentukan namespace saat membuat objek dengan perintah kubectl, Kubernetes akan menempatkan objek di namespace default. Perilaku ini dapat menyebabkan ketidakcocokan jika HorizontalPodAutoscaler Anda berada di namespace default dan workload Anda berada di namespace lain, atau sebaliknya. Periksa namespace untuk kedua objek dan verifikasi bahwa keduanya cocok.

Setelah HorizontalPodAutoscaler berhasil menemukan targetnya, kondisi AbleToScale akan menjadi True, dan pesan akan berubah menjadi: the HorizontalPodAutoscaler controller was able to get the target's current scale.

Metrik tidak valid

Gejala

Jika HorizontalPodAutoscaler tidak dapat menghitung replika yang diperlukan karena masalah konfigurasi, bagian Events-nya akan menampilkan alasan FailedComputeMetricsReplicas dengan pesan yang mirip dengan berikut ini:

invalid metrics (1 invalid out of 1)

Penyebab

Error ini biasanya berarti ada ketidakcocokan antara metrik type dan target yang Anda tentukan dalam manifes HorizontalPodAutoscaler. Misalnya, Anda mungkin telah menentukan type sebesar Utilization, tetapi memberikan nilai target averageValue, bukan averageUtilization.

Resolusi

Perbaiki manifes HorizontalPodAutoscaler sehingga nilai kolom target sesuai dengan metrik type:

  • Jika type adalah Utilization, nilai di kolom target harus averageUtilization.
  • Jika type adalah AverageValue, nilai di kolom target harus averageValue.

Label metrik tidak diizinkan

Gejala

Anda melihat error berikut:

unable to fetch metrics from external metrics API: googleapi: Error 400: Metric label: 'LABEL_NAME' is not allowed

Dalam output ini, LABEL_NAME adalah nama label yang salah.

Penyebab

Manifes HorizontalPodAutoscaler menentukan kunci label yang tidak valid di bagian metric.selector.matchLabels dan Cloud Monitoring tidak mengenali atau mengizinkan kunci ini untuk metrik.

Resolusi

Untuk mengatasi masalah ini, lakukan langkah berikut:

  1. Identifikasi nama label yang tidak diizinkan dari pesan error.
  2. Hapus atau perbaiki kunci label ini di bagian metric.selector.matchLabels pada manifes HorizontalPodAutoscaler Anda.
  3. Temukan kunci label yang valid dan dapat difilter dengan melihat dokumentasi Cloud Monitoring untuk metrik tersebut.

Beberapa HorizontalPodAutoscaler menargetkan workload yang sama

Gejala

Tidak ada Condition atau Reason tertentu dalam status HorizontalPodAutoscaler yang secara langsung menunjukkan konflik ini. Sebagai gantinya, Anda mungkin mengalami gejala berikut:

  • Jumlah replika workload dapat berfluktuasi secara tidak terduga.
  • Keputusan penskalaan mungkin tidak tampak sesuai dengan metrik yang ditentukan dalam satu HorizontalPodAutoscaler.
  • Saat melihat peristiwa, Anda mungkin melihat peristiwa SuccessfulRescale yang bergantian atau bertentangan dari objek HorizontalPodAutoscaler yang berbeda.

Penyebab

Masalah ini terjadi karena lebih dari satu objek HorizontalPodAutoscaler dalam namespace yang sama menentukan beban kerja yang sama persis di kolom spec.scaleTargetRef. Setiap HorizontalPodAutoscaler secara independen menghitung jumlah replika dan mencoba menskalakan workload berdasarkan kumpulan metrik dan targetnya sendiri. Kubernetes tidak memblokir konfigurasi ini, tetapi menyebabkan penyesuaian penskalaan yang tidak menentu karena HorizontalPodAutoscaler bersaing satu sama lain.

Resolusi

Untuk menghindari konflik, tentukan semua metrik penskalaan dalam satu objek HorizontalPodAutoscaler. Setiap HorizontalPodAutoscaler menghitung kebutuhan penskalaan dari kolom spec.metrics-nya sendiri, sehingga penggabungannya memungkinkan objek HorizontalPodAutoscaler yang dipilih mempertimbangkan semua faktor, seperti CPU dan permintaan per detik, secara bersamaan:

  1. Untuk mengidentifikasi HorizontalPodAutoscaler mana yang menargetkan workload yang sama, dapatkan manifes YAML untuk setiap objek HorizontalPodAutoscaler. Perhatikan baik-baik kolom spec.scaleTargetRef di output.

    kubectl get hpa -n NAMESPACE_NAME -o yaml

    Ganti NAMESPACE_NAME dengan namespace objek HorizontalPodAutoscaler Anda.

    Cari instance apa pun yang memiliki nilai yang sama untuk apiVersion, kind, dan name dalam kolom scaleTargetRef-nya di berbagai resource HorizontalPodAutoscaler.

  2. Menggabungkan metrik ke dalam satu objek HorizontalPodAutoscaler:

    1. Pilih satu objek HorizontalPodAutoscaler yang akan dipertahankan. HorizontalPodAutoscaler ini akan menjadi yang Anda ubah.
    2. Periksa bagian spec.metrics dalam manifes setiap objek HorizontalPodAutoscaler lainnya yang menargetkan workload yang sama.
    3. Salin definisi metrik yang ingin Anda pertahankan dari bagian spec.metrics objek HorizontalPodAutoscaler duplikat.
    4. Tempelkan definisi metrik yang disalin ini ke dalam array spec.metrics dari HorizontalPodAutoscaler yang Anda putuskan untuk dipertahankan.

  3. Terapkan perubahan Anda:

    kubectl apply -f MANIFEST_NAME

    Ganti MANIFEST_NAME dengan nama manifes HorizontalPodAutoscaler yang Anda putuskan untuk dipertahankan.

  4. Hapus objek HorizontalPodAutoscaler lainnya yang menargetkan workload yang sama:

    kubectl delete hpa DUPLICATE_MANIFEST_NAME -n NAMESPACE_NAME

    Ganti DUPLICATE_MANIFEST_NAME dengan nama objek HorizontalPodAutoscaler yang berlebihan yang ingin Anda hapus.

Memecahkan masalah error workload dan Layanan

Bagian berikut membahas error yang disebabkan oleh beban kerja target atau Layanan terkaitnya, bukan objek HorizontalPodAutoscaler itu sendiri.

Permintaan resource tidak ada untuk penghitungan penskalaan

Gejala

Kondisi ScalingActive adalah False dengan Reason FailedGetResourceMetric. Biasanya Anda juga akan melihat pesan yang mirip dengan berikut:

the HorizontalPodAutoscaler was unable to compute the replica count

Penyebab

HorizontalPodAutoscaler perlu menghitung pemanfaatan resource sebagai persentase untuk menskalakan workload, tetapi tidak dapat melakukan perhitungan ini karena setidaknya satu container dalam spesifikasi Pod tidak memiliki definisi resources.requests untuk resource yang sesuai (cpu atau memory).

Resolusi

Untuk mengatasi masalah ini, perbarui manifes Pod dalam Deployment, StatefulSet, atau pengontrol lainnya untuk menyertakan kolom resources.requests bagi resource (cpu atau memory) yang coba diskalakan HorizontalPodAutoscaler untuk semua container dalam Pod. Contoh:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
# Multiple lines are omitted here
spec:
  containers:
  - name: example-container
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Tidak dapat mengambil metrik Pod

Gejala

Anda akan melihat pesan persisten yang mirip dengan berikut ini:

unable to fetch pod metrics for pod

Wajar jika Anda melihat pesan ini untuk sementara saat server metrik mulai dijalankan.

Penyebab

Untuk melakukan penskalaan berdasarkan persentase penggunaan resource (seperti cpu atau memory), setiap container dalam Pod yang ditargetkan oleh objek HorizontalPodAutoscaler harus memiliki kolom resources.requests yang ditentukan untuk resource tertentu tersebut. Jika tidak, HorizontalPodAutoscaler tidak dapat melakukan penghitungan yang diperlukan, dan tidak mengambil tindakan terkait metrik tersebut.

Resolusi

Jika pesan error ini terus muncul dan Anda melihat bahwa Pod tidak diskalakan untuk workload, pastikan Anda telah menentukan permintaan resource untuk setiap container dalam workload.

Beberapa layanan memilih target yang sama

Gejala

Anda melihat error berikut:

multiple services selecting the same target of HPA_NAME: SERVICE_NAME

Output ini mencakup nilai-nilai berikut:

  • HPA_NAME: nama HorizontalPodAutoscaler.
  • SERVICE_NAME: nama Layanan.

Penyebab

Penskalaan otomatis berbasis traffic dikonfigurasi, tetapi lebih dari satu Layanan Kubernetes menargetkan kolom scaleTargetRef HorizontalPodAutoscaler. Penskalaan otomatis berbasis traffic hanya mendukung hubungan satu-ke-satu antara Layanan dan workload yang diskalakan otomatis.

Resolusi

Untuk memperbaiki masalah ini, pastikan hanya satu pemilih label Service yang cocok dengan Pod beban kerja Anda:

  1. Temukan label Pod workload Anda:

    kubectl get deployment HPA_TARGET_DEPLOYMENT \
    -n NAMESPACE \
    -o jsonpath='{.spec.template.metadata.labels}'

    Ganti kode berikut:

    • HPA_TARGET_DEPLOYMENT: nama Deployment yang ditargetkan oleh HorizontalPodAutoscaler.
    • NAMESPACE: namespace Deployment.

    Outputnya mirip dengan hal berikut ini:

    {"app":"my-app", "env":"prod"}

  2. Temukan semua Layanan yang cocok dengan label tersebut dengan meninjau kolom spec.selector untuk semua Layanan di namespace.

    kubectl get services -n NAMESPACE -o yaml

    Identifikasi setiap Layanan yang pemilihnya cocok dengan label dari langkah sebelumnya. Misalnya, {"app": "my-app"} dan {"app": "my-app", "env": "prod"} cocok dengan contoh label Pod.

  3. Selesaikan konflik dengan memilih salah satu opsi berikut:

    • Buat pemilih Layanan yang dimaksud menjadi unik dengan menambahkan label baru yang unik ke kolom spec.template.metadata.labels Deployment Anda. Kemudian, perbarui kolom spec.selector one Layanan yang dimaksud untuk menyertakan label baru ini.
    • Buat pemilih Service lainnya lebih ketat dengan mengubah kolom spec.selector dari semua Service yang bertentangan lainnya sehingga menjadi lebih ketat dan tidak lagi cocok dengan Pod beban kerja Anda.

  4. Terapkan perubahan Anda:

    kubectl apply -f MANIFEST_NAME

    Ganti MANIFEST_NAME dengan nama file YAML yang berisi manifes Service atau Deployment yang telah diperbarui.

Memecahkan masalah API metrik dan ketersediaan data

Bagian berikut membantu Anda mengatasi error yang terjadi saat HorizontalPodAutoscaler mencoba berkomunikasi dengan API metrik atau membuat kueri backend metrik.

Memecahkan masalah metrik kustom dan eksternal

Jika HorizontalPodAutoscaler Anda mengandalkan metrik dari sumber selain CPU atau memori default, masalah dapat terjadi dalam pipeline metrik kustom atau eksternal. Pipeline ini terdiri dari pengontrol HorizontalPodAutoscaler, server API metrik Kubernetes, adaptor metrik, dan sumber metrik (misalnya, Cloud Monitoring atau Prometheus) seperti yang ditunjukkan dalam diagram berikut:

Pipeline metrik HPA yang menampilkan komponen: pengontrol HPA, server Kubernetes API, adaptor metrik, dan sumber metrik.

Gejala

Gejala paling umum dari masalah dalam pipeline metrik adalah sebagai berikut:

  • Nilai metrik ditampilkan sebagai <unknown>.
  • Peristiwa HorizontalPodAutoscaler menampilkan error seperti FailedGetExternalMetric atau FailedGetCustomMetric.

Penyebab

Ada masalah dalam pipeline metrik kustom atau eksternal.

Resolusi

Gunakan langkah-langkah berikut untuk membantu Anda men-debug pipeline:

  1. Periksa apakah adaptor metrik terdaftar dan tersedia: adaptor metrik harus mendaftarkan dirinya ke server Kubernetes API utama untuk menayangkan metrik. Tindakan ini adalah cara paling langsung untuk melihat apakah adaptor berjalan dan dapat dijangkau oleh server API:

    kubectl get apiservice | grep -E 'NAME|metrics.k8s.io'

    Dalam output, Anda akan melihat entri v1beta1.custom.metrics.k8s.io atau v1beta1.external.metrics.k8s.io dan nilai True di kolom Available. Contoh:

    NAME                   SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io kube-system/metrics-server   True        18d

    • Jika nilai di kolom Available adalah False atau tidak ada, kemungkinan adaptor Anda mengalami error atau salah dikonfigurasi. Periksa log Pod adapter di namespace kube-system atau custom-metrics untuk mengetahui error terkait izin, konektivitas jaringan ke sumber metrik, atau pesan yang menunjukkan bahwa metrik tidak dapat ditemukan.

    • Jika nilainya True, lanjutkan ke langkah berikutnya.

  2. Kueri Metrics API secara langsung: jika adapter tersedia, lewati HorizontalPodAutoscaler dan minta metrik Anda langsung dari Kubernetes API. Perintah ini menguji seluruh pipeline, dari server API ke adaptor metrik hingga sumber data.

    Untuk membuat kueri metrik eksternal, jalankan perintah berikut:

    kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/METRIC_NAME" | jq .

    Untuk membuat kueri metrik Pod kustom, jalankan perintah berikut:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/pods/*/METRIC_NAME" | jq .

    Ganti kode berikut:

    • NAMESPACE_NAME: namespace tempat Pod Anda berjalan.
    • METRIC_NAME: nama metrik kustom atau eksternal yang ingin Anda kueri. Misalnya, requests_per_second atau queue_depth.

  3. Analisis output perintah: hasil perintah sebelumnya memberi tahu Anda letak masalahnya. Pilih skenario yang cocok dengan output Anda:

    • Respons JSON yang berhasil dengan nilai: pipeline metrik berfungsi dengan benar. Masalah ini kemungkinan merupakan masalah konfigurasi dalam manifes HorizontalPodAutoscaler Anda. Periksa kesalahan ejaan dalam nama metrik atau matchLabels yang salah.

    • Error: Error from server (Service Unavailable): error ini biasanya menunjukkan masalah konektivitas jaringan, yang sering kali merupakan masalah firewall di cluster yang menggunakan isolasi jaringan.

      1. Identifikasi Layanan adaptor metrik. Biasanya ada di ruang nama custom-metrics atau kube-system:

        kubectl get service -n custom-metrics,kube-system | grep -E 'adapter|metrics'

      2. Temukan port yang diproses adaptor:

        kubectl get service ADAPTER_SERVICE -n ADAPTER_NAMESPACE -o yaml

        Ganti kode berikut:

        • ADAPTER_SERVICE: nama Layanan Kubernetes yang terkait dengan adaptor metrik yang Anda deploy. Service ini adalah Service yang Anda temukan di langkah sebelumnya. Layanan ini mengekspos fungsi adaptor ke bagian lain cluster, termasuk server Kubernetes API.
        • ADAPTER_NAMESPACE: namespace tempat layanan adapter berada (misalnya, custom-metrics atau kube-system).

      3. Temukan aturan firewall masuk untuk bidang kontrol cluster Anda:

        gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master"

        Ganti CLUSTER_NAME dengan nama cluster Anda.

      4. Tambahkan targetPort adaptor ke aturan:

        1. Jelaskan aturan saat ini untuk melihat port yang diizinkan:

          gcloud compute firewall-rules describe FIREWALL_RULE_NAME

          Ganti FIREWALL_RULE_NAME dengan nama aturan firewall yang mengatur traffic jaringan ke bidang kontrol cluster Kubernetes Anda.

        2. Perbarui aturan untuk menambahkan port adaptor ke daftar:

          gcloud compute firewall-rules update FIREWALL_RULE_NAME \
    --allow tcp:443,tcp:10250,tcp:ADAPTER_PORT

          Ganti ADAPTER_PORT dengan port jaringan yang diproses adaptor metrik.

      5. Pastikan Kebijakan Jaringan Kubernetes tidak memblokir traffic ke Pod adaptor metrik:

        kubectl get networkpolicy -n custom-metrics,kube-system

        Tinjau kebijakan apa pun untuk memverifikasi bahwa kebijakan tersebut mengizinkan traffic masuk dari bidang kontrol atau server API ke ADAPTER_SERVICE di ADAPTER_PORT.

    • Daftar kosong []: output ini berarti adaptor sedang berjalan, tetapi tidak dapat mengambil metrik tertentu, yang menunjukkan adanya masalah pada konfigurasi adaptor atau sumber metrik itu sendiri.

      • Masalah Pod Adapter: periksa log Pod atau Pod metrik adapter untuk mengetahui error terkait panggilan API, autentikasi, atau pengambilan metrik. Untuk memeriksa log, lakukan hal berikut:

        1. Temukan nama Pod adaptor:

          kubectl get pods -n ADAPTER_NAMESPACE

        2. Melihat lognya:

          kubectl logs ADAPTER_POD_NAME \
    -n ADAPTER_NAMESPACE

          Ganti kode berikut:

          • ADAPTER_POD_NAME: nama Pod adapter yang Anda identifikasi di langkah sebelumnya.
          • ADAPTER_NAMESPACE: namespace tempat Pod adapter berada (misalnya, custom-metrics atau kube-system).

      • Tidak ada data di sumber: metrik mungkin tidak ada di sistem sumber. Gunakan alat pemantauan, seperti Metrics Explorer, untuk mengonfirmasi bahwa metrik ada dan memiliki nama serta label yang benar.

Versi metrik tidak ditemukan atau adaptor tidak tersedia

Gejala

Anda melihat error berikut:

unable to fetch metrics from custom metrics API: no known available metric versions found

Penyebab

Error ini menunjukkan gangguan komunikasi dalam cluster, bukan masalah pada sumber metrik (seperti Cloud Monitoring). Penyebab umumnya meliputi hal-hal berikut:

  • Server Kubernetes API tidak tersedia untuk sementara (misalnya, selama upgrade cluster atau perbaikan bidang kontrol).
  • Pod adaptor metrik (misalnya, custom-metrics-stackdriver-adapter) tidak sehat, tidak berjalan, atau tidak terdaftar dengan benar di server API.

Resolusi

Masalah ini sering kali bersifat sementara. Jika masalah berlanjut, coba solusi berikut:

  1. Periksa kondisi bidang kontrol Kubernetes:

    1. Di konsol Google Cloud , lihat kesehatan dan status cluster Anda.

      1. Buka halaman cluster Kubernetes.

        Buka cluster Kubernetes

    2. Periksa kolom Status dan Notifikasi untuk cluster Anda.

    3. Klik Notifikasi untuk mencari operasi yang sedang berlangsung seperti upgrade atau perbaikan. Server API mungkin tidak tersedia sebentar selama waktu ini.

    4. Tinjau Cloud Audit Logs untuk menemukan error terkait komponen bidang kontrol. Untuk mengetahui informasi tentang cara melihat log ini, lihat Informasi logging audit GKE.

  2. Periksa kondisi dan log Pod adaptor metrik: pastikan Pod adaptor metrik berstatus Running dan tidak memulai ulang baru-baru ini:

    kubectl get pods -n custom-metrics,kube-system -o wide

    Jika status Pod selain Running, atau memiliki jumlah mulai ulang yang tinggi, selidiki Pod untuk menemukan penyebab utamanya. Untuk mengetahui tips pemecahan masalah, lihat Debug Pod dalam dokumentasi Kubernetes.

  3. Pastikan bahwa API metrik terdaftar dan tersedia:

    kubectl get apiservice | grep metrics.k8s.io

    Jika API metrik responsif, outputnya akan mirip dengan berikut ini:

    NAME                            SERVICE                                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io   custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.external.metrics.k8s.io custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.metrics.k8s.io          kube-system/metrics-server                          True        18d

    Jika kolom AVAILABLE memiliki nilai False, kolom Message dalam manifes APIService lengkap mungkin memberikan detail selengkapnya.

    Anda dapat melihat manifes lengkap dengan perintah berikut:

    kubectl get apiservice API_SERVICE_NAME -o yaml

    Ganti API_SERVICE_NAME dengan nama objek APIService, seperti v1beta1.custom.metrics.k8s.io.

Kueri metrik tidak menampilkan deret waktu

Gejala

Anda melihat error berikut:

unable to fetch metrics from custom or external metrics API: googleapi: Error
400: The supplied filter [...] query will not return any time series

Penyebab

Kueri yang dikirim ke Cloud Monitoring valid, tetapi tidak menampilkan data. Artinya, tidak ada titik data yang cocok dengan filter Anda (yang berbeda dengan menemukan metrik dengan nilai 0). Kemungkinan besar, masalah ini terjadi karena aplikasi atau beban kerja yang bertanggung jawab untuk membuat metrik kustom tidak menulis data ke Cloud Monitoring selama waktu saat error dilaporkan.

Resolusi

Coba solusi berikut:

  1. Verifikasi konfigurasi: pastikan nama dan label metrik di objek HorizontalPodAutoscaler Anda sama persis dengan yang dikeluarkan oleh aplikasi.
  2. Periksa izin: pastikan aplikasi dikonfigurasi dengan benar dengan izin dan endpoint API yang diperlukan untuk memublikasikan metrik ke Cloud Monitoring.
  3. Konfirmasi aktivitas aplikasi: verifikasi bahwa aplikasi yang bertanggung jawab atas metrik tersebut beroperasi dan mencoba mengirim data ke Cloud Monitoring selama periode waktu saat peringatan HorizontalPodAutoscaler terjadi.
  4. Selidiki error: periksa log aplikasi dari jangka waktu yang sama untuk mengetahui error eksplisit terkait emisi metrik, seperti kegagalan koneksi, kredensial tidak valid, atau masalah pemformatan.

Memecahkan masalah perilaku penskalaan yang responsif tetapi tidak terduga

Bagian berikut membahas skenario saat konfigurasi HorizontalPodAutoscaler valid dan metrik tersedia, tetapi tindakan penskalaan tidak terjadi seperti yang diharapkan.

HorizontalPodAutoscaler dalam kondisi baik, tetapi tidak melakukan penskalaan

Gejala

HorizontalPodAutoscaler tampak berfungsi dengan baik, kondisinya melaporkan True, dan tidak menunjukkan error dalam peristiwanya. Namun, tindakan penskalaan masih belum dilakukan.

Penyebab

Beberapa faktor dapat menyebabkan perilaku yang diharapkan ini:

  • Batas replika: jumlah replika saat ini sudah mencapai batas yang ditetapkan oleh kolom minReplicas atau maxReplicas dalam konfigurasi HorizontalPodAutoscaler.
  • Jendela toleransi: Kubernetes menggunakan jendela toleransi default sebesar 10% untuk mencegah penskalaan pada fluktuasi metrik kecil. Penskalaan hanya terjadi jika rasio metrik saat ini terhadap metrik target berada di luar rentang 0,9 hingga 1,1. Misalnya, jika targetnya adalah CPU 85% dan penggunaan saat ini adalah 93%, rasionya kira-kira 1,094 (93/85≈1,094). Karena nilai ini kurang dari 1,1, HorizontalPodAutoscaler tidak meningkatkan skala.
  • Pod yang Belum Siap: HorizontalPodAutoscaler hanya menyertakan Pod dengan status Ready dalam perhitungan penskalaannya. Pod yang mengalami masalah dengan status Pending atau tidak menjadi Ready (karena health check gagal atau masalah resource) akan diabaikan dan dapat mencegah penskalaan.
  • Penundaan periode sinkronisasi: pengontrol HorizontalPodAutoscaler memeriksa metrik secara berkala. Penundaan 15-30 detik antara metrik yang melampaui nilai minimum dan inisiasi tindakan penskalaan adalah hal yang normal.
  • Latensi metrik baru: saat HorizontalPodAutoscaler menggunakan metrik kustom baru untuk pertama kalinya, Anda mungkin melihat latensi satu kali selama beberapa menit. Penundaan ini terjadi karena sistem pemantauan (seperti Cloud Monitoring) harus membuat deret waktu baru saat titik data pertama ditulis.
  • Penghitungan beberapa metrik: saat Anda mengonfigurasi beberapa metrik, HorizontalPodAutoscaler menghitung jumlah replika yang diperlukan untuk setiap metrik secara terpisah, lalu memilih nilai penghitungan tertinggi sebagai jumlah replika akhir. Karena perilaku ini, workload Anda akan diskalakan untuk memenuhi permintaan metrik dengan kebutuhan tertinggi. Misalnya, jika metrik CPU menghitung kebutuhan 9 replika, tetapi metrik permintaan per detik menghitung kebutuhan 15, HorizontalPodAutoscaler akan menskalakan Deployment menjadi 15 replika.

Resolusi

Coba solusi berikut:

  • Batas replika: periksa nilai minReplicas dan maxReplicas di manifes HorizontalPodAutoscaler atau di output perintah kubectl describe. Sesuaikan batas ini jika mencegah penskalaan yang diperlukan.
  • Jendela toleransi: jika penskalaan diperlukan dalam toleransi default, konfigurasi nilai toleransi yang berbeda. Jika tidak, tunggu hingga metrik bergerak di luar rasio 0,9 hingga 1,1.
  • Pod yang Belum Siap: selidiki alasan Pod Pending atau tidak Ready dan selesaikan masalah yang mendasarinya (misalnya, batasan resource, pemeriksaan kesiapan gagal). Untuk mengetahui tips pemecahan masalah, lihat Men-debug Pod dalam dokumentasi Kubernetes.
  • Penundaan periode sinkronisasi dan latensi metrik baru: latensi ini normal. Tunggu hingga periode sinkronisasi selesai atau deret waktu metrik kustom baru dibuat.
  • Penghitungan beberapa metrik: ini adalah perilaku yang dimaksudkan. Jika penskalaan terjadi berdasarkan satu metrik (seperti permintaan per detik), penskalaan tersebut akan menggantikan penghitungan metrik lain yang lebih rendah (seperti CPU) dengan benar.

HorizontalPodAutoscaler gagal memperkecil skala

Gejala

HorizontalPodAutoscaler berhasil menskalakan beban kerja, tetapi gagal menskalakannya kembali meskipun metrik seperti pemakaian CPU rendah.

Penyebab

Perilaku ini dirancang untuk mencegah peningkatan dan penurunan skala yang cepat atau penurunan skala berdasarkan informasi yang tidak lengkap. Alasan utamanya adalah sebagai berikut:

  • Menggunakan beberapa metrik: HorizontalPodAutoscaler menskalakan berdasarkan metrik yang memerlukan replika paling banyak. Jika Anda memiliki beberapa metrik, workload tidak akan diperkecil kecuali jika semua metrik menunjukkan bahwa lebih sedikit replika yang diperlukan. Satu metrik yang memerlukan jumlah replika yang tinggi akan mencegah penurunan skala, meskipun metrik lainnya rendah.
  • Metrik tidak tersedia: jika ada metrik yang tidak tersedia (sering ditampilkan sebagai <unknown>), HorizontalPodAutoscaler secara konservatif menolak untuk menurunkan skala workload. Metrik tidak dapat menentukan apakah metrik tidak ada karena penggunaan benar-benar nol atau karena pipeline metrik rusak. Masalah ini umum terjadi pada metrik kustom berbasis rasio (misalnya, messages_per_second), yang dapat berhenti melaporkan data saat tidak ada aktivitas, sehingga HorizontalPodAutoscaler melihat metrik sebagai tidak tersedia dan menghentikan operasi pengecilan skala.
  • Penundaan penurunan skala dari kebijakan penskalaan: kolom behavior HorizontalPodAutoscaler memungkinkan Anda mengonfigurasi kebijakan penskalaan. Kebijakan default untuk penurunan skala mencakup periode stabilisasi 300 detik (lima menit). Selama periode ini, HorizontalPodAutoscaler tidak akan mengurangi jumlah replika, meskipun nilai metrik telah turun di bawah batas target. Jendela ini mencegah fluktuasi yang cepat, tetapi dapat membuat penurunan skala lebih lambat dari yang diharapkan.

Resolusi

Coba solusi berikut:

  1. Untuk beberapa metrik dan metrik yang tidak tersedia, diagnosis metrik yang menyebabkan masalah:

    kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

    Pada output, cari metrik apa pun dengan status <unknown> di bagian Metrics dan peringatan seperti FailedGetCustomMetric atau FailedGetExternalMetric di bagian Events. Untuk men-debug pipeline secara mendetail, lihat bagian Memecahkan masalah metrik kustom dan eksternal.

  2. Untuk metrik yang tidak tersedia, jika metrik menjadi tidak tersedia selama periode traffic rendah (umum terjadi pada metrik berbasis rasio), coba salah satu solusi berikut:

    • Gunakan metrik berbasis pengukur, bukan metrik berbasis rasio jika memungkinkan. Metrik pengukur, seperti jumlah total pesan dalam antrean (misalnya, subscription atau num_undelivered_messages), secara konsisten melaporkan nilai, meskipun nilai tersebut adalah 0, sehingga memungkinkan HorizontalPodAutoscaler membuat keputusan penskalaan secara andal.
    • Pastikan sumber metrik Anda melaporkan nilai nol. Jika Anda mengontrol metrik kustom, konfigurasikan metrik tersebut untuk memublikasikan 0 selama periode tidak ada aktivitas daripada tidak mengirim data sama sekali.

  3. Untuk penundaan penurunan skala dari kebijakan penskalaan, jika periode stabilisasi default lima menit untuk penurunan skala terlalu lama, sesuaikan periode tersebut. Periksa bagian spec.behavior.scaleDown dari manifes HorizontalPodAutoscaler Anda. Anda dapat menurunkan stabilizationWindowSeconds untuk memungkinkan autoscaler memperkecil skala lebih cepat setelah metrik turun. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi kebijakan ini, lihat Kebijakan Penskalaan dalam dokumentasi Kubernetes.

Langkah berikutnya