Halaman ini menunjukkan cara menyelesaikan masalah terkait penginstalan atau upgrade GKE di cluster Bare Metal.
Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.Masalah penginstalan
Bagian berikut dapat membantu Anda memecahkan masalah saat menginstal GKE di Bare Metal.
Pesan error sementara
Proses penginstalan GKE di Bare Metal adalah loop rekonsiliasi yang berkelanjutan. Akibatnya, Anda mungkin melihat pesan error sementara dalam log selama penginstalan.
Selama penginstalan berhasil diselesaikan, error ini dapat diabaikan dengan aman. Berikut adalah daftar pesan log error sementara yang umum:
Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
dial tcp IP_ADDRESS:443: connect: connection refused
Internal error occurred: failed calling webhook "vcluster.kb.io": Post
https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
dial tcp IP_ADDRESS:443: connect: connection refused
Failed to register cluster with GKE Hub; gcloud output: error running command
'gcloud container fleet memberships register CLUSTER_NAME --verbosity=error --quiet':
error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF
Get
https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"
Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""
Jika kunci akun layanan Google Cloud sudah tidak berlaku, Anda akan melihat pesan error berikut dari bmctl
:
Error validating cluster config: 3 errors occurred:
* GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
Anda harus membuat kunci akun layanan baru.
Menggunakan cluster bootstrap untuk men-debug masalah
Saat membuat cluster yang dikelola sendiri (admin, hybrid, atau mandiri), GKE on Bare Metal akan men-deploy cluster Kubernetes di Docker untuk sementara guna menghosting pengontrol Kubernetes yang diperlukan untuk membuat cluster. Cluster sementara ini disebut cluster bootstrap. Cluster pengguna dibuat dan diupgrade oleh admin pengelola atau cluster hybrid mereka tanpa menggunakan cluster bootstrap.
Jika cluster jenis sudah ada di deployment Anda saat Anda mencoba menginstal, GKE di Bare Metal akan menghapus cluster jenis yang sudah ada tersebut. Penghapusan hanya
terjadi setelah penginstalan atau upgrade berhasil.
Untuk mempertahankan cluster jenis yang ada bahkan setelah berhasil, gunakan
tanda --keep-bootstrap-cluster
dari bmctl
.
GKE di Bare Metal membuat file konfigurasi untuk cluster bootstrap di bagian WORKSPACE_DIR/.kindkubeconfig
. Anda hanya dapat terhubung ke cluster bootstrap selama pembuatan dan upgrade cluster.
Cluster bootstrap perlu mengakses repositori Docker untuk mengambil image. Secara default, registry akan ditetapkan ke Container Registry kecuali jika Anda menggunakan registry pribadi. Selama pembuatan cluster,bmctl
membuat file berikut:
bmctl-workspace/config.json
: Berisi kredensial akun layanan Google Cloud untuk akses registry. Kredensial diperoleh dari kolomgcrKeyPath
dalam file konfigurasi cluster.bmctl-workspace/config.toml
: Berisi konfigurasi dalam container di cluster jenis.
Memeriksa log cluster bootstrap
Untuk men-debug cluster bootstrap, Anda dapat melakukan langkah-langkah berikut:
- Menghubungkan ke cluster bootstrap selama pembuatan dan upgrade cluster.
- Mendapatkan log cluster bootstrap.
Anda dapat menemukan log di mesin yang digunakan untuk menjalankan bmctl
di folder
berikut:
bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/
Ganti CLUSTER_NAME
dan TIMESTAMP
dengan
nama cluster Anda dan waktu sistem yang sesuai.
Untuk mendapatkan log dari cluster bootstrap secara langsung, Anda dapat menjalankan perintah berikut selama pembuatan dan upgrade cluster:
docker exec -it bmctl-control-plane bash
Perintah ini membuka terminal di dalam container bidang kontrol bmctl yang berjalan di cluster bootstrap.
Untuk memeriksa log kubelet
dan containerd
, gunakan perintah berikut dan
cari error atau peringatan dalam output:
journalctl -u kubelet
journalctl -u containerd
Masalah upgrade cluster
Saat mengupgrade GKE pada cluster Bare Metal, Anda dapat memantau progres dan memeriksa status cluster dan node Anda.
- Jika Anda mengalami masalah selama upgrade, cobalah untuk menentukan pada tahap mana kegagalan terjadi. Untuk mempelajari lebih lanjut apa yang terjadi pada cluster selama proses upgrade, lihat Siklus proses dan tahap upgrade cluster.
- Untuk mempelajari lebih lanjut dampak masalah selama upgrade cluster, lihat Memahami dampak kegagalan di GKE pada Bare Metal.
Panduan berikut dapat membantu menentukan apakah upgrade berlanjut seperti biasa atau ada masalah.
Memantau progres upgrade
Gunakan perintah kubectl describe cluster
untuk melihat status cluster selama proses upgrade:
kubectl describe cluster CLUSTER_NAME \
--namespace CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Ganti nilai berikut:
CLUSTER_NAME
: nama cluster Anda.CLUSTER_NAMESPACE
: namespace cluster Anda.ADMIN_KUBECONFIG
: file admin kubeconfig.- Secara default, admin, cluster hybrid, dan cluster mandiri menggunakan upgrade yang ada.
Jika Anda menggunakan flag
--use-bootstrap=true
dengan perintahbmctl upgrade
, operasi upgrade akan menggunakan cluster bootstrap. Untuk memantau progres upgrade saat cluster bootstrap digunakan, tentukan jalur ke file kubeconfig cluster bootstrap,.kindkubeconfig
. File ini berada di direktori workspace.
- Secara default, admin, cluster hybrid, dan cluster mandiri menggunakan upgrade yang ada.
Jika Anda menggunakan flag
Lihat bagian Status
dari output, yang menunjukkan agregasi
status upgrade cluster. Jika cluster melaporkan error, gunakan bagian berikut
untuk memecahkan masalah yang terjadi.
Memeriksa apakah node sudah siap
Gunakan perintah kubectl get nodes
untuk melihat status node dalam cluster
selama proses upgrade:
kubectl get nodes --kubeconfig KUBECONFIG
Untuk memeriksa apakah node berhasil menyelesaikan proses upgrade, lihat
kolom VERSION
dan AGE
dalam respons perintah. VERSION
adalah versi Kubernetes untuk cluster. Guna melihat versi Kubernetes untuk GKE tertentu pada versi Bare Metal, lihat tabel di Kebijakan Dukungan Versi.
Jika node menunjukkan NOT READY
, coba hubungkan node dan periksa status
kubelet:
systemctl status kubelet
Anda juga dapat meninjau log kubelet:
journalctl -u kubelet
Tinjau output status kubelet dan log ke pesan yang menunjukkan mengapa node tersebut memiliki masalah.
Memeriksa node mana yang sedang diupgrade
Untuk memeriksa node mana dalam cluster yang sedang dalam proses upgrade, gunakan perintah kubectl get baremetalmachines
:
kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Ganti nilai berikut:
CLUSTER_NAMESPACE
: namespace cluster Anda.ADMIN_KUBECONFIG
: file admin kubeconfig.- Jika cluster bootstrap digunakan untuk upgrade admin, hybrid, atau mandiri,
tentukan file kubeconfig cluster bootstrap
(
bmctl-workspace/.kindkubeconfig
).
- Jika cluster bootstrap digunakan untuk upgrade admin, hybrid, atau mandiri,
tentukan file kubeconfig cluster bootstrap
(
Contoh output berikut menunjukkan bahwa node yang sedang diupgrade
memiliki ABM VERSION
yang berbeda dari DESIRED ABM VERSION
:
NAME CLUSTER READY INSTANCEID MACHINE ABM VERSION DESIRED ABM VERSION
10.200.0.2 cluster1 true baremetal://10.200.0.2 10.200.0.2 1.13.0 1.14.0
10.200.0.3 cluster1 true baremetal://10.200.0.3 10.200.0.3 1.13.0 1.13.0
Memeriksa node apa yang saat ini sedang dikosongkan
Selama proses upgrade, node akan menghabiskan Pod, dan penjadwalan
dinonaktifkan hingga node berhasil diupgrade. Untuk melihat node mana yang
saat ini dikosongkan dari Pod, gunakan perintah kubectl get nodes
:
kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"
Ganti USER_CLUSTER_KUBECONFIG
dengan jalur ke file kubeconfig cluster pengguna.
Kolom STATUS
difilter menggunakan grep
agar hanya menampilkan node yang melaporkan
SchedulingDisabled
. Status ini menunjukkan bahwa node sedang dikuras.
Anda juga dapat memeriksa status node dari cluster admin:
kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Ganti nilai berikut:
CLUSTER_NAMESPACE
: namespace cluster Anda.ADMIN_KUBECONFIG
: file admin kubeconfig.- Jika cluster bootstrap digunakan untuk upgrade admin, hybrid, atau mandiri,
tentukan file kubeconfig cluster bootstrap
(
bmctl-workspace/.kindkubeconfig
).
- Jika cluster bootstrap digunakan untuk upgrade admin, hybrid, atau mandiri,
tentukan file kubeconfig cluster bootstrap
(
Node yang dikosongkan akan menampilkan status di bawah kolom MAINTENANCE
.
Memeriksa penyebab node berada dalam status pengurasan dalam waktu yang lama
Gunakan salah satu metode di bagian sebelumnya untuk mengidentifikasi node yang
terkuras menggunakan perintah kubectl get nodes
. Gunakan perintah kubectl get
pods
dan filter pada nama node ini untuk melihat detail tambahan:
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
Ganti NODE_NAME
dengan nama
node yang dikosongkan. Output-nya akan menampilkan daftar Pod yang saat ini macet
atau lambat dikuras. Upgrade akan dilanjutkan, meskipun dengan Pod yang macet, jika proses pengosongan
node pada node memerlukan waktu lebih dari 20 menit.
Memeriksa penyebab Pod tidak sehat
Upgrade dapat gagal jika Pod berisi alamat IP bidang kontrol upgrade-first-node
atau upgrade-node
. Perilaku ini biasanya terjadi karena Pod statis
tidak responsif.
Periksa Pod statis dengan perintah
crictl ps -a
dan cari Pod Kubernetes atau Podetcd
yang mengalami error. Jika ada Pod yang gagal, tinjau log Pod untuk melihat penyebab Pod tersebut mengalami error.Beberapa kemungkinan untuk perilaku crashloop meliputi hal berikut:
- Izin atau pemilik file yang dipasang ke Pod statis tidak benar.
- Konektivitas ke alamat IP virtual tidak berfungsi.
- Masalah terkait
etcd
.
Jika perintah
crictl ps
tidak berfungsi atau tidak menampilkan apa pun, periksa statuskubelet
dancontainerd
. Gunakan perintahsystemctl status SERVICE
danjournalctl -u SERVICE
untuk melihat log.
Langkah selanjutnya
- Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.