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 filelogs/gkectl-$(date).logdi direktori lokal tempat Anda menjalankangkectl.Untuk
gkeadm, file log default-nya adalahlogs/gkeadm-$(date).logdi direktori lokal tempat Anda menjalankangkeadm.Tingkat panjang
-v5default 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.
Temukan nama Pod pengontrol Cluster API:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ get pods | grep clusterapi-controllersLihat log dari
vsphere-controller-manager. Mulailah dengan menentukan Pod, tetapi tanpa container:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEOutput-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
Cluster jenis tidak dihapus
Saat Anda membuat cluster admin, cluster kind (juga disebut
cluster bootstrap) akan dibuat sebagai bagian dari proses. Saat operasi cluster admin
selesai, cluster kind akan dihapus secara otomatis.
Jika melihat pesan error Failed to delete the kind cluster, Anda dapat melakukan langkah-langkah berikut di workstation admin untuk menghapus cluster kind secara manual:
Dapatkan ID penampung
kind:docker inspect --format="{{.Id}}" gkectl-control-planeDapatkan ID proses
containerd-shim:sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'Menghentikan prosesnya:
sudo kill -9 PROCESS_ID
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.
Temukan nama Pod yang berjalan di namespace
kube-system:kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
Melihat log untuk Pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME
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
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
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
gkeOnPremVersionke 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
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:
Temukan nama MachineDeployment dan Mesin:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
Menjelaskan MachineDeployment untuk melihat log-nya:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
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.
Temukan nama Mesin:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
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/latest/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.
Hapus perubahan yang tidak didukung untuk berhenti memblokir upgrade
Saat mengupgrade cluster ke versi 1.16 atau yang lebih lama, perubahan pada sebagian besar kolom akan otomatis diabaikan selama upgrade, yang berarti perubahan tersebut tidak akan diterapkan selama dan setelah upgrade.
Saat mengupgrade cluster pengguna ke versi 1.28 atau yang lebih baru, kami memvalidasi semua perubahan yang dibuat dalam file konfigurasi dan menampilkan error untuk perubahan yang tidak didukung, bukan sekadar mengabaikannya. Misalnya, jika Anda mencoba menonaktifkan perbaikan otomatis node saat mengupgrade cluster pengguna ke 1.28, upgrade akan gagal dengan pesan error berikut:
failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
v1alpha1.OnPremUserClusterSpec{
... // 20 identical fields
UsageMetering: nil,
CloudAuditLogging: &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
- AutoRepair: &v1alpha1.AutoRepairConfig{Enabled: true},
+ AutoRepair: &v1alpha1.AutoRepairConfig{},
CARotation: &{Generated: &{CAVersion: 1}},
KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
... // 8 identical fields
}
Jika Anda harus mengabaikan error ini, ada solusi berikut:
- Kembalikan perubahan yang dicoba, lalu jalankan kembali upgrade. Misalnya, dalam skenario sebelumnya, Anda akan mengembalikan perubahan yang dibuat pada konfigurasi
AutoRepair, lalu menjalankan kembaligkectl upgrade. - Atau, Anda dapat membuat file konfigurasi yang cocok dengan status cluster saat ini dengan menjalankan
gkectl get-config, perbarui kolomgkeOnPremVersionuntuk cluster dan kumpulan node di file konfigurasi, lalu jalankan kembaligkectl upgrade.
Error perintah gkectl saat menggunakan Kontrol Layanan VPC
Jika menggunakan Kontrol Layanan VPC, Anda mungkin melihat error saat menjalankan beberapa perintah gkectl, seperti "Validation Category: GCP - [UNKNOWN] GCP
service: [Stackdriver] could not get GCP services". Untuk menghindari error ini, tambahkan parameter --skip-validation-gcp ke perintah Anda.