Mendiagnosis masalah cluster

Dokumen ini menunjukkan cara menggunakan gkectl diagnose untuk mendiagnosis masalah di cluster Anda.

Ringkasan

Alat gkectl memiliki dua perintah untuk memecahkan masalah cluster: gkectl diagnose cluster dan gkectl diagnose snapshot. Perintah tersebut berfungsi dengan cluster admin dan pengguna.

`gkectl diagnose cluster`

Melakukan health check pada cluster Anda dan melaporkan error. Menjalankan health check pada komponen berikut:

VCenter
- Kredensial
- DRS
- Kelompok Anti-Afinitas
- Jaringan
- Versi
- Pusat data
- Datastore
- ResourcePool
- Folder
- Jaringan
Loadbalancer (F5, Jungkat-jungkit, Manual)
Cluster pengguna dan kumpulan node
Objek cluster
Kesiapan server konnektivitas cluster pengguna
Objek mesin dan node cluster yang sesuai
Pod di namespace kube-system dan gke-system
Bidang kontrol
Volume persisten vSphere dalam cluster
Sinyal vCPU cluster pengguna dan admin (CPU virtual) dan sinyal pertentangan memori
Cluster pengguna dan admin ESXi Alarm Penggunaan CPU Host dan Penggunaan Memori yang telah dikonfigurasi sebelumnya.
Waktu (TOD)
Kebijakan jaringan node untuk cluster dengan Dataplane V2 diaktifkan
Tingkat kesiapan agen node Dataplane V2 secara keseluruhan

`gkectl diagnose snapshot`

Perintah ini mengompresi status, konfigurasi, dan log cluster menjadi file tarball. Jika Anda menjalankan gkectl diagnose snapshot, perintah tersebut akan otomatis menjalankan gkectl diagnose cluster sebagai bagian dari proses, dan file output ditempatkan ke folder baru dalam snapshot bernama /diagnose-report.

Konfigurasi default perintah gkectl diagnose snapshot juga menangkap informasi berikut tentang cluster Anda:

Versi Kubernetes
Status resource Kubernetes dalam namespace sistem kube dan gke: cluster, machine, node, Layanan, Endpoint, ConfigMaps, ReplicaSets, CronJobs, Pods, dan pemilik Pod tersebut, termasuk Deployment, DaemonSet, dan StatefulSet
Status bidang kontrol
Detail tentang setiap konfigurasi node, termasuk alamat IP, aturan iptables, titik pemasangan, sistem file, koneksi jaringan, dan proses yang sedang berjalan
Log container dari node bidang kontrol cluster admin, saat server Kubernetes API tidak tersedia
Informasi vSphere termasuk objek VM dan Peristiwanya berdasarkan Kumpulan Resource. Selain itu, objek Pusat Data, Cluster, Jaringan, dan Datastore yang terkait dengan VM
Informasi load balancer BIG-IP F5 termasuk server virtual, alamat virtual, kumpulan, node, dan monitor
Log dari perintah gkectl diagnose snapshot
Log tugas preflight
Log container di namespace berdasarkan skenario
Informasi tentang akhir masa berlaku sertifikat Kubernetes cluster admin dalam file snapshot /nodes/<admin_master_node_name>/sudo_kubeadm_certs_check-expiration
File indeks HTML untuk semua file dalam snapshot
Secara opsional, file konfigurasi cluster admin yang digunakan untuk menginstal dan mengupgrade cluster dengan tanda --config.

Kredensial, termasuk kredensial vSphere dan F5, akan dihapus sebelum tarball dibuat.

Dapatkan bantuan

Untuk mendapatkan bantuan tentang perintah yang tersedia:

gkectl diagnose --help

Mendiagnosis cluster admin

Untuk mendiagnosis cluster admin:

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Ganti ADMIN_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster admin Anda.

Output ujian:

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

- Validation Category: Admin Cluster Connectivity
Checking VMs TOD (availability)...SUCCESS
Checking Konnectivity Server (readiness)...SUCCESS

- Validation Category: Admin Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: Admin Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: Admin Cluster
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking kube-system pods...SUCCESS
Checking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

Jika ada masalah dengan alamat IP virtual (VIP) di cluster target, gunakan tanda --config untuk menyediakan file konfigurasi cluster admin. Hal ini memberi Anda lebih banyak informasi proses debug.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG

Ganti CLUSTER_CONFIG dengan jalur file konfigurasi cluster admin atau pengguna.

Contoh output:

Failed to access the api server via LB VIP "...": ...
Try to use the admin master IP instead of problematic VIP...
Reading config with version "[CONFIG_VERSION]"
Finding the admin master VM...
Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"...
Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM.
Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"...
...

Mendiagnosis cluster pengguna

Untuk mendapatkan nama cluster pengguna:

kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG

Ganti USER_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster pengguna.

Untuk mendiagnosis cluster pengguna:

gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

Ganti USER_CLUSTER_NAME dengan nama cluster pengguna.

Contoh output:

Preparing for the diagnose tool...
Diagnosing the cluster......DONE

Diagnose result is saved successfully in 

- Validation Category: User Cluster Connectivity
Checking Node Network Policy...SUCCESS
Checking VMs TOD (availability)...SUCCESS
Checking Dataplane-V2...Success

- Validation Category: User Cluster F5 BIG-IP
Checking f5 (credentials, partition)...SUCCESS

- Validation Category: User Cluster VCenter
Checking Credentials...SUCCESS
Checking DRS enabled...SUCCESS
Checking Hosts for AntiAffinityGroups...SUCCESS
Checking VSphere CSI Driver...SUCCESS
Checking Version...SUCCESS
Checking Datacenter...SUCCESS
Checking Datastore...SUCCESS
Checking Resource pool...SUCCESS
Checking Folder...SUCCESS
Checking Network...SUCCESS

- Validation Category: User Cluster
Checking user cluster and node pools...SUCCESS
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking control plane pods...SUCCESS
Checking kube-system pods...SUCCESS
Checking gke-system pods...SUCCESS
Checking gke-connect pods...SUCCESS
Checeking anthos-identity-service pods...SUCCESS
Checking storage...SUCCESS
Checking resource...SUCCESS
Checking virtual machine resource contention...SUCCESS
Checking host resource contention...SUCCESS
All validation results were SUCCESS.
Cluster is healthy!

Memecahkan masalah cluster yang didiagnosis

Jika Anda mengalami masalah berikut ini saat menjalankan gkectl diagnose cluster, berikut beberapa kemungkinan penyelesaiannya.

Masalah	Kemungkinan penyebab	Resolusi
Server Kubernetes API tidak dapat dijangkau, baik untuk cluster admin maupun untuk cluster pengguna.	Memeriksa kesehatan mesin virtual pada grafik latensi memori OOB (bawaan) yang idealnya harus memiliki latensi memori sekitar nol. Pertentangan memori juga dapat meningkatkan pertentangan CPU, dan grafik kesiapan CPU mungkin mengalami lonjakan karena akan terjadi pertukaran.	Meningkatkan memori fisik. Untuk opsi lainnya, lihat Saran pemecahan masalah VMware.
Waktu pembuatan Nodepool habis.	Latensi baca/tulis VMDK yang tinggi. Periksa kondisi VM OOB untuk latensi baca dan tulis disk virtual. Menurut VMware, latensi total yang lebih besar dari 20 md menunjukkan adanya masalah.	Lihat Solusi VMware untuk masalah performa disk.

Mengambil foto status cluster

Jika gkectl diagnose cluster menemukan error, Anda harus mengambil status cluster dan memberikan informasinya kepada Google. Anda dapat melakukannya menggunakan perintah gkectl diagnose snapshot.

gkectl diagnose snapshot memiliki flag opsional, --config. Selain mengumpulkan informasi tentang cluster, flag ini mengumpulkan GKE pada file konfigurasi VMware yang digunakan untuk membuat atau mengupgrade cluster.

Merekam status cluster admin

Untuk merekam status cluster admin, jalankan perintah berikut, dengan --config bersifat opsional:

gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] --config

Outputnya mencakup daftar file dan nama file tarball:

Taking snapshot of admin cluster "[ADMIN_CLUSTER_NAME]"...
   Using default snapshot configuration...
   Setting up "[ADMIN_CLUSTER_NAME]" ssh key file...DONE
   Taking snapshots...
       commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system
       ...
       nodes/[ADMIN_CLUSTER_NODE]/commands/journalctl_-u_kubelet
       nodes/[ADMIN_CLUSTER_NODE]/files/var/log/startup.log
       ...
   Snapshot succeeded. Output saved in [TARBALL_FILE_NAME].tar.gz.

Untuk mengekstrak file tarball ke direktori, jalankan perintah berikut:

tar -zxf TARBALL_FILE_NAME --directory EXTRACTION_DIRECTORY_NAME

Untuk melihat daftar file yang dihasilkan oleh snapshot, jalankan perintah berikut:

cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY
ls kubectlCommands
ls nodes/NODE_NAME/commands
ls nodes/NODE_NAME/files

Untuk melihat detail operasi tertentu, buka salah satu file.

Menentukan kunci SSH untuk cluster admin

Saat Anda mendapatkan snapshot cluster admin, gkectl akan otomatis menemukan kunci SSH pribadi untuk cluster admin. Anda juga dapat menentukan kunci secara eksplisit menggunakan parameter --admin-ssh-key-path.

Ikuti petunjuk untuk Menggunakan SSH untuk terhubung ke node cluster guna mendownload kunci SSH.

Kemudian, di perintah gkectl diagnose snapshot, tetapkan --admin-ssh-key-path ke jalur file kunci yang didekode:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --admin-ssh-key-path=PATH_TO_DECODED_KEY

Merekam status cluster pengguna

Untuk merekam status cluster pengguna, jalankan perintah berikut:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

Outputnya mencakup daftar file dan nama file tarball:

Taking snapshot of user cluster "[USER_CLUSTER_NAME]"...
Using default snapshot configuration...
Setting up "[USER_CLUSTER_NAME]" ssh key file...DONE
    commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user
    ...
    commands/kubectl_get_pods_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    commands/kubectl_get_deployments_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system
    ...
    nodes/[USER_CLUSTER_NODE]/commands/journalctl_-u_kubelet
    nodes/[USER_CLUSTER_NODE]/files/var/log/startup.log
    ...
Snapshot succeeded. Output saved in [FILENAME].tar.gz.

Skenario snapshot

Perintah gkectl diagnose snapshot mendukung dua skenario untuk cluster pengguna. Untuk menentukan skenario, gunakan flag --scenario. Daftar berikut menunjukkan nilai yang memungkinkan:

Sistem(default): Mengumpulkan snapshot dengan log di namespace sistem yang didukung.
Semua: Mengumpulkan snapshot dengan log di semua namespace, termasuk namespace yang ditentukan pengguna

Contoh berikut menunjukkan beberapa kemungkinannya.

Untuk membuat snapshot cluster admin, Anda tidak perlu menentukan skenario:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Untuk membuat snapshot cluster pengguna menggunakan skenario system:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=system

Untuk membuat snapshot cluster pengguna menggunakan skenario all:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=all

Menggunakan `--log-since` untuk membatasi snapshot

Anda dapat menggunakan flag --log-since untuk membatasi pengumpulan log hingga jangka waktu terbaru. Misalnya, Anda hanya dapat mengumpulkan log dari dua hari terakhir atau tiga jam terakhir. Secara default, diagnose snapshot mengumpulkan semua log.

Untuk membatasi jangka waktu pengumpulan log:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=CLUSTER_NAME \
    --scenario=system \
    --log-since=DURATION

Ganti DURATION dengan nilai waktu seperti 120m atau 48h.

Catatan:

Tanda --log-since hanya didukung untuk log kubectl dan journalctl.
Command flag seperti --log-since tidak diizinkan dalam konfigurasi snapshot yang disesuaikan.

Melakukan uji coba untuk snapshot

Anda dapat menggunakan tanda --dry-run untuk menampilkan tindakan yang akan dilakukan dan konfigurasi snapshot.

Untuk menjalankan uji coba pada cluster admin, masukkan perintah berikut:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=ADMIN_CLUSTER_NAME \
    --dry-run

Untuk menjalankan uji coba pada cluster pengguna, masukkan perintah berikut:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --dry-run

Menggunakan konfigurasi snapshot

Jika kedua skenario ini (--scenario system atau all) tidak memenuhi kebutuhan Anda, Anda dapat membuat snapshot yang disesuaikan dengan meneruskan file konfigurasi snapshot menggunakan tanda --snapshot-config:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --snapshot-config=SNAPSHOT_CONFIG_FILE

Membuat konfigurasi snapshot

Anda dapat membuat konfigurasi snapshot untuk skenario tertentu dengan meneruskan flag --scenario dan --dry-run. Misalnya, untuk melihat konfigurasi snapshot untuk skenario default (system) dari cluster pengguna, masukkan perintah berikut:

gkectl diagnose snapshot \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME \
    --scenario=system
    --dry-run

Outputnya mirip dengan hal berikut ini:

numOfParallelThreads: 10
excludeWords:
- password
kubectlCommands:
- commands:
  - kubectl get clusters -o wide
  - kubectl get machines -o wide
  - kubectl get clusters -o yaml
  - kubectl get machines -o yaml
  - kubectl describe clusters
  - kubectl describe machines
  namespaces:
  - default
- commands:
  - kubectl version
  - kubectl cluster-info
  - kubectl get nodes -o wide
  - kubectl get nodes -o yaml
  - kubectl describe nodes
  namespaces: []
- commands:
  - kubectl get pods -o wide
  - kubectl get deployments -o wide
  - kubectl get daemonsets -o wide
  - kubectl get statefulsets -o wide
  - kubectl get replicasets -o wide
  - kubectl get services -o wide
  - kubectl get jobs -o wide
  - kubectl get cronjobs -o wide
  - kubectl get endpoints -o wide
  - kubectl get configmaps -o wide
  - kubectl get pods -o yaml
  - kubectl get deployments -o yaml
  - kubectl get daemonsets -o yaml
  - kubectl get statefulsets -o yaml
  - kubectl get replicasets -o yaml
  - kubectl get services -o yaml
  - kubectl get jobs -o yaml
  - kubectl get cronjobs -o yaml
  - kubectl get endpoints -o yaml
  - kubectl get configmaps -o yaml
  - kubectl describe pods
  - kubectl describe deployments
  - kubectl describe daemonsets
  - kubectl describe statefulsets
  - kubectl describe replicasets
  - kubectl describe services
  - kubectl describe jobs
  - kubectl describe cronjobs
  - kubectl describe endpoints
  - kubectl describe configmaps
  namespaces:
  - kube-system
  - gke-system
  - gke-connect.*
prometheusRequests: []
nodeCommands:
- nodes: []
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - sudo iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1
  - sudo docker ps -a
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - sudo conntrack --count
nodeFiles:
- nodes: []
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/nf_conntrack_max
seesawCommands: []
seesawFiles: []
nodeCollectors:
- nodes: []
f5:
  enabled: true
vCenter:
  enabled: true

numOfParallelThreads: Jumlah thread paralel yang digunakan untuk mengambil snapshot.
excludeWords: Daftar kata yang akan dikecualikan dari snapshot (tidak peka huruf besar/kecil). Baris yang berisi kata-kata tersebut dihapus dari hasil snapshot. “{i>password<i}” selalu dikecualikan, baik Anda menentukannya atau tidak.
kubectlCommands: Daftar perintah kubectl yang akan dijalankan. Hasilnya akan disimpan. Perintah dijalankan pada namespace yang sesuai. Untuk perintah kubectl logs, semua Pod dan container dalam namespace yang terkait akan ditambahkan secara otomatis. Ekspresi reguler didukung untuk menentukan namespace. Jika Anda tidak menentukan namespace, namespace default akan digunakan.
nodeCommands: Daftar perintah untuk dijalankan pada node yang sesuai. Hasilnya disimpan. Jika node tidak ditentukan, semua node dalam cluster target akan dipertimbangkan.
nodeFiles: Daftar file yang akan dikumpulkan dari node terkait. File akan disimpan. Jika node tidak ditentukan, semua node dalam cluster target akan dipertimbangkan.
seesawCommands: Daftar perintah yang akan dijalankan untuk mengumpulkan informasi load balancer Seesaw. Hasilnya akan disimpan jika cluster menggunakan load balancer Seesaw.
seesawFiles: Daftar file yang akan dikumpulkan untuk load balancer Seesaw.
nodeCollectors: Kolektor yang menjalankan node Cilium untuk mengumpulkan informasi eBPF.
f5: Flag untuk memungkinkan pengumpulan informasi yang terkait dengan load balancer BIG-IP F5.
vCenter: Tanda untuk memungkinkan pengumpulan informasi yang terkait dengan vCenter.
prometheusRequests: Daftar permintaan Prometheus. Hasilnya disimpan.

Mengupload snapshot ke bucket Cloud Storage

Untuk mempermudah pencatatan, analisis, dan penyimpanan, Anda dapat mengupload semua snapshot cluster tertentu ke bucket Cloud Storage. Hal ini sangat membantu jika Anda memerlukan bantuan dari Cloud Customer Care.

Sebelum menjalankan perintah tersebut, pastikan Anda telah memenuhi persyaratan penyiapan ini.

Aktifkan storage.googleapis.com di project host armada. Meskipun Anda dapat menggunakan project berbeda, project host fleet direkomendasikan.
```
gcloud services enable --project=FLEET_HOST_PROJECT_ID storage.googleapis.com
```
Berikan roles/storage.admin ke akun layanan di project induknya, dan teruskan file kunci JSON akun layanan menggunakan parameter --service-account-key-file. Anda dapat menggunakan akun layanan apa pun, tetapi sebaiknya gunakan akun layanan register koneksi. Lihat Akun layanan untuk mengetahui informasi selengkapnya.

Catatan: Jika Anda menggunakan flag --share-with pada perintah gkectl diagnose snapshot, persyaratan penyiapan ini tidak diperlukan. Jika Anda ingin membagikan akses ke snapshot kepada Dukungan Google secara manual, gunakan perintah berikut dan jangan gunakan flag --share-with saat Anda membuat snapshot.
```
gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \
  --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \
  --role "roles/storage.admin"
```
Ganti CONNECT_REGISTER_SERVICE_ACCOUNT dengan akun layanan connect register.

Setelah memenuhi persyaratan ini, Anda kini dapat mengupload snapshot dengan perintah ini:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name CLUSTER_NAME \
    --upload \
    --share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT

Flag --share-with dapat menerima daftar nama akun layanan. Ganti GOOGLE_SUPPORT_SERVICE_ACCOUNT dengan akun layanan dukungan Google yang disediakan oleh dukungan Google, beserta akun layanan lainnya yang disediakan oleh dukungan Google. Jika Anda menggunakan tanda --upload, perintah akan menelusuri project Anda untuk menemukan bucket penyimpanan yang memiliki nama yang dimulai dengan "anthos-snapshot-". Jika bucket tersebut keluar, perintah akan mengupload snapshot ke bucket tersebut. Jika tidak menemukan bucket dengan nama yang cocok, perintah akan membuat bucket baru dengan nama anthos-snapshot-UUID, dengan UUID sebagai ID unik universal 32 digit.

Saat menggunakan tanda --share-with, Anda tidak perlu membagikan akses ke bucket secara manual kepada dukungan Google Cloud.

Contoh output:

Using "system" snapshot configuration...
Taking snapshot of user cluster CLUSTER_NAME...
Setting up CLUSTER_NAME ssh key...DONE
Using the gke-connect register service account key...
Setting up Google Cloud Storage bucket for uploading the snapshot...DONE
Taking snapshots in 10 thread(s)...
   ...
Snapshot succeeded.
Snapshots saved in "SNAPSHOT_FILE_PATH".
Uploading snapshot to Google Cloud Storage......  DONE
Uploaded the snapshot successfully to gs://anthos-snapshot-a4b17874-7979-4b6a-a76d-e49446290282/xSNAPSHOT_FILE_NAME.
Shared successfully with service accounts:
GOOGLE_SUPPORT_SERVICE_ACCOUNT

Masalah umum

`BundleUnexpectedDiff` error

Resource Kubernetes Cluster API yang dikelola oleh GKE pada paket VMware mungkin tidak sengaja dimodifikasi sehingga dapat menyebabkan kegagalan komponen sistem, atau upgrade cluster atau kegagalan update.

Dari GKE di VMware versi 1.13, onprem-user-cluster-controller akan memeriksa status objek secara berkala, dan melaporkan perbedaan yang tidak terduga dari status yang diinginkan melalui log dan peristiwa. Objek ini mencakup bidang kontrol cluster pengguna dan add-on seperti Services dan DaemonSet.

Berikut adalah contoh peristiwa:

 Type     Reason                 Age    From                              Message
 ----     ------                 ----   ----                              -------
 Warning  BundleUnexpectedDiff   13m    onpremusercluster/ci-bundle-diff  Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.

Berikut adalah contoh log yang dibuat oleh onprem-user-cluster-controller:

2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252       1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff:   map[string]string{
2022-08-06T02:54:42.701376406Z -    "mesh": (
2022-08-06T02:54:42.701381190Z -        """
2022-08-06T02:54:42.701385438Z -        defaultConfig:
2022-08-06T02:54:42.701389350Z -          discoveryAddress: istiod.gke-system.svc:15012
...
2022-08-06T02:54:42.701449954Z -        """
2022-08-06T02:54:42.701453099Z -    ),
2022-08-06T02:54:42.701456286Z -    "meshNetworks": "networks: {}",
2022-08-06T02:54:42.701459304Z +    "test-key":     "test-data",
2022-08-06T02:54:42.701462434Z   }

Peristiwa dan log tidak akan memblokir operasi cluster. Objek yang memiliki perbedaan yang tidak terduga dari status yang diinginkan akan ditimpa di upgrade cluster berikutnya.

Mendiagnosis masalah cluster

Ringkasan

gkectl diagnose cluster

gkectl diagnose snapshot

Dapatkan bantuan

Mendiagnosis cluster admin

Mendiagnosis cluster pengguna

Memecahkan masalah cluster yang didiagnosis

Mengambil foto status cluster

Merekam status cluster admin

Menentukan kunci SSH untuk cluster admin

Merekam status cluster pengguna

Skenario snapshot

Menggunakan --log-since untuk membatasi snapshot

Melakukan uji coba untuk snapshot

Menggunakan konfigurasi snapshot

Membuat konfigurasi snapshot

Mengupload snapshot ke bucket Cloud Storage

Masalah umum

BundleUnexpectedDiff error

`gkectl diagnose cluster`

`gkectl diagnose snapshot`

Menggunakan `--log-since` untuk membatasi snapshot

`BundleUnexpectedDiff` error