Mengontrol komunikasi antara Pod dan Service menggunakan kebijakan jaringan


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: Persyaratan dan batasan berikut hanya berlaku untuk cluster Standard:

  • 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 atau g1-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

  1. Di konsol Google Cloud, aktifkan Cloud Shell.

    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.

  2. 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:

    1. Jalankan perintah berikut untuk mengaktifkan add-on:

      gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
      

      Ganti CLUSTER_NAME dengan nama cluster.

    2. 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:

  1. Buka halaman Google Kubernetes Engine di Konsol Google Cloud.

    Buka Google Kubernetes Engine

  2. Klik Create.

  3. Pada dialog Create cluster, untuk GKE Standard, klik Configure.

  4. Konfigurasi cluster Anda sesuai pilihan.

  5. Dari panel navigasi, di bagian Cluster, klik Networking.

  6. Centang kotak Aktifkan kebijakan jaringan.

  7. Klik Create.

Untuk mengaktifkan penerapan kebijakan jaringan untuk cluster yang ada:

  1. Buka halaman Google Kubernetes Engine di Konsol Google Cloud.

    Buka Google Kubernetes Engine

  2. Di daftar cluster, klik nama cluster yang ingin diubah.

  3. Di bagian Networking, di kolom Network policy, klik Edit network policy.

  4. Centang kotak Enable network policy for master, lalu klik Save Changes.

  5. Tunggu hingga perubahan diterapkan, lalu klik Edit network policy lagi.

  6. Centang kotak Aktifkan kebijakan jaringan untuk node.

  7. Klik Simpan Perubahan.

API

Untuk mengaktifkan penerapan kebijakan jaringan, lakukan hal berikut:

  1. Tentukan objek networkPolicy di dalam objek cluster yang Anda berikan ke projects.zones.clusters.create atau project.zone.clusters.update.

  2. 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, perintah create dan update 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

  1. Di konsol Google Cloud, aktifkan Cloud Shell.

    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.

  2. Untuk menonaktifkan penerapan kebijakan jaringan, lakukan tugas berikut:

    1. 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.

  3. 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.

  4. 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:

  1. Buka halaman Google Kubernetes Engine di Konsol Google Cloud.

    Buka Google Kubernetes Engine

  2. Di daftar cluster, klik nama cluster yang ingin diubah.

  3. Di bagian Networking, di kolom Network policy, klik Edit network policy.

  4. Hapus centang Aktifkan kebijakan jaringan untuk node, lalu klik Simpan Perubahan.

  5. Tunggu hingga perubahan diterapkan, lalu klik Edit network policy lagi.

  6. Hapus centang Enable network policy for master.

  7. Klik Simpan Perubahan.

API

Untuk menonaktifkan penerapan kebijakan jaringan untuk cluster yang ada, lakukan hal berikut:

  1. Perbarui cluster Anda untuk menggunakan networkPolicy.enabled: false menggunakan setNetworkPolicy API.

  2. 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.

  3. Perbarui cluster Anda untuk menggunakan update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true menggunakan updateCluster 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 port 988.
  • Untuk cluster yang menjalankan versi GKE sebelum 1.21.0-gke.1000, izinkan traffic keluar ke 127.0.0.1/32 pada port 988.
  • Untuk cluster yang menjalankan GKE Dataplane V2, izinkan traffic keluar ke 169.254.169.254/32 pada port 80.

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 manifes NetworkPolicy. 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 manifes NetworkPolicy. 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.

Bagian berikut menjelaskan cara berbagai implementasi NetworkPolicy di GKE mengevaluasi rentang alamat IP yang Anda tentukan di kolom ipBlock.cidr, dan pengaruhnya terhadap rentang alamat IP Pod yang secara inheren disertakan dalam rentang CIDR yang luas. Memahami perbedaan perilaku antara implementasi akan membantu Anda mempersiapkan hasil saat memigrasikan ke implementasi lain.

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:

  1. 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 di master-ipv4-cidr ke setiap bidang kontrol. Jika tidak, GKE akan menggunakan subnet node cluster untuk menetapkan alamat IP internal ke setiap bidang kontrol.

  2. 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

    1. Buka halaman Google Kubernetes Engine di konsol Google Cloud.

      Buka Google Kubernetes Engine

    2. Dari panel navigasi, pada bagian Cluster, klik cluster yang alamat IP internalnya ingin Anda temukan.

    3. Di bagian Dasar-dasar cluster, buka Internal endpoint, tempat alamat IP internal dicantumkan.

    Setelah Anda dapat menemukan privateEndpoint atau Internal 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:

  1. 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.

  2. 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
    
  3. 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 label app=store dari langkah sebelumnya.

  4. 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.

Langkah berikutnya