Memecahkan masalah isolasi jaringan di GKE

Halaman ini menunjukkan cara menyelesaikan masalah terkait isolasi jaringan Google Kubernetes Engine (GKE).

Cluster GKE tidak berjalan

Menghapus aturan firewall yang mengizinkan traffic masuk dari bidang kontrol cluster ke node pada port 10250, atau menghapus rute default ke gateway internet default, menyebabkan cluster berhenti berfungsi. Jika Anda menghapus rute default, Anda harus memastikan traffic ke layanan Trusted Cloud yang diperlukan dirutekan. Untuk mengetahui informasi selengkapnya, lihat pemilihan rute kustom.

Waktu tunggu habis saat membuat cluster

Gejala
Cluster yang dibuat di 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 di atas secara bersamaan, waktu pembuatan cluster dapat habis.
Resolusi

Gunakan salah satu solusi berikut:

  • Buat cluster di 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 di 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 memasuki status perbaikan dan semua node akan menampilkan status UNKNOWN. Anda tidak akan dapat melakukan operasi apa pun pada cluster karena konektivitas ke bidang kontrol terputus. Saat Anda memeriksa bidang kontrol, log akan menampilkan error yang serupa dengan berikut ini:

error checking if node NODE_NAME is shutdown: unimplemented
Kemungkinan penyebab

Anda secara tidak sengaja menghapus koneksi Peering Jaringan VPC.

Resolusi

  1. Buat cluster GKE baru dengan versi yang mendahului peralihan PSC dan konfigurasi spesifiknya. Tindakan ini diperlukan untuk memaksa pembuatan ulang koneksi peering VPC, yang akan memulihkan cluster lama ke operasi normalnya.
    • Gunakan konfigurasi spesifik berikut untuk cluster baru:
      • Saluran rilis: diperluas
      • Versi cluster: versi yang lebih lama dari 1.29, seperti 1.28.15-gke.2403000
      • CIDR IPv4 Master: rentang alamat IP tertentu, seperti --master-ipv4-cidr=172.16.0.192/28
  2. Pantau status cluster asli.
    • Setelah cluster baru dibuat (dan dengan demikian peering VPC dibuat ulang), cluster asli akan pulih dari status perbaikannya, dan nodenya akan kembali ke status Ready.
  3. Hapus cluster GKE yang dibuat sementara.
    • Setelah cluster asli dipulihkan sepenuhnya dan beroperasi secara normal, Anda dapat menghapus cluster GKE yang dibuat sementara.

Endpoint Private Service Connect dan aturan penerusan tidak sengaja dihapus

Gejala

Jika Anda tidak sengaja menghapus endpoint Private Service Connect atau aturan penerusan, cluster akan memasuki 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 serupa dengan berikut ini:

error checking if node NODE_NAME is shutdown: unimplemented
Kemungkinan penyebab

Anda secara 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

Merotasi alamat IP bidang kontrol.

Cluster tumpang-tindih dengan peer aktif

Gejala

Mencoba membuat cluster tanpa endpoint eksternal akan menampilkan error yang mirip dengan berikut ini:

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 di 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 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 lebih sederhana dalam mengakses cluster Anda secara 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.

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

      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

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

    1. Jelaskan cluster untuk melihat respons konfigurasi akses kontrol:

      gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "controlPlaneEndpointsConfig.ipEndpointsConfig.globalAccess"

      Ganti kode berikut:

      Output yang berhasil akan tampak seperti berikut ini:

        enabled: true

    2. Jika null ditampilkan, aktifkan akses menggunakan alamat IP internal bidang kontrol dari region mana saja.

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

Mencoba membuat cluster menampilkan error yang mirip dengan 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:

  1. Periksa apakah rentang layanan digunakan oleh cluster yang ada. Anda dapat menggunakan perintah gcloud container clusters list dengan flag filter untuk menelusuri cluster. Jika sudah ada cluster yang menggunakan rentang layanan, Anda harus menghapus cluster tersebut atau membuat rentang layanan baru.
  2. Jika rentang layanan tidak digunakan oleh cluster yang ada, hapus secara manual entri metadata yang cocok dengan rentang layanan yang ingin Anda gunakan.

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 dalam 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 API dan layanan Trusted Cloud , 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, sehingga 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 serupa 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.
Resolusi

Gunakan salah satu solusi berikut:

kubelet Gagal membuat sandbox pod

Gejala

Setelah membuat cluster dengan node pribadi, cluster akan melaporkan error yang mirip dengan 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 atau netd 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 menggunakan node dengan alamat IP pribadi saja, sering kali saat menggunakan perutean kustom dan peralatan jaringan pihak ketiga di VPC, rute default (0.0.0.0/0) dialihkan ke peralatan, 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, muncul laporan error seperti 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 mengetahui informasi selengkapnya tentang status migrasi, hubungi dukungan.

Akses IP langsung tidak dapat dinonaktifkan untuk cluster yang sedang dalam 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 mengupgrade node pool secara otomatis selama peristiwa pemeliharaan.

Endpoint internal bidang kontrol tidak dapat diaktifkan

Gejala

Saat mencoba mengaktifkan endpoint internal bidang 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:

Pembuatan cluster gagal saat kebijakan organisasi ditentukan

Gejala

Saat mencoba membuat cluster, Anda akan melihat pesan error yang mirip dengan berikut ini:

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 di cluster yang menggunakan Private Service Connect. Pesan error yang mirip dengan 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 menyembunyikan endpoint, dan Anda tidak dapat melihatnya di konsolTrusted Cloud atau gcloud CLI.

Resolusi

Untuk mencegah kebocoran endpoint Private Service Connect sebelum penghapusan cluster, selesaikan langkah-langkah berikut:

  1. Tetapkan Kubernetes Engine Service Agent role ke akun layanan GKE.
  2. Pastikan izin compute.forwardingRules.* dan compute.addresses.* tidak ditolak secara eksplisit dari akun layanan GKE.

Jika Anda melihat endpoint Private Service Connect bocor, hubungi dukungan.

Tidak dapat mengurai jaringan resmi cluster

Gejala

Anda tidak dapat membuat cluster di versi 1.29 atau yang lebih baru. Pesan error yang mirip dengan yang berikut akan muncul:

Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
Kemungkinan penyebab

Project Trusted 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 mem-parsing flag master-ipv4-cidr.

Resolusi

Gunakan salah satu solusi berikut:

  • Lanjutkan 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 Trusted 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.

  • Migrasikan webhook berbasis IP pribadi Anda dengan menyelesaikan langkah-langkah di bagian Batasan Private Service Connect. Kemudian, hubungi dukungan untuk memilih ikut 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 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 flag master-ipv4-cidr di cluster tanpa mengaktifkan flag enable-private-nodes. Untuk membuat cluster dengan master-ipv4-cidr yang ditentukan, Anda harus mengonfigurasi cluster untuk menyediakan node dengan alamat IP internal (node pribadi) menggunakan flag enable-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.

  • Perbarui cluster Anda untuk menyediakan node dengan hanya alamat IP. Untuk mempelajari lebih lanjut, lihat Mengonfigurasi cluster Anda.

Tidak dapat menjadwalkan workload publik di cluster Autopilot

Gejala
Pada cluster Autopilot, jika cluster Anda hanya menggunakan node pribadi, Anda tidak dapat menjadwalkan workload di Pod publik menggunakan cloud.google.com/private-node=false nodeSelector.
Kemungkinan penyebab
Konfigurasi setelan flag private-node sebagai false 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 bidang 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:

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.

Langkah berikutnya