Mengonfigurasi buffer kapasitas

Buffering kapasitas meningkatkan responsivitas dan keandalan workload penting dengan mengelola kapasitas cluster cadangan dan status ditangguhkan dari kapasitas yang telah disediakan dan dikonfigurasi sebelumnya secara proaktif menggunakan CustomResourceDefinition (CRD) CapacityBuffer 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 menunjukkan cara mengonfigurasi buffering kapasitas berbasis persentase, batas resource, dan replika tetap, mendedikasikan buffering untuk workload tertentu, menyesuaikan perilaku buffering standby, dan memuat image container terlebih dahulu.

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 menjalankan versi 1.37.1-gke.3020000 atau yang lebih baru. Buffer standby di cluster Autopilot memerlukan ComputeClass kustom.
  • Aktifkan pembuatan otomatis node pool di cluster Standard Anda. Di cluster Autopilot, pembuatan otomatis node pool sudah diaktifkan. Pembuatan otomatis node pool 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 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 di objek CapacityBuffer. Panduan ini menggunakan objek Deployment sebagai contoh workload, tetapi buffer kapasitas mendukung salah satu jenis resource berikut:

    • Deployment
    • ReplicaSet
    • StatefulSet
    • ReplicationController
    • Tugas
    • CustomResourceDefinition (CRD) yang mengimplementasikan subresource scale.

Bagian ini memberikan contoh objek tersebut. Jika Anda sudah memiliki workload yang ingin dikonfigurasi dengan buffering kapasitas, lanjutkan ke Menerapkan buffering 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 resource yang tersedia kurang dari 1 CPU dan 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 buffering kapasitas

Bagian ini memberikan contoh berbagai jenis buffering kapasitas yang dapat Anda terapkan ke workload.

Mengonfigurasi buffer replika tetap

Mengonfigurasi CapacityBuffer dengan replika tetap akan menentukan jumlah unit buffer yang tepat 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 jumlah 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, baik "buffer.x-k8s.io/active-capacity" (default) maupun "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 akan menampilkan nilai yang berasal dari batas yang Anda tentukan. Jika Anda menggunakan contoh PodTemplate dari bagian sebelumnya, Anda akan melihat 5 unit buffer karena ini adalah jumlah maksimum unit yang sesuai dengan batas yang ditentukan.

Mengonfigurasi buffer berbasis persentase

Mengonfigurasi buffer berbasis persentase akan mengukur buffer secara dinamis berdasarkan persentase workload skalabel yang ada. Buffering 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 workload 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.

Untuk mempertahankan ukuran buffer minimum saat workload yang direferensikan diperkecil skalanya, 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 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 skalabel Anda, misalnya critical-workload-ref.
    • STRATEGY: strategi penyediaan, baik "buffer.x-k8s.io/active-capacity" (default) maupun "buffer.gke.io/standby-capacity".

    Manifes ini membuat resource CapacityBuffer yang meminta ukuran buffer yang setara dengan 20% replika resource yang direferensikan. 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 buffering, 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.

Mendedikasikan buffering kapasitas untuk workload tertentu

Secara default, Pod tertunda yang cocok dengan batasan penjadwalan node buffer dapat mengklaim kapasitas buffer. Jika beberapa workload menggunakan ComputeClass kustom atau node pool yang sama, gunakan pemisahan workload untuk mencadangkan buffering kapasitas bagi workload tertentu. Pendekatan ini memerlukan pembuatan otomatis node pool, atau node pool khusus untuk buffer aktif di cluster Standard.

Hindari mendedikasikan buffering kapasitas terpisah untuk banyak workload individual. Setiap buffer khusus memerlukan node pool-nya sendiri, yang meningkatkan waktu untuk menyediakan dan mengisi ulang buffer. Untuk jumlah buffer yang direkomendasikan, lihat Skalabilitas.

Untuk mendedikasikan buffering kapasitas ke workload tertentu, selesaikan langkah-langkah berikut:

  1. Dalam manifes workload Anda, seperti sample-workload-deployment.yaml dari Membuat objek Kubernetes prasyarat, tambahkan toleransi kustom dan pemilih node ke spesifikasi Pod:

    spec:
  tolerations:
  - key: KEY
    operator: Equal
    value: "VALUE"
    effect: NoSchedule
  nodeSelector:
    KEY: "VALUE"
    cloud.google.com/compute-class: ccc-example

    Ganti kode berikut:

    • KEY: kunci kustom untuk taint dan label node, seperti group. Untuk awalan kunci yang dibatasi, lihat Batasan pemisahan workload.
    • VALUE: nilai kustom yang mengidentifikasi workload, seperti critical-workload.

    Di cluster Autopilot, pertahankan ComputeClass kustom atau pemilih hardware di kolom nodeSelector agar buffer menggunakan penagihan berbasis node, bukan model penagihan berbasis Pod yang tidak didukung.

  2. Konfigurasikan CapacityBuffer Anda untuk menggunakan batasan penjadwalan yang sama:

    • Jika CapacityBuffer Anda menggunakan kolom scalableRef, referensikan workload di kolom spec.scalableRef. Buffer secara otomatis mewarisi kolom tolerations dan nodeSelector workload.
    • Jika CapacityBuffer Anda menggunakan kolom podTemplateRef, tambahkan kolom tolerations dan nodeSelector yang sama ke manifes PodTemplate, seperti buffer-pod-template.yaml.

  3. Terapkan manifes Anda dan buat CapacityBuffer. Untuk mengetahui petunjuknya, lihat Menerapkan buffering kapasitas. Jika Anda melakukan pramuat image pada buffer standby, tambahkan juga toleransi kustom ke DaemonSet pramuat Anda sehingga dapat dijadwalkan pada node buffer khusus. Jika buffer menggunakan ComputeClass kustom, DaemonSet juga memerlukan toleransi untuk taint ComputeClass:

    tolerations:
- key: "buffer.gke.io/standby-capacity-node-suspended"
  operator: "Exists"
- key: KEY
  operator: Equal
  value: "VALUE"
  effect: NoSchedule
- key: cloud.google.com/compute-class
  operator: Equal
  value: ccc-example
  effect: NoSchedule

  4. Setelah autoscaler cluster menyediakan node buffer, pastikan node tersebut memiliki label node khusus dan taint node:

    kubectl get nodes -l KEY=VALUE \
    -o custom-columns='NAME:.metadata.name,TAINTS:.spec.taints[*].key'

    Setiap node dalam output mencantumkan kunci taint KEY. Jika buffer menggunakan ComputeClass kustom, node juga akan mencantumkan kunci taint cloud.google.com/compute-class. Node buffer standby juga memiliki taint yang dikelola GKE, seperti buffer.gke.io/standby-capacity-node-suspended pada node yang ditangguhkan. Saat workload Anda ditingkatkan skalanya, jalankan kubectl get pods -n NAMESPACE -o wide dan konfirmasi bahwa kolom NODE mencantumkan nama node khusus dari output ini.

Menyesuaikan perilaku buffer standby

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

  • buffer.gke.io/standby-capacity-init-time: durasi 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, hingga maksimum 120h (5 hari). Defaultnya adalah 24h.

Contoh berikut menunjukkan manifes dengan bidang 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"

Pramuat gambar di buffer standby

Untuk mempercepat waktu mulai workload saat node standby dilanjutkan, Anda dapat memuat data image container terlebih dahulu menggunakan DaemonSet. DaemonSet berjalan selama periode start-up 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 telah dibuat:

    kubectl get daemonset image-prefetch-daemonset -n NAMESPACE

  4. Pastikan buffering kapasitas Anda telah dibuat dan siap untuk penyediaan:

    kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

    Periksa statusnya. Kolom STATUS harus menampilkan ReadyForProvisioning.

Memantau status dan performa buffering kapasitas

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

Memverifikasi status resource CapacityBuffer

Untuk memeriksa kondisi buffering kapasitas dan memastikan bahwa buffering tersebut siap menerima workload, selesaikan langkah-langkah berikut:

  1. Dapatkan status semua buffering 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 disediakan sebelumnya, tetapi disimpan 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 menyeluruh buffering kapasitas pada waktu peningkatan skala, gunakan dasbor Startup Latency di konsol Google Cloud . Gunakan diagram Pod Startup Latency Distribution dan Pod First Ready Latency untuk melacak metrik kubernetes.io/pod/latencies/pod_first_ready dari pembuatan Pod hingga kesiapan. Anda juga dapat mengkueri 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 buffering 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.

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

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 diandalkan) 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, update 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 pembuatan 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 dilanjutkan. Untuk mengetahui informasi selengkapnya, lihat batasan penangguhan dan melanjutkan Compute Engine.
  • Jika ComputeClass kustom Anda mengaktifkan migrasi aktif ke node dengan 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 rentan terhadap 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 akan 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 menemukan 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 ComputeClass kustom Anda. Jika node yang ditangguhkan tidak dapat dilanjutkan, autoscaler cluster dapat kembali 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 untuk 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 standby 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 peningkatan skala jika melebihi ResourceQuota Kubernetes atau kuota Compute Engine.

Untuk mengidentifikasi kuota 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, diperhitungkan dalam 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:

Pod DaemonSet berhenti menerima data setelah node standby dilanjutkan

Setelah node buffer standby yang ditangguhkan dilanjutkan, Pod DaemonSet di node tersebut mungkin berhenti menerima data melalui koneksi yang berjalan lama yang dibuka sebelum node ditangguhkan. Pod tidak mencatat error apa pun dan tidak terhubung kembali.

Masalah ini terjadi saat Pod DaemonSet bertindak sebagai klien khusus penerima, seperti untuk respons HTTP streaming, koneksi WebSocket, peristiwa yang dikirim server, atau panggilan streaming server gRPC. Saat node standby ditangguhkan, server atau perangkat jaringan perantara akan mengalami waktu tunggu habis dan menutup koneksi. Saat node dilanjutkan, stack jaringan Pod masih menganggap koneksi terbuka. Karena Pod tidak mengirim data apa pun, Pod tidak pernah mendeteksi bahwa koneksi telah ditutup dan menunggu data tanpa batas waktu.

Untuk mengatasi masalah ini, konfigurasikan aplikasi klien di Pod DaemonSet Anda untuk mendeteksi koneksi yang ditutup dan menghubungkan kembali dengan melakukan salah satu hal berikut:

  • Konfigurasikan keepalive TCP sisi klien di aplikasi Pod Anda (mengaktifkan keepalive hanya di server tidak akan memberi tahu Pod). Untuk mengetahui informasi selengkapnya tentang parameter keepalive TCP, lihat Koneksi tidak ada aktivitas.
    1. Aktifkan opsi soket SO_KEEPALIVE di library klien atau runtime bahasa Anda, seperti socket.setKeepAlive(true, initialDelay) di Node.js atau net.Dialer.KeepAlive di Go. Beberapa runtime menonaktifkan keepalive TCP secara default.
    2. Konfigurasikan waktu tidak ada aktivitas keepalive yang singkat (TCP_KEEPIDLE), seperti beberapa detik, daripada mengandalkan default sistem operasi.
    3. Perbarui aplikasi Anda untuk menangkap error koneksi (seperti reset koneksi atau waktu tunggu) saat pemeriksaan keepalive gagal dan buka koneksi baru.
  • Konfigurasikan heartbeat tingkat aplikasi atau waktu tunggu baca di klien Anda, seperti frame ping dan pong WebSocket atau ping keepalive gRPC, dan update aplikasi Anda untuk terhubung kembali saat waktu tunggu habis.

Langkah berikutnya