Memecahkan masalah cluster pribadi di GKE


Halaman ini menunjukkan cara menyelesaikan masalah terkait cluster pribadi Google Kubernetes Engine (GKE).

Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.

Cluster pribadi tidak berjalan

Jika peering VPC antara bidang kontrol cluster dan node cluster dihapus, aturan firewall yang mengizinkan traffic masuk dari bidang kontrol cluster ke node di port 10250, atau penghapusan rute default ke gateway internet default, akan menyebabkan cluster pribadi berhenti berfungsi. Jika menghapus rute default, Anda harus memastikan traffic ke layanan Google Cloud yang diperlukan telah dirutekan. Untuk informasi selengkapnya, lihat perutean kustom.

Waktu tunggu saat membuat cluster pribadi

Setiap cluster pribadi memerlukan rute peering antar-VPC, tetapi hanya satu operasi peering yang dapat terjadi dalam satu waktu. Jika Anda mencoba membuat beberapa cluster pribadi secara bersamaan, waktu pembuatan cluster dapat habis. Untuk menghindari hal ini, buat cluster pribadi baru secara serial sehingga rute peering VPC sudah ada untuk setiap cluster pribadi berikutnya. Mencoba membuat satu cluster pribadi juga dapat habis waktu tunggunya jika ada operasi yang berjalan di VPC Anda.

Koneksi Peering Jaringan VPC pada cluster pribadi tidak sengaja dihapus

Gejala

Jika Anda tidak sengaja menghapus koneksi Peering Jaringan VPC, cluster akan mengalami status perbaikan dan semua node akan menampilkan status UNKNOWN. Anda tidak akan dapat melakukan operasi apa pun pada cluster karena keterjangkauan ke bidang kontrol terputus. Saat Anda memeriksa bidang kontrol, log akan menampilkan error yang mirip dengan berikut ini:

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 pemulihan cluster lama ke operasi normalnya.

Cluster tumpang-tindih dengan peer aktif

Gejala

Percobaan pembuatan cluster pribadi 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

Hapus dan buat ulang cluster menggunakan CIDR bidang kontrol yang berbeda.

Tidak dapat menjangkau bidang kontrol cluster pribadi

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 pribadi, 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

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. Konfigurasi ini tidak dapat diubah setelah pembuatan cluster. 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(masterAuthorizedNetworksConfig)"\
          --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 informasi selengkapnya, lihat mengakses endpoint pribadi bidang kontrol secara global.

  1. Jelaskan cluster untuk melihat respons konfigurasi akses kontrol:

    gcloud container clusters describe CLUSTER_NAME \
        --location=COMPUTE_LOCATION \
        --flatten "privateClusterConfig.masterGlobalAccessConfig"
    

    Ganti kode berikut:

    Output yang berhasil akan tampak seperti berikut ini:

      enabled: true
    
  2. Jika null ditampilkan, aktifkan akses global ke bidang kontrol.

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 pribadi menampilkan error seperti berikut:

Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork
[SUBNET_NAME] is already used by another cluster.
Kemungkinan penyebab

Salah satu dari hal berikut:

  • 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 flag filter 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.

Tidak dapat membuat subnet

Gejala

Saat mencoba membuat cluster pribadi dengan subnet otomatis atau membuat subnet kustom, Anda mungkin mengalami error berikut:

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.
Kemungkinan penyebab

Rentang CIDR bidang kontrol yang Anda tentukan tumpang-tindih dengan rentang IP lain dalam cluster. Hal ini juga dapat terjadi jika Anda baru saja menghapus cluster pribadi dan mencoba membuat cluster pribadi baru menggunakan CIDR bidang kontrol yang sama.

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 dalam cluster pribadi tidak memiliki alamat IP eksternal, sehingga tidak memenuhi persyaratan akses internet. Namun, node dapat mengakses API dan layanan Google 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 pribadi Anda dari Docker Hub ke Artifact Registry. Lihat Memigrasikan container dari registry pihak ketiga untuk informasi selengkapnya.

  • GKE 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 pribadi akan terhenti di langkah health check dan melaporkan error yang seperti 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

Salah satu dari berikut 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 dibuat, cluster pribadi 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 atau netd tidak dapat menjangkau *.gcr.io.

Resolusi

Gunakan salah satu solusi berikut:

Node cluster pribadi dibuat tetapi tidak bergabung dengan cluster

Sering kali, saat menggunakan perutean kustom dan peralatan jaringan pihak ketiga di VPC yang digunakan cluster pribadi Anda, 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 pribadi tidak dapat mengakses internet

Pod dalam cluster GKE 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 memiliki 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.