Mengonfigurasi bursting Pod di GKE

Halaman ini menunjukkan cara mengonfigurasi Pod agar melakukan burst menjadi kapasitas yang tersedia dan tidak terpakai di node Google Kubernetes Engine (GKE).

Apa itu burst?

Bursting menjelaskan tindakan Pod yang menggunakan lebih banyak kapasitas komputasi pada 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 pada node yang memiliki kapasitas cukup untuk mengakomodasi permintaan resource tersebut.

Beberapa beban kerja tidak menggunakan 100% resource yang diminta selama seluruh runtime. Misalnya, beban kerja 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 beban kerja ke nilai yang lebih tinggi daripada permintaan resource atau tidak menetapkan batas tersebut. GKE memungkinkan workload untuk menggunakan lebih banyak resource untuk sementara daripada yang Anda tentukan dalam permintaan, jika kapasitas tersebut tersedia.

Untuk mengetahui informasi lebih lanjut mengenai cara kerja proses ini di GKE, baca Cara kerja bursting dalam dokumen ini.

Manfaat burst Pod

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

  • Anda memiliki kelompok workload yang sering kali 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.
  • Selama startup, workload Anda memerlukan lebih banyak resource daripada selama operasi normal.
  • Anda ingin memaksimalkan penggunaan kapasitas komputasi yang Anda sediakan.

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

  • Biaya pengoperasian yang lebih rendah: Anda tidak perlu meminta konsumsi resource puncak beban kerja yang diharapkan. Permintaan Anda dapat ditujukan untuk nilai status stabil yang lebih rendah. Di Autopilot, Anda membayar jumlah permintaan resource Pod, sehingga biaya pengoperasian Anda lebih rendah.
  • Penggunaan resource yang lebih efisien: Anda menghindari kapasitas komputasi tidak ada aktivitas karena Pod Anda meledak menjadi kapasitas yang tidak terpakai. Workload Anda cenderung menggunakan semua resource berbayar Anda.
  • Peningkatan performa: Pod dapat menggunakan resource tambahan sesuai kebutuhan untuk mengurangi waktu untuk memproses permintaan masuk, atau untuk melakukan booting lebih cepat selama peristiwa peningkatan skala.

Kapan sebaiknya tidak menggunakan burst

Kubernetes menetapkan class Quality of Service (QoS) Burstable ke Pod yang menentukan batas resource yang lebih tinggi dari permintaannya. Burstable Pod QoS cenderung dikeluarkan saat Kubernetes perlu memperoleh kembali resource di node. Untuk informasi selengkapnya, lihat Class QoS yang dapat mengalami 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 initialize 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.29.2-gke.1060000 atau yang lebih baru, atau cluster GKE Standard versi apa pun. Untuk membuat cluster baru, lihat Membuat cluster Autopilot.

Ketersediaan burst di GKE

Workload dapat burst dalam situasi berikut:

Ketersediaan burst
Mode Autopilot GKE

Pod yang menggunakan class komputasi Performance atau class komputasi Akselerator dapat melakukan burst dalam versi GKE apa pun yang mendukung class komputasi tersebut.

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

  • Awalnya Anda membuat cluster dengan GKE versi 1.26 atau yang lebih baru
  • Cluster menjalankan GKE versi 1.29.2-gke.1060000 atau yang lebih baru

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

Cluster Autopilot yang awalnya dibuat dengan versi lebih lama dari 1.26 dan kemudian diupgrade ke 1.29.2-gke.1060000 dan yang lebih baru tidak mendukung bursting. 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 burst untuk permintaan CPU dan memori.
  • Node dan pesawat kontrol autopilot harus menggunakan versi GKE yang didukung. Jika baru-baru ini Anda mengupgrade cluster ke versi yang didukung, pastikan node Anda menjalankan versi tersebut sebelum menggunakan burst.

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 diledakkan

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

    • resources.requests: Resource yang diperlukan container untuk berfungsi. Tetapkan nilai ini ke kapasitas yang akan diperlukan container Anda dalam keadaan stabil.
    • resources.limits: Kapasitas resource maksimum yang dapat digunakan container. Menyetel batas yang lebih tinggi dari permintaan akan memungkinkan Pod meledak hingga batas yang ditentukan jika kapasitas tersebut tersedia pada node. Jika kolom ini dihapus, Pod dapat menimbulkan burst hingga kapasitas yang dapat diledakkan yang tersedia pada node. Kapasitas ini dihitung sebagai berikut:
      • Mode autopilot: Kapasitas yang tidak terpakai dalam jumlah permintaan resource Pod pada node.
      • Mode standar: Kapasitas yang tidak digunakan dalam resource node.
    • spec.nodeSelector dan spec.tolerations: Opsional. Memberi tahu GKE untuk membuat node baru guna menjalankan Pod yang dapat di-burst. GKE menerapkan taint ke node baru ini untuk mencegah Pod lain, seperti beban kerja penting, 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

    Mungkin perlu waktu beberapa menit untuk memulai beban kerja.

  3. Memeriksa class QoS Pod:

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

    Output-nya adalah sebagai berikut:

    QoS Class: Burstable

Kapasitas burst di GKE

Untuk memfasilitasi bursting Pod, GKE menghitung kapasitas yang dapat meledak untuk setiap node dalam cluster. Perhitungan untuk node spesifik adalah sebagai berikut:

  • Cluster Autopilot: Jumlah permintaan resource dari semua Pod pada node tersebut, terlepas dari kapasitas resource node yang sebenarnya. Jika Pod dihentikan, kapasitas yang dapat diledak akan berkurang oleh permintaan Pod tersebut. Bagian dari kapasitas yang dapat di-burst yang tidak digunakan untuk menjalankan Pod dapat dialokasikan jika salah satu Pod perlu melakukan burst.

    Autopilot juga menambahkan buffer yang telah ditetapkan ke kapasitas yang dapat diledakkan, sehingga setiap Pod sistem pada node yang meledak di luar permintaannya tidak memengaruhi Pod milik Anda yang dapat diledakkan.

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

Praktik terbaik untuk bursting

Gunakan praktik berikut dengan bursting Pod:

  • Setel permintaan resource agar sama dengan batas Anda untuk setiap Pod yang menyediakan fungsi penting di lingkungan Anda. Hal ini memastikan bahwa Pod tersebut mendapatkan class Kubernetes Quality of Service (QoS) Guaranteed.
  • Pastikan Anda hanya mengonfigurasi burst memori pada Pod yang dapat menangani penghapusan saat Kubernetes perlu mendapatkan kembali memori pada node.
  • Selalu minta memori yang cukup agar Pod dapat melakukan booting. Jangan mengandalkan burst memori untuk memenuhi persyaratan booting Anda.
  • Untuk mencegah Pod yang dapat di-burst yang secara konsisten meledak ke beberapa permintaan CPU agar tidak berpotensi mengganggu beban kerja penting, gunakan pemisahan workload agar tidak menempatkan Pod tersebut bersama Pod penting Anda.

Mengoptimalkan kapasitas yang dapat diledakkan dalam node Autopilot

Autopilot menghitung kapasitas burst 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.

  • Guna meningkatkan kapasitas burst pada node untuk workload tertentu, gunakan Afinitas Pod untuk menempatkan Pod tertentu secara bersamaan di node yang sama.
  • Untuk memastikan kapasitas tertentu yang dapat diledakkan selalu tersedia di setiap node, buat DaemonSets untuk berjalan di semua node dalam cluster.

Contoh cara kerja burst

Bagian ini menggunakan contoh Deployment yang memiliki Pod yang dapat burst berikut untuk mendemonstrasikan cara kerja burst 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 200 m dan memiliki batas CPU 250 m. Pod 2 menggunakan CPU 100 m untuk berjalan.

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

Pertimbangkan skenario berikut saat lonjakan traffic terjadi:

  • Pod 1 memerlukan CPU tambahan 300 m: dapat melakukan burst dan menggunakan CPU 250 m, yang merupakan kapasitas burst yang tersedia yang tersedia. Node tidak lagi memiliki kapasitas burstable yang tersedia.
  • Pod 2 membutuhkan CPU tambahan 150 m: pod dapat meledak dan menggunakan CPU ekstra 150 m. Node tersebut kemudian memiliki 100 m CPU yang tersisa dari kapasitas yang dapat diledakkan yang tersedia.
  • Pod 2 memerlukan CPU tambahan sebesar 200 m: 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 melakukan burst di luar batas tersebut.

Cara GKE menangani Pod yang melebihi kapasitas yang dapat diledakkan

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

  • CPU: Jika penggunaan CPU melebihi kapasitas yang dapat diledakkan, GKE akan men-throttle penggunaan CPU pada beberapa container sehingga semua container di node mendapatkan CPU yang diminta.
  • Memori: Jika penggunaan memori melebihi kapasitas yang dapat diledakkan, GKE akan menghentikan container untuk memperoleh kembali memori pada node tersebut. GKE dimulai dengan menghentikan container yang memerlukan banyak resource di Pod dengan QoS yang lebih rendah.

Sebaiknya selalu minta memori yang cukup untuk operasi Pod normal. Jika container bergantung pada burst memori agar dapat berfungsi secara normal, container 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 guna mencadangkan kapasitas komputasi tambahan untuk penskalaan Pod yang lebih cepat selama peristiwa dengan traffic tinggi di masa mendatang seperti flash sale toko online. Pod lain pada node yang sama dapat meledak ke dalam kapasitas yang dicadangkan yang tidak terpakai ini sehingga kapasitas tersebut tidak nonaktif pada waktu menjelang peristiwa dengan traffic tinggi. Anda dapat mencadangkan 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 dengan cepat.

Pod burst di cluster GKE Standard

Cluster GKE Standard juga mendukung bursting Pod dengan menetapkan batas yang lebih tinggi dari permintaan atau dengan menghilangkan batas. Namun, dalam cluster Standar, Anda harus membuat dan mengonfigurasi node pool dengan kapasitas resource yang sesuai untuk mendukung burst. 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 untuk VM Compute Engine yang mendasarinya.

Pertimbangkan hal berikut di cluster Standar:

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

  • Penggunaan resource node pada cluster Standar lebih mungkin mencapai batas penghapusan Kubernetes karena GKE tidak secara otomatis membatasi konsumsi resource jika Anda tidak menentukan batasnya. Oleh karena itu, pod yang meledak ke dalam memori lebih mungkin dihentikan oleh penghilangan tekanan node Kubernetes.

Langkah selanjutnya