Permintaan resource di Autopilot


Untuk meningkatkan stabilitas workload, mode Autopilot Google Kubernetes Engine (GKE) mengelola nilai permintaan resource Pod, seperti CPU, memori, atau penyimpanan sementara. Halaman ini mencakup informasi berikut, yang dapat Anda gunakan untuk merencanakan workload yang efisien, stabil, dan hemat biaya:

  • Nilai default yang diterapkan Autopilot ke Pod yang tidak menentukan nilai.
  • Nilai minimum dan maksimum yang diterapkan Autopilot untuk permintaan resource.
  • Cara nilai default, minimum, dan maksimum bervariasi berdasarkan hardware yang diminta Pod Anda.

Halaman ini ditujukan bagi Operator dan Developer yang menyediakan dan mengonfigurasi resource cloud, serta men-deploy workload. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten, lihat Peran dan tugas pengguna GKE umum. Google Cloud

Anda seharusnya sudah memahami pengelolaan resource Kubernetes.

Ringkasan permintaan resource di Autopilot

Autopilot menggunakan permintaan resource yang Anda tentukan dalam konfigurasi workload untuk mengonfigurasi node yang menjalankan workload Anda. Autopilot menerapkan permintaan resource minimum dan maksimum berdasarkan class komputasi atau konfigurasi hardware yang digunakan workload Anda. Jika Anda tidak menentukan permintaan untuk beberapa container, Autopilot akan menetapkan nilai default agar container tersebut berjalan dengan benar.

Saat Anda men-deploy workload di cluster Autopilot, GKE memvalidasi konfigurasi workload berdasarkan nilai minimum dan maksimum yang diizinkan untuk class komputasi atau konfigurasi hardware yang dipilih (seperti GPU). Jika permintaan Anda kurang dari jumlah minimum, Autopilot akan otomatis mengubah konfigurasi workload Anda untuk membawa permintaan Anda dalam rentang yang diizinkan. Jika permintaan Anda lebih besar dari maksimum, Autopilot akan menolak workload Anda dan menampilkan pesan error.

Daftar berikut merangkum kategori permintaan resource:

  • Permintaan resource default: Autopilot menambahkan permintaan ini jika Anda tidak menentukan permintaan workload Anda sendiri
  • Permintaan resource minimum dan maksimum: Autopilot memvalidasi permintaan yang Anda tentukan untuk memastikan permintaan tersebut tidak melebihi batas ini. Jika permintaan Anda di luar batas, Autopilot akan mengubah permintaan workload Anda.
  • Pemisahan workload dan permintaan durasi yang diperpanjang: Autopilot memiliki nilai default yang berbeda dan nilai minimum yang berbeda untuk workload yang Anda pisahkan satu sama lain, atau untuk Pod yang mendapatkan perlindungan tambahan dari penghapusan yang dilakukan GKE.
  • Permintaan resource untuk DaemonSets: Autopilot memiliki nilai default, minimum, dan maksimum yang berbeda untuk container di DaemonSets.

Cara meminta resource

Dalam mode Autopilot, Anda meminta resource dalam spesifikasi Pod. Resource minimum dan maksimum yang didukung yang dapat Anda minta berubah berdasarkan konfigurasi hardware node tempat Pod berjalan. Untuk mempelajari cara meminta konfigurasi hardware tertentu, lihat halaman berikut:

Permintaan resource default

Jika Anda tidak menentukan permintaan resource untuk beberapa container dalam Pod, Autopilot akan menerapkan nilai default. Setelan default ini cocok untuk banyak workload yang lebih kecil.

Selain itu, Autopilot menerapkan permintaan resource default berikut, terlepas dari konfigurasi class komputasi atau hardware yang dipilih:

  • Container di DaemonSets

    • CPU: 50 mCPU
    • Memori: 100 MiB
    • Penyimpanan efemeral: 100 MiB
  • Semua container lainnya

    • Penyimpanan efemeral: 1 GiB

Untuk mengetahui informasi selengkapnya tentang batas cluster Autopilot, lihat Kuota dan batas.

Permintaan default untuk class komputasi

Autopilot menerapkan nilai default berikut ke resource yang tidak ditentukan dalam spesifikasi Pod untuk Pod yang berjalan di class komputasi. Jika Anda hanya menetapkan salah satu permintaan dan membiarkan yang lain kosong, GKE menggunakan rasio CPU:memori yang ditentukan di bagian Permintaan minimum dan maksimum untuk menetapkan permintaan yang tidak ada ke nilai yang sesuai dengan rasio.

Class komputasi Resource Permintaan default
Tujuan umum (default) CPU 0,5 vCPU
Memori 2 GiB
Akselerator Tidak ada permintaan default yang diterapkan.
Seimbang CPU 0,5 vCPU
Memori 2 GiB
Performa Tidak ada permintaan default yang diterapkan.
Penyebaran Skala CPU 0,5 vCPU
Memori 2 GiB

Permintaan resource minimum dan maksimum

Total resource yang diminta oleh konfigurasi deployment Anda harus berada dalam nilai minimum dan maksimum yang didukung yang diizinkan oleh Autopilot. Kondisi berikut berlaku:

  • Permintaan penyimpanan efemeral:

    • Penyimpanan efemeral menggunakan disk boot VM kecuali jika node Anda memiliki SSD lokal yang terpasang.

      Hardware komputasi yang mencakup SSD lokal seperti GPU A100 (80 GB), GPU H100 (80 GB), atau seri mesin Z3 mendukung permintaan maksimum yang sama dengan ukuran SSD lokal dikurangi overhead sistem. Untuk mengetahui informasi tentang overhead sistem ini, lihat Penyimpanan sementara yang didukung oleh SSD lokal.

    • Pada GKE versi 1.29.3-gke.1038000 dan yang lebih baru, Pod kelas Performa dan Pod akselerator hardware mendukung permintaan penyimpanan efemeral maksimum sebesar 56 TiB, kecuali jika hardware mencakup SSD lokal.

      Di semua Pod Autopilot lainnya, terlepas dari versi GKE, total permintaan penyimpanan efemeral di semua container dalam Pod harus antara 10 MiB dan 10 GiB, kecuali jika ditentukan lain.

    • Untuk volume yang lebih besar, gunakan volume efemeral generik, yang memberikan fungsionalitas dan performa yang setara dengan penyimpanan efemeral, tetapi dengan fleksibilitas yang jauh lebih besar karena dapat digunakan dengan opsi penyimpanan GKE apa pun. Misalnya, ukuran maksimum untuk volume efemeral generik yang menggunakan pd-balanced adalah 64 TiB.

  • Untuk Pod DaemonSet, permintaan resource minimum adalah sebagai berikut:

    • Cluster yang mendukung burst: 1 mCPU per Pod, 2 MiB memori per Pod, dan 10 MiB penyimpanan efemeral per container di Pod.
    • Cluster yang tidak mendukung bursting: 10 mCPU per Pod, memori 10 MiB per Pod, dan penyimpanan efemeral 10 MiB per container di Pod.

    Untuk memeriksa apakah cluster Anda mendukung lonjakan, lihat Ketersediaan lonjakan di GKE.

  • Jika cluster Anda mendukung bursting, Autopilot tidak menerapkan kenaikan 0,25 vCPU untuk permintaan CPU Pod Anda. Jika cluster Anda tidak mendukung bursting, Autopilot akan membulatkan permintaan CPU Anda ke 0,25 vCPU terdekat. Untuk memeriksa apakah cluster Anda mendukung bursting, lihat Ketersediaan bursting di GKE.

  • Rasio CPU:memori harus berada dalam rentang yang diizinkan untuk class komputasi atau konfigurasi hardware yang dipilih. Jika rasio CPU:memori Anda berada di luar rentang yang diizinkan, Autopilot akan otomatis meningkatkan resource yang lebih kecil. Misalnya, jika Anda meminta 1 vCPU dan memori 16 GiB (rasio 1:16) untuk Pod yang berjalan di class Scale-Out, Autopilot meningkatkan permintaan CPU menjadi 4 vCPU, yang mengubah rasionya menjadi 1:4.

Batas Minimum dan maksimum untuk class komputasi

Tabel berikut menjelaskan rasio CPU ke memori minimum, maksimum, dan yang diizinkan untuk setiap class komputasi yang didukung Autopilot:

Class komputasi Rasio CPU:memori (vCPU:GiB) Resource Minimum Maksimum
Tujuan umum (default) Antara 1:1 dan 1:6,5 CPU

Nilai bergantung pada apakah cluster Anda mendukung lonjakan, sebagai berikut:

  • Cluster yang mendukung bursting: 50 mCPU
  • Cluster yang tidak mendukung burst: 250m CPU

Untuk memeriksa apakah cluster Anda mendukung bursting, lihat Ketersediaan bursting di GKE.

30 vCPU
Memori

Nilai bergantung pada apakah cluster Anda mendukung lonjakan, sebagai berikut:

  • Cluster yang mendukung bursting: 52 MiB
  • Cluster yang tidak mendukung bursting: 512 MiB

Untuk memeriksa apakah cluster Anda mendukung bursting, lihat Ketersediaan bursting di GKE.

110 GiB
Akselerator Lihat Batas minimum dan maksimum untuk akselerator
Seimbang Antara 1:1 dan 1:8 CPU 0,25 vCPU

222 vCPU

Jika platform CPU minimum dipilih:

  • Platform Intel: 126 vCPU
  • Platform AMD: 222 vCPU
Memori 0,5 GiB

851 GiB

Jika platform CPU minimum dipilih:

  • Platform Intel: 823 GiB
  • Platform AMD: 851 GiB
Performa T/A CPU Tidak ada permintaan minimum yang diterapkan
  • Seri mesin C2: 58 vCPU
  • Seri mesin C2D: 110 vCPU
  • Seri mesin C3: 174 vCPU
  • Seri mesin C3 dengan SSD Lokal: 174 vCPU
  • Seri mesin C3D: 358 vCPU
  • Seri mesin C3D dengan SSD Lokal: 358 vCPU
  • Seri mesin C4D (1.33.0-gke.1439000 atau yang lebih baru): 382 vCPU
  • Seri mesin C4D dengan SSD Lokal (1.33.1-gke.1171000 atau yang lebih baru): 382 vCPU
  • Seri mesin H3: 86 vCPU
  • Seri mesin H4D (1.33.2-gke.4731000 atau yang lebih baru): 192 vCPU
  • Seri mesin T2A: 46 vCPU
  • Seri mesin T2D: 58 vCPU
  • Seri mesin C4: 286 vCPU
  • Seri mesin M4 (1.33.4-gke.1013000 atau yang lebih baru): 224 vCPU
  • Seri mesin N4: 78 vCPU
  • Seri mesin Z3: 174 vCPU
Memori Tidak ada permintaan minimum yang diterapkan
  • Seri mesin C2: 218 GiB
  • Seri mesin C2D: 835 GiB
  • Seri mesin C3: 1.345 GiB
  • Seri mesin C3 dengan SSD Lokal: 670 GiB
  • Seri mesin C3D: 2.750 GiB
  • Seri mesin C3D dengan SSD Lokal: 1.375 GiB
  • Seri mesin C4D (1.33.0-gke.1439000 atau yang lebih baru): 2.905 GiB
  • Seri mesin C4D dengan SSD Lokal (1.33.1-gke.1171000 atau yang lebih baru): 2.905 GiB
  • Seri mesin H3: 330 GiB
  • Seri mesin H4D (1.33.2-gke.4731000 atau yang lebih baru): 1.400 GiB
  • Seri mesin T2A: 172 GiB
  • Seri mesin T2D: 218 GiB
  • Seri mesin C4: 2.140 GiB
  • Seri mesin M4 (1.33.4-gke.1013000 atau yang lebih baru): 5.952 GiB
  • Seri mesin N4: 600 GiB
  • Seri mesin Z3: 34.000 GiB
Penyimpanan efemeral Tidak ada permintaan minimum yang diterapkan
  • Seri mesin C2: 56 TiB
  • Seri mesin C2D: 56 TiB
  • Seri mesin C3: 56 TiB
  • Seri mesin C3 dengan SSD Lokal: 10.000 GiB
  • Seri mesin C3D: 56 TiB
  • Seri mesin C3D dengan SSD Lokal: 10.000 GiB
  • Seri mesin C4D (1.33.0-gke.1439000 atau yang lebih baru): 56 TiB
  • Seri mesin C4D dengan SSD Lokal (1.33.1-gke.1171000 atau yang lebih baru): 10.000 GiB
  • Seri mesin H3: 56 TiB
  • Seri mesin H4D (1.33.2-gke.4731000 atau yang lebih baru): 56 Ti
  • Seri mesin T2A: 56 TiB
  • Seri mesin T2D: 56 TiB
  • Seri mesin C4: 56 TiB
  • Seri mesin M4 (1.33.4-gke.1013000 atau yang lebih baru): 56 TiB
  • Seri mesin N4: 56 TiB
  • Seri mesin Z3: 34.000 GiB
Penyebaran Skala Tepat 1:4 CPU 0,25 vCPU
  • arm64: 43 vCPU
  • amd64: 54 vCPU
Memori 1 GiB
  • arm64: 172 GiB
  • amd64: 216 GiB

Untuk mempelajari cara meminta class komputasi di Pod Autopilot, lihat Memilih class komputasi untuk Pod Autopilot.

Batas minimum dan maksimum untuk akselerator

GKE tidak menerapkan permintaan CPU, memori, atau penyimpanan sementara minimum untuk Pod yang menggunakan akselerator. Tabel berikut menjelaskan permintaan maksimum untuk setiap resource ini berdasarkan jumlah dan jenis akselerator yang Anda gunakan.

Kecuali ditentukan, penyimpanan efemeral maksimum yang didukung adalah 56 TiB.

Jenis akselerator Resource Maksimum
NVIDIA B200
nvidia-B200
CPU
  • 8 GPU: 224 vCPU
Memori
  • 8 GPU: 3.968 GiB
Penyimpanan efemeral
  • 8 GPU: 10 TiB
NVIDIA H200 (141GB)
nvidia-h200-141gb
CPU
  • 8 GPU: 224 vCPU
Memori
  • 8 GPU: 2.952 GiB
Penyimpanan efemeral
  • 8 GPU: 10 TiB (1.32.2-gke.1182000 atau yang lebih baru)
  • 8 GPU: 2.540 GiB (lebih lama dari 1.32.2-gke.1182000)
NVIDIA H100 Mega (80GB)
nvidia-h100-mega-80gb
CPU
  • 8 GPU: 206 vCPU
Memori
  • 8 GPU: 1.795 GiB
Penyimpanan efemeral
  • 8 GPU: 5.250 GiB
NVIDIA H100 (80GB)
nvidia-h100-80gb
CPU
  • 8 GPU: 206 vCPU
Memori
  • 8 GPU: 1.795 GiB
Penyimpanan efemeral
  • 8 GPU: 5.250 GiB
NVIDIA A100 (40GB)
nvidia-tesla-a100
CPU
  • 1 GPU: 11 vCPU
  • 2 GPU: 22 vCPU
  • 4 GPU: 46 vCPU
  • 8 GPU: 94 vCPU
  • 16 GPU: 94 vCPU

Jumlah permintaan CPU dari semua DaemonSets yang berjalan pada node GPU A100 tidak boleh lebih dari 2 vCPU.

Memori
  • 1 GPU: 74 GiB
  • 2 GPU: 148 GiB
  • 4 GPU: 310 GiB
  • 8 GPU: 632 GiB
  • 16 GPU: 1.264 GiB

Jumlah permintaan memori semua DaemonSets yang berjalan pada node GPU A100 tidak boleh melebihi 14 GiB.

NVIDIA A100 (80GB)
nvidia-a100-80gb
CPU
  • 1 GPU: 11 vCPU
  • 2 GPU: 22 vCPU
  • 4 GPU: 46 vCPU
  • 8 GPU: 94 vCPU

Jumlah permintaan CPU dari semua DaemonSets yang berjalan pada node GPU A100 (80 GB) tidak boleh lebih dari 2 vCPU.

Memori
  • 1 GPU: 148 GiB
  • 2 GPU: 310 GiB
  • 4 GPU: 632 GiB
  • 8 GPU: 1.264 GiB

Jumlah permintaan memori semua DaemonSets yang berjalan pada node GPU A100 (80 GB) tidak boleh melebihi 14 GiB.

Penyimpanan efemeral
  • 1 GPU: 280 GiB
  • 2 GPU: 585 GiB
  • 4 GPU: 1.220 GiB
  • 8 GPU: 2.540 GiB
NVIDIA L4
nvidia-l4
CPU
  • 1 GPU: 31 vCPU
  • 2 GPU: 23 vCPU
  • 4 GPU: 47 vCPU
  • 8 GPU: 95 vCPU

Jumlah permintaan CPU dari semua DaemonSets yang berjalan pada node GPU L4 tidak boleh lebih dari 2 vCPU.

Memori
  • 1 GPU: 115 GiB
  • 2 GPU: 83 GiB
  • 4 GPU: 177 GiB
  • 8 GPU: 363 GiB

Jumlah permintaan memori semua DaemonSets yang berjalan pada node GPU L4 tidak boleh melebihi 14 GiB.

NVIDIA Tesla T4
nvidia-tesla-t4
CPU
  • 1 GPU: 46 vCPU
  • 2 GPU: 46 vCPU
  • 4 GPU: 94 vCPU
Memori
  • 1 GPU: 287,5 GiB
  • 2 GPU: 287,5 GiB
  • 4 GPU: 587,5 GiB
TPU v5e
tpu-v5-lite-podslice
CPU
  • Topologi 1x1: 24 vCPU
  • Topologi 2x2: 112 vCPU
  • Topologi 2x4 (permintaan 4 chip): 112 vCPU
  • Topologi 2x4 (permintaan 8 chip): 224 vCPU
  • Topologi 4x4: 112 vCPU
  • Topologi 4x8: 112 vCPU
  • Topologi 8x8: 112 vCPU
  • Topologi 8x16: 112 vCPU
  • Topologi 16x16: 112 vCPU
Memori
  • Topologi 1x1: 48 GiB
  • Topologi 2x2: 192 GiB
  • Topologi 2x4 (permintaan 4 chip): 192 GiB
  • Topologi 2x4 (permintaan 8 chip): 384 GiB
  • Topologi 4x4: 192 GiB
  • Topologi 4x8: 192 GiB
  • Topologi 8x8: 192 GiB
  • Topologi 8x16: 192 GiB
  • Topologi 16x16: 192 GiB
Penyimpanan efemeral 56 TiB
TPU v5p
tpu-v5p-slice
CPU 280 vCPU
Memori 448 GiB
Penyimpanan efemeral 56 TiB
TPU v4
tpu-v4-podslice
CPU 240 vCPU
Memori 407 GiB
Penyimpanan efemeral 56 TiB

Untuk mempelajari cara meminta GPU di Pod Autopilot, lihat Men-deploy workload GPU di Autopilot.

Permintaan resource untuk pemisahan workload dan durasi yang diperpanjang

Dengan Autopilot, Anda dapat memanipulasi penjadwalan dan perilaku penggusuran Kubernetes menggunakan metode seperti berikut:

  • Gunakan taint dan toleransi serta pemilih node untuk memastikan Pod tertentu hanya ditempatkan di node tertentu. Untuk mengetahui detailnya, lihat Mengonfigurasi pemisahan workload di GKE.
  • Gunakan anti-afinitas Pod agar Pod tidak menemukan lokasi bersama di node yang sama. Permintaan resource default dan minimum bagi workload yang menggunakan metode ini untuk mengontrol perilaku penjadwalan lebih tinggi daripada workload yang tidak menggunakan metode ini.
  • Gunakan anotasi untuk melindungi Pod dari penghapusan yang disebabkan oleh upgrade otomatis node dan peristiwa penurunan skala hingga selama tujuh hari. Untuk mengetahui detailnya, lihat Memperpanjang runtime Pod Autopilot.

Jika permintaan yang Anda tentukan kurang dari jumlah minimum, perilaku Autopilot akan berubah berdasarkan metode yang Anda gunakan, sebagai berikut:

  • Taint, toleransi, pemilih, dan Pod dengan durasi yang diperpanjang: Autopilot mengubah Pod untuk meningkatkan permintaan saat menjadwalkan Pod.
  • Anti-afinitas Pod: Autopilot menolak Pod dan menampilkan pesan error.

Tabel berikut menjelaskan permintaan default dan permintaan resource minimum yang dapat Anda tentukan. Jika konfigurasi atau class komputasi tidak ada dalam tabel ini, Autopilot tidak akan menerapkan nilai minimum atau default khusus.

Class komputasi Resource Default Minimum
Tujuan umum CPU 0,5 vCPU 0,5 vCPU
Memori 2 GiB 0,5 GiB
Seimbang CPU 2 vCPU 1 vCPU
Memori 8 GiB 4 GiB
Penyebaran Skala CPU 0,5 vCPU 0,5 vCPU
Memori 2 GiB 2 GiB

Container init

Container init berjalan secara berurutan, dan semua container init harus selesai berjalan sebelum container aplikasi dapat dimulai. Di cluster Autopilot, jika Anda tidak menentukan permintaan CPU atau memori untuk container init atau secara eksplisit menetapkan permintaan ke 0, Autopilot akan mengubah Pod Anda selama pembuatan untuk menambahkan permintaan resource ke setiap container init. Permintaan yang ditetapkan ke setiap container init sama dengan jumlah permintaan untuk semua container aplikasi di Pod. Ini adalah perilaku default.

Perilaku ini berbeda dengan cluster Standar, yang memungkinkan container init menggunakan resource yang belum dialokasikan yang tersedia di node tempat Pod dijadwalkan.

Alokasi resource otomatis untuk container init

Alokasi resource otomatis untuk container init terjadi saat pembuatan Pod. Sebaiknya Anda tidak menentukan permintaan resource secara manual untuk container init di cluster Autopilot, sehingga setiap container mendapatkan resource penuh yang tersedia untuk Pod secara default.

Jika Anda mengubah permintaan resource container non-init di Pod setelah pembuatan, Autopilot tidak akan otomatis menyesuaikan permintaan resource container init. Akibatnya, Anda mungkin melihat biaya yang tidak konsisten dengan penggunaan resource sebenarnya dari Pod. Tagihan Anda didasarkan pada permintaan resource efektif Pod, yang merupakan nilai yang lebih besar dari berikut ini:

  • Permintaan resource terbesar dari satu container init dalam Pod.
  • Jumlah permintaan untuk semua container aplikasi di Pod.

Untuk mengetahui informasi selengkapnya, lihat Pengelolaan resource otomatis di Autopilot.

Alokasi resource manual untuk container init

Jika Anda perlu mengubah permintaan resource yang ada untuk container aplikasi guna mengelola biaya dan resource, sebaiknya lakukan salah satu hal berikut untuk menyesuaikan permintaan container init:

  • Perbarui permintaan resource secara manual untuk container init agar sesuai dengan total permintaan baru di Pod. Pertimbangkan hal-hal berikut saat menentukan permintaan resource secara manual:
    • Permintaan yang lebih rendah dari total resource Pod dapat membatasi container init.
    • Permintaan yang lebih tinggi dari total resource Pod dapat meningkatkan biaya.
  • Hapus permintaan resource agar Autopilot menghitung ulang permintaan tersebut. Autopilot akan secara default mengalokasikan ulang resource ke setiap container init berdasarkan total resource saat ini yang diminta oleh semua container aplikasi dalam Pod.

Menetapkan batas resource dalam Autopilot

Kubernetes dapat Anda gunakan untuk menetapkan requests dan limits untuk resource dalam spesifikasi Pod. Perilaku Pod Anda berubah, bergantung pada apakah limits Anda berbeda dengan requests, seperti yang dijelaskan dalam tabel berikut:

Nilai yang ditetapkan Perilaku Autopilot
requests sama dengan limits Pod menggunakan class QoS Guaranteed.
requests ditetapkan, limits belum ditetapkan

Perilakunya bergantung pada apakah cluster Anda mendukung lonjakan, sebagai berikut:

  • Cluster yang mendukung bursting: Pod dapat melakukan bursting ke kapasitas yang dapat di-burst yang tersedia.
  • Cluster yang tidak mendukung bursting: GKE menyetel limits sama dengan requests

Untuk memeriksa apakah cluster Anda mendukung bursting, lihat Ketersediaan bursting di GKE.

requests tidak ditetapkan, limits ditetapkan Autopilot menetapkan requests ke nilai limits, yang merupakan perilaku Kubernetes default.

Sebelum:

resources:
  limits:
    cpu: "400m"

Sesudah:

resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"
Lebih murah requests daripada limits

Perilakunya bergantung pada apakah cluster Anda mendukung lonjakan, sebagai berikut:

  • Cluster yang mendukung bursting: Pod dapat melakukan bursting hingga nilai yang ditentukan dalam limits.
  • Cluster yang tidak mendukung bursting: GKE menyetel limits sama dengan requests

Untuk memeriksa apakah cluster Anda mendukung bursting, lihat Ketersediaan bursting di GKE.

requests lebih besar dari limits Autopilot menetapkan requests ke nilai limits.

Sebelum:

resources:
  requests:
    cpu: "450m"
  limits:
    cpu: "400m"

Sesudah:

resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"
requests tidak ditetapkan, limits tidak ditetapkan

Autopilot menetapkan requests ke nilai default untuk konfigurasi hardware atau class komputasi.

Perilaku untuk limits bergantung pada apakah cluster Anda mendukung bursting atau tidak, sebagai berikut:

  • Cluster yang mendukung bursting: Autopilot tidak menetapkan limits.
  • Cluster yang tidak mendukung bursting: GKE menyetel limits sama dengan requests

Untuk memeriksa apakah cluster Anda mendukung bursting, lihat Ketersediaan bursting di GKE.

Dalam sebagian besar situasi, tetapkan permintaan resource yang memadai dan batas yang sama untuk workload Anda.

Untuk workload yang sementara memerlukan lebih banyak resource daripada kondisi stabilnya, seperti saat booting atau selama periode traffic yang lebih tinggi, tetapkan batas yang lebih tinggi daripada permintaan Anda agar Pod dapat melakukan bursting. Untuk mengetahui detailnya, lihat Mengonfigurasi bursting Pod di GKE.

Pengelolaan resource otomatis di Autopilot

Jika permintaan resource yang ditentukan untuk workload Anda berada di luar rentang yang diizinkan, atau jika Anda tidak meminta resource untuk beberapa container, Autopilot akan mengubah konfigurasi workload Anda untuk mematuhi batas yang diizinkan. Autopilot menghitung rasio resource dan persyaratan peningkatan skala resource setelah menerapkan nilai default ke container tanpa permintaan yang ditentukan.

  • Permintaan tidak ada: Jika Anda tidak meminta resource di beberapa container, Autopilot akan menerapkan permintaan default untuk class komputasi atau konfigurasi hardware.
  • Rasio CPU:memori: Autopilot meningkatkan skala resource yang lebih kecil untuk memasukkan rasio dalam rentang yang diizinkan.
  • Penyimpanan efemeral: Autopilot mengubah permintaan penyimpanan efemeral Anda untuk memenuhi jumlah minimum yang diperlukan oleh setiap container. Nilai kumulatif permintaan penyimpanan di semua container tidak boleh melebihi nilai maksimum yang diizinkan. Sebelum 1.28.6-gke.1317000, Autopilot menurunkan skala penyimpanan efemeral yang diminta jika nilainya melebihi maksimum. Pada versi 1.28.6-gke.1317000 dan yang lebih baru, Autopilot menolak workload Anda.
  • Permintaan di bawah batas minimum: Jika Anda meminta resource yang lebih sedikit dari jumlah minimum yang diizinkan untuk konfigurasi hardware yang dipilih, Autopilot akan otomatis mengubah Pod untuk meminta setidaknya nilai resource minimum.

Secara default, saat Autopilot meningkatkan skala resource secara otomatis untuk memenuhi nilai resource minimum atau default, GKE mengalokasikan kapasitas tambahan ke container pertama di manifes Pod. Pada GKE versi 1.27.2-gke.2200 dan yang lebih baru, Anda dapat meminta GKE untuk mengalokasikan resource tambahan ke container tertentu dengan menambahkan kode berikut ke kolom annotations di manifes Pod Anda:

autopilot.gke.io/primary-container: "CONTAINER_NAME"

Ganti CONTAINER_NAME dengan nama container.

Contoh modifikasi resource

Contoh skenario berikut menunjukkan cara Autopilot mengubah konfigurasi workload Anda untuk memenuhi persyaratan Pod dan container yang sedang berjalan.

Satu container dengan < 0,05 vCPU

Nomor container Permintaan asli Permintaan yang diubah
1 CPU: 30 mCPU
Memori: 0,5 GiB
Penyimpanan efemeral: 10 MiB
CPU: 50 mCPU
Memori: 0,5 GiB
Penyimpanan efemeral: 10 MiB

Beberapa container dengan total CPU < 0,05 vCPU

Nomor container Permintaan asli Permintaan yang diubah
1 CPU: 10 mCPU
Memori: 0,5 GiB
Penyimpanan efemeral: 10 MiB
CPU: 30 mCPU
Memori: 0,5 GiB
Penyimpanan efemeral: 10 MiB
2 CPU: 10 mCPU
Memori: 0,5 GiB
Penyimpanan efemeral: 10 MiB
CPU: 10 mCPU
Memori: 0,5 GiB
Penyimpanan efemeral: 10 MiB
3 CPU: 10 mvCPU
Memori: 0,5 GiB
Penyimpanan efemeral: 10 MiB
CPU: 10 mCPU
Memori: 0,5 GiB
Penyimpanan efemeral: 10 MiB
Total resource Pod CPU: 50 mCPU
Memori: 1,5 GiB
Penyimpanan efemeral: 30 MiB

Container tunggal dengan memori yang terlalu rendah untuk CPU yang diminta

Dalam contoh ini, memori terlalu rendah untuk jumlah CPU (minimum 1 vCPU:1 GiB). Rasio minimum yang diizinkan untuk CPU ke memori adalah 1:1. Jika rasionya lebih rendah dari itu, permintaan memori akan ditingkatkan.

Nomor container Permintaan asli Permintaan yang diubah
1 CPU: 4 vCPU
Memori: 1 GiB
Penyimpanan efemeral: 10 MiB
CPU: 4 vCPU
Memori: 4 GiB
Penyimpanan efemeral: 10 MiB
Total resource Pod CPU: 4 vCPU
Memori: 4 GiB
Penyimpanan efemeral: 10 MiB

Langkah berikutnya