Halaman ini menjelaskan cara mengontrol komunikasi antara Pod dan Service cluster menggunakan penerapan kebijakan jaringan GKE.
Anda juga dapat mengontrol traffic keluar Pod ke endpoint atau Service di luar cluster menggunakan kebijakan jaringan nama domain yang sepenuhnya memenuhi syarat (FQDN). Untuk mengetahui informasi selengkapnya, lihat Mengontrol komunikasi antara Pod dan Service menggunakan FQDN.
Tentang penerapan kebijakan jaringan GKE
Dengan penerapan kebijakan jaringan, Anda dapat membuat Kebijakan Jaringan Kubernetes di cluster Anda. Secara default, semua Pod dalam cluster dapat berkomunikasi satu sama lain dengan bebas. Kebijakan jaringan membuat aturan firewall tingkat Pod yang menentukan Pod dan Layanan mana yang dapat saling mengakses di dalam cluster Anda.
Dengan menentukan kebijakan jaringan, Anda dapat mengaktifkan hal-hal seperti defense in depth saat cluster menyajikan aplikasi multilevel. Misalnya, Anda dapat membuat kebijakan jaringan untuk memastikan bahwa layanan front-end yang disusupi di aplikasi Anda tidak dapat berkomunikasi langsung dengan layanan penagihan atau akuntansi di beberapa level ke bawah.
Kebijakan jaringan juga dapat mempermudah aplikasi Anda untuk menghosting data dari beberapa pengguna secara bersamaan. Misalnya, Anda dapat menyediakan multi-tenancy yang aman dengan menentukan model tenant per namespace. Dalam model semacam ini, aturan kebijakan jaringan dapat memastikan bahwa Pod dan Service di namespace tertentu tidak dapat mengakses Pod atau Service lain di namespace yang berbeda.
Sebelum memulai
Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:
- Aktifkan Google Kubernetes Engine API. Aktifkan Google Kubernetes Engine API
- Jika ingin menggunakan Google Cloud CLI untuk tugas ini,
instal lalu
lakukan inisialisasi
gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan
gcloud components update
.
Persyaratan dan batasan
Persyaratan dan batasan berikut berlaku untuk cluster Autopilot dan Standard:- Anda harus mengizinkan traffic keluar ke server metadata.
- Jika Anda menentukan kolom
endPort
di Kebijakan Jaringan di cluster yang telah mengaktifkan GKE Dataplane V2, kolom tersebut mungkin tidak akan berlaku mulai di GKE versi 1.22. Untuk mengetahui informasi selengkapnya, lihat Rentang port Kebijakan Jaringan tidak diterapkan. Untuk cluster Autopilot, GKE Dataplane V2 selalu diaktifkan.
- Anda harus mengizinkan traffic keluar ke server metadata jika menggunakan kebijakan jaringan dengan Workload Identity Federation untuk GKE.
- Mengaktifkan penerapan kebijakan jaringan akan meningkatkan jejak memori proses
kube-system
sekitar 128 MB, dan memerlukan sekitar 300 milicore CPU. Ini berarti, jika kebijakan jaringan untuk cluster yang ada diaktifkan, Anda mungkin perlu meningkatkan ukuran cluster agar dapat terus menjalankan workload terjadwal. - Untuk mengaktifkan penerapan kebijakan jaringan, node Anda harus dibuat ulang. Jika cluster memiliki masa pemeliharaan aktif, node tidak akan otomatis dibuat ulang hingga masa pemeliharaan berikutnya. Anda dapat mengupgrade cluster secara manual kapan saja sesuai keinginan Anda.
- Ukuran cluster minimum yang diperlukan untuk menjalankan penerapan kebijakan jaringan adalah tiga instance
e2-medium
atau satu instance jenis mesin dengan lebih dari 1 vCPU yang dapat dialokasikan. Lihat masalah umum GKE untuk mengetahui detail selengkapnya. - Kebijakan jaringan tidak didukung untuk cluster yang node-nya adalah instance
f1-micro
ataug1-small
, karena persyaratan resource terlalu tinggi.
Untuk mengetahui informasi lebih lanjut tentang jenis mesin node dan resource yang dapat dialokasikan, baca Arsitektur cluster Standard - Node.
Mengaktifkan penerapan kebijakan jaringan
Penerapan kebijakan jaringan diaktifkan secara default untuk cluster Autopilot, sehingga Anda dapat langsung membuka bagian Membuat kebijakan jaringan.
Anda dapat mengaktifkan penerapan kebijakan jaringan di cluster Standard menggunakan gcloud CLI, Konsol Google Cloud, atau GKE API.
Penerapan kebijakan jaringan disertakan dalam GKE Dataplane V2. Anda tidak perlu mengaktifkan penerapan kebijakan jaringan di cluster yang menggunakan GKE Dataplane V2.
Perubahan ini memerlukan pembuatan ulang node, yang dapat menyebabkan gangguan pada workload yang sedang berjalan. Untuk mengetahui detail tentang perubahan khusus ini, temukan baris yang sesuai dalam tabel perubahan manual yang membuat ulang node menggunakan strategi upgrade node dan mematuhi kebijakan pemeliharaan. Untuk mempelajari update node lebih lanjut, lihat Merencanakan gangguan update node.
gcloud
-
Di konsol Google Cloud, aktifkan Cloud Shell.
Di bagian bawah Google Cloud Console, Cloud Shell sesi akan terbuka dan menampilkan perintah command line. Cloud Shell adalah lingkungan shell dengan Google Cloud CLI yang sudah terinstal, dan dengan nilai yang sudah ditetapkan untuk project Anda saat ini. Diperlukan waktu beberapa detik untuk melakukan inisialisasi sesi.
Untuk mengaktifkan penerapan kebijakan jaringan saat membuat cluster baru, jalankan perintah berikut:
gcloud container clusters create CLUSTER_NAME --enable-network-policy
Ganti
CLUSTER_NAME
dengan nama cluster baru.Guna mengaktifkan penerapan kebijakan jaringan untuk cluster yang ada, lakukan tugas berikut:
Jalankan perintah berikut untuk mengaktifkan add-on:
gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
Ganti
CLUSTER_NAME
dengan nama cluster.Jalankan perintah berikut untuk mengaktifkan penerapan kebijakan jaringan di cluster Anda, yang akan membuat ulang node pool cluster dengan penerapan kebijakan jaringan yang diaktifkan:
gcloud container clusters update CLUSTER_NAME --enable-network-policy
Konsol
Untuk mengaktifkan penerapan kebijakan jaringan saat membuat cluster baru:
Buka halaman Google Kubernetes Engine di Konsol Google Cloud.
Klik add_box Create.
Pada dialog Create cluster, untuk GKE Standard, klik Configure.
Konfigurasi cluster Anda sesuai pilihan.
Dari panel navigasi, di bagian Cluster, klik Networking.
Centang kotak Aktifkan kebijakan jaringan.
Klik Create.
Untuk mengaktifkan penerapan kebijakan jaringan untuk cluster yang ada:
Buka halaman Google Kubernetes Engine di Konsol Google Cloud.
Di daftar cluster, klik nama cluster yang ingin diubah.
Di bagian Networking, di kolom Network policy, klik edit Edit network policy.
Centang kotak Enable network policy for master, lalu klik Save Changes.
Tunggu hingga perubahan diterapkan, lalu klik edit Edit network policy lagi.
Centang kotak Aktifkan kebijakan jaringan untuk node.
Klik Simpan Perubahan.
API
Untuk mengaktifkan penerapan kebijakan jaringan, lakukan hal berikut:
Tentukan objek
networkPolicy
di dalam objekcluster
yang Anda berikan ke projects.zones.clusters.create atau project.zone.clusters.update.Objek
networkPolicy
memerlukan enum yang menentukan penyedia kebijakan jaringan yang akan digunakan, dan nilai boolean yang menentukan apakah akan mengaktifkan kebijakan jaringan atau tidak. Jika Anda mengaktifkan kebijakan jaringan, tetapi tidak menetapkan penyedia, perintahcreate
danupdate
akan menampilkan error.
Menonaktifkan penerapan kebijakan jaringan di cluster Standard
Anda dapat menonaktifkan penerapan kebijakan jaringan menggunakan gcloud CLI, Konsol Google Cloud, atau GKE API. Anda tidak dapat menonaktifkan penerapan kebijakan jaringan di cluster Autopilot atau cluster yang menggunakan GKE Dataplane V2.
Perubahan ini memerlukan pembuatan ulang node, yang dapat menyebabkan gangguan pada workload yang sedang berjalan. Untuk mengetahui detail tentang perubahan khusus ini, temukan baris yang sesuai dalam tabel perubahan manual yang membuat ulang node menggunakan strategi upgrade node dan mematuhi kebijakan pemeliharaan. Untuk mempelajari update node lebih lanjut, lihat Merencanakan gangguan update node.
gcloud
-
Di konsol Google Cloud, aktifkan Cloud Shell.
Di bagian bawah Google Cloud Console, Cloud Shell sesi akan terbuka dan menampilkan perintah command line. Cloud Shell adalah lingkungan shell dengan Google Cloud CLI yang sudah terinstal, dan dengan nilai yang sudah ditetapkan untuk project Anda saat ini. Diperlukan waktu beberapa detik untuk melakukan inisialisasi sesi.
Untuk menonaktifkan penerapan kebijakan jaringan, lakukan tugas berikut:
- Nonaktifkan penerapan kebijakan jaringan di cluster Anda:
gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
Ganti
CLUSTER_NAME
dengan nama cluster.Setelah Anda menjalankan perintah ini, GKE akan membuat ulang node pool cluster dengan penerapan kebijakan jaringan yang dinonaktifkan.
Pastikan semua node Anda telah dibuat ulang:
kubectl get nodes -l projectcalico.org/ds-ready=true
Jika operasi berhasil, output-nya akan mirip dengan yang berikut ini:
No resources found
Jika outputnya mirip dengan yang berikut ini, Anda harus menunggu GKE selesai mengupdate node pool:
NAME STATUS ROLES AGE VERSION gke-calico-cluster2-default-pool-bd997d68-pgqn Ready,SchedulingDisabled <none> 15m v1.22.10-gke.600 gke-calico-cluster2-np2-c4331149-2mmz Ready <none> 6m58s v1.22.10-gke.600
Jika penerapan kebijakan jaringan dinonaktifkan, GKE mungkin tidak langsung mengupdate node jika cluster Anda memiliki masa pemeliharaan atau pengecualian yang dikonfigurasi. Untuk mengetahui informasi selengkapnya, lihat Cluster lambat untuk diupdate.
Setelah semua node dibuat ulang, nonaktifkan add-on:
gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
Konsol
Untuk menonaktifkan penerapan kebijakan jaringan untuk cluster yang ada, lakukan tindakan berikut:
Buka halaman Google Kubernetes Engine di Konsol Google Cloud.
Di daftar cluster, klik nama cluster yang ingin diubah.
Di bagian Networking, di kolom Network policy, klik edit Edit network policy.
Hapus centang Aktifkan kebijakan jaringan untuk node, lalu klik Simpan Perubahan.
Tunggu hingga perubahan diterapkan, lalu klik edit Edit network policy lagi.
Hapus centang Enable network policy for master.
Klik Simpan Perubahan.
API
Untuk menonaktifkan penerapan kebijakan jaringan untuk cluster yang ada, lakukan hal berikut:
Perbarui cluster Anda untuk menggunakan
networkPolicy.enabled: false
menggunakansetNetworkPolicy
API.Pastikan semua node Anda dibuat ulang menggunakan gcloud CLI:
kubectl get nodes -l projectcalico.org/ds-ready=true
Jika operasi berhasil, output-nya akan mirip dengan yang berikut ini:
No resources found
Jika outputnya mirip dengan yang berikut ini, Anda harus menunggu GKE selesai mengupdate node pool:
NAME STATUS ROLES AGE VERSION gke-calico-cluster2-default-pool-bd997d68-pgqn Ready,SchedulingDisabled <none> 15m v1.22.10-gke.600 gke-calico-cluster2-np2-c4331149-2mmz Ready <none> 6m58s v1.22.10-gke.600
Jika penerapan kebijakan jaringan dinonaktifkan, GKE mungkin tidak langsung mengupdate node jika cluster Anda memiliki masa pemeliharaan atau pengecualian yang dikonfigurasi. Untuk mengetahui informasi selengkapnya, lihat Cluster lambat untuk diupdate.
Perbarui cluster Anda untuk menggunakan
update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true
menggunakanupdateCluster
API.
Membuat kebijakan jaringan
Anda dapat membuat kebijakan jaringan menggunakan Kubernetes Network Policy API.
Untuk detail lebih lanjut tentang membuat kebijakan jaringan, lihat topik berikut di dokumentasi Kubernetes:
Kebijakan jaringan dan Workload Identity Federation untuk GKE
Jika menggunakan kebijakan jaringan dengan Workload Identity Federation untuk GKE, Anda harus mengizinkan traffic keluar ke alamat IP berikut agar Pod Anda dapat berkomunikasi dengan server metadata GKE.
- Untuk cluster yang menjalankan GKE versi 1.21.0-gke.1000 dan yang lebih baru, izinkan traffic keluar ke
169.254.169.252/32
pada port988
. - Untuk cluster yang menjalankan versi GKE sebelum 1.21.0-gke.1000, izinkan traffic keluar ke
127.0.0.1/32
pada port988
. - Untuk cluster yang menjalankan GKE Dataplane V2, izinkan traffic keluar ke
169.254.169.254/32
pada port80
.
Jika tidak mengizinkan traffic keluar ke alamat IP dan port ini, Anda mungkin mengalami gangguan selama upgrade otomatis.
Bermigrasi dari Calico ke GKE Dataplane V2
Jika Anda memigrasikan kebijakan jaringan dari Calico ke GKE Dataplane V2, pertimbangkan batasan berikut:
Anda tidak dapat menggunakan alamat IP Pod atau Service di kolom
ipBlock.cidr
dari manifesNetworkPolicy
. Anda harus mereferensikan workload menggunakan label. Misalnya, konfigurasi berikut tidak valid:- ipBlock: cidr: 10.8.0.6/32
Anda tidak dapat menentukan kolom
ports.port
kosong dalam manifesNetworkPolicy
. Jika Anda menentukan protokol, Anda juga harus menentukan port. Misalnya, konfigurasi berikut tidak valid:ingress: - ports: - protocol: TCP
Menggunakan Load Balancer Aplikasi
Saat Ingress diterapkan ke Service untuk mem-build Load Balancer Aplikasi, Anda harus mengonfigurasi kebijakan jaringan yang diterapkan ke Pod di belakang Service tersebut agar dapat mengizinkan Rentang IP health check Load Balancer Aplikasi yang sesuai. Jika menggunakan Load Balancer Aplikasi internal, Anda juga harus mengonfigurasi kebijakan jaringan untuk mengizinkan subnet khusus proxy.
Jika Anda tidak menggunakan load balancing yang berbasis container dengan grup endpoint jaringan, port node untuk Service mungkin meneruskan koneksi ke Pod di node lain kecuali jika port tersebut dicegah dengan menetapkan externalTrafficPolicy
ke Local
di definisi Service. Jika
externalTrafficPolicy
tidak ditetapkan ke Local
, kebijakan jaringan juga harus
mengizinkan koneksi dari IP node lain dalam cluster.
Penyertaan rentang IP Pod dalam aturan ipBlock
Untuk mengontrol traffic untuk Pod tertentu, selalu pilih Pod berdasarkan namespace
atau label Pod menggunakan kolom namespaceSelector
dan podSelector
dalam
aturan masuk atau keluar NetworkPolicy Anda. Jangan gunakan kolom ipBlock.cidr
untuk
memilih rentang alamat IP Pod secara sengaja, yang bersifat sementara.
Project Kubernetes tidak menentukan perilaku kolom ipBlock.cidr
secara eksplisit saat menyertakan rentang alamat IP Pod. Menentukan rentang
CIDR yang luas di kolom ini, seperti 0.0.0.0/0
(yang mencakup rentang alamat IP
Pod) mungkin memiliki hasil yang tidak terduga dalam berbagai implementasi
NetworkPolicy.
Perilaku ipBlock di GKE Dataplane V2
Dengan penerapan NetworkPolicy GKE Dataplane V2, traffic Pod tidak pernah
tercakup dalam aturan ipBlock
. Oleh karena itu, meskipun Anda menentukan aturan yang luas seperti
cidr: '0.0.0.0/0'
, aturan tersebut tidak akan menyertakan traffic Pod. Hal ini berguna karena
memungkinkan Anda, misalnya, mengizinkan Pod di namespace menerima traffic dari
internet, tanpa mengizinkan traffic dari Pod. Untuk juga
menyertakan traffic Pod, pilih Pod secara eksplisit menggunakan pemilih Pod atau namespace
tambahan dalam definisi aturan masuk atau keluar dari NetworkPolicy.
Perilaku ipBlock di Calico
Untuk penerapan NetworkPolicy Calico, aturan ipBlock
memang
mencakup traffic Pod. Dengan implementasi ini, untuk mengonfigurasi rentang CIDR yang luas
tanpa mengizinkan traffic Pod, kecualikan secara eksplisit rentang CIDR Pod cluster,
seperti dalam contoh berikut:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-non-pod-traffic
spec:
ingress:
- from:
- ipBlock:
cidr: '0.0.0.0/0'
except: ['POD_IP_RANGE']
Dalam contoh ini, POD_IP_RANGE
adalah rentang alamat IPv4 Pod
cluster Anda, misalnya 10.95.0.0/17
. Jika Anda memiliki beberapa rentang IP,
rentang tersebut dapat disertakan satu per satu dalam array, misalnya
['10.95.0.0/17', '10.108.128.0/17']
.
Pemecahan masalah
Pod tidak dapat berkomunikasi dengan bidang kontrol di cluster yang menggunakan Private Service Connect
Pod di cluster GKE yang menggunakan Private Service Connect mungkin mengalami masalah komunikasi dengan bidang kontrol jika traffic keluar Pod ke alamat IP internal bidang kontrol dibatasi dalam kebijakan jaringan keluar.
Untuk mengurangi masalah ini:
Pastikan cluster Anda menggunakan Private Service Connect. Pada cluster yang menggunakan Private Service Connect, jika Anda menggunakan flag
master-ipv4-cidr
saat membuat subnet, GKE akan menetapkan alamat IP internal dari nilai yang Anda tentukan dimaster-ipv4-cidr
ke setiap bidang kontrol. Jika tidak, GKE akan menggunakan subnet node cluster untuk menetapkan alamat IP internal ke setiap bidang kontrol.Konfigurasikan kebijakan keluar cluster Anda untuk mengizinkan traffic ke alamat IP internal bidang kontrol.
Untuk menemukan alamat IP internal bidang kontrol:
gcloud
Untuk mencari
privateEndpoint
, jalankan perintah berikut:gcloud container clusters describe CLUSTER_NAME
Ganti
CLUSTER_NAME
dengan nama cluster.Perintah ini mengambil
privateEndpoint
cluster yang ditentukan.Konsol
Buka halaman Google Kubernetes Engine di konsol Google Cloud.
Dari panel navigasi, pada bagian Cluster, klik cluster yang alamat IP internalnya ingin Anda temukan.
Di bagian Dasar-dasar cluster, buka
Internal endpoint
, tempat alamat IP internal dicantumkan.
Setelah Anda dapat menemukan
privateEndpoint
atauInternal endpoint
, konfigurasikan kebijakan keluar cluster untuk mengizinkan traffic ke alamat IP internal panel kontrol. Untuk mengetahui informasi selengkapnya, lihat Membuat kebijakan jaringan.
Cluster lambat diupdate
Saat Anda mengaktifkan atau menonaktifkan penerapan kebijakan jaringan pada cluster yang ada, GKE mungkin tidak langsung mengupdate node jika cluster memiliki masa pemeliharaan yang telah dikonfigurasi.
Anda dapat mengupgrade node pool secara manual dengan menetapkan flag--cluster-version
ke versi GKE yang sama dengan yang dijalankan oleh panel kontrol. Anda harus menggunakan Google Cloud CLI untuk melakukan operasi ini. Untuk informasi selengkapnya,
lihat
catatan untuk masa pemeliharaan.
Pod yang di-deploy secara manual tidak terjadwal
Saat Anda mengaktifkan penerapan kebijakan jaringan di bidang kontrol cluster yang ada, GKE akan membatalkan jadwal Pod ip-masquerade-agent atau node calico yang Anda deploy secara manual.
GKE tidak menjadwalkan ulang Pod ini hingga penerapan kebijakan jaringan diaktifkan pada node cluster dan node-node dibuat ulang.
Jika Anda telah mengonfigurasi masa pemeliharaan atau pengecualian, hal ini dapat menyebabkan gangguan yang lebih lama.
Untuk meminimalkan durasi gangguan ini, Anda dapat menetapkan label berikut secara manual ke node cluster:
node.kubernetes.io/masq-agent-ds-ready=true
projectcalico.org/ds-ready=true
Kebijakan jaringan tidak diterapkan
Jika NetworkPolicy tidak diterapkan, Anda dapat memecahkan masalah menggunakan langkah-langkah berikut:
Pastikan penerapan kebijakan jaringan diaktifkan. Perintah yang Anda gunakan bergantung pada sudah diaktifkannya atau belum GKE Dataplane V2 pada cluster Anda.
Jika cluster Anda telah mengaktifkan GKE Dataplane V2, jalankan perintah berikut:
kubectl -n kube-system get pods -l k8s-app=cilium
Jika output kosong, penerapan kebijakan jaringan tidak akan diaktifkan.
Jika cluster Anda belum mengaktifkan GKE Dataplane V2, jalankan perintah berikut:
kubectl get nodes -l projectcalico.org/ds-ready=true
Jika output kosong, penerapan kebijakan jaringan tidak akan diaktifkan.
Periksa label Pod:
kubectl describe pod POD_NAME
Ganti
POD_NAME
dengan nama Pod.Outputnya mirip dengan yang berikut ini:
Labels: app=store pod-template-hash=64d9d4f554 version=v1
Pastikan label pada kebijakan cocok dengan label di Pod:
kubectl describe networkpolicy
Outputnya mirip dengan yang berikut ini:
PodSelector: app=store
Dalam output ini, label
app=store
cocok dengan labelapp=store
dari langkah sebelumnya.Periksa apakah ada kebijakan jaringan yang memilih workload Anda:
kubectl get networkpolicy
Jika outputnya kosong, berarti tidak ada NetworkPolicy yang dibuat dalam namespace dan tidak ada yang memilih workload Anda. Jika output tidak kosong, periksa apakah kebijakan memilih workload Anda:
kubectl describe networkpolicy
Outputnya mirip dengan yang berikut ini:
... PodSelector: app=nginx Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: PodSelector: app=store Not affecting egress traffic Policy Types: Ingress
Masalah umum
Penghentian pod StatefulSet dengan Calico
Cluster GKE dengan
kebijakan jaringan
Calico yang diaktifkan mungkin mengalami masalah ketika pod StatefulSet memutus koneksi
yang ada saat pod dihapus. Setelah pod memasuki status Terminating
,
konfigurasi terminationGracePeriodSeconds
dalam spesifikasi pod tidak diterapkan
dan menyebabkan gangguan bagi aplikasi lain yang memiliki koneksi
dengan pod StatefulSet. Untuk informasi selengkapnya tentang masalah ini, lihat
Masalah Calico #4710.
Masalah ini memengaruhi versi GKE berikut:
- 1.18
- 1.19 hingga 1.19.16-gke.99
- 1.20 hingga 1.20.11-gke.1299
- 1.21 hingga 1.21.4-gke.1499
Untuk mengurangi masalah ini, upgrade bidang kontrol GKE Anda ke salah satu versi berikut:
- 1.19.16-gke.100 atau yang lebih baru
- 1.20.11-gke.1300 atau yang lebih baru
- 1.21.4-gke.1500 atau yang lebih baru
Pod macet dalam status containerCreating
Kemungkinan ada skenario ketika cluster GKE dengan kebijakan jaringan Calico
diaktifkan dapat mengalami masalah saat Pod macet dalam status containerCreating
.
Pada tab Peristiwa Pod, Anda akan melihat pesan yang mirip dengan berikut:
plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local
Untuk mengurangi masalah ini, gunakan ipam host-local untuk Calico, bukan calico-ipam di cluster GKE.