Memecahkan masalah pembuatan atau upgrade cluster

Halaman ini menunjukkan cara menyelesaikan masalah terkait penginstalan atau upgrade cluster Google Distributed Cloud.

Masalah penginstalan

Bagian berikut dapat membantu Anda memecahkan masalah terkait penginstalan Google Distributed Cloud.

Pesan error sementara

Proses penginstalan Google Distributed Cloud adalah loop rekonsiliasi 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 Anda telah habis masa berlakunya, 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 perlu membuat kunci akun layanan baru.

Menggunakan cluster bootstrap untuk men-debug masalah

Saat membuat cluster yang dikelola sendiri (admin, hybrid, atau mandiri), Google Distributed Cloud men-deploy cluster Kubernetes di Docker (kind) untuk menghosting sementara pengontrol Kubernetes yang diperlukan untuk membuat cluster. Cluster sementara ini disebut cluster bootstrap. Cluster pengguna dibuat dan diupgrade oleh admin pengelola atau cluster hybrid tanpa menggunakan cluster bootstrap.

Catatan: Mulai dari Google Distributed Cloud versi 1.15.0, perilaku upgrade default untuk cluster yang dikelola sendiri (admin, hybrid, atau mandiri) adalah upgrade di tempat. Upgrade langsung menggunakan pengontrol siklus proses, bukan cluster bootstrap, untuk mengelola seluruh operasi upgrade. Perubahan ini menyederhanakan proses dan mengurangi persyaratan resource, sehingga upgrade cluster menjadi lebih andal dan dapat diskalakan. Meskipun tidak direkomendasikan, dengan menyetel flag --use-bootstrap=true dengan perintah bmctl upgrade, Anda tetap memiliki opsi untuk menggunakan cluster bootstrap.

Jika cluster kind sudah ada di deployment saat Anda mencoba menginstal, Google Distributed Cloud akan menghapus cluster kind yang ada. Penghapusan hanya terjadi setelah penginstalan atau upgrade berhasil. Untuk mempertahankan cluster kind yang ada meskipun setelah berhasil, gunakan flag --keep-bootstrap-cluster dari bmctl.

Google Distributed Cloud membuat file konfigurasi untuk bootstrap cluster di WORKSPACE_DIR/.kindkubeconfig. Anda hanya dapat terhubung ke cluster bootstrap selama pembuatan dan upgrade cluster.

Cluster bootstrap perlu mengakses repositori Docker untuk menarik image. Registry secara default adalah Artifact Registry, kecuali jika Anda menggunakan registry pribadi. Selama pembuatan cluster,bmctl membuat file berikut:

• bmctl-workspace/config.json: Berisi kredensial akun layanan untuk akses registry. Google Cloud Kredensial diperoleh dari kolom gcrKeyPath dalam file konfigurasi cluster.

• bmctl-workspace/config.toml: Berisi konfigurasi containerd di cluster kind.

Memeriksa log cluster bootstrap

Untuk men-debug cluster bootstrap, Anda dapat melakukan langkah-langkah berikut:

• Hubungkan ke cluster bootstrap selama pembuatan dan upgrade cluster.
• Dapatkan log cluster bootstrap.

Anda dapat menemukan log di mesin yang Anda gunakan 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 langsung dari cluster bootstrap, Anda dapat menjalankan perintah berikut selama pembuatan dan upgrade cluster:

docker exec -it bmctl-control-plane bash

Perintah ini akan 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

Mengaktifkan logging debug containerd

Jika log containerd standar tidak memberikan informasi yang cukup untuk pemecahan masalah, Anda dapat meningkatkan tingkat logging. Peningkatan tingkat logging sering kali diperlukan saat mendiagnosis masalah kompleks, seperti masalah pada mirror registry atau error ImagePullBackOff.

Catatan: Jika tugas machine-update dipicu saat Anda memecahkan masalah, tugas tersebut akan mengurungkan semua perubahan yang Anda buat pada file config.toml. Jika peristiwa ini terjadi, tunggu hingga tugas selesai dan coba lagi.

Untuk meningkatkan level logging, lakukan hal berikut:

1. Aktifkan logging debug:

   1. Buka file konfigurasi containerd (/etc/containerd/config.toml) menggunakan editor teks pilihan Anda.

   2. Dalam file, temukan bagian [debug] dan ubah nilai level dari "" menjadi "debug".

   3. Simpan file dan keluar dari editor teks.

   4. Pastikan Anda berhasil memperbarui file konfigurasi:

      cat /etc/containerd/config.toml | grep debug
      

      Output harus berupa yang berikut ini:

      [debug]
        level = "debug"
          shim_debug = false
      

   5. Untuk menerapkan perubahan level logging, mulai ulang containerd:

      sudo systemctl restart containerd
      

2. Untuk membuat entri log baru, coba tarik image yang tidak ada atau tidak digunakan oleh node atau cluster mana pun. Contoh:

   # This command fails because the image doesn't exist
   crictl pull us-west1-docker.pkg.dev/gdc-project/samples/non-existent-image:latest
   

   Hal ini akan memaksa containerd untuk melakukan tindakan dan membuat log mendetail.

3. Tunggu hingga image ditarik atau gagal, lalu kumpulkan log containerd dalam file bernama containerd_log.txt:

   journalctl -u containerd --no-pager --since TIME_PERIOD > containerd_log.txt
   

   Ganti TIME_PERIOD dengan nilai yang menentukan waktu mulai untuk log. Lampirkan nilai yang berisi spasi dalam tanda kutip ganda. Contoh, "2 hours ago".

4. Setelah Anda selesai memecahkan masalah, kembalikan tingkat log ke default. Membiarkan logging debug diaktifkan dapat membanjiri log sistem Anda, memengaruhi performa, dan berpotensi mengekspos informasi sensitif.

   1. Buka file /etc/containerd/config.toml dan ubah nilai level kembali ke "", tingkat logging default.

   2. Pastikan Anda berhasil memperbarui konfigurasi:

      cat /etc/containerd/config.toml | grep level
      

      Output harus berupa yang berikut ini:

      level = ""
      

   3. Untuk menerapkan perubahan, mulai ulang containerd:

      sudo systemctl restart containerd
      

      Sistem Anda kini kembali ke konfigurasi logging standarnya.

Masalah upgrade cluster

Saat mengupgrade cluster Google Distributed Cloud, Anda dapat memantau progres dan memeriksa status cluster dan node.

• Jika Anda mengalami masalah selama upgrade, coba tentukan 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 Google Distributed Cloud.

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 kubeconfig admin.
  • Secara default, cluster admin, hybrid, dan mandiri menggunakan upgrade di tempat. 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 terletak di direktori ruang kerja.

Lihat bagian Status dari output, yang menunjukkan agregasi status upgrade cluster. Jika cluster melaporkan error, gunakan bagian berikut untuk memecahkan masalah penyebabnya.

Periksa 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 telah berhasil menyelesaikan proses upgrade, lihat kolom VERSION dan AGE dalam respons perintah. VERSION adalah versi Kubernetes untuk cluster. Untuk melihat versi Kubernetes untuk versi Google Distributed Cloud tertentu, lihat Pembuatan Versi.

Jika node menampilkan NOT READY, coba hubungkan node dan periksa status kubelet:

systemctl status kubelet

Anda juga dapat meninjau log kubelet:

journalctl -u kubelet

Tinjau output status dan log kubelet untuk menemukan pesan yang menunjukkan alasan node mengalami masalah.

Memeriksa node mana yang sedang diupgrade

Untuk memeriksa node mana di cluster yang sedang diupgrade, 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 kubeconfig admin.
  • Jika cluster bootstrap digunakan untuk upgrade admin, hybrid, atau mandiri, tentukan file kubeconfig cluster bootstrap (bmctl-workspace/.kindkubeconfig).

Output contoh 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 yang sedang dalam proses pengurasan

Selama proses upgrade, Pod akan dikuras dari node, dan penjadwalan akan dinonaktifkan hingga node berhasil diupgrade. Untuk melihat node mana yang sedang dikuras, 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 untuk 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 kubeconfig admin.
  • Jika cluster bootstrap digunakan untuk upgrade admin, hybrid, atau mandiri, tentukan file kubeconfig cluster bootstrap (bmctl-workspace/.kindkubeconfig).

Node yang dikuras akan menampilkan status di kolom MAINTENANCE.

Memeriksa alasan node berada dalam status pengurasan untuk waktu yang lama

Gunakan salah satu metode di bagian sebelumnya untuk mengidentifikasi node yang dikuras 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 sedang dikuras. Output menampilkan daftar Pod yang macet atau lambat dikuras. Upgrade akan dilanjutkan, meskipun dengan Pod yang macet, saat proses pengurasan pada node memerlukan waktu lebih dari 20 menit.

Mulai rilis 1.29, proses pengurasan node menggunakan Eviction API, yang mematuhi PodDisruptionBudgets (PDB).

Setelan PDB berikut dapat menyebabkan masalah pengurasan node:

• Pod yang dikelola oleh beberapa PDB

• Konfigurasi statis PDB seperti berikut:

  • maxUnavailable == 0
  • minUnavailable >= total replika

  Jumlah total replika sulit ditentukan dari resource PDB, karena ditentukan dalam resource tingkat yang lebih tinggi, seperti Deployment, ReplicaSet, atau StatefulSet. PDB cocok dengan pod berdasarkan pemilih dalam konfigurasinya saja. Pendekatan yang baik untuk mendiagnosis apakah konfigurasi PDB statis menyebabkan masalah adalah dengan melihat apakah pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy terlebih dahulu dan melihat apakah salah satu konfigurasi statis yang disebutkan memungkinkan hal ini terjadi.

Pelanggaran runtime, seperti nilai DisruptionsAllowed yang dihitung untuk resource PDB menjadi 0, juga dapat memblokir pengurasan node. Jika Anda telah mengonfigurasi objek PodDisruptionBudget yang tidak dapat mengizinkan gangguan tambahan, upgrade node mungkin akan gagal diupgrade ke versi bidang kontrol setelah beberapa kali percobaan. Untuk mencegah kegagalan ini, sebaiknya tingkatkan skala Deployment atau HorizontalPodAutoscaler agar node dapat dihabiskan sambil tetap mematuhi konfigurasi PodDisruptionBudget.

Untuk melihat semua objek PodDisruptionBudget yang tidak mengizinkan gangguan apa pun, gunakan perintah berikut:

kubectl get poddisruptionbudget --all-namespaces \
    -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Memeriksa alasan Pod tidak responsif

Upgrade dapat gagal jika Pod berisi alamat IP bidang kontrol upgrade-first-node atau upgrade-node. Perilaku ini biasanya terjadi karena Pod statis tidak dalam kondisi baik.

1. Periksa Pod statis dengan perintah crictl ps -a dan cari Pod etcd atau Kubernetes yang error. Jika ada Pod yang gagal, tinjau log Pod untuk mengetahui alasan Pod tersebut error.

   Beberapa kemungkinan perilaku crashloop meliputi:

   • Izin atau pemilik file yang di-mount ke Pod statis tidak benar.
   • Konektivitas ke alamat IP virtual tidak berfungsi.
   • Masalah pada 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.

Langkah berikutnya

Jika Anda memerlukan bantuan tambahan, hubungi Layanan Pelanggan Cloud. Anda juga dapat melihat bagian Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk:

• Persyaratan untuk membuka kasus dukungan.
• Alat untuk membantu Anda memecahkan masalah, seperti konfigurasi lingkungan, log, dan metrik.
• Komponen yang didukung.