Mengonfigurasi bursting Pod di GKE

Halaman ini menunjukkan cara mengonfigurasi Pod untuk melakukan burst ke kapasitas yang tidak digunakan yang tersedia di node Google Kubernetes Engine (GKE).

Apa yang dimaksud dengan bursting?

Bursting menjelaskan tindakan Pod yang menggunakan lebih banyak kapasitas komputasi di node untuk sementara daripada yang awalnya diminta.

Kubernetes memungkinkan Anda meminta kapasitas resource tertentu seperti CPU atau memori untuk Pod Anda. Anda menetapkan permintaan ini dalam manifes Pod. Penjadwal Kubernetes menempatkan Pod Anda di node yang memiliki kapasitas yang cukup untuk mengakomodasi permintaan resource tersebut.

Beberapa workload tidak menggunakan 100% resource yang diminta selama seluruh waktu operasionalnya. Misalnya, workload yang menggunakan CPU tambahan selama periode booting mungkin tidak memerlukan jumlah resource yang sama untuk operasi normal. Dalam situasi ini, Anda dapat menetapkan batas resource untuk workload ke nilai yang lebih tinggi daripada permintaan resource atau membiarkan batas tidak ditetapkan. GKE memungkinkan workload menggunakan lebih banyak resource untuk sementara daripada yang Anda tentukan dalam permintaan, jika kapasitas tersebut tersedia.

Untuk mengetahui informasi selengkapnya tentang cara kerja proses ini di GKE, lihat Kapasitas burstable di GKE di halaman ini.

Manfaat burst Pod

Bursting berguna saat Pod Anda hanya memerlukan resource tambahan untuk jangka waktu singkat guna mengakomodasi lonjakan penggunaan resource. Contoh skenario mencakup hal berikut:

  • Anda memiliki grup workload yang sering tidak aktif dan mengirimkan sejumlah kecil permintaan per detik, tetapi terkadang mengalami lonjakan traffic dan akan mendapatkan manfaat dari resource tambahan untuk memproses permintaan tersebut.
  • Workload Anda memerlukan lebih banyak resource selama startup daripada selama operasi normal.
  • Anda ingin memaksimalkan penggunaan kapasitas komputasi yang Anda sediakan.

Bursting memungkinkan Anda hanya meminta resource yang dibutuhkan Pod untuk sebagian besar runtime-nya dan membantu memastikan bahwa Pod dapat menggunakan lebih banyak resource jika diperlukan. Manfaat bursting meliputi:

  • Biaya pengoperasian yang lebih rendah: Anda tidak perlu meminta konsumsi resource puncak yang diharapkan dari workload. Permintaan Anda dapat ditujukan untuk nilai steady-state yang lebih rendah. Di Autopilot, Anda membayar jumlah permintaan resource Pod, sehingga biaya operasional Anda lebih rendah.
  • Penggunaan resource yang lebih efisien: Anda menghindari kapasitas komputasi yang tidak digunakan karena Pod Anda bursting ke kapasitas yang tidak terpakai. Workload Anda lebih cenderung menggunakan semua resource berbayar Anda.
  • Peningkatan performa: Pod dapat menggunakan resource tambahan sesuai kebutuhan untuk mengurangi waktu pemrosesan permintaan yang masuk, atau untuk melakukan booting lebih cepat selama peristiwa penskalaan.

Kapan sebaiknya tidak menggunakan bursting

Kubernetes menetapkan class Quality of Service (QoS) Burstable ke Pod yang menentukan batas resource yang lebih tinggi daripada permintaannya. Pod QoS Burstable lebih mungkin dikeluarkan saat Kubernetes perlu mengklaim kembali resource di node. Untuk mengetahui informasi selengkapnya, lihat Class QoS Burstable dalam dokumentasi Kubernetes.

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.
  • Pastikan Anda memiliki cluster GKE Autopilot yang menjalankan versi 1.30.2-gke.1394000 atau yang lebih baru, atau versi cluster GKE Standard apa pun. Untuk membuat cluster baru, lihat Membuat cluster Autopilot.

Ketersediaan bursting di GKE

Workload dapat mengalami burst dalam situasi berikut:

Ketersediaan burst
Mode Autopilot GKE

Jenis Pod berikut dapat melakukan burst di versi GKE mana pun yang mendukung hardware yang diminta Pod:

Untuk semua jenis Pod lainnya, bursting akan tersedia saat Anda memulai ulang bidang kontrol setelah memastikan bahwa cluster memenuhi semua kondisi berikut:

  • Cluster menjalankan cgroupv2. Cluster yang dibuat dengan GKE versi 1.26 atau yang lebih baru, atau telah dimigrasikan ke cgroupv2 akan memenuhi kondisi ini. Lihat memeriksa mode cgroup untuk menentukan versi cgroup saat ini, dan lakukan migrasi jika diperlukan.
  • Cluster menjalankan GKE versi 1.30.2-gke.1394000 atau yang lebih baru.

Untuk mengetahui detailnya, lihat Batasan.
Mode GKE Standard Pod dapat melakukan burst di versi GKE apa pun.

Batasan

  • Workload Autopilot hanya dapat menggunakan bursting untuk permintaan CPU dan memori.

  • Saat Anda mengupgrade cluster Autopilot ke versi yang didukung, GKE akan mengupgrade worker node agar sesuai dengan versi bidang kontrol dari waktu ke waktu. Mulai ulang bidang kontrol diperlukan untuk mengaktifkan bursting, dan harus terjadi setelah semua node menjalankan versi yang didukung dan mode cgroup yang didukung. Bidang kontrol dimulai ulang secara otomatis sekitar sekali seminggu selama operasi seperti penskalaan, upgrade, atau pemeliharaan.

    Untuk memicu mulai ulang bidang kontrol secara manual, lakukan hal berikut:

    1. Periksa apakah semua node Anda menjalankan versi 1.30.2-gke.1394000 atau yang lebih baru:

      kubectl get nodes

      Outputnya mirip dengan hal berikut ini:

      NAME                                          STATUS   ROLES    AGE     VERSION
gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000

      Semua node dalam output harus menampilkan versi yang diperlukan atau yang lebih baru.

    2. Pastikan cluster Anda menjalankan cgroupv2. Untuk mengetahui petunjuknya, lihat Memeriksa mode cgroup.

    3. Mulai upgrade bidang kontrol secara manual ke versi yang sama dengan yang sudah digunakan cluster.

      gcloud container clusters upgrade CLUSTER_NAME --master \
    --cluster-version CURRENT_CLUSTER_VERSION

      Ganti kode berikut:

      • CLUSTER_NAME: nama cluster yang ada.
      • CURRENT_CLUSTER_VERSION: versi yang dijalankan cluster Anda.

Hubungkan ke cluster

Jalankan perintah berikut:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster yang ada.
  • LOCATION: lokasi cluster Anda.

Memastikan cluster Anda mendukung bursting

Bursting selalu diaktifkan di cluster mode Standard dan untuk workload mode Autopilot yang meminta akselerator atau seri mesin tertentu. Lanjutkan ke bagian Men-deploy workload burstable.

Jenis workload Autopilot berikut hanya dapat melakukan burst jika DaemonSet yang dikelola GKE bernama efficiency-daemon berjalan di cluster:

GKE men-deploy DaemonSet efficiency-daemon saat cluster Autopilot Anda memenuhi persyaratan untuk bursting, seperti yang dijelaskan di bagian Ketersediaan bursting di GKE.

Untuk memeriksa apakah DaemonSet efficiency-daemon ada di cluster Anda, jalankan perintah berikut:

kubectl get daemonset --namespace=kube-system efficiency-daemon

Outputnya mirip dengan hal berikut ini:

NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
efficiency-daemon   1         1         1       1            1           <none>          105d

Jika output kosong, pastikan cluster memenuhi semua persyaratan dan batasan di bagian Sebelum memulai.

Men-deploy workload burstable

  1. Simpan manifes berikut sebagai burstable-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 350m

    Manifes ini memiliki kolom berikut untuk mengaktifkan bursting:

    • resources.requests: Resource yang diperlukan container agar dapat berfungsi. Tetapkan nilai ini ke kapasitas yang akan dibutuhkan container Anda dalam status stabil.
    • resources.limits: Kapasitas resource maksimum yang dapat digunakan container. Menetapkan batas yang lebih tinggi daripada permintaan memungkinkan Pod melakukan burst hingga batas yang ditentukan jika kapasitas tersebut tersedia di node. Jika Anda menghapus kolom ini, Pod dapat melakukan burst hingga kapasitas burstable yang tersedia di node. Kapasitas ini dihitung sebagai berikut:
      • Mode Autopilot: Kapasitas yang tidak digunakan dalam jumlah permintaan resource Pod pada node.
      • Mode standar: Kapasitas yang tidak digunakan dalam resource node.
    • spec.nodeSelector dan spec.tolerations: Opsional. Tambahkan kolom ini dengan label kustom seperti pod-type: "non-critical" untuk memberi tahu GKE agar membuat node baru untuk menjalankan Pod burstable. GKE menerapkan taint ke node baru ini untuk mencegah Pod lain, seperti workload penting, berjalan di node yang sama. Autopilot menerapkan permintaan resource minimum yang lebih tinggi untuk Pod yang menggunakan pemisahan workload. Untuk mengetahui detailnya, lihat Mengonfigurasi pemisahan workload di GKE dan Permintaan resource di Autopilot.

  2. Men-deploy workload:

    kubectl apply -f burstable-deployment.yaml

    Workload mungkin memerlukan waktu beberapa menit untuk dimulai.

  3. Memeriksa class QoS Pod:

    kubectl describe pod helloweb | grep -m 1 "QoS"

    Outputnya adalah sebagai berikut:

    QoS Class: Burstable

Kapasitas burstable di GKE

Untuk memfasilitasi burst Pod, GKE menghitung kapasitas burstable untuk setiap node dalam cluster. Penghitungan untuk node tertentu adalah sebagai berikut:

  • Cluster Autopilot:

    • Pod yang meminta akselerator atau meminta seri mesin tertentu: Kapasitas resource yang dapat dialokasikan node, yaitu kapasitas yang tersedia untuk penggunaan workload. Untuk mengetahui detailnya , lihat Resource yang dapat dialokasikan node.
    • Semua Pod lainnya: Jumlah permintaan resource dari semua Pod di node tersebut, terlepas dari kapasitas resource sebenarnya dari node tersebut. Jika Pod dihentikan, kapasitas burstable akan berkurang sebesar permintaan Pod tersebut. Bagian dari kapasitas burstable yang tidak digunakan oleh Pod yang berjalan tersedia untuk dialokasikan jika salah satu Pod perlu melakukan burst.

    Autopilot juga menambahkan buffer yang telah ditentukan ke kapasitas burstable sehingga Pod sistem apa pun pada node yang melakukan burst melebihi permintaannya tidak akan memengaruhi Pod burstable Anda sendiri.

  • Cluster standar: Kapasitas resource yang dapat dialokasikan node, yaitu kapasitas yang tersedia untuk penggunaan workload. Untuk mengetahui detailnya , lihat Resource yang dapat dialokasikan node.

Praktik terbaik untuk bursting

Gunakan praktik berikut dengan burst Pod:

  • Tetapkan permintaan resource yang sama dengan batas untuk Pod apa pun yang menyediakan fungsi penting di lingkungan Anda. Pendekatan ini membantu memastikan bahwa Pod tersebut mendapatkan class Quality of Service (QoS) Kubernetes Guaranteed.
  • Pastikan Anda hanya mengonfigurasi burst memori pada Pod yang dapat menangani penghapusan saat Kubernetes perlu mengklaim kembali memori pada node.
  • Selalu minta memori yang cukup agar Pod Anda dapat melakukan booting. Jangan mengandalkan burst memori untuk memenuhi persyaratan booting Anda.
  • Untuk mencegah Pod burstable yang secara konsisten melakukan burst ke kelipatan permintaan CPU-nya agar tidak berpotensi mengganggu workload penting, gunakan pemisahan workload untuk menghindari penempatan Pod tersebut bersama Pod penting Anda.

Mengoptimalkan kapasitas burstable di node Autopilot

Autopilot menghitung kapasitas burstable sebagai jumlah permintaan resource dari semua Pod pada node tertentu, termasuk Pod sistem dan DaemonSet. Anda dapat mengoptimalkan kapasitas burstable pada node dengan cara berikut. Namun, bursting bersifat oportunistik dan tidak dijamin.

  • Untuk meningkatkan kapasitas burstable pada node untuk workload tertentu, gunakan afinitas Pod untuk menempatkan Pod tertentu bersama-sama di node yang sama.
  • Untuk memastikan kapasitas burstable tertentu selalu tersedia di setiap node, buat DaemonSets untuk dijalankan di semua node dalam cluster.

Contoh cara kerja bursting

Bagian ini menggunakan contoh Deployment yang memiliki Pod burstable berikut untuk menunjukkan cara kerja burst Pod di cluster GKE Autopilot:

  • Pod 1 meminta CPU 250m dan tidak memiliki batas CPU. Pod 1 menggunakan CPU 100m untuk berjalan.
  • Pod 2 meminta CPU 200m dan memiliki batas CPU 250m. Pod 2 menggunakan CPU 100m untuk dijalankan.

Kedua Pod berjalan di node yang sama. Total kapasitas burstable pada node adalah CPU 450m (jumlah permintaan resource). Setiap Pod hanya menggunakan CPU 100m untuk berjalan, yang berarti node memiliki sisa kapasitas burstable yang tersedia sebesar 250m.

Pertimbangkan skenario berikut saat terjadi lonjakan traffic:

  • Pod 1 memerlukan CPU tambahan sebesar 300m: Pod ini dapat melakukan burst dan menggunakan CPU sebesar 250m, yang merupakan kapasitas burstable yang tersedia. Node tidak lagi memiliki kapasitas burstable yang tersedia.
  • Pod 2 memerlukan tambahan CPU 150m: Pod ini dapat melakukan burst dan menggunakan CPU 150m tambahan. Node kemudian memiliki sisa CPU 100m dari kapasitas burstable yang tersedia.
  • Pod 2 memerlukan tambahan 200m CPU: Pod ini dapat melakukan burst dan menggunakan 150m CPU, sehingga total penggunaan menjadi 250m CPU untuk Pod 2. Pod 2 memiliki batas CPU 250 m dan tidak dapat melakukan burst melebihi batas tersebut.

Cara GKE menangani Pod yang melebihi kapasitas burstable

Jika Pod burstable Anda mencoba menggunakan lebih banyak resource daripada kapasitas burstable pada node, GKE akan melakukan tindakan berikut:

  • CPU: Jika penggunaan CPU melebihi kapasitas burstable, GKE akan membatasi penggunaan CPU beberapa container sehingga semua container di node mendapatkan CPU yang diminta.
  • Memori: Jika penggunaan memori melebihi kapasitas burstable, GKE akan menghentikan container untuk mengklaim kembali memori pada node. GKE memulai dengan menghentikan container yang menggunakan banyak resource di Pod dengan QoS yang lebih rendah.

Sebaiknya Anda selalu meminta memori yang cukup untuk operasi Pod normal. Jika container memiliki dependensi pada burst memori agar dapat berfungsi secara normal, container tersebut mungkin akan mengalami error berulang kali jika memori tersebut tidak tersedia.

Menggunakan bursting Pod dengan penyediaan kapasitas cadangan

GKE memungkinkan Anda men-deploy Pod nonaktif untuk mencadangkan kapasitas komputasi tambahan guna penskalaan Pod yang lebih cepat selama peristiwa traffic tinggi di masa mendatang, seperti flash sale toko online. Pod lain di node yang sama dapat bursting ke kapasitas yang dicadangkan dan tidak terpakai ini, sehingga kapasitas tidak menganggur pada waktu menjelang peristiwa traffic tinggi Anda. Anda dapat memesan kapasitas ini menggunakan berbagai mekanisme Kubernetes. Misalnya, Anda dapat men-deploy Pod yang memiliki PriorityClass rendah. Untuk mengetahui detailnya, lihat Menyediakan kapasitas komputasi tambahan untuk penskalaan Pod yang cepat.

Bursting Pod di cluster GKE Standard

Cluster GKE Standard juga mendukung burst Pod dengan menetapkan batas yang lebih tinggi daripada permintaan atau dengan menghilangkan batas. Namun, di cluster Standard, Anda harus membuat dan mengonfigurasi node pool dengan kapasitas resource yang sesuai untuk mendukung burst. Untuk mendapatkan potensi pengurangan biaya Pod burstable di cluster Standard, diperlukan perencanaan node dan bin-packing Pod yang lebih cermat, karena Anda membayar VM Compute Engine yang mendasarinya.

Pertimbangkan hal berikut di cluster Standard:

  • Batas konsumsi resource maksimum yang memicu pengosongan Kubernetes atau throttling CPU adalah kapasitas resource yang dapat dialokasikan pada node. Untuk menentukan nilai ini, lihat Merencanakan ukuran node GKE Standard.

  • Penggunaan resource node di cluster Standard lebih cenderung mencapai batas pengeluaran Kubernetes karena GKE tidak otomatis membatasi konsumsi resource jika Anda tidak menentukan batas. Oleh karena itu, Pod yang mengalami lonjakan memori lebih mungkin dihentikan oleh pengusiran tekanan node Kubernetes.

Langkah berikutnya