Halaman ini menunjukkan cara menyelesaikan masalah terkait isolasi jaringan Google Kubernetes Engine (GKE).
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.
Cluster GKE tidak berjalan
Menghapus aturan firewall yang mengizinkan traffic masuk dari bidang kontrol cluster ke node di port 10250, atau menghapus rute default ke gateway internet default, akan menyebabkan cluster berhenti berfungsi. Jika menghapus rute default, Anda harus memastikan traffic ke layanan Google Cloud yang diperlukan dirutekan. Untuk informasi lebih lanjut, lihat pemilihan rute kustom.
Waktu tunggu habis saat membuat cluster
- Gejala
- Cluster yang dibuat dalam versi 1.28 atau yang lebih lama dengan node pribadi memerlukan rute peering antar-VPC. Namun, hanya satu operasi peering yang dapat terjadi dalam satu waktu. Jika Anda mencoba membuat beberapa cluster dengan karakteristik sebelumnya secara bersamaan, waktu pembuatan cluster dapat habis.
- Resolusi
Gunakan salah satu solusi berikut:
Buat cluster dalam versi 1.28 atau yang lebih lama secara serial sehingga rute peering VPC sudah ada untuk setiap cluster berikutnya tanpa endpoint eksternal. Waktu percobaan untuk membuat satu cluster juga dapat habis waktu jika ada operasi yang berjalan di VPC Anda.
Buat cluster dalam versi 1.29 atau yang lebih baru.
Koneksi Peering Jaringan VPC tidak sengaja dihapus
- Gejala
Jika Anda tidak sengaja menghapus koneksi VPC Network Peering, cluster akan berada dalam status perbaikan dan semua node akan menampilkan status
UNKNOWN
. Anda tidak akan dapat melakukan operasi apa pun pada cluster karena jangkauan ke bidang kontrol terputus. Saat Anda memeriksa platform kontrol, log akan menampilkan error yang mirip dengan berikut:error checking if node NODE_NAME is shutdown: unimplemented
- Kemungkinan penyebab
Anda tidak sengaja menghapus koneksi Peering Jaringan VPC.
- Resolusi
Ikuti langkah-langkah berikut:
Buat cluster Peering Jaringan VPC sementara yang baru. Pembuatan cluster menyebabkan pembuatan ulang Peering Jaringan VPC dan cluster lama dipulihkan ke operasi normalnya.
Hapus cluster Peering Jaringan VPC yang dibuat sementara setelah cluster lama dipulihkan ke operasi normalnya.
Endpoint Private Service Connect dan aturan penerusan tidak sengaja dihapus
- Gejala
Jika Anda tidak sengaja menghapus endpoint atau aturan penerusan Private Service Connect, cluster akan beralih ke status perbaikan dan semua node akan menampilkan status
UNKNOWN
. Anda tidak akan dapat melakukan operasi apa pun pada cluster karena akses ke bidang kontrol terputus. Saat Anda memeriksa bidang kontrol, log akan menampilkan error yang mirip dengan berikut:error checking if node NODE_NAME is shutdown: unimplemented
- Kemungkinan penyebab
Anda tidak sengaja menghapus endpoint Private Service Connect atau aturan penerusan. Kedua resource diberi nama
gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe
dan mengizinkan bidang kontrol dan node untuk terhubung secara pribadi.- Resolusi
Cluster tumpang-tindih dengan peer aktif
- Gejala
Mencoba membuat cluster tanpa endpoint eksternal akan menampilkan error seperti berikut:
Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network.
- Kemungkinan penyebab
Anda memilih CIDR bidang kontrol yang tumpang-tindih.
- Resolusi
Gunakan salah satu solusi berikut:
- Hapus dan buat ulang cluster menggunakan CIDR bidang kontrol yang berbeda.
- Buat ulang cluster dalam versi 1.29 dan sertakan flag
--enable-private-nodes
.
Tidak dapat menjangkau bidang kontrol cluster tanpa endpoint eksternal
Tingkatkan kemungkinan keterjangkauan bidang kontrol cluster Anda dengan mengimplementasikan salah satu konfigurasi akses endpoint cluster. Untuk informasi selengkapnya, lihat akses ke endpoint cluster.
- Gejala
Setelah membuat cluster tanpa endpoint eksternal, mencoba menjalankan perintah
kubectl
terhadap cluster akan menampilkan error seperti salah satu dari berikut ini:Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out.
Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
- Kemungkinan penyebab
kubectl
tidak dapat berkomunikasi dengan bidang kontrol cluster.- Resolusi
Gunakan salah satu solusi berikut:
Aktifkan akses DNS untuk cara yang disederhanakan guna mengakses cluster Anda dengan aman. Untuk mengetahui informasi selengkapnya, lihat Endpoint berbasis DNS.
Pastikan kredensial untuk cluster yang telah dibuat untuk kubeconfig atau konteks yang benar telah diaktifkan. Untuk informasi selengkapnya tentang cara menyetel kredensial cluster, lihat membuat entri kubeconfig.
Pastikan bahwa akses bidang kontrol menggunakan alamat IP eksternal diizinkan. Menonaktifkan akses eksternal ke bidang kontrol cluster akan mengisolasi cluster dari internet. Dengan konfigurasi ini, hanya rentang CIDR jaringan internal yang diizinkan atau jaringan yang dicadangkan yang memiliki akses ke bidang kontrol.
Pastikan bahwa alamat IP origin diizinkan untuk menjangkau bidang kontrol:
gcloud container clusters describe CLUSTER_NAME \ --format="value(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetworksConfig)"\ --location=COMPUTE_LOCATION
Ganti kode berikut:
CLUSTER_NAME
: nama cluster Anda.COMPUTE_LOCATION
: Lokasi Compute Engine untuk cluster.
Jika alamat IP origin tidak diizinkan, outputnya dapat menampilkan hasil kosong (hanya tanda kurung kurawal) atau rentang CIDR yang tidak mencakup alamat IP origin
cidrBlocks: cidrBlock: 10.XXX.X.XX/32 displayName: jumphost cidrBlock: 35.XXX.XXX.XX/32 displayName: cloud shell enabled: true
Tambahkan jaringan yang diizinkan untuk mengakses bidang kontrol.
Jika Anda menjalankan perintah
kubectl
dari lingkungan lokal atau region yang berbeda dengan lokasi cluster, pastikan akses global endpoint pribadi bidang kontrol diaktifkan. Untuk mengetahui informasi selengkapnya, lihat Akses menggunakan alamat IP internal bidang kontrol dari region mana pun.Jelaskan cluster untuk melihat respons konfigurasi kontrol akses:
gcloud container clusters describe CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --flatten "controlPlaneEndpointsConfig.ipEndpointsConfig.globalAccess"
Ganti kode berikut:
CLUSTER_NAME
: nama cluster Anda.COMPUTE_LOCATION
: Lokasi Compute Engine untuk cluster.
Output yang berhasil akan tampak seperti berikut ini:
enabled: true
Jika
null
ditampilkan, aktifkan akses menggunakan alamat IP internal bidang kontrol dari wilayah mana pun.
Tidak dapat membuat cluster karena blok CIDR IPv4 tumpang-tindih
- Gejala
gcloud container clusters create
menampilkan error yang tampak seperti berikut:The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20.
- Kemungkinan penyebab
Anda menentukan blok CIDR bidang kontrol yang tumpang-tindih dengan subnet yang ada di VPC.
- Resolusi
Tentukan blok CIDR untuk
--master-ipv4-cidr
yang tidak tumpang-tindih dengan subnet yang ada.
Tidak dapat membuat cluster karena rentang layanan sudah digunakan oleh cluster lain
- Gejala
Percobaan pembuatan cluster menampilkan error seperti berikut:
Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork [SUBNET_NAME] is already used by another cluster.
- Kemungkinan penyebab
Konfigurasi berikut dapat menyebabkan error ini:
- Anda memilih rentang layanan yang masih digunakan oleh cluster lain, atau cluster tidak dihapus.
- Ada cluster yang menggunakan rentang layanan tersebut yang telah dihapus, tetapi metadata rentang sekunder tidak dibersihkan dengan benar. Rentang sekunder untuk cluster GKE disimpan dalam metadata Compute Engine dan harus dihapus setelah cluster dihapus. Meskipun cluster berhasil dihapus, metadata mungkin tidak akan dihapus.
- Resolusi
Ikuti langkah-langkah berikut:
- Periksa apakah rentang layanan digunakan oleh cluster yang ada. Anda dapat menggunakan perintah
gcloud container clusters list
dengan flagfilter
untuk menelusuri cluster. Jika sudah ada cluster yang menggunakan rentang layanan, Anda harus menghapus cluster tersebut atau membuat rentang layanan baru. - Jika rentang layanan tidak digunakan oleh cluster yang ada, hapus secara manual entri metadata yang cocok dengan rentang layanan yang ingin Anda gunakan.
- Periksa apakah rentang layanan digunakan oleh cluster yang ada. Anda dapat menggunakan perintah
Tidak dapat membuat subnet
- Gejala
Saat mencoba membuat cluster dengan subnet otomatis atau membuat subnet kustom, Anda mungkin mengalami salah satu error berikut:
An IP range in the peer network overlaps with an IP range in one of the active peers of the local network.
Error: Error waiting for creating GKE cluster: Invalid value for field PrivateClusterConfig.MasterIpv4CidrBlock: x.x.x.x/28 conflicts with an existing subnet in one of the peered VPCs.
- Kemungkinan penyebab
Rentang CIDR bidang kontrol yang Anda tentukan tumpang-tindih dengan rentang IP lain dalam cluster. Error pembuatan subnet ini juga dapat terjadi jika Anda mencoba menggunakan kembali CIDR
master-ipv4-cidr
yang digunakan di cluster yang baru saja dihapus.- Resolusi
Coba gunakan rentang CIDR lain.
Tidak dapat mengambil image dari Docker Hub publik
- Gejala
Pod yang berjalan di cluster Anda menampilkan peringatan dalam
kubectl describe
:Failed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
- Kemungkinan penyebab
Node dengan alamat IP pribadi hanya memerlukan konfigurasi tambahan untuk memenuhi persyaratan akses internet. Namun, node dapat mengakses Google Cloud API dan layanan Google, termasuk Artifact Registry, jika Anda telah mengaktifkan Akses Google Pribadi dan memenuhi persyaratan jaringannya.
- Resolusi
Gunakan salah satu solusi berikut:
Salin image di cluster Anda dari Docker Hub ke Artifact Registry. Lihat Memigrasikan container dari registry pihak ketiga untuk informasi selengkapnya.
GKE secara otomatis memeriksa
mirror.gcr.io
untuk menemukan salinan yang di-cache dari image Docker Hub yang sering diakses.Jika Anda harus mengambil image dari Docker Hub atau repositori publik lainnya, gunakan Cloud NAT atau proxy berbasis instance yang merupakan target untuk rute
0.0.0.0/0
statis.
Waktu permintaan API yang memicu webhook penerimaan habis
- Gejala
Waktu permintaan API yang memicu webhook penerimaan yang dikonfigurasi untuk menggunakan layanan dengan
targetPort
selain 443 habis, menyebabkan permintaan gagal:Error from server (Timeout): request did not complete within requested timeout 30s
- Kemungkinan penyebab
Secara default, firewall tidak mengizinkan koneksi TCP ke node, kecuali pada port 443 (HTTPS) dan 10250 (kubelet). Webhook penerimaan yang mencoba berkomunikasi dengan Pod pada port selain 443 akan gagal jika tidak ada aturan firewall khusus yang mengizinkan traffic.
- Resolusi
Tambahkan aturan firewall untuk kasus penggunaan tertentu.
Tidak dapat membuat cluster karena health check gagal
- Gejala
Setelah dibuat, cluster Standard dengan node pool pribadi akan terhenti di langkah health check dan melaporkan error yang mirip dengan salah satu dari berikut ini:
All cluster resources were brought up, but only 0 of 2 have registered.
All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
- Kemungkinan penyebab
Konfigurasi berikut dapat menyebabkan error ini:
- Node cluster tidak dapat mendownload biner yang diperlukan dari Cloud Storage API
(
storage.googleapis.com
). - Aturan firewall yang membatasi traffic keluar.
- Izin IAM VPC Bersama salah.
- Akses Google Pribadi mengharuskan Anda mengonfigurasi DNS untuk
*.gcr.io
.
- Node cluster tidak dapat mendownload biner yang diperlukan dari Cloud Storage API
(
- Resolusi
Gunakan salah satu solusi berikut:
Aktifkan Akses Google Pribadi di subnet untuk akses jaringan node ke
storage.googleapis.com
, atau aktifkan Cloud NAT untuk mengizinkan node berkomunikasi dengan endpointstorage.googleapis.com
.Untuk akses baca node ke
storage.googleapis.com
, pastikan akun layanan yang ditetapkan ke node cluster memiliki akses baca penyimpanan.Pastikan Anda memiliki aturan firewall Google Cloud untuk mengizinkan semua traffic keluar atau mengonfigurasi aturan firewall guna mengizinkan traffic keluar untuk node ke bidang kontrol cluster dan
*.googleapis.com
.Buat konfigurasi DNS untuk
*.gcr.io
.Jika Anda memiliki penyiapan rute atau firewall non-default, konfigurasikan Akses Google Pribadi.
Jika Anda menggunakan Kontrol Layanan VPC, siapkan Container Registry atau Artifact Registry untuk cluster GKE.
Pastikan Anda belum menghapus atau mengubah aturan firewall yang dibuat otomatis untuk Ingress.
Jika menggunakan VPC Bersama, pastikan Anda telah mengonfigurasi izin IAM yang diperlukan.
kubelet Gagal membuat sandbox pod
- Gejala
Setelah membuat cluster dengan node pribadi, cluster akan melaporkan error seperti salah satu dari berikut ini:
Warning FailedCreatePodSandBox 12s (x9 over 4m) kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
- Kemungkinan penyebab
Pod
calico-node
ataunetd
tidak dapat menjangkau*.gcr.io
.- Resolusi
Pastikan Anda telah menyelesaikan penyiapan untuk Container Registry atau Artifact Registry yang diperlukan.
Node pribadi dibuat tetapi tidak bergabung dengan cluster
Untuk cluster yang hanya menggunakan node dengan alamat IP pribadi, sering kali saat menggunakan perutean
kustom dan peralatan jaringan pihak ketiga di
VPC, rute default
(0.0.0.0/0
) dialihkan ke perangkat, bukan gateway internet
default. Selain konektivitas bidang kontrol, Anda perlu memastikan bahwa
tujuan berikut dapat dijangkau:
- *.googleapis.com
- *.gcr.io
- gcr.io
Konfigurasikan Akses Google Pribadi untuk ketiga domain. Praktik terbaik ini memungkinkan node baru memulai dan bergabung dengan cluster sekaligus tetap membatasi traffic yang terikat ke internet.
Workload di cluster GKE tidak dapat mengakses internet
Pod yang berjalan di node dengan alamat IP pribadi tidak dapat mengakses internet. Misalnya, setelah menjalankan perintah apt update
dari Pod exec shell
, perintah tersebut
akan melaporkan error yang mirip dengan berikut:
0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]
Jika rentang alamat IP sekunder subnet yang digunakan untuk Pod dalam cluster tidak dikonfigurasi di gateway Cloud NAT, Pod tidak dapat terhubung ke internet karena tidak ada alamat IP eksternal yang dikonfigurasi untuk gateway Cloud NAT.
Pastikan Anda mengonfigurasi gateway Cloud NAT untuk menerapkan setidaknya rentang alamat IP subnet berikut untuk subnet yang digunakan cluster Anda:
- Rentang alamat IP primer subnet (digunakan oleh node)
- Rentang alamat IP sekunder subnet yang digunakan untuk Pod di cluster
- Rentang alamat IP sekunder subnet yang digunakan untuk Service di cluster
Untuk mempelajari lebih lanjut, lihat cara menambahkan rentang IP subnet sekunder yang digunakan untuk Pod.
Akses IP langsung tidak dapat dinonaktifkan untuk cluster publik
- Gejala
Setelah menonaktifkan endpoint alamat IP, Anda akan melihat pesan error yang mirip dengan berikut ini:
Direct IP access can't be disabled for public clusters
- Kemungkinan penyebab
Cluster Anda menggunakan jaringan lama.
- Resolusi
Migrasikan cluster Anda ke Private Service Connect. Untuk informasi selengkapnya tentang status migrasi, hubungi dukungan .
Akses IP langsung tidak dapat dinonaktifkan untuk cluster di tengah migrasi PSC
- Gejala
Setelah menonaktifkan endpoint alamat IP, Anda akan melihat pesan error yang mirip dengan berikut ini:
Direct IP access can't be disabled for public clusters
- Kemungkinan penyebab
Cluster Anda menggunakan jaringan lama.
- Resolusi
Gunakan salah satu solusi berikut:
- Buat ulang semua kumpulan node secara manual dalam versi yang berbeda.
- Tunggu hingga GKE otomatis mengupgrade kumpulan node selama peristiwa pemeliharaan.
Endpoint internal bidang kontrol tidak dapat diaktifkan
- Gejala
Saat mencoba mengaktifkan endpoint internal panel kontrol cluster, Anda akan melihat pesan error yang mirip dengan berikut ini:
private_endpoint_enforcement_enabled can't be enabled when envoy is disabled
private_endpoint_enforcement_enabled is unsupported. Please upgrade to the minimum support version
- Kemungkinan penyebab
Cluster Anda perlu melakukan rotasi alamat IP atau update versi.
- Resolusi
Gunakan salah satu solusi berikut:
- Merotasi alamat IP bidang kontrol untuk mengaktifkan Envoy.
- Upgrade cluster Anda ke versi 1.28.10-gke.1058000 atau yang lebih baru.
Pembuatan cluster gagal saat kebijakan organisasi ditentukan
- Gejala
Saat mencoba membuat cluster, Anda akan melihat pesan error yang mirip dengan berikut:
compute.disablePrivateServiceConnectCreationForConsumers violated for projects
- Kemungkinan penyebab
Endpoint atau backend cluster diblokir oleh kebijakan organisasi konsumen.
- Resolusi
Izinkan instance membuat endpoint dengan batasan
compute.restrictPrivateServiceConnectProducer
dengan menyelesaikan langkah-langkah di Kebijakan organisasi sisi konsumen.
Endpoint Private Service Connect mungkin bocor selama penghapusan cluster
- Gejala
Setelah membuat cluster, Anda mungkin melihat salah satu gejala berikut:
Anda tidak dapat melihat endpoint yang terhubung di bagian Private Service Connect di cluster berbasis Private Service Connect.
Anda tidak dapat menghapus subnet atau jaringan VPC yang dialokasikan untuk endpoint internal dalam cluster yang menggunakan Private Service Connect. Pesan error yang mirip dengan yang berikut ini akan muncul:
projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
- Kemungkinan penyebab
Di cluster GKE yang menggunakan Private Service Connect, GKE men-deploy endpoint Private Service Connect menggunakan aturan penerusan yang mengalokasikan alamat IP internal untuk mengakses bidang kontrol cluster di jaringan bidang kontrol. Untuk melindungi komunikasi antara bidang kontrol dan node menggunakan Private Service Connect, GKE membuat endpoint tetap tidak terlihat, dan Anda tidak dapat melihatnya di konsol Google Cloud atau gcloud CLI.
- Resolusi
Untuk mencegah kebocoran endpoint Private Service Connect sebelum penghapusan cluster, selesaikan langkah-langkah berikut:
- Tetapkan
Kubernetes Engine Service Agent role
ke akun layanan GKE. - Pastikan izin
compute.forwardingRules.*
dancompute.addresses.*
tidak ditolak secara eksplisit dari akun layanan GKE.
Jika Anda melihat kebocoran endpoint Private Service Connect, hubungi dukungan
- Tetapkan
Tidak dapat mengurai jaringan yang diizinkan cluster
- Gejala
Anda tidak dapat membuat cluster dalam versi 1.29 atau yang lebih baru. Pesan error yang mirip dengan yang berikut ini akan muncul:
Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
- Kemungkinan penyebab
Project Google Cloud Anda menggunakan webhook berbasis IP pribadi. Oleh karena itu, Anda tidak dapat membuat cluster dengan Private Service Connect. Sebagai gantinya, cluster Anda menggunakan Peering Jaringan VPC yang mengurai flag
master-ipv4-cidr
.- Resolusi
Gunakan salah satu solusi berikut:
Lanjutkan untuk membuat cluster Peering Jaringan VPC dan sertakan
master-ipv4-cidr
untuk menentukan CIDR yang valid. Solusi ini memiliki batasan berikut:- Flag
master-ipv4-cidr
tidak digunakan lagi di konsol Google Cloud. Untuk memperbarui tanda ini, Anda hanya dapat menggunakan Google Cloud CLI atau Terraform. - Peering Jaringan VPC tidak digunakan lagi di GKE versi 1.29 atau yang lebih baru.
- Flag
Migrasikan webhook berbasis IP pribadi Anda dengan menyelesaikan langkah-langkah di Batasan Private Service Connect. Kemudian, hubungi dukungan untuk memilih menggunakan cluster dengan Private Service Connect.
Tidak dapat menentukan rentang alamat IP internal di cluster dengan node publik
- Gejala
Anda tidak dapat menentukan rentang alamat IP internal menggunakan flag
--master-ipv4-cidr
. Pesan error yang mirip dengan yang berikut ini akan muncul:ERROR: (gcloud.container.clusters.create) Cannot specify --master-ipv4-cidr without --enable-private-nodes
- Kemungkinan penyebab
Anda menentukan rentang alamat IP internal untuk bidang kontrol dengan tanda
master-ipv4-cidr
dalam cluster tanpa mengaktifkan tandaenable-private-nodes
. Untuk membuat cluster denganmaster-ipv4-cidr
yang ditentukan, Anda harus mengonfigurasi cluster untuk menyediakan node dengan alamat IP internal (node pribadi) menggunakan flagenable-private-nodes
.- Resolusi
Gunakan salah satu solusi berikut:
Buat cluster dengan perintah berikut:
gcloud container clusters create-auto CLUSTER_NAME \ --enable-private-nodes \ --master-ipv4-cidr CP_IP_RANGE
Ganti kode berikut:
CLUSTER_NAME
: nama cluster Anda.CLUSTER_NAME
: rentang alamat IP internal untuk bidang kontrol.
Update cluster Anda untuk menyediakan node hanya dengan alamat IP. Untuk mempelajari lebih lanjut, lihat Mengonfigurasi cluster.
Tidak dapat menjadwalkan beban kerja publik di cluster Autopilot
- Gejala
- Di cluster Autopilot, jika cluster Anda hanya menggunakan node pribadi, Anda
tidak dapat menjadwalkan workload di Pod publik menggunakan
nodeSelector
cloud.google.com/private-node=false
. - Kemungkinan penyebab
- Konfigurasi tanda
private-node
yang ditetapkan sebagaifalse
di nodeSelector Pod hanya tersedia di cluster dalam versi 1.30.3 atau yang lebih baru. - Resolusi
- Upgrade cluster Anda ke versi 1.30 atau yang lebih baru.
Akses ke endpoint berbasis DNS dinonaktifkan
- Gejala
Mencoba menjalankan perintah kubectl terhadap cluster akan menampilkan error yang mirip dengan berikut ini:
couldn't get current server API group list: control_plane_endpoints_config.dns_endpoint_config.allow_external_traffic is disabled
- Kemungkinan penyebab
Akses berbasis DNS telah dinonaktifkan di cluster Anda.
- Resolusi
Aktifkan akses ke bidang kontrol menggunakan endpoint berbasis DNS dari bidang kontrol. Untuk mempelajari lebih lanjut, lihat Mengubah akses panel kontrol.
Node gagal mengalokasikan alamat IP selama penskalaan
- Gejala
Mencoba memperluas rentang alamat IP utama subnet ke daftar jaringan yang diizinkan akan menampilkan error yang mirip dengan berikut ini:
authorized networks fields cannot be mutated if direct IP access is disabled
- Kemungkinan penyebab
Anda telah menonaktifkan endpoint berbasis IP cluster.
- Resolusi
Nonaktifkan dan aktifkan endpoint berbasis IP cluster menggunakan flag
enable-ip-access
.
Terlalu banyak blok CIDR
gcloud
menampilkan error berikut saat mencoba membuat atau mengupdate cluster dengan lebih dari 50 blok CIDR:
ERROR: (gcloud.container.clusters.update) argument --master-authorized-networks: too many args
Untuk mengatasi masalah ini, coba langkah-langkah berikut:
- Jika cluster Anda tidak menggunakan Private Service Connect atau VPC Network Peering, pastikan Anda menentukan tidak lebih dari 50 blok CIDR.
- Jika cluster Anda menggunakan Private Service Connect atau Peering Jaringan VPC, tentukan tidak lebih dari 100 blok CIDR.
Tidak dapat menyambung ke server.
Waktu tunggu perintah kubectl
habis karena blok CIDR yang tidak dikonfigurasi dengan benar:
Unable to connect to the server: dial tcp MASTER_IP: getsockopt: connection timed out
Saat Anda membuat atau mengupdate cluster, pastikan Anda menentukan blok CIDR yang benar.