Mengonfigurasi bursting Pod di GKE

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

Apa yang dimaksud dengan burst?

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 menetapkan permintaan ini dalam manifes Pod. Penjadwal Kubernetes menempatkan Pod Anda di node yang memiliki kapasitas yang cukup untuk mengakomodasi permintaan resource tersebut.

Beberapa beban kerja tidak menggunakan 100% resource yang diminta selama seluruh waktu eksekusi. Misalnya, beban kerja yang menggunakan CPU tambahan selama periode bootingnya 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 daripada yang Anda tentukan dalam permintaan, jika kapasitas tersebut tersedia.

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

Manfaat Pod bursting

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

  • Anda memiliki grup beban kerja yang sering tidak ada aktivitas dan mengirim 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 disediakan.

Bursting memungkinkan Anda hanya meminta resource yang diperlukan Pod untuk sebagian besar runtime-nya, sekaligus memastikan bahwa Pod Anda dapat menggunakan lebih banyak resource jika diperlukan. Manfaat burst meliputi hal berikut:

  • Biaya operasi yang lebih rendah: Anda tidak perlu meminta konsumsi resource puncak beban kerja yang diharapkan. Permintaan Anda dapat berupa nilai steady state yang lebih rendah. Di Autopilot, Anda membayar jumlah permintaan resource Pod, sehingga biaya berjalan Anda lebih rendah.
  • Penggunaan resource yang lebih efisien: Anda menghindari kapasitas komputasi yang tidak ada aktivitasnya karena Pod Anda melakukan bursting ke kapasitas yang tidak terpakai. Workload Anda cenderung akan menggunakan semua resource berbayar.
  • Performa yang lebih baik: Pod dapat menggunakan resource tambahan sesuai kebutuhan untuk mengurangi waktu pemrosesan permintaan yang masuk, atau untuk melakukan booting lebih cepat selama peristiwa peningkatan skala.

Kapan sebaiknya Anda tidak menggunakan burst

Kubernetes menetapkan class Kualitas Layanan (QoS) Burstable ke Pod yang menentukan batas resource yang lebih tinggi daripada permintaannya. Pod QoS Burstable lebih cenderung dihapus saat Kubernetes perlu mengklaim kembali resource di node. Untuk informasi selengkapnya, lihat Kelas QoS Burstable dalam dokumentasi Kubernetes.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Jika ingin 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 gcloud components update.
  • Pastikan Anda memiliki cluster GKE Autopilot yang menjalankan versi 1.30.2-gke.1394000 atau yang lebih baru, atau versi apa pun dari cluster GKE Standard. Untuk membuat cluster baru, lihat Membuat cluster Autopilot.

Ketersediaan bursting di GKE

Workload dapat melonjak dalam situasi berikut:

Ketersediaan burst
Mode Autopilot GKE

Jenis Pod berikut dapat di-burst dalam versi GKE apa pun yang mendukung hardware yang diminta Pod:

Untuk semua workload lainnya, burst tersedia jika cluster memenuhi kedua kondisi berikut:

  • Cluster sedang 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 bermigrasi jika diperlukan.
  • Cluster menjalankan GKE versi 1.30.2-gke.1394000 atau yang lebih baru
Mode GKE Standard Pod dapat di-burst di versi GKE apa pun.

Batasan

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

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

    Untuk memicu mulai ulang panel kontrol secara manual, lakukan tindakan 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. Mulai upgrade control plane secara manual ke versi yang sama dengan yang sudah digunakan cluster. Untuk mengetahui petunjuknya, lihat Mengupgrade bidang kontrol secara manual.

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.

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 burst:

    • resources.requests: Resource yang diperlukan penampung untuk berfungsi. Tetapkan nilai ini ke kapasitas yang diperlukan penampung Anda dalam status stabil.
    • resources.limits: Kapasitas resource maksimum yang dapat digunakan penampung. Menetapkan batas yang lebih tinggi dari permintaan memungkinkan Pod melakukan bursting hingga batas yang ditentukan jika kapasitas tersebut tersedia di node. Jika Anda menghapus kolom ini, Pod dapat memicu burst hingga kapasitas burstable yang tersedia di node. Kapasitas ini dihitung sebagai berikut:
      • Mode Autopilot: Kapasitas yang tidak terpakai dalam jumlah permintaan resource Pod di node.
      • Mode standar: Kapasitas yang tidak digunakan di resource node.
    • spec.nodeSelector dan spec.tolerations: Opsional. Tambahkan kolom ini dengan label khusus seperti pod-type: "non-critical" untuk memberi tahu GKE agar membuat node baru untuk menjalankan Pod yang dapat di-burst. GKE menerapkan taint ke node baru ini untuk mencegah Pod lain, seperti beban kerja 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

    Mungkin perlu waktu beberapa menit untuk memulai beban kerja.

  3. Periksa class QoS Pod:

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

    Outputnya adalah sebagai berikut:

    QoS Class: Burstable

Kapasitas burstable di GKE

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

  • Cluster Autopilot:

    • Pod yang meminta akselerator atau meminta seri mesin tertentu: Kapasitas resource yang dapat dialokasikan node, yang merupakan 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. Jika Pod dihentikan, kapasitas burstable akan berkurang sesuai dengan permintaan Pod tersebut. Bagian kapasitas burstable yang tidak digunakan oleh Pod yang berjalan tersedia untuk dialokasikan jika salah satu Pod perlu di-burst.

    Autopilot juga menambahkan buffer yang telah ditentukan ke kapasitas burstable sehingga Pod sistem di node yang mengalami burst di luar permintaannya tidak 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 burst

Gunakan praktik berikut dengan Pod bursting:

  • Tetapkan permintaan resource Anda sama dengan batas untuk Pod apa pun yang menyediakan fungsi penting di lingkungan Anda. Hal ini memastikan bahwa Pod tersebut mendapatkan class Kualitas Layanan (QoS) Kubernetes Guaranteed.
  • Pastikan Anda hanya mengonfigurasi memory bursting pada Pod yang dapat menangani pengosongan saat Kubernetes perlu mengambil kembali memori di 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 mengalami burst menjadi kelipatan permintaan CPU-nya sehingga 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 di node tertentu, termasuk Pod sistem dan DaemonSets. Anda dapat mengoptimalkan kapasitas burstable di node dengan cara berikut. Namun, burst bersifat oportunistik dan tidak dijamin.

  • Untuk meningkatkan kapasitas burstable di node untuk beban kerja tertentu, gunakan afinitas Pod untuk menempatkan Pod tertentu secara bersamaan 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 burst

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

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

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

Pertimbangkan skenario berikut saat lonjakan traffic terjadi:

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

Cara GKE menangani Pod yang melebihi kapasitas burstable

Jika Pod burstable Anda mencoba menggunakan lebih banyak resource daripada kapasitas burstable di 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 mereka minta.
  • Memori: Jika penggunaan memori melebihi kapasitas burstable, GKE akan menghentikan container untuk mengklaim kembali memori di node. GKE dimulai dengan menghentikan container yang membutuhkan banyak resource di Pod dengan QoS yang lebih rendah.

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

Menggunakan bursting Pod dengan penyediaan kapasitas cadangan

GKE memungkinkan Anda men-deploy Pod yang tidak ada aktivitas untuk mencadangkan kapasitas komputasi tambahan untuk penskalaan Pod yang lebih cepat selama peristiwa traffic tinggi di masa mendatang seperti promo kilat toko online. Pod lain di node yang sama dapat melakukan bursting ke kapasitas yang direservasi dan tidak digunakan ini sehingga kapasitas tidak tidak ada aktivitasnya 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 lonjakan Pod dengan menetapkan batas yang lebih tinggi daripada permintaan atau dengan menghapus batas. Namun, di cluster Standard, Anda harus membuat dan mengonfigurasi node pool dengan kapasitas resource yang sesuai untuk mendukung bursting. Untuk mendapatkan potensi pengurangan biaya Pod burstable di cluster Standar, Anda memerlukan perencanaan node dan pengemasan bin Pod yang lebih cermat, karena Anda membayar VM Compute Engine yang mendasarinya.

Pertimbangkan hal berikut di cluster Standar:

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

  • Penggunaan resource node di cluster Standar lebih cenderung mencapai nilai minimum penghapusan Kubernetes karena GKE tidak otomatis membatasi konsumsi resource jika Anda tidak menentukan batas. Oleh karena itu, Pod yang memenuhi memori lebih cenderung dihentikan oleh pengusiran tekanan node Kubernetes.

Langkah selanjutnya