Mengonfigurasi bursting Pod di GKE


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

Apa yang dimaksud dengan bursting?

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

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 waktu prosesnya. 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 daripada yang Anda tentukan dalam permintaan untuk sementara, jika kapasitas tersebut tersedia.

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

Manfaat lonjakan 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 kali 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 meminta hanya resource yang dibutuhkan Pod untuk sebagian besar runtime-nya, sekaligus memastikan bahwa Pod Anda dapat menggunakan lebih banyak resource jika diperlukan. Manfaat bursting meliputi:

  • Biaya pengoperasian yang lebih rendah: Anda tidak perlu meminta perkiraan konsumsi resource puncak beban kerja. Permintaan Anda dapat berupa nilai steady-state yang lebih rendah. Dalam mode 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 dapat menggunakan kapasitas yang tidak terpakai. Workload Anda cenderung menggunakan semua resource berbayar Anda.
  • Peningkatan performa: Pod dapat menggunakan resource tambahan sesuai kebutuhan untuk mengurangi waktu pemrosesan permintaan masuk, atau untuk melakukan booting lebih cepat selama peristiwa peningkatan skala.

Kapan sebaiknya 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 mungkin dikeluarkan saat Kubernetes perlu mengklaim kembali resource di node. Untuk mengetahui informasi selengkapnya, lihat kelas QoS yang dapat di-burst 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 cluster GKE Standard apa pun. Untuk membuat cluster baru, lihat Membuat cluster Autopilot.

Ketersediaan bursting di GKE

Workload dapat mengalami lonjakan dalam situasi berikut:

Ketersediaan lonjakan
Mode Autopilot GKE

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

Untuk semua jenis Pod lainnya, lonjakan 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 bermigrasi 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. Restart bidang kontrol diperlukan untuk mengaktifkan lonjakan, dan harus dilakukan setelah semua node menjalankan versi yang didukung dan mode cgroup yang didukung. Bidang kontrol dimulai ulang secara otomatis sekitar seminggu sekali selama operasi seperti penskalaan, upgrade, atau pemeliharaan.

    Untuk memicu mulai ulang panel 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. Konfirmasi bahwa 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 Deploy workload yang dapat di-burst.

Jenis workload Autopilot berikut dapat melakukan burst hanya 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 yang dapat di-burst

  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 penampung Anda dalam kondisi 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 menggunakan kapasitas yang dapat di-burst yang tersedia di node. Kapasitas ini dihitung sebagai berikut:
      • Mode Autopilot: Kapasitas yang tidak digunakan dalam jumlah permintaan resource Pod di 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 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 agar beban kerja dimulai.

  3. Periksa class QoS Pod:

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

    Outputnya adalah sebagai berikut:

    QoS Class: Burstable
    

Kapasitas yang dapat di-burst di GKE

Untuk memfasilitasi lonjakan Pod, GKE menghitung kapasitas lonjakan 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 semua Pod di node tersebut, terlepas dari kapasitas resource sebenarnya dari node. Jika Pod dihentikan, kapasitas yang dapat di-burst akan berkurang sesuai permintaan Pod tersebut. Bagian dari kapasitas yang dapat di-burst yang tidak digunakan oleh Pod yang sedang berjalan tersedia untuk dialokasikan jika salah satu Pod perlu di-burst.

    Autopilot juga menambahkan buffer yang telah ditentukan sebelumnya ke kapasitas burstable sehingga Pod sistem apa pun di node yang melampaui 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 lonjakan

Gunakan praktik berikut dengan Pod bursting:

  • Tetapkan permintaan resource Anda sama dengan batas untuk Pod apa pun yang menyediakan fungsionalitas penting di lingkungan Anda. Hal ini memastikan bahwa Pod tersebut mendapatkan class Kualitas Layanan (QoS) Kubernetes Guaranteed.
  • Pastikan Anda hanya mengonfigurasi lonjakan memori pada Pod yang dapat menangani penghapusan saat Kubernetes perlu merebut kembali memori di node.
  • Selalu minta memori yang cukup agar Pod Anda dapat di-boot. Jangan mengandalkan lonjakan memori untuk memenuhi persyaratan booting Anda.
  • Untuk mencegah Pod yang dapat di-burst yang secara konsisten di-burst menjadi kelipatan permintaan CPU-nya berpotensi mengganggu workload penting, gunakan pemisahan workload untuk menghindari penempatan Pod tersebut bersama Pod penting Anda.

Mengoptimalkan kapasitas yang dapat di-burst di node Autopilot

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

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

Contoh cara kerja lonjakan

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

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

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

Pertimbangkan skenario berikut saat lonjakan traffic terjadi:

  • Pod 1 memerlukan CPU tambahan sebesar 300 m: Pod ini dapat melakukan burst dan menggunakan CPU sebesar 250 m, yang merupakan kapasitas burst yang tersedia. Node tidak lagi memiliki kapasitas lonjakan yang tersedia.
  • Pod 2 memerlukan tambahan 150m CPU: Pod ini dapat melakukan burst dan menggunakan tambahan 150m CPU. Kemudian, node memiliki 100 m CPU yang tersisa dari kapasitas burst yang tersedia.
  • Pod 2 memerlukan tambahan 200 mCPU: Pod ini dapat melakukan burst dan menggunakan 150 mCPU, sehingga total penggunaan menjadi 250 mCPU untuk Pod 2. Pod 2 memiliki batas CPU 250 m dan tidak dapat melampaui batas tersebut.

Cara GKE menangani Pod yang melebihi kapasitas yang dapat di-burst

Jika Pod yang dapat di-burst mencoba menggunakan lebih banyak resource daripada kapasitas yang dapat di-burst pada node, GKE akan melakukan tindakan berikut:

  • CPU: Jika penggunaan CPU melebihi kapasitas yang dapat di-burst, GKE akan membatasi penggunaan CPU beberapa container sehingga semua container di node mendapatkan CPU yang mereka minta.
  • Memori: Jika penggunaan memori melebihi kapasitas yang dapat di-burst, GKE akan menghentikan container untuk mengklaim kembali memori pada node. GKE dimulai 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 lonjakan memori agar berfungsi normal, container tersebut dapat terhenti berulang kali jika memori tersebut tidak tersedia.

Menggunakan bursting Pod dengan penyediaan kapasitas cadangan

GKE memungkinkan Anda men-deploy Pod dalam kondisi tidak ada aktivitas untuk mencadangkan kapasitas komputasi tambahan agar penskalaan Pod lebih cepat selama peristiwa traffic tinggi di masa mendatang seperti flash sale toko online. Pod lain di node yang sama dapat menggunakan kapasitas yang dipesan yang tidak terpakai ini sehingga kapasitas tidak menganggur pada waktu menjelang acara dengan traffic tinggi. 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 menghilangkan 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 yang dapat di-burst di cluster Standar, diperlukan perencanaan node dan bin-packing Pod yang lebih cermat, karena Anda membayar VM Compute Engine yang mendasarinya.

Pertimbangkan hal berikut di cluster Standar:

  • Batas konsumsi 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 batas pengusiran Kubernetes karena GKE tidak otomatis membatasi konsumsi resource jika Anda tidak menentukan batas. Oleh karena itu, Pod yang menggunakan memori secara berlebihan lebih mungkin dihentikan oleh Kubernetes karena pengusiran akibat tekanan node.

Langkah berikutnya