Memecahkan masalah pengelolaan alamat IP di cluster VPC

Pengelolaan alamat IP yang efektif sangat penting untuk stabilitas dan skalabilitas Google Kubernetes Engine (GKE) cluster VPC native. 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. Informasi 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 membantu mereka berkolaborasi dengan lebih baik bersama admin dan operator Platform untuk mendapatkan resolusi yang lebih cepat. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam Google Cloud konten, 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.

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 penggunaan alamat IP cluster, lakukan hal berikut:

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

    Buka cluster Kubernetes

  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 kemampuan observasi, 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 menampilkan 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 tersebut mencerminkan seluruh rentang Pod untuk node, bukan hanya alamat IP yang digunakan. Jika cluster berbagi rentang alamat IP yang sama, persentase penggunaan akan menampilkan total gabungannya.

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

Jika penggunaan 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 cukup rentang alamat IP atau ruang alamat RFC 1918, pertimbangkan rentang non-RFC 1918 (termasuk ruang alamat Class E).

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 diturunkan skalanya: GKE mencadangkan 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 menurunkan skala jumlah node, GKE akan terus mencadangkan ruang alamat IP berdasarkan initial_node_count node pool atau jumlah node saat ini di node pool, mana pun yang lebih besar. Situasi ini dapat menyebabkan cluster melaporkan kehabisan alamat IP meskipun jumlah node aktif saat ini rendah.

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

Konvensi penamaan subnet tertentu: Cara subnet diberi nama dalam pesan error dapat membantu Anda mengetahui apakah masalahnya terkait dengan rentang alamat IP node (tempat node itu sendiri 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 dan CIDR subnet. Selain itu, perhatikan rentang Cluster Pod IPv4 default dan tambahan (termasuk nama dan CIDR), apakah perutean traffic VPC native diaktifkan, dan setelan Pod maksimum per node di tingkat cluster dan node pool (jika berlaku). Perhatikan node pool yang terpengaruh dan rentang alamat IP Pod IPv4 spesifik serta konfigurasi Pod maksimum per node jika berbeda dari setelan seluruh cluster. Selain itu, catat konfigurasi default dan kustom (jika ada) untuk Pod maksimum per node dalam konfigurasi node pool.

Konfirmasi masalah kehabisan alamat IP

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

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

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

  • Log audit: Periksa kolom resourceName di entri IP_SPACE_EXHAUSTED, lalu 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 dari 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 habis. Jika nilai resourceName dalam format "[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]", berarti rentang alamat IP Pod habis.

Atasi kehabisan alamat IP Pod:

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

Kurangi Pod per node untuk mengosongkan alamat IP:

Atasi kehabisan alamat IP node:

  • Tinjau perencanaan alamat IP: Pastikan rentang alamat IP node selaras dengan persyaratan penskalaan Anda.
  • Buat cluster baru (jika diperlukan): 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.

Men-debug masalah kehabisan alamat IP dengan gcpdiag

gcpdiag adalah alat open source. Alat ini bukan produk yang didukung secara resmi 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 di cluster GKE Autopilot dan Standar, pertimbangkan hal berikut:
  • Status cluster: Memeriksa status cluster jika kehabisan alamat IP dilaporkan.
  • Network analyzer: Mengirim 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.

Google Cloud Konsol

  1. Selesaikan, 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 Google Cloud konsol , lalu 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 berlaku, ikuti petunjuk output untuk memperbaiki pemeriksaan yang gagal.

Docker

Anda dapat menjalankan gcpdiag menggunakan wrapper yang memulai gcpdiag di sebuah 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 saat masalah dimulai.
  • end_time: Waktu saat masalah berakhir. Tetapkan waktu saat ini jika masalah masih berlangsung.

Flag yang berguna:

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

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 mengatasi 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