Memecahkan masalah pembuatan atau upgrade cluster

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

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

  1. Temukan nama Pod yang berjalan di namespace kube-system:

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

  2. 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.

  3. 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 akan membuka terminal di dalam container gkectl-control-plane yang berjalan di cluster bootstrap.

  4. 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 dari 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 yang penting untuk proses pembuatan dan upgrade cluster admin.

Snapshot eksternal ini diupload secara otomatis ke bucket Cloud Storage untuk project Google Cloud Anda di folder /home/ubuntu. Snapshot hanya diambil saat operasi pembuatan atau upgrade cluster gagal. Anda dapat memberikan snapshot ini ke Cloud Customer Care jika diperlukan. Jika operasi cluster berhasil, tidak ada snapshot yang diupload.

Snapshot eksternal mencakup 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

Snapshot eksternal juga menyertakan deskripsi berbagai resource kustom. Misalnya, snapshot menyertakan deskripsi resource kustom Validasi, yang berisi informasi status dan peristiwa mendetail untuk operasi yang gagal:

kubectl describe validations.onprem.cluster.gke.io \
    --kubeconfig /home/ubuntu/.kube/kind-config-gkectl \
    --request-timeout 30s \
    --namespace kube-node-lease

VM tidak dimulai setelah bidang kontrol admin dimulai

Jika VM gagal dimulai setelah bidang kontrol admin dimulai, Anda dapat menyelidiki masalah tersebut dengan memeriksa log dari Pod pengontrol Cluster API di cluster admin:

  1. Temukan nama Pod pengontrol Cluster API:

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

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

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

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

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

  3. Pilih container, dan lihat log-nya:

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

Jumlah alamat IP yang dialokasikan memadai, tetapi Mesin gagal mendaftar ke 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 agar alamat mesin tidak bertentangan dengan alamat yang ditentukan dalam file konfigurasi cluster atau file blok IP Seesaw

Cluster Kind 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:

  1. Dapatkan ID container kind:

    docker inspect --format="{{.Id}}" gkectl-control-plane

  2. Dapatkan ID proses containerd-shim:

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

  3. Hentikan proses:

    sudo kill -9 PROCESS_ID

Masalah upgrade cluster

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

Me-roll back node pool setelah upgrade

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

Rollback 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 lebih lama dari versi bidang kontrol cluster pengguna. Misalnya, jika bidang kontrol berada di versi 1.14, node pool dapat berada di versi 1.14 atau 1.13.

Melihat versi node pool yang tersedia

Misalnya, Anda baru saja mengupgrade worker node 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 me-roll back satu atau beberapa node pool 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 akan menampilkan versi saat ini dan versi sebelumnya untuk setiap node pool. 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 me-roll back versi node pool satu per satu, atau me-roll back beberapa node pool dalam satu langkah.

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

  1. Dalam file konfigurasi cluster pengguna, di satu atau beberapa node pool, tetapkan nilai 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
  ...

  2. Update cluster untuk me-roll back node pool:

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

  3. Pastikan 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:

  1. Buat perubahan berikut dalam file konfigurasi cluster pengguna Anda:

    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: ""

  2. Jalankan gkectl prepare dan gkectl upgrade cluster seperti yang dijelaskan dalam Mengupgrade Google Distributed Cloud.

  3. 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.

  1. Temukan nama Mesin:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

  2. 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.

  3. 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 melanjutkan 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 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 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
    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, berikut beberapa solusinya:

  • Urungkan perubahan yang dicoba, lalu jalankan kembali upgrade. Misalnya, dalam skenario sebelumnya, Anda akan mengembalikan perubahan yang dilakukan pada konfigurasi AutoRepair, lalu menjalankan ulang 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 dalam file konfigurasi, lalu menjalankan ulang gkectl upgrade.

Masalah: OS Image tidak ditemukan setelah gkectl prepare

Setelah menjalankan perintah gkectl prepare, lalu mencoba mengupgrade cluster pengguna dengan gkectl upgrade cluster, Anda mungkin mengalami error seperti berikut:

[FAILURE] User OS images exist: OS images [gke-on-prem-ubuntu-VERSION] don't exist, please run `gkectl prepare` to upload OS images.

Error ini dapat terjadi jika cluster admin dan cluster pengguna dikonfigurasi untuk menggunakan folder vSphere yang berbeda. Secara default, perintah gkectl prepare mengupload OS image ke folder cluster admin. Untuk mengupload image ke folder cluster pengguna, gunakan flag --user-cluster-config seperti yang ditunjukkan dalam perintah berikut:

  gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-VERSION-full.tgz \
    --user-cluster-config USER_CLUSTER_CONFIG

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 pada vSphere

Anda dapat menggunakan govc untuk menyelidiki masalah pada 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 pengguna.
  • Jika file kubeconfig cluster pengguna tidak ada, misalnya setelah dihapus.

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

  1. 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 file kubeconfig untuk cluster admin Anda.
    • USER_CONTROLPLANEVIP: controlPlaneVIP cluster pengguna. Hal ini dapat diambil dari file manifes cluster pengguna.

  2. Membuat 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 berikutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Anda juga dapat melihat Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang referensi dukungan, termasuk referensi berikut:

  • Persyaratan untuk membuka kasus dukungan.
  • Alat untuk membantu Anda memecahkan masalah, seperti log dan metrik.
  • Komponen, versi, dan fitur Google Distributed Cloud untuk VMware (khusus software) yang didukung.