Memecahkan masalah pengelolaan alamat IP di cluster VPC

Bagian ini 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 dari subnet yang ditetapkan ke cluster Anda kehabisan alamat IP yang tersedia. Hal ini biasanya terjadi saat menskalakan node pool atau membuat cluster besar.

Kehabisan alamat IP Pod: Rentang CIDR Pod yang ditetapkan ke cluster Anda 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 terletak pada rentang alamat IP node (tempat node itu sendiri mendapatkan alamat IP-nya) atau rentang alamat IP Pod (tempat penampung 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 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 kumpulan node (jika berlaku). Perhatikan setiap node pool yang terpengaruh dan rentang alamat IP Pod IPv4 tertentu serta konfigurasi Pod maksimum per node jika berbeda dengan setelan seluruh cluster. Selain itu, catat konfigurasi default dan kustom (jika ada) untuk Pod maksimum per node dalam konfigurasi kumpulan node.

Mengonfirmasi masalah kehabisan alamat IP

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

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

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

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

Menyelesaikan kehabisan alamat IP Pod:

  • Ubah 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.

Mengurangi Pod per node untuk memperbarui alamat IP:

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 dibatasi, buat cluster pengganti dengan ukuran rentang alamat IP yang sesuai. Lihat rentang IP untuk cluster native VPC dan perencanaan rentang IP.

Men-debug masalah kehabisan alamat IP dengan gcpdiag

gcpdiag adalah alat open source. Ini bukan produk Google Cloud yang didukung secara resmi. Anda dapat menggunakan alat gcpdiag untuk membantu mengidentifikasi dan memperbaiki masalah project Google Cloud. Untuk mengetahui informasi selengkapnya, lihat project gcpdiag di GitHub.

Untuk memeriksa penyebab kehabisan alamat IP di cluster GKE Autopilot dan Standard, pertimbangkan hal berikut:
  • Status cluster: Memeriksa status cluster jika kehabisan alamat IP dilaporkan.
  • Network Analyzer: Mengkueri 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.

Konsol Google Cloud

  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 konsol Google Cloud dan aktifkan Cloud Shell.
    3. Buka Cloud Console
  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 dalam penampung 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 masalah berakhir. Tetapkan waktu saat ini jika masalah masih berlangsung.

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