Masalah umum Google Distributed Cloud (khusus software) untuk VMware

Halaman ini mencantumkan semua masalah umum untuk Google Distributed Cloud di VMware. Halaman ini ditujukan untuk Operator dan administrator IT yang mengelola siklus proses infrastruktur teknologi yang mendasarinya, serta merespons pemberitahuan dan halaman saat tujuan tingkat layanan (SLO) tidak terpenuhi atau aplikasi gagal. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud , lihat Peran dan tugas pengguna GKE Enterprise umum.

Jika Anda adalah bagian dari Program Developer Google, simpan halaman ini untuk menerima notifikasi saat catatan rilis yang terkait dengan halaman ini dipublikasikan. Untuk mempelajari lebih lanjut, lihat Halaman Tersimpan.

Untuk memfilter masalah umum berdasarkan versi atau kategori produk, pilih filter yang diinginkan dari menu drop-down berikut.

Pilih versi Google Distributed Cloud Anda:

  • 1,31
  • 1,30
  • 1,29
  • 1,28
  • 1.16
  • 1,15
  • 1,14
  • 1.13
  • 1.12

Pilih kategori masalah Anda:

  • Konfigurasi
  • Penginstalan
  • Upgrade
  • Update
  • Operasi
  • Logging dan pemantauan
  • Jaringan
  • Keamanan
  • Penyimpanan
  • Sistem operasi
  • VMware
  • Identitas
  • Migrasi
  • Lainnya

Atau, telusuri masalah Anda:

Kategori Versi yang diidentifikasi Masalah dan solusi
Konfigurasi, Operasi 1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+

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

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

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

Solusi:

Ganti nama datastore atau datadisk menjadi nama yang lebih pendek.
Pastikan panjang gabungan nama datastore dan datadisk tidak melebihi panjang karakter maksimum.
Update 1.13, 1.14, 1.15, 1.16

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

Penginstalan, Upgrade, dan update 1,31

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

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

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

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

Solusi

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

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

Solusi:

Jalankan perintah berikut untuk memeriksa status cloud-init:

    systemctl show -p Result cloud-final.service

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

    Result=success
Upgrade 1,28

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

    Workstation Hardware: Workstation hardware requirements are not satisfied

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

Solusi:

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

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

    detected unsupported drivers:
      csi.trident.netapp.io

Solusi:

Jalankan gkectl upgrade dengan flag `--skip-pre-upgrade-checks`.
VMware, Upgrade 1.16

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

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

    kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME

Solusi:

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

    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    
    gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
Upgrade 1,16, 1,28, 1,29, 1,30

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

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

Solusi:

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

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

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

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

Solusi:

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

gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
Update 1.16, 1.28.0-1.28.800, 1.29.0-1.29.400, 1.30.0

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

Solusi:

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

Periksa kesiapan DaemonSet setelah dimulai ulang:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

Pada output perintah sebelumnya, pastikan angka di kolom DESIRED cocok dengan angka di kolom READY.
Upgrade 1.16

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

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

Pencadangan cluster admin melibatkan beberapa langkah, termasuk mengambil snapshot etcd, lalu menulis file metadata untuk cluster admin. Pencadangan etcd masih berhasil karena etcdctl masih dapat dipicu setelah eksekusi ke Pod etcd. Namun, penulisan file metadata gagal karena masih mengandalkan biner etcdctl untuk diinstal di node. Namun, pencadangan file metadata bukanlah pemblokir untuk membuat cadangan, sehingga proses pencadangan masih berhasil, begitu juga dengan upgrade cluster pengguna.

Solusi:

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

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

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

Solusi:

Untuk mengatasi masalah ini, abaikan hasil yang ditampilkan oleh gkectl check-config. Untuk menonaktifkan ingress yang dipaketkan, lihat Menonaktifkan ingress yang dipaketkan.
Upgrade 1.16, 1.28, 1.29

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

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

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

Solusi:

  1. Dapatkan objek mesin yang dicerminkan dan simpan ke file lokal untuk tujuan pencadangan.
  2. Jalankan perintah berikut untuk menghapus finalizer dari mesin yang dicerminkan dan tunggu hingga dihapus dari cluster pengguna. 
        kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
  3. Ikuti langkah-langkah di Node bidang kontrol cluster pengguna Controlplane V2 untuk memicu perbaikan node di node bidang kontrol, sehingga spesifikasi mesin sumber yang benar akan disinkronkan ulang ke cluster pengguna.
  4. Jalankan ulang gkectl upgrade cluster untuk melanjutkan upgrade
Konfigurasi, Penginstalan 1.15, 1.16, 1.28, 1.29

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

Solusi:

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

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

Solusi:

  • Nonaktifkan multipathd
Update 1.15, 1.16

Jika beberapa konfigurasi yang diperlukan kosong di cluster admin karena validasi dilewati, menambahkannya mungkin diblokir oleh webhook cluster admin. Misalnya, jika kolom gkeConnect tidak ditetapkan di cluster admin yang 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

Jika 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, Google Distributed Cloud akan menetapkan nilai default ke semua NodePort termasuk manualLB.controlPlaneNodePort, yang menyebabkan pembuatan cluster gagal dengan pesan error berikut:

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

Solusi:

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

loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...
Upgrade, Update 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

Jika cluster admin dan cluster pengguna dengan ControlPlane V2 yang diaktifkan menggunakan kredensial vSphere yang berbeda, misalnya, setelah mengupdate kredensial vSphere untuk cluster admin, clusterapi-controller mungkin gagal terhubung ke vCenter setelah dimulai ulang. Melihat 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 dengan Controlplane V2 yang diaktifkan menggunakan kredensial vSphere yang sama.

Logging dan pemantauan 1,14

Prometheus mungkin melaporkan pemberitahuan yang mirip dengan contoh berikut:

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

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

  1. Periksa metrik grpc_server_handled_total mentah dengan 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 pada semua kode selain OK dapat diabaikan dengan aman jika kode tersebut bukan salah satu dari kode berikut: 
    Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Solusi:

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

  1. Senyapkan pemberitahuan dari UI Pengelola Notifikasi.
  2. Jika membisukan pemberitahuan bukan opsi, tinjau langkah-langkah berikut untuk menyembunyikan positif palsu:
    1. Skalakan operator pemantauan ke replika 0 sehingga 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 yang bermasalah, periksa log etcd dan log kube-apiserver untuk men-debug lebih lanjut.
Jaringan 1.16.0-1.16.2, 1.28.0

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

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

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


Solusi:

Tidak ada solusi mudah, dan kami belum melihat masalah dalam versi 1.16 dari perilaku ini. Jika Anda melihat koneksi yang lama terputus karena masalah ini, solusinya adalah menggunakan beban kerja di node yang sama dengan alamat IP keluar, atau mengirim pesan secara konsisten di koneksi TCP.
Operasi 1.14, 1.15, 1.16

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

Solusi:

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

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 pra-penerbangan. Meskipun pemeriksaan ini tidak diperlukan saat menonaktifkan ingress yang dipaketkan, pemeriksaan preflight gkectl akan gagal jika disableBundledIngress ditetapkan ke true.


Solusi:

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

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

Untuk informasi selengkapnya, lihat cara menonaktifkan ingress yang dipaketkan untuk cluster yang ada.
Upgrade, Update 1.13, 1.14, 1.15.0-1.15.6

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

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

Solusi:

Jika Anda terpengaruh oleh masalah ini, Anda dapat mengupdate cluster admin dengan 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 tanda --disable-update-from-checkpoint, perintah update tidak menggunakan file checkpoint sebagai sumber tepercaya selama update cluster. File checkpoint masih diperbarui untuk penggunaan di masa mendatang.
Penyimpanan 1.15.0-1.15.6, 1.16.0-1.16.2

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

Ada beberapa masalah umum yang dapat mencegah Pod ini dimulai:

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

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

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

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

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

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

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

Jika Pod Workload CSI tidak dimulai karena injeksi sidecar Istio, Anda dapat menonaktifkan injeksi sidecar 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. Buat Pod yang menggunakan PVC.
  3. Pastikan Pod dapat membaca/menulis data ke volume.
  4. Hapus Pod dan PVC setelah Anda memverifikasi operasi yang tepat.

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

Operasi 1.16.0-1.16.2

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

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

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

Solusi:

  1. Jalankan perintah berikut untuk men-deploy ulang validation-controller: 
          gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
  2. Setelah persiapan selesai, jalankan gkectl update cluster lagi untuk mengupdate cluster pengguna
Operasi 1.16.0-1.16.2

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

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

Karena validation-controller ditambahkan di 1.16, saat menggunakan cluster admin 1.15, validation-controller yang bertanggung jawab untuk memicu pemeriksaan pra-penerbangan tidak ada. Oleh karena itu, saat mencoba membuat cluster pengguna, pemeriksaan pra-penerbangan akan berhenti berfungsi 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 gkectl create cluster lagi untuk membuat cluster pengguna
Upgrade, Update 1.16.0-1.16.2

Saat 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 tersebut mungkin ditolak oleh webhook cluster admin. Salah satu pesan error berikut mungkin ditampilkan:

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

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


Solusi:

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

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

Saat Anda login ke workstation admin yang dikelola pengguna, perintah gkectl delete cluster mungkin kehabisan waktu tunggu 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. Saat kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba menghapus cluster: 

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

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

Solusi:

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

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

Jaringan 1.15, 1.16

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

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


Solusi:

Ubah port VXLAN yang digunakan oleh Cilium menjadi 4789:

  1. Edit ConfigMap cilium-config: 
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
  2. Tambahkan hal berikut ke ConfigMap cilium-config: 
    tunnel-port: 4789
  3. Mulai ulang DaemonSet anetd: 
    kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

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

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


Solusi:

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

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

Jika Anda sudah memiliki disk dengan CBT yang diaktifkan, ikuti langkah-langkah Penyelesaian dalam artikel VMware KB untuk menonaktifkan CBT di Disk Kelas Satu.
Penyimpanan 1.14, 1.15, 1.16

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


Solusi:

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

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

Tabel berikut mencantumkan ketidakcocokan versi yang diidentifikasi:

Versi Google Distributed Cloud 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 penyimpangan versi ini.

Operasi 1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1

Saat dihapus, cluster Controlplane V2 non-HA akan macet pada penghapusan node hingga waktu tunggu 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 paksa cluster lagi: 
         gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force

Penyimpanan 1.15.0+, 1.16.0+

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


Solusi:

Edit configMap fitur vSphere CSI dan tetapkan list-volumes ke false:

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

Mulai ulang pod pengontrol vSphere CSI:

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

Jika cluster berisi volume persisten vSphere intree, perintah gkectl diagnose dan gkectl upgrade dapat memunculkan peringatan palsu terhadap persistent volume claim (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 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, Update 1.15.0+, 1.16.0+

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

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

Solusi:

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

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

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 penggunanya mungkin dibuat ulang secara tidak terduga.

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

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

Solusi saat mengupgrade cluster pengguna menggunakan konsol Google Cloud:

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

Opsi 2: Lakukan langkah-langkah berikut:

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

    Anotasi jalankan ulang adalah:

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

Solusi saat mengupgrade cluster pengguna menggunakan workstation admin Anda sendiri:

Opsi 1: Gunakan GKE 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 pra-penerbangan berjalan secara lokal di workstation admin Anda, bukan di server. 
    gke_on_prem_version: GKE_ON_PREM_VERSION
     Misalnya: 
    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

Selama pembuatan cluster, jika Anda tidak menentukan nama host untuk setiap alamat IP dalam file blok IP, pemeriksaan pra-penerbangan 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 pra-penerbangan yang menganggap nama host kosong sebagai duplikat.

Solusi:

Opsi 1: Gunakan versi dengan perbaikan.

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

Opsi 3: Tentukan nama host unik untuk setiap alamat IP dalam file blok IP.
Upgrade, Update 1.16

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

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

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

Solusi:

  1. SSH ke node bidang kontrol pengguna, karena merupakan cluster pengguna bidang kontrol v1, node bidang kontrol pengguna berada di cluster admin.
  2. Mulai ulang kubelet menggunakan perintah berikut: 
        sudo systemctl restart kubelet
    Setelah dimulai ulang, kubelet dapat merekonstruksi pemasangan global tahap dengan benar.
Upgrade, Update 1.16.0

Selama upgrade atau update cluster admin, kondisi perlombaan dapat menyebabkan pengelola pengontrol cloud vSphere menghapus node control plane baru secara tidak terduga. Hal ini menyebabkan clusterapi-controller macet menunggu node dibuat, dan pada akhirnya waktu upgrade/update habis. Dalam hal ini, output perintah upgrade/update gkectl mirip dengan berikut:

    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 gejalanya, jalankan perintah di bawah untuk mendapatkan log di vSphere cloud controller manager di cluster admin:

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

Berikut adalah contoh pesan error dari perintah di atas:

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

Solusi:

  1. Mulai ulang komputer yang gagal untuk membuat ulang objek node yang dihapus.
  2. Gunakan SSH ke setiap node bidang kontrol dan mulai ulang pod statis pengelola pengontrol cloud vSphere: 
          sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
      sudo crictl stop PREVIOUS_COMMAND_OUTPUT
  3. Jalankan kembali perintah upgrade/update.
Operasi 1.16

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 pengontrol cloud vSphere untuk cluster. Perintah yang Anda gunakan bergantung pada jenis cluster, sebagai 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 diduplikasi, 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 ke nama unik dan picu update paksa:
                gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
    2. Jalankan ulang gkectl upgrade cluster
  • Cluster admin:
    1. Perbarui nama host mesin yang terpengaruh di admin-ip-block.yaml menjadi nama unik dan picu update paksa:
                gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
    2. Jika cluster admin non-HA, dan Anda menemukan vm master admin menggunakan nama host duplikat, Anda juga perlu:
      Mendapatkan nama mesin master admin 
                kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
      Perbarui objek mesin master admin
      Catatan: NEW_ADMIN_MASTER_HOSTNAME harus sama dengan yang Anda tetapkan di admin-ip-block.yaml pada langkah 1.
                kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
      Verifikasi bahwa nama host diperbarui di objek mesin master admin:
                kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
          kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
    3. Jalankan ulang upgrade cluster admin dengan checkpoint dinonaktifkan:
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Solusi untuk penginstalan:

Lakukan solusi untuk jenis cluster yang berlaku.
Operasi 1.16.0, 1.16.1, 1.16.2, 1.16.3

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

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

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

Solusi untuk upgrade:

  1. Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `.
  2. Perbarui nama pengguna atau sandi vCenter di file konfigurasi kredensial.
  3. Memicu update paksa cluster.
    • Cluster pengguna: 
              gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
    • Cluster admin: 
              gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check

Solusi untuk penginstalan:

  1. Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `.
  2. Perbarui nama pengguna atau sandi vCenter di file konfigurasi kredensial.
  3. Lakukan solusi untuk jenis cluster yang berlaku.
Penyimpanan 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

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 perlombaan saat pengontrol vSphere CSI tidak menghapus mesin yang dihapus dari cache-nya.


Solusi:

Mulai ulang pod pengontrol vSphere CSI:

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

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

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

Solusi:

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

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

Untuk menemukan template VM mesin:

  1. Buka halaman Host dan Cluster di klien vSphere.
  2. Klik VM Templates dan filter menurut nama cluster admin.

    Anda akan melihat tiga template VM untuk cluster admin.

  3. Salin template VM nama yang cocok dengan nama mesin yang Anda perbaiki dan gunakan nama template dalam perintah perbaikan.
  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
Jaringan 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

Jika menggunakan Seesaw sebagai jenis load balancer untuk cluster dan melihat bahwa VM Seesaw 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 ruang disk di VM rendah karena fluent-bit yang berjalan di VM Seesaw tidak dikonfigurasi dengan rotasi log yang benar.


Solusi:

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

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

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

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

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


Solusi:

Jika Anda tidak dapat mengupgrade ke versi patch Google Distributed Cloud dengan perbaikan ini, 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

Jika cluster admin terdaftar di GKE On-Prem API, mengupgrade cluster admin ke versi yang terpengaruh dapat gagal karena keanggotaan fleet tidak dapat diperbarui. Saat 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 terdaftar di API saat Anda mendaftarkan secara eksplisit cluster, atau saat Anda 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 error `gagal mendaftarkan cluster` yang sudah tidak berlaku untuk sementara. Setelah beberapa saat, status akan diperbarui secara otomatis.
Upgrade, Update 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

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

Cluster admin terdaftar di API saat Anda mendaftarkan secara eksplisit cluster, atau saat Anda 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 daftarkan ulang cluster admin lagi.
Upgrade, Update 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

Kondisi perlombaan tertentu dapat menyebabkan status OnPremAdminCluster tidak konsisten antara checkpoint dan CR sebenarnya. Saat 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 solusinya.
Operasi 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

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

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

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

    Perintah ini dapat menampilkan error otorisasi seperti berikut:

    Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
  • Log kube-apiserver untuk cluster admin Anda mungkin berisi error seperti berikut: 
    Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Solusi:

Upgrade ke versi Google Distributed Cloud dengan perbaikan: 1.13.10+, 1.14.6+, 1.15.2+. Jika Anda tidak dapat melakukan upgrade, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
Jaringan, Operasi 1.10, 1.11, 1.12, 1.13, 1.14

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

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

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


Solusi:

Upgrade ke 1.15 atau yang lebih baru.

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

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

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
 Mendapatkan nama cluster admin: 
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
 Hapus langganan fleet: 
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 periode waktu untuk perintah journalctl yang berjalan di node cluster

Hal ini tidak memengaruhi fungsi pengambilan snapshot cluster, karena snapshot masih menyertakan semua log yang dikumpulkan secara default dengan menjalankan journalctl di node cluster. Oleh karena itu, tidak ada informasi proses debug yang terlewat.
Penginstalan, Upgrade, Update 1.9+, 1.10+, 1.11+, 1.12+

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


Solusi:

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

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


Opsi 1: Upgrade Blue/Green

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

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


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

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

  1. Hapus node pool Windows yang ada dengan menghapus konfigurasi node pool Windows dari file user-cluster.yaml, lalu jalankan perintah: 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. Upgrade cluster admin+pengguna khusus Linux ke 1.12 dengan mengikuti panduan pengguna upgrade untuk versi minor target yang sesuai.
  3. (Pastikan untuk melakukan langkah ini sebelum mengupgrade ke 1.13) Pastikan enableWindowsDataplaneV2: true dikonfigurasi di CR OnPremUserCluster. Jika tidak, cluster akan terus menggunakan node pool Docker untuk Windows, yang tidak akan kompatibel dengan template VM Windows 1.13 yang baru dibuat dan tidak menginstal Docker. Jika tidak dikonfigurasi atau disetel ke salah (false), update cluster Anda untuk menyetelnya 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 gkectl 1.13: 
    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Tambahkan kembali konfigurasi node pool Windows ke user-cluster.yaml dengan kolom OSImage ditetapkan ke template VM Windows yang baru dibuat.
  7. Mengupdate cluster untuk menambahkan node pool Windows 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Penginstalan, Upgrade, Update 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Nilai default 5 detik untuk RootDistanceMaxSec akan digunakan di node, bukan 20 detik yang seharusnya merupakan konfigurasi yang diharapkan. Jika memeriksa log startup node dengan 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 saat drift 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, Update 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

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 setelan osImageType dari string kosong menjadi ubuntu_containerd.

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


Solusi:

Upgrade ke versi Google Distributed Cloud dengan perbaikan. Jika upgrade tidak memungkinkan bagi Anda, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
Pemasangan, Keamanan 1.13, 1.14, 1.15, 1.16

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


Solusi:

Sampai patch Google Distributed Cloud 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

Mesin panel kontrol admin gagal dimulai saat nama pengguna registry pribadi berisi $. Saat memeriksa /var/log/startup.log di 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 Google Distributed Cloud dengan perbaikan.
Upgrade, Update 1.12.0-1.12.4

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

    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      -         CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      +         CARotation:        nil,
      ...
    }
Upgrade, Update 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Setelah Anda memutar 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 secret di cluster admin pada namespace USER_CLUSTER_NAME, dan dapatkan nama secret kunci penandatanganan ksa: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. Salin secret ksa-signing-key, dan 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 secret kunci penandatanganan ksa sebelumnya: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Perbarui kolom data.data di configmap ksa-signing-key-rotation-stage menjadi '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
  5. Nonaktifkan webhook validasi untuk mengedit informasi versi di resource kustom OnPremUserCluster: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. Perbarui kolom spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation menjadi 1 di resource kustom OnPremUserCluster: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. Tunggu hingga cluster pengguna target siap, Anda dapat memeriksa statusnya dengan: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Pulihkan webhook validasi untuk cluster pengguna: 
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Hindari rotasi kunci penandatanganan KSA lain hingga cluster diupgrade ke versi dengan perbaikan.
Operasi 1.13.1+, 1.14, 1., 1.16

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


Solusi:

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

Penginstalan, Upgrade, Update 1.13.8, 1.14.4

Jika Anda membuat cluster admin versi 1.13.8 atau versi 1.14.4, atau mengupgrade cluster admin ke versi 1.13.8 atau 1.14.4, cluster kind akan menarik gambar penampung 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, pembuatan atau upgrade cluster admin akan gagal menampilkan cluster jenis. Menjalankan perintah berikut di workstation admin akan menampilkan container yang sesuai yang tertunda dengan ErrImagePull:

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

    Responsnya berisi entri seperti berikut:

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

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


    Solusi:

    Jalankan perintah berikut di workstation admin, saat 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

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

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


    Solusi:

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

    vsphere-csi-controller harus memuat ulang secret vCenter 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

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

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

    Anda juga dapat memeriksa apakah Anda dapat menemukan cluster di antara cluster terdaftar di cloud console.

    Solusi:

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

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

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

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


    Solusi:

    Periksa apakah cluster ditampilkan 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 versi 1.12 dan yang lebih baru, ikuti petunjuk untuk mencoba lagi pendaftaran cluster admin setelah pembuatan cluster. Untuk cluster yang diupgrade ke versi sebelumnya,
    1. Tambahkan pasangan nilai kunci palsu seperti "foo: bar" ke file kunci SA connect-register
    2. Jalankan gkectl update admin untuk mendaftarkan ulang cluster admin.

    Penyimpanan 1.15, 1.16

    Dalam kondisi tertentu, disk dapat dilampirkan sebagai hanya baca ke node Windows. Hal ini menyebabkan volume yang sesuai menjadi hanya baca di dalam Pod. Masalah ini lebih cenderung terjadi saat kumpulan node baru menggantikan kumpulan node lama (misalnya, upgrade cluster atau update node pool). Workload stateful yang sebelumnya berfungsi dengan baik mungkin tidak dapat menulis ke volumenya di 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 maupun antarmuka web vSphere.
    5. Menetapkan variabel lingkungan: 
      PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Identifikasi nomor disk untuk disk yang terkait dengan PersistentVolume: 
      PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. Verifikasi bahwa disk adalah readonly: 
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
       Hasilnya akan berupa True.
    8. Tetapkan readonly ke false. 
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Hapus Pod agar dimulai ulang: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. Pod harus dijadwalkan ke node yang sama. Namun, jika Pod dijadwalkan ke node baru, Anda mungkin perlu mengulangi langkah-langkah sebelumnya di node baru.

    Upgrade, 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 memperbarui kredensial cluster, Anda mungkin menemukan vsphere-csi-secret di bawah namespace kube-system di cluster admin yang masih menggunakan kredensial lama.


    Solusi:

    1. Dapatkan nama secret vsphere-csi-secret: 
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Perbarui data secret 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 diperbarui harus digunakan oleh pengontrol.
    Upgrade, 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 mungkin mengalami crashloop karena --cluster-name kosong. Perilaku ini disebabkan oleh bug dalam logika update, dengan nama cluster tidak disebarkan ke manifes pod / penampung 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 v1 bidang kontrol, edit penampung audit-proxy di statefulset kube-apiserver untuk menambahkan --cluster_name=USER_CLUSTER_NAME:

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

    Tepat setelah gkectl upgrade cluster, pod panel kontrol mungkin di-deploy ulang. Status cluster dari gkectl list clusters berubah dari RUNNING MENJADI RECONCILING. Permintaan ke cluster pengguna mungkin kehabisan waktu tunggu.

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

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


    Solusi:

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

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

    Solusi:

    Sebagai gantinya, gunakan rilis 1.12.7-gke.20.
    Upgrade, Update 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    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 image lama atau pod gke-connect-agent tidak dapat ditarik karena ImagePullBackOff.

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


    Solusi:

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

    1. Hapus namespace gke-connect: 
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Deploy ulang gke-connect-agent dengan kunci akun layanan pendaftaran asli (tidak perlu memperbarui kunci):

      Untuk cluster admin: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
       Untuk cluster pengguna: 
      gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

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

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

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

    1. Salin secret default ke namespace gke-connect: 
      kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. Dapatkan nama deployment gke-connect-agent: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Tambahkan secret default ke deployment gke-connect-agent: 
      kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    Penginstalan 1.13, 1.14

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

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

    Solusi:

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

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

    gkectl check-config --skip-validation-load-balancer
    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

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

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

    Masalah ini dapat membuat cluster tidak berfungsi.

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

    Solusi

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

    Untuk melihat metrik ini di Metrics Explorer:

    1. Buka Metrics Explorer di 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 categories, pilih Anthos.
      3. Di menu Active metrics, pilih etcd_network_client_grpc_sent_bytes_total.
      4. Klik Terapkan.
    Upgrade, Update 1.10, 1.11, 1.12, 1.13, dan 1.14

    Saat memulai ulang atau mengupgrade cluster, Identity Service GKE dapat kewalahan dengan traffic yang terdiri dari token JWT yang sudah tidak berlaku dan diteruskan dari kube-apiserver ke Identity Service GKE melalui webhook autentikasi. Meskipun tidak mengalami crashloop, Layanan Identitas GKE menjadi tidak responsif dan berhenti menayangkan permintaan lebih lanjut. Masalah ini pada akhirnya menyebabkan latensi bidang kontrol yang lebih tinggi.

    Masalah ini telah diperbaiki dalam rilis Google Distributed Cloud berikut:

    • 1.12.6+
    • 1.13.6+
    • 1.14.2+

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

    1. Periksa apakah endpoint Identity Service GKE dapat dijangkau secara eksternal: 
      curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

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

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

    2. Periksa log GKE Identity Service dan kube-apiserver:
      1. Periksa log GKE Identity Service: 
        kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

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

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

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

        Cluster admin:

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

        Cluster pengguna:

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

        Jika log kube-apiserver berisi entri seperti berikut, 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 langsung mengupgrade cluster untuk mendapatkan perbaikan, Anda dapat mengidentifikasi dan memulai ulang pod yang melanggar sebagai solusi:

    1. Tingkatkan tingkat kejelasan Identity Service GKE menjadi 9: 
      kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Periksa log Identity Service GKE untuk mengetahui konteks token yang tidak valid: 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Untuk mendapatkan payload token yang terkait dengan setiap konteks token yang tidak valid, urai setiap secret akun layanan terkait dengan perintah berikut: 
      kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Untuk mendekode token dan melihat nama dan namespace pod sumber, salin token ke debugger di jwt.io.
    5. Mulai ulang pod yang diidentifikasi dari token.
    Operasi 1.9, 1.10, 1.11, 1.12, 1.13

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


    Solusi:

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

    kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Jaringan 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    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 seesaw sudah ada. Selain itu, pemeriksaan pra-penerbangan mencoba memvalidasi load balancer seesaw yang tidak ada.

    Solusi:

    Hapus file grup seesaw 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.
    Jaringan 1,14

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

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

    sudo conntrack -S

    Responsnya akan terlihat seperti ini:

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

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

    Solusi

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

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

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

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

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


    Solusi:

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

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

    Hapus spec.template.spec.tolerations berikut:

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

    Lalu, tambahkan toleransi berikut:

        - key: node-role.kubernetes.io/master
      operator: Exists
    Penyimpanan 1.12+, 1.13.3

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

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

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

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

    # See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

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

    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+

    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+

    Di 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 dimatikan atau dimulai ulang. Setelah perubahan ini, VM akan mengirimkan pesan tersebut dan menampilkan IP ke server DHCP. Akibatnya, IP yang dirilis dapat dialokasikan ulang ke VM yang berbeda dan/atau IP yang berbeda dapat ditetapkan ke VM, sehingga menyebabkan konflik IP (di tingkat Kubernetes, bukan tingkat vSphere) dan/atau perubahan IP pada VM, yang dapat merusak cluster dengan berbagai cara.

    Misalnya, Anda mungkin melihat gejala berikut.

    • UI vCenter menunjukkan bahwa tidak ada VM yang menggunakan IP yang sama, tetapi kubectl get nodes -o wide menampilkan node dengan IP duplikat. 
      NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
    • Node baru gagal dimulai karena error calico-node 
      2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


    Solusi:

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

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

    Operasi, Upgrade, Update 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

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

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

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
     Jika Anda menemukan output kosong, artinya kunci telah dihapus.

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

    • Kegagalan pra-penerbangan validasi lambat dengan pesan error: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Penyiapan oleh 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 menjalankan gkectl update admin --enable-preview-user-cluster-central-upgrade untuk men-deploy pengontrol platform upgrade, perintah akan gagal dengan pesan: "failed to download bundle to disk: dialing: unexpected end of JSON input" (Anda dapat melihat pesan ini di kolom status dalam output kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).


    Solusi:

    Tambahkan kunci akun layanan akses komponen kembali 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+

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

      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
    Pod autoscaler 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 node pool dengan `gkectl update cluster` hingga mengupgrade ke versi dengan perbaikan
    Penginstalan 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

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

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


    Solusi:

    Sertakan setiap IP dalam file blok IP hingga mengupgrade ke versi dengan perbaikan: 1.12.5, 1.13.4, 1.14.1+.
    Operasi 1.10, 1.11, 1.12, 1.13, 1.14.0

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

      error getting ClusterInformation: connection is unauthorized: Unauthorized

    Masalah ini hanya diamati 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 ditetapkan ke `false`, atau tidak ditentukan, berarti Anda menggunakan Calico di cluster pengguna.

    Penampung install-cni node membuat kubeconfig dengan token yang berlaku 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 di node.


    Solusi:

    Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.14.1. Upgrade ke versi ini atau yang lebih baru.

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

      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

    Pembuatan cluster gagal meskipun pengguna memiliki konfigurasi yang tepat. Pengguna melihat pembuatan 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 sudah cukup.

    Upgrade, Update 1.11, 1.12

    Jika Anda menggunakan Google Distributed Cloud versi 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 di namespace gmp-system dan CRD dikelola oleh objek stackdriver, dengan tanda enableGMPForApplications ditetapkan ke false secara default. Jika Anda men-deploy komponen GMP secara manual di namespace sebelum mengupgrade ke 1.12, resource akan dihapus oleh stackdriver.


    Solusi:
    Operasi 1.11, 1.12, 1.13.0 - 1.13.1

    Dalam skenario system, snapshot cluster tidak menyertakan resource apa pun dalam 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, Update 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Saat menghapus, mengupdate, atau mengupgrade cluster pengguna, node drain mungkin macet dalam skenario berikut:

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

    Untuk mengidentifikasi gejalanya, jalankan perintah di bawah:

    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 yang menyebabkan node drain macet 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

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

    Gejalanya adalah sebagai berikut:

    • Log cluster-autoscaler
      • 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:

    Verifikasi apakah clusterrole dan clusterrolebinding tidak ada di cluster admin 

    • kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
       
    • kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler

    Terapkan clusterrole dan clusterrolebinding berikut ke cluster admin jika tidak ada. Tambahkan subjek akun layanan ke clusterrolebinding untuk setiap cluster pengguna.

    • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
  resources: ["clusters"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
  resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
  resources: ["onpremuserclusters"]
  verbs: ["get", "list", "watch"]
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  resourceNames: ["cluster-autoscaler"]
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
  - ""
  resources:
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - ""
  resources:
  - pods/eviction
  verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
  resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["poddisruptionbudgets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "csinodes"]
  verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["cluster-autoscaler-status"]
  verbs: ["get", "update", "patch", "delete"]
       
    • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-autoscaler
subjects:
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_1 
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_2 
  ...
    Konfigurasi 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    Saat cluster pengguna dihapus, clusterrole yang sesuai juga akan dihapus, yang menyebabkan perbaikan otomatis dan ekspor metrik vsphere tidak berfungsi

    Gejalanya adalah sebagai berikut:

    • Log cluster-health-controller
      • 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
    • Log vsphere-metrics-exporter
      • 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:

    Terapkan yaml berikut ke cluster admin

    • Untuk vsphere-metrics-exporter
      • kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: vsphere-metrics-exporter
rules:
  - apiGroups:
      - cluster.k8s.io
    resources:
      - clusters
    verbs: [get, list, watch]
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: vsphere-metrics-exporter
  name: vsphere-metrics-exporter
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vsphere-metrics-exporter
subjects:
  - kind: ServiceAccount
    name: vsphere-metrics-exporter
    namespace: kube-system
    • Untuk cluster-health-controller
      • apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-health-controller-role
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - "*"
    Konfigurasi 1.12.1-1.12.3, 1.13.0-1.13.2

    Masalah umum yang dapat menyebabkan kegagalan gkectl check-config tanpa menjalankan gkectl prepare. Hal ini membingungkan karena sebaiknya Anda menjalankan 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 image OS yang tidak ada.

    Opsi 2: gunakan gkectl check-config --skip-validation-os-images untuk melewati validasi image OS.
    Upgrade, Update 1.11, 1.12, 1.13

    Masalah umum yang dapat menyebabkan gkectl update admin/cluster gagal 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:

    Agar update dapat diterapkan, mesin harus dibuat ulang after update yang gagal.

    Untuk update cluster admin, node master pengguna dan add-on admin perlu dibuat ulang

    Untuk update cluster pengguna, node pekerja pengguna perlu dibuat ulang

    Untuk membuat ulang node pekerja pengguna

    Opsi 1
    Dalam dokumentasi versi 1.11, ikuti memperbarui node pool dan ubah CPU atau memori untuk memicu pembuatan ulang node secara bertahap.

    Opsi 2
    Gunakan kubectl delete untuk membuat ulang mesin satu per satu

    kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG

    Untuk membuat ulang node master pengguna

    Opsi 1
    Dalam dokumentasi versi 1.11, ikuti mengubah ukuran bidang kontrol dan ubah CPU atau memori untuk memicu pembuatan ulang node secara bertahap.

    Opsi 2
    Gunakan kubectl delete untuk membuat ulang mesin satu per satu

    kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

    Untuk membuat ulang node add-on admin

    Gunakan kubectl delete untuk membuat ulang mesin satu per satu

    kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
    Penginstalan, Upgrade, Update 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

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

    Untuk melihat CSR yang tertunda untuk node, jalankan perintah berikut:

    kubectl get csr -A -o wide

    Periksa log berikut untuk menemukan pesan error:

    • Lihat log di cluster admin untuk penampung 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
       dengan:
      • 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 di 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 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 VM dan nama node akan ditetapkan ke bob-vm-1.

    Jika verifikasi ID node diaktifkan, pemberi persetujuan CSR akan membandingkan nama node dengan nama host dalam spesifikasi Komputer, dan gagal merekonsiliasi nama tersebut. Pengajuan CSR ditolak oleh pemberi persetujuan, 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: 
      disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Simpan file, 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. Gunakan SSH untuk mengakses 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
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    In networkgatewaygroups.status.nodes, some nodes switch between NotHealthy and Up.

    Logs for the ang-daemon Pod running on that node reveal repeated errors: 

    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 floating tambahan ke node. Hal ini dapat menyebabkan beban yang lebih tinggi pada node lain atau kurangnya redundansi untuk ketersediaan tinggi.

    Aktivitas dataplane tidak terpengaruh.

    Persaingan pada objek networkgatewaygroup menyebabkan beberapa pembaruan status gagal karena kesalahan dalam penanganan percobaan ulang. Jika terlalu banyak pembaruan status gagal, ang-controller-manager akan menganggap node telah melewati batas waktu heartbeat dan menandai node NotHealthy.

    Kesalahan dalam penanganan percobaan ulang telah diperbaiki di versi yang lebih baru.


    Solusi:

    Upgrade ke versi yang diperbaiki, jika tersedia.
    Upgrade, Update 1.12.0-1.12.2, 1.13.0

    Masalah umum yang dapat menyebabkan upgrade atau update cluster stuck menunggu objek mesin lama dihapus. Hal ini karena finalizer tidak dapat dihapus dari objek mesin. Hal ini memengaruhi operasi update rolling 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 seperti di bawah ini:

    $ 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 ini berulang untuk mesin yang sama selama beberapa menit untuk menjalankan yang berhasil meskipun tanpa masalah ini, sebagian besar waktu dapat berjalan dengan cepat, tetapi dalam beberapa kasus yang jarang terjadi, error ini dapat terjebak dalam kondisi race ini selama beberapa jam.

    Masalahnya adalah VM yang mendasarinya sudah dihapus di vCenter, tetapi objek mesin yang sesuai tidak dapat dihapus, yang macet di penghapusan finalizer karena update yang sangat sering dari pengontrol lain. Hal ini dapat menyebabkan waktu tunggu perintah gkectl habis, tetapi pengontrol 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. Batasan opsi ini adalah tidak pasti berapa lama waktu yang diperlukan untuk penghapusan finalizer untuk setiap objek mesin. Proses ini dapat langsung selesai jika cukup beruntung, atau dapat berlangsung selama beberapa jam jika rekonsiliasi pengontrol set mesin terlalu cepat dan pengontrol mesin tidak pernah mendapatkan kesempatan untuk menghapus finalizer di antara rekonsiliasi.

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

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

      Kelemahannya adalah pod di mesin akan dihapus langsung, bukan dihapus, yang berarti pod tidak akan mengikuti 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 waktu yang lama, hubungi tim dukungan kami untuk mitigasi.
    Penginstalan, Upgrade, Update 1.10.2, 1.11, 1.12, 1.13

    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 pra-penerbangan 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

    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 yaml konfigurasi cluster admin atau cluster pengguna.
    Penginstalan, Upgrade, Update 1.10, 1.11, 1.12, 1.13

    gkectl prepare dapat mengalami error dengan stacktrace 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 adalah 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, Update 1.10, 1.11, 1.12, 1.13

    Setelah upaya upgrade cluster admin gagal, jangan jalankan gkectl repair admin-master. Tindakan ini dapat menyebabkan upaya upgrade admin berikutnya gagal dengan masalah seperti kegagalan daya master admin atau VM tidak dapat diakses.


    Solusi:

    Jika Anda telah mengalami skenario kegagalan ini, hubungi dukungan.
    Sistem operasi 1.12, 1.13

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


    Solusi:

    Kami beralih kembali ke cgroup v1 (hibrida) dalam 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

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


    Solusi:

    Sebaiknya cadangkan resource ClientConfig setelah setiap perubahan manual.
    Penginstalan 1.10, 1.11, 1.12, 1.13

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

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


    Solusi:

    Coba jalankan gkectl check-config lagi.
    Penginstalan 1.12

    Anda mungkin melihat kegagalan penginstalan karena cert-manager-cainjector dalam crashloop, saat apiserver/etcd 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:

    Jalankan perintah berikut untuk mengurangi masalah.

    Pertama, skalakan monitoring-operator ke bawah agar tidak mengembalikan perubahan ke Deployment cert-manager:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=0

    Edit Deployment cert-manager-cainjector untuk menonaktifkan pemilihan pemimpin, karena kita hanya memiliki satu replika yang berjalan. Hal ini tidak diperlukan untuk satu replika:

    # Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
    -n kube-system deployment cert-manager-cainjector

    Cuplikan YAML yang relevan untuk deployment cert-manager-cainjector akan terlihat seperti contoh berikut:

    ...
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager-cainjector
  namespace: kube-system
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: cert-manager
        image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
        args:
        ...
        - --leader-elect=false
...

    Tetapkan replika monitoring-operator ke 0 sebagai mitigasi hingga penginstalan selesai. Jika tidak, perubahan akan dikembalikan.

    Setelah penginstalan selesai dan cluster aktif dan berjalan,aktifkan monitoring-operator untuk operasi hari ke-2:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
    scale deployment monitoring-operator --replicas=1

    Setelah setiap upgrade, perubahan akan dikembalikan. Lakukan langkah-langkah yang sama lagi untuk memitigasi masalah ini hingga diperbaiki dalam rilis mendatang.
    VMware 1.10, 1.11, 1.12, 1.13

    Jika vCenter, untuk versi yang lebih rendah dari 7.0U2, dimulai ulang, setelah upgrade atau tidak, 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 Koneksi > Putuskan Sambungan. Selanjutnya, hubungkan kembali, yang akan memaksa update grup port VM.
    Sistem operasi 1.10, 1.11, 1.12, 1.13

    Untuk Google Distributed Cloud versi 1.7.2 dan yang lebih baru, image OS Ubuntu di-harden dengan CIS L1 Server Benchmark.

    Untuk memenuhi aturan CIS "5.2.16 Pastikan Interval Waktu tunggu Tidak Ada Aktivitas 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 terduga. Saat Anda menggunakan sesi ssh di workstation admin, atau node cluster, koneksi SSH mungkin terputus meskipun klien ssh Anda tidak tidak ada aktivitas, 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 untuk mencegah perintah Anda dihentikan saat koneksi SSH terputus, 
      nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Perbarui sshd_config untuk menggunakan nilai ClientAliveCountMax yang 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

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

    Anda hanya perlu menerapkan solusi ini satu kali untuk setiap cluster, dan perubahan 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) dapat dikembalikan ke versi sebelumnya. Hal ini disebabkan oleh monitoring-operator yang mencoba merekonsiliasi cert-manager, dan mengembalikan versi dalam proses.

    Solusi:

    <pMenghindari konflik selama upgrade

    1. Uninstal versi cert-manager Anda. Jika menentukan resource sendiri, sebaiknya cadangkan resource tersebut.
    2. Lakukan upgrade.
    3. Ikuti petunjuk berikut untuk memulihkan cert-manager Anda sendiri.

    Memulihkan cert-manager Anda sendiri di cluster pengguna

    • Menskalakan 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 kustom Anda jika ada.
    • Anda dapat melewati langkah ini jika menggunakan penginstalan cert-manager default upstream, atau Anda yakin cert-manager diinstal di namespace cert-manager. Jika tidak, salin Sertifikat metrics-ca cert-manager.io/v1 dan resource Issuer metrics-pki.cluster.local dari cert-manager ke namespace resource cluster cert-manager yang diinstal. 
      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

    Merestor cert-manager Anda sendiri di cluster admin

    Secara umum, Anda tidak perlu menginstal ulang cert-manager di cluster admin karena cluster admin hanya menjalankan workload platform kontrol Google Distributed Cloud. Dalam kasus yang jarang terjadi, jika Anda juga perlu menginstal cert-manager Anda sendiri di cluster admin, ikuti petunjuk berikut untuk menghindari konflik. Perhatikan bahwa jika Anda adalah pelanggan Apigee dan hanya memerlukan cert-manager 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 kustom Anda jika ada.
    • Anda dapat melewati langkah ini jika menggunakan penginstalan cert-manager default upstream, atau Anda yakin cert-manager diinstal di namespace cert-manager. Jika tidak, salin Sertifikat metrics-ca cert-manager.io/v1 dan resource Issuer metrics-pki.cluster.local dari cert-manager ke namespace resource cluster cert-manager yang diinstal. 
      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
    </p
    Sistem operasi 1.10, 1.11, 1.12, 1.13

    Docker, containerd, dan runc dalam image OS Ubuntu yang dikirimkan dengan Google Distributed Cloud disematkan ke versi khusus menggunakan Ubuntu PPA. Hal ini memastikan bahwa setiap perubahan runtime penampung akan memenuhi syarat oleh Google Distributed Cloud sebelum setiap rilis.

    Namun, versi khusus tidak diketahui oleh Ubuntu CVE Tracker, yang digunakan sebagai feed kerentanan oleh berbagai alat pemindaian CVE. Oleh karena itu, Anda akan melihat positif palsu dalam hasil pemindaian kerentanan Docker, containerd, dan runc.

    Misalnya, Anda mungkin melihat positif palsu berikut dari hasil pemindaian CVE. CVE ini telah diperbaiki di versi patch terbaru Google Distributed Cloud.

    Lihat catatan rilis] untuk mengetahui perbaikan CVE.


    Solusi:

    Canonical mengetahui masalah ini, dan perbaikannya dilacak di https://github.com/canonical/sec-cvescan/issues/73.
    Upgrade, Update 1.10, 1.11, 1.12, 1.13

    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 untuk sementara waktu. 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. Dalam cluster non-HA, hanya ada satu replika untuk Statefulset. Jadi, selama upgrade, ada kemungkinan kube-apiserver lama tidak tersedia saat kube-apiserver baru belum siap.


    Solusi:

    Periode nonaktif ini hanya terjadi selama proses upgrade. Jika Anda menginginkan waktu nonaktif yang lebih singkat selama upgrade, sebaiknya beralihlah ke cluster HA.
    Penginstalan, Upgrade, Update 1.10, 1.11, 1.12, 1.13

    Jika Anda membuat atau mengupgrade cluster HA dan melihat bahwa pemeriksaan kesiapan koneksi gagal dalam diagnosis cluster, biasanya hal ini tidak akan memengaruhi fungsi Google Distributed Cloud (kubectl exec, log kubectl, dan webhook). Hal ini terjadi karena terkadang satu atau dua replika konektivitas mungkin belum siap selama jangka waktu tertentu karena jaringan yang tidak stabil atau masalah lainnya.


    Solusi:

    Konektivitas akan pulih dengan sendirinya. Tunggu selama 30 menit hingga 1 jam, lalu jalankan kembali diagnosis cluster.
    Jaringan 1.10, 1.11, 1.12, 1.13

    Saat men-deploy Google Distributed Cloud versi 1.9 atau yang lebih baru, jika deployment memiliki load balancer Seesaw yang dipaketkan di lingkungan yang menggunakan aturan firewall terdistribusi stateful NSX-T, stackdriver-operator mungkin gagal membuat ConfigMap gke-metrics-agent-conf dan menyebabkan Pod gke-connect-agent berada dalam 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 Google Distributed Cloud yang menggunakan Seesaw. Anda mungkin melihat masalah koneksi serupa pada aplikasi Anda sendiri saat membuat objek Kubernetes besar yang ukurannya lebih besar dari 32K.


    Solusi:

    Dalam dokumentasi versi 1.13, ikuti petunjuk ini untuk menonaktifkan aturan firewall terdistribusi NSX-T, atau untuk menggunakan aturan firewall terdistribusi stateless untuk VM Seesaw.

    Jika cluster Anda menggunakan load balancer manual, ikuti petunjuk ini untuk mengonfigurasi load balancer agar mereset koneksi klien saat mendeteksi kegagalan node backend. Tanpa konfigurasi ini, klien server Kubernetes API mungkin berhenti merespons selama beberapa menit saat instance server mengalami error.
    Logging dan pemantauan 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Untuk Google Distributed Cloud versi 1.10 hingga 1.15, beberapa pelanggan menemukan penagihan yang tidak terduga tinggi untuk Metrics volume di halaman Billing. 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 Cloud Service Mesh juga dapat menambahkan anotasi ini.)

    Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini, cantumkan metrik yang ditentukan pengguna. Jika Anda melihat tagihan untuk metrik yang tidak diinginkan dengan awalan nama external.googleapis.com/prometheus dan juga melihat enableStackdriverForApplications ditetapkan ke true 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 beralih ke solusi pemantauan aplikasi baru managed-service-for-prometheus yang tidak lagi mengandalkan anotasi prometheus.io/scrap=true. Dengan solusi baru ini, Anda juga dapat mengontrol pengumpulan log dan metrik secara terpisah untuk aplikasi Anda, masing-masing dengan flag enableCloudLoggingForApplications dan enableGMPForApplications.

    Untuk berhenti menggunakan flag enableStackdriverForApplications, buka objek `stackdriver` untuk diedit:

    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 Layanan sumber yang memiliki metrik yang ditagih dan 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 Layanan. Jika anotasi ditambahkan oleh Cloud Service Mesh, pertimbangkan untuk mengonfigurasi Cloud Service Mesh tanpa opsi Prometheus, atau menonaktifkan fitur Penggabungan Metrik Istio.
    Penginstalan 1.11, 1.12, 1.13

    Penginstal Google Distributed Cloud dapat gagal jika peran kustom terikat pada tingkat izin yang salah.

    Jika pengikatan peran salah, pembuatan disk data vSphere dengan govc akan mengalami hang dan disk dibuat dengan ukuran sama dengan 0. Untuk memperbaiki masalah ini, Anda harus mengikat peran kustom di tingkat vCenter vSphere (root).


    Solusi:

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

    Untuk mengetahui informasi selengkapnya tentang pembuatan peran, lihat Hak istimewa akun pengguna vCenter.
    Logging dan pemantauan 1.11, 1.12, 1.13

    Jika metrik yang tidak digunakan lagi digunakan di dasbor bawaan, 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 berikut yang tidak digunakan lagi 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 "Status node on-prem GKE" di dasbor Google Cloud Monitoring. Instal ulang "Status node lokal GKE" dengan mengikuti petunjuk ini.
    2. Hapus "Penggunaan node on-prem GKE" di dasbor Google Cloud Monitoring. Instal ulang "Penggunaan node on-prem GKE" 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.
    Logging dan pemantauan 1.10, 1.11, 1.12, 1.13

    Untuk Google Distributed Cloud versi 1.10 dan yang lebih baru, data untuk cluster di Cloud Monitoring dapat berisi entri metrik ringkasan yang tidak relevan seperti berikut:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Jenis metrik lainnya yang mungkin memiliki metrik ringkasan yang tidak relevan meliputi

    :
    • 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 saat ini tidak didukung oleh gke-metrics-agent.
    Logging dan pemantauan 1.10, 1.11, 1.12, 1.13

    Anda mungkin mendapati bahwa metrik berikut tidak ada di beberapa, 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 diedit: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Untuk meningkatkan permintaan CPU untuk gke-metrics-agent dari 10m ke 50m, batas CPU dari 100m ke 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 memverifikasi bahwa perubahan Anda telah diterapkan, jalankan perintah berikut: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
       Perintah ini akan menemukan cpu: 50m jika hasil edit Anda telah diterapkan.
    Logging dan pemantauan 1.11.0-1.11.2, 1.12.0

    Jika cluster admin Anda terpengaruh oleh masalah ini, metrik penjadwal dan pengendali-pengelola tidak ada. 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

    Jika cluster pengguna Anda terpengaruh oleh masalah ini, metrik penjadwal dan pengendali-pengelola tidak ada. Misalnya, dua metrik ini tidak ada:

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

    Solusi:

    Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.13.0 dan yang lebih baru. Upgrade cluster Anda ke versi yang memiliki perbaikan.
    Penginstalan, Upgrade, Update 1.10, 1.11, 1.12, 1.13

    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 masih dapat menggunakan cluster admin ini, tetapi Anda akan mendapatkan error berikut jika nanti 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:

    Jika error ini terjadi, ikuti langkah-langkah berikut untuk memperbaiki masalah pendaftaran cluster. Setelah melakukan perbaikan ini, Anda dapat mengupgrade cluster admin.

    1. Jalankan gkectl update admin untuk mendaftarkan cluster admin dengan kunci akun layanan yang benar.
    2. Buat akun layanan khusus untuk menerapkan patch pada resource kustom OnPremAdminCluster. 
      export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: modify-admin
  namespace: kube-system
EOF

# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: modify-admin-role
rules:
- apiGroups:
  - "onprem.cluster.gke.io"
  resources:
  - "onpremadminclusters/status"
  verbs:
  - "patch"
EOF

# Create ClusterRoleBinding for binding the permissions to the modify-admin SA

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: modify-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: modify-admin-role
subjects:
- kind: ServiceAccount
  name: modify-admin
  namespace: kube-system
EOF
       Ganti ADMIN_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster admin Anda.
    3. Jalankan perintah ini untuk memperbarui resource kustom OnPremAdminCluster. 
      export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

SERVICE_ACCOUNT=modify-admin

SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
    -n kube-system -o json \
    | jq -Mr '.secrets[].name | select(contains("token"))')

TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data.token' | base64 -d)

kubectl get secret ${SECRET} -n kube-system -o json \
    | jq -Mr '.data["ca.crt"]' \
    | base64 -d > /tmp/ca.crt

APISERVER=https://$(kubectl -n default get endpoints kubernetes \
    --no-headers | awk '{ print $2 }')

# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
    --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
    -n kube-system $ADMIN_CLUSTER_NAME \
    -o=jsonpath='{.spec.gkeOnPremVersion}')

# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
    --header "Authorization: Bearer $TOKEN" -XPATCH \
    -H "Content-Type: application/merge-patch+json" \
    --cacert /tmp/ca.crt \
    --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
    $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
    4. Coba upgrade cluster admin lagi dengan flag --disable-upgrade-from-checkpoint. 
      gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-upgrade-from-checkpoint
       Ganti ADMIN_CLUSTER_CONFIG dengan jalur file konfigurasi cluster admin Anda.
    Identitas 1.10, 1.11, 1.12, 1.13

    Jika Anda menggunakan fitur Identity Service GKE untuk mengelola ClientConfig Identity Service GKE, Agen Connect mungkin akan dimulai ulang secara tiba-tiba.


    Solusi:

    Jika mengalami masalah ini dengan cluster yang ada, Anda dapat melakukan salah satu hal berikut:

    • Nonaktifkan GKE Identity Service. Jika Anda menonaktifkan Identity Service GKE, tindakan ini tidak akan menghapus biner Identity Service GKE yang di-deploy atau menghapus ClientConfig Identity Service GKE. Untuk menonaktifkan Identity Service GKE, 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 Agen Connect.
    Jaringan 1.10, 1.11, 1.12, 1.13

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


    Solusi:

    Solusi yang mungkin 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 untuk menonaktifkan pembelajaran IP akan menyebabkan endpoint IP berpindah-pindah antara lokasi yang berbeda di fabric Cisco API.
    VMware 1.10, 1.11, 1.12, 1.13

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

    • vSphere ESXi 7.0 Update 3 (build 18644231)
    • vSphere ESXi 7.0 Update 3a (build 18825058)
    • vSphere ESXi 7.0 Update 3b (build 18905247)
    • vSphere vCenter 7.0 Update 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

    Untuk Pod yang berjalan di node yang menggunakan image Container-Optimized OS (COS), Anda tidak dapat memasang volume emptyDir sebagai exec. File ini akan di-mount 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

    Dan di 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:

    Terapkan resource DaemonSet, misalnya:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fix-cos-noexec
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fix-cos-noexec
  template:
    metadata:
      labels:
        app: fix-cos-noexec
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: fix-cos-noexec
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          set -ex
          while true; do
            if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
              echo "remounting /var/lib/kubelet with exec"
              nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
              nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
            fi
            sleep 3600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
    Upgrade, Update 1.10, 1.11, 1.12, 1.13

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


    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 node pool yang sesuai.
    Logging dan pemantauan 1.11, 1.12, 1.13

    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 metrik Pod dan node Windows juga ditampilkan di cluster Linux.
    Logging dan pemantauan 1.10, 1.11, 1.12

    Untuk Google Distributed Cloud versi 1.10, 1.11, dan 1.12, stackdriver-log-forwarder DaemonSet mungkin mengalami error CrashLoopBackOff saat ada log buffering yang rusak di disk.


    Solusi:

    Untuk memitigasi masalah ini, kita perlu membersihkan log yang dibuffer di node.

    1. Untuk mencegah perilaku yang tidak terduga, skalakan 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. Deploy 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 DaemonSet pembersihan: 
      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

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

    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
    Kemungkinan kecepatan input log melebihi batas agen logging, yang menyebabkan stackdriver-log-forwarder tidak mengirim log. Masalah ini terjadi di semua versi Google Distributed Cloud.

    Solusi:

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

    1. Buka resource stackdriver untuk diedit: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Untuk 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 memverifikasi bahwa perubahan Anda telah diterapkan, jalankan perintah berikut: 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
       Perintah ini akan menemukan cpu: 1200m jika hasil edit Anda telah diterapkan.
    Keamanan 1.13

    ada periode singkat saat 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 baru untuk melihat IP node yang valid dan diperbarui.

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

    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 diupgrade sepenuhnya, 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 1.11 terlebih dahulu, lalu upgrade cluster pengguna ke 1.12.
    Penyimpanan 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    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 node pool 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

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

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


    Solusi:

    Anda dapat menghapus paksa cluster pengguna.
    Penginstalan, Sistem operasi 1.10, 1.11, 1.12, 1.13

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

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

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


    Solusi:

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

    Masalah ini memengaruhi pelanggan yang menggunakan Grafana di cluster admin untuk memantau cluster pengguna di Google Distributed Cloud versi 1.12.0 dan 1.12.1. Hal ini berasal dari ketidakcocokan sertifikat pushprox-client di cluster pengguna dan daftar yang diizinkan di pushprox-server di cluster admin. Gejalanya adalah pushprox-client di cluster pengguna 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:

    lakukan langkah-langkah berikut:

    1. Menskalakan deployment operator pemantauan di namespace kube-system cluster admin. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy monitoring-operator \
    --replicas=0
    2. Edit ConfigMap pushprox-server-rbac-proxy-config di namespace kube-system cluster admin. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system edit cm pushprox-server-rbac-proxy-config
       Temukan baris principals untuk pemroses external-pushprox-server-auth-proxy dan perbaiki principal_name untuk semua cluster pengguna dengan menghapus substring kube-system dari pushprox-client.metrics-consumers.kube-system.cluster. Konfigurasi baru akan terlihat seperti berikut: 
      permissions:
- or_rules:
    rules:
    - header: { name: ":path", exact_match: "/poll" }
    - header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
    3. Mulai ulang deployment pushprox-server di cluster admin dan deployment pushprox-client di cluster pengguna yang terpengaruh: 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
    4. Langkah-langkah sebelumnya akan menyelesaikan masalah. Setelah cluster diupgrade ke 1.12.2 dan yang lebih baru tempat masalah diperbaiki, skalakan operator pemantauan kube-system cluster admin sehingga dapat mengelola pipeline lagi. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
    Logging dan pemantauan 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

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

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

    Solusi:

    Untuk mengatasi masalah ini, izin dapat disiapkan dengan berinteraksi dengan fitur Hub cloudauditlogging:

    1. Pertama, periksa akun layanan yang ada yang diizinkan untuk Cloud Audit Logs di project Anda: 
      curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
    2. Bergantung pada responsnya, lakukan salah satu hal berikut:
      • Jika Anda menerima error 404 Not_found, artinya tidak ada akun layanan yang diizinkan untuk ID project ini. Anda dapat mengizinkan akun layanan dengan mengaktifkan fitur Hub cloudauditlogging: 
        curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
      • Jika Anda menerima spesifikasi fitur yang berisi "lifecycleState": "ENABLED" dengan "code": "OK" dan daftar akun layanan di allowlistedServiceAccounts, artinya ada akun layanan yang sudah ada dan diizinkan untuk project ini. Anda dapat menggunakan akun layanan dari daftar ini di cluster, atau menambahkan akun layanan baru ke daftar yang diizinkan: 
        curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
    '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
      • Jika Anda menerima spesifikasi fitur yang berisi "lifecycleState": "ENABLED" dengan "code": "FAILED", artinya penyiapan izin tidak berhasil. Coba atasi masalah di kolom description respons, atau cadangkan daftar yang diizinkan saat ini, hapus fitur hub cloudauditlogging, dan aktifkan kembali dengan mengikuti langkah 1 bagian ini lagi. Anda dapat menghapus fitur Hub cloudauditlogging dengan: 
        curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

    Dalam perintah di atas:
    Sistem operasi 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    /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 Google Distributed Cloud v1.8, image Ubuntu di-harden dengan CIS Level 2 Benchmark. Dan salah satu aturan kepatuhan, "4.1.2.2 Memastikan log audit tidak otomatis dihapus", memastikan setelan auditd max_log_file_action = keep_logs. Hal ini menyebabkan semua aturan audit disimpan di disk.


    Solusi:

    Workstation admin

    Untuk workstation admin, Anda dapat mengubah setelan auditd secara manual untuk memutar log secara otomatis, lalu memulai ulang layanan auditd:

    sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

    Setelan di atas akan membuat auditd secara otomatis merotasi lognya setelah menghasilkan lebih dari 250 file (masing-masing dengan ukuran 8 M).

    Node cluster

    Untuk node cluster, upgrade ke 1.11.5+, 1.12.4+, 1.13.2+, atau 1.14+. Jika Anda belum dapat mengupgrade ke versi tersebut, terapkan DaemonSet berikut ke cluster Anda:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

    Perhatikan bahwa membuat perubahan konfigurasi auditd ini akan melanggar aturan CIS Level 2 "4.1.2.2 Pastikan log audit tidak otomatis dihapus".
    Jaringan 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    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 salah mengikat ke alamat IP mengambang yang ditetapkan ke node dan melaporkannya sebagai alamat node di node.status.addresses. Webhook validasi memeriksa alamat IP mengambang NetworkGatewayGroup terhadap semua node.status.addresses di cluster dan menganggapnya sebagai konflik.


    Solusi:

    Di cluster yang sama tempat pembuatan atau pembaruan objek NetworkGatewayGroup gagal, nonaktifkan sementara webhook validasi ANG dan kirimkan perubahan Anda:

    1. Simpan konfigurasi webhook agar dapat dipulihkan pada akhirnya: 
      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.
    5. Terapkan kembali konfigurasi webhook asli: 
      kubectl -n kube-system apply -f webhook-config.yaml
    Jaringan semua versi sebelum 1.14.7, 1.15.0-1.15.3, 1.16.0

    GARP (ARP Serampangan) berkala yang dikirim oleh Seesaw setiap 20 detik tidak menetapkan IP target di header ARP. Beberapa jaringan mungkin tidak menerima paket tersebut (seperti Cisco ACI). Hal ini dapat menyebabkan waktu nonaktif layanan yang lebih lama setelah split brain (karena paket VRRP hilang) dipulihkan.

    Solusi:

    Picu failover Seesaw 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

    "staticPodPath" salah ditetapkan untuk node pekerja

    Solusi:

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