Menyesuaikan konfigurasi sistem node

Standard

Dokumen ini menunjukkan cara menyesuaikan konfigurasi node Google Kubernetes Engine (GKE) menggunakan file konfigurasi yang disebut konfigurasi sistem node.

Konfigurasi sistem node adalah file konfigurasi yang menyediakan cara untuk menyesuaikan serangkaian setelan sistem dalam jumlah terbatas. Di node pool, Anda dapat menggunakan konfigurasi sistem node untuk menentukan setelan kustom bagi agen node Kubernetes kubelet dan untuk konfigurasi kernel Linux level rendah sysctl.

Perhatian: Mengubah setelan kubelet atau sysctl dapat menimbulkan perilaku yang tidak diinginkan yang mungkin berdampak negatif terhadap responsivitas workload dan node Anda. Uji secara ekstensif setiap perubahan kubelet atau sysctl sebelum Anda men-deploy-nya pada workload produksi.

Dokumen ini menjelaskan konfigurasi yang tersedia untuk konfigurasi sistem node dan cara menerapkannya ke node pool GKE Standard Anda. Perhatikan bahwa karena cluster GKE Autopilot memiliki lingkungan node yang lebih terkelola, opsi konfigurasi sistem node langsungnya terbatas dibandingkan dengan node pool GKE Standard.

Alasan menggunakan konfigurasi sistem node

Konfigurasi sistem node menawarkan manfaat berikut:

• Penyesuaian performa: mengoptimalkan performa stack jaringan, pengelolaan memori, penjadwalan CPU, atau perilaku I/O untuk aplikasi yang menuntut seperti pelatihan atau inferensi AI, database, server web dengan traffic tinggi, atau layanan yang sensitif terhadap latensi.
• Hardening keamanan: menerapkan setelan keamanan tingkat kernel tertentu atau membatasi perilaku sistem tertentu untuk mengurangi permukaan serangan.
• Pengelolaan resource: menyesuaikan cara kubelet mengelola PID, kapasitas disk, pembersihan sampah memori image, atau resource CPU dan memori.
• Kompatibilitas workload: membantu memastikan bahwa lingkungan node memenuhi prasyarat tertentu untuk software khusus atau aplikasi lama yang memerlukan setelan kernel tertentu.

Opsi lain untuk menyesuaikan konfigurasi node

Anda juga dapat menyesuaikan konfigurasi node menggunakan metode lain:

• File konfigurasi runtime: untuk menyesuaikan runtime container containerd di node GKE, Anda dapat menggunakan file lain yang disebut file konfigurasi runtime. Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan konfigurasi containerd di node GKE.
• ComputeClass: Anda dapat menentukan atribut node dalam spesifikasi ComputeClass GKE. Anda dapat menggunakan ComputeClass, baik dalam mode GKE Autopilot maupun mode Standard, di GKE versi 1.32.1-gke.1729000 dan yang lebih baru. Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan konfigurasi sistem node.
• DaemonSets: Anda juga dapat menggunakan DaemonSets untuk menyesuaikan node. Untuk informasi selengkapnya, lihat Melakukan bootstrap node GKE secara otomatis dengan DaemonSets.

Konfigurasi sistem node tidak didukung di node Windows Server.

Sebelum memulai

Sebelum memulai, pastikan Anda melakukan hal berikut:

• Instal alat command line:
  • Jika Anda menggunakan contoh gcloud CLI dalam dokumen ini, pastikan Anda menginstal dan mengonfigurasi Google Cloud CLI.
  • Jika Anda menggunakan contoh Terraform, pastikan Anda menginstal dan mengonfigurasi Terraform.
• Memberikan izin: Anda memerlukan izin IAM yang sesuai untuk membuat dan mengupdate cluster dan node pool GKE, seperti container.clusterAdmin atau peran lain dengan izin yang setara.
• Rencanakan potensi gangguan workload: konfigurasi node kustom diterapkan di tingkat node pool. Perubahan biasanya memicu update bertahap pada node di pool, yang melibatkan pembuatan ulang node. Rencanakan potensi gangguan workload dan gunakan Pod Disruption Budget (PDB) jika sesuai.
• Cadangkan dan uji semua perubahan: selalu uji perubahan konfigurasi di lingkungan staging atau lingkungan pengembangan sebelum Anda menerapkannya ke produksi. Setelan yang salah dapat menyebabkan ketidakstabilan node atau kegagalan workload.
• Tinjau setelan default GKE: Image node GKE dilengkapi dengan konfigurasi default yang dioptimalkan. Hanya sesuaikan parameter jika Anda memiliki kebutuhan khusus dan memahami dampak perubahan Anda.

Menambahkan konfigurasi sistem node

Anda dapat menyesuaikan konfigurasi sistem node menggunakan ComputeClass atau file konfigurasi.

Menggunakan ComputeClass untuk konfigurasi sistem node

Anda dapat menggunakan ComputeClass kustom untuk menyesuaikan parameter tertentu di kubelet dan kernel Linux. Metode ini tersedia di GKE versi 1.32.1-gke.1729000 dan yang lebih baru.

Untuk menggunakan ComputeClass guna menyesuaikan konfigurasi sistem node, lakukan hal berikut:

1. Buat ComputeClass yang menyertakan pasangan nilai kolom spec.nodePoolAutoCreation.enabled: true dan tentukan konfigurasi sistem di kolom priorityDefaults.
2. Deploy workload yang memilih ComputeClass.

Membuat ComputeClass

Tulis konfigurasi ComputeClass Anda di YAML. Gunakan kolom nodeSystemConfig di dalam spesifikasi priorityDefaults untuk menetapkan konfigurasi sistem di semua prioritas.

Contoh ComputeClass berikut mengonfigurasi kebijakan pengelola CPU statis dan parameter kernel kustom:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-sysconfig
spec:
  nodePoolAutoCreation:
    enabled: true
  priorityDefaults:
    nodeSystemConfig:
      kubeletConfig:
        cpuManagerPolicy: static
      linuxNodeConfig:
        sysctls:
          net.core.somaxconn: 2048
  priorities:
  - machineFamily: n4

Terapkan ComputeClass:

kubectl apply -f custom-sysconfig.yaml

Men-deploy workload yang memilih ComputeClass

Dalam spesifikasi Pod, tambahkan pemilih node untuk nama ComputeClass:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        cloud.google.com/compute-class: custom-sysconfig
      containers:
      - name: app-container
        image: nginx

Terapkan workload:

kubectl apply -f my-app.yaml

Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan konfigurasi sistem node.

Menggunakan file konfigurasi untuk konfigurasi sistem node

Saat menggunakan file konfigurasi sistem node, Anda menggunakan file YAML yang berisi parameter konfigurasi untuk kubelet dan kernel Linux. Meskipun konfigurasi sistem node juga tersedia dalam mode GKE Autopilot, langkah-langkah dalam dokumen ini menunjukkan cara membuat dan menggunakan file konfigurasi untuk mode GKE Standard.

Untuk menggunakan file konfigurasi sistem node dalam mode GKE Standard, lakukan hal berikut:

1. Buat file konfigurasi. File ini berisi konfigurasi kubelet dan sysctl Anda.
2. Tambahkan konfigurasi saat Anda membuat cluster atau node pool, atau perbarui node pool yang ada.

Membuat file konfigurasi

Tulis konfigurasi sistem node Anda di YAML. Contoh berikut menambahkan konfigurasi untuk opsi kubelet dan sysctl:

kubeletConfig:
  cpuManagerPolicy: static
  allowedUnsafeSysctls:
    - 'kernel.shm*'
    - 'kernel.msg*'
    - 'kernel.sem'
    - 'fs.mqueue.*'
    - 'net.*'
linuxConfig:
  sysctl:
    net.core.somaxconn: '2048'
    net.ipv4.tcp_rmem: '4096 87380 6291456'
  kernelOverrides:
    kernelCommandlineOverrides:
      specRstackOverflow: 'SPEC_RSTACK_OVERFLOW_OFF'
      initOnAlloc: 'INIT_ON_ALLOC_OFF'

Dalam contoh ini, hal berikut berlaku:

• Kolom cpuManagerPolicy: static mengonfigurasi kubelet untuk menggunakan kebijakan pengelolaan CPU statis.
• Kolom net.core.somaxconn: '2048' membatasi backlog socket listen() hingga 2.048 byte.
• Kolom net.ipv4.tcp_rmem: '4096 87380 6291456' menetapkan nilai minimum, default, dan maksimum soket TCP yang menerima buffer, berturut-turut, ke 4.096 byte, 87.380 byte, dan 6.291.456 byte.
• Blok kernelCommandlineOverrides menonaktifkan mitigasi speculative return stack overflow (SRSO) dan parameter kernel init_on_alloc.

Jika Anda hanya ingin menambahkan konfigurasi untuk kubelet atau sysctl, sertakan bagian itu saja dalam konfigurasi sistem node Anda. Misalnya, untuk menambahkan konfigurasi kubelet, buat file berikut:

kubeletConfig:
  cpuManagerPolicy: static

Untuk mengetahui daftar lengkap kolom yang dapat Anda tambahkan ke konfigurasi sistem node, lihat bagian Opsi konfigurasi Kubelet dan Opsi konfigurasi Sysctl.

Menambahkan konfigurasi ke node pool Standard

Setelah Anda membuat konfigurasi sistem node, tambahkan flag --system-config-from-file menggunakan Google Cloud CLI. Anda dapat menambahkan flag ini saat membuat cluster atau node pool, atau saat mengupdate node pool yang ada. Anda tidak dapat menambahkan konfigurasi sistem node menggunakan konsol Google Cloud .

Membuat cluster dengan konfigurasi sistem node

Anda dapat menambahkan konfigurasi sistem node selama pembuatan cluster menggunakan gcloud CLI atau Terraform. Petunjuk berikut menerapkan konfigurasi sistem node ke node pool default:

gcloud CLI

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Ganti kode berikut:

• CLUSTER_NAME: nama cluster Anda
• LOCATION: zona atau region komputasi cluster
• SYSTEM_CONFIG_PATH: jalur ke file yang berisi konfigurasi kubelet dan sysctl

Setelah Anda menerapkan konfigurasi sistem node, node pool default cluster akan menggunakan setelan yang Anda tentukan.

Terraform

Untuk membuat cluster regional dengan konfigurasi sistem node yang disesuaikan menggunakan Terraform, lihat contoh berikut:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-central1"

  initial_node_count = 1

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Untuk mengetahui informasi selengkapnya tentang cara menggunakan Terraform, lihat Dukungan Terraform untuk GKE.

Membuat node pool baru dengan konfigurasi sistem node

Anda dapat menambahkan konfigurasi sistem node saat menggunakan gcloud CLI atau Terraform untuk membuat node pool baru.

Petunjuk berikut menerapkan konfigurasi sistem node ke node pool baru:

gcloud CLI

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --location=LOCATION \
     --system-config-from-file=SYSTEM_CONFIG_PATH

Ganti kode berikut:

• POOL_NAME: nama node pool Anda
• CLUSTER_NAME: nama cluster yang ingin Anda tambahi node pool
• LOCATION: zona atau region komputasi cluster
• SYSTEM_CONFIG_PATH: jalur ke file yang berisi konfigurasi kubelet dan sysctl

Terraform

Untuk membuat node pool dengan konfigurasi sistem node yang disesuaikan menggunakan Terraform, lihat contoh berikut:

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Untuk mengetahui informasi selengkapnya tentang cara menggunakan Terraform, lihat Dukungan Terraform untuk GKE.

Memperbarui konfigurasi sistem node untuk node pool yang ada

Jika menggunakan file konfigurasi untuk mengelola konfigurasi sistem node, Anda dapat mengupdate node pool yang ada dengan salah satu cara berikut:

• Update langsung tanpa gangguan: menerapkan setelan sysctl dan kubelet yang telah diupdate langsung ke node yang sedang berjalan tanpa membuat ulang VM atau mengeluarkan Pod. Gunakan metode ini jika Anda hanya mengubah setelan sysctl atau kubelet dan ingin meminimalkan gangguan.
• Strategi upgrade Standard: membuat ulang node dengan konfigurasi baru. Gunakan metode ini saat Anda mengubah setelan yang tidak mendukung live update, saat cluster atau node pool Anda menjalankan GKE versi sebelum 1.37.1-gke.1954000, atau saat Anda ingin GKE mengosongkan dan menjadwalkan ulang Pod ke node baru.

Untuk mengubah konfigurasi node yang menggunakan ComputeClass, lihat Mengedit konfigurasi sistem node untuk ComputeClass.

Perhatian: Dengan kedua metode tersebut, menyertakan bagian kubeletConfig atau linuxConfig dalam file Anda akan menggantikan seluruh bagian konfigurasi node pool yang ada. Setiap parameter yang Anda hapus dari bagian yang disertakan akan direset ke nilai defaultnya. Selama update langsung, menghilangkan parameter yang dikonfigurasi sebelumnya yang tidak mendukung update langsung (seperti cpuManagerPolicy atau cgroupMode) akan menyebabkan GKE menolak update. Sebelum mengupdate, dapatkan konfigurasi sistem node yang ada dan sertakan setiap setelan yang ingin Anda pertahankan.

Mengupdate menggunakan update langsung yang tidak mengganggu

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Anda dapat menerapkan setelan sysctl dan kubelet yang telah diupdate dari file konfigurasi langsung ke node yang sedang berjalan. Karena proses ini memperbarui parameter tanpa membuat ulang atau memulai ulang VM yang mendasarinya, proses ini mengurangi gangguan dan mempercepat update. Opsi linuxConfig berikut masih memerlukan strategi upgrade standar:

• Mode cgroup Linux
• Hugepages Linux
• Sinkronisasi waktu akurat Linux
• VFIO Linux
• Penjadwal I/O disk Linux

Cara kerja live update

Live update berfungsi sebagai berikut untuk setiap konfigurasi yang didukung:

• Konfigurasi sysctl: GKE memulai ulang layanan systemd sysctl di setiap node untuk menerapkan parameter kernel di kolom linuxConfig.sysctl. Jika Anda memperbarui parameter sysctl dengan namespace, GKE juga akan memulai ulang layanan kubelet untuk memperbarui konfigurasi sysctl level Pod. Untuk parameter yang didukung, lihat Opsi konfigurasi Sysctl.
• Konfigurasi kubelet: GKE memulai ulang layanan kubelet di setiap node untuk menerapkan parameter di kolom kubeletConfig. Sebagian besar opsi konfigurasi kubelet mendukung live update. Namun, opsi cpuManagerPolicy, shutdownGracePeriodSeconds, dan shutdownGracePeriodCriticalPodsSeconds memerlukan strategi upgrade standar.

Dalam kedua kasus tersebut, GKE menerapkan perubahan di tempat pada node yang berjalan tanpa membuat ulang VM, mengeluarkan Pod, atau membuat VM lonjakan sementara. GKE menggunakan jumlah setelan --max-surge-upgrade dan --max-unavailable-upgrade node pool Anda sebagai batas konkurensi untuk menentukan jumlah node yang ada yang diupdate secara paralel.

Prasyarat untuk live update

Untuk menggunakan live update, cluster dan node pool Anda harus memenuhi prasyarat berikut:

• Menjalankan GKE versi 1.37.1-gke.1954000 atau yang lebih baru.
• Aktifkan add-on NodeReadinessController di cluster. Selama update langsung, pengontrol ini menerapkan taint readiness.k8s.io/gke-node-live-update-reconciling:NoSchedule untuk sementara ke setiap node yang sedang diupdate sehingga GKE tidak menjadwalkan Pod baru ke node tersebut hingga update selesai:
  • Untuk cluster baru, sertakan add-on NodeReadinessController dalam flag --addons selama pembuatan cluster. Flag ini hanya mengaktifkan add-on yang Anda tentukan dan menonaktifkan semua add-on lainnya, jadi sertakan juga add-on default yang ingin Anda pertahankan.
  • Untuk cluster yang ada, teruskan flag --update-addons=NodeReadinessController=ENABLED selama update cluster.

Menerapkan live update

Untuk menerapkan live update, lakukan hal berikut:

1. Buat atau ubah file YAML konfigurasi sistem node Anda agar berisi konfigurasi lengkap node pool, termasuk setelan kubelet atau sysctl yang ingin Anda ubah. Agar tidak mereset setelan yang tidak ingin Anda ubah, mulailah dari konfigurasi yang ada pada node pool.

2. Update node pool dengan file konfigurasi Anda dan tetapkan nilai flag --node-config-update-mode ke LIVE_UPDATE_WITHOUT_DRAIN:

   gcloud container node-pools update POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --system-config-from-file=SYSTEM_CONFIG_PATH \
       --node-config-update-mode=LIVE_UPDATE_WITHOUT_DRAIN
   

   Ganti kode berikut:

   • POOL_NAME: nama node pool yang ingin Anda perbarui
   • CLUSTER_NAME: nama cluster yang berisi node pool
   • LOCATION: zona atau region komputasi cluster
   • SYSTEM_CONFIG_PATH: jalur ke file YAML yang berisi konfigurasi sistem node Anda

3. Pastikan GKE telah menerapkan setelan yang diperbarui ke node pool Anda:

   gcloud container node-pools describe POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --format="yaml(config.kubeletConfig, config.linuxNodeConfig)"
   

   Output perintah menampilkan setelan aktif pada node pool di kolom config.kubeletConfig dan config.linuxNodeConfig.

4. Opsional: mulai ulang Pod yang ada. Live update tidak mengganggu Pod yang sedang berjalan, sehingga GKE hanya menerapkan setelan yang diperbarui ke Pod yang dimulai setelah update selesai. Untuk menerapkan setelan ke workload yang sudah berjalan, mulai ulang Pod-nya, misalnya dengan menjalankan kubectl rollout restart pada Deployment.

Jika live update tidak berjalan seperti yang diharapkan, jalur pemulihan bergantung pada apakah operasi update telah selesai:

• Jika operasi update langsung gagal, lihat Memulihkan dari update langsung yang gagal.
• Jika operasi update langsung berhasil, tetapi setelan baru menyebabkan perilaku workload yang tidak diinginkan, lihat Mengembalikan update langsung yang telah selesai.

Memulihkan dari update live yang gagal

Jika update langsung gagal pada sebuah node, GKE akan segera menghentikan peluncuran dan membiarkan node pool dalam status diupdate sebagian. Untuk memeriksa detail kegagalan, lakukan salah satu hal berikut:

• Jalankan perintah gcloud container operations describe. Dalam output, kolom statusMessage mengidentifikasi node tempat live update gagal dan error yang dilaporkan node, misalnya:

  statusMessage: 'Failed precondition: live update failed on node gke-my-cluster-default-pool-ae3770ee-2kk0:
    Live update fails with error: failed to write new kubelet config: ...'
  

• Di Logs Explorer, periksa error dari komponen gke-node-live-update-reconciler pada node yang terpengaruh.

Karena update langsung yang gagal tidak mengubah konfigurasi tersimpan node pool, menerapkan kembali konfigurasi sebelumnya dengan perintah gcloud container node-pools update tidak akan memicu update. Setelah Anda memeriksa kegagalan, pilih salah satu opsi pemulihan berikut:

• Perbaiki masalah dan selesaikan update langsung (direkomendasikan): selesaikan masalah yang menyebabkan kegagalan, lalu jalankan kembali perintah gcloud container node-pools update dari prosedur sebelumnya dengan konfigurasi target Anda.
• Kembalikan ke konfigurasi sebelumnya: jika Anda tidak dapat menyelesaikan masalah, jalankan perintah gcloud container node-pools rollback untuk mengembalikan node pool ke konfigurasi sebelumnya. Tidak seperti live update, perintah ini membuat ulang semua node di node pool, yang mengganggu workload yang berjalan di dalamnya.

Mengembalikan live update yang telah selesai

Jika operasi update langsung berhasil, tetapi setelan yang baru diterapkan menyebabkan perilaku workload yang tidak diinginkan, kembalikan perubahan yang ada dengan menerapkan update langsung lainnya dengan konfigurasi sebelumnya. Live update ini memulihkan konfigurasi sebelumnya tanpa mengeluarkan Pod atau memulai ulang node. Perintah gcloud container node-pools rollback tidak tersedia setelah operasi berhasil; perintah ini hanya berfungsi jika operasi gagal.

Untuk mengembalikan live update yang telah selesai, lakukan hal berikut:

1. Perbarui file YAML konfigurasi sistem node Anda agar berisi konfigurasi lengkap node pool sebelumnya. Jika setelan belum dikonfigurasi sebelumnya, tetapkan secara eksplisit ke nilai defaultnya, bukan menghilangkannya atau membiarkan bagian tersebut kosong. Untuk mengetahui nilai default, lihat Opsi konfigurasi Kubelet dan Opsi konfigurasi Sysctl.

2. Terapkan konfigurasi sebelumnya ke node pool Anda:

   gcloud container node-pools update POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --system-config-from-file=SYSTEM_CONFIG_PATH \
       --node-config-update-mode=LIVE_UPDATE_WITHOUT_DRAIN
   

Mengupdate menggunakan strategi upgrade standar

Gunakan strategi upgrade standar jika Anda mengupdate opsi konfigurasi yang tidak mendukung live update, jika cluster atau node pool Anda menjalankan versi GKE yang lebih lama dari 1.37.1-gke.1954000, atau jika Anda ingin GKE mengosongkan dan menjadwalkan ulang Pod Anda secara otomatis ke node yang baru dibuat.

Untuk mengupdate node pool yang sudah ada menggunakan strategi upgrade standar, jalankan perintah berikut:

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Ganti kode berikut:

• POOL_NAME: nama node pool yang Anda ingin perbarui
• CLUSTER_NAME: nama cluster yang berisi node pool
• LOCATION: zona atau region komputasi cluster
• SYSTEM_CONFIG_PATH: jalur ke file YAML yang berisi konfigurasi sistem node Anda

Perubahan ini memerlukan pembuatan ulang node, yang dapat menyebabkan gangguan pada workload yang sedang berjalan. Untuk mengetahui informasi selengkapnya tentang perubahan spesifik ini, temukan baris yang sesuai dalam tabel perubahan manual yang membuat ulang node menggunakan strategi upgrade node tanpa mematuhi kebijakan pemeliharaan.

Untuk mengetahui informasi selengkapnya tentang update node, lihat Merencanakan gangguan update node.

Perhatian: GKE segera mulai membuat ulang node untuk perubahan ini menggunakan strategi upgrade node, terlepas dari kebijakan pemeliharaan yang aktif. GKE bergantung pada ketersediaan resource untuk perubahan. Menonaktifkan upgrade otomatis node tidak akan mencegah perubahan ini.

Mengedit konfigurasi sistem node

Anda dapat mengedit konfigurasi sistem node, bergantung pada apakah Anda menggunakan ComputeClass atau file konfigurasi.

Untuk ComputeClass

Untuk mengedit konfigurasi sistem node saat menggunakan ComputeClasses, pilih salah satu metode berikut:

Metode 1: Mengupdate ComputeClass yang ada

Jika Anda mengupdate nodeSystemConfig di ComputeClass yang ada, GKE akan menerapkan konfigurasi yang diupdate hanya ke node yang baru dibuat. Node yang ada tidak diupdate secara otomatis.

Untuk memigrasikan workload ke node dengan konfigurasi baru, Anda dapat melakukan salah satu hal berikut:

• Konfigurasikan migrasi aktif di ComputeClass Anda.
• Untuk memicu peningkatan skala node baru, mulai ulang atau buat ulang workload Anda secara manual.

Untuk memperbarui ComputeClass, edit file YAML dan terapkan:

kubectl apply -f custom-sysconfig.yaml

Metode 2: Membuat ComputeClass baru

Untuk membantu memastikan workload Anda dimigrasikan ke node baru dengan konfigurasi yang telah diupdate, lakukan hal berikut:

1. Buat ComputeClass baru dengan nama yang berbeda dan konfigurasi yang diperbarui.
2. Perbarui pemilih node dalam spesifikasi workload Anda untuk mereferensikan ComputeClass baru.
3. Terapkan spesifikasi workload yang telah diperbarui. Autoscaler cluster akan menyediakan node baru dengan konfigurasi baru dan pada akhirnya memperkecil skala node lama.
4. Hapus objek ComputeClass lama.

Untuk file konfigurasi

Untuk mengedit konfigurasi sistem node saat menggunakan file konfigurasi, Anda dapat membuat node pool baru dengan konfigurasi yang diinginkan, atau memperbarui konfigurasi sistem node untuk node pool yang ada.

Mengedit dengan membuat node pool

Untuk mengedit konfigurasi sistem node dengan membuat node pool, lakukan hal berikut:

1. Buat file konfigurasi dengan konfigurasi yang Anda inginkan.
2. Tambahkan konfigurasi ke node pool baru.
3. Migrasikan workload Anda ke node pool baru.
4. Hapus node pool lama.

Mengedit dengan memperbarui node pool yang ada

Untuk mengubah konfigurasi sistem node dari node pool yang ada, lihat Memperbarui konfigurasi sistem node untuk node pool yang ada.

Mendapatkan konfigurasi sistem node yang ada

Untuk mengambil konfigurasi sistem node yang ada di node pool Anda—misalnya, jika Anda telah menyesuaikan konfigurasi dan ingin menambahkannya—gunakan perintah gcloud container node-pools describe. Output perintah mencantumkan konfigurasi yang ada di bagian kubeletConfig dan linuxNodeConfig.

Perhatian: Saat mengupdate konfigurasi node Linux berdasarkan output ini, Anda harus menentukan parameter di kolom linuxConfig dalam perintah update. Perintah describe menampilkan setelan ini di bagian linuxNodeConfig, tetapi untuk update, kolom yang benar adalah linuxConfig. Menggunakan kolom output linuxNodeConfig dalam permintaan update tidak akan menerapkan perubahan.

Misalnya, lihat cuplikan berikut yang menunjukkan format output dari perintah describe:

  kubeletConfig:
    allowedUnsafeSysctls:
    - kernel.shm*
    - kernel.msg*
    - kernel.sem
    - fs.mqueue.*
    - net.*
    cpuManagerPolicy: static
    insecureKubeletReadonlyPortEnabled: false
    maxParallelImagePulls: 2
  linuxNodeConfig: # IMPORTANT: Use linuxConfig when updating these settings
    sysctl:
      net.core.somaxconn: '2048'
      net.ipv4.tcp_rmem: 4096 87380 6291456

Jika Anda belum menetapkan konfigurasi sistem node, output tidak akan mencantumkan kubeletConfig atau linuxNodeConfig.

Mereset konfigurasi sistem node yang ada

Jika Anda ingin mereset konfigurasi sistem node kembali ke default-nya, update file konfigurasi Anda dengan nilai kosong untuk kolom kubelet dan sysctl, misalnya:

```yaml
kubeletConfig: {}
linuxConfig:
  sysctl: {}
```

Menghapus konfigurasi sistem node

Untuk menghapus konfigurasi sistem node, ikuti langkah-langkahnya, bergantung pada apakah Anda menggunakan ComputeClass atau file konfigurasi.

Untuk ComputeClass

Untuk menghapus konfigurasi sistem node kustom, lakukan hal berikut:

1. Hapus pemilih node cloud.google.com/compute-class dari spesifikasi workload Anda.
2. Terapkan spesifikasi workload yang telah diperbarui. GKE membuat ulang workload di node default. Autoscaler cluster pada akhirnya akan memperkecil skala dan menghapus node yang disediakan untuk ComputeClass.

3. Hapus objek ComputeClass dari cluster:

   kubectl delete computeclass CUSTOM_COMPUTE_CLASS_NAME
   

Untuk file konfigurasi

Untuk menghapus konfigurasi sistem node yang diterapkan menggunakan file konfigurasi, lakukan hal berikut:

1. Buat node pool baru tanpa file konfigurasi.
2. Migrasikan workload Anda ke node pool baru.
3. Hapus node pool yang berisi konfigurasi sistem node lama.

Opsi konfigurasi untuk kubelet

Tabel di bagian ini menjelaskan opsi kubelet yang dapat Anda ubah.

Pengelolaan CPU

Tabel berikut menjelaskan opsi pengelolaan CPU untuk kubelet.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
cpuCFSQuota	Harus berupa true atau false.	true	Setelan ini memberlakukan batas CPU Pod. Jika nilai ini ditetapkan ke false, batas CPU untuk Pod akan diabaikan. Dalam skenario tertentu, batas CPU dapat diabaikan jika Pod sensitif terhadap batas CPU. Risiko menonaktifkan cpuCFSQuota adalah bahwa Pod yang bermasalah dapat memakai resource CPU lebih banyak daripada yang semestinya.
cpuCFSQuotaPeriod	Harus berupa durasi waktu.	"100ms"	Setelan ini menetapkan nilai periode kuota CFS CPU, cpu.cfs_period_us, yang menentukan periode seberapa sering akses cgroup ke resource CPU harus dialokasikan ulang. Dengan opsi ini, Anda dapat menyesuaikan perilaku throttling CPU.
reservedSystemCPUs (Pratinjau)	Harus berupa daftar core CPU tertentu yang akan direservasi (misalnya, 0-1 atau 0,1 untuk mereservasi core 0 dan 1). Karena core diindeks nol, nilainya harus kurang dari jumlah vCPU pada jenis mesin.	none	Secara eksplisit mencadangkan core CPU tertentu untuk layanan sistem host, seperti daemon OS dan layanan kubelet. Secara default, layanan ini dapat berjalan di core CPU mana pun, yang dapat menyebabkan masalah performa untuk workload yang sensitif terhadap CPU. Meskipun setelan cpuManagerPolicy: static menetapkan core khusus ke Pod Guaranteed dengan permintaan CPU bilangan bulat, setelan ini tidak mencegah layanan sistem host menggunakan core tersebut. Menambahkan setelan reservedSystemCPUs akan membatasi layanan sistem host ke core yang dicadangkan, sehingga mencegahnya mengganggu core eksklusif workload Anda. Untuk melakukan tugas ini, GKE secara otomatis menyematkan cgroup system.slice ke core yang dicadangkan saat node dimulai. Mereservasi CPU sistem akan mengurangi kapasitas keseluruhan yang dapat dialokasikan dari node Anda. Meskipun Pod Burstable dan BestEffort masih dapat berjalan di core yang dicadangkan ini, permintaan CPU-nya, termasuk permintaan pecahan dari DaemonSet GKE, masih diperhitungkan dalam kapasitas yang dapat dialokasikan node. Karena workload Guaranteed eksklusif memerlukan seluruh core, permintaan pecahan kecil sekalipun akan mengurangi jumlah core eksklusif yang tersedia. Pastikan Anda mencadangkan core CPU yang cukup di reservedSystemCPUs. Jika Anda mencadangkan terlalu sedikit core, daemon sistem host dan proses OS mungkin akan mengalami keterbatasan CPU saat beban tinggi, yang dapat menyebabkan ketidakstabilan atau paket jaringan yang hilang.

Manajemen memori dan penghapusan

Tabel berikut menjelaskan opsi yang dapat diubah untuk manajemen memori dan penghapusan. Bagian ini juga berisi tabel terpisah yang menjelaskan opsi yang dapat diubah untuk flag evictionSoft.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
evictionSoft	Peta nama sinyal. Untuk batasan nilai, lihat tabel berikut.	none	Setelan ini memetakan nama sinyal ke kuantitas atau persentase yang menentukan batas pengeluaran ringan. Batas pengeluaran ringan harus memiliki masa tenggang. kubelet tidak akan mengeluarkan Pod hingga masa tenggang terlampaui.
evictionSoftGracePeriod	Peta nama sinyal. Untuk setiap nama sinyal, nilainya harus berupa durasi positif yang kurang dari 5m. Unit waktu yang valid adalah ns, us (atau µs), ms, s, atau m.	none	Setelan ini memetakan nama sinyal ke durasi yang menentukan masa tenggang untuk batas pengosongan ringan. Setiap batas pengeluaran ringan harus memiliki masa tenggang yang sesuai.
evictionMinimumReclaim	Peta nama sinyal. Untuk setiap nama sinyal, nilainya harus berupa persentase positif yang kurang dari 10%.	none	Setelan ini memetakan nama sinyal ke persentase yang menentukan jumlah minimum resource tertentu yang diklaim kembali oleh kubelet saat melakukan pengeluaran Pod.
evictionMaxPodGracePeriodSeconds	Nilai harus berupa bilangan bulat antara 0 dan 300.	0	Setelan ini menentukan, dalam detik, masa tenggang maksimum untuk penghentian Pod selama pengeluaran.
singleProcessOOMKill	Nilai harus berupa true atau false.	true untuk node cgroupv1, false untuk node cgroupv2.	Setelan ini menetapkan apakah proses dalam container dihentikan oleh OOM secara individual atau sebagai grup. Tersedia di GKE versi 1.32.4-gke.1132000, 1.33.0-gke.1748000, atau yang lebih baru.

Tabel berikut menunjukkan opsi yang dapat diubah untuk flag evictionSoft. Opsi yang sama juga berlaku untuk flag evictionSoftGracePeriod dan evictionMinimumReclaim dengan batasan yang berbeda.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
memoryAvailable	Nilai harus berupa jumlah yang lebih besar dari 100Mi dan lebih kecil dari 50% memori node.	none	Setelan ini menunjukkan jumlah memori yang tersedia sebelum pengosongan ringan. Menentukan jumlah sinyal memory.available dalam kubelet .
nodefsAvailable	Nilai harus antara 10% dan 50%.	none	Setelan ini mewakili nodef yang tersedia sebelum pengeluaran ringan. Menentukan jumlah sinyal nodefs.available dalam kubelet .
nodefsInodesFree	Nilai harus antara 5% dan 50%.	none	Setelan ini mewakili inode nodefs yang kosong sebelum pengeluaran ringan. Menentukan jumlah sinyal nodefs.inodesFree dalam kubelet .
imagefsAvailable	Nilai harus antara 15% dan 50%.	none	Setelan ini mewakili imagefs yang tersedia sebelum pengusiran ringan. Menentukan jumlah sinyal imagefs.available di kubelet .
imagefsInodesFree	Nilai harus antara 5% dan 50%.	none	Setelan ini mewakili inode imagefs yang kosong sebelum pengeluaran ringan. Menentukan jumlah sinyal imagefs.inodesFree dalam kubelet.
pidAvailable	Nilai harus antara 10% dan 50%.	none	Setelan ini mewakili PID yang tersedia sebelum pengeluaran sementara. Menentukan jumlah sinyal pid.available dalam kubelet.

Pengelolaan PID

Tabel berikut menjelaskan opsi yang dapat diubah untuk pengelolaan PID.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
podPidsLimit	Nilai harus antara 1024 dan 4194304.	none	Setelan ini menetapkan jumlah maksimum ID proses (PID) yang dapat digunakan oleh setiap Pod.

Logging

Tabel berikut menjelaskan opsi yang dapat diubah untuk logging.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
containerLogMaxSize	Nilai harus berupa angka positif dan akhiran unit antara 10Mi dan 500Mi, inklusif.	10Mi	Setelan ini mengontrol setelan containerLogMaxSize dari kebijakan rotasi log container, yang memungkinkan Anda mengonfigurasi ukuran maksimum untuk setiap file log. Nilai defaultnya adalah 10Mi. Satuan yang valid adalah Ki, Mi, dan Gi.
containerLogMaxFiles	Nilai harus berupa bilangan bulat antara 2 dan 10, inklusif.	5	Setelan ini mengontrol setelan containerLogMaxFiles dari kebijakan rotasi file log container, yang memungkinkan Anda mengonfigurasi jumlah maksimum file yang diizinkan untuk setiap container. Nilai defaultnya adalah 5. Ukuran total log (container_log_max_size*container_log_max_files) per container tidak boleh melebihi 1% dari total penyimpanan node.

Pembersihan sampah memori image

Tabel berikut menjelaskan opsi yang dapat diubah untuk pembersihan sampah memori image.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
imageGcHighThresholdPercent	Nilai harus berupa bilangan bulat antara 10 dan 85, inklusif, dan lebih tinggi dari imageGcLowThresholdPercent.	85	Setelan ini menentukan persentase penggunaan disk yang di atasnya pembersihan sampah memori image dijalankan. Nilai ini mewakili penggunaan disk tertinggi untuk pembersihan sampah memori. Persentase dihitung dengan membagi nilai kolom ini dengan 100.
imageGcLowThresholdPercent	Nilai harus berupa bilangan bulat antara 10 dan 85, inklusif, dan lebih rendah dari imageGcHighThresholdPercent.	80	Setelan ini menentukan persentase penggunaan disk sebelum pembersihan sampah memori image dijalankan. Nilai ini mewakili penggunaan disk terendah untuk pembersihan sampah memori. Persentase dihitung dengan membagi nilai kolom ini dengan 100.
imageMinimumGcAge	Nilai harus berupa durasi waktu yang tidak lebih dari 2m. Unit waktu yang valid adalah ns, us (atau µs), ms, s, m, atau h.	2m	Setelan ini menentukan usia minimum untuk image yang tidak digunakan sebelum pembersihan sampah memori dilakukan.
imageMaximumGcAge	Nilai harus berupa durasi waktu.	0s	Setelan ini menentukan usia maksimum image yang tidak digunakan sebelum dihapus oleh pembersih sampah memori. Nilai default kolom ini adalah 0s, yang menonaktifkan kolom ini. Dengan demikian, image tidak akan dibersihkan melalui pembersihan sampah memori berdasarkan status tidak digunakan. Jika ditentukan, nilai ini harus lebih besar dari nilai kolom imageMinimumGcAge. Tersedia di GKE versi 1.30.7-gke.1076000, 1.31.3-gke.1023000 atau yang lebih baru.

Pengambilan image

Tabel berikut menjelaskan opsi yang dapat diubah untuk penarikan image.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
maxParallelImagePulls	Nilai harus berupa bilangan bulat antara 2 dan 5, inklusif.	2 atau 3 berdasarkan jenis disk.	Setelan ini menentukan jumlah maksimum penarikan image secara paralel. Nilai default ditentukan oleh jenis boot disk.

Keamanan dan operasi yang tidak aman

Tabel berikut menjelaskan opsi yang dapat diubah untuk mengonfigurasi keamanan dan menangani operasi yang tidak aman.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
allowedUnsafeSysctls	Daftar nama atau grup sysctl. Grup sysctl yang diizinkan adalah sebagai berikut: kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*.	none	Setelan ini menentukan daftar yang diizinkan yang dipisahkan koma untuk nama sysctl atau grup sysctl yang tidak aman yang dapat ditetapkan di Pod.
insecureKubeletReadonlyPortEnabled	Nilai harus berupa nilai boolean, yaitu true atau false.	false	Setelan ini menonaktifkan port hanya baca kubelet yang tidak aman 10255 di setiap node pool baru di cluster Anda. Jika mengonfigurasi setelan ini dalam file ini, Anda tidak dapat menggunakan klien GKE API untuk mengubah setelan di level cluster.

Pengelola Resource

Kubernetes menawarkan rangkaian Resource Manager. Anda dapat mengonfigurasi Resource Manager ini untuk mengoordinasikan dan mengoptimalkan penyelarasan resource node untuk Pod yang dikonfigurasi dengan persyaratan khusus untuk resource CPU, perangkat, dan memori (hugepages).

Tabel berikut menjelaskan opsi yang dapat diubah untuk Resource Manager.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
cpuManagerPolicy	Nilai harus berupa none atau static.	none	Setelan ini mengontrol kebijakan CPU Manager kubelet. Nilai default-nya adalah none, yang merupakan skema afinitas CPU default, yang tidak memberikan afinitas di luar apa yang dilakukan scheduler OS secara otomatis. Jika nilai ini ditetapkan ke static, Pod yang berada di class QoS Guaranteed dan memiliki permintaan CPU bilangan bulat akan ditetapkan untuk menggunakan CPU secara eksklusif.
memoryManager.policy	Nilai harus berupa None atau Static.	None	Setelan ini mengontrol kebijakan Memory Manager kubelet. Dengan nilai default None, Kubernetes bertindak sama seperti jika Memory Manager tidak ada. Jika Anda menetapkan nilai ini ke Static, kebijakan Memory Manager akan mengirimkan petunjuk topologi yang bergantung pada jenis Pod. Untuk mengetahui detailnya, lihat Kebijakan statis. Setelan ini didukung untuk cluster dengan bidang kontrol yang menjalankan GKE versi 1.32.3-gke.1785000 atau yang lebih baru.
topologyManager	Nilai harus berupa salah satu setelan yang didukung untuk setiap kolom yang terkait. Anda tidak dapat menetapkan kolom topologyManager saat menggunakan petunjuk Terraform untuk menambahkan konfigurasi ke node pool Standard.	policy: none scope: container	Setelan ini mengontrol konfigurasi Topology Manager kubelet menggunakan subkolom policy dan scope. Topology Manager mengoordinasikan kumpulan komponen yang bertanggung jawab atas pengoptimalan performa yang terkait dengan isolasi CPU, memori, dan lokalitas perangkat. Anda dapat menetapkan setelan kebijakan dan cakupan secara terpisah. Untuk mengetahui informasi selengkapnya tentang setelan ini, lihat Cakupan dan kebijakan pengelola topologi. Resource GKE berikut mendukung setelan ini: Cluster dengan bidang kontrol yang menjalankan GKE versi 1.32.3-gke.1785000 atau yang lebih baru. Untuk cluster dengan bidang kontrol dan node yang menjalankan 1.33.0-gke.1712000 atau yang lebih baru, Topology Manager juga menerima informasi tentang topologi GPU. Node dengan jenis mesin berikut: A2, A3, A4, C3, C4, C4A, C4N, G2, G4, M3, N4

Penundaan mulai ulang container

Setelan ini mengontrol waktu maksimum untuk menunggu di antara upaya memulai ulang container saat container dalam status CrashLoopBackOff. Anda dapat mengonfigurasi setelan ini untuk node pool Standard yang menjalankan GKE versi 1.35 atau yang lebih baru.

Perhatian: Penundaan yang sangat singkat pada container yang terus-menerus gagal dapat menyebabkan konsumsi CPU dan resource yang tinggi pada node, sehingga berpotensi memengaruhi workload lain karena kehabisan resource. Pertimbangkan untuk menguranginya hanya jika manfaat percobaan ulang yang lebih cepat lebih besar daripada risiko peningkatan penggunaan resource.

Tabel berikut menjelaskan opsi yang dapat diubah untuk crashLoopBackOff.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
crashLoopBackOff.maxContainerRestartPeriod	Nilai harus berupa durasi positif yang kurang dari atau sama dengan 5 menit (5m). Satuan waktu yang valid adalah ns, us (atau µs), ms, s, atau m.	none	Durasi maksimum penundaan backoff yang dapat diakumulasikan untuk mulai ulang container. Penundaan antara mulai ulang meningkat secara eksponensial dari nilai awal hingga batas maksimum ini. Batas maksimum default untuk cluster Kubernetes adalah 5 menit. Untuk mengetahui informasi selengkapnya, lihat Penundaan mulai ulang container yang dapat dikonfigurasi.

Penghentian tuntas Spot VM di GKE

Tabel berikut menjelaskan opsi yang dapat diubah untuk periode penghentian dan penghentian normal untuk Spot VM di GKE. Untuk menggunakan opsi ini, bidang kontrol cluster Anda harus menjalankan GKE versi 1.35.0-gke.1171000 atau yang lebih baru. Untuk mengetahui informasi selengkapnya, lihat Cara kerja Spot VM di GKE.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
shutdownGracePeriodSeconds	Nilai harus berupa bilangan bulat yang mewakili durasi dalam detik. Nilai yang diizinkan adalah 0, 30, atau 120.	30	Menentukan total durasi dalam detik yang digunakan node untuk menunda penonaktifan agar dapat menghentikan Pod secara tuntas.
shutdownGracePeriodCriticalPodsSeconds	Nilai harus berupa bilangan bulat antara 0 dan 120 (inklusif), dan harus kurang dari shutdownGracePeriodSeconds. Hanya berlaku jika shutdownGracePeriodSeconds juga ditetapkan.	15	Menentukan durasi dalam detik yang digunakan untuk menghentikan Pod penting selama penonaktifan node.

Reservasi resource sistem

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Untuk node pool Standard yang menjalankan Linux dan GKE 1.37 atau yang lebih baru, Anda dapat menyesuaikan jumlah memori dan CPU yang dicadangkan untuk komponen sistem. Hal ini memungkinkan Anda menyesuaikan kapasitas yang dapat dialokasikan untuk skenario tertentu, seperti menangani pengambilan image bervolume tinggi atau menjalankan DaemonSet node yang disesuaikan. Untuk mengetahui informasi selengkapnya tentang pemesanan default, lihat Tentang ukuran node GKE.

Tabel berikut menjelaskan opsi yang dapat diubah untuk pemesanan resource sistem.

Setelan konfigurasi kubelet	Pembatasan	Setelan default	Deskripsi
reservedResourcesConfig.memoryReservedMib	Nilai harus berupa bilangan bulat. Harus lebih besar dari atau sama dengan pemesanan memori default untuk node pool yang dibuat yang menjalankan 1.37 atau yang lebih baru, dan kurang dari 50% total kapasitas memori node.	Lihat Reservasi memori.	Jumlah memori yang akan dicadangkan untuk komponen sistem, dalam mebibyte (MiB).
reservedResourcesConfig.cpuReservedMillicore	Nilai harus berupa bilangan bulat. Harus lebih besar dari atau sama dengan pemesanan CPU default untuk node pool yang dibuat dan menjalankan versi 1.37 atau yang lebih baru, serta kurang dari 50% total kapasitas CPU node.	Lihat CPU reservations.	Jumlah CPU yang akan dicadangkan untuk komponen sistem, dalam milicore.

Memverifikasi reservasi yang efektif

Untuk memeriksa pemesanan aktif yang diterapkan ke node pool Anda, periksa kolom output effectiveMemoryReservedMib dan effectiveCpuReservedMillicore:

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="yaml(config.kubeletConfig.reservedResourcesConfig)"

Opsi konfigurasi Sysctl

Untuk menyesuaikan performa sistem, Anda dapat mengubah parameter kernel Linux. Tabel di bagian ini menjelaskan berbagai parameter kernel yang dapat Anda konfigurasi.

Parameter sistem file (fs.*)

Tabel berikut menjelaskan parameter yang dapat diubah untuk sistem file Linux. Setelan ini mengontrol perilaku sistem file Linux, seperti batas pengendali file dan pemantauan peristiwa.

Parameter Sysctl	Pembatasan	Deskripsi
fs.aio-max-nr	Harus antara [65536, 4194304].	Setelan ini menentukan jumlah maksimum permintaan I/O asinkron di seluruh sistem.
fs.file-max	Harus antara [104857, 67108864].	Setelan ini menentukan jumlah maksimum handle file yang dapat dialokasikan oleh kernel Linux.
fs.inotify.max_user_instances	Harus antara [8192, 1048576].	Setelan ini menentukan jumlah maksimum instance inotify yang dapat dibuat pengguna.
fs.inotify.max_user_watches	Harus antara [8192, 1048576].	Setelan ini menentukan jumlah maksimum watch inotify yang dapat dibuat pengguna.
fs.nr_open	Harus antara [1048576, 2147483584].	Setelan ini menentukan jumlah maksimum deskriptor file yang dapat dibuka oleh suatu proses.

Parameter kernel (kernel.*)

Tabel berikut menjelaskan parameter yang dapat diubah untuk kernel Linux. Setelan ini mengonfigurasi fungsi kernel inti, termasuk alokasi memori bersama.

Parameter sysctl	Pembatasan	Deskripsi
kernel.shmmni	Harus antara [4096, 32768].	Setelan ini menentukan jumlah maksimum segmen memori bersama di seluruh sistem. Jika nilai ini tidak ditetapkan, nilai defaultnya adalah 4096.
kernel.shmmax	Harus antara [0, 18446744073692774399].	Setelan ini menentukan ukuran maksimum, dalam byte, dari satu segmen memori bersama yang diizinkan oleh kernel. Nilai ini diabaikan jika lebih besar dari jumlah RAM sebenarnya, yang berarti semua RAM yang tersedia dapat dibagikan.
kernel.shmall	Harus antara [0, 18446744073692774399].	Setelan ini menentukan jumlah total halaman memori bersama yang dapat digunakan pada sistem sekaligus. Satu halaman berukuran 4.096 byte pada arsitektur AMD64 dan Intel 64.
kernel.perf_event_paranoid	Harus antara [-1, 3].	Setelan ini mengontrol penggunaan sistem peristiwa performa oleh pengguna yang tidak memiliki hak istimewa tanpa CAP_PERFMON. Nilai defaultnya adalah 2 di kernel.
kernel.sched_rt_runtime_us	Harus antara [-1, 1000000].	Setelan ini menentukan batas global untuk jumlah waktu yang dapat digunakan penjadwalan real-time.
kernel.softlockup_panic	Opsional (boolean).	Setelan ini mengontrol apakah kernel mengalami error saat soft lockup terdeteksi.
kernel.yama.ptrace_scope	Harus antara [0, 3].	Setelan ini menentukan cakupan dan batasan untuk panggilan sistem ptrace(), yang memengaruhi proses proses debug dan pelacakan. Nilai yang didukung mencakup hal berikut: 0: izin ptrace klasik. 1: ptrace yang dibatasi, yang merupakan default di banyak distribusi. Hanya proses turunan atau CAP_SYS_PTRACE. 2: ptrace khusus admin. Hanya proses dengan CAP_SYS_PTRACE. 3: tidak ada ptrace. Panggilan ptrace tidak diizinkan.
kernel.kptr_restrict	Harus antara [0, 2].	Setelan ini menunjukkan apakah ada batasan yang diterapkan pada eksposur alamat kernel melalui /proc dan antarmuka lainnya.
kernel.dmesg_restrict	Opsional (boolean).	Setelan ini menunjukkan apakah pengguna yang tidak memiliki hak istimewa dicegah menggunakan dmesg(8) untuk melihat pesan dari buffer log kernel.
kernel.sysrq	Harus antara [0, 511].	Setelan ini mengontrol fungsi yang diizinkan untuk dipanggil melalui tombol SysRq. Nilai yang memungkinkan mencakup: 0: menonaktifkan sysrq sepenuhnya. 1: mengaktifkan semua fungsi sysrq. >1: bitmask fungsi sysrq yang diizinkan. Untuk mengetahui informasi selengkapnya, lihat Peretasan Kunci Permintaan Sistem Magic Linux.
kernel.keys.maxbytes	Harus antara [20000, 2097152].	Setelan ini menentukan jumlah byte maksimum yang dapat disimpan oleh pengguna non-root di bagian payload semua kuncinya.
kernel.keys.maxkeys	Harus antara [200, 1048576].	Setelan ini menentukan jumlah maksimum kunci yang dapat dimiliki oleh pengguna non-root.

Parameter jaringan (net.*)

Tabel berikut menjelaskan parameter yang dapat diubah untuk jaringan. Setelan ini menyesuaikan performa dan perilaku stack jaringan, mulai dari buffer soket hingga pelacakan koneksi.

Parameter sysctl	Pembatasan	Deskripsi
net.core.busy_poll	Bilangan bulat positif apa pun, kurang dari 2147483647.	Setelan ini menentukan waktu tunggu polling sibuk latensi rendah untuk polling dan pemilihan. Nilai ini menunjukkan perkiraan waktu dalam µs untuk loop sibuk yang menunggu peristiwa.
net.core.busy_read	Bilangan bulat positif apa pun, kurang dari 2147483647.	Setelan ini menentukan waktu tunggu polling sibuk latensi rendah untuk pembacaan soket. Nilai ini menunjukkan perkiraan waktu dalam µs untuk loop sibuk yang menunggu paket di antrean perangkat.
net.core.netdev_max_backlog	Bilangan bulat positif apa pun, kurang dari 2147483647.	Setelan ini menentukan jumlah maksimum paket, yang diantrekan di sisi INPUT, saat antarmuka menerima paket lebih cepat daripada yang dapat diproses oleh kernel.
net.core.rmem_default	Bilangan bulat positif apa pun, kurang dari 2147483647.	Setelan ini menentukan ukuran buffer soket penerima default, dalam byte.
net.core.rmem_max	Bilangan bulat positif apa pun, kurang dari 2147483647.	Setelan ini menentukan ukuran buffer soket penerimaan maksimum, dalam byte.
net.core.wmem_default	Bilangan bulat positif apa pun, kurang dari 2147483647.	Setelan ini menentukan setelan default, dalam byte, dari buffer pengiriman soket.
net.core.wmem_max	Bilangan bulat positif apa pun, kurang dari 2147483647.	Setelan ini menentukan ukuran buffer soket pengiriman maksimum, dalam byte.
net.core.optmem_max	Bilangan bulat positif apa pun, kurang dari 2147483647.	Setelan ini menentukan ukuran buffer tambahan maksimum yang diizinkan per soket.
net.core.somaxconn	Harus antara [128, 2147483647].	Setelan ini menentukan batas backlog socket listen(), yang dikenal di userspace sebagai SOMAXCONN. Setelan ini ditetapkan ke 128 secara default.
net.ipv4.tcp_rmem	{min, default, max} (masing-masing > 0, memori dalam byte).	Setelan ini menentukan ukuran minimum, dalam byte, buffer penerimaan yang digunakan oleh soket UDP dalam moderasi. Setelan defaultnya adalah 1 halaman.
net.ipv4.tcp_wmem	{min, default, max} (masing-masing > 0, memori dalam byte).	Setelan ini menentukan ukuran minimal, dalam byte, dari buffering pengiriman yang digunakan oleh soket UDP dalam moderasi. Setelan defaultnya adalah 1 halaman.
net.ipv4.tcp_tw_reuse	Harus antara {0, 1}.	Setelan ini menentukan apakah akan mengizinkan penggunaan kembali soket dalam status TIME_WAIT untuk koneksi baru jika aman dari sudut pandang protokol. Nilai defaultnya adalah 0.
net.ipv4.tcp_max_orphans	Harus antara [16384, 262144].	Setelan ini menentukan jumlah maksimum soket TCP yang tidak terpasang ke deskriptor file pengguna mana pun.
net.ipv4.tcp_max_tw_buckets	Harus antara [4096, 2147483647].	Setelan ini menentukan jumlah maksimum soket timewait yang dipertahankan oleh sistem secara bersamaan. Jika jumlah ini terlampaui, soket time-wait akan segera dihancurkan dan peringatan akan dicetak.
net.ipv4.tcp_syn_retries	Harus antara [1, 127].	Setelan ini menentukan frekuensi SYN awal untuk upaya koneksi TCP aktif ditransmisikan ulang.
net.ipv4.tcp_ecn	Harus antara [0, 2].	Setelan ini mengontrol penggunaan Explicit Congestion Notification (ECN) oleh TCP. ECN hanya digunakan jika kedua ujung koneksi TCP menunjukkan dukungan untuknya.
net.ipv4.tcp_mtu_probing	Harus antara [0, 2].	Setelan ini mengontrol TCP Packetization-Layer Path MTU Discovery. Nilai yang didukung adalah sebagai berikut: 0: dinonaktifkan. 1: dinonaktifkan secara default, diaktifkan saat black hole ICMP terdeteksi. 2: selalu diaktifkan. Gunakan MSS awal tcp_base_mss.
net.ipv4.tcp_congestion_control	Harus berupa salah satu nilai yang didukung dari kolom Deskripsi.	Setelan ini tidak didukung jika GKE Dataplane V2 diaktifkan di cluster. Nilai yang didukung berikut bergantung pada jenis gambar: Container-Optimized OS: reno, cubic, bbr, lp, htcp (tersedia di GKE versi 1.34.1-gke.3355001 atau yang lebih baru) Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood, yeah
net.ipv6.conf.all.disable_ipv6	Boolean.	Mengubah nilai ini sama dengan mengubah setelan conf/default/disable_ipv6 dan juga semua setelan disable_ipv6 per antarmuka ke nilai yang sama.
net.ipv6.conf.default.disable_ipv6	Boolean.	Setelan ini menonaktifkan operasi IPv6.
net.netfilter.nf_conntrack_acct	Harus antara {0, 1}.	Setelan ini mengaktifkan akuntansi alur pelacakan koneksi. Nilai defaultnya adalah 0, yang berarti setelan ini dinonaktifkan. Tersedia di GKE versi 1.32.0-gke.1448000 atau yang lebih baru.
net.netfilter.nf_conntrack_max	Harus antara [65536, 4194304].	Setelan ini menentukan ukuran tabel pelacakan koneksi. Jika nilai maksimum tercapai, koneksi baru akan gagal. Tersedia di GKE versi 1.32.0-gke.1448000 atau yang lebih baru.
net.netfilter.nf_conntrack_buckets	Harus antara [65536, 524288].	Setelan ini menentukan ukuran tabel hash. Setelan yang direkomendasikan adalah hasil dari hal berikut: nf_conntrack_max = nf_conntrack_buckets * 4. Tersedia di GKE versi 1.32.0-gke.1448000 atau yang lebih baru.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	Harus antara [60, 3600].	Setelan ini menentukan periode, dalam detik, saat koneksi TCP dapat tetap dalam status CLOSE_WAIT. Nilai defaultnya adalah 3600. Tersedia di GKE versi 1.32.0-gke.1448000 atau yang lebih baru.
net.netfilter.nf_conntrack_tcp_timeout_established	Harus antara [600, 86400].	Setelan ini menentukan durasi, dalam detik, koneksi yang tidak aktif sebelum dihapus secara otomatis dari tabel pelacakan koneksi. Tersedia di GKE versi 1.32.0-gke.1448000 atau yang lebih baru.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	Harus antara [1, 600].	Setelan ini menentukan periode, dalam detik, saat koneksi TCP dapat tetap dalam status TIME_WAIT. Nilai defaultnya adalah 120. Tersedia di GKE versi 1.32.0-gke.1448000 atau yang lebih baru.
net.ipv4.neigh.default.gc_thresh1	Harus antara [0, 262144].	Setelan ini menentukan jumlah minimum entri yang akan disimpan di cache ARP. Pembersih sampah memori tidak akan berjalan jika jumlah entri di bawah setelan ini. Menetapkan nilai ini ke 0 dapat menyebabkan thrashing cache dan penurunan performa.
net.ipv4.neigh.default.gc_thresh2	Harus antara [512, 524288].	Setelan ini menentukan jumlah maksimum entri yang dapat disimpan dalam cache ARP. Pembersih sampah memori memungkinkan jumlah entri melebihi nilai ini selama 5 detik sebelum memulai pembersihan sampah memori ringan.
net.ipv4.neigh.default.gc_thresh3	Harus antara [1024, 1048576].	Setelan ini menentukan jumlah maksimum entri yang harus disimpan di cache ARP. Pembersih sampah memori dirancang untuk selalu berjalan jika jumlah entri melebihi setelan ini.

Parameter Memori Virtual (vm.*)

Tabel berikut menjelaskan parameter yang dapat diubah untuk subsistem Memori Virtual. Setelan ini mengelola subsistem Memori Virtual, yang mengontrol cara kernel menangani memori, swapping, dan caching disk.

Parameter sysctl	Pembatasan	Deskripsi
vm.max_map_count	Harus antara [65536, 2147483647].	File ini menentukan jumlah maksimum area peta memori yang dapat dimiliki oleh suatu proses.
vm.dirty_background_ratio	Harus antara [1, 100].	Setelan ini menentukan persentase memori sistem yang dapat diisi dengan halaman kotor sebelum thread flusher kernel latar belakang memulai writeback. Nilai ini harus lebih kecil dari nilai kolom vm.dirty_ratio.
vm.dirty_background_bytes	Harus antara [0, 68719476736].	Setelan ini menentukan jumlah memori kotor yang digunakan thread flusher kernel latar belakang untuk memulai writeback. Perlu diketahui bahwa vm.dirty_background_bytes adalah padanan dari vm.dirty_background_ratio. Hanya salah satu setelan ini yang dapat ditentukan.
vm.dirty_expire_centisecs	Harus antara [0, 6000].	Setelan ini menentukan usia maksimum, dalam seperseratus detik, data kotor dapat tetap berada di memori sebelum thread flusher kernel menulisnya ke disk.
vm.dirty_ratio	Harus antara [1, 100].	Setelan ini menentukan persentase memori sistem yang dapat diisi dengan halaman kotor sebelum proses yang melakukan penulisan dipaksa untuk memblokir dan menulis data kotor secara sinkron.
vm.dirty_bytes	Harus antara [0, 68719476736].	Setelan ini menentukan jumlah memori kotor yang digunakan oleh proses yang menghasilkan penulisan disk untuk memulai writeback itu sendiri. Nilai minimum yang diizinkan untuk vm.dirty_bytes adalah dua halaman dalam byte. Nilai apa pun yang lebih rendah dari batas ini akan diabaikan dan konfigurasi lama akan dipertahankan. Perlu diketahui bahwa vm.dirty_bytes adalah padanan dari vm.dirty_ratio. Hanya salah satu setelan ini yang dapat ditentukan.
vm.dirty_writeback_centisecs	Harus antara [0, 1000].	Setelan ini menentukan interval, dalam seperseratus detik, saat thread flusher kernel aktif untuk menulis data kotor lama ke disk.
vm.overcommit_memory	Harus antara {0, 1, 2}.	Setelan ini menentukan strategi kernel untuk menangani overcommitment memori. Nilainya adalah sebagai berikut: 0: menolak alokasi besar 1: selalu izinkan (nilai default) 2: mencegah commit di luar swap + rasio RAM Setelan ini tidak didukung di mesin dengan memori kurang dari 15 GB.
vm.overcommit_ratio	Harus antara [0, 100].	Setelan ini menentukan persentase RAM fisik yang diizinkan untuk overcommit jika nilai kolom vm.overcommit_memory ditetapkan ke 2.
vm.vfs_cache_pressure	Harus antara [0, 100].	Setelan ini menyesuaikan preferensi kernel untuk mengklaim kembali memori yang digunakan untuk cache dentry (direktori) dan inode.
vm.swappiness	Harus antara [0, 200].	Setelan ini mengontrol kecenderungan kernel untuk memindahkan proses dari memori fisik ke disk swap. Nilai defaultnya adalah 60.
vm.watermark_scale_factor	Harus antara [10, 3000].	Setelan ini mengontrol agresivitas kswapd. Fungsi ini menentukan memori yang tersisa sebelum kswapd aktif dan memori yang akan dikosongkan sebelum kswapd tidur. Nilai defaultnya adalah 10.
vm.min_free_kbytes	Harus antara [67584, 1048576].	Setelan ini menentukan memori kosong minimum sebelum OOM. Nilai defaultnya adalah 67584.

Untuk mengetahui informasi selengkapnya tentang nilai yang didukung untuk setiap flag sysctl, lihat dokumentasi gcloud CLI --system-config-from-file.

Namespace Linux yang berbeda dapat memiliki nilai unik untuk flag sysctl tertentu, tetapi namespace lainnya mungkin bersifat global untuk keseluruhan node. Memperbarui opsi sysctl menggunakan konfigurasi sistem node membantu memastikan bahwa sysctl diterapkan secara global pada node dan di setiap namespace, sehingga setiap Pod memiliki nilai sysctl yang sama di setiap namespace Linux.

Opsi konfigurasi mode cgroup Linux

Perhatian: GKE menghentikan penggunaan cgroupv1 dengan versi minor 1.31, dan menghapus dukungan untuk cgroupv1 dengan versi 1.35. Untuk mengetahui informasi selengkapnya tentang cara GKE bertransisi ke cgroupv2 dan cara menyiapkan cluster untuk transisi ini, lihat Memigrasikan node ke Linux cgroupv2.

Runtime container dan kubelet menggunakan cgroups kernel Linux untuk pengelolaan resource, seperti membatasi jumlah CPU atau memori yang dapat diakses oleh setiap container di sebuah Pod. Ada dua versi subsistem cgroup dalam kernel: cgroupv1 dan cgroupv2. Dukungan Kubernetes untuk cgroupv2 diperkenalkan sebagai alfa pada Kubernetes versi 1.18, beta pada 1.22, dan GA pada 1.25. Untuk mengetahui informasi selengkapnya, baca dokumentasi Kubernetes cgroups v2.

Dengan konfigurasi sistem node, Anda dapat menyesuaikan konfigurasi cgroup node pool. Anda dapat menggunakan cgroupv1 atau cgroupv2. GKE menggunakan cgroupv2 untuk node pool Standard baru yang menjalankan versi 1.26 dan yang lebih baru, serta cgroupv1 untuk node pool yang menjalankan versi yang lebih lama dari 1.26. Untuk node pool yang dibuat dengan node auto-provisioning, konfigurasi cgroup bergantung pada versi cluster awal, bukan versi node pool. cgroupv1 tidak didukung di mesin Arm.

Anda dapat menggunakan konfigurasi sistem node untuk mengubah setelan node pool agar menggunakan cgroupv1 atau cgroupv2 secara eksplisit. Mengupgrade node pool yang sudah ada yang menggunakan cgroupv1 ke versi 1.26 tidak akan mengubah setelan ke cgroupv2. Node pool yang ada yang menjalankan versi sebelum 1.26—dan yang tidak menyertakan konfigurasi cgroup yang disesuaikan—akan terus menggunakan cgroupv1. Untuk mengubah setelan, Anda harus menentukan cgroupv2 secara eksplisit untuk node pool yang ada.

Misalnya, untuk mengonfigurasi node pool agar menggunakan cgroupv2, gunakan file konfigurasi sistem node seperti berikut:

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

Opsi cgroupMode yang didukung adalah sebagai berikut:

• CGROUP_MODE_V1: menggunakan cgroupv1 di node pool.
• CGROUP_MODE_V2: menggunakan cgroupv2 di node pool.
• CGROUP_MODE_UNSPECIFIED: menggunakan konfigurasi cgroup GKE default.

Untuk menggunakan cgroupv2, persyaratan dan batasan berikut berlaku:

• Untuk node pool yang menjalankan versi lebih lama dari 1.26, Anda harus menggunakan gcloud CLI versi 408.0.0 atau yang lebih baru. Atau, gunakan gcloud beta dengan versi 395.0.0 atau yang lebih baru.
• Cluster dan node pool Anda harus menjalankan GKE versi 1.24.2-gke.300 atau yang lebih baru.
• Anda harus menggunakan Container-Optimized OS dengan containerd atau Ubuntu dengan image node containerd.
• Jika ada workload yang bergantung pada pembacaan sistem file cgroup (/sys/fs/cgroup/...), pastikan workload tersebut kompatibel dengan API cgroupv2.
• Jika Anda menggunakan alat pemantauan atau alat pihak ketiga, pastikan alat tersebut kompatibel dengan cgroupv2.
• Jika Anda menggunakan workload Java (JDK), sebaiknya gunakan versi yang mendukung cgroupv2 sepenuhnya, termasuk JDK 8u372, JDK 11.0.16 atau yang lebih baru, atau JDK 15 atau yang lebih baru.

Memverifikasi konfigurasi cgroup

Saat Anda menambahkan konfigurasi sistem node, GKE harus membuat ulang node untuk menerapkan perubahan. Setelah Anda menambahkan konfigurasi ke node pool dan node dibuat ulang, Anda dapat memverifikasi konfigurasi baru.

Anda dapat memverifikasi konfigurasi cgroup untuk node dalam node pool menggunakan gcloud CLI atau alat command line kubectl:

gcloud CLI

Periksa konfigurasi cgroup untuk node pool:

gcloud container node-pools describe POOL_NAME \
  --format='value(Config.effectiveCgroupMode)'

Ganti POOL_NAME dengan nama node pool Anda.

Output potensialnya adalah salah satu dari berikut:

• EFFECTIVE_CGROUP_MODE_V1: node menggunakan cgroupv1
• EFFECTIVE_CGROUP_MODE_V2: node menggunakan cgroupv2

Output hanya menampilkan konfigurasi cgroup baru setelah node di node pool dibuat ulang. Output-nya kosong untuk node pool Windows Server, yang tidak mendukung cgroup.

kubectl

Untuk menggunakan kubectl guna memverifikasi konfigurasi cgroup untuk node di node pool ini, pilih node dan hubungkan menggunakan petunjuk berikut:

1. Buat shell interaktif dengan node mana pun di node pool. Dalam perintah, ganti mynode dengan nama node mana pun di node pool.
2. Identifikasi versi cgroup di node Linux.

Opsi konfigurasi hugepage Linux

Anda dapat menggunakan hugepage yang dialokasikan sebelumnya secara manual atau hugepage transparan yang ditetapkan secara otomatis.

Hugepage yang dialokasikan sebelumnya

Anda dapat menggunakan file konfigurasi sistem node untuk mengalokasikan hugepages terlebih dahulu. Kubernetes mendukung hugepage yang telah dialokasikan sebelumnya sebagai jenis resource, mirip dengan CPU atau memori.

Untuk menggunakan hugepages, batasan dan persyaratan berikut berlaku:

• Untuk memastikan bahwa node tidak sepenuhnya ditempati oleh hugepage, ukuran keseluruhan hugepage yang dialokasikan tidak boleh melebihi salah satu dari hal berikut:
  • Pada mesin dengan memori kurang dari 30 GB: 60% dari total memori. Misalnya, pada mesin e2-standard-2 dengan memori 8 GB, Anda tidak dapat mengalokasikan lebih dari 4,8 GB untuk hugepage.
  • Pada mesin dengan memori lebih dari 30 GB: 80% dari total memori. Misalnya, pada mesin c4a-standard-8 dengan memori 32 GB, hugepages tidak boleh melebihi 25,6 GB.
• Hugepage 1 GB hanya tersedia di jenis mesin A3, C2D, C3, C3D, C4, C4A, C4D, C4N, CT5E, CT5LP, CT6E, H3, M2, M3, M4, Z3, atau Z4D.

Tabel berikut menjelaskan setelan yang dapat diubah untuk hugepage Linux.

Parameter konfigurasi	Pembatasan	Nilai default	Deskripsi
hugepage_size2m	Jumlah bilangan bulat. Tunduk pada batas alokasi memori yang dijelaskan sebelumnya.	0	Setelan ini mengalokasikan terlebih dahulu sejumlah hugepage 2 MB tertentu.
hugepage_size1g	Jumlah bilangan bulat. Tunduk pada batasan memori dan jenis mesin yang telah dijelaskan sebelumnya.	0	Setelan ini mengalokasikan terlebih dahulu sejumlah hugepage 1 GB tertentu.

Transparent hugepages (THP)

Anda dapat menggunakan file konfigurasi sistem node untuk mengaktifkan Transparent HugePage Support kernel Linux. Dengan THP, kernel secara otomatis menetapkan hugepage ke proses tanpa pra-alokasi manual.

Tabel berikut menjelaskan parameter yang dapat diubah untuk THP.

Parameter konfigurasi	Nilai yang didukung	Nilai default	Deskripsi
transparentHugepageEnabled	TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS: transparent hugepage diaktifkan di seluruh sistem. TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: transparent hugepage diaktifkan di dalam region MADV_HUGEPAGE. Setelan ini adalah konfigurasi kernel default. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: transparent hugepage dinonaktifkan. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: nilai default. GKE tidak mengubah konfigurasi kernel.	UNSPECIFIED	Setelan ini mengontrol apakah THP diaktifkan untuk memori anonim.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: aplikasi yang meminta THP akan terhenti saat terjadi kegagalan alokasi dan langsung mengklaim kembali halaman serta memadatkan memori untuk segera mengalokasikan THP. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: aplikasi mengaktifkan kswapd di latar belakang untuk mengklaim kembali halaman dan mengaktifkan kcompactd untuk memadatkan memori sehingga THP tersedia dalam waktu dekat. Khugepaged bertanggung jawab untuk menginstal halaman THP nanti. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: aplikasi memasuki reklamasi dan pemadatan langsung seperti biasa, tetapi hanya untuk region yang telah menggunakan madvise(MADV_HUGEPAGE). Semua region lainnya mengaktifkan kswapd di latar belakang untuk mengklaim kembali halaman dan mengaktifkan kcompactd untuk memadatkan memori sehingga THP tersedia dalam waktu dekat. TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: aplikasi memasuki reklamasi dan pemadatan langsung seperti biasa, tetapi hanya untuk region yang telah menggunakan madvise(MADV_HUGEPAGE). Semua region lainnya mengaktifkan kswapd di latar belakang untuk mengklaim kembali halaman dan mengaktifkan kcompactd untuk memadatkan memori sehingga THP tersedia dalam waktu dekat. TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: aplikasi tidak pernah memasuki reklamasi atau pemadatan langsung. TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: nilai default. GKE tidak mengubah konfigurasi kernel.	UNSPECIFIED	Setelan ini menentukan konfigurasi defragmentasi untuk THP.

THP tersedia di GKE versi 1.33.2-gke.4655000 atau yang lebih baru. Fitur ini juga diaktifkan di node pool TPU baru secara default di GKE versi 1.33.2-gke.4655000 atau yang lebih baru. THP tidak diaktifkan saat Anda mengupgrade node pool yang ada ke versi yang didukung atau yang lebih baru.

Opsi sinkronisasi waktu akurat Linux

Jika sinkronisasi waktu yang akurat dan pemantauan akurasi sinkronisasi waktu penting untuk workload Anda, Anda dapat mengonfigurasi waktu yang akurat untuk menyinkronkan jam VM dengan jam host menggunakan chrony dan ptp_kvm. Sinkronisasi waktu yang akurat tersedia di GKE versi 1.36.0-gke.3241000 dan yang lebih baru. Konfigurasi ini dirancang untuk mencapai akurasi dalam 1 md untuk penyiapan yang didukung. Untuk mengetahui informasi selengkapnya tentang jenis mesin yang didukung, sistem operasi yang didukung, dan zona yang didukung, lihat Mengonfigurasi waktu yang akurat untuk VM Compute Engine.

Tabel berikut menjelaskan parameter untuk mengonfigurasi sinkronisasi waktu yang akurat dengan GKE:

Parameter konfigurasi	Nilai yang didukung	Nilai default	Deskripsi
File konfigurasi: accurateTimeConfig.enablePtpKvmTimeSync Terraform: accurate_time_config.enable_ptp_kvm_time_sync	true atau false	false	Setelan ini memungkinkan sinkronisasi waktu yang akurat. Fitur ini hanya didukung dengan jenis mesin, sistem operasi, dan zona tertentu.

Setelah Anda mengaktifkan sinkronisasi waktu yang akurat, GKE akan mengumpulkan dan mengekspor informasi berikut:

• Metrik compute.googleapis.com/instance/clock_accuracy/ptp_kvm/nanosecond_accuracy, yang menunjukkan akurasi jam host VM terhadap UTC.
• Log projects/PROJECT_ID/logs/chrony.tracking, yang berisi log pelacakan dari chrony. Log ini memberikan informasi seperti tingkat penambahan atau pengurangan jam sistem.

Anda dapat menggunakan informasi ini untuk membuat metrik berbasis log dan dasbor di Cloud Monitoring guna menganalisis performa dan keandalan sinkronisasi waktu.

Misalnya, konfigurasi gke-clock-metric.json berikut menentukan metrik berbasis log dari error jam host maksimum:

{
  "name": "phc-clock-max-error",
  "description": "Maximum error of the VM clock from the host clock exposed by ptp_kvm",
  "filter": "resource.type=\"k8s_node\" AND log_id(\"chrony.tracking\")",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "DISTRIBUTION",
    "unit": "s",
    "labels": []
  },
  "valueExtractor": "REGEXP_EXTRACT(textPayload, \"^.*PHC0.* ([-\\\\d\\\\.eE]+)$\")",
  "bucketOptions": {
    "explicitBuckets": {
      "bounds": [
        0.0, 5.0E-7, 1.0E-6, 2.0E-6, 4.0E-6, 5.0E-6, 8.0E-6, 1.0E-5, 2.0E-5,
        1.0E-4, 0.001, 0.01, 0.1, 1.0
      ]
    }
  }
}

Konfigurasi gke-metrics-dashboard.json berikut menentukan dasbor Monitoring yang menggabungkan data error dari metrik berbasis log dan metrik akurasi UTC:

{
  "displayName": "Overall Clock Accuracy",
  "dashboardFilters": [],
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "width": 28,
        "height": 28,
        "widget": {
          "xyChart": {
            "dataSets": [
              {
                "plotType": "LINE",
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "prometheusQuery": "(\n  histogram_quantile(1, sum by (le, node_name) (\n    increase(logging_googleapis_com:user_phc_clock_max_error_bucket{monitored_resource=\"k8s_node\"}[1m])\n  )) * 1000000000\n)\n+ on(node_name) group_left()\nlabel_replace(\n  compute_googleapis_com:instance_clock_accuracy_ptp_kvm_nanosecond_accuracy{monitored_resource=\"gce_instance\"},\n  \"node_name\", \"$1\", \"instance_name\", \"(.*)\"\n)\n",
                  "unitOverride": "ns"
                }
              }
            ],
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR"
            },
            "thresholds": [],
            "yAxis": {
              "label": "Clock Accuracy",
              "scale": "LINEAR"
            }
          }
        }
      }
    ]
  }
}

Opsi konfigurasi VFIO Linux

Tabel berikut menjelaskan parameter untuk mengonfigurasi VFIO (Virtual Function I/O) pada node. VFIO memungkinkan driver userspace yang aman dan tanpa hak istimewa untuk mengakses perangkat I/O.

Parameter konfigurasi	Pembatasan	Nilai default	Deskripsi
nodeVfioConfig.dmaEntryLimit	Harus berupa bilangan bulat antara 65535 dan 4194304.	65535	Menentukan jumlah maksimum entri DMA (halaman) yang dapat dipetakan oleh driver VFIO IOMMU jenis 1 untuk container. Batas ini memengaruhi jumlah total memori host yang dapat disematkan untuk akses perangkat langsung, yang sering kali penting untuk perangkat berperforma tinggi seperti TPU dan GPU. Setelan ini sesuai dengan parameter kernel berikut: /sys/module/vfio_iommu_type1/parameters/dma_entry_limit. Nilai yang lebih tinggi mungkin diperlukan untuk workload yang memetakan region memori besar. Tersedia di GKE versi 1.36.0-gke.3009000 atau yang lebih baru.

Opsi konfigurasi penjadwal I/O disk Linux

Tabel berikut menjelaskan parameter untuk mengonfigurasi penjadwal I/O disk untuk node pool.

Parameter konfigurasi	Nilai yang didukung	Nilai default	Deskripsi
diskIoScheduler.nodeSystemIoScheduler	mq-deadline, bfq, kyber, none	bfq untuk image Container-Optimized OS, none untuk image Ubuntu	Mengonfigurasi penjadwal I/O untuk boot disk atau SSD lokal efemeral yang menjalankan workload sistem node. Tersedia di GKE versi 1.36.0-gke.3009000 atau yang lebih baru.
diskIoScheduler.nodeAttachedDiskIoScheduler	mq-deadline, bfq, kyber, none	none	Mengonfigurasi penjadwal I/O untuk disk yang terpasang. Tersedia di GKE versi 1.36.0-gke.3009000 atau yang lebih baru.

Opsi penggantian kernel Linux

Anda dapat menggunakan file konfigurasi sistem node untuk mengganti parameter kernel Linux tertentu, termasuk command line kernel dan setelan LRU Multi-Gen. Setelan ini didukung untuk cluster yang menjalankan GKE versi 1.35.0-gke.1018000 atau yang lebih baru.

Opsi command line kernel Linux

Tabel berikut menjelaskan opsi command line kernel yang dapat diubah.

Parameter konfigurasi	Nilai yang didukung	Deskripsi
specRstackOverflow	SPEC_RSTACK_OVERFLOW_OFF	Mengubah mitigasi speculative return stack overflow (SRSO). Satu-satunya nilai yang didukung adalah SPEC_RSTACK_OVERFLOW_OFF.
initOnAlloc	INIT_ON_ALLOC_OFF	Mengubah parameter init_on_alloc di command line kernel. Satu-satunya nilai yang didukung adalah INIT_ON_ALLOC_OFF.

Opsi konfigurasi LRU Multi-Gen

Tabel berikut menjelaskan opsi LRU Multi-Gen yang dapat diubah.

Parameter konfigurasi	Nilai yang didukung	Deskripsi
enabled	true, false	Mengaktifkan atau menonaktifkan LRU Multi-Gen. Setelan ini mengonfigurasi tombol darurat.
minTtlMs	Bilangan bulat positif	Opsional. Mengonfigurasi nilai pencegahan thrashing min_ttl_ms untuk LRU Multi-Gen.

Opsi konfigurasi file OS

Anda dapat menggunakan file konfigurasi sistem node untuk menambahkan entri ke file konfigurasi OS tertentu di node Anda. Setelan ini didukung untuk cluster yang menjalankan GKE versi 1.35.0-gke.1018000 atau yang lebih baru.

Entri /etc/hosts tambahan

Kolom ini menambahkan entri file /etc/hosts, seperti dalam contoh berikut:

linuxConfig:
  additionalEtcHosts:
    - ip: 1.2.3.4
      host: myownpersonaldomain.com
    - ip: 5.6.7.8
      host: otherpersonaldomain.com

Entri /etc/systemd/resolved.conf tambahan

Kolom ini menambahkan entri file /etc/systemd/resolved.conf. Kolom ini menerima array key-value pair. Kunci berikut didukung:

• DNS
• FallbackDNS
• Domains
• LLMNR
• MulticastDNS
• DNSSEC
• DNSOverTLS
• Cache
• CacheFromLocalhost
• DNSStubListener
• DNSStubListenerExtra
• ReadEtcHosts
• ResolveUnicastSingleLabel
• StaleRetentionSec

Contoh berikut menambahkan dua nilai server DNS (8.8.8.8 dan 8.8.4.4) ke kunci DNS dan nilai domain (myownpersonaldomain.com) ke kunci Domains:

linuxConfig:
  additionalEtcSystemdResolvedConf:
    - key: DNS
      value:
        - 8.8.8.8
        - 8.8.4.4
    - key: Domains
      value:
        - myownpersonaldomain.com

Entri /etc/resolv.conf tambahan

Kolom ini menambahkan entri file /etc/resolv.conf. Kolom ini menerima array pasangan nilai kunci. Kunci berikut didukung:

• nameserver
• search
• sortlist
• options

Contoh berikut menambahkan nilai server DNS (1.1.1.1) ke kunci nameserver dan nilai domain (myownpersonaldomain.com) ke kunci search:

linuxConfig:
  additionalEtcResolvConf:
    - key: nameserver
      value:
        - 1.1.1.1
    - key: search
      value:
        - myownpersonaldomain.com

Konfigurasi zona waktu

Kolom timeZone menetapkan zona waktu pada node, misalnya, America/Los_Angeles. Setelan ini didukung untuk cluster yang menjalankan GKE versi 1.35.0-gke.1018000 atau yang lebih baru.

Contoh berikut menetapkan kolom timeZone ke America/Los_Angeles:

linuxConfig:
  timeZone: America/Los_Angeles

Langkah berikutnya

• Pelajari cara memigrasikan node ke cgroupv2 Linux.
• Pelajari cara menambahkan dan mengelola node pool.
• Pelajari cara menyesuaikan konfigurasi containerd di node GKE.
• Pelajari cara otomatis melakukan bootstrap node GKE dengan DaemonSets.