Mengonfigurasi bursting Pod di GKE

Halaman ini menunjukkan cara mengonfigurasi Pod agar burst menjadi tersedia kapasitas pada node Google Kubernetes Engine (GKE).

Apa itu bursting?

Bursting menjelaskan tindakan Pod untuk sementara menggunakan kapasitas komputasi yang lebih besar pada {i>node<i} daripada yang awalnya mereka minta.

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

Beberapa workload tidak menggunakan 100% resource yang diminta untuk keseluruhan operasinya baik. Misalnya, beban kerja yang memakai CPU tambahan selama periode booting-nya mungkin tidak memerlukan jumlah sumber daya yang sama untuk operasi normal. Dengan Anda dapat menetapkan batas resource untuk workload ke nilai yang lebih tinggi daripada permintaan resource atau membiarkan batasnya tidak ditetapkan. GKE memungkinkan untuk sementara menggunakan lebih banyak resource daripada yang Anda tentukan dalam permintaan, jika kapasitas tersebut tersedia.

Untuk informasi lebih lanjut tentang cara kerja proses ini di GKE, lihat Kapasitas burst di GKE dalam dokumen ini.

Manfaat bursting Pod

Bursting berguna ketika Pod Anda hanya membutuhkan resource tambahan untuk periode waktu untuk mengakomodasi lonjakan penggunaan resource. Contoh skenario meliputi hal berikut:

  • Anda memiliki grup workload yang sering kali tidak ada aktivitas dan mengirim sejumlah kecil permintaan penyimpanan per detik, tetapi terkadang mengalami lonjakan lalu lintas dan mendapat manfaat dari sumber daya tambahan untuk memproses permintaan tersebut.
  • Workload Anda memerlukan lebih banyak resource selama startup daripada selama biasanya operations.
  • Anda ingin memaksimalkan penggunaan kapasitas komputasi yang Anda sediakan.

Dengan Bursting, Anda dapat meminta resource yang diperlukan Pod untuk sebagian besar runtime-nya, sembari juga memastikan bahwa Pod dapat menggunakan resource jika diperlukan. Manfaat bursting meliputi:

  • Biaya pengoperasian lebih rendah: Anda tidak perlu meminta puncak yang diharapkan konsumsi resource dari workload. Permintaan Anda dapat berupa nilai nilai stabil. Dalam Autopilot, Anda membayar jumlah Pod permintaan resource, sehingga biaya pengoperasian Anda lebih rendah.
  • Penggunaan resource yang lebih efisien: Anda menghindari kapasitas komputasi nonaktif karena Pod akan meledak 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 untuk memproses permintaan yang masuk, atau untuk booting lebih cepat selama peningkatan skala peristiwa.

Kapan tidak boleh menggunakan bursting

Kubernetes menetapkan class Kualitas Layanan (QoS) Burstable ke Pod yang menetapkan batas resource yang lebih tinggi daripada permintaannya. Burstable Pod QoS kemungkinan besar akan dikeluarkan saat Kubernetes perlu memperoleh kembali resource di {i>node<i}. Untuk informasi selengkapnya, lihat Class QoS yang dapat di-burstable dalam dokumentasi Kubernetes.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Mengaktifkan 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 berjalan 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 mengalami burst dalam situasi berikut:

Ketersediaan bursting
Mode Autopilot GKE

Pod yang menggunakan class komputasi Performance atau Akselerator dapat burst di semua versi GKE yang mendukung kelas komputasi tersebut.

Di class komputasi lainnya dan untuk Pod yang tidak menentukan bursting hanya tersedia jika cluster tersebut memenuhi kedua jenis kondisi berikut:

  • Anda awalnya membuat cluster dengan versi GKE 1.26 atau yang lebih baru
  • Cluster ini menjalankan GKE versi 1.30.2-gke.1394000 atau yang lebih baru

Pembatasan ini ada karena, di klaster Autopilot, bursting membutuhkan cgroup v2. cgroup v2 hanya tersedia dalam cluster yang dibuat dengan versi 1.26 dan yang lebih baru.
Mode GKE Standard Pod dapat melakukan burst dalam versi GKE apa pun.

Cluster Autopilot yang awalnya dibuat dengan versi sebelumnya dari 1.26 dan kemudian diupgrade ke 1.29.2-gke.1060000 dan yang lebih baru tidak mendukung meledak. Untuk memeriksa versi cluster asli, jalankan perintah berikut:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(initialClusterVersion)"

Output harus berupa GKE versi 1.26 atau yang lebih baru.

Batasan

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

  • Saat Anda mengupgrade cluster Autopilot ke versi yang didukung, GKE mengupgrade node pekerja agar sesuai dengan bidang kontrol dari waktu ke waktu. Sebuah bidang kontrol perlu dimulai ulang untuk mengaktifkan bursting, dan harus terjadi setelah semua node menjalankan versi yang didukung. Bidang kontrol memulai 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. Memeriksa 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 bidang kontrol secara manual ke versi yang sama dengan oleh 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 yang dapat di-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:
      nodeSelector:
        pod-type: "non-critical"
      tolerations:
      - key: pod-type
        operator: Equal
        value: "non-critical"
        effect: NoSchedule
      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 untuk fungsi tersebut. Tetapkan nilai ini ke kapasitas yang akan diperlukan container Anda dalam keadaan stabil.
    • resources.limits: Kapasitas resource maksimum yang dapat dimiliki container gunakan. Menyetel batas yang lebih tinggi dari permintaan akan membuat Pod burst hingga batas yang ditentukan jika kapasitas tersebut tersedia di node. Jika Anda menghilangkan kolom ini, Pod dapat melakukan burstable ke burstable yang tersedia kapasitas pada 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 di resource node.
    • spec.nodeSelector dan spec.tolerations: Opsional. Memberi tahu GKE untuk membuat node baru guna menjalankan Pod burstable. GKE menerapkan taint ke node baru ini untuk mencegah Pod, seperti workload kritis, agar tidak berjalan di node yang sama. Untuk mengetahui detailnya, lihat Mengonfigurasi pemisahan workload di GKE.

  2. Men-deploy workload:

    kubectl apply -f burstable-deployment.yaml

    Beban kerja mungkin memerlukan waktu beberapa menit untuk dimulai.

  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 bursting Pod, GKE menghitung kapasitas burstable untuk setiap node dalam cluster. Berikut adalah penghitungan untuk node tertentu:

  • Cluster Autopilot: Jumlah permintaan resource dari semua Pod pada node, terlepas dari kapasitas resource node sebenarnya. Jika Pod dihentikan, kapasitas burstable akan berkurang berdasarkan permintaan Pod tersebut. Bagian kapasitas burstable yang tidak digunakan dengan menjalankan Pod tersedia untuk alokasikan jika salah satu Pod perlu melakukan burst.

    Autopilot juga menambahkan {i>buffer<i} yang telah ditentukan sebelumnya ke kapasitas {i>burstable<i} sehingga bahwa semua Pod sistem di node yang burst yang melebihi permintaannya tidak akan terpengaruh Pod burstable Anda sendiri.

  • Cluster standar: Total kapasitas resource yang tersedia di node Pesan Suara.

Praktik terbaik untuk bursting

Gunakan praktik berikut dengan bursting Pod:

  • Tetapkan permintaan resource yang sama dengan batas untuk Pod yang menyediakan fungsionalitas penting di lingkungan Anda. Hal ini memastikan bahwa Pod tersebut mendapatkan class Kualitas Layanan (QoS) Kubernetes Guaranteed.
  • Pastikan Anda hanya mengonfigurasi bursting memori pada Pod yang dapat menangani dikeluarkan saat Kubernetes perlu memperoleh kembali memori pada node.
  • Selalu minta memori yang cukup agar Pod Anda dapat melakukan booting. Jangan mengandalkan memori bursting untuk memenuhi persyaratan booting Anda.
  • Untuk mencegah Pod burstable yang secara konsisten burstable menjadi beberapa permintaan CPU agar tidak mengganggu workload kritis, menggunakan pemisahan beban kerja agar tidak menempatkan Pod tersebut bersama Pod penting.

Mengoptimalkan kapasitas burstable di node Autopilot

Autopilot menghitung kapasitas burstable sebagai jumlah resource permintaan semua Pod pada node tertentu, termasuk Pod sistem dan DaemonSet. Anda dapat mengoptimalkan kapasitas burstable pada node di bawah cara. 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 pada node yang sama.
  • Untuk memastikan bahwa kapasitas burstable tertentu selalu tersedia di setiap node, buat DaemonSets untuk dijalankan pada semua node dalam cluster.

Contoh cara kerja bursting

Bagian ini menggunakan contoh Deployment yang memiliki Pod burstable berikut untuk mendemonstrasikan cara kerja bursting Pod di GKE Autopilot {i>cluster <i}(klaster):

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

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

Pertimbangkan skenario berikut saat terjadi lonjakan traffic:

  • Pod 1 membutuhkan CPU tambahan 300 m: ia dapat burst dan menggunakan CPU sebesar 250 m, kapasitas burstable yang tersedia. Node tidak lagi memiliki kapasitas burstable.
  • Pod 2 memerlukan CPU tambahan 150 m: pod dapat burst dan menggunakan CPU tambahan sebesar 150 m. Node kemudian memiliki sisa 100 juta CPU dari kapasitas burstable yang tersedia.
  • Pod 2 membutuhkan CPU tambahan 200 m: pod ini dapat meledak dan menggunakan CPU 150 m, sehingga total penggunaan ke 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 mencoba menggunakan lebih banyak resource daripada kapasitas burstable di node, GKE akan melakukan tindakan berikut:

  • CPU: Jika penggunaan CPU melebihi kapasitas burstable, GKE men-throttle penggunaan CPU beberapa kontainer sehingga semua kontainer pada mendapatkan CPU yang mereka minta.
  • Memori: Jika penggunaan memori melebihi kapasitas burstable, GKE menghentikan container untuk mengklaim kembali memori pada node. GKE dimulai dengan menghentikan container yang menggunakan banyak resource Pod dengan QoS yang lebih rendah.

Sebaiknya selalu meminta cukup memori untuk operasi Pod normal. Jika container memiliki dependensi pada memory bursting agar berfungsi secara normal, dapat mengalami error berulang kali jika memori itu tidak tersedia.

Menggunakan bursting Pod dengan penyediaan kapasitas cadangan

GKE memungkinkan Anda men-deploy Pod nonaktif untuk mencadangkan kapasitas komputasi tambahan untuk penskalaan Pod yang lebih cepat selama peristiwa dengan traffic tinggi mendatang seperti flash toko online penjualan. Pod lain pada node yang sama dapat burst ke dalam kapasitas cadangan yang tidak digunakan ini agar kapasitas tidak nonaktif saat mengarah ke traffic tinggi peristiwa. Anda dapat mereservasi kapasitas ini menggunakan berbagai mekanisme Kubernetes. Sebagai sebagai contoh, Anda dapat men-deploy Pod yang memiliki PriorityClass rendah. Untuk mengetahui detailnya, lihat Sediakan kapasitas komputasi tambahan untuk penskalaan Pod yang cepat.

Bursting pod di cluster GKE Standard

Cluster GKE Standard juga mendukung bursting Pod dengan menetapkan batas lebih tinggi dari permintaan atau dengan menghilangkan batas. Namun, di cluster standar, Anda harus membuat dan mengonfigurasi kumpulan node dengan kapasitas resource yang sesuai untuk mendukung bursting. Mendapatkan potensi biaya pengurangan Pod burstable di cluster Standar memerlukan kehati-hatian perencanaan node dan bin-packing Pod, karena Anda membayar biaya dan melakukan load balancing di semua VM Compute Engine.

Pertimbangkan hal berikut di Cluster standar:

  • Batas konsumsi resource maksimum yang memicu Kubernetes pengecualian atau throttling CPU adalah kapasitas resource yang bisa dialokasikan {i>node<i}. Untuk menentukan nilai ini, lihat Merencanakan ukuran node GKE Standard.

  • Penggunaan resource node pada cluster Standar lebih cenderung mencapai Nilai minimum penghapusan Kubernetes karena GKE tidak secara otomatis membatasi konsumsi resource jika Anda tidak menetapkan batas. Pod yang burst sehingga memori cenderung dihentikan oleh Kubernetes penghilangan tekanan node.

Langkah selanjutnya