Memecahkan masalah pengelolaan alamat IP di cluster VPC

Pengelolaan alamat IP yang efektif sangat penting untuk stabilitas dan skalabilitas cluster VPC native Google Kubernetes Engine (GKE). Masalah dapat mencegah penskalaan, atau menyebabkan kegagalan workload seperti Pod yang gagal dijadwalkan.

Gunakan dokumen ini untuk memecahkan masalah dan memperbaiki masalah terkait alokasi alamat IP, stabilitas jaringan, dan fitur jaringan lanjutan di cluster VPC native GKE.

Informasi ini terutama ditujukan untuk admin dan operator Platform yang mengelola infrastruktur jaringan cluster. Hal ini juga membantu developer Aplikasi memahami bagaimana batasan jaringan yang mendasarinya, seperti ruang alamat IP yang habis, dapat memengaruhi workload mereka. Meskipun developer mungkin tidak mengonfigurasi VPC secara langsung, memahami masalah umum ini akan membantu mereka berkolaborasi dengan lebih baik dengan admin dan operator Platform untuk mendapatkan penyelesaian yang lebih cepat. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud , lihat Peran dan tugas pengguna GKE umum.

Mendiagnosis kehabisan alamat IP

Kehabisan alamat IP di cluster dapat mencegah penskalaan node dan mengganggu workload Anda. Bagian ini menjelaskan cara menggunakan pemantauan penggunaan alamat IP di GKE untuk mendeteksi dan menyelesaikan potensi masalah kehabisan alamat IP.

GKE menghitung penggunaan alamat IP menggunakan data dari insight Network Analyzer dan sumber data GKE lainnya. Pemantauan ini tersedia untuk semua cluster VPC native.

Untuk melihat pemakaian alamat IP cluster, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman Kubernetes clusters.

    Buka Kubernetes clusters

  2. Klik nama cluster yang ingin Anda periksa. Tindakan ini akan membuka halaman Details cluster.

  3. Buka halaman IP utilization menggunakan salah satu metode berikut:

    • Pilih tab Observability, lalu di menu navigasi observability, klik IP utilization.

    • Di bagian Networking, temukan baris Cluster Pod IPv4 range (default), lalu klik View IP utilization.

  4. Tinjau kolom Status of IP allocation. Kolom ini menunjukkan persentase alamat IP yang dialokasikan dalam rentang alamat IP Pod Anda. GKE menganggap semua alamat IP dalam rentang CIDR yang ditetapkan node sebagai dialokasikan, terlepas dari apakah alamat IP individual ditetapkan ke Pod atau tidak. Perilaku ini berarti bahwa persentase mencerminkan seluruh rentang Pod untuk sebuah node, bukan hanya alamat IP yang digunakan. Jika cluster menggunakan rentang alamat IP yang sama, persentase pemanfaatan akan menampilkan total gabungannya.

  5. Untuk melihat tampilan mendetail penggunaan alamat IP, termasuk rentang CIDR, informasi subnet, dan rekomendasi, klik Show details.

Jika pemanfaatan alamat IP Anda tinggi (mendekati 100%), pertimbangkan solusi berikut untuk mencegah kehabisan alamat IP:

  • Tambahkan lebih banyak rentang alamat IPv4 Pod menggunakan CIDR multi-Pod yang terpisah-pisah. Fitur ini memungkinkan Anda menambahkan lebih banyak alamat IPv4 untuk Pod tanpa perlu membuat ulang cluster atau mengonfigurasi subnet baru.
  • Tambahkan lebih banyak subnet dengan rentang alamat IPv4 tambahan di cluster. Fitur ini memungkinkan node pool baru menggunakan alamat IP dari subnet yang baru ditambahkan.
  • Buat cluster baru dengan nilai yang lebih rendah untuk jumlah maksimum Pod. Pendekatan ini mencadangkan lebih sedikit alamat IP untuk setiap node, yang dapat membantu Anda mengelola konsumsi alamat IP secara keseluruhan dalam rentang jaringan cluster. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi Pod maksimum per node.
  • Jika Anda tidak memiliki rentang alamat IP atau ruang alamat RFC 1918 yang cukup, pertimbangkan rentang non-RFC 1918 (termasuk ruang alamat Class E).

Memahami matematika alokasi CIDR Pod GKE

Sumber kebingungan yang umum adalah bahwa GKE tidak mengalokasikan alamat IP Pod individual secara dinamis dari pool pusat sesuai permintaan. Sebagai gantinya, saat node baru bergabung ke cluster Anda, GKE akan mengukir blok CIDR yang berdekatan dari rentang Pod sekunder subnet dan menetapkannya secara eksklusif ke node tersebut.

Untuk mencegah tabrakan daur ulang IP selama peluncuran Pod yang cepat, GKE mengalokasikan ukuran blok per node yang sama dengan blok pangkat dua terkecil yang menampung setidaknya 2 × Pod maksimum per node alamat:

Per-node Pod CIDR block size (addresses) = 2^(ceil(log2(2 * max_pods_per_node)))
  • Konfigurasi default (--max-pods-per-node=110): memerlukan setidaknya 2 × 110 = 220 alamat. Kelipatan dua terdekat adalah 256 alamat, yang menetapkan blok /24 (256 alamat IP) ke setiap node.
  • Dampak pada kapasitas node cluster: karena setiap node menggunakan blok /24 (256 alamat IP Pod) terlepas dari berapa banyak Pod yang berjalan di node tersebut, jumlah maksimum node yang didukung oleh rentang Pod sekunder bergantung langsung pada setelan --max-pods-per-node Anda:
Pod maksimum per node Blok per node dialokasikan Node maksimum per rentang Pod /19 (8.192 alamat IP) Node maksimum per rentang Pod /16 (65.536 alamat IP)
110 (Default) /24 (256 alamat IP) 32 node 256 node
64 /25 (128 alamat IP) 64 node 512 node
32 (Default Autopilot) /26 (64 alamat IP) 128 node 1.024 node
16 /27 (32 alamat IP) 256 node 2.048 node
8 /28 (16 alamat IP) 512 node 4.096 node

Memecahkan masalah jaringan tertentu

Bagian berikut berisi panduan untuk menyelesaikan masalah terkait cluster VPC native. Anda juga dapat melihat insight penggunaan alamat IP GKE.

Resource jaringan default belum siap

Gejala

Anda akan mendapatkan pesan error yang mirip dengan berikut ini:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Kemungkinan penyebab

Ada operasi paralel di subnet yang sama. Misalnya, cluster VPC native lain sedang dibuat, atau rentang sekunder sedang ditambahkan atau dihapus di subnet.

Resolusi

Coba lagi perintah tersebut.

Nilai tidak valid untuk IPCidrRange.

Gejala

Anda akan mendapatkan pesan error yang mirip dengan berikut ini:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
Kemungkinan penyebab

Cluster VPC native lain sedang dibuat secara bersamaan dan mencoba mengalokasikan rentang yang sama di jaringan VPC yang sama.

Rentang sekunder yang sama ditambahkan ke subnetwork di jaringan VPC yang sama.

Resolusi

Jika error ini ditampilkan saat pembuatan cluster saat tidak ada rentang sekunder yang ditentukan, coba lagi perintah pembuatan cluster.

Ruang alamat IP yang kosong tidak cukup untuk Pod

Gejala

Cluster macet dalam status penyediaan untuk jangka waktu yang lebih lama.

Pembuatan cluster menampilkan error Grup Instance Terkelola (MIG).

Saat Anda menambahkan satu atau beberapa node ke cluster, error berikut akan muncul:

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
Kemungkinan penyebab

Kehabisan alamat IP node: Rentang alamat IP utama subnet yang ditetapkan ke cluster Anda kehabisan alamat IP yang tersedia. Hal ini biasanya terjadi saat menskalakan node pool atau membuat cluster besar.

Jumlah node awal yang tinggi di node pool yang diperkecil skalanya: GKE memesan alamat IP untuk Pod berdasarkan kapasitas awal yang Anda minta saat membuat node pool. Jika Anda membuat node pool dengan initial_node_count yang tinggi, lalu memperkecil skala jumlah node, GKE akan terus mencadangkan ruang alamat IP berdasarkan jumlah yang lebih besar dari initial_node_count node pool atau jumlah node saat ini di node pool. Situasi ini dapat menyebabkan status saat cluster melaporkan kehabisan alamat IP meskipun jumlah node aktif saat ini rendah.

Kehabisan alamat IP Pod: Rentang Pod CIDR yang ditetapkan ke cluster Anda sudah penuh. Hal ini terjadi jika jumlah Pod melebihi kapasitas CIDR Pod, terutama dengan kepadatan Pod yang tinggi per node atau deployment yang besar.

Konvensi penamaan subnet tertentu: Cara penamaan subnet dalam pesan error dapat membantu Anda mengetahui apakah masalahnya ada pada rentang alamat IP node (tempat node mendapatkan alamat IP-nya) atau rentang alamat IP Pod (tempat container di dalam Pod mendapatkan alamat IP-nya).

Kehabisan rentang sekunder (Autopilot): Di cluster Autopilot, rentang sekunder yang ditetapkan untuk alamat IP Pod habis karena penskalaan atau kepadatan Pod yang tinggi.

Solusi

Kumpulkan informasi berikut tentang cluster Anda: nama, versi bidang kontrol, mode operasi, nama VPC terkait, serta nama subnet dan CIDR. Selain itu, perhatikan rentang IPv4 Pod Cluster default dan tambahan (termasuk nama dan CIDR), apakah pemilihan rute traffic native VPC diaktifkan, dan setelan Pod maksimum per node di tingkat cluster dan node pool (jika berlaku). Catat node pool yang terpengaruh dan rentang alamat IP Pod IPv4 spesifiknya serta konfigurasi Pod maksimum per node jika berbeda dengan setelan di seluruh cluster. Selain itu, catat konfigurasi default dan kustom (jika ada) untuk Pod maksimum per node dalam konfigurasi node pool.

Mengonfirmasi masalah kehabisan alamat IP

  • Network Intelligence Center: Periksa tingkat alokasi alamat IP yang tinggi dalam rentang alamat IP Pod di Network Intelligence Center untuk cluster GKE Anda.

    Jika Anda mengamati tingkat alokasi alamat IP yang tinggi dalam rentang Pod di Network Intelligence Center, berarti rentang alamat IP Pod Anda sudah habis.

    Jika rentang alamat IP Pod menunjukkan tingkat alokasi normal, tetapi Anda masih mengalami kehabisan alamat IP, kemungkinan rentang alamat IP node Anda sudah habis.

  • Log audit: Periksa kolom resourceName di entri IP_SPACE_EXHAUSTED, bandingkan dengan nama subnet atau nama rentang alamat IP Pod sekunder.

  • Periksa apakah rentang alamat IP yang habis adalah rentang alamat IP node atau rentang alamat IP Pod.

    Untuk memverifikasi apakah rentang alamat IP yang habis adalah rentang alamat IP node atau rentang alamat IP Pod, periksa apakah nilai resourceName di bagian ipSpaceExhausted entri log IP_SPACE_EXHAUSTED berkorelasi dengan nama subnet atau nama rentang alamat IPv4 sekunder untuk Pod yang digunakan di cluster GKE yang terpengaruh.

    Jika nilai resourceName dalam format "[Subnet_name]", berarti rentang alamat IP node telah habis. Jika nilai resourceName dalam format "[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]", maka rentang alamat IP Pod habis.

Mengatasi kehabisan alamat IP Pod:

  • Mengubah ukuran CIDR Pod yang ada: Meningkatkan ukuran rentang alamat IP Pod saat ini. Anda dapat menambahkan rentang IP Pod ke cluster menggunakan CIDR multi-Pod yang berjauhan.
  • Membuat subnet tambahan: Tambahkan subnet dengan CIDR Pod khusus ke cluster.

Kurangi Pod per node untuk mengosongkan alamat IP:

Mengatasi kehabisan alamat IP node:

  • Tinjau perencanaan alamat IP: Pastikan rentang alamat IP node sesuai dengan persyaratan penskalaan Anda.
  • Buat cluster baru (jika perlu): Jika rentang alamat IP node sangat terbatas, buat cluster pengganti dengan ukuran rentang alamat IP yang sesuai. Lihat rentang IP untuk cluster VPC native dan perencanaan rentang IP.

Perintah diagnostik tambahan dan playbook resolusi yang tidak mengganggu

Untuk mempercepat pemecahan masalah dan mengatasi kehabisan alamat IP sekaligus meminimalkan periode nonaktif cluster, terapkan playbook diagnostik dan operasional berikut:

1. Biseksi command line menggunakan Cloud Logging dan Recommender

Untuk membagi masalah kehabisan alamat IP dari command line, lakukan tugas berikut:

  • Buat kueri Cloud Logging untuk peristiwa kehabisan alamat IP eksplisit: logquery resource.type="k8s_cluster" logName:"logs/container.googleapis.com" ("IP_SPACE_EXHAUSTED" OR "ran out of IPs" OR "wouldn't fit if a new node is added")
  • Buat kueri ke Recommender API untuk mendapatkan insight Network Analyzer otomatis (pemanfaatan lebih dari 80%): sh gcloud recommender insights list \ --insight-type=google.networkanalyzer.container.ipAddressInsight \ --project=PROJECT_ID --location=GLOBAL
2. Perluasan subnet utama langsung di tempat (untuk kehabisan alamat IP utama node)

Tidak seperti rentang sekunder, Anda dapat memperluas rentang alamat host IP utama subnet secara langsung di Compute Engine tanpa membuat ulang cluster atau mengganggu workload:

gcloud compute networks subnets expand-ip-range SUBNET_NAME \
    --region=REGION \
    --prefix-length=NEW_PREFIX_LENGTH

Misalnya, memperluas subnet utama dari /24 ke /22 akan meningkatkan kapasitas alamat IP host VM utama dari 252 menjadi 1.020 node VM.

3. Playbook migrasi node pool blue-green (untuk kehabisan alamat IP Pod)

Jika node pool yang ada terkunci dalam rentang sekunder kecil atau alokasi alamat IP besar dari konfigurasi default --max-pods-per-node=110, migrasikan workload ke node pool baru dengan CIDR berukuran tepat:

# Step 1: Add a new secondary IPv4 range to your subnet
gcloud compute networks subnets update SUBNET_NAME \
    --region=REGION \
    --add-secondary-ranges=NEW_SECONDARY_RANGE_NAME=NEW_CIDR

# Step 2: Register the new Pod range with your GKE cluster
gcloud container clusters update CLUSTER_NAME \
    --region=REGION \
    --additional-pod-ipv4-ranges=NEW_SECONDARY_RANGE_NAME

# Step 3: Launch a replacement node pool with right-sized --max-pods-per-node
gcloud container node-pools create pool-blue-v2 \
    --cluster=CLUSTER_NAME \
    --region=REGION \
    --max-pods-per-node=32 \
    --pod-ipv4-range=NEW_SECONDARY_RANGE_NAME \
    --enable-autoscaling --min-nodes=2 --max-nodes=60

# Step 4: Gracefully cordon and drain old nodes
kubectl cordon -l cloud.google.com/gke-nodepool=OLD_POOL_NAME
kubectl drain -l cloud.google.com/gke-nodepool=OLD_POOL_NAME --ignore-daemonsets --delete-emptydir-data --force --grace-period=300

# Step 5: Delete old node pool after workloads migrate
gcloud container node-pools delete OLD_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --region=REGION
4. Desain rentang Class E (240.0.0.0/4) dengan penyamaran IP

Jika jaringan perusahaan Anda kehabisan ruang alamat RFC 1918, alokasikan blok IPv4 Class E (240.0.0.0/4) ke rentang Pod sekunder Anda (blok ini menyediakan lebih dari 268 juta alamat). Aktifkan agen penyamaran IP GKE agar traffic keluar ke database lokal atau endpoint jaringan lain yang ada disamarkan menggunakan alamat host RFC 1918 utama node.

Men-debug masalah kehabisan alamat IP dengan gcpdiag

gcpdiag adalah alat open source. Produk ini tidak didukung secara resmi oleh Google Cloud . Anda dapat menggunakan alat gcpdiag untuk membantu mengidentifikasi dan memperbaiki Google Cloud masalah project. Untuk mengetahui informasi selengkapnya, lihat project gcpdiag di GitHub.

Untuk memeriksa penyebab kehabisan alamat IP pada cluster GKE Autopilot dan Standard, pertimbangkan hal berikut:
  • Status cluster: Memeriksa status cluster jika kehabisan alamat IP dilaporkan.
  • Network analyzer: Membuat kueri log stackdriver untuk log network analyzer guna mengonfirmasi apakah ada kehabisan alamat IP Pod atau node.
  • Jenis Cluster: Memeriksa jenis cluster dan memberikan rekomendasi yang relevan berdasarkan jenis cluster.

KonsolGoogle Cloud

  1. Lengkapi, lalu salin perintah berikut. 
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. Buka konsol Google Cloud dan aktifkan Cloud Shell.
    3. Buka Konsol Cloud
  3. Tempel perintah yang disalin.
  4. Jalankan perintah gcpdiag, yang mendownload image docker gcpdiag, lalu melakukan pemeriksaan diagnostik. Jika ada, ikuti petunjuk output untuk memperbaiki pemeriksaan yang gagal.

Docker

Anda dapat menjalankan gcpdiag menggunakan wrapper yang memulai gcpdiag dalam container Docker. Docker atau Podman harus diinstal.

  1. Salin dan jalankan perintah berikut di workstation lokal Anda. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Jalankan perintah gcpdiag. 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

Lihat parameter yang tersedia untuk runbook ini.

Ganti kode berikut:

  • PROJECT_ID: ID project yang berisi resource
  • CLUSTER_NAME: Nama cluster GKE target dalam project Anda.
  • LOCATION: Zona atau region tempat cluster Anda berada.
  • start_time: Waktu masalah dimulai.
  • end_time: Waktu berakhirnya masalah. Tetapkan waktu saat ini jika masalah masih terjadi.

Flag yang berguna:

Untuk mengetahui daftar dan deskripsi semua flag alat gcpdiag, lihat petunjuk penggunaan gcpdiag.

Mengonfirmasi apakah SNAT default dinonaktifkan

Gunakan perintah berikut untuk memeriksa status SNAT default:

gcloud container clusters describe CLUSTER_NAME

Ganti CLUSTER_NAME dengan nama cluster Anda.

Outputnya mirip dengan hal berikut ini:

networkConfig:
  disableDefaultSnat: true
  network: ...

Tidak dapat menggunakan --disable-default-snat tanpa --enable-ip-alias

Dengan pesan error ini, dan must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster, berarti Anda harus secara eksplisit menetapkan flag --disable-default-snat saat membuat cluster karena Anda menggunakan alamat IP publik di cluster pribadi.

Jika Anda melihat pesan error seperti cannot disable default sNAT ..., ini berarti SNAT default tidak dapat dinonaktifkan di cluster Anda. Untuk menyelesaikan masalah ini, tinjau konfigurasi cluster Anda.

Men-debug Cloud NAT dengan SNAT default dinonaktifkan

Jika Anda memiliki cluster pribadi yang dibuat dengan flag --disable-default-snat dan telah menyiapkan Cloud NAT untuk akses internet, tetapi tidak ada traffic yang terhubung ke internet dari Pod, pastikan rentang Pod tersebut disertakan dalam konfigurasi Cloud NAT.

Jika ada masalah dengan komunikasi Pod ke Pod, periksa aturan iptables pada node untuk memverifikasi bahwa rentang Pod tidak disamarkan oleh aturan iptables.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi penyamaran IP GKE.

Jika Anda belum mengonfigurasi agen penyamaran IP untuk cluster, GKE akan otomatis memastikan bahwa komunikasi Pod ke Pod tidak disamarkan. Namun, jika dikonfigurasi, agen penyamaran IP akan menggantikan aturan penyamaran IP default. Pastikan aturan tambahan dikonfigurasi di agen penyamaran IP untuk mengabaikan penyamaran rentang Pod.

Komunikasi jaringan cluster stack ganda tidak berfungsi sesuai ekspektasi

Kemungkinan penyebab
Aturan firewall yang dibuat oleh cluster GKE tidak menyertakan alamat IPv6 yang dialokasikan.
Resolusi
Anda dapat memvalidasi aturan firewall dengan mengikuti langkah-langkah berikut:

  1. Verifikasi konten aturan firewall:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Ganti FIREWALL_RULE_NAME dengan nama aturan firewall.

    Setiap cluster stack ganda membuat aturan firewall yang memungkinkan node dan Pod berkomunikasi satu sama lain. Isi aturan firewall-nya mirip dengan berikut ini:

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    Nilai sourceRanges harus sama dengan subnetIpv6CidrBlock. Nilai targetTags harus sama dengan tag di node GKE. Untuk memperbaiki masalah ini, perbarui aturan firewall dengan informasi blok ipAllocationPolicy cluster.

Langkah berikutnya