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 cluster bootstrap sementara. Setelah penginstalan berhasil, Google Distributed Cloud akan menghapus cluster bootstrap, sehingga Anda hanya memiliki cluster admin dan cluster pengguna. Umumnya, Anda tidak perlu 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

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

Ganti POD_NAME dengan 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 bash
```
Perintah ini membuka terminal di dalam penampung 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 akan mengambil snapshot eksternal cluster bootstrap. Snapshot cluster bootstrap ini mirip dengan snapshot yang diambil dengan menjalankan perintah gkectl diagnose snapshot di cluster admin, tetapi prosesnya dipicu secara otomatis. 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.

Ringkasan 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

VM tidak dimulai setelah control plane admin dimulai

Jika VM gagal dimulai setelah control plane admin dimulai, Anda dapat menyelidiki masalahnya 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-controllers

Lihat log dari vsphere-controller-manager. Mulai dengan menentukan Pod, tetapi tidak ada penampung:

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

Output ini memberi tahu Anda bahwa Anda harus menentukan penampung, dan memberikan nama penampung di Pod. Contoh:

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

Pilih penampung, lalu lihat lognya:

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

Jumlah alamat IP yang dialokasikan cukup, tetapi Mesin gagal mendaftar ke cluster

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

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

Cluster jenis tidak dihapus

Saat Anda membuat cluster admin, cluster kind (juga disebut cluster bootstrap) akan dibuat sebagai bagian dari proses. Setelah operasi cluster admin selesai, cluster kind akan otomatis dihapus.

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-plane

Dapatkan ID proses containerd-shim:

sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'

Menghentikan proses:
```
sudo kill -9 PROCESS_ID
```

Masalah upgrade cluster

Bagian berikut memberikan tips tentang cara menyelesaikan masalah yang mungkin Anda hadapi selama upgrade cluster.

Me-roll back node pool setelah upgrade

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

Melakukan rollback pada node pool yang dipilih didukung untuk node pool Ubuntu dan COS, tetapi tidak untuk node pool Windows.

Versi node pool dapat sama atau satu versi minor yang lebih lama dari versi panel kontrol cluster pengguna. Misalnya, jika control plane berada di versi 1.14, node pool dapat berada di versi 1.14 atau 1.13.

Melihat versi kumpulan node yang tersedia

Misalnya, Anda baru-baru ini mengupgrade cluster pengguna node pekerja dan panel kontrol dari versi 1.13.1-gke.35 ke versi 1.14.0, dan Anda menemukan masalah pada node pekerja yang diupgrade. Jadi, Anda memutuskan untuk melakukan rollback satu atau beberapa node pool ke versi yang sebelumnya Anda jalankan: 1.13.1-gke.35. Sebelum dapat memulai rollback, Anda harus 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 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

Me-roll back versi node pool

Anda dapat melakukan rollback versi node pool satu node pool dalam satu waktu, atau Anda dapat melakukan rollback beberapa node pool dalam satu langkah.

Untuk melakukan roll back versi node pool, selesaikan langkah-langkah berikut:

Dalam file konfigurasi cluster pengguna, di satu atau beberapa node pool, tetapkan nilai gkeOnPremVersion ke versi sebelumnya. Contoh berikut menunjukkan cara melakukan rollback 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 melakukan rollback node pool:

gkectl update cluster --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Verifikasi bahwa rollback berhasil:

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

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

Mengupgrade ke versi patch baru

Anda dapat mengupgrade semua node pool 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:
1. Tetapkan nilai gkeOnPremVersion ke versi patch baru. Contoh ini menggunakan 1.14.1-gke.x.
2. Untuk setiap node pool, hapus kolom gkeOnPremVersion, atau tetapkan ke string kosong. Jika tidak ada versi yang ditentukan untuk node pool, versi untuk node pool 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 prepare dan gkectl upgrade cluster seperti 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_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 cluster admin atau pengguna, dan operasi tersebut gagal, Google Distributed Cloud akan otomatis menjalankan perintah gkectl diagnose cluster di cluster.

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

Proses upgrade macet

Di balik layar, Google Distributed Cloud 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 Google Distributed Cloud versi 1.13, Anda dapat memeriksa kegagalan melalui peristiwa Pod Kubernetes.

Temukan nama Komputer:

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

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, dan hapus dari cluster sebelum mencoba upgrade. Kemudian, Anda dapat menambahkan kembali PDB setelah upgrade selesai.

Menghapus 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 otomatis selama upgrade, yang berarti perubahan ini tidak akan berlaku selama dan setelah upgrade.

Saat mengupgrade cluster pengguna ke versi 1.28 atau yang lebih baru, kami memvalidasi semua perubahan yang dilakukan 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 akan diabaikan secara otomatis dan tidak akan diterapkan setelah upgrade.

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 perlu mengabaikan error ini, ada solusi berikut:

Kembalikan perubahan yang dicoba, lalu jalankan ulang upgrade. Misalnya, dalam skenario sebelumnya, Anda akan mengembalikan perubahan yang dilakukan pada konfigurasi AutoRepair, lalu menjalankan kembali gkectl upgrade.
Atau, Anda dapat membuat file konfigurasi yang cocok dengan status cluster saat ini dengan menjalankan gkectl get-config, memperbarui kolom gkeOnPremVersion untuk cluster dan node pool di file konfigurasi, lalu jalankan kembali gkectl upgrade.

Men-debug masalah F5 BIG-IP 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, kecuali bahwa 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 terkait vSphere. Misalnya, Anda dapat mengonfirmasi izin dan akses untuk akun pengguna vCenter, dan Anda dapat mengumpulkan log vSphere.

Membuat ulang file kubeconfig cluster pengguna yang hilang

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

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, seperti setelah dihapus.

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

Menentukan Variabel Lingkungan:

Mulai 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 file kubeconfig untuk cluster admin Anda.
- USER_CONTROLPLANEVIP: controlPlaneVIP cluster pengguna. Ini dapat diambil dari file manifes cluster pengguna.

Buat File Kubeconfig:

Jalankan perintah berikut untuk membuat file kubeconfig 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 file kubeconfig baru untuk cluster pengguna Anda.

Langkah selanjutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.