Masalah umum Google Distributed Cloud (khusus software) untuk VMware

Secret tetap dienkripsi setelah menonaktifkan enkripsi secret selalu aktif

Setelah menonaktifkan enkripsi secret selalu aktif dengan gkectl update cluster, secret tetap disimpan di etcd dengan enkripsi. Masalah ini hanya berlaku untuk cluster pengguna kubeception. Jika cluster Anda menggunakan Controlplane V2, Anda tidak terpengaruh oleh masalah ini.

Untuk memeriksa apakah secret masih dienkripsi, jalankan perintah berikut, yang mengambil secret default/private-registry-creds yang disimpan di etcd:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    exec -it -n USER_CLUSTER_NAME kube-etcd-0 -c kube-etcd -- \
    /bin/sh -ec "export ETCDCTL_API=3; etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etcd.local.config/certificates/etcdCA.crt \
    --cert=/etcd.local.config/certificates/etcd.crt \
    --key=/etcd.local.config/certificates/etcd.key \
    get /registry/secrets/default/private-registry-creds" | hexdump -C

Jika secret disimpan dengan enkripsi, output-nya akan terlihat seperti berikut:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 3a 65 6e  63 3a 6b 6d 73 3a 76 31  |..k8s:enc:kms:v1|
00000040  3a 67 65 6e 65 72 61 74  65 64 2d 6b 65 79 2d 6b  |:generated-key-k|
00000050  6d 73 2d 70 6c 75 67 69  6e 2d 31 3a 00 89 65 79  |ms-plugin-1:..ey|
00000060  4a 68 62 47 63 69 4f 69  4a 6b 61 58 49 69 4c 43  |JhbGciOiJkaXIiLC|
...

Jika secret tidak disimpan dengan enkripsi, output-nya akan terlihat seperti berikut:

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 00 0d 0a  0c 0d 0a 02 76 31 12 06  |..k8s.......v1..|
00000040  53 65 63 72 65 74 12 83  47 0d 0a b0 2d 0d 0a 16  |Secret..G...-...|
00000050  70 72 69 76 61 74 65 2d  72 65 67 69 73 74 72 79  |private-registry|
00000060  2d 63 72 65 64 73 12 00  1a 07 64 65 66 61 75 6c  |-creds....defaul|
...

Solusi:

1. Lakukan update berkelanjutan pada DaemonSet tertentu, sebagai berikut:

       kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
         rollout restart statefulsets kube-apiserver \
         -n USER_CLUSTER_NAME
       

2. Dapatkan manifes semua secret di cluster pengguna, dalam format YAML:

       kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
         get secrets -A -o yaml > SECRETS_MANIFEST.yaml
       

3. Terapkan kembali semua secret di cluster pengguna sehingga semua secret disimpan di etcd sebagai teks biasa:

       kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
         apply -f SECRETS_MANIFEST.yaml
       

File user-cluster.yaml yang dihasilkan tidak memiliki kolom hostgroups

File konfigurasi cluster pengguna, user-cluster.yaml, yang dibuat oleh perintah gkectl get-config tidak memiliki kolom hostgroups di bagian nodePools. Perintah gkectl get-config menghasilkan file user-cluster.yaml berdasarkan konten resource kustom OnPremUserCluster. Namun, kolom nodePools[i].vsphere.hostgroups ada di resource kustom OnPremNodePool dan tidak disalin ke file user-cluster.yaml saat Anda menjalankan gkectl get-config.

Solusi

Untuk mengatasi masalah ini, tambahkan kolom nodePools[i].vsphere.hostgroups secara manual ke file user-cluster.yaml. File yang diedit akan terlihat mirip dengan contoh berikut:

apiVersion: v1
kind: UserCluster
...
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
  replicas: 3
  vsphere:
    hostgroups:
    - "hostgroup-1"
...

Anda dapat menggunakan file konfigurasi cluster pengguna yang telah diedit untuk mengupdate cluster pengguna tanpa memicu error dan kolom hostgroups dipertahankan.

Ingress gabungan tidak kompatibel dengan resource gateway.networking.k8s.io

Pod Istiod dari ingress gabungan tidak dapat siap jika gateway.networking.k8s.io resource diinstal ke dalam cluster pengguna. Pesan error contoh berikut dapat ditemukan di log pod:

    failed to list *v1beta1.Gateway: gateways.gateway.networking.k8s.io is forbidden: User \"system:serviceaccount:gke-system:istiod-service-account\" cannot list resource \"gateways\" in API group \"gateway.networking.k8s.io\" at the cluster scope"
    

Solusi:

Terapkan ClusterRole dan ClusterRoleBinding berikut ke cluster pengguna Anda:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: istiod-gateway
rules:
- apiGroups:
  - 'gateway.networking.k8s.io'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: istiod-gateway-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istiod-gateway
subjects:
- kind: ServiceAccount
  name: istiod-service-account
  namespace: gke-system
    

Node bidang kontrol cluster admin terus melakukan booting ulang setelah menjalankan gkectl create admin

Jika nama host di kolom ipblocks berisi huruf besar, node panel kontrol cluster admin mungkin berulang kali melakukan reboot.

Solusi:

Gunakan hanya nama host huruf kecil.

Runtime: out of memory "error" setelah menjalankan gkeadm create atau upgrade

Saat membuat atau mengupgrade workstation admin dengan perintah gkeadm, , Anda mungkin mendapatkan error OOM saat memverifikasi image OS yang didownload.

Misalnya,

Downloading OS image
"gs://gke-on-prem-release/admin-appliance/1.30.400-gke.133/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova"...

[==================================================>] 10.7GB/10.7GB

Image saved to
/anthos/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova

Verifying image gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova...
|

runtime: out of memory

Solusi:

Upgrade cluster admin non-HA macet di Creating or updating cluster control plane workloads

Saat mengupgrade cluster admin non-HA, upgrade mungkin macet di Creating or updating cluster control plane workloads.

Masalah ini terjadi jika di VM master admin, ip a | grep cali menampilkan hasil yang tidak kosong.

Misalnya,

ubuntu@abf8a975479b-qual-342-0afd1d9c ~ $ ip a | grep cali
4: cali2251589245f@if3:  mtu 1500 qdisc noqueue state UP group default

Solusi:

1. Perbaiki master admin:

   gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
       --config=ADMIN_CONFIG_FILE \
       --skip-validation
   

2. Pilih template VM 1.30 jika Anda melihat perintah seperti contoh berikut:

   Please select the control plane VM template to be used for re-creating the
   admin cluster's control plane VM.
   

3. Lanjutkan upgrade:

   gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG \
       --config ADMIN_CONFIG_FILE
   

Kolom isControlPlane yang berlebihan dalam file konfigurasi cluster di bagian network.controlPlaneIPBlock

File konfigurasi cluster yang dibuat oleh gkectl create-config di 1.31.0 berisi kolom isControlPlane yang berlebihan di bagian network.controlPlaneIPBlock:

    controlPlaneIPBlock:
    netmask: ""
    gateway: ""
    ips:
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false
    

Kolom ini tidak diperlukan dan dapat dihapus dengan aman dari file konfigurasi.

Node add-on admin macet di NotReady selama migrasi cluster admin dari non-HA ke HA

Saat memigrasikan cluster admin non-HA yang menggunakan MetalLB ke HA, node add-on admin mungkin mengalami masalah pada status NotReady, sehingga mencegah penyelesaian migrasi.

Masalah ini hanya memengaruhi cluster admin yang dikonfigurasi dengan MetalLB, yang tidak mengaktifkan perbaikan otomatis.

Masalah ini disebabkan oleh kondisi persaingan selama migrasi saat speaker MetalLB masih menggunakan secret metallb-memberlist lama. Akibat kondisi persaingan, VIP bidang kontrol lama menjadi tidak dapat diakses, yang menyebabkan migrasi terhenti.

Solusi:

1. Hapus rahasia metallb-memberlist yang ada:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       delete secret metallb-memberlist
   

2. Mulai ulang Deployment metallb-controller agar dapat membuat metallb-memberlist baru:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       rollout restart deployment metallb-controller
   

3. Pastikan metallb-memberlist baru dibuat:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       get secret metallb-memberlist
   

4. Update updateStrategy.rollingUpdate.maxUnavailable di DaemonSet metallb-speaker dari 1 menjadi 100%.

   Langkah ini diperlukan karena pod DaemonSet tertentu berjalan di node NotReady.

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       edit daemonset metallb-speaker
   

5. Mulai ulang DaemonSet metallb-speaker agar dapat mengambil daftar anggota baru:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       rollout restart daemonset metallb-speaker
   

   Setelah beberapa menit, node add-on admin akan menjadi Ready lagi, dan migrasi dapat dilanjutkan.

6. Jika perintah gkectl awal mengalami waktu tunggu habis setelah lebih dari 3 jam, jalankan kembali gkectl update untuk melanjutkan migrasi yang gagal.

Pencadangan cluster untuk cluster admin non-HA gagal karena nama datastore dan datadisk yang panjang

Saat mencoba mencadangkan cluster admin non-HA, pencadangan gagal karena panjang gabungan nama datastore dan datadisk melebihi panjang karakter maksimum.

Panjang karakter maksimum untuk nama penyimpanan data adalah 80.
Jalur pencadangan untuk cluster admin non-HA memiliki sintaksis penamaan "__". Jadi, jika nama yang digabungkan melebihi panjang maksimum, pembuatan folder cadangan akan gagal

Solusi:

Ganti nama datastore atau datadisk menjadi nama yang lebih pendek.
Pastikan panjang gabungan nama datastore dan datadisk tidak melebihi panjang karakter maksimum.

Node bidang kontrol admin HA menampilkan versi yang lebih lama setelah menjalankan gkectl repair admin-master

Setelah menjalankan perintah gkectl repair admin-master, node bidang kontrol admin mungkin menampilkan versi yang lebih lama daripada versi yang diharapkan.

Masalah ini terjadi karena template VM yang dicadangkan yang digunakan untuk perbaikan node panel kontrol admin HA tidak diperbarui di vCenter setelah upgrade, karena template VM cadangan tidak di-clone selama pembuatan mesin jika nama mesin tetap tidak berubah.

Solusi:

1. Cari tahu nama mesin yang menggunakan versi Kubernetes yang lebih lama:

       kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG
       

2. Hapus anotasi onprem.cluster.gke.io/prevented-deletion:

       kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
       

   Simpan hasil edit.

3. Jalankan perintah berikut untuk menghapus mesin:

       kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
       

   Mesin baru akan dibuat dengan versi yang benar.

Terraform menghapus kolom vCenter secara tiba-tiba

Saat memperbarui cluster pengguna atau node pool menggunakan Terraform, Terraform mungkin mencoba menetapkan kolom vCenter ke nilai kosong.

Masalah ini dapat terjadi jika cluster awalnya tidak dibuat menggunakan Terraform.

Solusi:

Untuk mencegah update yang tidak terduga, pastikan update aman sebelum menjalankan terraform apply, seperti yang dijelaskan berikut:

1. Jalankan terraform plan
2. Pada output, periksa apakah kolom vCenter disetel ke nil.
3. Jika ada kolom vCenter yang ditetapkan ke nilai kosong, dalam konfigurasi Terraform, tambahkan vcenter ke daftar ignore_changes mengikuti dokumentasi Terraform. Tindakan ini mencegah pembaruan pada kolom ini.
4. Jalankan terraform plan lagi dan periksa output untuk mengonfirmasi bahwa update sudah sesuai dengan yang diharapkan

Node bidang kontrol cluster pengguna selalu di-reboot selama operasi update cluster admin pertama

Setelah node control plane cluster pengguna kubeception dibuat, diupdate, atau diupgrade, node tersebut akan di-reboot satu per satu, selama operasi cluster admin pertama saat cluster admin dibuat atau diupgrade ke salah satu versi yang terpengaruh. Untuk cluster kubeception dengan 3 node bidang kontrol, hal ini tidak akan menyebabkan periode nonaktif bidang kontrol dan satu-satunya dampak adalah operasi cluster admin membutuhkan waktu lebih lama.

Error saat membuat resource kustom

Di Google Distributed Cloud versi 1.31, Anda mungkin mendapatkan error saat mencoba membuat resource kustom, seperti cluster (semua jenis) dan beban kerja. Masalah ini disebabkan oleh perubahan yang tidak kompatibel yang diperkenalkan di Kubernetes 1.31 yang mencegah kolom caBundle dalam definisi resource kustom bertransisi dari status valid ke status tidak valid. Untuk mengetahui informasi selengkapnya tentang perubahan ini, lihat log perubahan Kubernetes 1.31.

Sebelum Kubernetes 1.31, kolom caBundle sering kali ditetapkan ke nilai sementara \n, karena di versi Kubernetes sebelumnya server API tidak mengizinkan konten paket CA kosong. Penggunaan \n adalah solusi yang wajar untuk menghindari kebingungan, karena cert-manager biasanya memperbarui caBundle nanti.

Jika caBundle telah di-patch satu kali dari status tidak valid ke status valid, tidak akan ada masalah. Namun, jika definisi resource kustom direkonsiliasi kembali ke \n (atau nilai lain yang tidak valid), Anda mungkin mengalami error berikut:

...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]

Solusi

Jika Anda memiliki definisi resource kustom yang caBundle ditetapkan ke nilai yang tidak valid, Anda dapat menghapus kolom caBundle seluruhnya dengan aman. Tindakan ini akan menyelesaikan masalah.

cloud-init status selalu menampilkan error

Saat mengupgrade cluster yang menggunakan image OS Container Optimized OS (COS) ke 1.31, perintah cloud-init status akan gagal meskipun cloud-init selesai tanpa error.

Solusi:

Jalankan perintah berikut untuk memeriksa status cloud-init:

    systemctl show -p Result cloud-final.service
    

Jika output-nya mirip dengan berikut ini, maka cloud-init telah selesai dengan berhasil:

    Result=success
    

Pemeriksaan pendahuluan workstation admin gagal saat mengupgrade ke 1.28 dengan ukuran disk kurang dari 100 GB

Saat mengupgrade cluster ke 1.28, perintah gkectl prepare gagal saat menjalankan pemeriksaan awal workstation admin jika ukuran disk workstation admin kurang dari 100 GB. Dalam hal ini, perintah menampilkan pesan error yang mirip dengan berikut ini:

    Workstation Hardware: Workstation hardware requirements are not satisfied
    

Di 1.28, prasyarat ukuran disk workstation admin ditingkatkan dari 50 GB menjadi 100 GB.

Solusi:

1. Roll back workstation admin.
2. Perbarui file konfigurasi workstation admin untuk meningkatkan ukuran disk menjadi minimal 100 GB.
3. Upgrade workstation admin.

gkectl menampilkan error salah di netapp storageclass

Perintah gkectl upgrade menampilkan error yang salah tentang netapp storageclass. Pesan errornya mirip dengan yang berikut ini:

    detected unsupported drivers:
      csi.trident.netapp.io
    

Solusi:

Jalankan gkectl upgrade dengan tanda `--skip-pre-upgrade-checks`.

Sertifikat CA tidak valid setelah rotasi CA cluster di ClientConfig mencegah autentikasi cluster

Setelah Anda mengganti sertifikat certificate authority (CA) di cluster pengguna, kolom spec.certificateAuthorityData di ClientConfig berisi sertifikat CA yang tidak valid, yang mencegah autentikasi ke cluster.

Solusi:

Sebelum autentikasi gcloud CLI berikutnya, perbarui kolom spec.certificateAuthorityData secara manual di ClientConfig dengan sertifikat CA yang benar.

1. Salin sertifikat CA cluster dari kolom certificate-authority-data di kubeconfig cluster admin.
2. Edit ClientConfig dan tempel sertifikat CA di kolom spec.certificateAuthorityData.

       kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
       

Pemeriksaan pra-penerbangan gagal saat menonaktifkan ingress gabungan

Saat Anda menonaktifkan ingress gabungan dengan menghapus kolom loadBalancer.vips.ingressVIP dalam file konfigurasi cluster, bug dalam pemeriksaan awal MetalLB menyebabkan update cluster gagal dengan pesan error "invalid user ingress vip: invalid IP".

Solusi:

Abaikan pesan error.
Lewati pemeriksaan awal menggunakan salah satu metode berikut:

• Tambahkan flag --skip-validation-load-balancer ke perintah gkectl update cluster.
• Anotasikan objek onpremusercluster dengan onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer
.

Upgrade cluster gagal karena aturan grup anti-afinitas tidak ada di vCenter

Selama upgrade cluster, objek mesin mungkin macet di fase `Membuat` dan gagal ditautkan ke objek node karena tidak adanya aturan grup anti-afinitas (AAG) di vCenter.

Jika Anda menjelaskan objek komputer yang bermasalah, Anda dapat melihat pesan berulang seperti "Reconfigure DRS rule task "task-xxxx" complete"

    kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME
    

Solusi:

Nonaktifkan setelan grup anti-afinitas di konfigurasi cluster admin dan konfigurasi cluster pengguna, lalu picu perintah update paksa untuk membuka blokir upgrade cluster:

    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    

    gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
    

Memigrasikan cluster pengguna ke Controlplane V2 akan gagal jika enkripsi secret pernah diaktifkan

Saat memigrasikan cluster pengguna ke Controlplane V2, jika enkripsi rahasia selalu aktif pernah diaktifkan, proses migrasi gagal menangani kunci enkripsi rahasia dengan benar. Karena masalah ini, cluster Controlplane V2 yang baru tidak dapat mendekripsi rahasia. Jika output perintah berikut tidak kosong, berarti enkripsi secret yang selalu aktif telah diaktifkan pada suatu waktu dan cluster terpengaruh oleh masalah ini:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      get onpremusercluster USER_CLUSTER_NAME \
      -n USER_CLUSTER_NAME-gke-onprem-mgmt \
      -o jsonpath={.spec.secretsEncryption}
    

Jika Anda telah memulai migrasi dan migrasi gagal, hubungi Google untuk mendapatkan dukungan. Jika tidak, sebelum migrasi, nonaktifkan enkripsi secret selalu aktif dan dekripsi secret.

Memigrasikan cluster admin dari non-HA ke HA akan gagal jika enkripsi secret diaktifkan

Jika cluster admin telah mengaktifkan enkripsi rahasia yang selalu aktif di versi 1.14 atau yang lebih lama, dan diupgrade dari versi lama ke versi 1.29 dan 1.30 yang terpengaruh, saat memigrasikan cluster admin dari non-HA ke HA, proses migrasi gagal menangani kunci enkripsi rahasia dengan benar. Karena masalah ini, cluster admin HA baru tidak dapat mendekripsi rahasia.

Untuk memeriksa apakah cluster dapat menggunakan kunci berformat lama:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'
    

Jika output menampilkan kunci kosong seperti berikut, berarti cluster akan terpengaruh oleh masalah ini:

    "GeneratedKeys":[{"KeyVersion":"1","Key":""}]
    

Jika Anda telah memulai migrasi dan migrasi gagal, hubungi Google untuk mendapatkan dukungan.

Jika tidak, sebelum memulai migrasi, ganti kunci enkripsi.

credential.yaml diregenerasi secara tidak benar selama upgrade workstation admin

Saat mengupgrade workstation admin menggunakan perintah gkeadm upgrade admin-workstation, file credential.yaml dibuat ulang dengan tidak benar. Kolom nama pengguna dan sandi kosong. Selain itu, kunci privateRegistry berisi kesalahan ketik.

Kesalahan ejaan yang sama pada kunci privateRegistry juga ada di file admin-cluster.yaml.
Karena file credential.yaml dibuat ulang selama proses upgrade cluster admin, kesalahan ketik akan tetap ada meskipun Anda telah memperbaikinya sebelumnya.

Solusi:

• Perbarui nama kunci registry pribadi di credential.yaml agar cocok dengan privateRegistry.credentials.fileRef.entry di admin-cluster.yaml.
• Perbarui nama pengguna dan sandi registry pribadi di credential.yaml.

Upgrade cluster pengguna gagal karena waktu tunggu rekonsiliasi pra-upgrade habis

Saat mengupgrade cluster pengguna, operasi rekonsiliasi pra-upgrade mungkin membutuhkan waktu lebih lama daripada waktu tunggu yang ditentukan, sehingga menyebabkan kegagalan upgrade. Pesan error terlihat seperti berikut:

Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.

Waktu tunggu untuk operasi rekonsiliasi pra-upgrade adalah 5 menit ditambah 1 menit per node pool di cluster pengguna.

Solusi:

Pastikan perintah gkectl diagnose cluster berhasil tanpa error.
Lewati operasi rekonsiliasi pra-upgrade dengan menambahkan flag --skip-reconcile-before-preflight ke perintah gkectl upgrade cluster. Contoh:

gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE

Memperbarui ForwardMode DataplaneV2 tidak otomatis memicu mulai ulang DaemonSet anetd

Saat Anda mengupdate cluster pengguna menggunakan kolom dataplaneV2.forwardMode gkectl update cluster, perubahan hanya diupdate di ConfigMap, DaemonSet anetd tidak akan mengambil perubahan konfigurasi hingga dimulai ulang dan perubahan Anda tidak diterapkan.

Solusi:

Setelah perintah gkectl update cluster selesai, Anda akan melihat output Done updating the user cluster. Setelah Anda melihat pesan tersebut, jalankan perintah berikut untuk memulai ulang DaemonSet anetd agar perubahan konfigurasi diterapkan:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

Periksa kesiapan DaemonSet setelah dimulai ulang:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

Dalam output perintah sebelumnya, pastikan angka di kolom DESIRED cocok dengan angka di kolom READY.

Perintah etcdctl tidak ditemukan selama upgrade cluster pada tahap pencadangan cluster admin

Selama upgrade cluster pengguna dari 1.16 ke 1.28, cluster admin akan dicadangkan. Proses pencadangan cluster admin menampilkan pesan error "etcdctl: command not found". Upgrade cluster pengguna berhasil, dan cluster admin tetap dalam kondisi baik. Satu-satunya masalah adalah file metadata di cluster admin tidak dicadangkan.

Penyebab masalah ini adalah biner etcdctl ditambahkan di 1.28, dan tidak tersedia di node 1.16.

Pencadangan cluster admin melibatkan beberapa langkah, termasuk mengambil snapshot etcd dan kemudian menulis file metadata untuk cluster admin. Pencadangan etcd masih berhasil karena etcdctl masih dapat dipicu setelah menjalankan perintah ke Pod etcd. Namun, penulisan file metadata gagal karena masih mengandalkan biner etcdctl yang akan diinstal di node. Namun, pencadangan file metadata tidak menghalangi pencadangan, sehingga proses pencadangan tetap berhasil, begitu juga dengan upgrade cluster pengguna.

Solusi:

Jika ingin mencadangkan file metadata, ikuti Mencadangkan dan memulihkan cluster admin dengan gkectl untuk memicu pencadangan cluster admin terpisah menggunakan versi gkectl yang cocok dengan versi cluster admin Anda.

Kegagalan pembuatan cluster pengguna dengan load balancing manual

Saat membuat cluster pengguna yang dikonfigurasi untuk load balancing manual, terjadi kegagalan gkectl check-config yang menunjukkan bahwa nilai ingressHTTPNodePort harus minimal 30000, meskipun ingress gabungan dinonaktifkan.

Masalah ini terjadi terlepas dari apakah kolom ingressHTTPNodePort dan ingressHTTPSNodePort ditetapkan atau dibiarkan kosong.

Solusi:

Untuk mengatasi masalah ini, abaikan hasil yang ditampilkan oleh gkectl check-config. Untuk menonaktifkan ingress gabungan, lihat Menonaktifkan ingress gabungan.

Setelah memigrasikan cluster pengguna ke Controlplane V2, PDB metrics-server cluster admin mungkin salah dikonfigurasi

Masalah pada PodDisruptionBudget (PDB) terjadi saat menggunakan cluster admin ketersediaan tinggi (HA), dan ada 0 atau 1 node cluster admin tanpa peran setelah migrasi. Untuk memeriksa apakah ada objek node tanpa peran, jalankan perintah berikut:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

Jika ada dua objek node atau lebih tanpa peran setelah migrasi, maka PDB tidak salah dikonfigurasi.

Gejala:

Output admin cluster diagnose mencakup informasi berikut

Checking all poddisruptionbudgets...FAILURE
  Reason: 1 pod disruption budget error(s).
  Unhealthy Resources:
  PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).

Solusi:

Jalankan perintah berikut untuk menghapus PDB:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server

Webhook Otorisasi Biner memblokir plugin CNI untuk memulai sehingga salah satu nodepool gagal diaktifkan

Dalam kondisi persaingan yang jarang terjadi, urutan penginstalan webhook Otorisasi Biner dan pod gke-connect yang salah dapat menyebabkan pembuatan cluster pengguna terhenti karena node gagal mencapai status siap. Dalam skenario yang terpengaruh, pembuatan cluster pengguna dapat terhenti karena node gagal mencapai status siap. Jika hal ini terjadi, pesan berikut akan ditampilkan:

     Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready
    

Solusi:

1. Hapus konfigurasi Otorisasi Biner dari file konfigurasi Anda. Untuk mengetahui petunjuk penyiapan, lihat Panduan penginstalan Otorisasi Biner untuk GKE di VMware.
2. Untuk membatalkan pemblokiran node yang tidak sehat selama proses pembuatan cluster saat ini, hapus sementara konfigurasi webhook Otorisasi Biner di cluster pengguna menggunakan perintah berikut.

           kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
           

   Setelah proses bootstrap selesai, Anda dapat menambahkan kembali konfigurasi webhook berikut.

   apiVersion: admissionregistration.k8s.io/v1
   kind: ValidatingWebhookConfiguration
   metadata:
     name: binauthz-validating-webhook-configuration
   webhooks:
   - name: "binaryauthorization.googleapis.com"
     namespaceSelector:
       matchExpressions:
       - key: control-plane
         operator: DoesNotExist
     objectSelector:
       matchExpressions:
       - key: "image-policy.k8s.io/break-glass"
         operator: NotIn
         values: ["true"]
     rules:
     - apiGroups:
       - ""
       apiVersions:
       - v1
       operations:
       - CREATE
       - UPDATE
       resources:
       - pods
       - pods/ephemeralcontainers
     admissionReviewVersions:
     - "v1beta1"
     clientConfig:
       service:
         name: binauthz
         namespace: binauthz-system
         path: /binauthz
       # CA Bundle will be updated by the cert rotator.
       caBundle: Cg==
     timeoutSeconds: 10
     # Fail Open
     failurePolicy: "Ignore"
     sideEffects: None
           

Upgrade cluster pengguna CPV2 terhenti karena mesin yang dicerminkan dengan deletionTimestamp

Selama upgrade cluster pengguna, operasi upgrade mungkin macet jika objek mesin yang di-mirror di cluster pengguna berisi deletionTimestamp. Pesan error berikut akan ditampilkan jika upgrade terhenti:

    machine is still in the process of being drained and subsequently removed
    

Masalah ini dapat terjadi jika Anda sebelumnya mencoba memperbaiki node panel kontrol pengguna dengan menjalankan gkectl delete machine terhadap mesin yang di-mirror di cluster pengguna.

Solusi:

1. Dapatkan objek mesin yang dicerminkan dan simpan ke file lokal untuk tujuan pencadangan.
2. Jalankan perintah berikut untuk menghapus finalizer dari mesin yang di-mirror dan tunggu hingga finalizer dihapus dari cluster pengguna.

       kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

3. Ikuti langkah-langkah di Node bidang kontrol cluster pengguna Controlplane V2 untuk memicu perbaikan node pada node bidang kontrol, sehingga spesifikasi mesin sumber yang benar akan disinkronkan ulang ke cluster pengguna.
4. Jalankan kembali gkectl upgrade cluster untuk melanjutkan upgrade

Kegagalan pembuatan cluster karena VIP bidang kontrol di subnet yang berbeda

Untuk cluster admin HA atau cluster pengguna ControlPlane V2, VIP bidang kontrol harus berada di subnet yang sama dengan node cluster lainnya. Jika tidak, pembuatan cluster akan gagal karena kubelet tidak dapat berkomunikasi dengan server API menggunakan VIP bidang kontrol.

Solusi:

Sebelum pembuatan cluster, pastikan VIP bidang kontrol dikonfigurasi di subnet yang sama dengan node cluster lainnya.

Kegagalan Pembuatan/Upgrade Cluster karena Nama Pengguna vCenter non-FQDN

Pembuatan/upgrade cluster gagal dengan error di pod CSI vSphere yang menunjukkan bahwa nama pengguna vCenter tidak valid. Hal ini terjadi karena nama pengguna yang digunakan bukan nama domain yang sepenuhnya memenuhi syarat. Pesan error di pod vsphere-csi-controller seperti di bawah ini:

    GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username
    

Masalah ini hanya terjadi di versi 1.29 dan yang lebih baru, karena validasi ditambahkan ke driver vSphere CSI untuk menerapkan penggunaan nama pengguna domain yang sepenuhnya memenuhi syarat.

Solusi:

Gunakan nama domain yang sepenuhnya memenuhi syarat untuk nama pengguna vCenter dalam file konfigurasi kredensial. Misalnya, gunakan "username1@example.com", bukan "username1".

Upgrade cluster admin gagal untuk cluster yang dibuat pada versi 1.10 atau yang lebih lama

Saat mengupgrade cluster admin dari 1.16 ke 1.28, bootstrap mesin master admin baru mungkin gagal membuat sertifikat bidang kontrol. Masalah ini disebabkan oleh perubahan cara sertifikat dibuat untuk server Kubernetes API di versi 1.28 dan yang lebih baru. Masalah ini terjadi pada cluster yang dibuat di versi 1.10 dan yang lebih lama yang telah diupgrade hingga ke 1.16 dan sertifikat leaf tidak dirotasi sebelum upgrade.

Untuk menentukan apakah kegagalan upgrade cluster admin disebabkan oleh masalah ini, lakukan langkah-langkah berikut:

1. Hubungkan ke mesin master admin yang gagal menggunakan SSH.
2. Buka /var/log/startup.log dan telusuri error seperti berikut:

Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>
   

Solusi:

1. Hubungkan ke mesin master admin menggunakan SSH. Untuk mengetahui detailnya, lihat Menggunakan SSH untuk terhubung ke node cluster admin.
2. Buat salinan /etc/startup/pki-yaml.sh dan beri nama /etc/startup/pki-yaml-copy.sh
3. Edit /etc/startup/pki-yaml-copy.sh. Temukan authorityKeyIdentifier=keyidset dan ubah menjadi authorityKeyIdentifier=keyid,issuer di bagian untuk ekstensi berikut: apiserver_ext, client_ext, etcd_server_ext, dan kubelet_server_ext. Contoh:

         [ apiserver_ext ]
         keyUsage = critical, digitalSignature, keyEncipherment
         extendedKeyUsage=serverAuth
         basicConstraints = critical,CA:false
         authorityKeyIdentifier = keyid,issuer
         subjectAltName = @apiserver_alt_names
   

4. Simpan perubahan pada /etc/startup/pki-yaml-copy.sh.
5. Dengan menggunakan editor teks, buka /opt/bin/master.sh, temukan dan ganti semua kemunculan /etc/startup/pki-yaml.sh dengan /etc/startup/pki-yaml-copy.sh, lalu simpan perubahan.
6. Jalankan /opt/bin/master.sh untuk membuat sertifikat dan menyelesaikan startup mesin.
7. Jalankan gkectl upgrade admin lagi untuk mengupgrade cluster admin.
8. Setelah upgrade selesai, lakukan rotasi sertifikat leaf untuk cluster admin dan pengguna, seperti yang dijelaskan dalam Mulai rotasi.
9. Setelah rotasi sertifikat selesai, lakukan pengeditan yang sama pada /etc/startup/pki-yaml-copy.sh seperti yang Anda lakukan sebelumnya, dan jalankan /opt/bin/master.sh.

Pesan peringatan yang salah untuk cluster dengan Dataplane V2 yang diaktifkan

Pesan peringatan yang salah berikut ditampilkan saat Anda menjalankan gkectl untuk membuat, mengupdate, atau mengupgrade cluster yang sudah mengaktifkan Dataplane V2:

WARNING: Your user cluster is currently running our original architecture with
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration
tool is available.

Ada bug di gkectl yang menyebabkan peringatan ini selalu ditampilkan selama dataplaneV2.forwardMode tidak digunakan, meskipun Anda telah menetapkan enableDataplaneV2: true dalam file konfigurasi cluster.

Solusi:

Anda dapat mengabaikan peringatan ini dengan aman.

Pemeriksaan pendahuluan penginstalan cluster admin HA melaporkan jumlah IP statis yang diperlukan salah

Saat Anda membuat cluster admin HA, pemeriksaan awal menampilkan pesan error yang salah berikut:

- Validation Category: Network Configuration
    - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
    at least X+1 IP addresses for admin cluster with X nodes

Persyaratan ini salah untuk cluster admin HA 1.28 dan yang lebih tinggi karena tidak lagi memiliki node add-on. Selain itu, karena IP node bidang kontrol cluster admin 3 ditentukan di bagian network.controlPlaneIPBlock dalam file konfigurasi cluster admin, IP dalam file blok IP hanya diperlukan untuk node bidang kontrol cluster pengguna kubeception.

Solusi:

Untuk melewati pemeriksaan pra-peluncuran yang salah dalam rilis yang belum diperbaiki, tambahkan --skip-validation-net-config ke perintah gkectl.

Agen Connect kehilangan koneksi ke Google Cloud setelah migrasi cluster admin dari non-HA ke HA

Jika Anda melakukan migrasi dari cluster admin non-HA ke cluster admin HA, Connect Agent di cluster admin akan kehilangan koneksi ke gkeconnect.googleapis.com dengan error "Failed to verify JWT signature". Hal ini karena selama migrasi, kunci penandatanganan KSA diubah, sehingga pendaftaran ulang diperlukan untuk memperbarui JWK OIDC.

Solusi:

Untuk menghubungkan kembali cluster admin ke Google Cloud, lakukan langkah-langkah berikut untuk memicu pendaftaran ulang:

Pertama, dapatkan nama deployment gke-connect:

kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect

Hapus deployment gke-connect:

kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect

Picu rekonsiliasi paksa untuk onprem-admin-cluster-controller dengan menambahkan anotasi "force-reconcile" ke CR onpremadmincluster Anda:

kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
  annotations:
    onprem.cluster.gke.io/force-reconcile: "true"
'

Idenya adalah onprem-admin-cluster-controller akan selalu men-deploy ulang deployment gke-connect dan mendaftarkan ulang cluster jika tidak menemukan deployment gke-connect yang ada.

Setelah solusi (mungkin perlu waktu beberapa menit agar pengontrol menyelesaikan rekonsiliasi), Anda dapat memverifikasi bahwa error 400 "Gagal memverifikasi tanda tangan JWT" tidak ada lagi di log gke-connect-agent:

kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect

IP bridge Docker menggunakan 172.17.0.1/16 untuk node bidang kontrol cluster COS

Google Distributed Cloud menentukan subnet khusus, --bip=169.254.123.1/24, untuk IP bridge Docker dalam konfigurasi Docker untuk mencegah pencadangan subnet 172.17.0.1/16 default. Namun, di versi 1.28.0-1.28.500 dan 1.29.0, layanan Docker tidak dimulai ulang setelah Google Distributed Cloud menyesuaikan konfigurasi Docker karena regresi pada image OS COS. Akibatnya, Docker memilih 172.17.0.1/16 default sebagai subnet alamat IP bridge-nya. Hal ini dapat menyebabkan konflik alamat IP jika Anda sudah menjalankan beban kerja dalam rentang alamat IP tersebut.

Solusi:

Untuk mengatasi masalah ini, Anda harus memulai ulang layanan docker:

sudo systemctl restart docker

Pastikan Docker memilih alamat IP jembatan yang benar:

ip a | grep docker0

Solusi ini tidak bertahan di seluruh pembuatan ulang VM. Anda harus menerapkan ulang solusi ini setiap kali VM dibuat ulang.

Menggunakan beberapa antarmuka jaringan dengan CNI standar tidak berfungsi

Biner CNI standar bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap tidak disertakan dalam image OS di versi yang terpengaruh. Biner CNI ini tidak digunakan oleh data plane v2, tetapi dapat digunakan untuk antarmuka jaringan tambahan dalam fitur beberapa antarmuka jaringan.

Beberapa antarmuka jaringan dengan plugin CNI ini tidak akan berfungsi.

Solusi:

Lakukan upgrade ke versi dengan perbaikan jika Anda menggunakan fitur ini.

Dependensi NetApp Trident mengganggu driver CSI vSphere

Menginstal multipathd di node cluster mengganggu driver CSI vSphere sehingga workload pengguna tidak dapat dimulai.

Solusi:

• Nonaktifkan multipathd

Webhook cluster admin mungkin memblokir update

Jika beberapa konfigurasi yang diperlukan kosong di cluster admin karena validasi dilewati, penambahannya mungkin diblokir oleh webhook cluster admin. Misalnya, jika kolom gkeConnect tidak disetel di cluster admin yang ada, menambahkannya dengan perintah gkectl update admin dapat memunculkan pesan error berikut:

admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters

failed to apply OnPremAdminCluster 'kube-system/gke-admin-btncc': Internal error occurred: failed calling webhook "monpremadmincluster.onprem.cluster.gke.io": failed to call webhook: Post "https://onprem-admin-cluster-controller.kube-system.svc:443/mutate-onprem-cluster-gke-io-v1alpha1-onpremadmincluster?timeout=10s": dial tcp 10.96.55.208:443: connect: connection refused

Solusi:

• Untuk cluster admin 1.15, jalankan perintah gkectl update admin dengan flag --disable-admin-cluster-webhook. Contoh:

          gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
          

• Untuk cluster admin 1.16, jalankan perintah gkectl update admin dengan flag --force. Contoh:

          gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
          

Kolom controlPlaneNodePort secara default adalah 30968 jika spesifikasi manualLB kosong

Jika Anda akan menggunakan load balancer manual (loadBalancer.kind disetel ke "ManualLB"), Anda tidak perlu mengonfigurasi bagian loadBalancer.manualLB dalam file konfigurasi untuk cluster admin ketersediaan tinggi (HA) di versi 1.16 dan yang lebih tinggi. Namun, jika bagian ini kosong, Google Distributed Cloud akan menetapkan nilai default ke semua NodePort, termasuk manualLB.controlPlaneNodePort, yang menyebabkan pembuatan cluster gagal dengan pesan error berikut:

- Validation Category: Manual LB
  - [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
   not be set when using HA admin cluster, got: 30968

Solusi:

Tentukan manualLB.controlPlaneNodePort: 0 dalam konfigurasi cluster admin untuk cluster admin HA:

loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...

nfs-common tidak ada di image OS Ubuntu

nfs-common tidak ada di image OS Ubuntu yang dapat menyebabkan masalah bagi pelanggan yang menggunakan driver yang bergantung pada NFS seperti NetApp.

Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".
      

Solusi:

Pastikan node Anda dapat mendownload paket dari Canonical.

Selanjutnya, terapkan DaemonSet berikut ke cluster Anda untuk menginstal nfs-common:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: install-nfs-common
  labels:
    name: install-nfs-common
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: install-nfs-common
  minReadySeconds: 0
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        name: install-nfs-common
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      initContainers:
      - name: install-nfs-common
        image: ubuntu
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        command:
        - chroot
        - /host
        - bash
        - -c
        args:
        - |
          apt install -y nfs-common
        volumeMounts:
        - name: host
          mountPath: /host
      containers:
      - name: pause
        image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
        imagePullPolicy: IfNotPresent
      volumes:
      - name: host
        hostPath:
          path: /
      

Kolom kebijakan penyimpanan tidak ada dalam template konfigurasi cluster admin

SPBM di cluster admin didukung di versi 1.28.0 dan yang lebih baru. Namun, kolom vCenter.storagePolicyName tidak ada dalam template file konfigurasi.

Solusi:

Tambahkan kolom `vCenter.storagePolicyName` di file konfigurasi cluster admin jika Anda ingin mengonfigurasi kebijakan penyimpanan untuk cluster admin. Lihat petunjuk.

Kubernetes Metadata API tidak mendukung VPC-SC

API kubernetesmetadata.googleapis.com yang baru ditambahkan tidak mendukung VPC-SC. Hal ini akan menyebabkan agen pengumpulan metadata gagal menjangkau API ini di bawah VPC-SC. Akibatnya, label metadata metrik akan hilang.

Solusi:

Tetapkan di namespace `kube-system`, CR `stackdriver` menetapkan kolom `featureGates.disableExperimentalMetadataAgent` ke `true` dengan menjalankan perintah

`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`

lalu jalankan

`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`

clusterapi-controller dapat mengalami error saat cluster admin dan cluster pengguna yang mengaktifkan ControlPlane V2 menggunakan kredensial vSphere yang berbeda

Jika cluster admin dan cluster pengguna yang mengaktifkan ControlPlane V2 menggunakan kredensial vSphere yang berbeda, misalnya, setelah memperbarui kredensial vSphere untuk cluster admin, clusterapi-controller mungkin gagal terhubung ke vCenter setelah dimulai ulang. Lihat log clusterapi-controller yang berjalan di namespace `kube-system` cluster admin,

kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG

E1214 00:02:54.095668       1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found

Solusi:

Perbarui kredensial vSphere sehingga cluster admin dan semua cluster pengguna dengan Controlplane V2 yang diaktifkan menggunakan kredensial vSphere yang sama.

Jumlah permintaan GRPC yang gagal dalam jumlah besar di Prometheus Alert Manager

Prometheus mungkin melaporkan pemberitahuan yang mirip dengan contoh berikut:

Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.

Untuk memeriksa apakah peringatan ini adalah positif palsu yang dapat diabaikan, selesaikan langkah-langkah berikut:

1. Periksa metrik grpc_server_handled_total mentah terhadap grpc_method yang diberikan dalam pesan pemberitahuan. Dalam contoh ini, periksa label grpc_code untuk Watch.
   
   Anda dapat memeriksa metrik ini menggunakan Cloud Monitoring dengan kueri MQL berikut:

   fetch
       k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m

2. Peringatan pada semua kode selain OK dapat diabaikan dengan aman jika kode tersebut bukan salah satu dari kode berikut:

   Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Solusi:

Untuk mengonfigurasi Prometheus agar mengabaikan pemberitahuan positif palsu ini, tinjau opsi berikut:

1. Menyenyapkan pemberitahuan dari UI Pengelola Pemberitahuan.
2. Jika membisukan notifikasi bukan opsi yang tersedia, tinjau langkah-langkah berikut untuk menekan positif palsu:
   1. Turunkan skala operator pemantauan menjadi 0 replika agar modifikasi dapat tetap ada.
   2. Ubah configmap prometheus-config, lalu tambahkan grpc_method!="Watch" ke konfigurasi pemberitahuan etcdHighNumberOfFailedGRPCRequests seperti yang ditunjukkan dalam contoh berikut:
      • Asli:

        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])

      • Diubah:

        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])

        Ganti CLUSTER_NAME berikut dengan nama cluster Anda.
   3. Mulai ulang Statefulset Prometheus dan Alertmanager untuk mengambil konfigurasi baru.
3. Jika kode termasuk dalam salah satu kasus bermasalah, periksa log etcd dan log kube-apiserver untuk men-debug lebih lanjut.

Koneksi berumur panjang NAT keluar dihentikan

Koneksi NAT keluar mungkin terputus setelah 5 hingga 10 menit koneksi dibuat jika tidak ada traffic.

Karena conntrack hanya penting dalam arah masuk (koneksi eksternal ke cluster), masalah ini hanya terjadi jika koneksi tidak mengirimkan informasi apa pun selama beberapa waktu, lalu sisi tujuan mengirimkan sesuatu. Jika Pod dengan NAT keluar selalu membuat instance pesan, masalah ini tidak akan terlihat.

Masalah ini terjadi karena pengumpulan sampah anetd secara tidak sengaja menghapus entri conntrack yang dianggap tidak digunakan oleh daemon. Perbaikan upstream baru-baru ini diintegrasikan ke dalam anetd untuk memperbaiki perilaku tersebut.

Solusi:

Tidak ada solusi mudah, dan kami belum melihat masalah di versi 1.16 dari perilaku ini. Jika Anda melihat koneksi yang berjalan lama terputus karena masalah ini, solusi yang dapat dilakukan adalah menggunakan workload di node yang sama dengan alamat IP keluar, atau mengirim pesan secara konsisten pada koneksi TCP.

Penanda tangan CSR mengabaikan spec.expirationSeconds saat menandatangani sertifikat

Jika Anda membuat CertificateSigningRequest (CSR) dengan expirationSeconds yang ditetapkan, expirationSeconds akan diabaikan.

Solusi:

Jika Anda terpengaruh oleh masalah ini, Anda dapat memperbarui cluster pengguna dengan menambahkan disableNodeIDVerificationCSRSigning: true di file konfigurasi cluster pengguna dan menjalankan perintah gkectl update cluster untuk memperbarui cluster dengan konfigurasi ini.

Validasi load balancer cluster pengguna gagal untuk disable_bundled_ingress

Jika Anda mencoba menonaktifkan ingress paket untuk cluster yang sudah ada, perintah gkectl update cluster akan gagal dengan error yang mirip dengan contoh berikut:

[FAILURE] Config: ingress IP is required in user cluster spec

Error ini terjadi karena gkectl memeriksa alamat IP ingress load balancer selama pemeriksaan pra-penerbangan. Meskipun pemeriksaan ini tidak diperlukan saat menonaktifkan ingress yang dibundel, pemeriksaan pra-penerbangan gkectl gagal saat disableBundledIngress disetel ke true.

Solusi:

Gunakan parameter --skip-validation-load-balancer saat Anda memperbarui cluster, seperti yang ditunjukkan dalam contoh berikut:

gkectl update cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG  \
  --skip-validation-load-balancer

Untuk mengetahui informasi selengkapnya, lihat cara menonaktifkan ingress paket untuk cluster yang ada.

Update cluster admin gagal setelah rotasi CA

Jika Anda mengganti sertifikat certificate authority (CA) cluster admin, upaya berikutnya untuk menjalankan perintah gkectl update admin akan gagal. Error yang ditampilkan mirip dengan berikut ini:

failed to get last CARotationStage: configmaps "ca-rotation-stage" not found

Solusi:

Jika Anda mengalami masalah ini, Anda dapat mengupdate cluster admin dengan menggunakan tanda --disable-update-from-checkpoint dengan perintah gkectl update admin:

gkectl update admin --config ADMIN_CONFIG_file \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint

Saat Anda menggunakan tanda --disable-update-from-checkpoint, perintah update tidak menggunakan file titik pemeriksaan sebagai sumber tepercaya selama update cluster. File titik pemeriksaan masih diupdate untuk penggunaan di masa mendatang.

Pemeriksaan pra-penerbangan Workload CSI gagal karena kegagalan startup Pod

Selama pemeriksaan pra-penerbangan, pemeriksaan validasi Workload CSI menginstal Pod di namespace default. Pod Workload CSI memvalidasi bahwa Driver CSI vSphere telah diinstal dan dapat melakukan penyediaan volume dinamis. Jika Pod ini tidak dimulai, pemeriksaan validasi Workload CSI akan gagal.

Ada beberapa masalah umum yang dapat mencegah Pod ini dimulai:

• Jika Pod tidak memiliki batas resource yang ditentukan, yang merupakan kasus untuk beberapa cluster dengan webhook penerimaan yang diinstal, Pod tidak akan dimulai.
• Jika Cloud Service Mesh diinstal di cluster dengan injeksi sidecar Istio otomatis diaktifkan di namespace default, Pod Workload CSI tidak akan dimulai.

Jika Pod Workload CSI tidak dimulai, Anda akan melihat error waktu tunggu seperti berikut selama validasi pra-penerbangan:

- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition

Untuk mengetahui apakah kegagalan disebabkan oleh kurangnya setelan resource Pod, jalankan perintah berikut untuk memeriksa status tugas anthos-csi-workload-writer-<run-id>:

kubectl describe job anthos-csi-workload-writer-<run-id>

Jika batas resource tidak ditetapkan dengan benar untuk Pod Workload CSI, status tugas akan berisi pesan error seperti berikut:

CPU and memory resource limits is invalid, as it are not defined for container: volume-tester

Jika Pod Workload CSI tidak dimulai karena injeksi sidecar Istio, Anda dapat menonaktifkan sementara injeksi sidecar Istio otomatis di namespace default. Periksa label namespace dan gunakan perintah berikut untuk menghapus label yang diawali dengan istio.io/rev:

kubectl label namespace default istio.io/rev-

Jika Pod salah dikonfigurasi, verifikasi secara manual bahwa penyediaan volume dinamis dengan Driver CSI vSphere berfungsi:

1. Buat PVC yang menggunakan StorageClass standard-rwo.
2. Buat Pod yang menggunakan PVC.
3. Verifikasi bahwa Pod dapat membaca/menulis data ke volume.
4. Hapus Pod dan PVC setelah Anda memverifikasi operasi yang tepat.

Jika penyediaan volume dinamis dengan Driver CSI vSphere berfungsi, jalankan gkectl diagnose atau gkectl upgrade dengan tanda --skip-validation-csi-workload untuk melewati pemeriksaan Workload CSI.

Waktu tunggu update cluster pengguna habis saat versi cluster admin adalah 1.15

Saat Anda login ke workstation admin yang dikelola pengguna, perintah gkectl update cluster mungkin mengalami waktu tunggu dan gagal memperbarui cluster pengguna. Hal ini terjadi jika versi cluster admin adalah 1.15 dan Anda menjalankan gkectl update admin sebelum menjalankan gkectl update cluster. Saat kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba mengupdate cluster:

      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
      

Selama update cluster admin 1.15, validation-controller yang memicu pemeriksaan pra-penerbangan dihapus dari cluster. Jika Anda kemudian mencoba mengupdate cluster pengguna, pemeriksaan pra-penerbangan akan terhenti hingga waktu tunggu tercapai.

Solusi:

1. Jalankan perintah berikut untuk men-deploy ulang validation-controller:

         gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
         

2. Setelah persiapan selesai, jalankan gkectl update cluster lagi untuk mengupdate cluster pengguna

Waktu tunggu pembuatan cluster pengguna habis saat versi cluster admin adalah 1.15

Saat Anda login ke workstation admin yang dikelola pengguna, perintah gkectl create cluster mungkin mengalami waktu tunggu habis dan gagal membuat cluster pengguna. Hal ini terjadi jika versi cluster admin adalah 1.15. Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba membuat cluster:

      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
      

Karena validation-controller ditambahkan di 1.16, saat menggunakan cluster admin 1.15, validation-controller yang bertanggung jawab untuk memicu pemeriksaan awal tidak ada. Oleh karena itu, saat mencoba membuat cluster pengguna, pemeriksaan pra-peluncuran akan terhenti hingga waktu tunggu habis.

Solusi:

1. Jalankan perintah berikut untuk men-deploy validation-controller:

         gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
         

2. Setelah persiapan selesai, jalankan gkectl create cluster lagi untuk membuat cluster pengguna

Update atau upgrade cluster admin gagal jika project atau lokasi layanan add-on tidak cocok satu sama lain

Saat Anda mengupgrade cluster admin dari versi 1.15.x ke 1.16.x, atau menambahkan konfigurasi connect, stackdriver, cloudAuditLogging, atau gkeOnPremAPI saat mengupdate cluster admin, operasi tersebut mungkin ditolak oleh webhook cluster admin. Salah satu pesan error berikut mungkin ditampilkan:

• "projects for connect, stackdriver and cloudAuditLogging must be the same when specified during cluster creation."
• "locations for connect, gkeOnPremAPI, stackdriver and cloudAuditLogging must be in the same region when specified during cluster creation."
• "locations for stackdriver and cloudAuditLogging must be the same when specified during cluster creation."

Update atau upgrade cluster admin memerlukan onprem-admin-cluster-controller untuk merekonsiliasi cluster admin dalam cluster jenis. Saat status cluster admin dipulihkan di cluster jenis, webhook cluster admin tidak dapat membedakan apakah objek OnPremAdminCluster ditujukan untuk pembuatan cluster admin, atau untuk melanjutkan operasi update atau upgrade. Beberapa validasi khusus pembuatan dipanggil saat memperbarui dan mengupgrade secara tidak terduga.

Solusi:

Tambahkan anotasi onprem.cluster.gke.io/skip-project-location-sameness-validation: true ke objek OnPremAdminCluster:

1. Edit resource cluster onpremadminclusters:

   kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG

   Ganti kode berikut:
   • ADMIN_CLUSTER_NAME: nama cluster admin.
   • ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin.
2. Tambahkan anotasi onprem.cluster.gke.io/skip-project-location-sameness-validation: true dan simpan resource kustom.
3. Bergantung pada jenis cluster admin, selesaikan salah satu langkah berikut:
   • Untuk cluster admin non-HA dengan file checkpoint: tambahkan parameter disable-update-from-checkpoint dalam perintah update, atau tambahkan parameter `disable-upgrade-from-checkpoint` dalam perintah upgrade. Parameter ini hanya diperlukan untuk saat berikutnya Anda menjalankan perintah update atau upgrade:
     • gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
         --disable-update-from-checkpoint

     • gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
         --disable-upgrade-from-checkpoint

   • Untuk cluster admin HA atau file checkpoint dinonaktifkan: perbarui atau upgrade cluster admin seperti biasa. Tidak ada parameter tambahan yang diperlukan pada perintah update atau upgrade.

Penghapusan cluster pengguna gagal saat menggunakan workstation admin yang dikelola pengguna

Saat Anda login ke workstation admin yang dikelola pengguna, perintah gkectl delete cluster dapat mengalami waktu tunggu habis dan gagal menghapus cluster pengguna. Hal ini terjadi jika Anda telah menjalankan gkectl di workstation yang dikelola pengguna untuk membuat, mengupdate, atau mengupgrade cluster pengguna. Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba menghapus cluster:

      failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
      to be deleted: timed out waiting for the condition
      

Selama penghapusan, cluster akan menghapus semua objeknya terlebih dahulu. Penghapusan objek Validasi (yang dibuat selama pembuatan, pembaruan, atau upgrade) macet di fase penghapusan. Hal ini terjadi karena finalizer memblokir penghapusan objek, yang menyebabkan penghapusan kluster gagal.

Solusi:

1. Mendapatkan nama semua objek Validasi:

            kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
              -n USER_CLUSTER_NAME-gke-onprem-mgmt
           

2. Untuk setiap objek Validasi, jalankan perintah berikut untuk menghapus finalizer dari objek Validasi:

         kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
         

   Setelah menghapus finalizer dari semua objek Validasi, objek akan dihapus dan operasi penghapusan cluster pengguna akan selesai secara otomatis. Anda tidak perlu melakukan tindakan tambahan.

Traffic gateway NAT keluar ke server eksternal gagal

Jika Pod sumber dan Pod gateway NAT keluar berada di dua node pekerja yang berbeda, traffic dari Pod sumber tidak dapat menjangkau layanan eksternal mana pun. Jika Pod berada di host yang sama, koneksi ke layanan atau aplikasi eksternal akan berhasil.

Masalah ini disebabkan oleh vSphere yang menghapus paket VXLAN saat agregasi tunnel diaktifkan. Ada masalah umum pada NSX dan VMware yang hanya mengirimkan traffic gabungan pada port VXLAN yang dikenal (4789).

Solusi:

Ubah port VXLAN yang digunakan oleh Cilium menjadi 4789:

1. Edit ConfigMap cilium-config:

   kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

2. Tambahkan kode berikut ke ConfigMap cilium-config:

   tunnel-port: 4789

3. Mulai ulang DaemonSet anetd:

   kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

Solusi ini akan dikembalikan setiap kali cluster diupgrade. Anda harus mengonfigurasi ulang setelah setiap upgrade. VMware harus menyelesaikan masalahnya di vSphere untuk perbaikan permanen.

Mengupgrade cluster admin dengan enkripsi secret yang selalu aktif diaktifkan akan gagal

Upgrade cluster admin dari 1.14.x ke 1.15.x dengan enkripsi secret selalu aktif yang diaktifkan gagal karena ketidakcocokan antara kunci enkripsi yang dibuat pengontrol dengan kunci yang tetap ada di disk data master admin. Output gkectl upgrade admin berisi pesan error berikut:

      E0926 14:42:21.796444   40110 console.go:93] Exit with error:
      E0926 14:42:21.796491   40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane
      

Menjalankan kubectl get secrets -A --kubeconfig KUBECONFIG` gagal dengan error berikut:

      Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk
      

Solusi

Jika Anda memiliki cadangan cluster admin, lakukan langkah-langkah berikut untuk mengatasi kegagalan upgrade:

1. Nonaktifkan secretsEncryption di file konfigurasi cluster admin, dan perbarui cluster menggunakan perintah berikut:

   gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG

2. Saat VM master admin baru dibuat, lakukan SSH ke VM master admin, ganti kunci baru pada disk data dengan kunci lama dari cadangan. Kuncinya terletak di /opt/data/gke-k8s-kms-plugin/generatedkeys di master admin.
3. Perbarui manifes Pod statis kms-plugin.yaml di /etc/kubernetes/manifests untuk memperbarui --kek-id agar cocok dengan kolom kid dalam kunci enkripsi asli.
4. Mulai ulang Pod statis kms-plugin dengan memindahkan /etc/kubernetes/manifests/kms-plugin.yaml ke direktori lain, lalu pindahkan kembali.
5. Lanjutkan upgrade admin dengan menjalankan gkectl upgrade admin lagi.

Mencegah kegagalan upgrade

Jika Anda belum mengupgrade, sebaiknya jangan mengupgrade ke versi 1.15.0-1.15.4. Jika Anda harus mengupgrade ke versi yang terpengaruh, lakukan langkah-langkah berikut sebelum mengupgrade cluster admin:

1. Mencadangkan cluster admin.
2. Nonaktifkan secretsEncryption di file konfigurasi cluster admin, dan perbarui cluster menggunakan perintah berikut:

   gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG

3. Upgrade cluster admin.
4. Aktifkan kembali enkripsi secret selalu aktif.

Error disk dan kegagalan pemasangan saat menggunakan Changed Block Tracking (CBT)

Google Distributed Cloud tidak mendukung Pelacakan Blok yang Berubah (CBT) pada disk. Beberapa software pencadangan menggunakan fitur CBT untuk melacak status disk dan melakukan pencadangan, yang menyebabkan disk tidak dapat terhubung ke VM yang menjalankan Google Distributed Cloud. Untuk mengetahui informasi selengkapnya, lihat artikel VMware KB.

Solusi:

Jangan mencadangkan VM Google Distributed Cloud, karena software pencadangan pihak ketiga dapat menyebabkan CBT diaktifkan di disknya. VM ini tidak perlu dicadangkan.

Jangan aktifkan CBT di node, karena perubahan ini tidak akan tetap ada di seluruh update atau upgrade.

Jika Anda sudah memiliki disk dengan CBT yang diaktifkan, ikuti langkah-langkah Penyelesaian dalam artikel VMware KB untuk menonaktifkan CBT di First Class Disk.

Kerusakan data di NFSv3 saat penambahan paralel ke file bersama dilakukan dari beberapa host

Jika Anda menggunakan array penyimpanan Nutanix untuk menyediakan berbagi NFSv3 ke host, Anda mungkin mengalami kerusakan data atau Pod tidak dapat berjalan dengan berhasil. Masalah ini disebabkan oleh masalah kompatibilitas yang diketahui antara versi VMware dan Nutanix tertentu. Untuk mengetahui informasi selengkapnya, lihat artikel VMware KB terkait.

Solusi:

Artikel KB VMware sudah tidak berlaku dalam mencatat bahwa tidak ada resolusi saat ini. Untuk mengatasi masalah ini, update ke versi terbaru ESXi di host Anda dan ke versi Nutanix terbaru di array penyimpanan Anda.

Ketidakcocokan versi antara kubelet dan bidang kontrol Kubernetes

Untuk rilis Google Distributed Cloud tertentu, kubelet yang berjalan di node menggunakan versi yang berbeda dengan bidang kontrol Kubernetes. Terjadi ketidakcocokan karena biner kubelet yang telah dimuat sebelumnya pada image OS menggunakan versi yang berbeda.

Tabel berikut mencantumkan ketidakcocokan versi yang teridentifikasi:

Solusi:

Anda tidak perlu melakukan apa pun. Ketidakcocokan hanya terjadi antara versi patch Kubernetes dan tidak ada masalah yang disebabkan oleh perbedaan versi ini.

Mengupgrade atau memperbarui cluster admin dengan versi CA yang lebih besar dari 1 akan gagal

Jika cluster admin memiliki versi otoritas sertifikat (CA) yang lebih besar dari 1, update atau upgrade akan gagal karena validasi versi CA di webhook. Output upgrade/update gkectl berisi pesan error berikut:

    CAVersion must start from 1
    

Solusi:

• Kecilkan skala deployment auto-resize-controller di cluster admin untuk menonaktifkan pengubahan ukuran otomatis node. Hal ini diperlukan karena kolom baru yang diperkenalkan ke Resource Kustom cluster admin di 1.15 dapat menyebabkan error pointer nol di auto-resize-controller.

   kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
        

• Jalankan perintah gkectl dengan flag --disable-admin-cluster-webhook.Misalnya:

          gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
          

Penghapusan cluster Controlplane V2 non-HA macet hingga waktu tunggu habis

Saat cluster Controlplane V2 non-HA dihapus, cluster akan macet saat penghapusan node hingga waktunya habis.

Solusi:

Jika cluster berisi StatefulSet dengan data penting, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.

Jika tidak, lakukan langkah-langkah berikut:

• Hapus semua VM cluster dari vSphere. Anda dapat menghapus VM melalui UI vSphere, atau menjalankan perintah berikut:

        govc vm.destroy

  .
• Hapus cluster secara paksa lagi:

       gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force
       

Tugas attachvolume CNS konstan muncul setiap menit untuk PVC/PV dalam struktur setelah mengupgrade ke versi 1.15+

Jika cluster berisi volume persisten vSphere dalam pohon (misalnya, PVC yang dibuat dengan standard StorageClass), Anda akan melihat tugas com.vmware.cns.tasks.attachvolume yang dipicu setiap menit dari vCenter.

Solusi:

Edit vSphere CSI feature configMap dan setel list-volumes ke false:

     kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG
     

Mulai ulang pod pengontrol vSphere CSI:

     kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
    

Peringatan palsu terhadap PVC

Jika cluster berisi volume persisten vSphere dalam pohon, perintah gkectl diagnose dan gkectl upgrade dapat memunculkan peringatan palsu terhadap klaim volume persisten (PVC) saat memvalidasi setelan penyimpanan cluster. Pesan peringatan akan terlihat seperti berikut

    CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled
    

Solusi:

Jalankan perintah berikut untuk memeriksa anotasi PVC dengan peringatan di atas:

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG
    

Jika kolom annotations dalam output berisi hal berikut, Anda dapat mengabaikan peringatan tersebut dengan aman:

      pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
    

Rotasi kunci akun layanan gagal saat beberapa kunci telah habis masa berlakunya

Jika cluster Anda tidak menggunakan registry pribadi, dan kunci akun layanan akses komponen serta kunci akun layanan Logging-monitoring (atau Connect-register) telah habis masa berlakunya, saat Anda merotasi kunci akun layanan, gkectl update credentials akan gagal dengan error yang mirip dengan berikut ini:

Error: reconciliation failed: failed to update platform: ...

Solusi:

Pertama, ganti kunci akun layanan komponen akses. Meskipun pesan error yang sama ditampilkan, Anda akan dapat merotasi kunci lainnya setelah rotasi kunci akun layanan komponen akses.

Jika update masih tidak berhasil, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.

1.15 Mesin master pengguna mengalami pembuatan ulang yang tidak terduga saat pengontrol cluster pengguna diupgrade ke 1.16

Selama upgrade cluster pengguna, setelah pengontrol cluster pengguna diupgrade ke 1.16, jika Anda memiliki cluster pengguna 1.15 lain yang dikelola oleh cluster admin yang sama, mesin master pengguna mungkin dibuat ulang secara tidak terduga.

Ada bug di pengontrol cluster pengguna 1.16 yang dapat memicu pembuatan ulang mesin master pengguna 1.15.

Solusi yang Anda lakukan bergantung pada cara Anda mengalami masalah ini.

Solusi saat mengupgrade cluster pengguna menggunakan konsol Google Cloud :

Opsi 1: Gunakan GKE on VMware versi 1.16.6+ dengan perbaikan.

Opsi 2: Lakukan langkah-langkah berikut:

1. Tambahkan anotasi jalankan ulang secara manual dengan perintah berikut:

   kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

   Anotasi tayang ulang adalah:

   onprem.cluster.gke.io/server-side-preflight-rerun: true

2. Pantau progres upgrade dengan memeriksa kolom status OnPremUserCluster.

Solusi saat mengupgrade cluster pengguna menggunakan workstation admin Anda sendiri:

Opsi 1: Gunakan GKE on VMware versi 1.16.6+ dengan perbaikan.

Opsi 2: Lakukan langkah-langkah berikut:

1. Tambahkan file info build /etc/cloud/build.info dengan konten berikut. Hal ini menyebabkan pemeriksaan pra-penerbangan berjalan secara lokal di workstation admin Anda, bukan di server.

   gke_on_prem_version: GKE_ON_PREM_VERSION

   Contoh:

   gke_on_prem_version: 1.16.0-gke.669

2. Jalankan kembali perintah upgrade.
3. Setelah upgrade selesai, hapus file build.info.

Pemeriksaan pra-penerbangan gagal saat nama host tidak ada dalam file blok IP.

Selama pembuatan cluster, jika Anda tidak menentukan nama host untuk setiap alamat IP dalam file blok IP, pemeriksaan pra-peluncuran akan gagal dengan pesan error berikut:

multiple VMs found by DNS name  in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`
    

Ada bug dalam pemeriksaan awal yang menganggap hostname kosong sebagai duplikat.

Solusi:

Opsi 1: Gunakan versi dengan perbaikan.

Opsi 2: Lewati pemeriksaan pra-penerbangan ini dengan menambahkan tanda --skip-validation-net-config.

Opsi 3: Tentukan nama host unik untuk setiap alamat IP dalam file blok IP.

Kegagalan pemasangan volume saat mengupgrade/memperbarui cluster admin jika menggunakan cluster admin non-HA dan cluster pengguna v1 bidang kontrol

Untuk cluster admin non-HA dan cluster pengguna bidang kontrol v1, saat Anda mengupgrade atau mengupdate cluster admin, pembuatan ulang mesin master cluster admin mungkin terjadi pada saat yang sama dengan reboot mesin master cluster pengguna, yang dapat memunculkan kondisi persaingan. Hal ini menyebabkan Pod bidang kontrol cluster pengguna tidak dapat berkomunikasi dengan bidang kontrol cluster admin, yang menyebabkan masalah pemasangan volume untuk kube-etcd dan kube-apiserver di bidang kontrol cluster pengguna.

Untuk memverifikasi masalah, jalankan perintah berikut untuk pod yang terpengaruh:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME

Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Warning  FailedMount  101s                 kubelet            Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
  Warning  FailedMount  86s (x2 over 3m28s)  kubelet            MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"

Solusi:

1. SSH ke node bidang kontrol pengguna, karena merupakan cluster pengguna v1 bidang kontrol, node bidang kontrol pengguna berada di cluster admin.
2. Mulai ulang kubelet menggunakan perintah berikut:

       sudo systemctl restart kubelet
       

   Setelah dimulai ulang, kubelet dapat merekonstruksi pemasangan global tahap dengan benar.

Node bidang kontrol gagal dibuat

Selama upgrade atau update cluster admin, kondisi persaingan mungkin menyebabkan pengelola pengontrol cloud vSphere menghapus node bidang kontrol baru secara tidak terduga. Hal ini menyebabkan clusterapi-controller macet menunggu node dibuat, dan akhirnya upgrade/update kehabisan waktu. Dalam hal ini, output perintah upgrade/update gkectl akan mirip dengan berikut ini:

    controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...
    

Untuk mengidentifikasi gejala, jalankan perintah di bawah untuk mendapatkan log di pengelola pengontrol cloud vSphere di cluster admin:

    kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
    kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
    

Berikut adalah contoh pesan error dari perintah di atas:

    node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.
    

Solusi:

1. Mulai ulang komputer yang gagal untuk membuat ulang objek node yang dihapus.
2. Gunakan SSH untuk mengakses setiap node bidang kontrol dan mulai ulang pod statis pengontrol cloud vSphere:

         sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
         sudo crictl stop PREVIOUS_COMMAND_OUTPUT
         

3. Jalankan kembali perintah upgrade/update.

Nama host duplikat di pusat data yang sama menyebabkan kegagalan upgrade atau pembuatan cluster

Mengupgrade cluster 1.15 atau membuat cluster 1.16 dengan IP statis akan gagal jika ada nama host duplikat di data center yang sama. Kegagalan ini terjadi karena pengelola pengontrol cloud vSphere gagal menambahkan IP eksternal dan ID penyedia di objek node. Hal ini menyebabkan upgrade/pembuatan cluster kehabisan waktu.

Untuk mengidentifikasi masalah, dapatkan log pod pengelola pengontrol cloud vSphere untuk cluster. Perintah yang Anda gunakan bergantung pada jenis cluster, seperti berikut:

• Cluster admin:

        kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
        kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
        

• Cluster pengguna dengan enableControlplaneV2 false:

        kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
        kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
        

• Cluster pengguna dengan enableControlplaneV2 true:

        kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
        kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system
        

Berikut adalah contoh pesan error:

    I1003 17:17:46.769676       1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
    E1003 17:17:46.771717       1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2
    

Periksa apakah nama host diduplikasi di pusat data:

          export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME
          

          export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb
          

Solusi yang Anda lakukan bergantung pada operasi yang gagal.

Solusi untuk upgrade:

Lakukan solusi untuk jenis cluster yang berlaku.

• Grup pengguna:
  1. Perbarui nama host mesin yang terpengaruh di user-ip-block.yaml menjadi nama unik dan picu update paksa:
     

               gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
               

  2. Jalankan ulang gkectl upgrade cluster
• Cluster admin:
  1. Perbarui nama host mesin yang terpengaruh di admin-ip-block.yaml menjadi nama unik dan picu update paksa:
     

               gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
               

  2. Jika cluster admin adalah cluster admin non-HA, dan Anda menemukan bahwa VM master admin menggunakan nama host duplikat, Anda juga perlu:
     Mendapatkan nama mesin master admin

               kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
               

     Perbarui objek mesin master admin
     Catatan: NEW_ADMIN_MASTER_HOSTNAME harus sama dengan yang Anda tetapkan di admin-ip-block.yaml pada langkah 1.
     

               kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
               

     Verifikasi nama host diperbarui di objek mesin master admin:
     

               kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
               kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
               

  3. Jalankan ulang upgrade cluster admin dengan checkpoint dinonaktifkan:
     

               gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint
               

Solusi untuk penginstalan:

Lakukan solusi untuk jenis cluster yang berlaku.

• Admin cluster:
  1. Hapus mesin node admin.
  2. Hapus disk data.
  3. Hapus file checkpoint cluster admin.
  4. Perbarui nama host mesin yang terpengaruh di admin-ip-block.yaml menjadi nama unik.
  5. Jalankan ulang gkectl create admin.
• Grup pengguna:
  1. Membersihkan resource.
  2. Perbarui nama host komputer yang terpengaruh di user-ip-block.yaml menjadi nama unik.
  3. Jalankan ulang gkectl create cluster.

$ dan ` tidak didukung di nama pengguna atau sandi vSphere

Operasi berikut akan gagal jika nama pengguna atau sandi vSphere berisi $ atau `:

• Mengupgrade cluster pengguna 1.15 dengan Controlplane V2 yang diaktifkan ke 1.16
• Mengupgrade cluster admin ketersediaan tinggi (HA) 1.15 ke 1.16
• Membuat cluster pengguna 1.16 dengan Controlplane V2 diaktifkan
• Membuat cluster admin HA 1.16

Gunakan Google Distributed Cloud versi 1.16.4+ dengan perbaikan atau lakukan solusi sementara di bawah. Solusi yang Anda lakukan bergantung pada operasi yang gagal.

Solusi untuk upgrade:

1. Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `.
2. Perbarui nama pengguna atau sandi vCenter di file konfigurasi credentials.
3. Memicu update paksa cluster.
• Cluster pengguna:

          gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
          

• Cluster admin:

          gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
          

Solusi untuk penginstalan:

1. Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `.
2. Perbarui nama pengguna atau sandi vCenter di file konfigurasi credentials.
3. Lakukan solusi untuk jenis cluster yang berlaku.
• Admin cluster:
  1. Hapus mesin node admin.
  2. Hapus disk data.
  3. Hapus file checkpoint cluster admin.
  4. Jalankan ulang gkectl create admin.
• Grup pengguna:
  1. Membersihkan resource.
  2. Jalankan ulang gkectl create cluster.

Kegagalan pembuatan PVC setelah node dibuat ulang dengan nama yang sama

Setelah node dihapus lalu dibuat ulang dengan nama node yang sama, ada sedikit kemungkinan bahwa pembuatan PersistentVolumeClaim (PVC) selanjutnya akan gagal dengan error seperti berikut:

    The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created

Hal ini disebabkan oleh kondisi persaingan saat pengontrol vSphere CSI tidak menghapus mesin yang dihapus dari cache-nya.

Solusi:

Mulai ulang pod pengontrol vSphere CSI:

    kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
    

gkectl repair admin-master menampilkan error unmarshall kubeconfig

Saat Anda menjalankan perintah gkectl repair admin-master di cluster admin HA, gkectl akan menampilkan pesan error berikut:

  Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
    line 3: cannot unmarshal !!seq into map[string]*api.Cluster
    line 8: cannot unmarshal !!seq into map[string]*api.Context
  

Solusi:

Tambahkan tanda --admin-master-vm-template= ke perintah dan berikan template VM dari mesin yang akan diperbaiki:

  gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE \
      --admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME
  

Untuk menemukan template VM mesin:

1. Buka halaman Hosts and Clusters di klien vSphere.
2. Klik VM Templates dan filter menurut nama cluster admin.

   Anda akan melihat tiga template VM untuk cluster admin.

3. Salin nama template VM yang cocok dengan nama mesin yang Anda perbaiki dan gunakan nama template dalam perintah perbaikan.

  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl

VM Seesaw rusak karena ruang disk hampir habis

Jika Anda menggunakan Seesaw sebagai jenis load balancer untuk cluster dan melihat bahwa VM Seesaw tidak aktif atau terus gagal di-boot, Anda mungkin melihat pesan error berikut di konsol vSphere:

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd
    

Error ini menunjukkan bahwa ruang disk di VM hampir penuh karena fluent-bit yang berjalan di VM Seesaw tidak dikonfigurasi dengan rotasi log yang benar.

Solusi:

Temukan file log yang menghabiskan sebagian besar ruang disk menggunakan du -sh -- /var/lib/docker/containers/* | sort -rh. Bersihkan file log dengan ukuran terbesar dan mulai ulang VM.

Catatan: Jika VM tidak dapat diakses sama sekali, pasang disk ke VM yang berfungsi (misalnya, workstation admin), hapus file dari disk yang terpasang, lalu pasang kembali disk ke VM Seesaw asli.

Untuk mencegah masalah ini terjadi lagi, hubungkan ke VM dan ubah file /etc/systemd/system/docker.fluent-bit.service. Tambahkan --log-opt max-size=10m --log-opt max-file=5 dalam perintah Docker, lalu jalankan systemctl restart docker.fluent-bit.service

Error kunci publik SSH admin setelah upgrade atau update cluster admin

Saat Anda mencoba mengupgrade (gkectl upgrade admin) atau mengupdate (gkectl update admin) cluster admin non-Ketersediaan Tinggi dengan checkpoint yang diaktifkan, upgrade atau update mungkin gagal dengan error seperti berikut:

Checking admin cluster certificates...FAILURE
    Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
    AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey).

failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey)

error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...

Solusi:

Jika Anda tidak dapat mengupgrade ke versi patch Google Distributed Cloud dengan perbaikan, hubungi Dukungan Google untuk mendapatkan bantuan.

Mengupgrade cluster admin yang terdaftar di GKE On-Prem API dapat gagal

Jika cluster admin didaftarkan di GKE On-Prem API, mengupgrade cluster admin ke versi yang terpengaruh dapat gagal karena keanggotaan armada tidak dapat diupdate. Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba mengupgrade cluster:

    failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated
    

Cluster admin didaftarkan di API saat Anda mendaftarkan secara eksplisit cluster, atau saat Anda mengupgrade cluster pengguna menggunakan klien GKE On-Prem API.

Solusi:

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
    

Anotasi link resource cluster admin terdaftar tidak dipertahankan

Saat cluster admin didaftarkan ke GKE On-Prem API, anotasi link resource-nya diterapkan ke resource kustom OnPremAdminCluster, yang tidak dipertahankan selama update cluster admin berikutnya karena kunci anotasi yang salah digunakan. Hal ini dapat menyebabkan cluster admin mendaftar ke GKE On-Prem API lagi secara keliru.

Cluster admin didaftarkan di API saat Anda mendaftarkan secara eksplisit cluster, atau saat Anda mengupgrade cluster pengguna menggunakan klien GKE On-Prem API.

Solusi:

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
    

orderPolicy CoreDNS tidak dikenali

OrderPolicy tidak dikenali sebagai parameter dan tidak digunakan. Sebagai gantinya, Google Distributed Cloud selalu menggunakan Random.

Masalah ini terjadi karena template CoreDNS tidak diperbarui, yang menyebabkan orderPolicy diabaikan.

Solusi:

Perbarui template CoreDNS dan terapkan perbaikan. Perbaikan ini akan berlanjut hingga upgrade.

1. Edit template yang ada:

   kubectl edit cm -n kube-system coredns-template

   Ganti konten template dengan kode berikut:

   coredns-template: |-
     .:53 {
       errors
       health {
         lameduck 5s
       }
       ready
       kubernetes cluster.local in-addr.arpa ip6.arpa {
         pods insecure
         fallthrough in-addr.arpa ip6.arpa
       }
   {{- if .PrivateGoogleAccess }}
       import zones/private.Corefile
   {{- end }}
   {{- if .RestrictedGoogleAccess }}
       import zones/restricted.Corefile
   {{- end }}
       prometheus :9153
       forward . {{ .UpstreamNameservers }} {
         max_concurrent 1000
         {{- if ne .OrderPolicy "" }}
         policy {{ .OrderPolicy }}
         {{- end }}
       }
       cache 30
   {{- if .DefaultDomainQueryLogging }}
       log
   {{- end }}
       loop
       reload
       loadbalance
   }{{ range $i, $stubdomain := .StubDomains }}
   {{ $stubdomain.Domain }}:53 {
     errors
   {{- if $stubdomain.QueryLogging }}
     log
   {{- end }}
     cache 30
     forward . {{ $stubdomain.Nameservers }} {
       max_concurrent 1000
       {{- if ne $.OrderPolicy "" }}
       policy {{ $.OrderPolicy }}
       {{- end }}
     }
   }
   {{- end }}

Status OnPremAdminCluster tidak konsisten antara titik pemeriksaan dan CR sebenarnya

Kondisi persaingan tertentu dapat menyebabkan status OnPremAdminCluster tidak konsisten antara titik pemeriksaan dan CR sebenarnya. Saat masalah terjadi, Anda dapat mengalami error berikut saat mengupdate cluster admin setelah mengupgradenya:

Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated

Proses rekonsiliasi mengubah sertifikat admin pada cluster admin

Google Distributed Cloud mengubah sertifikat admin pada bidang kontrol cluster admin dengan setiap proses rekonsiliasi, seperti selama upgrade cluster. Perilaku ini meningkatkan kemungkinan mendapatkan sertifikat yang tidak valid untuk cluster admin Anda, terutama untuk cluster versi 1.15.

Jika terpengaruh oleh masalah ini, Anda mungkin mengalami masalah seperti berikut:

• Sertifikat yang tidak valid dapat menyebabkan perintah berikut mengalami waktu tunggu habis dan menampilkan error:
  • gkectl create admin
  • gkectl upgrade amdin
  • gkectl update admin

  Perintah ini dapat menampilkan error otorisasi seperti berikut:

  Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized

• Log kube-apiserver untuk cluster admin Anda mungkin berisi error seperti berikut:

  Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Solusi:

Lakukan upgrade ke versi Google Distributed Cloud dengan perbaikan: 1.13.10+, 1.14.6+, 1.15.2+. Jika upgrade tidak memungkinkan bagi Anda, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.

Komponen Anthos Network Gateway dikeluarkan atau tertunda karena tidak ada class prioritas

Pod gateway jaringan di kube-system mungkin menampilkan status Pending atau Evicted, seperti yang ditunjukkan dalam contoh output ringkas berikut:

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Error ini menunjukkan peristiwa pengusiran atau ketidakmampuan untuk menjadwalkan Pod karena resource node. Karena Pod Anthos Network Gateway tidak memiliki PriorityClass, Pod tersebut memiliki prioritas default yang sama dengan workload lainnya. Jika node kekurangan resource, Pod gateway jaringan mungkin dikeluarkan. Perilaku ini sangat buruk untuk DaemonSet ang-node, karena Pod tersebut harus dijadwalkan di node tertentu dan tidak dapat dimigrasikan.

Solusi:

Upgrade ke 1.15 atau yang lebih baru.

Sebagai solusi jangka pendek, Anda dapat menetapkan PriorityClass secara manual ke komponen Anthos Network Gateway. Pengontrol Google Distributed Cloud akan menimpa perubahan manual ini selama proses rekonsiliasi, seperti selama upgrade cluster.

• Tetapkan PriorityClass system-cluster-critical ke Deployment pengontrol cluster ang-controller-manager dan autoscaler.
• Tetapkan PriorityClass system-node-critical ke DaemonSet node ang-daemon.

Upgrade cluster admin gagal setelah mendaftarkan cluster dengan gcloud

Setelah menggunakan gcloud untuk mendaftarkan cluster admin dengan bagian gkeConnect yang tidak kosong, Anda mungkin melihat error berikut saat mencoba mengupgrade cluster:

failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

Hapus namespace gke-connect:

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG

kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME

gkectl diagnose snapshot --log-since gagal membatasi jangka waktu untuk perintah journalctl yang berjalan di node cluster

Hal ini tidak memengaruhi fungsi pengambilan snapshot cluster, karena snapshot masih menyertakan semua log yang dikumpulkan secara default dengan menjalankan journalctl di node cluster. Oleh karena itu, tidak ada informasi debug yang terlewat.

gkectl prepare windows gagal

gkectl prepare windows gagal menginstal Docker di Google Distributed Cloud versi sebelum 1.13 karena MicrosoftDockerProvider tidak digunakan lagi.

Solusi:

Ide umum untuk mengatasi masalah ini adalah mengupgrade ke Google Distributed Cloud 1.13 dan menggunakan gkectl 1.13 untuk membuat template VM Windows, lalu membuat node pool Windows. Ada dua opsi untuk mendapatkan Google Distributed Cloud 1.13 dari versi saat ini seperti yang ditunjukkan di bawah.

Catatan: Kami memiliki opsi untuk mengatasi masalah ini di versi Anda saat ini tanpa perlu mengupgrade ke 1.13, tetapi akan memerlukan langkah-langkah manual lainnya. Hubungi tim dukungan kami jika Anda ingin mempertimbangkan opsi ini.

Opsi 1: Upgrade Blue/Green

Anda dapat membuat cluster baru menggunakan versi Google Distributed Cloud 1.13+ dengan node pool Windows, dan memigrasikan workload Anda ke cluster baru, lalu menghapus cluster saat ini. Sebaiknya gunakan versi minor Google Distributed Cloud terbaru.

Catatan: Tindakan ini akan memerlukan resource tambahan untuk menyediakan cluster baru, tetapi waktu nonaktif dan gangguan yang lebih sedikit untuk workload yang ada.

Opsi 2: Hapus kumpulan node Windows dan tambahkan kembali saat mengupgrade ke Google Distributed Cloud 1.13

Catatan: Untuk opsi ini, workload Windows tidak akan dapat berjalan hingga cluster diupgrade ke 1.13 dan node pool Windows ditambahkan kembali.

1. Hapus node pool Windows yang ada dengan menghapus konfigurasi node pool Windows dari file user-cluster.yaml, lalu jalankan perintah:

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

2. Upgrade cluster admin+pengguna khusus Linux ke 1.12 dengan mengikuti panduan upgrade untuk versi minor target yang sesuai.
3. (Pastikan untuk melakukan langkah ini sebelum mengupgrade ke 1.13) Pastikan enableWindowsDataplaneV2: true dikonfigurasi di CR OnPremUserCluster, jika tidak, cluster akan terus menggunakan node pool Docker for Windows, yang tidak akan kompatibel dengan template VM Windows 1.13 yang baru dibuat dan tidak menginstal Docker. Jika tidak dikonfigurasi atau disetel ke false, update cluster Anda untuk menyetelnya ke true di user-cluster.yaml, lalu jalankan:

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

4. Upgrade cluster admin+pengguna khusus Linux ke 1.13 dengan mengikuti panduan upgrade.
5. Siapkan template VM Windows menggunakan gkectl 1.13:

   gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG

6. Tambahkan kembali konfigurasi node pool Windows ke user-cluster.yaml dengan kolom OSImage yang ditetapkan ke template VM Windows yang baru dibuat.
7. Mengupdate cluster untuk menambahkan node pool Windows

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

Konfigurasi RootDistanceMaxSec tidak berlaku untuk node ubuntu

Nilai default 5 detik untuk RootDistanceMaxSec akan digunakan di node, bukan 20 detik yang seharusnya menjadi konfigurasi yang diharapkan. Jika Anda memeriksa log startup node dengan melakukan SSH ke VM, yang berada di `/var/log/startup.log`, Anda dapat menemukan error berikut:

+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

Menggunakan RootDistanceMaxSec 5 detik dapat menyebabkan jam sistem tidak tersinkron dengan server NTP jika penyimpangan jam lebih besar dari 5 detik.

Solusi:

Terapkan DaemonSet berikut ke cluster Anda untuk mengonfigurasi RootDistanceMaxSec:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-root-distance
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-root-distance
  template:
    metadata:
      labels:
        app: change-root-distance
    spec:
      hostIPC: true
      hostPID: true
      tolerations:
      # Make sure pods gets scheduled on all nodes.
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      containers:
      - name: change-root-distance
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
            if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
              echo "timesyncd has the expected RootDistanceMaxSec, skip update"
            else
              echo "updating timesyncd config to RootDistanceMaxSec=20"
              mkdir -p /etc/systemd/timesyncd.conf.d
              cat > $conf_file << EOF
          [Time]
          RootDistanceMaxSec=20
          EOF
              systemctl restart systemd-timesyncd
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

gkectl update admin gagal karena kolom osImageType kosong

Saat menggunakan gkectl versi 1.13 untuk mengupdate cluster admin versi 1.12, Anda mungkin melihat error berikut:

Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

Saat menggunakan gkectl update admin untuk cluster versi 1.13 atau 1.14, Anda mungkin melihat pesan berikut dalam respons:

Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

Jika memeriksa log gkectl, Anda mungkin melihat bahwa beberapa perubahan mencakup penyetelan osImageType dari string kosong menjadi ubuntu_containerd.

Error update ini disebabkan oleh pengisian ulang yang tidak tepat pada kolom osImageType dalam konfigurasi cluster admin sejak diperkenalkan di versi 1.9.

Solusi:

Lakukan upgrade ke versi Google Distributed Cloud yang berisi perbaikan. Jika mengupgrade tidak memungkinkan bagi Anda, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.

SNI tidak berfungsi di cluster pengguna dengan Controlplane V2

Kemampuan untuk memberikan sertifikat penayangan tambahan untuk server Kubernetes API dari cluster pengguna dengan authentication.sni tidak berfungsi saat Controlplane V2 diaktifkan ( enableControlplaneV2: true).

Solusi:

Hingga patch Google Distributed Cloud yang berisi perbaikan tersedia, jika Anda perlu menggunakan SNI, nonaktifkan Controlplane V2 (enableControlplaneV2: false).

$ di nama pengguna registry pribadi menyebabkan kegagalan startup mesin bidang kontrol admin

Mesin bidang kontrol admin gagal di-start saat nama pengguna registry pribadi berisi $. Saat memeriksa /var/log/startup.log di komputer bidang kontrol admin, Anda akan melihat error berikut:

++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

Solusi:

Gunakan nama pengguna registry pribadi tanpa $, atau gunakan versi Google Distributed Cloud dengan perbaikan.

Peringatan positif palsu tentang perubahan yang tidak didukung selama update cluster admin

Saat Anda mengupdate cluster admin, Anda akan melihat peringatan positif palsu berikut dalam log, dan Anda dapat mengabaikannya.

    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      -         CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      +         CARotation:        nil,
      ...
    }

Gagal memperbarui cluster pengguna setelah rotasi kunci penandatanganan KSA

Setelah Anda merotasi kunci penandatanganan KSA dan selanjutnya memperbarui cluster pengguna, gkectl update mungkin gagal dengan pesan error berikut:

Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"

Solusi:

1. Periksa secret di cluster admin dalam namespace USER_CLUSTER_NAME, dan dapatkan nama secret ksa-signing-key:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key

2. Salin secret ksa-signing-key, lalu beri nama secret yang disalin sebagai service-account-cert:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
   sed 's/ name: .*/ name: service-account-cert/' | \
   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -

3. Hapus rahasia ksa-signing-key sebelumnya:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME

4. Perbarui kolom data.data di configmap ksa-signing-key-rotation-stage menjadi '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}':

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
   edit configmap ksa-signing-key-rotation-stage

5. Nonaktifkan webhook validasi untuk mengedit informasi versi di resource kustom OnPremUserCluster:

   kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
   webhooks:
   - name: vonpremnodepool.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       resources:
       - onpremnodepools
   - name: vonpremusercluster.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       resources:
       - onpremuserclusters
   '

6. Perbarui kolom spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation menjadi 1 di resource kustom OnPremUserCluster Anda:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
   edit onpremusercluster USER_CLUSTER_NAME

7. Tunggu hingga cluster pengguna target siap. Anda dapat memeriksa statusnya dengan:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
   get onpremusercluster

8. Pulihkan webhook validasi untuk cluster pengguna:

   kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
   webhooks:
   - name: vonpremnodepool.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       - UPDATE
       resources:
       - onpremnodepools
   - name: vonpremusercluster.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       - UPDATE
       resources:
       - onpremuserclusters
   '

9. Hindari rotasi kunci penandatanganan KSA lainnya hingga cluster diupgrade ke versi dengan perbaikan.

Server virtual F5 BIG-IP tidak dibersihkan saat Terraform menghapus cluster pengguna

Saat Anda menggunakan Terraform untuk menghapus cluster pengguna dengan load balancer F5 BIG-IP, server virtual F5 BIG-IP tidak akan dihapus setelah penghapusan cluster.

Solusi:

Untuk menghapus resource F5, ikuti langkah-langkah untuk membersihkan partisi F5 cluster pengguna

Cluster kind menarik image container dari docker.io

Jika Anda membuat cluster admin versi 1.13.8 atau versi 1.14.4, atau mengupgrade cluster admin ke versi 1.13.8 atau 1.14.4, cluster kind akan menarik image container berikut dari docker.io:

Jika docker.io tidak dapat diakses dari workstation admin Anda, pembuatan atau upgrade cluster admin gagal memunculkan cluster jenis. Menjalankan perintah berikut di workstation admin akan menampilkan container yang sesuai dalam status tertunda dengan ErrImagePull:

docker exec gkectl-control-plane kubectl get pods -A

Responsnya berisi entri seperti berikut:

...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

Image container ini harus dimuat sebelumnya di image container cluster kind. Namun, kind v0.18.0 memiliki masalah dengan image container yang telah dimuat sebelumnya, yang menyebabkan image tersebut ditarik dari internet secara keliru.

Solusi:

Jalankan perintah berikut di workstation admin, saat cluster admin Anda tertunda pembuatan atau upgrade-nya:

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501

Failover yang tidak berhasil pada cluster pengguna dan cluster admin HA Controlplane V2 saat jaringan memfilter permintaan GARP duplikat

Jika VM cluster Anda terhubung dengan switch yang memfilter permintaan GARP (ARP gratis) duplikat, pemilihan pemimpin keepalived mungkin mengalami kondisi persaingan, yang menyebabkan beberapa node memiliki entri tabel ARP yang salah.

Node yang terpengaruh dapat ping VIP bidang kontrol, tetapi koneksi TCP ke VIP bidang kontrol akan mencapai waktu tunggu habis.

Solusi:

    iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    

vsphere-csi-controller perlu dimulai ulang setelah rotasi sertifikat vCenter

vsphere-csi-controller harus memperbarui secret vCenter-nya setelah rotasi sertifikat vCenter. Namun, sistem saat ini tidak memulai ulang pod vsphere-csi-controller dengan benar, sehingga menyebabkan vsphere-csi-controller error setelah rotasi.

Solusi:

Untuk cluster yang dibuat di versi 1.13 dan yang lebih baru, ikuti petunjuk di bawah untuk memulai ulang vsphere-csi-controller

kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system

Pembuatan cluster admin tidak gagal karena error pendaftaran cluster

Meskipun pendaftaran cluster gagal selama pembuatan cluster admin, perintah gkectl create admin tidak gagal karena error dan mungkin berhasil. Dengan kata lain, pembuatan cluster admin dapat "berhasil" tanpa didaftarkan ke fleet.

Failed to register admin cluster

Anda juga dapat memeriksa apakah Anda dapat menemukan cluster di antara cluster terdaftar di Konsol Cloud.

Solusi:

Untuk cluster yang dibuat pada versi 1.12 dan yang lebih baru, ikuti petunjuk untuk mencoba lagi pendaftaran cluster admin setelah pembuatan cluster. Untuk cluster yang dibuat pada versi sebelumnya,

1. Tambahkan pasangan nilai kunci palsu seperti "foo: bar" ke file kunci SA connect-register Anda
2. Jalankan gkectl update admin untuk mendaftarkan ulang cluster admin.

Pendaftaran ulang cluster admin dapat dilewati selama upgrade cluster admin

Selama upgrade cluster admin, jika upgrade node bidang kontrol pengguna kehabisan waktu, cluster admin tidak akan didaftarkan ulang dengan versi agen connect yang diupdate.

Solusi:

1. Tambahkan pasangan nilai kunci palsu seperti "foo: bar" ke file kunci SA connect-register Anda
2. Jalankan gkectl update admin untuk mendaftarkan ulang cluster admin.

Pesan error palsu tentang vCenter.dataDisk

Untuk cluster admin dengan ketersediaan tinggi, gkectl prepare menampilkan pesan error palsu ini:

vCenter.dataDisk must be present in the AdminCluster spec

Solusi:

Anda dapat mengabaikan pesan error ini dengan aman.

Pembuatan node pool gagal karena aturan afinitas VM-Host yang berlebihan

Selama pembuatan node pool yang menggunakan afinitas VM-Host, kondisi persaingan dapat menyebabkan beberapa aturan afinitas VM-Host dibuat dengan nama yang sama. Hal ini dapat menyebabkan pembuatan node pool gagal.

Solusi:

Hapus aturan lama yang berlebihan agar pembuatan node pool dapat dilanjutkan. Aturan ini diberi nama [USER_CLUSTER_NAME]-[HASH].

gkectl repair admin-master dapat gagal karena failed to delete the admin master node object and reboot the admin master VM

Perintah gkectl repair admin-master mungkin gagal karena kondisi persaingan dengan error berikut.

Failed to repair: failed to delete the admin master node object and reboot the admin master VM

Solusi:

Perintah ini bersifat idempoten. Dapat dijalankan kembali dengan aman hingga perintah berhasil.

Pod tetap dalam status Gagal setelah pembuatan ulang atau update node bidang kontrol

Setelah Anda membuat ulang atau memperbarui node bidang kontrol, Pod tertentu mungkin ditinggalkan dalam status Failed karena kegagalan predikat NodeAffinity. Pod yang gagal ini tidak memengaruhi operasi atau kesehatan cluster normal.

Solusi:

Anda dapat mengabaikan Pod yang gagal atau menghapusnya secara manual.

OnPremUserCluster tidak siap karena kredensial registry pribadi

Jika Anda menggunakan kredensial siap pakai dan registry pribadi, tetapi Anda belum mengonfigurasi kredensial siap pakai untuk registry pribadi, OnPremUserCluster mungkin tidak siap, dan Anda mungkin melihat pesan error berikut:

failed to check secret reference for private registry …

Solusi:

Siapkan kredensial registry pribadi untuk cluster pengguna sesuai dengan petunjuk di Mengonfigurasi kredensial yang disiapkan.

gkectl upgrade admin gagal dengan StorageClass standard sets the parameter diskformat which is invalid for CSI Migration

Selama gkectl upgrade admin, pemeriksaan pra-penerbangan penyimpanan untuk Migrasi CSI memverifikasi bahwa StorageClass tidak memiliki parameter yang diabaikan setelah Migrasi CSI. Misalnya, jika ada StorageClass dengan parameter diskformat, maka gkectl upgrade admin akan menandai StorageClass dan melaporkan kegagalan dalam validasi pra-penerbangan. Cluster admin yang dibuat di Google Distributed Cloud 1.10 dan sebelumnya memiliki StorageClass dengan diskformat: thin yang akan gagal dalam validasi ini, tetapi StorageClass ini tetap berfungsi dengan baik setelah Migrasi CSI. Kegagalan ini harus ditafsirkan sebagai peringatan.

Untuk mengetahui informasi selengkapnya, lihat bagian parameter StorageClass di Memigrasikan Volume vSphere In-Tree ke Plugin Penyimpanan Kontainer vSphere.

Solusi:

Setelah mengonfirmasi bahwa cluster Anda memiliki StorageClass dengan parameter yang diabaikan setelah Migrasi CSI jalankan gkectl upgrade admin dengan tanda --skip-validation-cluster-health.

Volume vSphere dalam tree yang dimigrasikan menggunakan sistem file Windows tidak dapat digunakan dengan driver CSI vSphere

Dalam kondisi tertentu, disk dapat dilampirkan sebagai hanya baca ke node Windows. Hal ini menyebabkan volume yang sesuai menjadi hanya baca di dalam Pod. Masalah ini lebih mungkin terjadi saat sekumpulan node baru menggantikan sekumpulan node lama (misalnya, upgrade cluster atau update node pool). Workload stateful yang sebelumnya berfungsi dengan baik mungkin tidak dapat menulis ke volumenya pada kumpulan node baru.

Solusi:

1. Dapatkan UID Pod yang tidak dapat menulis ke volumenya:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
       POD_NAME --namespace POD_NAMESPACE \
       -o=jsonpath='{.metadata.uid}{"\n"}'

2. Gunakan PersistentVolumeClaim untuk mendapatkan nama PersistentVolume:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
       PVC_NAME --namespace POD_NAMESPACE \
       -o jsonpath='{.spec.volumeName}{"\n"}'

3. Tentukan nama node tempat Pod berjalan:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
       --namespace POD_NAMESPACE \
       -o jsonpath='{.spec.nodeName}{"\n"}'

4. Dapatkan akses PowerShell ke node, baik melalui SSH atau antarmuka web vSphere.
5. Menetapkan variabel lingkungan:

   PS C:\Users\administrator> pvname=PV_NAME
   PS C:\Users\administrator> podid=POD_UID

6. Identifikasi nomor disk untuk disk yang terkait dengan PersistentVolume:

   PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
   "C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber

7. Verifikasi bahwa disk adalah readonly:

   PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly

   Hasilnya harus True.
8. Tetapkan readonly ke false.

   PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
   PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly

9. Hapus Pod agar dimulai ulang:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
       --namespace POD_NAMESPACE

10. Pod akan dijadwalkan ke node yang sama. Namun, jika Pod dijadwalkan ke node baru, Anda mungkin perlu mengulangi langkah-langkah sebelumnya di node baru.

vsphere-csi-secret tidak diperbarui setelah gkectl update credentials vsphere --admin-cluster

Jika Anda memperbarui kredensial vSphere untuk cluster admin setelah memperbarui kredensial cluster, Anda mungkin menemukan vsphere-csi-secret di namespace kube-system di cluster admin masih menggunakan kredensial lama.

Solusi:

1. Dapatkan nama secret vsphere-csi-secret:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret

2. Perbarui data rahasia vsphere-csi-secret yang Anda dapatkan dari langkah di atas:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
     "{\"data\":{\"config\":\"$( \
       kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
         | base64 -d \
         | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
         | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
         | base64 -w 0 \
       )\"}}"

3. Mulai ulang vsphere-csi-controller:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller

4. Anda dapat melacak status peluncuran dengan:

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller

   Setelah deployment berhasil diluncurkan, vsphere-csi-secret yang telah diupdate harus digunakan oleh pengontrol.

audit-proxy crashloop saat mengaktifkan Cloud Audit Logs dengan gkectl update cluster

audit-proxy mungkin mengalami loop error karena --cluster-name kosong. Perilaku ini disebabkan oleh bug dalam logika update, di mana nama cluster tidak diteruskan ke manifes pod / container audit-proxy.

Solusi:

Untuk cluster pengguna v2 bidang kontrol dengan enableControlplaneV2: true, hubungkan ke mesin bidang kontrol pengguna menggunakan SSH, lalu update /etc/kubernetes/manifests/audit-proxy.yaml dengan --cluster_name=USER_CLUSTER_NAME.

Untuk cluster pengguna v1 control plane, edit penampung audit-proxy di statefulset kube-apiserver untuk menambahkan --cluster_name=USER_CLUSTER_NAME:

kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Penyiapan ulang bidang kontrol tambahan tepat setelah gkectl upgrade cluster

Segera setelah gkectl upgrade cluster, pod bidang kontrol mungkin di-deploy ulang. Status cluster dari gkectl list clusters berubah dari RUNNING menjadi RECONCILING. Permintaan ke cluster pengguna mungkin mengalami waktu tunggu habis.

Perilaku ini terjadi karena rotasi sertifikat bidang kontrol terjadi secara otomatis setelah gkectl upgrade cluster.

Masalah ini hanya terjadi pada cluster pengguna yang TIDAK menggunakan bidang kontrol v2.

Solusi:

Tunggu hingga status cluster berubah kembali menjadi RUNNING di gkectl list clusters, atau upgrade ke versi dengan perbaikan: 1.13.6+, 1.14.2+, atau 1.15+.

Rilis buruk 1.12.7-gke.19 telah dihapus

Google Distributed Cloud 1.12.7-gke.19 adalah rilis yang buruk dan Anda tidak boleh menggunakannya. Artefak telah dihapus dari bucket Cloud Storage.

Solusi:

Gunakan rilis 1.12.7-gke.20 sebagai gantinya.

gke-connect-agent terus menggunakan image yang lebih lama setelah kredensial registry diperbarui

Jika Anda memperbarui kredensial registri menggunakan salah satu metode berikut:

• gkectl update credentials componentaccess jika tidak menggunakan registry pribadi
• gkectl update credentials privateregistry jika menggunakan registry pribadi

Anda mungkin mendapati bahwa gke-connect-agent terus menggunakan image yang lebih lama atau pod gke-connect-agent tidak dapat ditarik karena ImagePullBackOff.

Masalah ini akan diperbaiki dalam rilis Google Distributed Cloud 1.13.8, 1.14.4, dan rilis berikutnya.

Solusi:

Opsi 1: Deploy ulang gke-connect-agent secara manual:

1. Hapus namespace gke-connect:

   kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect

2. Deploy ulang gke-connect-agent dengan kunci akun layanan pendaftaran asli (tidak perlu memperbarui kunci):
   Untuk cluster admin:

   gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster

   Untuk cluster pengguna:

   gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

Opsi 2: Anda dapat mengubah data secret penarikan image secara manual regcred yang digunakan oleh deployment gke-connect-agent:

kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

Opsi 3: Anda dapat menambahkan secret penarikan gambar default untuk cluster di deployment gke-connect-agent dengan:

1. Salin secret default ke namespace gke-connect:

   kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -

2. Dapatkan nama deployment gke-connect-agent:

   kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent

3. Tambahkan secret default ke deployment gke-connect-agent:

   kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'

Kegagalan pemeriksaan konfigurasi LB manual

Saat Anda memvalidasi konfigurasi sebelum membuat cluster dengan Load balancer manual dengan menjalankan gkectl check-config, perintah akan gagal dengan pesan error berikut.

 - Validation Category: Manual LB    Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference

Solusi:

Opsi 1: Anda dapat menggunakan versi patch 1.13.7 dan 1.14.4 yang akan menyertakan perbaikan.

Opsi 2: Anda juga dapat menjalankan perintah yang sama untuk memvalidasi konfigurasi, tetapi melewati validasi load balancer.

gkectl check-config --skip-validation-load-balancer

kelaparan etcd watch

Cluster yang menjalankan etcd versi 3.4.13 atau yang lebih lama dapat mengalami kekurangan watch dan watch resource yang tidak beroperasi, yang dapat menyebabkan masalah berikut:

• Penjadwalan Pod terganggu
• Node tidak dapat mendaftar
• kubelet tidak mengamati perubahan pod

Masalah ini dapat membuat cluster tidak berfungsi.

Masalah ini telah diperbaiki di rilis Google Distributed Cloud 1.12.7, 1.13.6, 1.14.3, dan rilis berikutnya. Rilis yang lebih baru ini menggunakan etcd versi 3.4.21. Semua versi Google Distributed Cloud sebelumnya terpengaruh oleh masalah ini.

Solusi

Jika tidak dapat mengupgrade segera, Anda dapat mengurangi risiko kegagalan cluster dengan mengurangi jumlah node dalam cluster. Hapus node hingga metrik etcd_network_client_grpc_sent_bytes_total kurang dari 300 MBps.

Untuk melihat metrik ini di Metrics Explorer:

1. Buka Metrics Explorer di Google Cloud konsol:

   Buka Metrics Explorer

2. Pilih tab Configuration
3. Luaskan Pilih metrik, masukkan Kubernetes Container di panel filter, lalu gunakan submenu untuk memilih metrik:
   1. Di menu Active resources, pilih Kubernetes Container.
   2. Di menu Active metric categories, pilih Anthos.
   3. Di menu Active metrics, pilih etcd_network_client_grpc_sent_bytes_total.
   4. Klik Terapkan.

GKE Identity Service dapat menyebabkan latensi bidang kontrol

Saat cluster dimulai ulang atau diupgrade, GKE Identity Service dapat terbebani dengan traffic yang terdiri dari token JWT yang sudah habis masa berlakunya yang diteruskan dari kube-apiserver ke GKE Identity Service melalui webhook autentikasi. Meskipun GKE Identity Service tidak mengalami crashloop, layanan ini menjadi tidak responsif dan berhenti melayani permintaan lebih lanjut. Masalah ini pada akhirnya menyebabkan latensi bidang kontrol yang lebih tinggi.

Masalah ini telah diperbaiki dalam rilis Google Distributed Cloud berikut:

• 1.12.6+
• 1.13.6+
• 1.14.2+

Untuk menentukan apakah Anda terpengaruh oleh masalah ini, lakukan langkah-langkah berikut:

1. Periksa apakah endpoint GKE Identity Service dapat dijangkau secara eksternal:

   curl -s -o /dev/null -w "%{http_code}" \
       -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

   Ganti CLUSTER_ENDPOINT dengan VIP bidang kontrol dan port load balancer bidang kontrol untuk cluster Anda (misalnya, 172.16.20.50:443).

   Jika Anda terpengaruh oleh masalah ini, perintah akan menampilkan kode status 400. Jika permintaan kehabisan waktu, mulai ulang Pod ais dan jalankan kembali perintah curl untuk melihat apakah tindakan tersebut dapat menyelesaikan masalah. Jika Anda mendapatkan kode status 000, masalah telah teratasi dan Anda telah selesai. Jika Anda masih mendapatkan kode status 400, berarti server HTTP GKE Identity Service tidak dimulai. Dalam hal ini, lanjutkan.

2. Periksa log GKE Identity Service dan kube-apiserver:
   1. Periksa log GKE Identity Service:

      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
          --kubeconfig KUBECONFIG

      Jika log berisi entri seperti berikut, berarti Anda terpengaruh oleh masalah ini:

      I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:

   2. Periksa log kube-apiserver untuk cluster Anda:

      Dalam perintah berikut, KUBE_APISERVER_POD adalah nama Pod kube-apiserver di cluster tertentu.

      Cluster admin:

      kubectl --kubeconfig ADMIN_KUBECONFIG logs \
          -n kube-system KUBE_APISERVER_POD kube-apiserver

      Cluster pengguna:

      kubectl --kubeconfig ADMIN_KUBECONFIG logs \
          -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

      Jika log kube-apiserver berisi entri seperti berikut, maka Anda terpengaruh oleh masalah ini:

      E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
      E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

Solusi

Jika Anda tidak dapat mengupgrade cluster Anda segera untuk mendapatkan perbaikan, Anda dapat mengidentifikasi dan memulai ulang pod yang bermasalah sebagai solusi:

1. Tingkatkan tingkat keaktifan Identity Service GKE menjadi 9:

   kubectl patch deployment ais -n anthos-identity-service --type=json \
       -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
       "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
       --kubeconfig KUBECONFIG

2. Periksa log GKE Identity Service untuk mengetahui konteks token yang tidak valid:

   kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
       --kubeconfig KUBECONFIG

3. Untuk mendapatkan payload token yang terkait dengan setiap konteks token yang tidak valid, parsing setiap secret akun layanan terkait dengan perintah berikut:

   kubectl -n kube-system get secret SA_SECRET \
       --kubeconfig KUBECONFIG \
       -o jsonpath='{.data.token}' | base64 --decode

4. Untuk mendekode token dan melihat nama pod sumber dan namespace, salin token ke debugger di jwt.io.
5. Mulai ulang pod yang diidentifikasi dari token.

Masalah peningkatan penggunaan memori pod etcd-maintenance

Pod pemeliharaan etcd yang menggunakan image etcddefrag:gke_master_etcddefrag_20210211.00_p0 terpengaruh. Kontainer `etcddefrag` membuka koneksi baru ke server etcd selama setiap siklus defrag dan koneksi lama tidak dibersihkan.

Solusi:

Opsi 1: Upgrade ke versi patch terbaru dari 1.8 ke 1.11 yang berisi perbaikan.

Opsi 2: Jika Anda menggunakan versi patch yang lebih lama dari 1.9.6 dan 1.10.3, Anda perlu menskalakan pod etcd-maintenance untuk cluster admin dan pengguna:

kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Tidak ada health check pod bidang kontrol cluster pengguna

Pengontrol kondisi cluster dan perintah gkectl diagnose cluster melakukan serangkaian health check, termasuk health check pod di seluruh namespace. Namun, mereka mulai melewati pod bidang kontrol pengguna secara keliru. Jika Anda menggunakan mode bidang kontrol v2, hal ini tidak akan memengaruhi cluster Anda.

Solusi:

Hal ini tidak akan memengaruhi pengelolaan cluster atau beban kerja. Jika ingin memeriksa kondisi pod bidang kontrol, Anda dapat menjalankan perintah berikut:

kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Upgrade cluster admin 1.6 dan 1.7 mungkin terpengaruh oleh pengalihan k8s.gcr.io -> registry.k8s.io

Kubernetes mengarahkan ulang traffic dari k8s.gcr.io ke registry.k8s.io pada 20/3/2023. Di Google Distributed Cloud 1.6.x dan 1.7.x, upgrade cluster admin menggunakan image container k8s.gcr.io/pause:3.2. Jika Anda menggunakan proxy untuk workstation admin dan proxy tidak mengizinkan registry.k8s.io serta image container k8s.gcr.io/pause:3.2 tidak di-cache secara lokal, upgrade cluster admin akan gagal saat menarik image container.

Solusi:

Tambahkan registry.k8s.io ke daftar yang diizinkan untuk proxy workstation admin Anda.

Kegagalan validasi Seesaw saat pembuatan load balancer

gkectl create loadbalancer gagal dengan pesan error berikut:

- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

Hal ini karena file grup jungkat-jungkit sudah ada. Selain itu, pemeriksaan pra-penerbangan mencoba memvalidasi load balancer seesaw yang tidak ada.

Solusi:

Hapus file grup jungkat-jungkit yang ada untuk cluster ini. Nama file adalah seesaw-for-gke-admin.yaml untuk cluster admin, dan seesaw-for-{CLUSTER_NAME}.yaml untuk cluster pengguna.

Waktu tunggu aplikasi habis karena kegagalan penyisipan tabel conntrack

Google Distributed Cloud versi 1.14 rentan terhadap kegagalan penyisipan tabel pelacakan koneksi (conntrack) netfilter saat menggunakan image sistem operasi Ubuntu atau COS. Kegagalan penyisipan menyebabkan aplikasi kehabisan waktu secara acak dan dapat terjadi meskipun tabel conntrack memiliki ruang untuk entri baru. Kegagalan disebabkan oleh perubahan pada kernel 5.15 dan yang lebih tinggi yang membatasi penyisipan tabel berdasarkan panjang rantai.

Untuk melihat apakah Anda terpengaruh oleh masalah ini, Anda dapat memeriksa statistik sistem pelacakan koneksi dalam kernel di setiap node dengan perintah berikut:

sudo conntrack -S

Responsnya akan terlihat seperti ini:

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

Jika nilai chaintoolong dalam respons adalah angka selain nol, Anda terpengaruh oleh masalah ini.

Solusi

Mitigasi jangka pendek adalah dengan meningkatkan ukuran tabel hash netfilter (nf_conntrack_buckets) dan tabel pelacakan koneksi netfilter (nf_conntrack_max). Gunakan perintah berikut di setiap node cluster untuk meningkatkan ukuran tabel:

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Ganti TABLE_SIZE dengan ukuran baru dalam byte. Nilai ukuran tabel default adalah 262144. Sebaiknya tetapkan nilai yang sama dengan 65.536 kali jumlah core di node. Misalnya, jika node Anda memiliki delapan core, tetapkan ukuran tabel ke 524288.

Loop error calico-typha atau anetd-operator pada node Windows dengan Controlplane V2

Dengan Controlplane V2 diaktifkan, calico-typha atau anetd-operator mungkin dijadwalkan ke node Windows dan masuk ke loop error.

Alasannya adalah kedua deployment tersebut mentoleransi semua taint, termasuk taint node Windows.

Solusi:

Lakukan upgrade ke 1.13.3+, atau jalankan perintah berikut untuk mengedit deployment `calico-typha` atau `anetd-operator`:

    # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG
    

Hapus spec.template.spec.tolerations berikut:

    - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists
    

Lalu, tambahkan toleransi berikut:

    - key: node-role.kubernetes.io/master
      operator: Exists
    

File kredensial registry pribadi kluster pengguna tidak dapat dimuat

Anda mungkin tidak dapat membuat cluster pengguna jika Anda menentukan bagian privateRegistry dengan kredensial fileRef. Pemeriksaan awal mungkin gagal dengan pesan berikut:

[FAILURE] Docker registry access: Failed to login.

Solusi:

• Jika Anda tidak bermaksud menentukan kolom atau ingin menggunakan kredensial private registry yang sama dengan cluster admin, Anda cukup menghapus atau mengomentari bagian privateRegistry dalam file konfigurasi cluster pengguna.
• Jika ingin menggunakan kredensial registry pribadi tertentu untuk cluster pengguna, Anda dapat menentukan bagian privateRegistry untuk sementara dengan cara ini:

  privateRegistry:
    address: PRIVATE_REGISTRY_ADDRESS
    credentials:
      username: PRIVATE_REGISTRY_USERNAME
      password: PRIVATE_REGISTRY_PASSWORD
    caCertPath: PRIVATE_REGISTRY_CACERT_PATH

  (CATATAN: Ini hanya perbaikan sementara dan kolom ini sudah tidak digunakan lagi, pertimbangkan untuk menggunakan file kredensial saat mengupgrade ke 1.14.3+.)

Cloud Service Mesh dan mesh layanan lainnya tidak kompatibel dengan Dataplane v2

Dataplane V2 mengambil alih load balancing dan membuat soket kernel, bukan DNAT berbasis paket. Artinya, Cloud Service Mesh tidak dapat melakukan pemeriksaan paket karena pod dilewati dan tidak pernah menggunakan IPTables.

Hal ini terwujud dalam mode bebas kube-proxy dengan hilangnya konektivitas atau perutean traffic yang salah untuk layanan dengan Cloud Service Mesh sebagai sidecar karena tidak dapat melakukan pemeriksaan paket.

Masalah ini ada di semua versi Google Distributed Cloud 1.10, tetapi beberapa versi 1.10 yang lebih baru (1.10.2+) memiliki solusi.

Solusi:

Upgrade ke 1.11 untuk kompatibilitas penuh atau jika menjalankan 1.10.2 atau yang lebih baru, jalankan:

    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
    

Tambahkan bpf-lb-sock-hostns-only: true ke configmap, lalu mulai ulang daemonset anetd:

      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
    

kube-controller-manager dapat melepaskan volume persisten secara paksa setelah 6 menit

kube-controller-manager mungkin mengalami waktu tunggu saat melepaskan PV/PVC setelah 6 menit, dan melepaskan PV/PVC secara paksa. Log mendetail dari kube-controller-manager menampilkan peristiwa yang mirip dengan berikut:

$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

Untuk memverifikasi masalah ini, login ke node dan jalankan perintah berikut:

# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

Dalam log kubelet, error seperti berikut ditampilkan:

Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

Solusi:

Hubungkan ke node yang terpengaruh menggunakan SSH dan mulai ulang node.

Upgrade cluster terhenti jika driver CSI pihak ketiga digunakan

Anda mungkin tidak dapat mengupgrade cluster jika menggunakan driver CSI pihak ketiga. Perintah gkectl cluster diagnose mungkin menampilkan error berikut:

"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"

Solusi:

Lakukan upgrade menggunakan opsi --skip-validation-all.

gkectl repair admin-master membuat VM master admin tanpa mengupgrade versi hardware VM-nya

Node master admin yang dibuat melalui gkectl repair admin-master dapat menggunakan versi hardware VM yang lebih rendah dari yang diharapkan. Saat masalah terjadi, Anda akan melihat error dari laporan gkectl diagnose cluster.

CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.

Solusi:

Nonaktifkan node master admin, ikuti https://kb.vmware.com/s/article/1003746 untuk mengupgrade node ke versi yang diharapkan yang dijelaskan dalam pesan error, lalu mulai node.

VM melepaskan lease DHCP saat dimatikan/di-reboot secara tidak terduga, yang dapat mengakibatkan perubahan IP

Di systemd v244, systemd-networkd memiliki perubahan perilaku default pada konfigurasi KeepConfiguration. Sebelum perubahan ini, VM tidak mengirim pesan pelepasan lease DHCP ke server DHCP saat dimatikan atau dimulai ulang. Setelah perubahan ini, VM akan mengirim pesan tersebut dan mengembalikan IP ke server DHCP. Akibatnya, IP yang dilepaskan dapat dialokasikan ulang ke VM lain dan/atau IP lain dapat ditetapkan ke VM, sehingga menyebabkan konflik IP (di tingkat Kubernetes, bukan tingkat vSphere) dan/atau perubahan IP pada VM, yang dapat merusak cluster dengan berbagai cara.

Misalnya, Anda mungkin melihat gejala berikut.

• UI vCenter menunjukkan bahwa tidak ada VM yang menggunakan IP yang sama, tetapi kubectl get nodes -o wide menampilkan node dengan IP duplikat.

  NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
  node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
  node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13

• Node baru gagal dimulai karena error calico-node

  2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
  2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
  2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
  2023-01-19T22:07:08.828218856Z Calico node failed to start

Solusi:

Deploy DaemonSet berikut di cluster untuk mengembalikan perubahan perilaku default systemd-networkd. VM yang menjalankan DaemonSet ini tidak akan melepaskan IP ke server DHCP saat dimatikan/di-reboot. IP akan otomatis dibebaskan oleh server DHCP saat masa berlaku sewa berakhir.

      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule
      

Kunci akun layanan akses komponen dihapus setelah cluster admin diupgrade dari 1.11.x

Masalah ini hanya akan memengaruhi cluster admin yang diupgrade dari 1.11.x, dan tidak akan memengaruhi cluster admin yang baru dibuat setelah 1.12.

Setelah mengupgrade cluster 1.11.x ke 1.12.x, kolom component-access-sa-key di admin-cluster-creds secret akan dihapus menjadi kosong. Hal ini dapat diperiksa dengan menjalankan perintah berikut:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'

Setelah kunci akun layanan akses komponen dihapus, penginstalan cluster pengguna baru atau upgrade cluster pengguna yang ada akan gagal. Berikut adalah beberapa pesan error yang mungkin Anda temui:

• Kegagalan pra-penerbangan validasi lambat dengan pesan error: "Failed to create the test VMs: failed to get service account key: service account is not configured."
• Penyiapan gkectl prepare gagal dengan pesan error: "Failed to prepare OS images: dialing: unexpected end of JSON input"
• Jika Anda mengupgrade cluster pengguna 1.13 menggunakan konsol Google Cloud atau gcloud CLI, saat Anda menjalankan gkectl update admin --enable-preview-user-cluster-central-upgrade untuk men-deploy pengontrol platform upgrade, perintah akan gagal dengan pesan: "failed to download bundle to disk: dialing: unexpected end of JSON input" (Anda dapat melihat pesan ini di kolom status dalam output kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).

Solusi:

Tambahkan kembali kunci akun layanan akses komponen ke secret secara manual dengan menjalankan perintah berikut:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -

Autoscaler cluster tidak berfungsi saat Controlplane V2 diaktifkan

Untuk cluster pengguna yang dibuat dengan Controlplane V2 diaktifkan, node pool dengan penskalaan otomatis yang diaktifkan selalu menggunakan autoscaling.minReplicas-nya di user-cluster.yaml. Log pod cluster-autoscaler menampilkan error yang mirip dengan berikut:

  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
  

  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s
  

Solusi:

Nonaktifkan penskalaan otomatis di semua node pool dengan `gkectl update cluster` hingga mengupgrade ke versi dengan perbaikan

CIDR tidak diizinkan dalam file blok IP

Saat pengguna menggunakan CIDR dalam file blok IP, validasi konfigurasi akan gagal dengan error berikut:

- Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30
  

Solusi:

Sertakan IP individual dalam file blok IP hingga mengupgrade ke versi dengan perbaikan: 1.12.5, 1.13.4, 1.14.1+.

Pembaruan jenis image OS di admin-cluster.yaml tidak menunggu hingga mesin bidang kontrol pengguna dibuat ulang

Saat Memperbarui jenis image OS bidang kontrol di admin-cluster.yaml, dan jika cluster penggunanya dibuat dengan enableControlplaneV2 disetel ke true, mesin bidang kontrol pengguna mungkin tidak menyelesaikan pembuatan ulang saat perintah gkectl selesai.

Solusi:

Setelah update selesai, terus tunggu hingga mesin bidang kontrol pengguna juga selesai dibuat ulang dengan memantau jenis image OS node-nya menggunakan kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Misalnya, jika mengupdate dari Ubuntu ke COS, kita harus menunggu hingga semua mesin control plane sepenuhnya berubah dari Ubuntu ke COS, bahkan setelah perintah update selesai.

Error pembuatan atau penghapusan pod karena masalah token autentikasi akun layanan Calico CNI

Masalah pada Calico di Google Distributed Cloud 1.14.0 menyebabkan pembuatan dan penghapusan Pod gagal dengan pesan error berikut di output kubectl describe pods: