Mengonfigurasi buffer kapasitas

Buffer kapasitas meningkatkan responsivitas dan keandalan workload penting dengan mengelola secara proaktif kapasitas cluster cadangan dan status ditangguhkan dari kapasitas yang telah disediakan sebelumnya dan telah dikonfigurasi sebelumnya menggunakan CapacityBuffer CustomResourceDefinition (CRD) Kubernetes. Dengan menggunakan buffer kapasitas, Anda dapat menentukan jumlah kapasitas node yang tidak digunakan secara eksplisit dalam cluster. Kapasitas yang dicadangkan ini membantu mengurangi waktu penjadwalan Pod.

Saat workload berprioritas tinggi perlu ditingkatkan skalanya dengan cepat, workload baru dapat segera menggunakan kapasitas kosong tanpa menunggu penyediaan node. Pendekatan ini meminimalkan latensi dan menghindari persaingan penggunaan resource selama lonjakan permintaan yang tiba-tiba.

Halaman ini menyediakan metode untuk mengonfigurasi buffer kapasitas: buffer replika tetap, buffer batas resource, dan buffer berbasis persentase.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Untuk menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. Versi gcloud CLI yang lebih lama mungkin tidak mendukung menjalankan perintah dalam dokumen ini.
  • Buat atau miliki akses ke cluster GKE yang memenuhi persyaratan versi berikut:
    • Untuk buffer aktif, gunakan versi 1.35.2-gke.1842000 atau yang lebih baru di cluster Standard dan Autopilot.
    • Untuk buffer standby, gunakan versi 1.36.0-gke.2253000 atau yang lebih baru di cluster Standard, atau versi 1.36.0-gke.2853000 atau yang lebih baru di cluster Autopilot dengan ComputeClass kustom.
  • Aktifkan node auto-provisioning di cluster Standar Anda. Di cluster Autopilot, node auto-provisioning sudah diaktifkan. Node auto-provisioning bersifat opsional, tetapi direkomendasikan untuk buffer aktif dan diperlukan untuk buffer standby.

Membuat objek Kubernetes prasyarat

Untuk mengonfigurasi CapacityBuffer, Anda memerlukan namespace yang menyimpan semua objek yang diperlukan (CapacityBuffer itu sendiri, dan resource tambahan seperti PodTemplate atau workload). PodTemplate dan CapacityBuffer harus berada di namespace yang sama. Anda dapat membuat namespace atau menggunakan namespace yang sudah ada, termasuk namespace default.

Bergantung pada jenis CapacityBuffer yang Anda konfigurasi, Anda juga memerlukan salah satu hal berikut:

  • PodTemplate: menentukan persyaratan resource untuk satu unit kapasitas buffer. Konfigurasi yang ditentukan dalam objek CapacityBuffer mereferensikan template Pod.

  • Workload: workload yang ada yang Anda referensikan dalam objek CapacityBuffer. Panduan ini menggunakan objek Deployment sebagai contoh workload, tetapi buffer kapasitas mendukung salah satu jenis resource berikut:

    • Deployment
    • ReplicaSet
    • StatefulSet
    • ReplicationController
    • Tugas

    • CustomResourceDefinitions (CRD) yang mengimplementasikan subresource scale.

Bagian ini memberikan contoh objek tersebut. Jika Anda sudah memiliki workload yang ingin dikonfigurasi dengan buffer kapasitas, lanjutkan ke Menerapkan buffer kapasitas.

Untuk membuat contoh workload Kubernetes, selesaikan langkah-langkah berikut:

  1. Simpan manifes berikut sebagai namespace.yaml:

    apiVersion: v1
kind: Namespace
metadata:
  name: capacity-buffer-example
  labels:
    name: capacity-buffer-example

    Manifes ini membuat namespace bernama capacity-buffer-example.

  2. Opsional: untuk menggunakan buffer kapasitas dengan ComputeClass kustom, simpan manifes berikut sebagai custom-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: ccc-example
spec:
  # Buffers are also created according to these priorities
  priorities:
  - machineFamily: n4
  - machineFamily: n4d
  - machineFamily: c4
  - machineFamily: c4d
  nodePoolAutoCreation:
    enabled: true

    Manifes ini membuat ComputeClass kustom yang menentukan dan mengontrol prioritas komputasi untuk node yang disediakan GKE. Untuk mempelajari lebih lanjut, lihat ComputeClass kustom.

  3. Simpan manifes berikut sebagai buffer-pod-template.yaml:

    apiVersion: v1
kind: PodTemplate
metadata:
  name: buffer-unit-template
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
template:
  spec:
    terminationGracePeriodSeconds: 0
    containers:
    - name: buffer-container
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: "1"
          memory: "1Gi"
        limits:
          cpu: "1"
          memory: "1Gi"
    # Optional: Using buffers with a custom ComputeClass /
    # controls the properties of the provisioned nodes.
    nodeSelector:
      cloud.google.com/compute-class: ccc-example

    Manifes ini membuat PodTemplate yang menentukan persyaratan resource untuk satu unit kapasitas buffer (CPU 1 dan Memori 1Gi). Konfigurasi ini menentukan ukuran unit kapasitas yang disediakan GKE untuk buffer. Misalnya, dengan PodTemplate ini, GKE tidak akan mempertimbangkan node dengan CPU kurang dari 1 dan resource yang tersedia kurang dari 1 Gi sebagai bagian dari buffer, jika cluster ditingkatkan skalanya.

  4. Simpan manifes berikut sebagai sample-workload-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: critical-workload-ref
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
spec:
  replicas: 10
  selector:
    matchLabels:
      app: critical-workload
  template:
    metadata:
      labels:
        app: critical-workload
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["sleep", "3600"]
        resources:
          requests:
            cpu: 100m
      # Optional: Using buffers with a custom ComputeClass /
      # controls the properties of the provisioned nodes.
      nodeSelector:
        cloud.google.com/compute-class: ccc-example

    Manifes ini membuat contoh Deployment dengan 10 replika, yang merupakan objek referensi untuk contoh buffer berbasis persentase di bagian berikutnya.

  5. Terapkan manifes ke cluster Anda:

    kubectl apply -f namespace.yaml -f custom-compute-class.yaml -f buffer-pod-template.yaml -f sample-workload-deployment.yaml

  6. Pastikan GKE membuat objek:

    kubectl get podtemplate -n capacity-buffer-example
kubectl get deployment critical-workload-ref -n capacity-buffer-example

    Outputnya mirip dengan hal berikut ini:

    NAME                   AGE
buffer-unit-template   1m

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
critical-workload-ref   10/10   10           10          1m

Menerapkan buffer kapasitas

Bagian ini memberikan contoh berbagai jenis buffer kapasitas yang dapat Anda terapkan pada workload Anda.

Mengonfigurasi buffer replika tetap

Mengonfigurasi CapacityBuffer dengan replika tetap akan menentukan jumlah unit buffer yang Anda inginkan berdasarkan PodTemplate.

Untuk membuat buffer dengan replika tetap, selesaikan langkah-langkah berikut:

  1. Simpan manifes berikut sebagai cb-fixed-replicas.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: fixed-replica-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  replicas: 3
  provisioningStrategy: "STRATEGY"

    Ganti kode berikut:

    • NAMESPACE: nama namespace Anda, misalnya capacity-buffer-example.
    • POD_TEMPLATE: PodTemplate yang menentukan persyaratan resource Anda, misalnya buffer-unit-template.
    • STRATEGY: strategi penyediaan, baik "buffer.x-k8s.io/active-capacity" (default) maupun "buffer.gke.io/standby-capacity".

    Manifes ini membuat resource CapacityBuffer yang mereferensikan PodTemplate untuk meminta sejumlah unit buffer tertentu.

  2. Terapkan manifes:

    kubectl apply -f cb-fixed-replicas.yaml

  3. Pastikan GKE menerapkan buffer kapasitas:

    kubectl get capacitybuffer fixed-replica-buffer -n NAMESPACE

    Kolom replicas dalam status akan menampilkan 3, yang mencerminkan jumlah replika yang Anda tentukan dalam manifes. Kolom STATUS harus menampilkan ReadyForProvisioning.

Mengonfigurasi buffer batas resource

Anda dapat menggunakan kolom limits untuk menentukan jumlah maksimum resource yang harus digunakan buffer, yang dihitung berdasarkan ukuran PodTemplate Anda.

Untuk membuat buffer batas resource, selesaikan langkah-langkah berikut:

  1. Simpan manifes berikut sebagai cb-resource-limits.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: resource-limit-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  limits:
    cpu: "5"
    memory: "5Gi"
  provisioningStrategy: "STRATEGY"

    Ganti kode berikut:

    • NAMESPACE: nama namespace Anda, misalnya capacity-buffer-example.
    • POD_TEMPLATE: PodTemplate yang menentukan persyaratan resource Anda, misalnya buffer-unit-template.
    • STRATEGY: strategi penyediaan, "buffer.x-k8s.io/active-capacity" (default) atau "buffer.gke.io/standby-capacity".

    Manifes ini membuat resource CapacityBuffer dengan batas total 5 CPU dan Memori 5 GiB. Jika Anda menggunakan contoh PodTemplate dari langkah sebelumnya, Anda menentukan setiap unit sebagai CPU 1 dan Memori 1Gi, yang akan menghasilkan 5 unit buffering.

  2. Terapkan manifes:

    kubectl apply -f cb-resource-limits.yaml

  3. Pastikan GKE menerapkan buffer kapasitas:

    kubectl get capacitybuffer resource-limit-buffer -n NAMESPACE

    Periksa status CapacityBuffer. Kolom replicas harus menampilkan nilai yang berasal dari batas yang Anda tentukan. Jika Anda menggunakan contoh PodTemplate dari bagian sebelumnya, Anda akan melihat unit buffer 5 karena ini adalah jumlah unit maksimum yang sesuai dengan batas yang ditentukan.

Mengonfigurasi buffer berbasis persentase

Mengonfigurasi buffer berbasis persentase secara dinamis akan menentukan ukuran buffer berdasarkan persentase workload yang dapat diskalakan yang ada. Buffer kapasitas berbasis persentase hanya didukung untuk objek skalabel Kubernetes yang mengimplementasikan subresource skala, seperti Deployment, StatefulSet, ReplicaSet, atau Tugas. Anda tidak dapat menentukan buffer berbasis persentase untuk template Pod karena template tersebut tidak memiliki kolom replicas.

Pada umumnya, mulailah dengan strategi replika tetap atau batas resource, bukan buffer berbasis persentase. Pertimbangkan hal berikut saat memutuskan:

  • Buffer berbasis persentase kurang responsif terhadap peningkatan skala yang tiba-tiba jika beban kerja diskalakan ke angka rendah atau nol karena margin keamanan menurun sebanding dengan Pod aktif.
  • Node standby dikenai biaya komputasi selama periode inisialisasi sebelum ditangguhkan. Menskalakan buffer standby secara dinamis seiring fluktuasi workload akan memboroskan resource komputasi. Jadi, gunakan replika tetap atau batas resource untuk buffer standby.
  • Buffer berbasis persentase sangat berguna untuk buffer aktif pada deployment besar yang tidak pernah diskalakan ke jumlah replika yang rendah.

Di GKE versi 1.36.3-gke.1244000 dan yang lebih baru, untuk mempertahankan ukuran buffer minimum saat workload yang direferensikan memperkecil skala, tetapkan kolom replicas bersama dengan kolom percentage. GKE menggunakan kolom mana pun yang menghasilkan lebih banyak unit buffer. Untuk membatasi ukuran buffer, tetapkan juga kolom limits.

Misalnya, pertimbangkan buffer dengan percentage: 20 dan replicas: 3 yang mereferensikan Deployment dengan 10 replika. Karena 20% dari 10 replika adalah 2, yang kurang dari nilai replicas sebesar 3, GKE menyediakan 3 unit buffer. Jika Deployment diskalakan menjadi 20 replika, buffer akan bertambah menjadi 4 unit. Untuk mengetahui informasi selengkapnya, lihat dokumentasi referensi CapacityBuffer.

Untuk membuat buffer berbasis persentase, selesaikan langkah-langkah berikut:

  1. Simpan manifes berikut sebagai cb-percentage-based.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: percentage-buffer
  namespace: NAMESPACE
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: SCALABLE_RESOURCE_NAME
  percentage: 20
  provisioningStrategy: "STRATEGY"

    Ganti kode berikut:

    • NAMESPACE: nama namespace Anda.
    • SCALABLE_RESOURCE_NAME: nama resource yang dapat diskalakan, misalnya critical-workload-ref.
    • STRATEGY: strategi penyediaan, "buffer.x-k8s.io/active-capacity" (default) atau "buffer.gke.io/standby-capacity".

    Manifes ini membuat resource CapacityBuffer yang meminta ukuran buffer yang setara dengan 20% replika resource yang dirujuk. Jika Anda menggunakan contoh Deployment dari bagian sebelumnya, nilai replika ditetapkan ke 10.

  2. Terapkan manifes:

    kubectl apply -f cb-percentage-based.yaml

  3. Pastikan GKE menerapkan buffer kapasitas:

    kubectl get capacitybuffer percentage-buffer -n NAMESPACE

    Periksa status CapacityBuffer. Kolom replicas akan menampilkan nilai dari penghitungan persentase. Jika Anda menggunakan contoh Deployment dari bagian sebelumnya, Anda akan melihat 2 unit buffer, yang merupakan 20% dari 10 replika yang ditentukan dalam Deployment.

  4. Uji penskalaan dinamis dengan menskalakan Deployment secara manual hingga 20 replika:

    kubectl scale deployment critical-workload-ref -n NAMESPACE --replicas=20

    Pengontrol CapacityBuffer bereaksi dan otomatis menskalakan buffer menjadi 4 replika.

Menyesuaikan perilaku buffer standby

Anda dapat menggunakan anotasi untuk menyesuaikan cara buffer siaga dimulai dan diperbarui. Tambahkan anotasi ini ke kolom metadata.annotations resource CapacityBuffer Anda:

  • buffer.gke.io/standby-capacity-init-time: jumlah waktu node tetap aktif setelah pembuatan sebelum GKE menangguhkannya. Tentukan string durasi seperti 5m atau 1h. Defaultnya adalah 5m.

  • buffer.gke.io/standby-capacity-refresh-frequency: seberapa sering GKE me-refresh node yang ditangguhkan. Tentukan string durasi seperti 12h atau 24h. Defaultnya adalah 24h.

Contoh berikut menunjukkan manifes dengan kolom opsional ini untuk menyesuaikan perilaku buffer standby:

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: customized-standby-buffer
  namespace: my-namespace
  annotations:
    buffer.gke.io/standby-capacity-init-time: "15m"
    buffer.gke.io/standby-capacity-refresh-frequency: "12h"
spec:
  podTemplateRef:
    name: buffer-unit-template
  replicas: 3
  provisioningStrategy: "buffer.gke.io/standby-capacity"

Memuat gambar terlebih dahulu di buffer siaga

Untuk mempercepat waktu mulai beban kerja saat node standby dilanjutkan, Anda dapat memuat ulang image container menggunakan DaemonSet. DaemonSet berjalan selama periode sistem dimulai sebelum node ditangguhkan.

Untuk melakukan pramuat image menggunakan DaemonSet, selesaikan langkah-langkah berikut:

  1. Simpan manifes berikut sebagai image-puller-daemonset.yaml:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-prefetch-daemonset
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      name: image-prefetch
  template:
    metadata:
      labels:
        name: image-prefetch
    spec:
      tolerations:
      - key: "buffer.gke.io/standby-capacity-node-suspended"
        operator: "Exists"
      initContainers:
      - name: image-puller
        image: IMAGE_NAME
        command: ["sh", "-c", "true"]
      containers:
      - name: pause
        image: registry.k8s.io/pause:3.9

    Ganti kode berikut:

    • NAMESPACE: namespace untuk DaemonSet, misalnya capacity-buffer-example.
    • IMAGE_NAME: nama image yang akan dipramuat, misalnya your-app-image:latest.

    Manifes ini menyertakan toleransi buffer.gke.io/standby-capacity-node-suspended sehingga DaemonSet tetap dijadwalkan pada node standby setelah GKE menangguhkannya.

  2. Terapkan manifes DaemonSet ke cluster Anda:

    kubectl apply -f image-puller-daemonset.yaml

  3. Pastikan DaemonSet dibuat:

    kubectl get daemonset image-prefetch-daemonset -n NAMESPACE

  4. Pastikan buffer kapasitas Anda dibuat dan siap untuk penyediaan:

    kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

    Periksa statusnya. Kolom STATUS harus menampilkan ReadyForProvisioning.

Memantau status dan performa buffer kapasitas

Anda dapat memantau status dan kondisi buffer kapasitas menggunakan perintah kubectl dan metrik Cloud Monitoring.

Memverifikasi status resource CapacityBuffer

Untuk memeriksa kondisi buffer kapasitas Anda dan memverifikasi bahwa buffer tersebut siap menerima beban kerja, selesaikan langkah-langkah berikut:

  1. Dapatkan status semua buffer kapasitas di seluruh cluster:

    kubectl get capacitybuffer -A

  2. Periksa status, kondisi, dan log peristiwa mendetail dari buffer tertentu:

    kubectl describe capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

Mengidentifikasi node buffer standby yang ditangguhkan

VM buffer standby telah diprovisi sebelumnya, tetapi tetap dalam status ditangguhkan untuk membantu mengurangi biaya. Anda dapat mengenali node yang ditangguhkan ini karena memiliki kondisi kustom. Untuk mengaudit instance node yang ditangguhkan, jalankan perintah berikut:

kubectl get nodes -o custom-columns='NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status'

Status True menunjukkan bahwa VM standby ditangguhkan. Status False atau <none> menunjukkan node yang aktif dan berjalan.

Memantau performa dengan Cloud Monitoring

Untuk memantau dampak end-to-end buffer kapasitas pada waktu penskalaan, gunakan dasbor Startup Latency di konsol Google Cloud . Gunakan diagram Distribusi Latensi Startup Pod dan Latensi Siap Pertama Pod untuk melacak metrik kubernetes.io/pod/latencies/pod_first_ready dari pembuatan Pod hingga kesiapan. Anda juga dapat membuat kueri peristiwa Scheduled di Cloud Logging untuk mengukur latensi penjadwalan Pod. Untuk mengetahui petunjuknya, lihat Memantau metrik latensi startup.

Menghapus buffer kapasitas

Jika Anda tidak lagi memerlukan buffer kapasitas untuk workload, hapus objek CapacityBuffer. Tindakan ini akan menghapus Pod placeholder dan memungkinkan autoscaler cluster memperkecil skala node.

kubectl delete capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

Ganti CAPACITY_BUFFER_NAME dengan nama CapacityBuffer yang ingin Anda hapus.

Pemecahan masalah

Bagian berikut berisi informasi tentang cara menyelesaikan masalah umum terkait buffer kapasitas.

Buffer kapasitas belum siap karena model penagihan

Jika Anda membuat CapacityBuffer untuk workload yang menggunakan model penagihan berbasis Pod (bayar per Pod), buffer kapasitas tidak akan siap untuk penyediaan.

Untuk mengidentifikasi masalah ini, periksa status CapacityBuffer:

kubectl describe capacitybuffer BUFFER_NAME -n NAMESPACE

Cari kondisi jenis ReadyForProvisioning dengan status False.

Untuk mengatasi masalah ini, pastikan CapacityBuffer Anda merujuk ke workload atau PodTemplate yang kompatibel dengan penagihan berbasis node.

Error izin untuk resource kustom yang skalabel

Jika Anda mengonfigurasi CapacityBuffer untuk berfungsi dengan objek yang dapat diskalakan kustom (menggunakan kolom scalableRef), penskalaan otomatis cluster mungkin gagal menskalakan buffer jika tidak memiliki izin yang diperlukan. Masalah ini hanya terjadi di GKE versi sebelum 1.36.0-gke.2459000.

Untuk mengatasi masalah ini, berikan izin yang diperlukan secara manual dengan membuat ClusterRole dan ClusterRoleBinding, seperti dalam contoh berikut:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-scale-getter
rules:
- apiGroups: ["api.example.com"]
  resources: ["customreplicatedresources/scale"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ca-custom-scale-getter
subjects:
- kind: User
  name: "system:cluster-autoscaler"
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-scale-getter

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi RBAC, lihat dokumentasi RBAC Kubernetes.

Pod buffer tidak dijadwalkan pada node yang disediakan oleh ComputeClass kustom

Jika dependensi konfigurasi CapacityBuffer Anda (misalnya, PodTemplate) memilih ComputeClass kustom, Anda mungkin mengalami masalah saat Pod buffering tidak dijadwalkan di node yang baru disediakan. Masalah ini menyebabkan autoscaler cluster berulang kali membuat node pool dan node yang redundan, sementara node yang tidak ada aktivitasnya dihapus.

Masalah ini terjadi jika ComputeClass kustom menyediakan node dengan taint atau persyaratan runtime tertentu, dan Pod buffer Anda (atau PodTemplate yang diandalkannya) tidak memiliki toleransi atau setelan yang cocok.

Untuk mengatasi masalah ini, perbarui konfigurasi CapacityBuffer Anda untuk menentukan toleransi, pemilih node, atau class runtime yang diperlukan. Misalnya, jika dependensi Anda memilih ComputeClass kustom yang dikonfigurasi dengan GKE Sandbox, perbarui dependensi untuk melakukan salah satu hal berikut:

  • Tentukan kolom spec.runtimeClassName: gvisor.
  • Sertakan toleransi eksplisit untuk taint sandbox.gke.io/runtime=gvisor:NoSchedule.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi ComputeClass kustom.

Node buffer standby gagal dilanjutkan

Node buffer standby yang ditangguhkan mungkin gagal dilanjutkan karena salah satu alasan berikut:

  • Melanjutkan node standby yang ditangguhkan memerlukan kapasitas Compute Engine yang tersedia di zona untuk jenis mesin node dan generasi platform CPU tertentu, seperti dalam seri mesin E2 atau N2. Jika zona tidak memiliki kapasitas komputasi yang memadai untuk konfigurasi yang tepat, node akan gagal melanjutkan. Untuk mengetahui informasi selengkapnya, lihat Batasan penangguhan dan pelanjutan Compute Engine.
  • Jika ComputeClass kustom Anda mengaktifkan migrasi aktif ke node prioritas lebih tinggi (activeMigration.optimizeRulePriority: true) dan menempatkan Spot VM pada prioritas yang lebih tinggi daripada VM on-demand, GKE akan memigrasikan node standby on-demand ke Spot VM seiring waktu. Karena Spot VM lebih tunduk pada batasan kapasitas dan Spot VM yang ditangguhkan tidak dapat dikonversi menjadi VM on-demand saat dilanjutkan, batasan ini dapat mencegah node standby tersebut dilanjutkan.
  • Melanjutkan node melebihi kuota Compute Engine project Anda. Untuk mengetahui informasi selengkapnya, lihat Buffer kapasitas gagal disediakan karena batas kuota.

Untuk mengidentifikasi alasan node standby gagal melanjutkan, buat kueri log audit Compute Engine di Logs Explorer untuk error ZONE_RESOURCE_POOL_EXHAUSTED atau QUOTA_EXCEEDED pada operasi compute.instances.resume.

Untuk mengatasi atau mengurangi masalah ini, lakukan satu atau beberapa langkah berikut:

  • Gunakan cluster regional agar autoscaler cluster dapat menyediakan atau melanjutkan node di beberapa zona.
  • Konfigurasikan beberapa kelompok mesin dalam daftar spec.priorities di ComputeClass kustom Anda. Jika node yang ditangguhkan tidak dapat dilanjutkan, autoscaler cluster dapat beralih untuk membuat node baru berdasarkan aturan prioritas yang berbeda. Node baru ini memerlukan waktu lebih lama untuk siap dibandingkan dengan node standby yang dilanjutkan. Konfigurasi ini tidak membantu node yang ditangguhkan melanjutkan, karena node yang ditangguhkan hanya dapat melanjutkan dengan jenis mesin aslinya.
  • Gunakan ComputeClass kustom khusus dengan VM on-demand, atau tetapkan kolom activeMigration.optimizeRulePriority ke false untuk ComputeClass yang digunakan buffer standby Anda.
  • Pasangkan buffer siaga Anda dengan buffer aktif kecil untuk menyerap lonjakan traffic langsung.

Buffer kapasitas gagal disediakan karena batas kuota

Buffer kapasitas mungkin menyediakan lebih sedikit replika daripada yang diminta atau gagal melakukan penskalaan jika melebihi ResourceQuota Kubernetes atau kuota Compute Engine.

Untuk mengidentifikasi kuota mana yang membatasi buffer, periksa satu atau beberapa kuota berikut:

  • Periksa apakah ResourceQuota Kubernetes di namespace membatasi buffer:

    kubectl describe capacitybuffer \
    CAPACITY_BUFFER_NAME \
    -n NAMESPACE

    Pada output status.conditions, cari kondisi LimitedByQuotas dengan status True. Unit buffer aktif dan standby, termasuk unit yang didukung oleh node standby yang ditangguhkan, dihitung terhadap batas ResourceQuota namespace seolah-olah Pod buffer sedang berjalan. Jika buffer melebihi kuota namespace, GKE akan membatasi kolom status.replicas agar sesuai dengan kuota yang tersedia.

  • Periksa apakah kuota project Compute Engine memblokir penyediaan node. Di Logs Explorer, telusuri log container.googleapis.com/cluster-autoscaler-visibility untuk menemukan peristiwa no.scale.up.nap.quota.exceeded, atau telusuri log audit Compute Engine untuk menemukan error QUOTA_EXCEEDED.

    Saat memeriksa kuota Compute Engine untuk buffer standby, verifikasi kedua kuota berikut selain kuota vCPU dan memori:

    • Node standby yang ditangguhkan mempertahankan alamat IP internal dan eksternalnya, yang menggunakan kuota alamat IP yang sedang digunakan.
    • Saat menangguhkan VM standby, Compute Engine menulis memori node ke disk, yang menggunakan Persistent disk standard (GB) kuota disk yang sebanding dengan ukuran memori node.

Untuk mengatasi batas kuota, lakukan salah satu tindakan berikut:

Langkah berikutnya