Masalah umum GKE di VMware

Halaman ini mencantumkan semua masalah umum terkait GKE di VMware. Untuk memfilter masalah umum menurut versi atau kategori produk, pilih filter yang diinginkan dari menu drop-down berikut.

Pilih GKE pada versi VMware:

Pilih kategori masalah Anda:

Atau, telusuri masalah Anda:

Kategori Versi yang diidentifikasi Masalah dan solusi
update 1,15, 1,16, 1,28

Dependensi trident Netapp mengganggu driver CSI vSphere

Menginstal multipathd pada node cluster dapat mengganggu driver CSI vSphere, sehingga beban kerja pengguna tidak dapat dimulai.

Solusi:

  • Nonaktifkan multipathd
Update 1,15, 1,16

Webhook cluster admin mungkin memblokir update saat Anda menambahkan konfigurasi yang diperlukan

Jika beberapa konfigurasi yang diperlukan kosong di cluster admin karena validasi dilewati, penambahan konfigurasi mungkin akan diblokir oleh webhook cluster admin. Misalnya, jika kolom gkeConnect tidak ditetapkan dalam cluster admin yang sudah ada, menambahkannya dengan perintah gkectl update admin mungkin akan mendapatkan pesan error berikut:


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

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
Konfigurasi 1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200

Kolom controlPlaneNodePort ditetapkan secara default ke 30968 jika spesifikasi manualLB kosong

Jika Anda akan menggunakan load balancer manual (loadBalancer.kind ditetapkan ke "ManualLB"), Anda tidak perlu mengonfigurasi bagian loadBalancer.manualLB dalam file konfigurasi untuk cluster admin ketersediaan tinggi (HA) dalam versi 1.16 dan yang lebih baru. Namun, jika bagian ini kosong, GKE di VMware akan menetapkan nilai default ke semua NodePorts, 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 di konfigurasi cluster admin Anda untuk cluster admin dengan ketersediaan tinggi (HA):


loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...
Penyimpanan 1.28.0-1.28.100

nfs-common tidak ada di OS image Ubuntu

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

Jika log berisi entri seperti berikut setelah mengupgrade ke versi 1.28, maka Anda akan terpengaruh oleh masalah ini: 

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

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: /
Penyimpanan 1.28.0-1.28.100

Kolom kebijakan penyimpanan tidak ada di template konfigurasi cluster admin

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

Solusi:

Tambahkan kolom `vCenter.storagePolicyName` di file konfigurasi cluster admin jika Anda ingin mengonfigurasi kebijakan penyimpanan untuk cluster admin. Lihat instructions.
Logging dan pemantauan 1.28.0-1.28.100

Kubernetes Metadata API tidak mendukung VPC-SC

API kubernetesmetadata.googleapis.com yang baru ditambahkan tidak mendukung VPC-SC. Hal ini akan menyebabkan agen pengumpul metadata gagal menjangkau API ini berdasarkan VPC-SC. Setelah itu, label metadata metrik akan hilang.

Solusi:

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

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

kemudian 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"}]}]}}}}'`

Upgrade dan update 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

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

Saat cluster admin dan cluster pengguna dengan ControlPlane V2 aktif 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
Jika log berisi entri seperti berikut, berarti Anda terpengaruh oleh masalah ini: 

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 yang mengaktifkan Controlplane V2 menggunakan kredensial vSphere yang sama.

Logging dan pemantauan 1,14

etcd jumlah permintaan GRPC yang gagal yang tinggi di Prometheus Alert Manager

Prometheus mungkin melaporkan peringatan 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 pemberitahuan 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. Pemberitahuan untuk semua kode selain OK dapat diabaikan dengan aman jika kode bukan salah satu dari kode berikut: 
    
Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Solusi:

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

  1. Senyapkan pemberitahuan dari UI Alert Manager.
  2. Jika menonaktifkan pemberitahuan tidak dapat dilakukan, tinjau langkah-langkah berikut untuk menekan positif palsu (PP):
    1. Turunkan skala operator pemantauan menjadi replika 0 agar modifikasi dapat dipertahankan.
    2. Ubah configmap prometheus-config, dan 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 Prometheus dan Alertmanager Statefulset 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.
Networking 1.16.0-1.16.2, 1.28.0

Koneksi keluar yang berumur panjang NAT terputus

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

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

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


Solusi:

Tidak ada solusi yang mudah, dan kami belum melihat masalah di versi 1.16 dari perilaku ini. Jika Anda melihat koneksi yang tahan lama terputus karena masalah ini, solusinya adalah menggunakan workload pada node yang sama dengan alamat IP keluar, atau untuk mengirim pesan secara konsisten di koneksi TCP.
Operasi 1,14, 1,15, 1,16

Penanda tangan CSR mengabaikan spec.expirationSeconds saat menandatangani sertifikat

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

Solusi:

Jika terpengaruh oleh masalah ini, Anda dapat memperbarui cluster pengguna dengan menambahkan disableNodeIDVerificationCSRSigning: true dalam file konfigurasi cluster pengguna dan menjalankan perintah gkectl update cluster untuk mengupdate cluster dengan konfigurasi ini.
Networking, Upgrade, dan update 1.16.0-1.16.3

Validasi load balancer cluster pengguna gagal untuk disable_bundled_ingress

Jika Anda mencoba menonaktifkan ingress yang dipaketkan untuk cluster yang 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 masuk load balancer selama pemeriksaan preflight. Meskipun pemeriksaan ini tidak diperlukan saat menonaktifkan ingress yang dipaketkan, pemeriksaan preflight gkectl akan gagal saat disableBundledIngress disetel ke true.


Solusi:

Gunakan parameter --skip-validation-load-balancer saat Anda mengupdate 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 yang dipaketkan untuk cluster yang ada.
Upgrade dan update 1.13, 1.14, 1.15.0-1.15.6

Pembaruan cluster admin gagal setelah rotasi CA

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


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

Solusi:

Jika terpengaruh oleh masalah ini, Anda dapat memperbarui cluster admin menggunakan flag --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 flag --disable-update-from-checkpoint, perintah update tidak menggunakan file checkpoint sebagai sumber tepercaya selama update cluster. File checkpoint masih diperbarui untuk digunakan di lain waktu.
Penyimpanan 1.15.0-1.15.6, 1.16.0-1.16.2

Pemeriksaan preflight Workload CSI gagal karena kegagalan startup Pod

Selama pemeriksaan preflight, pemeriksaan validasi Workload CSI akan 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 sejumlah masalah umum yang dapat mencegah Pod ini dimulai:

  • Jika Pod tidak memiliki batas resource yang ditentukan, yang terjadi pada beberapa cluster yang memiliki webhook akses masuk yang terinstal, Pod tidak akan dimulai.
  • Jika Anthos Service Mesh diinstal di cluster dengan injeksi file bantuan Istio otomatis yang diaktifkan di namespace default, Pod Workload CSI tidak akan dimulai.

Jika Pod Beban Kerja CSI tidak dimulai, Anda akan melihat error waktu tunggu seperti berikut selama validasi preflight:


- [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 melihat apakah kegagalan disebabkan oleh kurangnya set 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 menampilkan 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 file bantuan Istio, Anda dapat menonaktifkan injeksi file bantuan Istio otomatis untuk sementara di namespace default. Periksa label namespace dan gunakan perintah berikut untuk menghapus label yang dimulai 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. Membuat Pod yang menggunakan PVC.
  3. Verifikasi bahwa Pod dapat membaca/menulis data ke volume.
  4. Hapus Pod dan PVC setelah Anda memverifikasi operasi yang benar.

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

Operasi 1.16.0-1.16.2

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 habis waktu tunggunya dan gagal memperbarui cluster pengguna. Hal ini terjadi jika cluster admin adalah 1.15 dan Anda menjalankan gkectl update admin sebelum menjalankan gkectl update cluster. Jika 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 preflight akan dihapus dari cluster. Jika Anda kemudian mencoba memperbarui cluster pengguna, pemeriksaan preflight akan ditangguhkan hingga waktu tunggu habis.

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 kembali gkectl update cluster untuk memperbarui cluster pengguna
Operasi 1.16.0-1.16.2

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

Saat Anda login ke workstation admin yang dikelola pengguna, perintah gkectl create cluster mungkin habis waktu tunggunya dan gagal membuat cluster pengguna. Hal ini terjadi jika 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 pada 1.16, maka saat menggunakan cluster admin 1.15, validation-controller yang bertanggung jawab untuk memicu pemeriksaan preflight tidak ada. Oleh karena itu, saat mencoba membuat cluster pengguna, pemeriksaan preflight akan macet hingga waktu tunggu tercapai.

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 kembali gkectl create cluster untuk membuat cluster pengguna
Upgrade dan update 1.16.0-1.16.2

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

Jika Anda mengupgrade cluster admin dari versi 1.15.x ke 1.16.x, atau menambahkan konfigurasi connect, stackdriver, cloudAuditLogging, atau gkeOnPremAPI saat Anda mengupdate cluster admin, operasi 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 guna update atau upgrade. Beberapa validasi khusus buat dipanggil saat mengupdate 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 tersebut.
  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 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 dengan ketersediaan tinggi (HA) atau file checkpoint dinonaktifkan: update atau upgrade cluster admin seperti biasa. Tidak ada parameter tambahan yang diperlukan pada perintah update atau upgrade.
Operasi 1.16.0-1.16.2

Penghapusan cluster pengguna gagal saat menggunakan workstation admin yang dikelola pengguna

Saat Anda login ke workstation admin yang dikelola pengguna, perintah gkectl delete cluster mungkin habis waktu tunggunya dan gagal menghapus cluster pengguna. Hal ini terjadi jika Anda telah menjalankan gkectl terlebih dahulu 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 menghapus semua objeknya terlebih dahulu. Penghapusan objek Validation (yang dibuat saat pembuatan, pembaruan, atau upgrade) terhenti pada fase penghapusan. Hal ini terjadi karena resolver memblokir penghapusan objek, yang menyebabkan kegagalan penghapusan cluster.

Solusi:

  1. Mendapatkan nama semua objek Validation: 
    
         kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
  2. Untuk setiap objek Validation, jalankan perintah berikut untuk menghapus finalr dari objek Validation: 
    
      kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
        -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

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

Networking 1,15, 1,16

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 apa pun. Jika Pod tersebut berada di host yang sama, koneksi ke layanan atau aplikasi eksternal akan berhasil.

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


Solusi:

Ubah port VXLAN yang digunakan oleh Cilium ke 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 setiap kali setelah upgrade. VMware harus menyelesaikan masalah di vSphere untuk perbaikan permanen.
Upgrade 1.15.0-1.15.4

Gagal mengupgrade cluster admin yang mengaktifkan enkripsi secret selalu aktif

Upgrade cluster admin dari 1.14.x ke 1.15.x dengan enkripsi always-on secrets yang diaktifkan gagal karena ada ketidakcocokan antara kunci enkripsi yang dihasilkan 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, lalu update cluster menggunakan perintah berikut: 
    
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  2. Saat VM master admin baru dibuat, terapkan SSH ke VM master admin, ganti kunci baru pada disk data dengan kunci lama dari cadangan. Kunci ini terletak di /opt/data/gke-k8s-kms-plugin/generatedkeys pada master admin.
  3. Update manifes Pod statis kms-plugin.yaml di /etc/kubernetes/manifests untuk mengupdate --kek-id agar cocok dengan kolom kid di 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 upgrade ke versi 1.15.0-1.15.4. Jika Anda harus melakukan upgrade ke versi yang terpengaruh, lakukan langkah-langkah berikut sebelum mengupgrade cluster admin:

  1. Cadangkan cluster admin.
  2. Nonaktifkan secretsEncryption di file konfigurasi cluster admin, lalu update cluster menggunakan perintah berikut: 
    
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  3. Upgrade cluster admin.
  4. Aktifkan enkripsi secret yang selalu aktif.
Penyimpanan 1,11-1,16

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

GKE di VMware tidak mendukung Changed Block Tracking (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 GKE di VMware. Untuk mengetahui informasi selengkapnya, lihat artikel Pusat Informasi VMware.


Solusi:

Jangan cadangkan GKE di VM VMware, karena software pencadangan pihak ketiga dapat menyebabkan CBT diaktifkan di disk mereka. VM ini tidak perlu dicadangkan.

Jangan aktifkan CBT pada node, karena perubahan ini tidak akan dipertahankan pada update atau upgrade.

Jika Anda sudah memiliki disk dengan CBT aktif, ikuti langkah-langkah Resolution di artikel VMware KB untuk menonaktifkan CBT pada Disk Kelas Satu.
Penyimpanan 1,14, 1,15, 1,16

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

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


Solusi:

Artikel Pusat Informasi VMware tidak berlaku lagi dan menyatakan bahwa tidak ada resolusi saat ini. Untuk mengatasi masalah ini, update ESXi ke versi terbaru di host Anda dan ke versi Nutanix terbaru di array penyimpanan Anda.
Sistem operasi 1.13.10, 1.14.6, 1.15.3

Ketidakcocokan versi antara kubelet dan bidang kontrol Kubernetes

Untuk rilis GKE pada VMware tertentu, kubelet yang berjalan pada node menggunakan versi yang berbeda dengan bidang kontrol Kubernetes. Ada ketidakcocokan, karena biner kubelet yang dimuat sebelumnya pada OS image menggunakan versi berbeda.

Tabel berikut mencantumkan ketidakcocokan versi yang diidentifikasi:

GKE pada versi VMware versi kubelet Versi Kubernetes
1.13.10 v1.24.11-gke.1200 v1.24.14-gke.2100
1.14.6 v1.25.8-gke.1500 v1.25.10-gke.1200
1.15.3 v1.26.2-gke.1001 v1.26.5-gke.2100

Solusi:

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

Upgrade dan update 1.15.0-1.15.4

Gagal mengupgrade atau mengupdate cluster admin dengan versi CA yang lebih besar dari 1

Jika cluster admin memiliki versi certificate authority (CA) 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:

  • Turunkan 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 versi 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
Operasi 1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1

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

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

Solusi:

Jika cluster berisi StatefulSet dengan data penting, hubungi 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 lagi secara paksa: 
    
     gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

Penyimpanan 1.15.0+, 1.16.0+

Tugas lampiranvolume CNS konstan muncul setiap menit untuk PVC/PV dalam pohon setelah upgrade ke versi 1.15+

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


Solusi:

Edit configMap fitur vSphere CSI dan setel daftar-volume 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 vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Penyimpanan 1.16.0

Peringatan palsu tentang PVC

Jika cluster berisi volume persisten vSphere intree, perintah gkectl diagnose dan gkectl upgrade mungkin memberikan 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 ini 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
Upgrade dan update 1.15.0+, 1.16.0+

Rotasi kunci akun layanan gagal saat beberapa kunci 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) Anda sudah tidak berlaku, 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, rotasikan kunci akun layanan akses komponen. Meskipun pesan error yang sama ditampilkan, Anda seharusnya dapat merotasi kunci lain setelah rotasi kunci akun layanan akses komponen.

Jika pembaruan tetap tidak berhasil, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
Upgrade 1.16.0-1.16.5

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 lainnya yang dikelola oleh cluster admin yang sama, mesin master pengguna mereka mungkin secara tidak terduga dibuat ulang.

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

Solusi yang Anda lakukan bergantung pada bagaimana Anda menghadapi masalah ini.

Solusi saat mengupgrade cluster pengguna menggunakan Konsol Google Cloud:

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

Opsi 2: Lakukan langkah-langkah berikut:

  1. Tambahkan anotasi rerun secara manual dengan perintah berikut: 
    
kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

    Anotasi jalankan ulang adalah:

    
onprem.cluster.gke.io/server-side-preflight-rerun: true
  2. Pantau progres upgrade dengan mencentang kolom status di OnPremUserCluster.

Solusi saat mengupgrade cluster pengguna menggunakan workstation admin Anda sendiri:

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

Opsi 2: Lakukan langkah-langkah berikut:

  1. Tambahkan file info build /etc/cloud/build.info dengan konten berikut. Hal ini menyebabkan pemeriksaan preflight berjalan secara lokal di workstation admin, 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.
Buat 1.16.0-1.16.5, 1.28.0-1.28.100

Pemeriksaan preflight gagal jika 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 preflight 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 preflight yang menganggap nama host kosong sebagai duplikat.

Solusi:

Opsi 1: Gunakan versi yang telah diperbaiki.

Opsi 2: Abaikan pemeriksaan preflight ini dengan menambahkan tanda --skip-validation-net-config.

Opsi 3: Tentukan nama host unik untuk setiap alamat IP di file blok IP.
Upgrade dan update 1.16.0

Node bidang kontrol gagal dibuat

Selama upgrade atau update cluster admin, kondisi race dapat menyebabkan pengelola pengontrol cloud vSphere menghapus node bidang kontrol baru secara tidak terduga. Hal ini menyebabkan clusterapi-controller terhenti saat menunggu node dibuat, dan bahkan waktu upgrade/update habis. Dalam hal ini, output perintah upgrade/update gkectl 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 perangkat yang gagal untuk membuat ulang objek node yang dihapus.
  2. SSH ke setiap node bidang kontrol dan mulai ulang pod statis pengelola cloud controller vSphere: 
    
      sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
  3. Jalankan kembali perintah upgrade/update.
Operasi 1.16

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

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

Untuk mengidentifikasi masalah, dapatkan log pod pengelola cloud controller vSphere untuk cluster tersebut. Perintah yang digunakan 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 (kubeception): 
    
      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: (Controlplane V2): 
    
      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:

Anda dapat menggunakan pendekatan berikut untuk memeriksa apakah nama host duplikat, dan melakukan solusi jika diperlukan. 

          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
Contoh perintah dan output: 

          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.

  • Cluster pengguna:
    1. Perbarui nama host mesin yang terpengaruh di user-ip-block.yaml menjadi nama yang unik dan picu update paksa:
      
          gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
    2. Jalankan kembali 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 non-HA, dan Anda mendapati admin master vm menggunakan nama host duplikat, Anda juga perlu:
      Mendapatkan nama mesin master admin 
      
          kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
      Update 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"}]'
      Pastikan 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 kembali upgrade cluster admin saat 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.
Operasi 1.16.0, 1.16.1, 1.16.2, 1.16.3

$ 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 diaktifkan ke versi 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 dengan ketersediaan tinggi (HA) 1,16

Gunakan GKE versi 1.16.4+ di VMware dengan perbaikan atau lakukan solusi di bawah ini. 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 kredensial Anda.
  3. Memicu update cluster paksa.
    • 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 kredensial Anda.
  3. Lakukan solusi untuk jenis cluster yang berlaku.
Penyimpanan 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

Kegagalan pembuatan PVC setelah node dibuat ulang dengan nama yang sama

Setelah node dihapus, lalu dibuat ulang dengan nama node yang sama, ada kemungkinan kecil bahwa pembuatan PersistentVolumeClaim (PVC) berikutnya 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 race saat pengontrol vSphere CSI tidak menghapus mesin yang dihapus dari cache-nya.


Solusi:

Mulai ulang pod pengontrol vSphere CSI:


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

perbaikan gkectl admin-master mengembalikan error kubeconfig unmarshall

Saat Anda menjalankan perintah gkectl repair admin-master di cluster admin dengan ketersediaan tinggi (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 flag --admin-master-vm-template= ke perintah dan berikan template VM mesin untuk 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 berdasarkan nama cluster admin.

    Anda akan melihat tiga template VM untuk cluster admin.

  3. Salin nama template VM yang cocok dengan nama perangkat yang Anda perbaiki dan gunakan nama template dalam perintah reparasi.

  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
Networking 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

VM Seesaw rusak karena kapasitas disk hampir habis

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


    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

Error ini menunjukkan bahwa kapasitas disk hampir habis pada VM karena bit fasih yang berjalan di Seesaw VM tidak dikonfigurasi dengan rotasi log yang benar.


Solusi:

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

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

Untuk mencegah masalah 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 di perintah Docker, lalu jalankan systemctl restart docker.fluent-bit.service
Operasi 1.13, 1.14.0-1.14.6, 1.15

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 GKE di VMware dengan perbaikan, hubungi Dukungan Google untuk mendapatkan bantuan.
Upgrade 1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

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

Saat cluster admin didaftarkan di GKE On-Prem API, upgrade cluster admin ke versi yang terpengaruh dapat gagal karena keanggotaan fleet 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 cluster secara eksplisit, atau saat mengupgrade cluster pengguna menggunakan klien GKE On-Prem API.


Solusi:

Batalkan pendaftaran cluster admin: 

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
dan lanjutkan upgrade cluster admin. Anda mungkin melihat pesan error `failed to register cluster` yang sudah tidak berlaku untuk sementara. Setelah beberapa saat, paket akan otomatis diupdate.
Upgrade dan update 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

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

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


Solusi:

Batalkan pendaftaran cluster admin: 

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
lalu daftarkan ulang cluster admin lagi.
Networking 1.15.0-1.15.2

CoreDNS orderPolicy tidak dikenali

OrderPolicy tidak dikenali sebagai parameter dan tidak digunakan. Sebagai gantinya, GKE di VMware selalu menggunakan Random.

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


Solusi:

Update template CoreDNS dan terapkan perbaikan. Perbaikan ini berlanjut hingga upgrade dilakukan.

  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 }}
Upgrade dan update 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

Status OnPremAdminCluster tidak konsisten antara checkpoint dan CR yang sebenarnya

Kondisi race tertentu dapat menyebabkan status OnPremAdminCluster menjadi tidak konsisten antara checkpoint dan CR yang sebenarnya. Jika masalah ini terjadi, Anda mungkin 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
Untuk mengatasi masalah ini, Anda harus mengedit checkpoint atau menonaktifkan checkpoint untuk upgrade/update. Hubungi tim dukungan kami untuk melanjutkan solusi tersebut.
Operasi 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Proses rekonsiliasi mengubah sertifikat admin pada cluster admin

GKE di VMware 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, terutama untuk cluster versi 1.15.

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

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

    Perintah ini mungkin 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:

Upgrade ke versi GKE di VMware dengan perbaikan: 1.13.10+, 1.14.6+, 1.15.2+. Jika upgrade tidak memungkinkan untuk Anda, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
Jaringan, Operasi 1,10, 1,11, 1,12, 1,13, 1,14

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

Pod gateway jaringan di kube-system mungkin menampilkan status Pending atau Evicted, seperti 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 penggusuran atau ketidakmampuan untuk menjadwalkan Pod karena resource node. Karena Pod Gateway Jaringan Anthos tidak memiliki PriorityClass, Pod tersebut memiliki prioritas default yang sama dengan workload lainnya. Jika node memiliki resource yang terbatas, Pod gateway jaringan mungkin akan dikeluarkan. Perilaku ini sangat buruk untuk DaemonSet ang-node, karena Pod tersebut harus dijadwalkan pada node tertentu dan tidak dapat dimigrasikan.


Solusi:

Upgrade ke versi 1.15 atau yang lebih baru.

Sebagai perbaikan jangka pendek, Anda dapat menetapkan PriorityClass ke komponen Gateway Jaringan Anthos secara manual. Pengontrol GKE pada VMware menimpa perubahan manual ini selama proses rekonsiliasi, seperti saat mengupgrade cluster.

  • Tetapkan PriorityClass system-cluster-critical ke Deployment pengontrol cluster ang-controller-manager dan autoscaler.
  • Tetapkan PriorityClass system-node-critical ke node ang-daemon DaemonSet.
Upgrade dan update 1.12, 1.13, 1.14, 1.15.0-1.15.2

upgrade cluster admin gagal setelah mendaftarkan cluster ke 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
Dapatkan nama cluster admin: 

kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Menghapus keanggotaan perangkat: 

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
dan lanjutkan upgrade cluster admin.
Operasi 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

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

Hal ini tidak memengaruhi fungsionalitas pengambilan snapshot cluster, karena snapshot masih menyertakan semua log yang dikumpulkan secara default dengan menjalankan journalctl pada node cluster. Oleh karena itu, tidak ada informasi proses debug yang terlewat.
Penginstalan, Peningkatan Versi, dan Pembaruan 1,9+, 1,10+, 1,11+, 1,12+

gkectl prepare windows gagal

gkectl prepare windows gagal menginstal Docker di GKE pada versi VMware yang lebih lama dari 1.13 karena MicrosoftDockerProvider tidak digunakan lagi.


Solusi:

Ide umum untuk mengatasi masalah ini adalah dengan mengupgrade ke GKE pada VMware 1.13 dan menggunakan gkectl 1.13 untuk membuat template VM Windows, lalu membuat kumpulan node Windows. Ada dua opsi untuk membuka GKE di VMware 1.13 dari versi saat ini seperti yang ditunjukkan di bawah ini.

Catatan: Kami memiliki opsi untuk menyelesaikan masalah ini pada versi Anda saat ini tanpa harus mengupgrade hingga versi 1.13, tetapi akan memerlukan lebih banyak langkah manual . Hubungi tim dukungan kami jika Anda ingin mempertimbangkan opsi ini.


Opsi 1: Upgrade Biru/Hijau

Anda dapat membuat cluster baru menggunakan GKE pada VMware 1.13+ versi dengan node pool Windows, dan memigrasikan workload ke cluster baru, kemudian menghapus cluster saat ini. Sebaiknya gunakan GKE terbaru di VMware versi minor.

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


Opsi 2: Menghapus node pool Windows dan menambahkannya kembali saat melakukan upgrade ke GKE pada VMware 1.13

Catatan: Untuk opsi ini, beban kerja Windows tidak akan dapat berjalan hingga cluster diupgrade ke versi 1.13 dan kumpulan node Windows ditambahkan kembali.

  1. Hapus pool node Windows yang sudah 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 pengguna untuk versi minor target yang sesuai.
  3. (Pastikan untuk melakukan langkah ini sebelum mengupgrade ke versi 1.13) Pastikan enableWindowsDataplaneV2: true dikonfigurasi di OnPremUserCluster CR. Jika tidak, cluster akan tetap menggunakan Docker untuk kumpulan node Windows. Jika tidak, cluster akan tetap menggunakan Docker untuk kumpulan node Windows. Hal ini tidak akan kompatibel dengan template VM Windows 1.13 yang baru dibuat dan tidak diinstal Docker. Jika tidak dikonfigurasi atau disetel ke salah (false), update cluster agar disetel ke benar (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 pengguna upgrade.
  5. Siapkan template VM Windows menggunakan versi 1.13 gkectl: 
    
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Tambahkan kembali konfigurasi kumpulan node Windows ke user-cluster.yaml dengan kolom OSImage yang disetel 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
Penginstalan, Peningkatan Versi, dan Pembaruan 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Konfigurasi RootDistanceMaxSec tidak diterapkan untuk ubuntu node

Nilai default 5 detik untuk RootDistanceMaxSec akan digunakan pada node, bukan 20 detik yang seharusnya merupakan konfigurasi yang diharapkan. Jika Anda memeriksa log startup node dengan menjalankan SSH ke VM, yang terletak 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 sinkron 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: /
Upgrade dan update 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

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 penetapan osImageType dari string kosong ke ubuntu_containerd.

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


Solusi:

Upgrade ke versi GKE di VMware setelah melakukan perbaikan. Jika upgrade tidak memungkinkan, hubungi Cloud Customer Care untuk mengatasi masalah ini.
Pemasangan, Keamanan 1,13, 1,14, 1,15, 1,16

SNI tidak berfungsi pada cluster pengguna dengan Controlplane V2

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


Solusi:

Sampai patch GKE pada VMware tersedia dengan perbaikan, jika Anda perlu menggunakan SNI, nonaktifkan Controlplane V2 (enableControlplaneV2: false).
Penginstalan 1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

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

Mesin bidang kontrol admin gagal dimulai jika nama pengguna registry pribadi berisi $. Saat memeriksa /var/log/startup.log pada mesin 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 GKE di VMware dengan perbaikan.
Upgrade dan update 1.12.0-1.12.4

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

Saat 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,
      ...
    }
Upgrade dan update 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Update cluster pengguna gagal setelah rotasi kunci penandatanganan KSA

Setelah Anda merotasi kunci penandatanganan KSA lalu 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:

Ubah versi kunci penandatanganan KSA Anda kembali ke 1, tetapi pertahankan data kunci terbaru:
  1. Periksa rahasia di cluster admin pada namespace USER_CLUSTER_NAME, lalu dapatkan nama rahasia ksa- signing-key: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. Salin rahasia 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 configmap ke '{"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 berdasarkan: 
    
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 lagi hingga cluster diupgrade ke versi dengan perbaikan.
Operasi 1.13.1+, 1.14, 1., 1.16

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

Ketika Anda menggunakan Terraform untuk menghapus cluster pengguna yang memiliki load balancer BIG-IP F5, server virtual F5 BIG-IP tidak akan dihapus setelah cluster dihapus.


Solusi:

Untuk menghapus resource F5, ikuti langkah-langkah untuk membersihkan partisi F5 cluster pengguna
Penginstalan, Peningkatan Versi, dan Pembaruan 1.13.8, 1.14.4

cluster jenis 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 jenis akan mengambil image container berikut dari docker.io:

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • Jika docker.io tidak dapat diakses dari workstation admin Anda, pembuatan atau upgrade cluster admin akan gagal memunculkan cluster jenis. Menjalankan perintah berikut di workstation admin akan menunjukkan penampung terkait yang tertunda dengan ErrImagePull:

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

    Respons 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 dipramuat dalam image container cluster jenis. Namun, jenis v0.18.0 memiliki masalah dengan image container yang telah dimuat sebelumnya, yang menyebabkan image tersebut diambil dari internet secara tidak sengaja.


    Solusi:

    Jalankan perintah berikut di workstation admin, sementara cluster admin Anda menunggu pembuatan atau upgrade:

    
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
    Operasi 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    Failover yang gagal pada cluster pengguna dan cluster admin dengan ketersediaan tinggi (HA) Controlplane V2 saat jaringan memfilter permintaan GARP duplikat

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

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


    Solusi:

    Jalankan perintah berikut pada setiap node bidang kontrol dari cluster yang terpengaruh: 
    
    iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Upgrade dan Update 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

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

    vsphere-csi-controller akan memperbarui rahasia 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 pada 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
    Penginstalan 1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1

    Pembuatan cluster admin tidak gagal pada error pendaftaran cluster

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

    Untuk mengidentifikasi gejala, Anda dapat mencari pesan error berikut di log `gkectl create admin`, 
    
Failed to register admin cluster

    Anda juga dapat memeriksa apakah cluster dapat ditemukan di antara cluster terdaftar di Cloud Console.

    Solusi:

    Untuk cluster yang dibuat di 1.12 dan versi yang lebih baru, ikuti petunjuk untuk mencoba kembali pendaftaran cluster admin setelah pembuatan cluster. Untuk {i>cluster<i} yang dibuat pada versi sebelumnya,

    1. Menambahkan key-value pair palsu seperti "foo: bar" ke file kunci SA connect-register
    2. Jalankan gkectl update admin untuk mendaftarkan ulang cluster admin.

    Upgrade dan Update 1.10, 1.11, 1.12, 1.13.0-1.13.1

    Pendaftaran ulang cluster admin mungkin dilewati selama upgrade cluster admin

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


    Solusi:

    Periksa apakah cluster muncul di antara cluster terdaftar. Sebagai langkah opsional, Login ke cluster setelah menyiapkan autentikasi. Jika cluster masih terdaftar, Anda dapat melewati petunjuk berikut untuk mencoba kembali pendaftaran. Untuk cluster yang diupgrade ke 1.12 dan versi yang lebih baru, ikuti petunjuk untuk mencoba kembali pendaftaran cluster admin setelah pembuatan cluster. Untuk cluster yang diupgrade ke versi sebelumnya,
    1. Menambahkan key-value pair palsu seperti "foo: bar" ke file kunci SA connect-register
    2. Jalankan gkectl update admin untuk mendaftarkan ulang cluster admin.

    Konfigurasi 1.15.0

    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 kesalahan ini dengan aman.
    VMware 1.15.0

    Pembuatan kumpulan node gagal karena aturan afinitas VM-Host yang redundan

    Selama pembuatan kumpulan node yang menggunakan afinitas VM-Host, kondisi race dapat mengakibatkan beberapa aturan afinitas VM-Host dibuat dengan nama yang sama. Hal ini dapat menyebabkan kegagalan pembuatan kumpulan node.


    Solusi:

    Hapus aturan lama yang berulang agar pembuatan kumpulan node dapat dilanjutkan. Aturan ini diberi nama [USER_CLUSTER_NAME]-[HASH].
    Operasi 1.15.0

    gkectl repair admin-master mungkin 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 race 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. SDK ini dapat berjalan kembali dengan aman hingga perintah berhasil.
    Upgrade dan update 1.15.0

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

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


    Solusi:

    Anda dapat mengabaikan Pod yang gagal atau menghapusnya secara manual.
    Keamanan, Konfigurasi 1.15.0-1.15.1

    OnPremUserCluster tidak siap karena kredensial registry pribadi

    Jika Anda menggunakan kredensial yang sudah disiapkan dan registry pribadi, tetapi Anda belum mengonfigurasi kredensial yang sudah disiapkan untuk registry pribadi Anda, OnPremUserCluster mungkin belum 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 dalam Mengonfigurasi kredensial yang sudah disiapkan.

    Upgrade dan update 1.15.0

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

    Selama gkectl upgrade admin, pemeriksaan preflight penyimpanan untuk Migrasi CSI memverifikasi bahwa StorageClass tidak memiliki parameter yang diabaikan setelah Migrasi CSI. Misalnya, jika ada StorageClass dengan parameter diskformat, gkectl upgrade admin akan menandai StorageClass dan melaporkan kegagalan dalam validasi preflight. Cluster admin yang dibuat di GKE pada VMware 1.10 dan sebelumnya memiliki StorageClass dengan diskformat: thin yang akan menggagalkan validasi ini, tetapi StorageClass ini masih berfungsi dengan baik setelah Migrasi CSI. Kegagalan ini harus ditafsirkan sebagai peringatan.

    Untuk informasi selengkapnya, periksa bagian parameter StorageClass di Memigrasikan Volume In-Tree vSphere ke vSphere Container Storage Plugin.


    Solusi:

    Setelah mengonfirmasi bahwa cluster Anda memiliki StorageClass dengan parameter yang diabaikan setelah Migrasi CSI menjalankan gkectl upgrade admin dengan flag --skip-validation-cluster-health.
    Penyimpanan 1,15, 1,16

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

    Dalam kondisi tertentu, disk dapat dipasang sebagai hanya baca ke node Windows. Hal ini menyebabkan volume yang sesuai hanya dapat dibaca di dalam Pod. Masalah ini lebih mungkin terjadi jika serangkaian node baru menggantikan kumpulan node lama (misalnya, upgrade cluster atau update kumpulan node). 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. Pastikan disk readonly: 
      
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Hasilnya seharusnya 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 Pod dimulai ulang: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. Pod harus dijadwalkan ke node yang sama. Namun, jika Pod dijadwalkan ke node baru, Anda mungkin perlu mengulangi langkah-langkah sebelumnya pada node baru.

    Upgrade dan update 1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

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

    Jika Anda memperbarui kredensial vSphere untuk cluster admin setelah mengupdate kredensial cluster, Anda mungkin akan menemukan vsphere-csi-secret pada namespace kube-system dalam cluster admin yang masih menggunakan kredensial lama.


    Solusi:

    1. Dapatkan nama rahasia vsphere-csi-secret: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Update 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 diupdate akan digunakan oleh pengontrol.
    Upgrade dan update 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

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

    audit-proxy mungkin mengalami errorloop karena --cluster-name kosong. Perilaku ini disebabkan oleh bug dalam logika update, saat nama cluster tidak disebarkan ke manifes pod / container audit-proxy.


    Solusi:

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

    Untuk cluster pengguna bidang kontrol v1, edit penampung audit-proxy dalam statefulset kube-apiserver untuk menambahkan --cluster_name=USER_CLUSTER_NAME:

    
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    Upgrade dan update 1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

    Satu pesawat kontrol tambahan di-deploy ulang tepat setelah gkectl upgrade cluster

    Tepat setelah gkectl upgrade cluster, pod bidang kontrol mungkin di-deploy ulang lagi. Status cluster dari gkectl list clusters berubah dari RUNNING menjadi RECONCILING. Permintaan ke cluster pengguna mungkin telah habis waktu tunggunya.

    Perilaku ini 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 ke RUNNING lagi di gkectl list clusters, atau upgrade ke versi dengan perbaikan: 1.13.6+, 1.14.2+, atau 1.15+.
    Upgrade dan update 1.12.7

    Rilis buruk 1.12.7-gke.19 telah dihapus

    GKE on VMware 1.12.7-gke.19 adalah rilis yang buruk dan Anda sebaiknya tidak menggunakannya. Artefak telah dihapus dari bucket Cloud Storage.

    Solusi:

    Gunakan rilis 1.12.7-gke.20 sebagai gantinya.
    Upgrade dan update 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

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

    Jika Anda memperbarui kredensial registry 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 gke-connect-agent terus menggunakan gambar lama atau pod gke-connect-agent tidak dapat diambil karena ImagePullBackOff.

    Masalah ini akan diperbaiki di GKE pada VMware rilis 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 pull image regcred yang digunakan oleh deployment gke-connect-agent secara manual:

    
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 rahasia pull image default untuk cluster dalam deployment gke-connect-agent dengan:

    1. Salin rahasia 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 rahasia 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"}]}}}}'
    Penginstalan 1,13, 1,14

    Kegagalan pemeriksaan konfigurasi LB manual

    Jika Anda memvalidasi konfigurasi sebelum membuat cluster menggunakan 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 patch versi 1.13.7 dan 1.14.4 yang akan mencakup 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
    Operasi 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, dan 1.14

    etcd melihat kelaparan

    Cluster yang menjalankan etcd versi 3.4.13 atau sebelumnya mungkin mengalami kelaparan dan pengamatan resource non-operasional, yang dapat menyebabkan masalah berikut:

    • Penjadwalan pod terganggu
    • Node tidak dapat didaftarkan
    • kubelet tidak mengamati perubahan pod

    Masalah ini dapat membuat cluster tidak berfungsi.

    Masalah ini telah diperbaiki di GKE pada VMware rilis 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 GKE sebelumnya di VMware terpengaruh oleh masalah ini.

    Solusi

    Jika tidak dapat langsung melakukan upgrade, Anda dapat memitigasi risiko kegagalan cluster dengan mengurangi jumlah node dalam cluster Anda. 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 Konsol Google Cloud:

      Buka Metrics Explorer

    2. Pilih tab Configuration
    3. Luaskan Select a metric, 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 category, pilih Anthos.
      3. Di menu Metrik aktif, pilih etcd_network_client_grpc_sent_bytes_total.
      4. Klik Terapkan.
    Upgrade dan update 1.10, 1.11, 1.12, 1.13, dan 1.14

    GKE Identity Service dapat menyebabkan latensi bidang kontrol

    Saat cluster dimulai ulang atau diupgrade, GKE Identity Service dapat kewalahan dengan traffic yang terdiri dari token JWT yang sudah tidak berlaku, yang diteruskan dari kube-apiserver ke GKE Identity Service melalui webhook autentikasi. Meskipun tidak mengalami errorloop, GKE Identity Service akan 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 GKE di VMware berikut:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

    Untuk mengetahui 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 port load balancer bidang kontrol VIP dan bidang kontrol untuk cluster Anda (misalnya, 172.16.20.50:443).

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

    2. Periksa GKE Identity Service dan log 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, berarti 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 tidak dapat segera mengupgrade cluster untuk memperbaikinya, Anda dapat mengidentifikasi dan memulai ulang pod yang melanggar sebagai solusinya:

    1. Tingkatkan level panjang Layanan Identitas 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 mencari 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, urai setiap rahasia 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 serta melihat nama dan namespace pod sumber, salin token ke debugger di jwt.io.
    5. Mulai ulang pod yang diidentifikasi dari token.
    Operasi 1,8, 1,9, 1,10

    Masalah peningkatan penggunaan memori pod etcd-maintenance

    Pod pemeliharaan etcd yang menggunakan gambar etcddefrag:gke_master_etcddefrag_20210211.00_p0 akan terpengaruh. Penampung `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 hingga 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 menurunkan skala pod pemeliharaan etcd untuk admin dan cluster 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
    Operasi 1,9, 1,10, 1,11, 1,12, 1,13

    Melewatkan health check pada pod bidang kontrol cluster pengguna

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


    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 dan update 1,6+, 1,7+

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

    Kubernetes mengalihkan traffic dari k8s.gcr.io ke registry.k8s.io pada 20/3/2023. Pada GKE pada VMware 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 tersebut 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 proxy yang diizinkan untuk workstation admin Anda.
    Networking 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Melihat kegagalan validasi pada 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 keren yang sudah ada. Pemeriksaan preflight mencoba memvalidasi load balancer jungkat-jungkit yang tidak ada.

    Solusi:

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

    Waktu tunggu aplikasi yang disebabkan oleh kegagalan penyisipan tabel koneksi

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

    Untuk melihat apakah Anda terpengaruh oleh masalah ini, Anda dapat memeriksa statistik sistem pelacakan koneksi in-kernel pada 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 bukan angka nol, berarti Anda akan terpengaruh oleh masalah ini.

    Solusi

    Mitigasi jangka pendek adalah meningkatkan ukuran tabel hash netfiler (nf_conntrack_buckets) dan tabel pelacakan koneksi netfilter (nf_conntrack_max). Gunakan perintah berikut pada 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 dikalikan dengan jumlah inti pada node. Misalnya, jika node Anda memiliki delapan core, tetapkan ukuran tabel ke 524288.
    Networking 1.13.0-1.13.2

    calico-typha atau anetd-operator crash loop pada node Windows dengan Controlplane v2

    Dengan Controlplane v2 atau model penginstalan baru, calico-typha atau anetd-operator mungkin dijadwalkan ke node Windows dan mengalami error loop.

    Alasannya karena kedua deployment tersebut menoleransi semua taint termasuk taint node Windows.


    Solusi:

    Upgrade ke versi 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

    Dan tambahkan toleransi berikut:

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

    File kredensial registry pribadi cluster pengguna tidak dapat dimuat

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

    
[FAILURE] Docker registry access: Failed to login.


    Solusi:

    • Jika tidak ingin menentukan kolom ini atau ingin menggunakan kredensial registry pribadi yang sama seperti cluster admin, Anda cukup menghapus atau memberi komentar di bagian privateRegistry di file konfigurasi cluster pengguna Anda.
    • 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: Perbaikan ini hanya untuk sementara dan kolom ini sudah tidak digunakan lagi, pertimbangkan untuk menggunakan file kredensial saat mengupgrade ke versi 1.14.3+.)

    Operasi 1,10+

    Anthos 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. Ini berarti Anthos Service Mesh tidak dapat melakukan inspeksi paket karena pod dilewati dan tidak pernah menggunakan IPTables.

    Ini terwujud dalam mode bebas kube-proxy dengan hilangnya konektivitas atau perutean traffic yang salah untuk layanan dengan Anthos Service Mesh karena file bantuan tidak dapat melakukan pemeriksaan paket.

    Masalah ini ada di semua versi GKE pada Bare Metal 1.10, tetapi beberapa versi 1.10 (1.10.2+) yang lebih baru memiliki solusi yang dapat dilakukan.


    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

    Penyimpanan 1,12+, 1,13,3

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

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

    
$ 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, login ke node dan jalankan perintah berikut:

    
# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    Di log kubelet, error seperti berikut akan 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, lalu mulai ulang node.
    Upgrade dan update 1.12+, 1.13+, 1.14+

    Upgrade cluster macet 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.
    Operasi 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    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:

    Matikan 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.
    Sistem operasi 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+

    VM merilis sewa DHCP saat perangkat dimatikan/memulai ulang secara tiba-tiba, yang dapat menyebabkan perubahan IP

    Pada systemd v244, systemd-networkd memiliki perubahan perilaku default pada konfigurasi KeepConfiguration. Sebelum perubahan ini, VM tidak mengirim pesan rilis sewa DHCP ke server DHCP saat perangkat dimatikan atau dimulai ulang. Setelah perubahan ini, VM mengirim pesan tersebut dan menampilkan IP ke server DHCP. Akibatnya, IP yang dirilis dapat dialokasikan ulang ke VM yang berbeda dan/atau IP berbeda mungkin ditetapkan ke VM, yang mengakibatkan 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 terjadi calico-node error 
      
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 pada cluster untuk mengembalikan perubahan perilaku default systemd-networkd. VM yang menjalankan DaemonSet ini tidak akan merilis IP ke server DHCP saat penonaktifan/mulai ulang. IP akan dibebaskan secara otomatis oleh server DHCP saat lease berakhir masa berlakunya. 

    
      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

    Operasi, upgrade, dan update 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

    Kunci akun layanan akses komponen dihapus total 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 versi 1.12.

    Setelah mengupgrade cluster 1.11.x ke 1.12.x, kolom component-access-sa-key dalam admin-cluster-creds secret akan dihapus total. 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'
    Jika Anda mendapati output kosong, berarti kunci tersebut telah dihapus total.

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

    • Kegagalan preflight validasi lambat dengan pesan error: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Penyiapan dari 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 di 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 -
    Operasi 1.13.0+, 1.14.0+

    Autoscaler cluster tidak berfungsi saat Controlplane V2 diaktifkan

    Untuk cluster pengguna yang dibuat dengan Controlplane V2 atau model penginstalan baru, node pool yang mengaktifkan penskalaan otomatis selalu menggunakan autoscaling.minReplicas di user-cluster.yaml. Log pod cluster-autoscaler juga menunjukkan bahwa pod tersebut tidak sehat. 

    
  > 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
    Pod penskala otomatis cluster dapat ditemukan dengan menjalankan perintah berikut. 
    
  > 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 kumpulan node dengan `gkectl update cluster` hingga upgrade ke versi dengan perbaikan
    Penginstalan 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    CIDR tidak diizinkan dalam file blok IP

    Jika 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 upgrade ke versi dengan perbaikan: 1.12.5, 1.13.4, 1.14.1+.
    Upgrade dan update 1.14.0-1.14.1

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

    Saat Mengupdate jenis image OS bidang kontrol di admin-cluster.yaml, dan jika cluster pengguna terkaitnya telah dibuat melalui Controlplane V2, mesin bidang kontrol pengguna mungkin tidak akan menyelesaikan pembuatan ulangnya saat perintah gkectl selesai.


    Solusi:

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

    Operasi 1,10, 1,11, 1,12, 1,13, 1,14,0

    Error saat membuat atau menghapus pod karena masalah token autentikasi akun layanan Calico CNI

    Masalah dengan Calico di GKE pada VMware 1.14.0 menyebabkan pembuatan dan penghapusan Pod gagal dengan pesan error berikut dalam output kubectl describe pods:

    
  error getting ClusterInformation: connection is unauthorized: Unauthorized

    Masalah ini hanya teramati 24 jam setelah cluster dibuat atau diupgrade ke 1.14 menggunakan Calico.

    Cluster admin selalu menggunakan Calico, sedangkan untuk cluster pengguna ada kolom konfigurasi `enableDataPlaneV2` di user-cluster.yaml. Jika kolom tersebut disetel ke `false`, atau tidak ditentukan, artinya Anda menggunakan Calico di cluster pengguna.

    Container install-cni node membuat kubeconfig dengan token yang valid selama 24 jam. Token ini perlu diperpanjang secara berkala oleh Pod calico-node. Pod calico-node tidak dapat memperpanjang token karena tidak memiliki akses ke direktori yang berisi file kubeconfig pada node.


    Solusi:

    Masalah ini telah diperbaiki di GKE pada VMware versi 1.14.1. Upgrade ke versi ini atau yang lebih baru.

    Jika Anda tidak dapat langsung melakukan upgrade, terapkan patch berikut pada calico-node DaemonSet di admin dan cluster pengguna Anda:

    
  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
    Ganti kode berikut:
    • ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin.
    • USER_CLUSTER_CONFIG_FILE: jalur file konfigurasi cluster pengguna Anda.
    Penginstalan 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    Validasi blok IP gagal saat menggunakan CIDR

    Pembuatan cluster gagal meskipun pengguna memiliki konfigurasi yang benar. Pengguna melihat pembuatan yang gagal karena cluster tidak memiliki cukup IP.


    Solusi:

    Membagi CIDR menjadi beberapa blok CIDR yang lebih kecil, seperti 10.0.0.0/30 menjadi 10.0.0.0/31, 10.0.0.2/31. Selama ada CIDR N+1, dengan N adalah jumlah node dalam cluster, ini seharusnya sudah cukup.

    Operasi, Upgrade, dan update 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    Pencadangan cluster admin tidak mencakup konfigurasi dan kunci enkripsi secret yang selalu aktif

    Jika fitur enkripsi secret selalu aktif diaktifkan bersama dengan pencadangan cluster, pencadangan cluster admin akan gagal menyertakan kunci enkripsi dan konfigurasi yang diperlukan oleh fitur enkripsi secret yang selalu aktif. Akibatnya, memperbaiki master admin dengan cadangan ini menggunakan gkectl repair admin-master --restore-from-backup akan menyebabkan error berikut: 

    
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

    Operasi, Upgrade, dan update 1,10+

    Membuat ulang VM master admin dengan boot disk baru (misalnya, gkectl repair admin-master) akan gagal jika fitur enkripsi secret selalu aktif diaktifkan menggunakan perintah `gkectl update`.

    Jika fitur enkripsi rahasia selalu aktif tidak diaktifkan saat pembuatan cluster, tetapi diaktifkan nanti menggunakan operasi gkectl update, gkectl repair admin-master akan gagal memperbaiki node bidang kontrol cluster admin. Sebaiknya fitur enkripsi secret selalu aktif diaktifkan saat pembuatan cluster. Tidak ada mitigasi saat ini.

    Upgrade dan update 1.10

    Mengupgrade cluster pengguna pertama dari 1,9 menjadi 1,10 akan membuat ulang node di cluster pengguna lainnya

    Mengupgrade cluster pengguna pertama dari 1,9 ke 1,10 dapat membuat ulang node di cluster pengguna lain di bawah cluster admin yang sama. Pembuatan ulang dilakukan secara bergantian.

    disk_label dihapus dari MachineTemplate.spec.template.spec.providerSpec.machineVariables, yang memicu update pada semua MachineDeployment secara tidak terduga.


    Solusi:
    Upgrade dan update 1.10.0

    Docker sering dimulai ulang setelah upgrade cluster

    Mengupgrade cluster pengguna ke 1.10.0 mungkin menyebabkan Docker sering memulai ulang.

    Anda dapat mendeteksi masalah ini dengan menjalankan kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG

    Kondisi node akan menunjukkan apakah Docker sering memulai ulang. Berikut adalah contoh output:

    
Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

    Untuk memahami akar masalahnya, Anda harus melakukan ssh ke node yang memiliki gejala dan menjalankan perintah seperti sudo journalctl --utc -u docker atau sudo journalctl -x


    Solusi:
    Upgrade dan update 1,11, 1,12

    Komponen GMP yang di-deploy sendiri tidak dipertahankan setelah diupgrade ke versi 1.12

    Jika Anda menggunakan GKE pada versi VMware di bawah 1.12, dan telah menyiapkan komponen Prometheus yang dikelola Google (GMP) secara manual di namespace gmp-system untuk cluster Anda, komponen tersebut tidak akan dipertahankan saat Anda mengupgrade ke versi 1.12.x.

    Mulai versi 1.12, komponen GMP dalam namespace gmp-system dan CRD dikelola oleh objek stackdriver, dengan flag enableGMPForApplications ditetapkan ke false secara default. Jika Anda men-deploy komponen GMP secara manual di namespace sebelum mengupgrade ke versi 1.12, resource akan dihapus paling lambat stackdriver.


    Solusi:
    Operasi 1.11, 1.12, 1.13.0 - 1.13.1

    Objek ClusterAPI tidak ada dalam skenario system snapshot cluster

    Dalam skenario system, snapshot cluster tidak menyertakan resource apa pun pada namespace default.

    Namun, beberapa resource Kubernetes seperti objek Cluster API yang berada dalam namespace ini berisi informasi proses debug yang berguna. Snapshot cluster harus menyertakannya.


    Solusi:

    Anda dapat menjalankan perintah berikut secara manual untuk mengumpulkan informasi proses debug.

    
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
    dengan:

    USER_CLUSTER_KUBECONFIG adalah file kubeconfig cluster pengguna.
    Upgrade dan update 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Penghapusan cluster pengguna terhenti di node drain untuk penyiapan vSAN

    Saat menghapus, mengupdate, atau mengupgrade cluster pengguna, pengurasan node mungkin terhenti dalam skenario berikut:

    • Cluster admin telah menggunakan driver CSI vSphere pada vSAN sejak versi 1.12.x, dan
    • Tidak ada objek PVC/PV yang dibuat oleh plugin vSphere dalam hierarki di admin dan cluster pengguna.

    Untuk mengidentifikasi gejala, jalankan perintah di bawah ini:

    
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

    Berikut adalah contoh pesan error dari perintah di atas:

    
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

    kubevols adalah direktori default untuk driver dalam hierarki vSphere. Jika tidak ada objek PVC/PV yang dibuat, Anda mungkin mengalami bug sehingga drain node akan terhenti saat menemukan kubevols, karena implementasi saat ini mengasumsikan bahwa kubevols selalu ada.


    Solusi:

    Buat direktori kubevols di datastore tempat node dibuat. Ini ditentukan di kolom vCenter.datastore dalam file user-cluster.yaml atau admin-cluster.yaml.
    Konfigurasi 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14

    Cluster Autoscaler clusterrolebinding dan clusterrole akan dihapus setelah menghapus cluster pengguna.

    Saat penghapusan cluster pengguna, clusterrole dan clusterrolebinding yang sesuai untuk penskalaan otomatis cluster juga akan dihapus. Hal ini memengaruhi semua cluster pengguna lainnya di cluster admin yang sama dengan cluster penskalaan otomatis diaktifkan. Hal ini terjadi karena peran cluster dan clusterrolebinding yang sama digunakan untuk semua pod penskalaan otomatis cluster dalam cluster admin yang sama.

    Gejalanya adalah sebagai berikut:

    • cluster-autoscaler log
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
      dengan ADMIN_CLUSTER_KUBECONFIG adalah file kubeconfig cluster admin. Berikut adalah contoh pesan error yang mungkin Anda lihat: 
      
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Solusi:

    Konfigurasi 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    cluster admin cluster-health-controller dan vsphere-metrics-exporter tidak berfungsi setelah menghapus cluster pengguna

    Saat penghapusan cluster pengguna, clusterrole terkait juga dihapus, sehingga menyebabkan perbaikan otomatis dan pengekspor metrik vsphere tidak berfungsi

    Gejalanya adalah sebagai berikut:

    • cluster-health-controller log
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
      dengan ADMIN_CLUSTER_KUBECONFIG adalah file kubeconfig cluster admin. Berikut adalah contoh pesan error yang mungkin Anda lihat: 
      
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
    • vsphere-metrics-exporter log
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
      dengan ADMIN_CLUSTER_KUBECONFIG adalah file kubeconfig cluster admin. Berikut adalah contoh pesan error yang mungkin Anda lihat: 
      
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Solusi:

    Konfigurasi 1.12.1-1.12.3, 1.13.0-1.13.2

    gkectl check-config gagal pada validasi image OS

    Masalah umum yang dapat menggagalkan gkectl check-config tanpa menjalankan gkectl prepare. Hal ini membingungkan karena sebaiknya jalankan perintah sebelum menjalankan gkectl prepare

    Gejalanya adalah perintah gkectl check-config akan gagal dengan pesan error berikut:

    
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

    Solusi:

    Opsi 1: jalankan gkectl prepare untuk mengupload OS image yang tidak ada.

    Opsi 2: gunakan gkectl check-config --skip-validation-os-images untuk melewati validasi OS image.
    Upgrade dan update 1,11, 1,12, 1,13

    gkectl update admin/cluster gagal memperbarui grup anti-afinitas

    Masalah umum yang dapat menggagalkan gkectl update admin/cluster saat mengupdate anti affinity groups.

    Gejalanya adalah perintah gkectl update akan gagal dengan pesan error berikut:

    
Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

    Solusi:
    Penginstalan, Upgrade, dan update 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    Node gagal mendaftar jika nama host yang dikonfigurasi berisi titik

    Pendaftaran node gagal selama pembuatan, upgrade, pembaruan, dan perbaikan otomatis node, jika ipMode.type adalah static dan nama host yang dikonfigurasi dalam file blok IP berisi satu atau beberapa titik. Dalam hal ini, Permintaan Penandatanganan Sertifikat (CSR) untuk node tidak disetujui secara otomatis.

    Guna melihat CSR yang tertunda untuk sebuah node, jalankan perintah berikut:

    
kubectl get csr -A -o wide

    Periksa log berikut untuk melihat pesan error:

    • Lihat log di cluster admin untuk container clusterapi-controller-manager di Pod clusterapi-controllers: 
      
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Untuk melihat log yang sama di cluster pengguna, jalankan perintah berikut: 
      
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      dalam hal ini:
      • ADMIN_CLUSTER_KUBECONFIG adalah file kubeconfig cluster admin.
      • USER_CLUSTER_NAME adalah nama cluster pengguna.
      Berikut adalah contoh pesan error yang mungkin Anda lihat: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Lihat log kubelet pada node yang bermasalah: 
      
journalctl --u kubelet
      Berikut adalah contoh pesan error yang mungkin Anda lihat: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Jika Anda menentukan nama domain di kolom nama host pada file blok IP, karakter apa pun setelah titik pertama akan diabaikan. Misalnya, jika Anda menentukan nama host sebagai bob-vm-1.bank.plc, nama host dan nama node VM akan ditetapkan ke bob-vm-1.

    Jika verifikasi ID node diaktifkan, pemberi persetujuan CSR akan membandingkan nama node dengan nama host pada spesifikasi Machine, dan gagal merekonsiliasi namanya. Pemberi persetujuan menolak CSR, dan node gagal melakukan bootstrap.


    Solusi:

    Cluster pengguna

    Nonaktifkan verifikasi ID node dengan menyelesaikan langkah-langkah berikut:

    1. Tambahkan kolom berikut di file konfigurasi cluster pengguna Anda: 
      
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Simpan file tersebut, dan perbarui cluster pengguna dengan menjalankan perintah berikut: 
      
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
      Ganti kode berikut:
      • ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin.
      • USER_CLUSTER_CONFIG_FILE: jalur file konfigurasi cluster pengguna Anda.

    Cluster Admin

    1. Buka resource kustom OnPremAdminCluster untuk mengedit: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Tambahkan anotasi berikut ke resource kustom: 
      
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Edit manifes kube-controller-manager di bidang kontrol cluster admin:
      1. SSH ke node bidang kontrol cluster admin.
      2. Buka manifes kube-controller-manager untuk mengedit: 
        
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Temukan daftar controllers: 
        
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Perbarui bagian ini seperti yang ditunjukkan di bawah: 
        
--controllers=*,bootstrapsigner,tokencleaner
    4. Buka pengontrol Deployment Cluster API untuk mengedit: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Ubah nilai node-id-verification-enabled dan node-id-verification-csr-signing-enabled menjadi false: 
      
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Penginstalan, Upgrade, dan update 1.11.0-1.11.4

    Kegagalan startup mesin bidang kontrol admin yang disebabkan oleh paket sertifikat registry pribadi

    Pembuatan/upgrade cluster admin terhenti di log berikut selamanya dan pada akhirnya waktu habis:

    
Waiting for Machine gke-admin-master-xxxx to become ready...

    Log pengontrol Cluster API dalam snapshot cluster eksternal menyertakan log berikut:

    
Invalid value 'XXXX' specified for property startup-data

    Berikut adalah contoh jalur file untuk log pengontrol Cluster API:

    
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayNodes ditandai tidak responsif dari konflik pembaruan status serentak

    Pada networkgatewaygroups.status.nodes, beberapa node beralih antara NotHealthy dan Up.

    Log untuk Pod ang-daemon yang berjalan pada node tersebut menunjukkan error berulang: 

    
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

    Status NotHealthy mencegah pengontrol menetapkan IP mengambang tambahan ke node. Hal ini dapat mengakibatkan beban yang lebih tinggi pada node lain atau kurangnya redundansi untuk ketersediaan tinggi.

    Aktivitas pesawat data tidak terpengaruh.

    Pertentangan pada objek networkgatewaygroup menyebabkan beberapa update status gagal karena adanya kesalahan dalam penanganan percobaan ulang. Jika terlalu banyak pembaruan status yang gagal, ang-controller-manager akan melihat node melampaui batas waktu detak jantungnya dan menandai node NotHealthy.

    Kesalahan dalam penanganan percobaan ulang telah diperbaiki pada versi lebih baru.


    Solusi:

    Upgrade ke versi tetap, jika tersedia.
    Upgrade dan update 1.12.0-1.12.2, 1.13.0

    Kondisi race memblokir penghapusan objek mesin selama dan mengupdate atau mengupgrade

    Masalah umum yang dapat menyebabkan upgrade atau upgrade cluster macet saat menunggu objek mesin lama dihapus. Hal ini karena finaler tidak dapat dihapus dari objek mesin. Hal ini memengaruhi semua operasi update berkelanjutan untuk node pool.

    Gejalanya adalah waktu tunggu perintah gkectl habis dengan pesan error berikut:

    
E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Dalam log Pod clusterapi-controller, error-nya adalah seperti berikut:

    
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

    Error akan berulang untuk mesin yang sama selama beberapa menit agar operasi berjalan dengan sukses meskipun tanpa masalah ini. Biasanya, error dapat diselesaikan dengan cepat. Namun, untuk beberapa kasus yang jarang terjadi, error dapat terhenti pada kondisi race ini selama beberapa jam.

    Masalahnya adalah VM dasar sudah dihapus di vCenter, tetapi objek mesin yang terkait tidak dapat dihapus, yang terhenti saat penghapusan finalr karena update yang sangat sering dari pengontrol lain. Hal ini dapat menyebabkan waktu tunggu perintah gkectl habis, tetapi pengontrol akan terus merekonsiliasi cluster sehingga proses upgrade atau update pada akhirnya selesai.


    Solusi:

    Kami telah menyiapkan beberapa opsi mitigasi yang berbeda untuk masalah ini, yang bergantung pada lingkungan dan persyaratan Anda.

    • Opsi 1: Tunggu hingga upgrade selesai dengan sendirinya.

      Berdasarkan analisis dan reproduksi di lingkungan Anda, upgrade pada akhirnya dapat selesai dengan sendirinya tanpa intervensi manual apa pun. Kekurangan dari opsi ini adalah tidak pasti berapa lama waktu yang diperlukan untuk menyelesaikan setiap objek mesin. Proses ini dapat langsung dilanjutkan jika cukup beruntung, atau dapat berlangsung selama beberapa jam jika pengontrol machineset melakukan rekonsiliasi terlalu cepat dan pengontrol mesin tidak pernah berkesempatan menghapus finalr di sela-sela rekonsiliasi.

      Sisi baiknya adalah opsi ini tidak memerlukan tindakan apa pun dari pihak Anda, dan workload tidak akan terganggu. Hanya perlu waktu lebih lama untuk menyelesaikan upgrade.
    • Opsi 2: Terapkan anotasi perbaikan otomatis ke semua objek mesin lama.

      Pengontrol machineset akan memfilter mesin yang memiliki anotasi perbaikan otomatis dan stempel waktu penghapusan bukan nol, dan tidak akan terus mengeluarkan panggilan hapus pada komputer tersebut, hal ini dapat membantu menghindari kondisi race.

      Kelemahannya adalah pod pada mesin akan dihapus secara langsung, bukan dikeluarkan, yang berarti tidak akan mematuhi konfigurasi PDB, hal ini berpotensi menyebabkan periode nonaktif untuk workload Anda.

      Perintah untuk mendapatkan semua nama mesin: 
      
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      Perintah untuk menerapkan anotasi perbaikan otomatis untuk setiap mesin: 
      
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

    Jika Anda mengalami masalah ini dan upgrade atau update masih tidak dapat diselesaikan setelah sekian lama, hubungi tim dukungan kami untuk melakukan mitigasi.
    Penginstalan, Upgrade, dan update 1.10.2, 1.11, 1.12, 1.13

    gkectl mempersiapkan kegagalan preflight validasi gambar OS

    Perintah gkectl prepare gagal dengan:

    
- Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

    Pemeriksaan preflight gkectl prepare menyertakan validasi yang salah.


    Solusi:

    Jalankan perintah yang sama dengan flag tambahan --skip-validation-os-images.
    Penginstalan 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    URL vCenter dengan awalan https:// atau http:// dapat menyebabkan kegagalan startup cluster

    Pembuatan cluster admin gagal dengan:

    
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

    URL digunakan sebagai bagian dari Kunci rahasia, yang tidak mendukung "/" atau ":".


    Solusi:

    Hapus awalan https:// atau http:// dari kolom vCenter.Address di cluster admin atau yaml konfigurasi cluster pengguna.
    Penginstalan, Upgrade, dan update 1,10, 1,11, 1,12, 1,13

    gkectl prepare panik pada util.CheckFileExists

    gkectl prepare dapat mengalami panik dengan pelacakan tumpukan berikut:

    
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

    Masalahnya, gkectl prepare membuat direktori sertifikat registry pribadi dengan izin yang salah.


    Solusi:

    Untuk memperbaiki masalah ini, jalankan perintah berikut di workstation admin:

    
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    Upgrade dan update 1,10, 1,11, 1,12, 1,13

    gkectl repair admin-master dan upgrade admin yang dapat dilanjutkan tidak berfungsi bersama

    Setelah upaya upgrade cluster admin gagal, jangan jalankan gkectl repair admin-master. Jika dilakukan, upgrade admin berikutnya dapat gagal dengan masalah seperti daya master admin jika mengalami kegagalan atau VM tidak dapat diakses.


    Solusi:

    Jika Anda pernah mengalami skenario kegagalan ini, hubungi dukungan.
    Upgrade dan update 1,10, 1,11

    Upgrade cluster admin yang dilanjutkan dapat menyebabkan template VM bidang kontrol admin tidak ada

    Jika mesin bidang kontrol admin tidak dibuat ulang setelah upaya upgrade cluster admin dilanjutkan, template VM bidang kontrol admin akan dihapus. Template VM bidang kontrol admin adalah template dari master admin yang digunakan untuk memulihkan mesin bidang kontrol dengan gkectl repair admin-master.


    Solusi:

    Template VM bidang kontrol admin akan dibuat ulang selama upgrade cluster admin berikutnya.
    Sistem operasi 1,12, 1,13

    cgroup v2 dapat memengaruhi beban kerja

    Pada versi 1.12.0, cgroup v2 (unified) diaktifkan secara default untuk node Container Optimized OS (COS). Hal ini berpotensi menyebabkan ketidakstabilan workload di cluster COS.


    Solusi:

    Kami beralih kembali ke cgroup v1 (hybrid) di versi 1.12.1. Jika Anda menggunakan node COS, sebaiknya upgrade ke versi 1.12.1 segera setelah dirilis.
    Identitas 1,10, 1,11, 1,12, 1,13

    Resource kustom ClientConfig

    gkectl update mengembalikan perubahan manual apa pun yang Anda buat pada resource kustom ClientConfig.


    Solusi:

    Kami sangat menyarankan Anda untuk mencadangkan resource ClientConfig setelah setiap perubahan manual.
    Penginstalan 1,10, 1,11, 1,12, 1,13

    Validasi gkectl check-config gagal: tidak dapat menemukan partisi BIG-IP F5

    Validasi gagal karena partisi F5 BIG-IP tidak dapat ditemukan, meskipun ada.

    Masalah dengan F5 BIG-IP API dapat menyebabkan validasi gagal.


    Solusi:

    Coba jalankan gkectl check-config lagi.
    Penginstalan 1.12

    Penginstalan cluster pengguna gagal karena masalah pemilihan pemimpin pengelola sertifikat/injektor ca-injector

    Anda mungkin melihat kegagalan penginstalan karena cert-manager-cainjector dalam errorloop, saat apiserver/etcd berjalan lambat:

    
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

    Solusi:
    VMware 1,10, 1,11, 1,12, 1,13

    Memulai ulang atau mengupgrade vCenter untuk versi yang lebih rendah dari 7.0U2

    Jika vCenter, untuk versi yang lebih rendah dari 7.0U2, dimulai ulang, setelah diupgrade atau lainnya, nama jaringan dalam informasi vm dari vCenter salah, dan menyebabkan mesin berada dalam status Unavailable. Hal ini pada akhirnya menyebabkan node diperbaiki secara otomatis untuk membuat node baru.

    Bug govmomi terkait.


    Solusi:

    Solusi ini disediakan oleh dukungan VMware:

    1. Masalah ini telah diperbaiki di vCenter versi 7.0U2 dan yang lebih baru.
    2. Untuk versi yang lebih rendah, klik kanan host, lalu pilih Connection > Putuskan koneksi. Selanjutnya, hubungkan kembali, yang memaksa update portgroup VM.
    Sistem operasi 1,10, 1,11, 1,12, 1,13

    Koneksi SSH ditutup oleh host jarak jauh

    Untuk GKE di VMware versi 1.7.2 dan yang lebih baru, image OS Ubuntu di-hardening dengan CIS L1 Server Benchmark.

    Untuk memenuhi aturan CIS "5.2.16 Pastikan Interval Waktu Tunggu Idle SSH dikonfigurasi", /etc/ssh/sshd_config memiliki setelan berikut:

    
ClientAliveInterval 300
ClientAliveCountMax 0

    Tujuan setelan ini adalah untuk menghentikan sesi klien setelah 5 menit waktu tidak ada aktivitas. Namun, nilai ClientAliveCountMax 0 menyebabkan perilaku yang tidak diharapkan. Saat Anda menggunakan sesi ssh di workstation admin, atau node cluster, koneksi SSH mungkin terputus meskipun klien ssh Anda sedang tidak aktif, seperti saat menjalankan perintah yang memakan waktu, dan perintah Anda dapat dihentikan dengan pesan berikut:

    
Connection to [IP] closed by remote host.
Connection to [IP] closed.

    Solusi:

    Anda dapat:

    • Gunakan nohup agar perintah Anda tidak dihentikan saat koneksi SSH terputus, 
      
nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Perbarui sshd_config untuk menggunakan nilai ClientAliveCountMax bukan nol. Aturan CIS merekomendasikan untuk menggunakan nilai kurang dari 3: 
      
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Pastikan Anda menghubungkan kembali sesi SSH.
    Penginstalan 1,10, 1,11, 1,12, 1,13

    Penginstalan cert-manager bertentangan

    Pada rilis 1.13, monitoring-operator akan menginstal pengelola sertifikat di namespace cert-manager. Jika karena alasan tertentu, Anda perlu menginstal pengelola sertifikat Anda sendiri, ikuti petunjuk berikut untuk menghindari konflik:

    Anda hanya perlu menerapkan solusi ini satu kali untuk setiap cluster, dan perubahan tersebut akan dipertahankan di seluruh upgrade cluster.

    Catatan: Salah satu gejala umum saat menginstal cert manager Anda sendiri adalah versi atau image cert-manager (misalnya v1.7.2) mungkin kembali ke versi sebelumnya. Hal ini disebabkan oleh monitoring-operator yang mencoba merekonsiliasi cert-manager, dan mengembalikan versi dalam prosesnya.

    Solusi:

    Menghindari konflik selama upgrade

    1. Uninstal versi cert-manager Anda. Jika menentukan resource Anda sendiri, Anda mungkin perlu melakukan pencadangan .
    2. Lakukan upgrade.
    3. Ikuti petunjuk berikut untuk memulihkan cert-manager Anda sendiri.

    Memulihkan pengelola sertifikat Anda sendiri di cluster pengguna

    • Skalakan Deployment monitoring-operator ke 0: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Skalakan deployment cert-manager yang dikelola oleh monitoring-operator ke 0: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
    • Instal ulang versi cert-manager Anda. Pulihkan resource yang disesuaikan jika ya.
    • Anda dapat melewati langkah ini jika menggunakan penginstalan pengelola sertifikat default upstream, atau Anda yakin pengelola sertifikat diinstal di namespace cert-manager. Atau, salin Sertifikat cert-manager.io/v1 metrics-ca dan resource Penerbit metrics-pki.cluster.local dari cert-manager ke namespace resource cluster dari pengelola sertifikat yang Anda instal. 
      
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

    Memulihkan pengelola sertifikat Anda sendiri di cluster admin

    Secara umum, Anda tidak perlu menginstal ulang cert-manager di cluster admin karena cluster admin hanya menjalankan GKE di workload bidang kontrol VMware. Dalam kasus yang jarang terjadi, jika Anda juga perlu menginstal pengelola sertifikat sendiri di cluster admin, ikuti petunjuk berikut untuk menghindari konflik. Harap diperhatikan, jika Anda adalah pelanggan Apigee dan hanya memerlukan pengelola sertifikat untuk Apigee, Anda tidak perlu menjalankan perintah cluster admin.

    • Skalakan deployment monitoring-operator ke 0. 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Skalakan deployment cert-manager yang dikelola oleh monitoring-operator ke 0. 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
    • Instal ulang versi cert-manager Anda. Pulihkan resource yang disesuaikan jika ya.
    • Anda dapat melewati langkah ini jika menggunakan penginstalan pengelola sertifikat default upstream, atau Anda yakin pengelola sertifikat diinstal di namespace cert-manager. Atau, salin Sertifikat cert-manager.io/v1 metrics-ca dan resource Penerbit metrics-pki.cluster.local dari cert-manager ke namespace resource cluster dari pengelola sertifikat yang Anda instal. 
      
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
    Sistem operasi 1,10, 1,11, 1,12, 1,13

    Positif palsu dalam pemindaian kerentanan Docker, containerd, dan runc

    Docker, containerd, dan runc dalam image OS Ubuntu yang dikirim dengan GKE di VMware disematkan ke versi khusus menggunakan Ubuntu PPA. Hal ini memastikan bahwa setiap perubahan runtime container akan dikualifikasikan oleh GKE di VMware sebelum setiap rilis.

    Namun, versi khusus ini tidak dikenal oleh Ubuntu CVE Tracker, yang digunakan sebagai feed kerentanan oleh berbagai fitur pemindaian CVE. Oleh karena itu, Anda akan melihat positif palsu (PP) pada hasil pemindaian kerentanan Docker, containerd, dan runc.

    Misalnya, Anda mungkin melihat positif palsu (PP) berikut dari hasil pemindaian CVE Anda. CVE ini sudah diperbaiki dalam versi patch terbaru GKE di VMware.

    Lihat catatan rilis] untuk perbaikan CVE apa pun.


    Solusi:

    Kanonis mengetahui masalah ini, dan perbaikan dilacak di https://github.com/canonical/sec-cvescan/issues/73.
    Upgrade dan update 1,10, 1,11, 1,12, 1,13

    Koneksi jaringan antara admin dan cluster pengguna mungkin tidak tersedia untuk waktu yang singkat selama upgrade cluster non-HA

    Jika mengupgrade cluster non-HA dari 1,9 ke 1,10, Anda mungkin melihat bahwa kubectl exec, kubectl log, dan webhook terhadap cluster pengguna mungkin tidak tersedia dalam waktu singkat. Periode nonaktif ini dapat berlangsung hingga satu menit. Hal ini terjadi karena permintaan masuk (kubectl exec, kubectl log dan webhook) ditangani oleh kube-apiserver untuk cluster pengguna. kube-apiserver pengguna adalah Statefulset. Di cluster non-HA, hanya ada satu replika untuk Statefulset. Jadi selama upgrade, ada kemungkinan kube-apiserver lama tidak tersedia sedangkan kube-apiserver baru belum siap.


    Solusi:

    Periode nonaktif ini hanya terjadi selama proses upgrade. Jika Anda menginginkan periode nonaktif yang lebih singkat selama upgrade, sebaiknya beralih ke cluster HA.
    Penginstalan, Upgrade, dan update 1,10, 1,11, 1,12, 1,13

    Pemeriksaan kesiapan konnektivitas gagal dalam diagnosis cluster HA setelah pembuatan atau upgrade cluster

    Jika Anda membuat atau mengupgrade cluster HA dan mendapati pemeriksaan kesiapan konnektivitas gagal dalam diagnosis cluster, dalam sebagian besar kasus, hal ini tidak akan memengaruhi fungsi GKE pada VMware (kubectl exec, kubectl log and webhook). Hal ini terjadi karena terkadang satu atau dua replika konnektivitas mungkin belum siap untuk jangka waktu tertentu karena jaringan yang tidak stabil atau masalah lainnya.


    Solusi:

    Konnektivitas akan pulih dengan sendirinya. Tunggu selama 30 menit hingga 1 jam dan jalankan kembali diagnosis cluster.
    Sistem operasi 1,7, 1,8, 1,9, 1,10, 1,11

    /etc/cron.daily/aide masalah lonjakan CPU dan memori

    Mulai dari GKE pada VMware versi 1.7.2, image OS Ubuntu di-hardening dengan CIS L1 Server Benchmark.

    Akibatnya, skrip cron /etc/cron.daily/aide telah diinstal sehingga pemeriksaan aide dijadwalkan untuk memastikan bahwa aturan Server CIS L1 "1.4.2 Memastikan integritas sistem file diperiksa secara rutin" diikuti.

    cron job berjalan setiap hari pada pukul 06.25 UTC. Bergantung pada jumlah file pada sistem file, Anda mungkin mengalami lonjakan penggunaan CPU dan memori pada sekitar waktu tersebut yang disebabkan oleh proses aide ini.


    Solusi:

    Jika lonjakan memengaruhi workload, Anda dapat menonaktifkan cron job harian:

    
sudo chmod -x /etc/cron.daily/aide
    Networking 1,10, 1,11, 1,12, 1,13

    Aturan firewall terdistribusi stateful NSX-T dan load balancer berinteraksi secara tidak terduga

    Saat men-deploy GKE pada VMware versi 1.9 atau yang lebih baru, saat deployment memiliki load balancer yang dipaketkan Seesaw di lingkungan yang menggunakan aturan firewall terdistribusi stateful NSX-T, stackdriver-operator mungkin gagal membuat gke-metrics-agent-conf ConfigMap dan menyebabkan Pod gke-connect-agent berada di loop error.

    Masalah yang mendasarinya adalah aturan firewall terdistribusi NSX-T stateful menghentikan koneksi dari klien ke server API cluster pengguna melalui load balancer Seesaw karena Seesaw menggunakan alur koneksi asimetris. Masalah integrasi dengan aturan firewall terdistribusi NSX-T memengaruhi semua rilis GKE di VMware yang menggunakan Seesaw. Anda mungkin mengalami masalah koneksi serupa pada aplikasi Anda sendiri saat membuat objek Kubernetes besar yang ukurannya lebih dari 32K.


    Solusi:

    Ikuti petunjuk berikut untuk menonaktifkan aturan firewall terdistribusi NSX-T, atau menggunakan aturan firewall terdistribusi stateless untuk Seesaw VM.

    Jika cluster Anda menggunakan load balancer manual, ikuti petunjuk ini untuk mengonfigurasi load balancer Anda agar dapat mereset koneksi klien saat mendeteksi kegagalan node backend. Tanpa konfigurasi ini, klien server Kubernetes API mungkin berhenti merespons selama beberapa menit saat instance server tidak berfungsi.
    Logging dan pemantauan 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Penagihan pemantauan yang tidak terduga

    Untuk GKE di VMware versi 1.10 hingga 1.15, beberapa pelanggan mendapati tagihan yang tinggi secara tidak terduga untuk Metrics volume di halaman Penagihan. Masalah ini hanya memengaruhi Anda jika semua keadaan berikut berlaku:

    • Logging dan pemantauan aplikasi diaktifkan (enableStackdriverForApplications=true)
    • Pod Aplikasi memiliki anotasi prometheus.io/scrap=true. (Menginstal Anthos Service Mesh juga dapat menambahkan anotasi ini.)

    Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini, cantumkan metrik yang ditentukan pengguna. Jika Anda melihat penagihan untuk metrik yang tidak diinginkan dengan awalan nama external.googleapis.com/prometheus dan juga melihat enableStackdriverForApplications ditetapkan ke benar dalam respons kubectl -n kube-system get stackdriver stackdriver -o yaml, berarti masalah ini berlaku untuk Anda.


    Solusi

    Jika Anda terpengaruh oleh masalah ini, sebaiknya upgrade cluster ke versi 1.12 atau yang lebih baru, berhenti menggunakan flag enableStackdriverForApplications, dan beralihlah ke solusi pemantauan aplikasi baru managed-service-for-prometheus yang tidak lagi bergantung pada anotasi prometheus.io/scrap=true. Dengan solusi baru ini, Anda juga dapat mengontrol pengumpulan log dan metrik secara terpisah untuk aplikasi Anda, dengan tanda enableCloudLoggingForApplications dan enableGMPForApplications.

    Untuk berhenti menggunakan tanda enableStackdriverForApplications, buka objek `stackdriver` untuk mengedit:

    
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

    Hapus baris enableStackdriverForApplications: true, simpan, dan tutup editor.

    Jika Anda tidak dapat beralih dari pengumpulan metrik berbasis anotasi, gunakan langkah-langkah berikut:

    1. Temukan Pod dan Service sumber yang memiliki metrik penagihan yang tidak diinginkan. 
      
kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Hapus anotasi prometheus.io/scrap=true dari Pod atau Service. Jika anotasi ditambahkan oleh Anthos Service Mesh, pertimbangkan untuk mengonfigurasi Anthos Service Mesh tanpa opsi Prometheus, atau nonaktifkan fitur Penggabungan Metrik Istio.
    Penginstalan 1,11, 1,12, 1,13

    Penginstal gagal saat membuat datadisk vSphere

    Penginstal GKE pada VMware dapat gagal jika peran kustom terikat pada tingkat izin yang salah.

    Jika binding peran salah, datadisk vSphere dengan govc akan mengalami hang dan disk akan dibuat dengan ukuran 0. Untuk memperbaiki masalah ini, Anda harus mengikat peran khusus di level vSphere vCenter (root).


    Solusi:

    Jika ingin mengikat peran khusus di level DC (atau lebih rendah dari root), Anda juga perlu mengikat peran hanya baca ke pengguna di level vCenter root.

    Untuk mengetahui informasi selengkapnya tentang pembuatan peran, lihat hak istimewa akun pengguna vCenter.
    Logging dan pemantauan 1.9.0-1.9.4, 1.10.0-1.10.1

    Traffic jaringan tinggi ke monitoring.googleapis.com

    Anda mungkin melihat traffic jaringan yang tinggi ke monitoring.googleapis.com, bahkan di cluster baru yang tidak memiliki workload pengguna.

    Masalah ini memengaruhi versi 1.10.0-1.10.1 dan versi 1.9.0-1.9.4. Masalah ini telah diperbaiki di versi 1.10.2 dan 1.9.5.


    Solusi:
    Logging dan pemantauan 1,10, 1,11

    gke-metrics-agent sering mengalami error CrashLoopBackOff

    Untuk GKE pada VMware versi 1.10 dan yang lebih baru, DaemonSet `gke-metrics-agent` DaemonSet sering mengalami error CrashLoopBackOff saat `enableStackdriverForApplications` ditetapkan ke `true` dalam objek `stackdriver`.


    Solusi:

    Untuk mengurangi masalah ini, nonaktifkan pengumpulan metrik aplikasi dengan menjalankan perintah berikut. Perintah ini tidak akan menonaktifkan pengumpulan log aplikasi.

    1. Agar perubahan berikut tidak dikembalikan, turunkan skala stackdriver-operator: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Ganti USER_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster pengguna.
    2. Buka ConfigMap gke-metrics-agent-conf untuk mengedit: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. Di bagian services.pipelines, jadikan seluruh bagian metrics/app-metrics sebagai komentar: 
      
services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Tutup sesi pengeditan.
    5. Mulai ulang DaemonSet gke-metrics-agent: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Logging dan pemantauan 1,11, 1,12, 1,13

    Ganti metrik yang tidak digunakan lagi di dasbor

    Jika metrik yang tidak digunakan lagi digunakan di dasbor OOTB, Anda akan melihat beberapa diagram kosong. Untuk menemukan metrik yang tidak digunakan lagi di dasbor Monitoring, jalankan perintah berikut:

    
gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    Metrik yang tidak digunakan lagi berikut ini harus dimigrasikan ke penggantinya.

    Tidak digunakan lagiPenggantian
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Solusi:

    Untuk mengganti metrik yang tidak digunakan lagi

    1. Hapus "GKE on-prem node status" di dasbor Google Cloud Monitoring. Instal ulang "status node on-prem GKE" dengan mengikuti petunjuk ini.
    2. Hapus "GKE on-prem node utilization" di dasbor Google Cloud Monitoring. Instal ulang "Penggunaan node GKE on-prem" dengan mengikuti petunjuk ini.
    3. Hapus "GKE on-prem vSphere vm health" di dasbor Google Cloud Monitoring. Instal ulang "GKE on-prem vSphere vm health" dengan mengikuti petunjuk ini.

      4. Penghentian ini disebabkan oleh upgrade agen kube-state-metrics dari v1.9 ke v2.4, yang diperlukan untuk Kubernetes 1.22. Anda dapat mengganti semua metrik kube-state-metrics yang tidak digunakan lagi, yang memiliki awalan kube_, di dasbor kustom atau kebijakan pemberitahuan Anda.
    Logging dan pemantauan 1,10, 1,11, 1,12, 1,13

    Data metrik tidak diketahui di Cloud Monitoring

    Untuk GKE pada VMware versi 1.10 dan yang lebih baru, data untuk cluster dalam Cloud Monitoring mungkin berisi entri metrik ringkasan yang tidak relevan seperti berikut:

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Jenis metrik lain yang mungkin memiliki metrik ringkasan yang tidak relevan mencakup

    .
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Meskipun metrik jenis ringkasan ini ada dalam daftar metrik, metrik tersebut tidak didukung oleh gke-metrics-agent pada saat ini.
    Logging dan pemantauan 1,10, 1,11, 1,12, 1,13

    Metrik tidak ada di beberapa node

    Anda mungkin menemukan bahwa metrik berikut tidak ada di sebagian, tetapi tidak semua, node:

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Solusi:

    Untuk memperbaiki masalah ini, lakukan langkah-langkah berikut sebagai solusi. Untuk [versi 1.9.5+, 1.10.2+, 1.11.0]: tingkatkan CPU untuk gke-metrics-agent dengan mengikuti langkah 1 - 4

    1. Buka resource stackdriver untuk mengedit: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Guna meningkatkan permintaan CPU untuk gke-metrics-agent dari 10m menjadi 50m, batas CPU dari 100m menjadi 200m tambahkan bagian resourceAttrOverride berikut ke manifes stackdriver : 
      
spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      Resource yang diedit akan terlihat seperti berikut: 
      
spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Simpan perubahan Anda dan tutup editor teks.
    4. Untuk memastikan perubahan telah diterapkan, jalankan perintah berikut: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      Perintah akan menemukan cpu: 50m jika hasil edit Anda telah diterapkan.
    Logging dan pemantauan 1.11.0-1.11.2, 1.12.0

    Metrik penjadwal dan pengontrol-pengelola tidak ada di cluster admin

    Jika cluster admin Anda terpengaruh oleh masalah ini, metrik penjadwal dan pengelola pengontrol akan hilang. Misalnya, kedua metrik ini tidak ada

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solusi:

    Upgrade ke v1.11.3+, v1.12.1+, atau v1.13+.
    1.11.0-1.11.2, 1.12.0

    Metrik penjadwal dan pengelola pengontrol tidak ada di cluster pengguna

    Jika cluster pengguna Anda terpengaruh oleh masalah ini, metrik penjadwal dan pengelola pengontrol tidak akan ada. Misalnya, kedua metrik berikut tidak ada:

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solusi:

    Masalah ini telah diperbaiki di GKE pada VMware versi 1.13.0 dan yang lebih baru. Upgrade cluster Anda ke versi yang telah diperbaiki.
    Penginstalan, Upgrade, dan update 1,10, 1,11, 1,12, 1,13

    Gagal mendaftarkan cluster admin selama pembuatan

    Jika Anda membuat cluster admin untuk versi 1.9.x atau 1.10.0, dan jika cluster admin gagal mendaftar dengan spesifikasi gkeConnect yang disediakan selama pembuatannya, Anda akan mendapatkan error berikut.

    
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    Anda akan tetap dapat menggunakan cluster admin ini, tetapi Anda akan mendapatkan error berikut jika nanti Anda mencoba mengupgrade cluster admin ke versi 1.10.y.

    
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

    Solusi:
    Identitas 1,10, 1,11, 1,12, 1,13

    Penggunaan GKE Identity Service dapat menyebabkan Agen Connect memulai ulang secara tidak terduga

    Jika Anda menggunakan fitur GKE Identity Service untuk mengelola GKE Identity Service ClientConfig, Connect Agent mungkin dimulai ulang secara tidak terduga.


    Solusi:

    Jika mengalami masalah ini pada cluster yang sudah ada, Anda dapat melakukan salah satu tindakan berikut:

    • Nonaktifkan GKE Identity Service. Jika Anda menonaktifkan GKE Identity Service, tindakan tersebut tidak akan menghapus biner Layanan Identitas GKE yang di-deploy atau menghapus GKE Identity Service ClientConfig. Untuk menonaktifkan GKE Identity Service, jalankan perintah ini: 
      
gcloud container fleet identity-service disable \
    --project PROJECT_ID
      Ganti PROJECT_ID dengan ID project host fleet cluster.
    • Update cluster ke versi 1.9.3 atau yang lebih baru, atau versi 1.10.1 atau yang lebih baru, untuk mengupgrade versi Connect Agent.
    Networking 1,10, 1,11, 1,12, 1,13

    Cisco ACI tidak berfungsi dengan Direct Server Return (DSR)

    Seesaw berjalan dalam mode DSR, dan secara default tidak berfungsi dalam Cisco ACI karena pembelajaran IP bidang data.


    Solusi:

    Solusi yang memungkinkan adalah menonaktifkan pembelajaran IP dengan menambahkan alamat IP Seesaw sebagai IP Virtual L4-L7 di Cisco Application Policy Infrastructure Controller (APIC).

    Anda dapat mengonfigurasi opsi IP Virtual L4-L7 dengan membuka Tenant > Application Profiles > Application EPGs atau uSeg EPGs. Kegagalan dalam menonaktifkan pembelajaran IP akan mengakibatkan endpoint IP beroperasi di antara lokasi yang berbeda dalam fabric Cisco API.
    VMware 1,10, 1,11, 1,12, 1,13

    vSphere 7.0 Memperbarui 3 masalah

    VMWare baru-baru ini mengidentifikasi masalah kritis pada rilis vSphere 7.0 Update 3 berikut:

    • vSphere ESXi 7.0 Pembaruan 3 (build 18644231)
    • vSphere ESXi 7.0 Pembaruan 3a (build 18825058)
    • vSphere ESXi 7.0 Pembaruan 3b (build 18905247)
    • vSphere vCenter 7.0 Pembaruan 3b (build 18901211)

    Solusi:

    VMWare telah menghapus rilis ini. Anda harus mengupgrade ESXi dan Server vCenter ke versi yang lebih baru.
    Sistem operasi 1,10, 1,11, 1,12, 1,13

    Kegagalan memasang volume emptyDir sebagai exec ke dalam Pod yang berjalan pada node COS

    Untuk Pod yang berjalan pada node yang menggunakan image Container-Optimized OS (COS), Anda tidak dapat memasang volume emptyDir sebagai exec. Metode ini dipasang sebagai noexec dan Anda akan mendapatkan error berikut: exec user process caused: permission denied. Misalnya, Anda akan melihat pesan error ini jika men-deploy Pod pengujian berikut:

    
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    Dalam Pod pengujian, jika Anda menjalankan mount | grep test-volume, opsi noexec akan ditampilkan:

    
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Solusi:
    Upgrade dan update 1,10, 1,11, 1,12, 1,13

    Update replika kumpulan node cluster tidak berfungsi setelah penskalaan otomatis dinonaktifkan di kumpulan node

    Replika kumpulan node tidak akan diupdate setelah penskalaan otomatis diaktifkan dan dinonaktifkan di kumpulan node.


    Solusi:

    Menghapus anotasi cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size dan cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size dari deployment mesin kumpulan node yang sesuai.
    Logging dan pemantauan 1,11, 1,12, 1,13

    Dasbor pemantauan Windows menampilkan data dari cluster Linux

    Mulai versi 1.11, di dasbor pemantauan siap pakai, dasbor status Pod Windows dan dasbor status node Windows juga menampilkan data dari cluster Linux. Hal ini karena node Windows dan metrik Pod juga diekspos di cluster Linux.
    Logging dan pemantauan 1,10, 1,11, 1,12

    stackdriver-log-forwarder dalam CrashLoopBackOff yang konstan

    Untuk GKE di VMware versi 1.10, 1.11, dan 1.12, stackdriver-log-forwarder DaemonSet mungkin mengalami error CrashLoopBackOff jika terdapat kerusakan log buffering di disk.


    Solusi:

    Untuk mengurangi masalah ini, kami harus membersihkan log yang di-buffer pada node.

    1. Untuk mencegah perilaku yang tidak terduga, turunkan skala stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Ganti USER_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster pengguna.
    2. Terapkan DaemonSet pembersihan untuk membersihkan bagian yang rusak: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Untuk memastikan DaemonSet pembersihan telah membersihkan semua bagian, Anda dapat menjalankan perintah berikut. Output dari kedua perintah tersebut harus sama dengan nomor node Anda di cluster: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Hapus pembersihan DaemonSet: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Lanjutkan stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging dan pemantauan 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    stackdriver-log-forwarder tidak mengirim log ke Cloud Logging

    Jika Anda tidak melihat log di Cloud Logging dari cluster Anda, dan melihat error berikut di log Anda: 

    
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    Rasio input log kemungkinan melebihi batas agen logging, yang menyebabkan stackdriver-log-forwarder tidak mengirim log. Masalah ini terjadi di semua GKE pada versi VMware.

    Solusi:

    Untuk mengurangi masalah ini, Anda perlu meningkatkan batas resource pada agen logging.

    1. Buka resource stackdriver untuk mengedit: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Guna meningkatkan permintaan CPU untuk stackdriver-log-forwarder, tambahkan bagian resourceAttrOverride berikut ke manifes stackdriver : 
      
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      Resource yang diedit akan terlihat seperti berikut: 
      
spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Simpan perubahan Anda dan tutup editor teks.
    4. Untuk memastikan perubahan telah diterapkan, jalankan perintah berikut: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      Perintah akan menemukan cpu: 1200m jika hasil edit Anda telah diterapkan.
    Keamanan 1.13

    Layanan Kubelet tidak akan tersedia untuk sementara setelah NodeReady

    ada periode singkat di mana node siap tetapi sertifikat server kubelet belum siap. kubectl exec dan kubectl logs tidak tersedia selama puluhan detik ini. Hal ini karena perlu waktu bagi pemberi persetujuan sertifikat server yang baru untuk melihat IP valid yang diperbarui dari node.

    Masalah ini hanya memengaruhi sertifikat server kubelet dan tidak akan memengaruhi penjadwalan Pod.
    Upgrade dan update 1.12

    Upgrade cluster admin sebagian tidak memblokir upgrade cluster pengguna berikutnya

    Upgrade cluster pengguna gagal dengan:

    
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Cluster admin tidak sepenuhnya diupgrade, dan versi statusnya masih 1.10. Upgrade cluster pengguna ke 1.12 tidak akan diblokir oleh pemeriksaan preflight, dan gagal dengan masalah kemiringan versi.


    Solusi:

    Selesaikan untuk mengupgrade cluster admin ke versi 1.11 terlebih dahulu, lalu upgrade cluster pengguna ke versi 1.12.
    Penyimpanan 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    Datastore salah melaporkan ruang kosong yang tidak cukup

    Perintah gkectl diagnose cluster gagal dengan: 

    
Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    Validasi ruang kosong datastore tidak boleh digunakan untuk kumpulan node cluster yang ada, dan ditambahkan di gkectl diagnose cluster secara tidak sengaja.


    Solusi:

    Anda dapat mengabaikan pesan error atau melewati validasi menggunakan --skip-validation-infra.
    Operasi, Jaringan 1.11, 1.12.0-1.12.1

    Gagal menambahkan cluster pengguna baru saat cluster admin menggunakan load balancer MetalLB

    Anda mungkin tidak dapat menambahkan cluster pengguna baru jika cluster admin Anda disiapkan dengan konfigurasi load balancer MetalLB.

    Proses penghapusan cluster pengguna mungkin terhambat karena alasan tertentu yang mengakibatkan pembatalan validasi ConfigMap MatalLB. Anda tidak dapat menambahkan cluster pengguna baru dalam status ini.


    Solusi:

    Anda dapat memaksa menghapus cluster pengguna.
    Penginstalan, Sistem operasi 1,10, 1,11, 1,12, 1,13

    Gagal saat menggunakan Container-Optimized OS (COS) untuk cluster pengguna

    Jika osImageType menggunakan cos untuk cluster admin, dan saat gkectl check-config dijalankan setelah pembuatan cluster admin dan sebelum pembuatan cluster pengguna, cluster tersebut akan gagal pada: 

    
Failed to create the test VMs: VM failed to get IP addresses on the network.

    Secara default, VM pengujian yang dibuat untuk cluster pengguna check-config menggunakan osImageType yang sama dari cluster admin, dan saat ini VM uji belum kompatibel dengan COS.


    Solusi:

    Untuk menghindari pemeriksaan preflight lambat yang membuat VM pengujian, menggunakan gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
    Logging dan pemantauan 1.12.0-1.12.1

    Grafana di cluster admin tidak dapat menjangkau cluster pengguna

    Masalah ini memengaruhi pelanggan yang menggunakan Grafana di cluster admin untuk memantau cluster pengguna di GKE pada VMware versi 1.12.0 dan 1.12.1. Hal ini disebabkan oleh ketidakcocokan sertifikat pushprox-client di cluster pengguna dan daftar yang diizinkan di server pushprox di cluster admin. Gejalanya adalah pushprox-client di cluster pengguna untuk mencetak log error seperti berikut:

    
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Solusi:
    Other 1.11.3

    gkectl repair admin-master tidak menyediakan template VM yang akan digunakan untuk pemulihan

    Perintah gkectl repair admin-master gagal dengan: 

    
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master tidak dapat mengambil template VM yang akan digunakan untuk memperbaiki VM bidang kontrol admin jika nama VM bidang kontrol admin diakhiri dengan karakter t, m, p, atau l.


    Solusi:

    Jalankan kembali perintah dengan --skip-validation.
    Logging dan pemantauan 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    Kegagalan logging audit cloud karena izin ditolak

    Cloud Audit Logs memerlukan penyiapan izin khusus yang saat ini hanya dilakukan secara otomatis untuk cluster pengguna melalui GKE Hub. Sebaiknya Anda memiliki minimal satu cluster pengguna yang menggunakan project ID dan akun layanan yang sama dengan cluster admin untuk Cloud Audit Logs sehingga cluster admin akan memiliki izin yang diperlukan.

    Namun, jika cluster admin menggunakan project ID atau akun layanan yang berbeda dengan cluster pengguna mana pun, log audit dari cluster admin akan gagal dimasukkan ke Google Cloud. Gejalanya adalah serangkaian error Permission Denied dalam Pod audit-proxy di cluster admin.

    Solusi:
    Operasi, Keamanan 1,11

    gkectl diagnose memeriksa kegagalan sertifikat

    Jika stasiun kerja Anda tidak memiliki akses ke node pekerja cluster pengguna, stasiun kerja akan mendapatkan kegagalan berikut saat menjalankan gkectl diagnose:

    
Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Jika stasiun kerja Anda tidak memiliki akses ke node pekerja cluster admin atau node pekerja cluster admin, node tersebut akan mendapatkan kegagalan berikut saat menjalankan gkectl diagnose:

    
Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Solusi:

    Jika aman untuk mengabaikan pesan ini.
    Sistem operasi 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    /var/log/audit/ mengisi ruang disk pada VM

    /var/log/audit/ diisi dengan log audit. Anda dapat memeriksa penggunaan disk dengan menjalankan sudo du -h -d 1 /var/log/audit.

    Perintah gkectl tertentu di workstation admin, misalnya, gkectl diagnose snapshot berkontribusi pada penggunaan ruang disk.

    Sejak GKE di VMware v1.8, image Ubuntu di-hardening dengan Benchmark CIS Level 2. Dan salah satu aturan kepatuhan, "4.1.2.2 Memastikan log audit tidak dihapus secara otomatis", memastikan max_log_file_action = keep_logs setelan yang diaudit. Hasilnya, semua aturan audit disimpan di disk.


    Solusi:
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayGroup IP mengambang bertentangan dengan alamat node

    Pengguna tidak dapat membuat atau memperbarui objek NetworkGatewayGroup karena error webhook validasi berikut:

    
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    Pada versi yang terpengaruh, kubelet dapat secara keliru mengikat ke alamat IP mengambang yang ditetapkan ke node dan melaporkannya sebagai alamat node di node.status.addresses. Webhook yang memvalidasi akan memeriksa alamat IP mengambang NetworkGatewayGroup terhadap semua node.status.addresses dalam cluster dan melihatnya sebagai konflik.


    Solusi:

    Dalam cluster yang sama tempat pembuatan atau pembaruan objek NetworkGatewayGroup gagal, nonaktifkan sementara webhook yang memvalidasi ANG dan kirim perubahan Anda:

    1. Simpan konfigurasi webhook agar dapat dipulihkan di akhir: 
      
kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Edit konfigurasi webhook: 
      
kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Hapus item vnetworkgatewaygroup.kb.io dari daftar konfigurasi webhook dan tutup untuk menerapkan perubahan.
    4. Buat atau edit objek NetworkGatewayGroup Anda.
    5. Terapkan kembali konfigurasi webhook asli: 
      
kubectl -n kube-system apply -f webhook-config.yaml
    Penginstalan, Upgrade, dan update 1.10.0-1.10.2

    Membuat atau mengupgrade waktu tunggu cluster admin

    Selama upaya upgrade cluster admin, VM bidang kontrol admin mungkin terhenti selama pembuatan. VM bidang kontrol admin akan berada dalam loop tunggu tanpa batas selama booting, dan Anda akan melihat error loop terus-menerus berikut dalam file /var/log/cloud-init-output.log:

    
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Hal ini karena saat GKE di VMware mencoba mendapatkan alamat IP node di skrip startup, grep -v ADMIN_CONTROL_PLANE_VIP akan digunakan untuk melewati VIP bidang kontrol cluster admin yang juga dapat ditetapkan ke NIC. Namun, perintah tersebut juga melewati alamat IP apa pun yang memiliki awalan VIP bidang kontrol, yang menyebabkan skrip startup hang.

    Misalnya, anggaplah VIP bidang kontrol cluster admin adalah 192.168.1.25. Jika alamat IP VM bidang kontrol cluster admin memiliki awalan yang sama, misalnya,192.168.1.254, maka VM bidang kontrol akan macet selama pembuatan. Masalah ini juga dapat dipicu jika alamat siaran memiliki awalan yang sama dengan VIP bidang kontrol, misalnya, 192.168.1.255.


    Solusi:

    • Jika alasan waktu tunggu pembuatan cluster admin habis karena alamat IP siaran, jalankan perintah berikut di VM bidang kontrol cluster admin: 
      
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      Tindakan ini akan membuat baris tanpa alamat siaran, dan membuka pemblokiran proses booting. Setelah skrip startup dibatalkan pemblokirannya, hapus baris yang ditambahkan ini dengan menjalankan perintah berikut: 
      
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Namun, jika alasan waktu tunggu pembuatan cluster admin habis karena alamat IP VM bidang kontrol, Anda tidak dapat berhenti memblokir skrip startup. Beralihlah ke alamat IP lain, lalu buat ulang atau upgrade ke versi 1.10.3 atau yang lebih baru.
    Sistem operasi, Upgrade, dan update 1.10.0-1.10.2

    Status cluster admin yang menggunakan image COS akan hilang saat upgrade cluster admin atau perbaikan master admin

    DataDisk tidak dapat dipasang dengan benar ke node master cluster admin saat menggunakan image COS dan status cluster admin yang menggunakan image COS akan hilang setelah upgrade cluster admin atau perbaikan master admin. (cluster admin yang menggunakan gambar COS adalah fitur pratinjau)


    Solusi:

    Membuat ulang cluster admin dengan osImageType yang ditetapkan ke ubuntu_containerd

    Setelah Anda membuat cluster admin dengan osImageType yang ditetapkan ke cos, ambil kunci SSH cluster admin dan SSH ke node master admin. df -h hasil berisi /dev/sdb1 98G 209M 93G 1% /opt/data. Dan lsblk hasil berisi -sdb1 8:17 0 100G 0 part /opt/data
    Sistem operasi 1.10

    pencarian DNS gagal yang diselesaikan oleh sistem di .local domain

    Di GKE pada VMware versi 1.10.0, resolusi nama di Ubuntu akan dirutekan ke pemrosesan lokal yang diselesaikan oleh sistem pada 127.0.0.53 secara default. Alasannya adalah pada image Ubuntu 20.04 yang digunakan dalam versi 1.10.0, /etc/resolv.conf ditautkan ke /run/systemd/resolve/stub-resolv.conf, yang mengarah ke stub DNS localhost 127.0.0.53.

    Akibatnya, resolusi nama DNS localhost menolak untuk memeriksa nama dengan akhiran .local di server DNS upstream (ditentukan dalam /run/systemd/resolve/resolv.conf), kecuali jika nama tersebut ditetapkan sebagai domain penelusuran.

    Hal ini menyebabkan pencarian nama .local gagal. Misalnya, saat startup node, kubelet gagal mengambil image dari registry pribadi dengan akhiran .local. Penentuan alamat vCenter dengan akhiran .local tidak akan berfungsi di workstation admin.


    Solusi:

    Masalah ini dapat dihindari untuk node cluster jika Anda menentukan kolom searchDomainsForDNS di file konfigurasi cluster admin dan file konfigurasi cluster pengguna untuk menyertakan domain tersebut.

    Saat ini, gkectl update belum mendukung pembaruan kolom searchDomainsForDNS.

    Oleh karena itu, jika belum menyiapkan kolom ini sebelum pembuatan cluster, Anda harus menjalankan SSH ke dalam node dan mengabaikan stub lokal yang telah diselesaikan sistem dengan mengubah symlink /etc/resolv.conf dari /run/systemd/resolve/stub-resolv.conf (yang berisi stub lokal 127.0.0.53) menjadi /run/systemd/resolve/resolv.conf (yang mengarah ke DNS upstream sebenarnya): 

    
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    Untuk workstation admin, gkeadm tidak mendukung penentuan domain penelusuran, sehingga Anda harus mengatasi masalah ini dengan langkah manual ini.

    Solusi untuk ini tidak terus ada di seluruh pembuatan ulang VM. Anda harus menerapkan kembali solusi ini setiap kali VM dibuat ulang.
    Penginstalan, Sistem operasi 1.10

    IP bridge Docker menggunakan 172.17.0.1/16, bukan 169.254.123.1/24

    GKE di VMware menentukan subnet khusus untuk alamat IP bridge Docker yang menggunakan --bip=169.254.123.1/24, sehingga tidak akan mencadangkan subnet 172.17.0.1/16 default. Namun, pada versi 1.10.0, ada bug pada OS image Ubuntu yang menyebabkan konfigurasi Docker yang disesuaikan diabaikan.

    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 workload dalam rentang alamat IP tersebut.


    Solusi:

    Untuk mengatasi masalah ini, Anda harus mengganti nama file konfigurasi sistem berikut untuk dockerd, lalu memulai ulang layanan:

    
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    Pastikan Docker memilih alamat IP bridge yang benar:

    
ip a | grep docker0

    Solusi ini tidak bertahan di seluruh pembuatan ulang VM. Anda harus menerapkan kembali solusi ini setiap kali VM dibuat ulang.
    Upgrade dan update 1,11

    Upgrade ke 1.11 terhalang oleh kesiapan stackdriver

    Di GKE pada VMware versi 1.11.0, terdapat perubahan definisi resource kustom terkait logging dan pemantauan:

    • Nama grup resource kustom stackdriver diubah dari addons.sigs.k8s.io menjadi addons.gke.io;
    • Nama grup resource kustom monitoring dan metricsserver diubah dari addons.k8s.io menjadi addons.gke.io;
    • Spesifikasi resource di atas mulai dihargai terhadap skemanya. Secara khusus, spesifikasi resourceAttrOverride dan storageSizeOverride dalam resource khusus stackdriver harus memiliki jenis string dalam nilai permintaan dan batas ukuran cpu, memori, dan penyimpanan.

    Perubahan nama grup dilakukan untuk mematuhi update CustomResourceDefinition di Kubernetes 1.22.

    Anda tidak perlu melakukan tindakan apa pun jika tidak memiliki logika tambahan yang menerapkan atau mengedit resource kustom yang terpengaruh. Proses upgrade GKE pada VMware akan menangani migrasi resource yang terpengaruh dan mempertahankan spesifikasi yang ada setelah perubahan nama grup.

    Namun, jika Anda menjalankan logika apa pun yang menerapkan atau mengedit resource yang terpengaruh, Anda perlu perhatian khusus. Pertama, nama file harus direferensikan dengan nama grup baru dalam file manifes Anda. Contoh:

    
apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    Kedua, pastikan nilai spesifikasi resourceAttrOverride dan storageSizeOverride berjenis string. Contoh:

    
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work
        memory: 3000Mi

    Jika tidak, penerapan dan pengeditan tidak akan berpengaruh dan dapat menyebabkan status yang tidak terduga dalam logging dan pemantauan komponen. Gejala potensial dapat termasuk:

    • Log error rekonsiliasi di onprem-user-cluster-controller, misalnya: 
      
potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Kegagalan di kubectl edit stackdriver stackdriver, misalnya: 
      
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Jika Anda mengalami error di atas, berarti jenis yang tidak didukung dalam spesifikasi CR stackdriver sudah ada sebelum upgrade. Sebagai solusinya, Anda dapat mengedit CR stackdriver secara manual dengan nama grup lama kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver dan melakukan hal berikut:

    1. Mengubah permintaan resource dan batas untuk tipe string;
    2. Hapus anotasi addons.gke.io/migrated-and-deprecated: true apa pun jika ada.
    Kemudian, lanjutkan atau mulai ulang proses upgrade.

    Sistem operasi 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    VM COS tidak menampilkan IP saat VM dipindahkan melalui penonaktifan host secara tidak sopan

    Setiap kali ada kesalahan dalam server ESXi dan fungsi HA vCenter telah diaktifkan untuk server, semua VM di server ESXi yang rusak akan memicu mekanisme vMotion dan dipindahkan ke server ESXi normal lainnya. COS VM yang dimigrasikan akan kehilangan IP-nya.

    Solusi:

    Memulai ulang VM
    Networking semua versi sebelum 1.14.7, 1.15.0-1.15.3, 1.16.0

    Balasan GARP yang dikirim oleh Seesaw tidak menetapkan IP target

    GARP periodik (Gratuitous ARP) yang dikirim oleh Seesaw setiap 20 detik tidak menetapkan IP target di {i>header<i} ARP. Beberapa jaringan mungkin tidak menerima paket tersebut (seperti Cisco ACI). Hal ini dapat menyebabkan waktu henti layanan yang lebih lama setelah otak yang terbelah (karena penurunan paket VRRP) dipulihkan.

    Solusi:

    Picu failover Seeaw dengan menjalankan sudo seesaw -c failover di salah satu VM Seesaw. Tindakan ini akan memulihkan traffic.
    Sistem operasi 1.16, 1.28.0-1.28.200

    Kubelet dibanjiri log yang menyatakan bahwa "/etc/kubernetes/manifests" tidak ada di node pekerja

    "staticPodPath" keliru ditetapkan untuk node pekerja

    Solusi:

    Buat folder "/etc/kubernetes/manifests" secara manual
    Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.