Halaman ini menunjukkan cara menyelidiki masalah terkait pembuatan dan upgrade cluster di Google Distributed Cloud.
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.Masalah penginstalan
Bagian berikut dapat membantu Anda memecahkan masalah terkait penginstalan Google Distributed Cloud.
Menggunakan cluster bootstrap untuk men-debug masalah
Selama penginstalan, Google Distributed Cloud akan membuat cluster bootstrap sementara. Setelah penginstalan berhasil, Google Distributed Cloud akan menghapus cluster bootstrap, sehingga Anda tetap memiliki cluster admin dan cluster pengguna. Umumnya, Anda tidak perlu memiliki alasan untuk berinteraksi dengan cluster bootstrap. Namun, jika mengalami masalah selama penginstalan, Anda dapat menggunakan log cluster bootstrap untuk membantu men-debug masalah tersebut.
Jika Anda meneruskan --cleanup-external-cluster=false ke gkectl create cluster, cluster bootstrap tidak akan dihapus, dan Anda dapat menggunakan cluster
bootstrap untuk men-debug masalah penginstalan.
Memeriksa log cluster bootstrap
Cari nama Pod yang berjalan di namespace
kube-system:kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-systemLihat log untuk Pod:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAMEGanti
POD_NAMEdengan nama Pod yang ingin Anda lihat.Untuk mendapatkan log dari cluster bootstrap secara langsung, jalankan perintah berikut selama pembuatan, update, dan upgrade cluster:
docker exec -it gkectl-control-plane bashPerintah ini membuka terminal di dalam container
gkectl-control-planeyang berjalan di cluster bootstrap.Untuk memeriksa log
kubeletdancontainerd, 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
Memeriksa snapshot cluster bootstrap
Jika Anda mencoba membuat atau mengupgrade cluster admin, dan operasi tersebut gagal, Google Distributed Cloud akan mengambil snapshot eksternal dari cluster bootstrap.
Snapshot cluster bootstrap ini mirip dengan snapshot yang diambil
dengan menjalankan perintah
gkectl diagnose snapshot pada cluster admin,
tetapi prosesnya akan otomatis dipicu. Snapshot cluster bootstrap
berisi informasi proses debug penting untuk proses pembuatan dan
upgrade cluster admin. Anda dapat memberikan snapshot ini
ke Cloud Customer Care jika diperlukan.
Snapshot eksternal mencakup log Pod dari onprem-admin-cluster-controller yang dapat Anda lihat untuk men-debug masalah pembuatan cluster atau upgrade. 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
VM tidak dimulai setelah bidang kontrol admin dimulai
Jika VM gagal dimulai setelah bidang kontrol admin dimulai, Anda dapat menyelidiki masalah dengan memeriksa log dari Pod pengontrol Cluster API di cluster admin:
Cari nama Pod pengontrol Cluster API:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ get pods | grep clusterapi-controllersMelihat log dari
vsphere-controller-manager. Mulailah dengan menentukan Pod, tetapi tanpa container:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAMEOutput memberi tahu Anda bahwa Anda harus menentukan container, dan Anda akan diberi nama container di Pod. Contoh:
... a container name must be specified ..., choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
Pilih penampung, dan lihat lognya:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME --container CONTAINER_NAME
Jumlah alamat IP yang dialokasikan memadai, tetapi Mesin gagal mendaftar dengan cluster
Masalah ini dapat terjadi jika ada konflik alamat IP. Misalnya, alamat IP yang Anda tentukan untuk sebuah 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
Masalah upgrade cluster
Bagian berikut memberikan tips tentang cara menyelesaikan masalah yang mungkin Anda alami selama upgrade cluster.
Melakukan roll back kumpulan node setelah upgrade
Jika Anda mengupgrade cluster pengguna lalu menemukan masalah pada node cluster, Anda dapat melakukan roll back kumpulan node yang dipilih ke versi sebelumnya.
Me-roll back kumpulan node yang dipilih didukung untuk kumpulan node Ubuntu dan COS, tetapi tidak untuk kumpulan node Windows.
Versi kumpulan node dapat sama atau satu versi minor yang lebih lama dari versi bidang kontrol cluster pengguna. Misalnya, jika bidang kontrol berada pada versi 1.14, kumpulan node dapat berada pada versi 1.14 atau 1.13.
Melihat versi node pool yang tersedia
Misalkan Anda baru saja mengupgrade node pekerja cluster pengguna dan bidang kontrol dari versi 1.13.1-gke.35 ke versi 1.14.0, dan Anda menemukan masalah pada worker node yang diupgrade. Jadi, Anda memutuskan untuk melakukan roll back satu atau beberapa kumpulan node ke versi yang sebelumnya dijalankan: 1.13.1-gke.35. Sebelum dapat memulai rollback, Anda harus memastikan bahwa versi sebelumnya tersedia untuk rollback.
Untuk melihat versi yang tersedia, jalankan perintah berikut:
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 versi kumpulan node
Anda dapat melakukan roll back versi kumpulan node satu per satu kumpulan node, atau melakukan roll back beberapa kumpulan node dalam satu langkah.
Untuk melakukan roll back versi kumpulan node, selesaikan langkah-langkah berikut:
Di file konfigurasi cluster pengguna, pada satu atau beberapa kumpulan node, tetapkan nilai
gkeOnPremVersionke versi sebelumnya. Contoh berikut menunjukkan cara melakukan roll back ke versi 1.13.1-gke.35:nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: 1.13.1-gke.35 ...Update cluster untuk me-roll back kumpulan node:
gkectl update cluster --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGPastikan rollback berhasil:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGOutput berikut menunjukkan bahwa
pool-1telah 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
Anda dapat mengupgrade semua kumpulan node dan bidang kontrol ke versi patch baru. Hal ini mungkin berguna jika Anda melakukan roll back ke versi sebelumnya dan ingin mengupgrade ke versi yang menyertakan perbaikan.
Untuk mengupgrade ke versi baru, selesaikan langkah-langkah berikut:
Buat perubahan berikut di file konfigurasi cluster pengguna Anda:
Setel nilai
gkeOnPremVersionke versi patch baru. Contoh ini menggunakan 1.14.1-gke.x.Untuk setiap kumpulan node, hapus kolom
gkeOnPremVersion, atau tetapkan ke string kosong. Jika tidak ada versi yang ditentukan untuk kumpulan node, versi kumpulan node akan ditetapkan secara default ke versi yang ditentukan untuk cluster.Perubahan ini terlihat mirip dengan contoh berikut:
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 preparedangkectl upgrade clusterseperti yang dijelaskan dalam Mengupgrade Google Distributed Cloud.Verifikasi versi cluster baru, dan lihat versi yang tersedia untuk rollback:
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGOutputnya mirip dengan hal berikut ini:
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 ```
Health check dijalankan secara otomatis saat upgrade cluster gagal
Jika Anda mencoba mengupgrade admin atau cluster pengguna, dan operasi tersebut gagal, Google Distributed Cloud akan otomatis menjalankan perintah gkectl diagnose cluster pada cluster.
Untuk melewati diagnosis otomatis, teruskan flag --skip-diagnose-cluster ke
gkectl upgrade.
Proses upgrade menjadi macet
Di balik layar, Google Distributed Cloud menggunakan perintah
Kubernetes drain
selama upgrade. Prosedur drain ini dapat diblokir oleh Deployment dengan
hanya satu replika yang memiliki PodDisruptionBudget (PDB) yang dibuat untuknya dengan
minAvailable: 1.
Dari Google Distributed Cloud versi 1.13, Anda dapat memeriksa kegagalan melalui peristiwa Pod Kubernetes.
Temukan nama Mesin:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespacesPeriksa apakah ada error menggunakan perintah
kubectl describe machine:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAMEOutputnya mirip dengan hal berikut ini:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.Opsional: Untuk analisis yang lebih mendetail tentang status objek mesin, jalankan
gkectl diagnose cluster.Outputnya mirip dengan hal berikut ini:
... 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 upgrade. Anda kemudian dapat menambahkan kembali PDB setelah upgrade selesai.
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 diabaikan secara diam-diam selama upgrade, yang berarti perubahan ini tidak berlaku 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 hanya mengabaikannya. Fitur ini hanya untuk cluster pengguna. Saat mengupgrade cluster admin, perubahan pada sebagian besar kolom otomatis diabaikan dan tidak akan diterapkan setelah upgrade.
Misalnya, jika Anda mencoba menonaktifkan perbaikan otomatis node saat mengupgrade cluster pengguna ke versi 1.28, upgrade akan gagal dan menampilkan 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 perlu mengabaikan error ini, ada solusi berikut:
- Kembalikan upaya perubahan yang dicoba, lalu jalankan kembali upgrade. Misalnya, dalam
skenario sebelumnya, Anda akan mengembalikan perubahan yang dibuat pada konfigurasi
AutoRepair, lalu menjalankan kembaligkectl upgrade. - Selain itu, Anda dapat membuat file konfigurasi yang cocok dengan status
cluster saat ini dengan menjalankan
gkectl get-config, memperbarui kolomgkeOnPremVersionuntuk cluster dan kumpulan node dalam file konfigurasi, kemudian menjalankan kembaligkectl upgrade.
Men-debug masalah BIG-IP F5 dengan file kubeconfig internal
Setelah penginstalan, Google Distributed Cloud 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, hanya saja file ini mengarah langsung ke node bidang kontrol cluster admin, tempat server Kubernetes API berjalan. Anda dapat menggunakan
file internal-cluster-kubeconfig-debug untuk men-debug masalah F5 BIG-IP.
Men-debug masalah dengan vSphere
Anda dapat menggunakan
govc untuk
menyelidiki masalah dengan vSphere. Misalnya, Anda dapat mengonfirmasi izin dan
akses untuk akun pengguna vCenter Anda, dan Anda dapat mengumpulkan log vSphere.
Membuat ulang file kubeconfig cluster pengguna yang tidak ada
Sebaiknya buat ulang file kubeconfig cluster pengguna dalam situasi
berikut:
- Jika Anda mencoba membuat cluster pengguna, dan operasi pembuatannya gagal, dan Anda ingin memiliki file
kubeconfigcluster penggunanya. - Jika file
kubeconfigcluster 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 filekubeconfigbaru untuk cluster pengguna Anda.ADMIN_CLUSTER_KUBECONFIG: jalur filekubeconfiguntuk cluster admin Anda.
Langkah selanjutnya
- Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.