Memecahkan masalah pembuatan dan upgrade cluster

Halaman ini menunjukkan cara menyelidiki masalah terkait pembuatan, upgrade, dan perubahan ukuran cluster di GKE di VMware.

Perilaku logging default untuk gkectl dan gkeadm

Untuk gkectl dan gkeadm, cukup gunakan setelan logging default:

  • Untuk gkectl, file log default-nya adalah /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log, dan file tersebut terhubung dengan file logs/gkectl-$(date).log di direktori lokal tempat Anda menjalankan gkectl.

  • Untuk gkeadm, file log default-nya adalah logs/gkeadm-$(date).log di direktori lokal tempat Anda menjalankan gkeadm.

  • Tingkat panjang -v5 default mencakup semua entri log yang dibutuhkan oleh tim dukungan.

  • File log berisi perintah yang dieksekusi dan pesan kegagalan.

Sebaiknya kirimkan file log kepada tim dukungan saat Anda memerlukan bantuan.

Menentukan lokasi non-default untuk file log

Untuk menentukan lokasi non-default untuk file log gkectl, gunakan flag --log_file. File log yang Anda tentukan tidak akan di-symlink dengan direktori lokal.

Untuk menentukan lokasi non-default untuk file log gkeadm, gunakan flag --log_file.

Menemukan log Cluster API di cluster admin

Jika VM gagal dimulai setelah bidang kontrol admin dimulai, Anda dapat menyelidiki masalah dengan memeriksa log dari Pod pengontrol Cluster API di cluster admin.

  1. Temukan nama Pod pengontrol Cluster API:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

  2. Lihat log dari vsphere-controller-manager. Mulailah dengan menentukan Pod, tetapi tanpa container:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME

    Output-nya memberi tahu bahwa Anda harus menentukan container, dan memberi Anda nama container dalam Pod. Contoh:

    ... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

    Pilih container, dan lihat log-nya:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

Menggunakan govc untuk menyelesaikan masalah dengan vSphere

Anda dapat menggunakan govc untuk menyelidiki masalah pada vSphere. Misalnya, Anda dapat mengonfirmasi izin dan akses untuk akun pengguna vCenter, serta dapat mengumpulkan log vSphere.

Proses debug menggunakan log cluster bootstrap

Selama penginstalan, GKE di VMware membuat cluster bootstrap sementara. Setelah penginstalan berhasil, GKE di VMware akan menghapus cluster bootstrap, sehingga menyisakan cluster admin dan cluster pengguna Anda. Umumnya, Anda tidak memiliki alasan untuk berinteraksi dengan cluster bootstrap.

Jika Anda meneruskan --cleanup-external-cluster=false ke gkectl create cluster, cluster bootstrap tidak akan dihapus, dan Anda dapat menggunakan log cluster bootstrap untuk men-debug masalah penginstalan.

  1. Temukan nama Pod yang berjalan di namespace kube-system:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

  2. Melihat log untuk Pod:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

  3. Untuk mendapatkan log dari cluster bootstrap secara langsung, Anda dapat menjalankan perintah berikut selama pembuatan, update, dan upgrade cluster:

    docker exec -it gkectl-control-plane bash

    Perintah tersebut membuka terminal di dalam container gkectl-control-plane yang berjalan di cluster bootstrap.

    Untuk memeriksa log kubelet dan containerd, gunakan perintah berikut dan cari error atau peringatan dalam output:

    systemctl status -l kubelet
journalctl --utc -u kubelet
systemctl status -l containerd
journalctl --utc -u containerd

Melakukan roll back kumpulan node setelah upgrade

Jika mengupgrade cluster pengguna lalu menemukan masalah pada node cluster, Anda dapat melakukan roll back kumpulan node yang dipilih ke versi sebelumnya.

Roll back kumpulan node yang dipilih didukung untuk kumpulan node Ubuntu dan COS, tetapi tidak untuk kumpulan node Windows.

Versi kumpulan node bisa sama atau satu versi minor yang lebih lama dari versi bidang kontrol cluster pengguna. Misalnya, jika bidang kontrol berada di versi 1.14, kumpulan node dapat berada di versi 1.14 atau 1.13.

Melihat versi kumpulan node yang tersedia

Misalnya, Anda baru saja mengupgrade node pekerja cluster pengguna dan bidang kontrol dari versi 1.13.1-gke.35 ke versi 1.14.0, dan menemukan masalah pada node pekerja yang diupgrade. Jadi, Anda memutuskan untuk melakukan roll back satu atau beberapa kumpulan node ke versi yang sebelumnya Anda jalankan: 1.13.1-gke.35.

Pastikan versi sebelumnya tersedia untuk rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Output menunjukkan versi saat ini dan versi sebelumnya untuk setiap kumpulan node. Contoh: 
user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Melakukan roll back kumpulan node

Anda dapat melakukan roll back satu kumpulan node dalam satu waktu, atau me-roll back beberapa kumpulan node dalam satu langkah.

Dalam file konfigurasi cluster pengguna Anda, di satu atau beberapa kumpulan node, tetapkan nilai gkeOnPremVersion ke versi sebelumnya: 1.13.1-gke.35 dalam contoh ini:

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: 1.13.1-gke.35
  ...

Update cluster untuk melakukan roll back kumpulan node:

gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Pastikan bahwa rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Misalnya, output berikut menunjukkan bahwa pool-1 di-roll back ke versi 1.13.1-gke.35. 
user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.13.1-gke.35
  - previous version: 1.14.0-gke.x
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Upgrade ke versi patch baru

Misalkan masalah telah diperbaiki dalam versi patch baru, misalkan 1.14.1. Sekarang Anda dapat mengupgrade semua kumpulan node dan bidang kontrol ke versi patch baru.

Dalam file konfigurasi cluster pengguna Anda:

  • Tetapkan nilai gkeOnPremVersion ke versi patch baru: 1.14.1-gke.x dalam contoh ini.

  • Untuk setiap kumpulan node, hapus kolom gkeOnPremVersion, atau tetapkan ke string yang kosong. Jika tidak ada versi yang ditentukan untuk kumpulan node, versi untuk kumpulan node akan ditetapkan secara default ke versi yang ditentukan untuk cluster tersebut.

Contoh:

gkeOnPremVersion: 1.14.1-gke.x

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: ""
- name: pool-2
  cpus: 8
  memoryMB: 8192
  replicas: 2
  gkeOnPremVersion: ""

Jalankan gkectl prepare dan gkectl upgrade cluster seperti yang dijelaskan dalam Mengupgrade GKE di VMware.

Verifikasi versi cluster baru, dan lihat versi yang sekarang tersedia untuk rollback:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Contoh output: 
user cluster version: 1.14.1-gke.y

node pools:
- pool-1:
  - version: 1.14.1-gke.y
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.1-gke.y
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x
- 1.14.1-gke.y

Men-debug masalah F5 BIG-IP menggunakan file kubeconfig internal

Setelah penginstalan, GKE di VMware akan membuat file kubeconfig bernama internal-cluster-kubeconfig-debug di direktori utama workstation admin Anda. File kubeconfig ini identik dengan file kubeconfig cluster admin Anda, tetapi file tersebut mengarah langsung ke node bidang kontrol cluster admin, tempat server Kubernetes API berjalan. Anda dapat menggunakan file internal-cluster-kubeconfig-debug untuk melakukan debug masalah BIG-IP F5.

Gagal mengubah ukuran cluster pengguna

Jika perubahan ukuran cluster pengguna gagal:

  1. Temukan nama MachineDeployment dan Mesin:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

  2. Menjelaskan MachineDeployment untuk melihat log-nya:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

  3. Periksa kesalahan pada Mesin yang baru dibuat:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Tidak ada alamat yang dapat dialokasikan untuk pengubahan ukuran cluster

Masalah ini terjadi jika tidak ada cukup alamat IP yang tersedia untuk mengubah ukuran cluster pengguna.

kubectl describe machine menampilkan error berikut:

Events:
Type     Reason  Age                From                    Message
----     ------  ----               ----                    -------
Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

Untuk mengatasi masalah ini, Alokasikan lebih banyak alamat IP untuk cluster. Kemudian, hapus Perangkat yang terpengaruh:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

GKE di VMware membuat Mesin baru dan menetapkan salah satu alamat IP yang baru tersedia.

Jumlah alamat IP yang dialokasikan sudah memadai, tetapi Mesin gagal mendaftar dengan cluster

Masalah ini dapat terjadi jika ada konflik alamat IP. Misalnya, alamat IP yang Anda tentukan untuk mesin digunakan untuk load balancer.

Untuk mengatasi masalah ini, perbarui file blok IP cluster Anda agar alamat mesin tidak bertentangan dengan alamat yang ditentukan dalam file konfigurasi cluster atau file blok IP Seesaw.

Snapshot dibuat secara otomatis saat pembuatan atau upgrade cluster admin gagal

Jika Anda mencoba membuat atau mengupgrade cluster admin, dan operasi tersebut gagal, GKE di VMware akan mengambil snapshot eksternal cluster bootstrap, yang merupakan cluster sementara yang digunakan untuk membuat atau mengupgrade cluster admin. Meskipun snapshot cluster bootstrap ini mirip dengan snapshot yang diambil dengan menjalankan perintah gkectl diagnose snapshot di cluster admin, snapshot tersebut dipicu secara otomatis. Snapshot cluster bootstrap ini berisi informasi proses debug penting untuk proses pembuatan dan upgrade cluster admin. Anda dapat memberikan snapshot ini kepada Dukungan Google Cloud jika diperlukan.

Snapshot eksternal menyertakan log Pod dari onprem-admin-cluster-controller yang dapat Anda lihat untuk men-debug masalah pembuatan atau upgrade cluster. Log disimpan dalam file terpisah, misalnya:

kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_--container_onprem-admin-cluster-controller_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--namespace_kube-system

Health check dijalankan secara otomatis saat upgrade cluster gagal

Jika Anda mencoba mengupgrade admin atau cluster pengguna, dan operasi tersebut gagal, GKE di VMware akan otomatis menjalankan perintah gkectl diagnose cluster pada cluster.

Untuk melewati diagnosis otomatis, teruskan flag --skip-diagnose-cluster ke gkectl upgrade.

Proses upgrade macet

GKE di VMware, di balik layar, menggunakan perintah drain Kubernetes selama upgrade. Prosedur drain ini dapat diblokir oleh Deployment dengan hanya satu replika yang memiliki PodDisruptionBudget (PDB) yang dibuat untuknya dengan minAvailable: 1.

Dari GKE di VMware versi 1.13, Anda dapat memeriksa kegagalan melalui peristiwa Pod Kubernetes.

  1. Temukan nama Mesin:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

  2. Periksa error menggunakan perintah kubectl describe machine:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Berikut adalah contoh output:

Events:
  Type     Reason              Age    From                Message
  ----     ------              ----   ----                -------
  Warning  PodEvictionTooLong  3m49s  machine-controller  Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.

Untuk analisis yang lebih mendetail tentang status objek mesin, jalankan gkectl diagnose cluster:

...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
    Reason: 1 machine objects error(s).
    Unhealthy Resources:
    Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
    Reason: 1 pod disruption budget error(s).
    Unhealthy Resources:
    PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.

Untuk mengatasi masalah ini, simpan PDB, lalu hapus dari cluster sebelum mencoba melakukan upgrade. Anda kemudian dapat menambahkan kembali PDB setelah upgrade selesai.

Mendiagnosis status virtual machine

Jika muncul masalah terkait pembuatan virtual machine, jalankan gkectl diagnose cluster untuk mendapatkan diagnosis status mesin virtual.

Berikut adalah contoh output-nya:


- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
    Reason: 1 machine VMs error(s).
    Unhealthy Resources:
    Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
    Debug Information:
    null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/1.15/diagnose#overview_diagnose_snapshot

Baca artikel Mendiagnosis masalah cluster untuk informasi selengkapnya.

Membuat ulang file kubeconfig cluster pengguna yang hilang

Anda mungkin perlu membuat ulang file kubeconfig cluster pengguna dalam beberapa situasi:

  • Jika Anda mencoba membuat cluster pengguna, dan operasi pembuatan gagal, dan Anda ingin memiliki file kubeconfig cluster penggunanya.
  • Jika file kubeconfig cluster pengguna tidak ada, misalnya setelah dihapus.

Jalankan perintah berikut untuk membuat ulang file kubeconfig cluster pengguna:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
  -o jsonpath='{.data.admin\.conf}' | base64 -d  > USER_CLUSTER_KUBECONFIG

Ganti kode berikut:

  • USER_CLUSTER_KUBECONFIG: nama file kubeconfig baru untuk cluster pengguna Anda.
  • ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig untuk cluster admin Anda.