Memecahkan masalah penginstalan atau upgrade cluster

Version 1.15 

• Terbaru
• Versi 1.16
• Versi sebelumnya (tidak didukung)

Halaman ini memberikan informasi pemecahan masalah jika Anda mengalami masalah saat menginstal atau mengupgrade GKE pada cluster Bare Metal.

Masalah cluster bootstrap

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.

Catatan: Mulai dari GDCV untuk Bare Metal versi 1.15.0, perilaku upgrade default untuk cluster yang dikelola sendiri (admin, hybrid, atau mandiri) adalah upgrade siap pakai. Upgrade yang diterapkan menggunakan pengontrol siklus proses, bukan cluster bootstrap, untuk mengelola seluruh operasi upgrade. Perubahan ini menyederhanakan proses dan mengurangi persyaratan resource, yang membuat upgrade cluster lebih andal dan skalabel. Meskipun tidak direkomendasikan, dengan menetapkan flag --use-bootstrap=true dengan perintah bmctl upgrade, Anda masih memiliki opsi untuk menggunakan cluster bootstrap.

Jika cluster jenis sudah ada di deployment saat Anda mencoba menginstal, GDCV untuk Bare Metal akan menghapus cluster jenis yang 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.

GDCV untuk Bare Metal akan 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 kolom gcrKeyPath dalam file konfigurasi cluster.

• bmctl-workspace/config.toml: Berisi konfigurasi dalam container di cluster jenis.

Men-debug 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 GDCV untuk 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 perintah bmctl 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.

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 bagi GDCV tertentu untuk versi Bare Metal, lihat tabel di Kebijakan Dukungan Versi.

Jika node menunjukkan NOT READY, coba hubungkan ke 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 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).

Contoh output berikut menunjukkan bahwa node yang 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 dikosongkan

Selama proses upgrade, node akan menghabiskan Pod, dan penjadwalan dinonaktifkan hingga node berhasil diupgrade. Untuk melihat node mana yang dihabiskan 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).

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 macet atau lambat dihabiskan. Upgrade akan dilanjutkan, meskipun dengan Pod yang macet, jika proses pengosongan 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.

1. Periksa Pod statis dengan perintah crictl ps -a dan cari Pod Kubernetes atau Pod etcd 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.

2. Jika perintah crictl ps tidak berfungsi atau tidak menampilkan apa pun, periksa status kubelet dan containerd. Gunakan perintah systemctl status SERVICE dan journalctl -u SERVICE untuk melihat log.