Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Memecahkan masalah pembuatan atau upgrade cluster

Halaman ini menunjukkan cara menyelidiki masalah terkait pembuatan dan upgrade cluster di Google Distributed Cloud (khusus software) untuk VMware.

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 bootstrap sementara . Setelah penginstalan berhasil, Google Distributed Cloud akan menghapus cluster bootstrap, menyisakan cluster admin dan cluster pengguna Anda. 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 Anda men-debug masalah.

Jika Anda meneruskan --cleanup-external-cluster=false ke gkectl create cluster, cluster bootstrap tidak dihapus, dan Anda dapat menggunakan bootstrap cluster 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-system

Lihat log untuk Pod:

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

Ganti POD_NAME dengan nama Pod yang ingin dilihat.

Untuk mendapatkan log dari cluster bootstrap secara langsung, jalankan perintah berikut selama pembuatan, update, dan upgrade cluster:
```
docker exec -it gkectl-control-plane bash
```
Perintah ini 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

Memeriksa snapshot cluster bootstrap

Jika Anda mencoba membuat atau mengupgrade cluster admin, dan operasi tersebut gagal, Google Distributed Cloud mengambil snapshot eksternal dari cluster bootstrap. Snapshot cluster bootstrap ini mirip dengan snapshot yang diambil dengan menjalankan gkectl diagnose snapshot pada cluster admin, tetapi proses itu terpicu secara otomatis. Snapshot cluster bootstrap berisi informasi proses debug penting untuk pembuatan cluster admin dan proses upgrade. Anda dapat memberikan ringkasan ini ke Cloud Customer Care jika diperlukan.

Snapshot eksternal mencakup log Pod dari onprem-admin-cluster-controller yang dapat Anda lihat untuk men-debug pembuatan cluster atau masalah 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 ini dengan memeriksa log dari pengontrol Cluster API Pod di cluster admin:

Cari nama Pod pengontrol Cluster API:

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

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

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

Outputnya memberi tahu bahwa Anda harus menentukan container, dan memberi Anda nama-nama container di dalam 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, IP alamat yang Anda tentukan untuk sebuah mesin digunakan untuk load balancer.

Untuk mengatasi masalah ini, perbarui file blok IP cluster yang diperlukan agar komputer 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 selama upgrade cluster.

Melakukan roll back kumpulan node setelah upgrade

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

Me-roll back node pool yang dipilih didukung untuk node pool Ubuntu dan COS, tetapi tidak untuk node pool Windows.

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

Melihat versi node pool yang tersedia

Misalkan Anda baru-baru ini mengupgrade cluster pengguna node pekerja 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 {i>rollback<i} satu atau beberapa kumpulan node ke versi yang sebelumnya Anda jalankan: 1.13.1-gke.35. Sebelum dapat memulai rollback, Anda perlu memverifikasi 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 node kolam renang. 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, atau Anda dapat melakukan roll back kembali ke 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, setel sebesar gkeOnPremVersion ke 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_KUBECONFIG

Pastikan rollback berhasil:

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Output berikut menunjukkan bahwa pool-1 telah 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 patch baru . Hal ini mungkin membantu jika Anda melakukan roll back ke versi sebelumnya dan ingin untuk meningkatkan ke versi yang menyertakan perbaikan.

Untuk mengupgrade ke versi baru, selesaikan langkah-langkah berikut:

Buat perubahan berikut di file konfigurasi cluster pengguna Anda:
1. Setel nilai gkeOnPremVersion ke versi patch baru. Contoh ini menggunakan 1.14.1-gke.x.
2. Untuk setiap kumpulan node, hapus kolom gkeOnPremVersion, atau tetapkan ke {i>string<i} kosong. Ketika tidak ada versi yang ditentukan untuk kumpulan node, versi untuk kumpulan node tersebut secara default disetel ke versi yang ditentukan untuk .
  
  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 prepare dan gkectl upgrade cluster seperti yang dijelaskan di Mengupgrade Google Distributed Cloud.

Verifikasi versi cluster baru, dan lihat versi yang tersedia untuk {i>rollback<i}:

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Outputnya 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 otomatis menjalankan gkectl diagnose cluster pada cluster.

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

Proses upgrade menjadi macet

Di balik layar, Google Distributed Cloud menggunakan Kubernetes drain perintah selama proses 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-namespaces

Periksa apakah ada error menggunakan perintah kubectl describe machine:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Outputnya 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 melakukan 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 sebelumnya, perubahan pada sebagian besar isian diabaikan secara diam-diam selama upgrade, yang berarti perubahan ini tidak memerlukan selama dan setelah upgrade.

Saat mengupgrade cluster pengguna ke versi 1.28 atau yang lebih baru, kami memvalidasi semua perubahan yang dibuat di file konfigurasi dan menampilkan kesalahan untuk perubahan yang tidak didukung, alih-alih hanya mengabaikannya. Fitur ini hanya untuk cluster pengguna. Saat mengupgrade cluster admin, perubahan pada sebagian besar kolom otomatis diabaikan dan tidak akan berlaku setelah upgrade.

Misalnya, jika Anda mencoba menonaktifkan perbaikan otomatis node ketika mengupgrade cluster pengguna ke 1.28, upgrade gagal dengan error berikut pesan:

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, di kolom skenario sebelumnya, Anda akan mengembalikan perubahan yang dibuat pada AutoRepair konfigurasi, lalu jalankan kembali gkectl upgrade.
Atau, Anda dapat membuat file konfigurasi yang cocok dengan status cluster dengan menjalankan gkectl get-config, perbarui kolom gkeOnPremVersion untuk cluster dan kumpulan node di file konfigurasi, lalu jalankan kembali gkectl upgrade.

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

Setelah penginstalan, Google Distributed Cloud membuat file kubeconfig bernama internal-cluster-kubeconfig-debug di direktori beranda admin Anda Infrastruktur Cloud. File kubeconfig ini sama dengan file cluster admin Anda file kubeconfig, hanya saja file ini mengarah langsung ke kontrol cluster admin node bidang, tempat server Kubernetes API berjalan. Anda dapat menggunakan internal-cluster-kubeconfig-debug untuk men-debug masalah F5 BIG-IP.

Men-debug masalah dengan vSphere

Anda dapat menggunakan govc ke menyelidiki masalah dengan vSphere. Misalnya, Anda dapat mengkonfirmasi izin dan akses untuk akun pengguna vCenter Anda, dan Anda dapat mengumpulkan log vSphere.

Membuat ulang file kubeconfig cluster pengguna yang tidak ada

Anda mungkin ingin membuat ulang file kubeconfig cluster pengguna sebagai berikut situasi:

Jika Anda mencoba membuat cluster pengguna, dan operasi pembuatannya gagal, dan Anda menginginkan file kubeconfig cluster penggunanya.
Jika file kubeconfig cluster pengguna tidak ada, misalnya setelah dihapus.

Untuk membuat file kubeconfig baru untuk cluster pengguna Anda, jalankan langkah-langkah berikut:

Menentukan Variabel Lingkungan:

Mulailah dengan menetapkan variabel lingkungan berikut dengan nilai yang sesuai:
```
USER_CONTROLPLANEVIP=USER_CONTROLPLANEVIP
USER_CLUSTER_NAME=USER_CLUSTER_NAME
ADMIN_CLUSTER_KUBECONFIG=PATH_TO_ADMIN_KUBECONFIG
KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets -n $USER_CLUSTER_NAME | grep ^admin | cut -d' ' -f1 | head -n 1)
```
Ganti kode berikut:
- ADMIN_CLUSTER_KUBECONFIG: jalur kubeconfig untuk cluster admin Anda.
- USER_CONTROLPLANEVIP: controlPlaneVIP pengguna . Parameter ini dapat diambil dari file manifes cluster pengguna.

Buat File Kubeconfig:

Jalankan perintah berikut untuk membuat file kubeconfig yang baru:

kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets $KUBECONFIG_SECRET_NAME \
 -n $USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}'  | base64 -d | \
 sed -r "s/ kube-apiserver.*local\./${USER_CONTROLPLANEVIP}/" \
 > USER_CLUSTER_KUBECONFIG

Ganti :

USER_CLUSTER_KUBECONFIG: nama baru kubeconfig untuk cluster pengguna Anda.

Langkah selanjutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.