Masalah umum Google Distributed Cloud (khusus software) untuk VMware

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

Untuk memfilter masalah yang diketahui menurut versi atau kategori produk, pilih filter yang diinginkan dari menu {i>drop-down<i} berikut ini.

Pilih versi Google Distributed Cloud Anda: 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 Lainnya

Atau, telusuri masalah Anda:

Kategori	Versi yang diidentifikasi	Masalah dan solusi
Upgrade	1,16, 1,28, 1,29, 1,30	credential.yaml dibuat ulang dengan tidak benar selama admin upgrade workstation Saat mengupgrade workstation admin menggunakan perintah gkeadm upgrade admin-workstation, file credential.yaml tidak dibuat ulang dengan benar. Kolom nama pengguna dan sandi kosong. Selain itu, kunci privateRegistry memiliki kesalahan ketik. Kesalahan ejaan tombol privateRegistry yang sama juga ditemukan file admin-cluster.yaml. Sejak File credential.yaml dibuat ulang selama cluster admin proses peningkatan versi, ada kesalahan ketik meskipun Anda sudah mengoreksi sebelumnya. Solusi: Perbarui nama kunci registry pribadi di credential.yaml menjadi cocokkan privateRegistry.credentials.fileRef.entry pada admin-cluster.yaml. Perbarui nama pengguna dan sandi registry pribadi di credential.yaml.
Upgrade	1,16, 1,28	Upgrade cluster pengguna gagal karena waktu tunggu rekonsiliasi pra-upgrade terjadi Saat mengupgrade cluster pengguna, operasi rekonsiliasi pra-upgrade mungkin memakan waktu lebih lama dari waktu tunggu yang ditentukan, sehingga mengakibatkan kegagalan upgrade. Pesan error akan 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 plus 1 menit per kumpulan node di cluster pengguna. Solusi: Pastikan bahwa gkectl diagnose cluster tanpa terjadi error. Lewati operasi rekonsiliasi pra-upgrade dengan menambahkan tanda --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	Mengupdate DataplaneV2 ForwardMode tidak secara otomatis memicu mulai ulang DaemonSet anetd Saat Anda memperbarui cluster pengguna dataplaneV2.forwardMode menggunakan gkectl update cluster, perubahan tersebut hanya diupdate di ConfigMap, DaemonSet anetd tidak akan mengambil perubahan konfigurasi hingga dimulai ulang dan perubahan Anda tidak diterapkan. Solusi: Setelah perintah gkectl update cluster selesai, Anda akan melihat output dari Done updating the user cluster. Setelah Anda melihat bahwa pesan ini, jalankan perintah berikut untuk memulai ulang anetd DaemonSet untuk mengambil perubahan konfigurasi: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd Periksa kesiapan DaemonSet setelah mulai 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	Perintah etcdctl tidak ditemukan selama upgrade cluster pada tahap pencadangan cluster admin Selama upgrade cluster pengguna 1.16 ke 1.28, cluster admin didukung ke atas. Proses pencadangan cluster admin menampilkan pesan error "etcdctl: perintah tidak ditemukan". Upgrade cluster pengguna berhasil, dan cluster admin tetap dalam status responsif. Satu-satunya masalah adalah file metadata di cluster admin tidak dicadangkan. Penyebab masalah ini adalah biner etcdctl ditambahkan di 1.28, dan tidak tersedia pada 1.16 node. Pencadangan cluster admin melibatkan beberapa langkah, termasuk mengambil dll. lalu menulis file metadata untuk cluster admin. Pencadangan dll. masih berhasil karena etcdctl masih dapat dipicu setelah {i>exec<i} masuk ke dalam Pod {i>etcd<i}. Tetapi menulis file metadata gagal karena masih mengandalkan biner etcdctl untuk yang diinstal pada node. Namun, pencadangan file metadata bukanlah pemblokir untuk membuat cadangan, sehingga proses pencadangan masih berhasil, seperti halnya upgrade cluster pengguna. Solusi: Jika Anda ingin mengambil cadangan file {i>metadata<i}, ikuti Kembali dan memulihkan cluster admin dengan gkectl untuk memicu pencadangan cluster admin menggunakan versi gkectl yang cocok versi cluster admin Anda.
Penginstalan	1,16-1,29	Kegagalan pembuatan cluster pengguna dengan load balancing manual Saat membuat cluster pengguna yang dikonfigurasi untuk load balancing manual, Kegagalan gkectl check-config terjadi yang menunjukkan bahwa Nilai ingressHTTPNodePort minimal harus 30000, meskipun traffic masuk yang dipaketkan dinonaktifkan. Masalah ini terjadi terlepas dari apakah ingressHTTPNodePort dan ingressHTTPSNodePort kolom ditetapkan atau dibiarkan kosong. Solusi: Untuk mengatasi masalah ini, abaikan hasil yang dikembalikan oleh gkectl check-config. Untuk menonaktifkan paket masuk, lihat Nonaktifkan traffic masuk yang dipaketkan.
Update	1.29.0	Setelah memigrasikan cluster pengguna ke Controlplane V2, cluster admin PDB server metrik mungkin menjadi tidak dikonfigurasi dengan benar Masalah dengan PodDisruptionBudget (PDB) terjadi saat menggunakan cluster admin ketersediaan tinggi (HA), dan terdapat 0 atau 1 admin node cluster tanpa peran setelah migrasi. Untuk memeriksa apakah ada node objek tanpa peran, jalankan perintah berikut: kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide Jika ada dua objek node atau lebih tanpa peran setelah migrasi, maka PDB tidak salah dikonfigurasi. Gejala: Output dari diagnostik cluster admin mencakup informasi berikut Checking all poddisruptionbudgets...FAILURE Reason: 1 pod disruption budget error(s). Unhealthy Resources: PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1). Solusi: Jalankan perintah berikut untuk menghapus PDB: kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
Penginstalan, Upgrade, dan update	1.28.0-1.28.600,1.29.0-1.29.100	Webook Otorisasi Biner memblokir plugin CNI agar mulai menyebabkan salah satu nodepool gagal muncul Dalam kondisi race yang jarang terjadi, urutan penginstalan webhook Otorisasi Biner dan pod gke-connect yang salah dapat menyebabkan pembuatan cluster pengguna terhenti karena node gagal mencapai status siap. Dalam skenario yang terpengaruh, pembuatan cluster pengguna dapat terhenti karena node gagal mencapai status siap. Jika ini terjadi, pesan berikut akan ditampilkan: Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready Solusi: Hapus konfigurasi Otorisasi Biner dari file konfigurasi Anda. Untuk petunjuk penyiapan, lihat panduan penginstalan Otorisasi Biner hari ke-2 untuk GKE di VMware. Untuk berhenti memblokir node yang tidak responsif selama proses pembuatan cluster saat ini, hapus konfigurasi webhook Otorisasi Biner di cluster pengguna untuk sementara menggunakan perintah berikut. kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration Setelah proses bootstrap selesai, Anda dapat menambahkan kembali konfigurasi webhook berikut. apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingWebhookConfiguration metadata: name: binauthz-validating-webhook-configuration webhooks: - name: "binaryauthorization.googleapis.com" namespaceSelector: matchExpressions: - key: control-plane operator: DoesNotExist objectSelector: matchExpressions: - key: "image-policy.k8s.io/break-glass" operator: NotIn values: ["true"] rules: - apiGroups: - "" apiVersions: - v1 operations: - CREATE - UPDATE resources: - pods - pods/ephemeralcontainers admissionReviewVersions: - "v1beta1" clientConfig: service: name: binauthz namespace: binauthz-system path: /binauthz # CA Bundle will be updated by the cert rotator. caBundle: Cg== timeoutSeconds: 10 # Fail Open failurePolicy: "Ignore" sideEffects: None
Upgrade	1,16, 1,28, 1,29	Upgrade cluster pengguna CPV2 terhenti karena mesin yang dicerminkan dengan deletionTimestamp Selama upgrade cluster pengguna, operasi upgrade mungkin macet jika objek mesin yang dicerminkan di cluster pengguna berisi deletionTimestamp. Pesan error berikut ditampilkan jika upgrade terhenti: machine is still in the process of being drained and subsequently removed Masalah ini dapat terjadi jika sebelumnya Anda mencoba memperbaiki pengguna node bidang kontrol dengan menjalankan gkectl delete machine terhadap komputer yang dicerminkan di cluster pengguna. Solusi: Mendapatkan objek mesin yang dicerminkan dan menyimpannya ke file lokal untuk dicadangkan tujuan. Jalankan perintah berikut untuk menghapus finaler dari jendela yang dicerminkan komputer dan menunggu 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 Ikuti langkah-langkah di Node bidang kontrol cluster pengguna Controlplane V2 untuk memicu perbaikan node pada simpul bidang kontrol, sehingga spesifikasi komputer sumber yang benar akan disinkronkan ulang ke dalam cluster pengguna. Jalankan kembali gkectl upgrade cluster untuk melanjutkan upgrade
Konfigurasi, Penginstalan	1,15, 1,16, 1,28, 1,29	Kegagalan pembuatan cluster karena VIP bidang kontrol di subnet yang berbeda Untuk cluster admin HA atau cluster pengguna ControlPlane V2, bidang kontrol VIP harus berada di subnet yang sama dengan node cluster lainnya. Jika tidak, kelompokkan pembuatan 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.
Penginstalan, Upgrade, Update	1.29.0 - 1.29.100	Kegagalan Pembuatan/Upgrade Cluster karena Nama Pengguna vCenter non-FQDN Pembuatan/upgrade cluster gagal disertai error dalam pod CSI vsphere yang menunjukkan bahwa nama pengguna vCenter tidak valid. Hal ini terjadi karena nama pengguna yang digunakan bukan nama domain yang sepenuhnya memenuhi syarat. Pesan error pada pod vsphere-csi-controller seperti di bawah ini: GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username Masalah ini hanya terjadi di versi 1.29 dan yang lebih baru, karena validasi ditambahkan ke driver CSI vSphere untuk menerapkan penggunaan nama pengguna domain yang sepenuhnya memenuhi syarat. Solusi: Gunakan nama domain yang sepenuhnya memenuhi syarat untuk nama pengguna vCenter di file konfigurasi kredensial. Misalnya, gunakan "[e-mail]", bukan "namapengguna1".
Upgrade, Update	1.28.0 - 1.28.500	Upgrade cluster admin gagal untuk cluster yang dibuat di versi 1.10 atau lebih cepat Saat mengupgrade cluster admin dari 1.16 ke 1.28, bootstrap komputer master admin baru mungkin gagal membuat bidang kontrol CA {i>root<i}. Masalah ini disebabkan oleh perubahan pada cara sertifikat yang dibuat untuk server Kubernetes API versi 1.28 dan yang lebih baru. Tujuan direproduksi kembali untuk cluster yang dibuat pada versi 1.10 dan sebelumnya, telah ditingkatkan hingga 1.16 dan sertifikat {i>leaf<i} tidak dirotasi sebelum upgrade. Untuk menentukan apakah kegagalan upgrade cluster admin disebabkan oleh lakukan langkah-langkah berikut: Hubungkan ke mesin master admin yang gagal menggunakan SSH. Buka /var/log/startup.log dan telusuri error seperti berikut ini: Error adding extensions from section apiserver_ext 801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177: 801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid> Solusi: Hubungkan ke mesin master admin menggunakan SSH. Untuk mengetahui detailnya, lihat Menggunakan SSH untuk terhubung ke node cluster admin. Edit /etc/startup/pki-yaml.sh. Find (Menemukan) authorityKeyIdentifier=keyidset dan ubah menjadi authorityKeyIdentifier=keyid,issuer di bagian untuk ekstensi berikut: apiserver_ext, client_ext, etcd_server_ext, dan kubelet_server_ext. Sebagai contoh: [ apiserver_ext ] keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage=serverAuth basicConstraints = critical,CA:false authorityKeyIdentifier = keyid,issuer subjectAltName = @apiserver_alt_names Simpan perubahan ke /etc/startup/pki-yaml.sh. Jalankan /opt/bin/master.sh untuk membuat sertifikat dan menyelesaikan {i>startup<i} mesin. Jalankan gkectl upgrade admin lagi untuk mengupgrade admin . Setelah upgrade selesai, rotasikan leaf certificate untuk kedua admin serta cluster pengguna, seperti yang dijelaskan dalam Memulai rotasi. Setelah rotasi sertifikat selesai, lakukan pengeditan yang sama pada /etc/startup/pki-yaml.sh seperti yang Anda lakukan sebelumnya, dan jalankan /opt/bin/master.sh.
Konfigurasi	1.29.0	Pesan peringatan yang salah untuk cluster dengan Dataplane V2 diaktifkan Pesan peringatan yang salah berikut ditampilkan saat Anda menjalankan gkectl untuk membuat, mengupdate, atau mengupgrade cluster yang sudah memiliki Dataplane V2 diaktifkan: WARNING: Your user cluster is currently running our original architecture with [DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend to update it to the newer architecture with [DataPlaneV2] once our migration tool is available. Ada {i>bug<i} di {i>gkectl<i} yang menyebabkannya selalu menampilkan peringatan ini sebagai selama dataplaneV2.forwardMode tidak digunakan, meskipun Anda telah menetapkan enableDataplaneV2: true dalam cluster Anda file konfigurasi Anda. Solusi: Anda dapat mengabaikan peringatan ini dengan aman.
Konfigurasi	1.28.0-1.28.400, 1.29.0	Laporan pemeriksaan preflight penginstalan cluster admin HA salah jumlah IP statis yang diperlukan Saat Anda membuat cluster admin HA, pemeriksaan preflight akan menampilkan pesan error yang salah berikut ini: - Validation Category: Network Configuration - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed at least X+1 IP addresses for admin cluster with X nodes Persyaratan untuk cluster admin dengan ketersediaan tinggi (HA) 1,28 dan yang lebih tinggi tidak benar karena tidak lagi memiliki node add-on. Selain itu, karena 3 IP node bidang kontrol cluster admin ditentukan dalam Bagian network.controlPlaneIPBlock di cluster admin file konfigurasi, IP dalam file blok IP hanya diperlukan untuk {i>node<i} bidang kontrol cluster pengguna kubeception. Solusi: Untuk melewati pemeriksaan preflight yang salah dalam rilis yang tidak tetap, tambahkan --skip-validation-net-config ke gkectl perintah.
Operasi	1.29.0-1.29.100	Menghubungkan Agen kehilangan koneksi ke Google Cloud setelah non-HA ke HA migrasi cluster admin Jika Anda memigrasikan dari cluster admin non-HA ke cluster admin HA, Connect Agent di cluster admin kehilangan koneksi ke gkeconnect.googleapis.com dengan pesan error "Gagal memverifikasi JWT tanda tangan". Hal ini karena selama migrasi, kunci penandatanganan KSA diubah, sehingga pendaftaran ulang diperlukan untuk memperbarui JWK OIDC. Solusi: Untuk menghubungkan kembali cluster admin ke Google Cloud, lakukan langkah-langkah berikut untuk memicu pendaftaran ulang: Pertama-tama, dapatkan nama deployment gke-connect: kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect Hapus deployment gke-connect: kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect Picu rekonsiliasi paksa untuk onprem-admin-cluster-controller dengan menambahkan opsi "rekonsiliasi paksa" anotasi ke CR onpremadmincluster Anda: kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p ' metadata: annotations: onprem.cluster.gke.io/force-reconcile: "true" ' Idenya adalah onprem-admin-cluster-controller akan selalu men-deploy ulang deployment gke-connect dan mendaftar ulang cluster tersebut jika tidak menemukan deployment gke-connect yang ada yang tersedia. Setelah solusinya (mungkin perlu beberapa menit bagi pengontrol untuk menyelesaikan rekonsiliasi), Anda dapat memverifikasi bahwa pesan "Gagal verifikasi tanda tangan JWT Error 400 hilang dari log gke-connect-agent: kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
Penginstalan, Sistem operasi	1.28.0-1.28.500, 1.29.0	IP jembatan Docker menggunakan 172.17.0.1/16 untuk node bidang kontrol cluster COS Google Distributed Cloud menentukan subnet khusus, --bip=169.254.123.1/24, untuk IP jembatan Docker di Konfigurasi Docker untuk mencegah pemesanan Subnet 172.17.0.1/16. Namun, dalam versi 1.28.0-1.28.500 dan 1.29.0, layanan Docker tidak dimulai ulang setelah Google Distributed Cloud menyesuaikan konfigurasi Docker karena adanya regresi dalam gambar. Hasilnya, Docker memilih 172.17.0.1/16 default sebagai subnet alamat IP jembatannya. Hal ini dapat menyebabkan konflik alamat IP jika Anda sudah memiliki beban kerja yang berjalan dalam rentang alamat IP tersebut. Solusi: Untuk mengatasi masalah ini, Anda harus memulai ulang layanan Docker: sudo systemctl restart docker Verifikasi bahwa Docker memilih alamat IP jembatan yang benar: ip a | grep docker0 Solusi ini tidak dapat dipertahankan di seluruh pembuatan ulang VM. Anda harus mengajukan permohonan kembali solusi ini setiap kali VM dibuat ulang.
update	1.28.0-1.28.400, 1.29.0-1.29.100	Penggunaan beberapa antarmuka jaringan dengan CNI standar tidak berfungsi Biner CNI standar bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap tidak disertakan dalam OS image di versi. Biner CNI ini tidak digunakan oleh bidang data v2, tetapi dapat digunakan untuk antarmuka jaringan tambahan dalam fitur beberapa antarmuka jaringan. Beberapa antarmuka jaringan dengan plugin CNI ini tidak akan berfungsi. Solusi: Upgrade ke versi dengan perbaikan jika Anda menggunakan fitur ini.
update	1,15, 1,16, 1,28	Dependensi trident Netapp mengganggu driver CSI vSphere Menginstal multipathd pada node cluster mengganggu driver CSI vSphere sehingga beban kerja pengguna tidak dapat dimulai. Solusi: Nonaktifkan multipathd
Update	1,15, 1,16	Webhook cluster admin mungkin memblokir pembaruan saat Anda menambahkan konfigurasi yang diperlukan Jika beberapa konfigurasi yang diperlukan kosong di cluster admin karena validasi dilewati, penambahannya dapat diblokir oleh admin webhook cluster. Misalnya, jika kolom gkeConnect tidak tetapkan di cluster admin yang ada, dengan menambahkannya dengan Perintah gkectl update admin mungkin mendapatkan error berikut pesan: admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters Solusi: Untuk 1.15 cluster admin, 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 1.16 cluster admin, 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	Setelan default kolom controlPlaneNodePort adalah 30968 jika Spesifikasi manualLB kosong Jika Anda akan menggunakan load balancer manual (loadBalancer.kind ditetapkan ke "ManualLB"), Anda tidak perlu mengonfigurasi loadBalancer.manualLB di file konfigurasi untuk admin ketersediaan tinggi (HA) cluster di versi 1.16 dan yang lebih baru. Tapi jika bagian ini kosong, Google Distributed Cloud menetapkan nilai default ke semua NodePorts termasuk manualLB.controlPlaneNodePort, yang menyebabkan cluster pembuatan gagal dengan pesan error berikut: - Validation Category: Manual LB - [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must not be set when using HA admin cluster, got: 30968 Solusi: Tentukan manualLB.controlPlaneNodePort: 0 di konfigurasi cluster admin Anda untuk cluster admin HA: loadBalancer: ... kind: ManualLB manualLB: controlPlaneNodePort: 0 ...
Penyimpanan	1.28.0-1.28.100	nfs-common tidak ada di image OS Ubuntu nfs-common tidak ada di OS image Ubuntu yang dapat menyebabkan masalah untuk pelanggan yang menggunakan {i>driver<i} yang bergantung pada NFS seperti NetApp. Jika log berisi entri seperti berikut setelah mengupgrade ke 1.28, Anda akan terpengaruh oleh masalah ini: Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32". Solusi: Pastikan node Anda dapat mendownload paket dari Kanonis. Selanjutnya, terapkan DaemonSet berikut ke cluster Anda untuk menginstal nfs-common: apiVersion: apps/v1 kind: DaemonSet metadata: name: install-nfs-common labels: name: install-nfs-common namespace: kube-system spec: selector: matchLabels: name: install-nfs-common minReadySeconds: 0 updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 100% template: metadata: labels: name: install-nfs-common spec: hostPID: true hostIPC: true hostNetwork: true initContainers: - name: install-nfs-common image: ubuntu imagePullPolicy: IfNotPresent securityContext: privileged: true command: - chroot - /host - bash - -c args: - | apt install -y nfs-common volumeMounts: - name: host mountPath: /host containers: - name: pause image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5 imagePullPolicy: IfNotPresent volumes: - name: host hostPath: path: /
Penyimpanan	1.28.0-1.28.100	Kolom kebijakan penyimpanan tidak ada di template konfigurasi cluster admin SPBM di cluster admin didukung pada versi 1.28.0 dan yang lebih baru. Tapi bidang vCenter.storagePolicyName tidak ada di template file konfigurasi. Solusi: Tambahkan kolom `vCenter.storagePolicyName` di file konfigurasi cluster admin jika Anda ingin mengonfigurasi kebijakan penyimpanan untuk cluster admin. Lihat petunjuknya.
Logging dan pemantauan	1.28.0-1.28.100	Kubernetes Metadata API tidak mendukung VPC-SC API kubernetesmetadata.googleapis.com yang baru-baru ini ditambahkan tidak mendukung VPC-SC. Hal ini akan menyebabkan agen pengumpul metadata gagal menjangkau API ini berdasarkan VPC-SC. Selanjutnya, label metadata metrik akan hilang. Solusi: Di namespace `kube-system`, tetapkan kolom `featureGates.disableExperimentalMetadataAgent` di namespace CR `stackdriver` ke `true` dengan menjalankan perintah `kubectl -n kube-system patch stackdriver stackdriver -p &#39;{&quot;spec&quot;:{&quot;featureGates&quot;:{&quot;disableExperimentalMetadataAgent&quot;:true}}}&#39;` lalu jalankan `kubectl -n kube-system patch deployment stackdriver-operator -p &#39;{&quot;spec&quot;:{&quot;template&quot;:{&quot;spec&quot;:{&quot;containers&quot;:[{&quot;name&quot;:&quot;stackdriver-operator&quot;,&quot;env&quot;:[{&quot;name&quot;:&quot;ENABLE_LEGACY_METADATA_AGENT&quot;,&quot;value&quot;:&quot;true&quot;}]}]}}}}&#39;`
Upgrade, Update	1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0	Pengontrol clusterapi dapat mengalami error jika cluster admin dan cluster pengguna apa pun yang mengaktifkan ControlPlane V2 menggunakan kredensial vSphere yang berbeda Saat cluster admin dan cluster pengguna mana pun yang mengaktifkan ControlPlane V2, akan menggunakan kredensial vSphere yang berbeda, misalnya, setelah memperbarui kredensial vSphere untuk admin, clusterapi-controller mungkin gagal terhubung ke vCenter setelah dimulai ulang. Lihat log pengontrol clusterapi yang berjalan di konfigurasi cluster admin namespace `kube-system`, kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \ -n kube-system --kubeconfig KUBECONFIG Jika log berisi entri seperti berikut, berarti Anda terpengaruh oleh masalah ini: E1214 00:02:54.095668 1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found Solusi: Perbarui kredensial vSphere sehingga cluster admin dan semua cluster pengguna yang mengaktifkan Controlplane V2 menggunakan kredensial vSphere yang sama.
Logging dan pemantauan	1,14	dll. tingginya jumlah permintaan GRPC yang gagal di Prometheus Alert Manager Prometheus mungkin melaporkan peringatan yang mirip dengan contoh berikut: Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001. Untuk memeriksa apakah pemberitahuan ini positif palsu (PP) yang dapat diabaikan, selesaikan langkah-langkah berikut: Periksa metrik grpc_server_handled_total mentah terhadap grpc_method yang diberikan dalam pesan pemberitahuan. Di sini misalnya, periksa label grpc_code untuk Watch. Anda dapat memeriksa metrik ini menggunakan Cloud Monitoring dengan Kueri MQL: fetch k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m Notifikasi pada semua kode selain OK dapat dikirimkan dengan aman diabaikan jika kode tidak termasuk salah satu dari yang berikut ini: Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded Solusi: Untuk mengonfigurasi Prometheus agar mengabaikan pemberitahuan positif palsu ini, tinjau opsi berikut: Menyenyapkan notifikasi dari UI Pengelola Pemberitahuan. Jika tidak dapat menampilkan notifikasi, tinjau langkah-langkah berikut untuk menyembunyikan positif palsu: Menurunkan skala operator pemantauan menjadi 0 replika sehingga agar modifikasi dapat dipertahankan. Ubah konfigurasi peta prometheus-config, lalu tambahkan grpc_method!="Watch" ke etcdHighNumberOfFailedGRPCRequests konfigurasi pemberitahuan seperti yang ditampilkan 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. Mulai ulang Prometheus dan Alertmanager Statefulset untuk mengambil konfigurasi baru. Jika kode termasuk dalam salah satu kasus yang bermasalah, periksa {i>etcd<i} dan log kube-apiserver untuk men-debug lebih lanjut.
Jaringan	1.16.0-1.16.2, 1.28.0	Koneksi yang aktif dalam waktu lama NAT keluar akan terputus Koneksi NAT keluar mungkin terputus setelah 5 hingga 10 menit koneksi yang tersambung jika tidak ada lalu lintas data. Karena conntrack hanya penting untuk arah masuk (eksternal koneksi ke cluster), masalah ini hanya terjadi jika koneksi tidak mengirimkan informasi apa pun untuk sementara waktu, lalu sisi tujuan mentransmisikan sesuatu. Jika Pod keluar NAT selalu membuat instance maka masalah ini tidak akan terlihat. Masalah ini terjadi karena pembersihan sampah memori yang tidak sengaja menghapus entri {i>conntrack<i} yang dianggap {i>daemon <i}tidak digunakan. Perbaikan upstream diintegrasikan ke dalam anetd untuk memperbaiki perilaku tersebut. Solusi: Tidak ada solusi yang mudah, dan kami belum melihat masalah di versi 1.16 dari perilaku ini. Jika Anda melihat sambungan jangka panjang yang terputus karena masalah ini, solusinya adalah menggunakan beban kerja pada {i>node<i} yang sama dengan alamat IP keluar, atau untuk mengirim pesan secara konsisten di TCP koneksi jarak jauh.
Operasi	1,14, 1,15, 1,16	Penanda tangan CSR mengabaikan spec.expirationSeconds saat menandatangani sertifikat Jika Anda membuat Certificate SigningRequest (CSR) dengan expirationSeconds ditetapkan, expirationSeconds akan diabaikan. Solusi: Jika Anda terpengaruh oleh masalah ini, Anda dapat memperbarui cluster pengguna dengan menambahkan disableNodeIDVerificationCSRSigning: true pada pengguna file konfigurasi cluster dan jalankan gkectl update cluster untuk mengupdate cluster dengan konfigurasi ini.
Jaringan, Peningkatan Versi, Pembaruan	1.16.0-1.16.3	Validasi load balancer cluster pengguna gagal untuk disable_bundled_ingress Jika Anda mencoba nonaktifkan traffic masuk yang dipaketkan untuk cluster yang ada, perintah gkectl update cluster gagal dengan error mirip dengan contoh berikut: [FAILURE] Config: ingress IP is required in user cluster spec Error ini terjadi karena gkectl memeriksa beban alamat IP traffic masuk balancer selama pemeriksaan preflight. Meskipun pemeriksaan ini tidak diperlukan saat menonaktifkan traffic masuk yang dipaketkan, gkectl pemeriksaan preflight gagal saat disableBundledIngress disetel ke true. Solusi: Gunakan parameter --skip-validation-load-balancer saat Anda mengupdate cluster, seperti yang ditunjukkan pada contoh berikut: gkectl update cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \ --skip-validation-load-balancer Untuk informasi selengkapnya, lihat cara menonaktifkan traffic masuk yang dipaketkan untuk cluster yang ada.
Upgrade, Update	1.13, 1.14, 1.15.0-1.15.6	Update cluster admin gagal setelah rotasi CA Jika Anda mengganti sertifikat certificate authority (CA) cluster admin, upaya berikutnya untuk menjalankan perintah gkectl update admin 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 memperbarui 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 flag --disable-update-from-checkpoint, perintah {i>update<i} tidak menggunakan file checkpoint sebagai sumber kebenaran selama update cluster. File checkpoint masih diperbarui untuk digunakan di masa mendatang.
Penyimpanan	1.15.0-1.15.6, 1.16.0-1.16.2	Pemeriksaan preflight Workload CSI gagal karena kegagalan startup Pod Selama pemeriksaan preflight, pemeriksaan validasi Beban Kerja CSI menginstal Pod di namespace default. Pod Workload CSI memvalidasi bahwa {i>Driver<i} CSI vSphere sudah diinstal dan dapat melakukan pengaturan volume penyediaan resource. Jika Pod ini tidak dimulai, pemeriksaan validasi Workload CSI gagal. Ada beberapa masalah umum yang dapat mencegah Pod ini dimulai: Jika Pod belum menetapkan batas resource, yang akan terjadi beberapa cluster dengan webhook penerimaan terinstal, Pod tidak dapat dimulai. Jika Cloud Service Mesh diinstal di cluster dengan injeksi file bantuan Istio otomatis diaktifkan di default pada namespace, Pod Workload CSI tidak dapat dimulai. Jika Pod Workload CSI tidak dimulai, Anda akan melihat error waktu tunggu seperti berikut ini selama validasi preflight: - [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition Untuk melihat apakah kegagalan disebabkan oleh kurangnya resource Pod yang ditetapkan, jalankan perintah berikut untuk memeriksa anthos-csi-workload-writer-<run-id> status pekerjaan: kubectl describe job anthos-csi-workload-writer-<run-id> Jika batas resource tidak ditetapkan dengan benar untuk Pod Workload CSI, status pekerjaan berisi pesan {i>error<i} seperti berikut: CPU and memory resource limits is invalid, as it are not defined for container: volume-tester Jika Pod Workload CSI tidak dimulai karena injeksi file bantuan Istio, Anda dapat menonaktifkan injeksi file bantuan Istio otomatis untuk sementara di Namespace default. Periksa label namespace dan gunakan perintah berikut untuk menghapus label yang dimulai dengan istio.io/rev: kubectl label namespace default istio.io/rev- Jika Pod salah dikonfigurasi, verifikasi secara manual bahwa volume dinamis penyediaan dengan kerja Driver vSphere CSI: Buat PVC yang menggunakan StorageClass standard-rwo. Buat Pod yang menggunakan PVC. Pastikan bahwa Pod dapat membaca/menulis data ke volume. Hapus Pod dan PVC setelah Anda memverifikasi operasi yang benar. Jika penyediaan volume dinamis dengan Driver vSphere CSI berfungsi, jalankan gkectl diagnose atau gkectl upgrade dengan flag --skip-validation-csi-workload untuk melewati CSI Pemeriksaan beban kerja.
Operasi	1.16.0-1.16.2	Waktu tunggu update cluster pengguna habis saat versi cluster admin adalah 1.15 Saat Anda masuk ke komputer admin yang dikelola pengguna, gkectl update cluster mungkin habis waktu tunggunya dan gagal memperbarui cluster pengguna. Hal ini terjadi jika versi cluster admin adalah 1.15 dan Anda menjalankan gkectl update admin sebelum Anda menjalankan gkectl update cluster. Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba mengupdate cluster: Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition Selama update cluster admin 1.15, validation-controller yang memicu pemeriksaan preflight akan dihapus dari cluster. Jika Anda kemudian mencoba memperbarui cluster pengguna, pemeriksaan preflight akan berhenti waktu tunggu habis. Solusi: Jalankan perintah berikut untuk men-deploy ulang validation-controller: gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform Setelah persiapan selesai, jalankan gkectl update cluster lagi untuk memperbarui cluster pengguna
Operasi	1.16.0-1.16.2	Waktu tunggu pembuatan cluster pengguna habis saat versi cluster admin adalah 1.15 Saat Anda masuk ke komputer admin yang dikelola pengguna, gkectl create cluster mungkin habis waktu tunggunya dan gagal membuat cluster pengguna. Hal ini terjadi jika versi cluster admin adalah 1.15. Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba membuat cluster: Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition Karena validation-controller ditambahkan di 1.16, saat menggunakan 1.15 admin mengelompokkan validation-controller yang bertanggung jawab untuk memicu pemeriksaan preflight tidak ada. Oleh karena itu, saat mencoba membuat cluster pengguna, pemeriksaan preflight hang sampai waktu tunggu habis. Solusi: Jalankan perintah berikut untuk men-deploy validation-controller: gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform Setelah persiapan selesai, jalankan gkectl create cluster lagi untuk membuat cluster pengguna
Upgrade, Update	1.16.0-1.16.2	Pembaruan atau upgrade cluster admin gagal jika project atau lokasi layanan add-on tidak cocok satu sama lain Saat Anda mengupgrade cluster admin dari versi 1.15.x ke 1.16.x, atau menambahkan connect, stackdriver, Konfigurasi cloudAuditLogging, atau gkeOnPremAPI saat Anda mengupdate cluster admin, operasi mungkin ditolak oleh admin webhook cluster. 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 admin cluster yang sama. Saat status cluster admin dipulihkan di jenis cluster, webhook cluster admin tidak dapat membedakan apakah Objek OnPremAdminCluster ditujukan untuk pembuatan cluster admin, atau melanjutkan operasi pembaruan atau {i>upgrade<i}. Beberapa khusus buat validasi dipanggil saat mengupdate dan mengupgrade secara tiba-tiba. Solusi: Tambahkan onprem.cluster.gke.io/skip-project-location-sameness-validation: true ke objek OnPremAdminCluster: Edit resource cluster onpremadminclusters: kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG Ganti yang berikut: ADMIN_CLUSTER_NAME: nama cluster admin. ADMIN_CLUSTER_KUBECONFIG: jalur pada file kubeconfig cluster admin. Tambahkan onprem.cluster.gke.io/skip-project-location-sameness-validation: true dan menyimpan resource kustom. Bergantung pada jenis cluster admin, selesaikan salah satu langkah-langkah berikut: Untuk cluster admin non-HA yang memiliki file checkpoint: tambahkan parameter disable-update-from-checkpoint dalam perintah update, atau tambahkan parameter `disable-upgrade-from-checkpoint` dalam perintah upgrade. Ini parameter hanya diperlukan saat berikutnya Anda menjalankan Perintah update atau upgrade: gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --disable-update-from-checkpoint gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --disable-upgrade-from-checkpoint Untuk cluster admin dengan ketersediaan tinggi (HA) atau file checkpoint dinonaktifkan: mengupdate atau mengupgrade cluster admin seperti biasa. Tidak ada parameter tambahan diperlukan pada perintah pembaruan atau {i>upgrade<i}.
Operasi	1.16.0-1.16.2	Gagal menghapus cluster pengguna saat menggunakan workstation admin yang dikelola pengguna Saat Anda masuk ke komputer admin yang dikelola pengguna, gkectl delete cluster mungkin habis waktu tunggunya dan gagal menghapus cluster pengguna. Hal ini terjadi jika Anda pertama kali menjalankan gkectl di workstation yang dikelola pengguna untuk membuat, memperbarui, atau mengupgrade cluster pengguna. Ketika 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. Tujuan penghapusan objek Validasi (yang dibuat saat pembuatan, {i>update<i}, atau upgrade) terhenti di fase penghapusan. Hal ini sering terjadi karena finaler memblokir penghapusan objek, yang menyebabkan penghapusan cluster gagal. Solusi: Dapatkan nama semua objek Validasi: kubectl --kubeconfig ADMIN_KUBECONFIG get validations \ -n USER_CLUSTER_NAME-gke-onprem-mgmt Untuk setiap objek Validasi, jalankan perintah berikut untuk menghapus finaler dari objek Validation: kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \ -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge Setelah menghapus finaler dari semua objek Validasi, objek ini dihapus dan operasi penghapusan cluster pengguna selesai secara otomatis. Anda tidak perlu melakukan tindakan tambahan.
Jaringan	1,15, 1,16	Traffic gateway NAT keluar ke server eksternal gagal Jika Pod sumber dan Pod gateway NAT keluar berada di dua node pekerja, traffic dari Pod sumber tidak dapat menjangkau layanan IT perusahaan mereka. Jika Pod terletak di host yang sama, koneksi ke layanan atau aplikasi eksternal berhasil. Masalah ini disebabkan oleh {i>vSphere<i} menjatuhkan paket VXLAN saat {i>tunnel<i} penggabungan diaktifkan. Ada masalah umum pada NSX dan VMware yang hanya mengirimkan traffic gabungan pada port VXLAN yang dikenal (4789). Solusi: Ubah port VXLAN yang digunakan oleh Cilium menjadi 4789: Edit ConfigMap cilium-config: kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG Tambahkan kode berikut ke cilium-config ConfigMap: tunnel-port: 4789 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.
Upgrade	1.15.0-1.15.4	Upgrade cluster admin yang mengaktifkan enkripsi secret yang selalu aktif akan gagal Cluster admin mengupgrade dari 1.14.x ke 1.15.x dengan selalu aktif enkripsi secret diaktifkan akan gagal karena ketidakcocokan antara kunci enkripsi yang dibuat pengontrol dengan kunci yang tetap berada di disk data master admin. Output gkectl upgrade admin berisi pesan error berikut: E0926 14:42:21.796444 40110 console.go:93] Exit with error: E0926 14:42:21.796491 40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane Menjalankan kubectl get secrets -A --kubeconfig KUBECONFIG` gagal dengan error berikut: Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk Solusi Jika Anda memiliki cadangan cluster admin, lakukan langkah-langkah berikut untuk mengatasi kegagalan upgrade: Nonaktifkan secretsEncryption di cluster admin file konfigurasi, lalu mengupdate cluster menggunakan perintah berikut: gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG Saat VM master admin yang baru dibuat, lakukan SSH ke VM master admin, dan mengganti kunci baru pada {i>disk <i} dengan yang lama dari cadangan. Kuncinya ada di /opt/data/gke-k8s-kms-plugin/generatedkeys di master admin. Update manifes Pod statis kms-plugin.yaml di /etc/kubernetes/manifests untuk memperbarui --kek-id agar sesuai dengan kid di kunci enkripsi asli. Mulai ulang Pod statis kms-plugin dengan memindahkan /etc/kubernetes/manifests/kms-plugin.yaml ke lokasi lainnya direktori lalu memindahkannya kembali. Lanjutkan upgrade admin dengan menjalankan gkectl upgrade admin lagi. Mencegah kegagalan upgrade Jika Anda belum melakukan upgrade, sebaiknya Anda tidak mengupgrade ke 1.15.0-1.15.4. Jika Anda harus mengupgrade ke versi yang terpengaruh, lakukan langkah-langkah berikut sebelum mengupgrade cluster admin: Cadangkan cluster admin. Nonaktifkan secretsEncryption di cluster admin file konfigurasi, lalu mengupdate cluster menggunakan perintah berikut: gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG Upgrade cluster admin. Mengaktifkan kembali enkripsi rahasia yang selalu aktif.
Penyimpanan	1,11-1,16	Error disk dan kegagalan pemasangan saat menggunakan Pelacakan Pemblokiran yang Diubah (CBT) Google Distributed Cloud tidak mendukung Changes Block Tracking (CBT) di {i>disk<i}. Beberapa perangkat lunak cadangan menggunakan fitur CBT untuk melacak status {i>disk<i} dan melakukan pencadangan, yang menyebabkan {i> disk<i} tidak dapat terhubung ke VM yang menjalankan Google Distributed Cloud. Untuk informasi selengkapnya, lihat Pusat Informasi VMware artikel ini. Solusi: Jangan mencadangkan VM Google Distributed Cloud, sebagai software pencadangan pihak ketiga dapat menyebabkan CBT diaktifkan pada {i>disk<i} mereka. Tidak perlu kembali mengubah VM ini. Jangan aktifkan CBT pada node, karena perubahan ini tidak akan dipertahankan di seluruh atau upgrade aplikasi. Jika Anda sudah memiliki disk dengan CBT yang diaktifkan, ikuti Langkah-langkah Penyelesaian di Pusat Informasi VMware artikeluntuk menonaktifkan CBT di Disk First Class.
Penyimpanan	1,14, 1,15, 1,16	Kerusakan data pada NFSv3 ketika paralel menambahkan ke file bersama dilakukan dari beberapa {i>host<i} Jika Anda menggunakan susunan penyimpanan Nutanix untuk menyediakan pembagian NFSv3 ke Anda mungkin akan mengalami kerusakan data atau ketidakmampuan Pod untuk berjalan dengan sukses. Masalah ini disebabkan oleh masalah kompatibilitas umum antara versi VMware dan Nutanix tertentu. Untuk selengkapnya lihat informasi terkait Pusat Informasi VMware artikel ini. Solusi: Artikel Pusat Informasi VMware sudah usang karena menunjukkan bahwa tidak ada resolusi saat ini. Untuk mengatasi masalah ini, update ke versi terbaru ESXi di host Anda dan ke versi Nutanix terbaru di penyimpanan Anda .
Sistem operasi	1.13.10, 1.14.6, 1.15.3	Ketidakcocokan versi antara kubelet dan bidang kontrol Kubernetes Untuk rilis Google Distributed Cloud tertentu, kubelet yang berjalan di versi yang berbeda dari bidang kontrol Kubernetes. Terdapat ketidakcocokan karena biner kubelet yang dimuat sebelumnya di OS image menggunakan versi yang berbeda. Tabel berikut mencantumkan ketidakcocokan versi yang teridentifikasi: 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 ada antara patch Kubernetes versi dan tidak ada masalah yang disebabkan oleh kecondongan versi ini.
Upgrade, Update	1.15.0-1.15.4	Upgrade atau update cluster admin dengan versi CA yang lebih tinggi dari 1 gagal Jika cluster admin memiliki versi certificate authority (CA) yang lebih tinggi dari 1, update atau upgrade akan gagal karena validasi versi CA di webhook. Output dari Upgrade/update gkectl berisi pesan error berikut: CAVersion must start from 1 Solusi: Menurunkan skala deployment auto-resize-controller di untuk menonaktifkan perubahan ukuran otomatis node. Ini diperlukan karena kolom baru diperkenalkan ke Resource Kustom cluster admin di 1.15 dapat menyebabkan error pointer nol di auto-resize-controller. kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG Jalankan perintah gkectl dengan flag --disable-admin-cluster-webhook.Misalnya: gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
Operasi	1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1	Penghapusan cluster Controlplane V2 non-HA macet hingga waktu tunggu habis Ketika gugus Controlplane V2 non-HA dihapus, gugus tersebut akan tertahan di node hingga kehabisan waktu. Solusi: Jika cluster berisi StatefulSet dengan data penting, hubungi hubungi Cloud Customer Care untuk mengatasi masalah ini. Atau, lakukan langkah-langkah berikut: Hapus semua VM cluster dari vSphere. Anda dapat menghapus VM melalui UI vSphere, atau jalankan perintah berikut: govc vm.destroy . Hapus otomatis cluster lagi: gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force
Penyimpanan	1.15.0+, 1.16.0+	Tugas pemasangan volume CNS yang konstan muncul setiap menit untuk PVC/PV dalam hierarki setelah mengupgrade ke versi 1.15+ Saat 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 CSI vSphere dan setel list-volumes ke false: kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG Mulai ulang pod pengontrol vSphere CSI: kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Penyimpanan	1.16.0	Peringatan palsu yang dilihat oleh PVC Jika sebuah cluster berisi volume persisten vSphere intree, perintah gkectl diagnose dan gkectl upgrade mungkin mengumpulkan peringatan palsu terhadap klaim volume persisten (PVC) saat memvalidasi setelan penyimpanan cluster. Pesan peringatan terlihat seperti berikut ini 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 di output berisi hal berikut, Anda dapat mengabaikan peringatan tersebut dengan aman: pv.kubernetes.io/bind-completed: "yes" pv.kubernetes.io/bound-by-controller: "yes" volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
Upgrade, Update	1.15.0+, 1.16.0+	Rotasi kunci akun layanan gagal saat beberapa kunci sudah tidak berlaku Jika cluster Anda tidak menggunakan registry pribadi, dan komponen Anda akses kunci akun layanan dan Pemantauan log (atau pendaftaran Connect) masa berlaku kunci akun layanan sudah habis, saat Anda putar kunci akun layanan, gkectl update credentials gagal dengan error yang mirip dengan berikut ini: Error: reconciliation failed: failed to update platform: ... Solusi: Pertama, rotasikan kunci akun layanan akses komponen. Meskipun yang sama ditampilkan, Anda seharusnya dapat merotasi setelah rotasi kunci akun layanan akses komponen. Jika update masih belum berhasil, hubungi Cloud Customer Care untuk mengatasi masalah ini.
Upgrade	1.16.0-1.16.5	1.15 Mesin master pengguna mengalami pembuatan ulang yang tidak terduga saat pengontrol cluster pengguna diupgrade ke 1.16 Selama upgrade cluster pengguna, setelah pengontrol cluster pengguna diupgrade ke 1.16, jika Anda memiliki cluster pengguna 1,15 lainnya yang dikelola oleh cluster admin yang sama, mesin master penggunanya mungkin akan 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 bagaimana 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 tersebut. Opsi 2: Lakukan langkah-langkah berikut: 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 Pantau progres upgrade dengan memeriksa kolom status di OnPremUserCluster. Solusi saat mengupgrade cluster pengguna menggunakan workstation admin Anda sendiri: Opsi 1: Gunakan GKE versi 1.16.6+ di VMware dengan perbaikan tersebut. Opsi 2: Lakukan langkah-langkah berikut: Tambahkan file info build /etc/cloud/build.info dengan konten berikut. Hal ini menyebabkan pemeriksaan preflight berjalan secara lokal di workstation admin, bukan di server. gke_on_prem_version: GKE_ON_PREM_VERSION Contoh: gke_on_prem_version: 1.16.0-gke.669 Jalankan kembali perintah upgrade. Setelah upgrade selesai, hapus file build.info.
Buat	1.16.0-1.16.5, 1.28.0-1.28.100	Pemeriksaan preflight akan gagal jika nama host tidak ada dalam file blok IP. Selama pembuatan cluster, jika Anda tidak menentukan nama host untuk setiap IP di file blok IP, pemeriksaan {i>preflight<i} akan gagal dengan pesan error berikut: multiple VMs found by DNS name in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.` Ada bug dalam pemeriksaan preflight yang menganggap nama host kosong sebagai duplikat. Solusi: Opsi 1: Gunakan versi yang memiliki perbaikan. Opsi 2: Abaikan pemeriksaan preflight 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	Kegagalan pemasangan volume saat mengupgrade/mengupdate cluster admin jika menggunakan cluster pengguna non-HA dan bidang kontrol v1 Untuk cluster admin non-HA dan cluster pengguna bidang kontrol v1, saat Anda mengupgrade atau mengupdate cluster admin, pembuatan ulang mesin master cluster admin dapat terjadi bersamaan dengan mulai ulang mesin master cluster pengguna, yang dapat menampilkan kondisi race. Hal ini menyebabkan Pod bidang kontrol cluster pengguna tidak dapat berkomunikasi ke 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 Dan 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: SSH ke node bidang kontrol pengguna, karena node tersebut adalah cluster pengguna bidang kontrol v1, node bidang kontrol pengguna berada di cluster admin. Mulai ulang kubelet menggunakan perintah berikut: sudo systemctl restart kubelet Setelah mulai ulang, kubelet dapat merekonstruksi stage global mount dengan benar.
Upgrade, Update	1.16.0	Node bidang kontrol gagal dibuat Selama upgrade atau update cluster admin, kondisi race mungkin menyebabkan pengelola pengontrol cloud vSphere menghapus {i>node<i} bidang kontrol. Ini menyebabkan clusterapi-controller macet menunggu node dibuat, dan bahkan upgrade/update waktunya habis. Dalam hal ini, output dari gkectl perintah upgrade/update mirip dengan yang berikut ini: controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"... Untuk mengidentifikasi gejala, jalankan perintah di bawah untuk mendapatkan login pengelola pengontrol cloud vSphere di cluster admin: kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system Berikut adalah contoh pesan error dari perintah di atas: node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache. Solusi: Mulai ulang mesin yang gagal untuk membuat ulang objek node yang dihapus. SSH ke setiap node bidang kontrol dan memulai ulang pod statis pengelola pengontrol cloud vSphere: sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}' sudo crictl stop PREVIOUS_COMMAND_OUTPUT Jalankan kembali perintah upgrade/update.
Operasi	1.16	Nama host duplikat di pusat data yang sama menyebabkan kegagalan pembuatan atau upgrade cluster Upgrade cluster 1.15 atau pembuatan cluster 1.16 dengan IP statis akan gagal jika ada duplikat nama {i>host<i} di pusat data yang sama. Kegagalan ini terjadi karena Pengelola pengontrol cloud vSphere gagal menambahkan IP eksternal dan penyedia ID pada objek node. Hal ini menyebabkan waktu tunggu proses upgrade/pembuatan cluster habis. Untuk mengidentifikasi masalah, dapatkan log pod pengelola pengontrol cloud vSphere untuk cluster tersebut. 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 {i>host<i} diduplikasi, dan lakukan solusinya 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: Perbarui nama host mesin yang terpengaruh di user-ip-block.yaml ke nama yang unik dan picu update otomatis: gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force Jalankan kembali gkectl upgrade cluster Cluster Admin: Perbarui nama host mesin yang terpengaruh di admin-ip-block.yaml ke nama yang unik dan picu update otomatis: gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check Jika ini adalah cluster admin non-HA, dan Anda menemukan vm master admin menggunakan nama host duplikat, Anda juga perlu: Dapatkan 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 di langkah 1. kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]' Pastikan nama host telah 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}' Jalankan kembali 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. Cluster Admin: Hapus mesin node admin. Hapus disk data. Hapus file checkpoint cluster admin. Perbarui nama host mesin yang terpengaruh di admin-ip-block.yaml ke nama yang unik. Jalankan kembali gkectl create admin. Cluster pengguna: Membersihkan resource. Perbarui nama host mesin yang terpengaruh di user-ip-block.yaml ke nama yang unik. Jalankan kembali gkectl create cluster.
Operasi	1.16.0, 1.16.1, 1.16.2, 1.16.3	$ dan ` tidak didukung di nama pengguna atau sandi vSphere Operasi berikut gagal saat nama pengguna atau sandi vSphere berisi $ atau `: Mengupgrade cluster pengguna 1.15 dengan Controlplane V2 yang diaktifkan ke versi 1.16 Mengupgrade cluster admin dengan ketersediaan tinggi (HA) 1,15 ke versi 1.16 Membuat cluster pengguna 1.16 dengan Controlplane V2 diaktifkan Membuat cluster admin dengan ketersediaan tinggi (HA) 1.16 Gunakan Google Distributed Cloud versi 1.16.4+ untuk perbaikan atau lakukan solusi di bawah ini. Solusi yang Anda lakukan bergantung pada operasi yang gagal. Solusi untuk upgrade: Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `. Perbarui nama pengguna atau sandi vCenter di kredensial file konfigurasi. Picu update cluster secara paksa. Cluster pengguna: gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force Cluster Admin: gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check Solusi untuk penginstalan: Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `. Perbarui nama pengguna atau sandi vCenter di kredensial file konfigurasi. Lakukan solusi untuk jenis cluster yang berlaku. Cluster Admin: Hapus mesin node admin. Hapus disk data. Hapus file checkpoint cluster admin. Jalankan kembali gkectl create admin. Cluster pengguna: Membersihkan resource. Jalankan kembali gkectl create cluster.
Penyimpanan	1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16	Kegagalan pembuatan PVC setelah node dibuat ulang dengan nama yang sama Setelah {i>node<i} dihapus dan kemudian dibuat ulang dengan nama {i>node<i} yang sama, ada sedikit kemungkinan bahwa PersistentVolumeKlaim (PVC) berikutnya pembuatan gagal dengan error seperti berikut: The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created Hal ini disebabkan oleh kondisi race saat pengontrol CSI vSphere 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	Perbaikan gkectl admin-master menampilkan error kubeconfig unmarshall Saat Anda menjalankan perintah gkectl repair admin-master pada HA cluster admin, 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 tersebut, lalu menyediakan 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: Buka halaman Hosts and Clusters di klien vSphere. Klik Template VM dan filter menurut nama cluster admin. Anda akan melihat tiga template VM untuk cluster admin. Salin nama template VM yang cocok dengan nama mesin Anda memperbaiki dan menggunakan nama {i>template<i} 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	Melihat VM rusak karena kapasitas disk hampir penuh Jika Anda menggunakan Seesaw sebagai jenis load balancer untuk cluster, VM Seesaw tidak aktif atau terus gagal booting, Anda mungkin melihat pesan error berikut di konsol vSphere: GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd Kesalahan ini menunjukkan bahwa kapasitas {i>disk<i} pada VM rendah karena yang berjalan di Seesaw VM 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, lalu 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 di perintah Docker, lalu jalankan systemctl restart docker.fluent-bit.service
Operasi	1.13, 1.14.0-1.14.6, 1.15	Terjadi error pada kunci publik SSH admin setelah upgrade atau update cluster admin Saat Anda mencoba mengupgrade (gkectl upgrade admin) atau mengupdate (gkectl update admin) cluster admin yang tidak memiliki Ketersediaan Tinggi dengan checkpoint diaktifkan, upgrade atau update mungkin akan gagal dengan pesan error seperti berikut ini: 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 melakukan upgrade ke versi patch Google Distributed Cloud setelah 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	Upgrade cluster admin yang terdaftar di GKE On-Prem API dapat gagal Saat cluster admin didaftarkan di GKE On-Prem API, mengupgrade cluster admin ke versi yang terpengaruh bisa gagal karena keanggotaan fleet tidak dapat diperbarui. Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba mengupgrade cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated Cluster admin didaftarkan di API saat Anda secara eksplisit mendaftarkan 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 mengupgrade cluster admin. Anda mungkin melihat pesan status `gagal untuk error register cluster` untuk sementara. Setelah beberapa waktu, data tersebut akan diupdate secara otomatis.
Upgrade, Update	1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0	Anotasi link resource cluster admin yang terdaftar tidak dipertahankan Saat cluster admin didaftarkan di GKE On-Prem API, resource-nya anotasi link diterapkan ke OnPremAdminCluster kustom resource, yang tidak dipertahankan selama update cluster admin berikutnya karena kunci anotasi yang digunakan salah. Hal ini dapat menyebabkan cluster admin dan tidak sengaja terdaftar di GKE On-Prem API. Cluster admin didaftarkan di API saat Anda secara eksplisit mendaftarkan 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 ke cluster admin lagi.
Jaringan	1.15.0-1.15.2	CoreDNS orderPolicy tidak dikenali OrderPolicy tidak dikenali sebagai parameter dan tidak digunakan. Sebagai gantinya, Google Distributed Cloud selalu menggunakan Random. Masalah ini terjadi karena template CoreDNS tidak diperbarui, yang menyebabkan orderPolicy diabaikan. Solusi: Perbarui template CoreDNS dan terapkan perbaikan. Perbaikan ini berlanjut hingga melakukan upgrade. Edit template yang ada: kubectl edit cm -n kube-system coredns-template Ganti konten template dengan berikut ini: coredns-template: |- .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } {{- if .PrivateGoogleAccess }} import zones/private.Corefile {{- end }} {{- if .RestrictedGoogleAccess }} import zones/restricted.Corefile {{- end }} prometheus :9153 forward . {{ .UpstreamNameservers }} { max_concurrent 1000 {{- if ne .OrderPolicy "" }} policy {{ .OrderPolicy }} {{- end }} } cache 30 {{- if .DefaultDomainQueryLogging }} log {{- end }} loop reload loadbalance }{{ range $i, $stubdomain := .StubDomains }} {{ $stubdomain.Domain }}:53 { errors {{- if $stubdomain.QueryLogging }} log {{- end }} cache 30 forward . {{ $stubdomain.Nameservers }} { max_concurrent 1000 {{- if ne $.OrderPolicy "" }} policy {{ $.OrderPolicy }} {{- end }} } } {{- end }}
Upgrade, Update	1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3	Status OnPremAdminCluster tidak konsisten antara checkpoint dan CR sebenarnya Kondisi race tertentu dapat menyebabkan status OnPremAdminCluster menjadi tidak konsisten antara checkpoint dan CR sebenarnya. Jika masalah 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 menggunakan solusi ini.
Operasi	1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1	Proses rekonsiliasi mengubah sertifikat admin pada cluster admin Google Distributed Cloud mengubah sertifikat admin di bidang kontrol cluster admin pada 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 akan mengalami masalah seperti berikut ini: Sertifikat yang tidak valid dapat menyebabkan perintah berikut kehabisan waktu dan error yang ditampilkan: 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 ini: Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid... Solusi: Upgrade ke versi Google Distributed Cloud setelah perbaikan: 1.13.10+, 1.14.6+, 1.15.2+. Jika upgrade tidak dapat dilakukan, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
Jaringan, Operasi	1.10, 1.11, 1.12, 1.13, 1.14	Komponen Gateway Jaringan Anthos dihapus atau tertunda karena tidak ada kelas prioritas Pod gateway jaringan di kube-system mungkin menampilkan status Pending atau Evicted, seperti yang ditunjukkan dalam contoh {i>output<i} yang ringkas: $ 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 penghapusan atau ketidakmampuan untuk menjadwalkan Pod karena resource node. Karena Pod Gateway Jaringan Anthos tidak PriorityClass memiliki prioritas default yang sama dengan workload lainnya. Jika node memiliki resource yang terbatas, Pod gateway jaringan mungkin dikeluarkan. Perilaku ini sangat buruk untuk ang-node DaemonSet, karena Pod harus dijadwalkan pada node tertentu dan tidak melakukan migrasi. Solusi: Upgrade ke versi 1.15 atau yang lebih baru. Sebagai perbaikan jangka pendek, Anda dapat menetapkan PriorityClass ke komponen Anthos Network Gateway. Pengontrol Google Distributed Cloud menimpa perubahan manual ini selama proses rekonsiliasi, seperti selama upgrade cluster. Menetapkan PriorityClass system-cluster-critical ke Cluster ang-controller-manager dan autoscaler Deployment pengontrol. Menetapkan PriorityClass system-node-critical ke DaemonSet node ang-daemon.
Upgrade, Update	1.12, 1.13, 1.14, 1.15.0-1.15.2	upgrade cluster admin gagal setelah mendaftarkan cluster ke gcloud Setelah Anda menggunakan gcloud untuk mendaftarkan cluster admin dengan non-kosong gkeConnect, Anda mungkin melihat error berikut saat mencoba mengupgrade cluster: failed to register cluster: failed to apply Hub Mem\ bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\ n_prem_cluster.admin_cluster: field cannot be updated Hapus namespace gke-connect: kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG Dapatkan nama cluster admin: kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG Hapus keanggotaan 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 jangka waktu untuk Perintah journalctl yang berjalan di node cluster Hal ini tidak memengaruhi fungsi pengambilan snapshot karena snapshot masih mencakup semua log yang dikumpulkan oleh default dengan menjalankan journalctl pada 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 gkectl prepare windows gagal menginstal Docker di Google Distributed Cloud versi lebih awal dari 1.13 karena MicrosoftDockerProvider tidak digunakan lagi. Solusi: Ide umum untuk menyelesaikan masalah ini adalah dengan mengupgrade ke Google Distributed Cloud 1.13 dan menggunakan gkectl 1.13 untuk membuat template VM Windows, lalu membuat Kumpulan node Windows. Ada dua opsi untuk masuk ke Google Distributed Cloud 1.13 dari versi saat ini seperti yang ditunjukkan di bawah ini. Catatan: Kami memiliki opsi untuk menyelesaikan masalah ini di versi Anda saat ini tanpa harus meningkatkan sepenuhnya ke versi 1.13, tetapi akan membutuhkan lebih banyak panduan langkah selanjutnya, hubungi tim dukungan kami jika Anda ingin mempertimbangkan menggunakan opsi ini. Opsi 1: Upgrade Biru/Hijau Anda dapat membuat cluster baru menggunakan Google Distributed Cloud versi 1.13+ dengan node pool Windows, dan memigrasikan workload Anda ke cluster baru, lalu menghancurkan . Sebaiknya gunakan Google Distributed Cloud versi minor terbaru. Catatan: Anda akan memerlukan resource tambahan untuk menyediakan cluster baru, tetapi lebih sedikit periode nonaktif dan gangguan untuk workload yang ada. Opsi 2: Menghapus kumpulan node Windows dan menambahkannya kembali saat mengupgrade ke Google Distributed Cloud 1.13 Catatan: Untuk opsi ini, beban kerja Windows tidak akan dapat berjalan hingga cluster diupgrade ke versi 1.13 dan kumpulan node Windows ditambahkan kembali. Menghapus kumpulan node Windows yang ada dengan menghapus node pool Windows konfigurasi dari file user-cluster.yaml, lalu jalankan perintah: gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE Upgrade cluster admin+pengguna khusus Linux ke 1.12 setelah mengikuti panduan pengguna upgrade untuk versi minor target yang sesuai. (Pastikan untuk melakukan langkah ini sebelum mengupgrade ke 1.13) Pastikan enableWindowsDataplaneV2: true dikonfigurasi di CR OnPremUserCluster. Jika tidak, cluster akan tetap menggunakan node pool Docker untuk Windows, yang tidak akan kompatibel dengan template VM Windows 1.13 yang baru dibuat dan belum menginstal Docker. Jika tidak dikonfigurasi atau disetel ke salah (false), perbarui cluster Anda untuk menyetelnya ke benar (true) di user-cluster.yaml, lalu jalankan: gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE Upgrade cluster admin+pengguna khusus Linux ke versi 1.13 setelah mengikuti upgrade panduan pengguna. Siapkan template VM Windows menggunakan 1.13 gkectl: gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG Tambahkan kembali konfigurasi kumpulan node Windows ke user-cluster.yaml dengan kolom OSImage yang ditetapkan ke template VM Windows yang baru dibuat. Mengupdate cluster untuk menambahkan kumpulan node 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	Konfigurasi RootDistanceMaxSec tidak diterapkan untuk ubuntu node Nilai default 5 detik untuk RootDistanceMaxSec adalah digunakan pada {i>node<i}, bukan 20 detik yang seharusnya sesuai dengan konfigurasi Anda. Jika Anda memeriksa log startup {i>node<i} dengan melakukan SSH ke VM, yang terletak di `/var/log/startup.log`, Anda dapat menemukan hal berikut {i>error<i}: + has_systemd_unit systemd-timesyncd /opt/bin/master.sh: line 635: has_systemd_unit: command not found Menggunakan RootDistanceMaxSec selama 5 detik dapat menyebabkan sistem jam tidak sinkron dengan server NTP ketika penyimpangan jam lebih besar dari 5 detik. Solusi: Terapkan DaemonSet berikut ke cluster Anda untuk mengonfigurasi RootDistanceMaxSec: apiVersion: apps/v1 kind: DaemonSet metadata: name: change-root-distance namespace: kube-system spec: selector: matchLabels: app: change-root-distance template: metadata: labels: app: change-root-distance spec: hostIPC: true hostPID: true tolerations: # Make sure pods gets scheduled on all nodes. - effect: NoSchedule operator: Exists - effect: NoExecute operator: Exists containers: - name: change-root-distance image: ubuntu command: ["chroot", "/host", "bash", "-c"] args: - | while true; do conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf" if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then echo "timesyncd has the expected RootDistanceMaxSec, skip update" else echo "updating timesyncd config to RootDistanceMaxSec=20" mkdir -p /etc/systemd/timesyncd.conf.d cat > $conf_file << EOF [Time] RootDistanceMaxSec=20 EOF systemctl restart systemd-timesyncd fi sleep 600 done volumeMounts: - name: host mountPath: /host securityContext: privileged: true volumes: - name: host hostPath: path: /
Upgrade, Update	1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2	gkectl update admin gagal karena kolom osImageType kosong Jika Anda menggunakan gkectl versi 1.13 untuk mengupdate versi 1.12 Anda, 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" Jika Anda menggunakan gkectl update admin untuk versi 1.13 atau 1.14 , Anda mungkin melihat pesan berikut dalam responsnya: 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 termasuk menyetel osImageType dari string kosong ke ubuntu_containerd. Kesalahan pembaruan ini disebabkan oleh pengisian ulang yang tidak tepat Kolom osImageType di konfigurasi cluster admin karena yang diperkenalkan dalam versi 1.9. Solusi: Upgrade ke versi Google Distributed Cloud setelah perbaikan. Jika mengupgrade ini tidak memungkinkan bagi Anda, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
Pemasangan, Keamanan	1.13, 1.14, 1.15, 1.16	SNI tidak berfungsi pada cluster pengguna dengan Controlplane V2 Kemampuan untuk memberikan sertifikat penayangan tambahan untuk Server Kubernetes API cluster pengguna dengan authentication.sni tidak berfungsi saat Controlplane V2 diaktifkan ( enableControlplaneV2: true). Solusi: Hingga 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	$ di nama pengguna registry pribadi menyebabkan kegagalan startup mesin bidang kontrol admin Mesin bidang 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 perbaikannya.
Upgrade, Update	1.12.0-1.12.4	Peringatan positif palsu tentang perubahan yang tidak didukung selama update cluster admin Bila Anda update 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	Update cluster pengguna gagal setelah rotasi kunci penandatanganan KSA Setelah Anda memutar Kunci penandatanganan KSA, lalu mengupdate 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: Periksa rahasia di cluster admin pada namespace USER_CLUSTER_NAME, dan dapatkan nama rahasia kunci penandatanganan ksa: kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key Salin rahasia kunci penandatanganan ksa, dan beri nama rahasia 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 - Hapus rahasia kunci penandatanganan ksa sebelumnya: kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME Perbarui kolom data.data di configmap ksa-signed-key-rotation-stage ke '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \ edit configmap ksa-signing-key-rotation-stage 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 ' Update kolom spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation menjadi 1 di resource kustom OnPremUserCluster Anda: kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \ edit onpremusercluster USER_CLUSTER_NAME Tunggu hingga cluster pengguna target siap, Anda dapat memeriksa statusnya dengan: kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \ get onpremusercluster 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 ' Hindari rotasi kunci penandatanganan KSA lainnya hingga cluster meng-upgrade ke versi yang telah diperbaiki.
Operasi	1.13.1+, 1.14, 1., 1.16	Server virtual BIG-IP F5 tidak dibersihkan saat Terraform menghapus cluster pengguna Saat Anda menggunakan Terraform untuk menghapus cluster pengguna dengan beban F5 BIG-IP load balancer, server virtual F5 BIG-IP tidak dihapus setelah cluster penghapusan. Solusi: Untuk menghapus resource F5, ikuti langkah-langkah untuk membersihkan partisi cluster pengguna F5
Penginstalan, Upgrade, Update	1.13.8, 1.14.4	jenis cluster mengambil image container dari docker.io Jika Anda membuat cluster admin versi 1.13.8 atau versi 1.14.4, atau meng-upgrade cluster admin ke versi 1.13.8 atau 1.14.4, jenis cluster menarik image container berikut dari docker.io: docker.io/kindest/kindnetd docker.io/kindest/local-path-provisioner docker.io/kindest/local-path-helper Jika docker.io tidak dapat diakses dari workstation admin Anda, pembuatan atau upgrade cluster admin gagal memunculkan cluster jenis. Menjalankan perintah berikut di workstation admin akan menunjukkan penampung yang sesuai tertunda dengan ErrImagePull: docker exec gkectl-control-plane kubectl get pods -A Respons berisi entri seperti berikut: ... kube-system kindnet-xlhmr 0/1 ErrImagePull 0 3m12s ... local-path-storage local-path-provisioner-86666ffff6-zzqtp 0/1 Pending 0 3m12s ... Image container ini harus dipramuat di container cluster jenis gambar. Namun, v0.18.0 telah masalah dengan image container yang dimuat sebelumnya, sehingga mereka akan ditarik dari internet secara tidak sengaja. Solusi: Jalankan perintah berikut di workstation admin, saat ada cluster admin sedang menunggu dibuat atau diupgrade: docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0 docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
Operasi	1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0	Failover gagal pada cluster pengguna HA Controlplane V2 dan cluster admin saat jaringan memfilter permintaan GARP duplikat Jika VM cluster Anda terhubung dengan {i>switch<i} yang memfilter permintaan GARP duplikat (ARP) duplikat, pemilihan pemimpin keepalive mungkin mengalami kondisi race, yang menyebabkan beberapa {i>node<i} memiliki entri tabel ARP yang salah. Node yang terpengaruh dapat melakukan ping VIP bidang kontrol, tetapi koneksi TCP ke VIP bidang kontrol waktu tunggunya akan habis. Solusi: Jalankan perintah berikut di setiap node bidang kontrol dari 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 dimulai ulang setelah rotasi sertifikat vCenter vsphere-csi-controller harus memuat ulang rahasia vCenter-nya setelah rotasi sertifikat vCenter. Namun, sistem saat ini tidak memulai ulang pod vsphere-csi-controller dengan benar, sehingga menyebabkan vsphere-csi-controller error setelah rotasi. Solusi: Untuk cluster yang dibuat di versi 1.13 dan yang lebih baru, ikuti petunjuk di bawah untuk memulai ulang vsphere-csi-controller kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
Penginstalan	1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1	Pembuatan cluster admin tidak gagal saat terjadi error pendaftaran cluster Bahkan ketika pendaftaran cluster gagal selama pembuatan cluster admin, perintah gkectl create admin tidak gagal saat terjadi error dan mungkin berhasil. Dengan kata lain, pembuatan cluster admin bisa "berhasil" tanpa terdaftar ke suatu fleet. Untuk mengidentifikasi gejala, Anda dapat mencari pesan error berikut dalam log `gkectl create admin`, Failed to register admin cluster Anda juga dapat memeriksa apakah 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 kembali pendaftaran cluster admin setelah pembuatan cluster. Untuk cluster yang dibuat pada versi sebelumnya, Tambahkan pasangan nilai kunci palsu seperti "foo: bar" ke file kunci SA Connect-register Anda Jalankan gkectl update admin untuk mendaftarkan ulang cluster admin.
Upgrade, Update	1.10, 1.11, 1.12, 1.13.0-1.13.1	Pendaftaran ulang cluster admin mungkin dilewati selama upgrade cluster admin Selama upgrade cluster admin, jika waktu upgrade node bidang kontrol pengguna habis, cluster admin tidak akan didaftarkan ulang dengan versi agen koneksi yang telah diupdate. Solusi: Periksa apakah cluster ditampilkan di antara cluster yang 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 kembali pendaftaran cluster admin setelah pembuatan cluster. Untuk cluster yang diupgrade ke versi sebelumnya, Tambahkan pasangan nilai kunci palsu seperti "foo: bar" ke file kunci SA Connect-register Anda Jalankan gkectl update admin untuk mendaftarkan ulang cluster admin.
Konfigurasi	1.15.0	Pesan error palsu tentang vCenter.dataDisk Untuk cluster admin dengan ketersediaan tinggi, gkectl prepare menampilkan pesan {i>error <i}yang keliru ini: vCenter.dataDisk must be present in the AdminCluster spec Solusi: Anda dapat mengabaikan pesan error ini dengan aman.
VMware	1.15.0	Pembuatan kumpulan node gagal karena aturan afinitas Host VM yang redundan Selama pembuatan kumpulan node yang menggunakan Afinitas Host VM, kondisi race dapat mengakibatkan beberapa Aturan afinitas Host VM dibuat dengan nama yang sama. Hal ini dapat menyebabkan pembuatan kumpulan node gagal. Solusi: Hapus aturan redundan lama agar pembuatan kumpulan node dapat dilanjutkan. Aturan ini diberi nama [USER_CLUSTER_NAME]-[HASH].
Operasi	1.15.0	gkectl repair admin-master mungkin gagal karena failed to delete the admin master node object and reboot the admin master VM Perintah gkectl repair admin-master mungkin gagal karena kondisi race dengan error berikut. Failed to repair: failed to delete the admin master node object and reboot the admin master VM Solusi: Perintah ini bersifat idempoten. {i>Tcpdump<i} dapat berjalan kembali dengan aman sampai perintah berhasil.
Upgrade, Update	1.15.0	Pod tetap dalam status Gagal setelah pembuatan ulang atau update node bidang kontrol Setelah Anda membuat ulang atau mengupdate node bidang kontrol, Pod tertentu mungkin dibiarkan dalam status Failed karena predikat NodeAffinity gagal. Pod yang gagal ini tidak memengaruhi health atau operasi cluster normal. Solusi: Anda dapat mengabaikan Pod yang gagal dengan aman atau menghapusnya secara manual.
Keamanan, Konfigurasi	1.15.0-1.15.1	OnPremUserCluster tidak siap karena kredensial registry pribadi Jika Anda menggunakan kredensial yang disiapkan dan {i>registry<i} pribadi, tetapi Anda belum mengonfigurasi kredensial yang disiapkan untuk registry pribadi Anda, {i>OnPremUserCluster<i} mungkin belum siap, dan Anda mungkin melihat pesan error berikut: failed to check secret reference for private registry … Solusi: Siapkan kredensial registry pribadi untuk cluster pengguna sesuai dengan ke petunjuk di Konfigurasi kredensial yang disiapkan.
Upgrade, Update	1.15.0	gkectl upgrade admin gagal dengan StorageClass standard sets the parameter diskformat which is invalid for CSI Migration Selama gkectl upgrade admin, pemeriksaan preflight penyimpanan untuk Migrasi CSI akan diverifikasi bahwa StorageClasses tidak memiliki parameter yang diabaikan setelah Migrasi CSI. Misalnya, jika ada StorageClass dengan parameter diskformat, gkectl upgrade admin menandai StorageClass dan melaporkan kegagalan dalam validasi preflight. Cluster admin yang dibuat di Google Distributed Cloud 1.10 dan sebelumnya memiliki StorageClass dengan diskformat: thin yang akan menggagalkan validasi ini, tetapi StorageClass ini masih berfungsi setelah Migrasi CSI. Kegagalan ini harus ditafsirkan sebagai peringatan. Untuk informasi selengkapnya, periksa bagian parameter StorageClass di Memigrasikan Volume vSphere In-Tree ke Plugin Penyimpanan Container vSphere. Solusi: Setelah mengonfirmasi bahwa cluster Anda memiliki StorageClass dengan parameter yang diabaikan setelah Migrasi CSI jalankan gkectl upgrade admin dengan flag --skip-validation-cluster-health.
Penyimpanan	1,15, 1,16	Volume vSphere dalam pohon yang dimigrasikan menggunakan sistem file Windows tidak dapat digunakan dengan driver CSI vSphere Dalam kondisi tertentu, disk dapat dipasang sebagai hanya baca ke Windows node. Hal ini menyebabkan volume terkait bersifat hanya baca di dalam Pod. Masalah ini kemungkinan besar terjadi jika sekumpulan node baru menggantikan node lama yang sama (misalnya, upgrade cluster atau pembaruan kumpulan node). Stateful yang sebelumnya bekerja dengan baik mungkin tidak dapat menulis ke pada kumpulan node baru. Solusi: 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"}' Gunakan PersistentVolumeKlaim untuk mendapatkan nama PersistentVolume: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \ PVC_NAME --namespace POD_NAMESPACE \ -o jsonpath='{.spec.volumeName}{"\n"}' Tentukan nama node tempat Pod dijalankan: kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \ --namespace POD_NAMESPACE \ -o jsonpath='{.spec.nodeName}{"\n"}' Mendapatkan akses powershell ke node, baik melalui SSH atau vSphere dan antarmuka web Anda. Menetapkan variabel lingkungan: PS C:\Users\administrator> pvname=PV_NAME PS C:\Users\administrator> podid=POD_UID Identifikasi nomor {i>disk<i} 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 Pastikan disk adalah readonly: PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly Hasilnya seharusnya True. Tetapkan readonly ke false. PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly Hapus Pod agar dapat dimulai ulang: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \ --namespace POD_NAMESPACE Pod akan dijadwalkan ke node yang sama. Namun, seandainya Pod mendapatkan dijadwalkan ke {i>node<i} baru, Anda mungkin perlu mengulangi langkah sebelumnya pada {i>node<i} baru.
Upgrade, Update	1.12, 1.13.0-1.13.7, 1.14.0-1.14.4	vsphere-csi-secret tidak diupdate setelah gkectl update credentials vsphere --admin-cluster Jika Anda memperbarui kredensial vSphere untuk cluster admin yang mengikuti memperbarui kredensial cluster, Anda mungkin menemukan vsphere-csi-secret pada namespace kube-system di cluster admin yang masih menggunakan kredensial lama. Solusi: Dapatkan nama rahasia vsphere-csi-secret: kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret Perbarui data rahasia vsphere-csi-secret yang Anda dapatkan dari langkah di atas: kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \ "{\"data\":{\"config\":\"$( \ kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \ | base64 -d \ | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \ | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \ | base64 -w 0 \ )\"}}" Mulai ulang vsphere-csi-controller: kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller Anda dapat melacak status peluncuran dengan: kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller Setelah deployment berhasil diluncurkan, vsphere-csi-secret yang telah diupdate akan 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 errorloop saat mengaktifkan Cloud Audit Logs dengan gkectl update cluster audit-proxy mungkin errorloop karena --cluster-name kosong. Perilaku ini disebabkan oleh bug dalam logika update, yang membuat nama cluster tidak disebarkan ke pod audit-proxy / manifes container. Solusi: Untuk cluster pengguna bidang kontrol v2 dengan enableControlplaneV2: true, hubungkan ke mesin bidang kontrol pengguna menggunakan SSH, dan perbarui /etc/kubernetes/manifests/audit-proxy.yaml dengan --cluster_name=USER_CLUSTER_NAME. Untuk cluster pengguna bidang kontrol v1, edit penampung audit-proxy di set stateful 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	Deployment ulang bidang kontrol tambahan tepat setelah gkectl upgrade cluster Tepat setelah gkectl upgrade cluster, pod bidang kontrol dapat di-deploy ulang lagi. Status cluster dari gkectl list clusters berubah dari RUNNING menjadi RECONCILING. Permintaan ke cluster pengguna mungkin kehabisan waktu. Perilaku ini terjadi karena rotasi sertifikat bidang kontrol terjadi secara otomatis setelah gkectl upgrade cluster. Masalah ini hanya terjadi pada cluster pengguna yang TIDAK menggunakan bidang kontrol v2. Solusi: Tunggu hingga status cluster berubah kembali menjadi RUNNING dalam gkectl list clusters, atau meng-upgrade ke versi dengan perbaikan: 1.13.6+, 1.14.2+, atau 1.15+.
Upgrade, Update	1.12.7	Rilis buruk 1.12.7-gke.19 telah dihapus Google Distributed Cloud 1.12.7-gke.19 adalah rilis yang buruk dan Anda tidak boleh menggunakannya. Artefak telah dihapus dari bucket Cloud Storage. Solusi: Gunakan rilis 1.12.7-gke.20 sebagai gantinya.
Upgrade, Update	1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3	gke-connect-agent terus menggunakan image lama setelah kredensial registry diperbarui Jika Anda memperbarui kredensial registry menggunakan salah satu metode berikut: gkectl update credentials componentaccess jika tidak menggunakan registry pribadi gkectl update credentials privateregistry jika menggunakan registry pribadi Anda mungkin mendapati gke-connect-agent terus menggunakan versi lama gambar atau pod gke-connect-agent tidak dapat diambil karena ke 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: Hapus namespace gke-connect: kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect Deploy ulang gke-connect-agent dengan register asli kunci akun layanan (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 rahasia pull image secara manual regcred yang digunakan oleh gke-connect-agent deployment: kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}" Opsi 3: Anda dapat menambahkan rahasia pull image default untuk cluster Anda di deployment gke-connect-agent dengan: Salin rahasia default ke namespace gke-connect: kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f - Dapatkan nama deployment gke-connect-agent: kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent Tambahkan rahasia default ke deployment gke-connect-agent: kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
Penginstalan	1,13, 1,14	Kegagalan pemeriksaan konfigurasi LB manual Jika Anda memvalidasi konfigurasi sebelum membuat cluster 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	dll. kelaparan smartwatch Cluster yang menjalankan dlld versi 3.4.13 atau sebelumnya mungkin mengalami menonton kelaparan dan pengawasan sumber daya non-operasional, yang dapat menyebabkan masalah berikut: Penjadwalan pod terganggu Node tidak dapat didaftarkan kubelet tidak mengamati perubahan pod Masalah ini dapat menyebabkan 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 versi {i>etcd<i} 3.4.21. Semua versi Google Distributed Cloud sebelumnya terpengaruh oleh menyelesaikan masalah ini. Solusi Jika tidak dapat segera melakukan upgrade, Anda dapat mengurangi risiko kegagalan cluster dengan mengurangi jumlah node dalam cluster Anda. Hapus node hingga etcd_network_client_grpc_sent_bytes_total kurang dari 300 MBps. Untuk melihat metrik ini di Metrics Explorer: Buka Metrics Explorer di konsol Google Cloud: Buka Metrics Explorer Pilih tab Configuration Luaskan Pilih metrik, masukkan Kubernetes Container di panel filter, lalu gunakan submenu untuk memilih metrik: Di menu Active resources, pilih Kubernetes Container. Di menu Active metric categories, pilih Anthos. Di menu Active metrics, pilih etcd_network_client_grpc_sent_bytes_total. Klik Terapkan.
Upgrade, Update	1.10, 1.11, 1.12, 1.13, dan 1.14	GKE Identity Service dapat menyebabkan latensi bidang kontrol Saat cluster dimulai ulang atau diupgrade, GKE Identity Service dapat memperoleh kewalahan dengan traffic yang terdiri dari token JWT kedaluwarsa yang diteruskan dari kube-apiserver ke GKE Identity Service selama webhook otentikasi. Meskipun GKE Identity Service tidak {i>crashloop <i}menjadi tidak responsif dan berhenti melayani permintaan lebih lanjut. Masalah ini pada akhirnya menyebabkan latensi bidang kontrol yang lebih tinggi. Masalah ini telah diperbaiki dalam rilis Google Distributed Cloud berikut: 1.12.6+ 1.13.6+ 1.14.2+ Untuk mengetahui apakah Anda terpengaruh oleh masalah ini, lakukan langkah-langkah berikut: Periksa apakah endpoint GKE Identity Service dapat dijangkau secara eksternal: curl -s -o /dev/null -w "%{http_code}" \ -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}' Ganti CLUSTER_ENDPOINT dengan VIP bidang kontrol dan port load balancer bidang kontrol untuk (misalnya, 172.16.20.50:443). Jika Anda terpengaruh oleh masalah ini, perintah tersebut akan menampilkan 400 kode status. Jika waktu permintaan habis, mulai ulang Pod ais lalu jalankan kembali perintah curl untuk melihat apakah tindakan tersebut menyelesaikan masalah. Jika Anda mendapatkan kode status 000, masalah telah teratasi dan selesai. Jika Anda masih mendapatkan kode status 400, Server HTTP GKE Identity Service tidak dimulai. Jika demikian, lanjutkan. Periksa log kube-apiserver dan GKE Identity Service: 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: Periksa log kube-apiserver untuk cluster Anda: Dalam perintah berikut, KUBE_APISERVER_POD adalah nama Pod kube-apiserver di cluster yang diberikan. 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 akan terpengaruh oleh masalah ini: E0811 22:30:22.656085 1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout E0811 22:30:22.656266 1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]" Solusi Jika tidak dapat segera mengupgrade cluster untuk mendapatkan perbaikan, Anda dapat identifikasi dan mulai ulang pod yang bermasalah sebagai solusi: Tingkatkan level verbositas GKE Identity Service ke 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 Periksa log GKE Identity Service untuk mengetahui konteks token yang tidak valid: kubectl logs -f -l k8s-app=ais -n anthos-identity-service \ --kubeconfig KUBECONFIG Untuk mendapatkan payload token yang terkait dengan setiap konteks token yang tidak valid, mengurai setiap rahasia akun layanan terkait dengan perintah berikut: kubectl -n kube-system get secret SA_SECRET \ --kubeconfig KUBECONFIG \ -o jsonpath='{.data.token}' | base64 --decode Untuk mendekode token dan melihat nama pod sumber dan namespace, salin token ke debugger di jwt.io. Mulai ulang pod yang diidentifikasi dari token.
Operasi	1.8, 1.9, 1.10	Masalah peningkatan penggunaan memori pada pod pemeliharaan etcd Pod pemeliharaan etcd yang menggunakan image etcddefrag:gke_master_etcddefrag_20210211.00_p0 akan terpengaruh. Container `etcddefrag` membuka koneksi baru ke server etcd selama setiap siklus defrag dan koneksi lama tidak dibersihkan. Solusi: Opsi 1: Upgrade ke versi patch terbaru dari 1.8 ke 1.11 yang berisi perbaikan. Opsi 2: Jika Anda menggunakan versi patch yang lebih lama dari 1.9.6 dan 1.10.3, Anda perlu menurunkan skala pod pemeliharaan etcd untuk admin dan cluster pengguna: kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Operasi	1.9, 1.10, 1.11, 1.12, 1.13	Melewatkan health check pod bidang kontrol cluster pengguna Pengontrol kondisi cluster dan perintah gkectl diagnose cluster melakukan serangkaian health check, termasuk health check pod di seluruh namespace. Namun, pod mulai melewati pod bidang kontrol pengguna secara tidak sengaja. Mode bidang kontrol v2 tidak akan memengaruhi cluster Anda. Solusi: Hal ini tidak akan memengaruhi pengelolaan cluster atau workload apa pun. Jika ingin memeriksa kondisi pod bidang kontrol, Anda dapat menjalankan perintah berikut: kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Upgrade, Update	1,6+, 1,7+	Upgrade cluster admin 1.6 dan 1.7 mungkin terpengaruh oleh k8s.gcr.io -> Pengalihan registry.k8s.io Kubernetes mengalihkan traffic dari k8s.gcr.io ke registry.k8s.io pada 20/3/2023. Di Google Distributed Cloud 1.6.x dan 1.7.x, upgrade cluster admin menggunakan image container k8s.gcr.io/pause:3.2. Jika Anda menggunakan proxy untuk workstation admin dan proxy tidak mengizinkan registry.k8s.io serta image container k8s.gcr.io/pause:3.2 tidak di-cache secara lokal, upgrade cluster admin akan gagal saat mengambil image container. Solusi: Tambahkan registry.k8s.io ke daftar proxy yang diizinkan untuk workstation admin Anda.
Jaringan	1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2	Melihat kegagalan validasi pada pembuatan load balancer gkectl create loadbalancer gagal dengan pesan error berikut: - Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host Hal ini terjadi karena file grup jungkat-jungkit sudah ada. Dan pemeriksaan preflight mencoba memvalidasi load balancer jungkat-jungkit yang tidak ada. Solusi: Hapus file grup jungkat-jungkit yang ada untuk cluster ini. Nama file adalah seesaw-for-gke-admin.yaml untuk cluster admin, dan seesaw-for-{CLUSTER_NAME}.yaml untuk cluster pengguna.
Jaringan	1,14	Waktu tunggu aplikasi yang disebabkan oleh kegagalan penyisipan tabel conntrack Google Distributed Cloud versi 1.14 rentan terhadap netfilter kegagalan penyisipan tabel pelacakan koneksi (conntrack) saat menggunakan {i>image<i} sistem operasi Ubuntu atau COS. Kegagalan penyisipan menyebabkan acak aplikasi telah habis dan dapat terjadi bahkan ketika tabel conntrack memiliki ruang untuk entri baru. Kegagalan disebabkan oleh perubahan {i>kernel<i} 5.15 dan yang lebih tinggi yang membatasi penyisipan tabel berdasarkan rantai paruh. Untuk melihat apakah Anda terpengaruh oleh masalah ini, Anda dapat memeriksa in-kernel statistik sistem pelacakan koneksi di setiap node dengan 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 bukan nol nomor tersebut, Anda terpengaruh oleh masalah ini. Solusi Mitigasi jangka pendeknya adalah dengan meningkatkan ukuran file netfiler tabel hash (nf_conntrack_buckets) dan netfilter tabel pelacakan koneksi (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. Tujuan nilai ukuran tabel default adalah 262144. Sebaiknya Anda menetapkan bernilai 65.536 kali jumlah inti pada {i>node<i}. Misalnya, jika node Anda memiliki delapan core, tetapkan ukuran tabel ke 524288.
Jaringan	1.13.0-1.13.2	calico-typha atau loop error operator anetd pada node Windows dengan Controlplane v2 Dengan Controlplane v2 atau model penginstalan baru, calico-typha atau anetd-operator mungkin dijadwalkan ke node Windows dan mengalami error loop. Alasannya adalah karena kedua deployment ini menoleransi semua taint, termasuk taint node Windows. Solusi: Upgrade ke versi 1.13.3+, atau jalankan perintah berikut untuk mengedit deployment `calico-typha` atau `anetd-operator`: # If dataplane v2 is not used. kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG # If dataplane v2 is used. kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG Hapus spec.template.spec.tolerations berikut: - effect: NoSchedule operator: Exists - effect: NoExecute operator: Exists Dan tambahkan toleransi berikut: - key: node-role.kubernetes.io/master operator: Exists
Konfigurasi	1.14.0-1.14.2	File kredensial registry pribadi cluster pengguna tidak dapat dimuat Anda mungkin tidak dapat membuat cluster pengguna jika menentukan Bagian privateRegistry dengan kredensial fileRef. Preflight mungkin gagal dengan pesan berikut: [FAILURE] Docker registry access: Failed to login. Solusi: Jika Anda tidak ingin menentukan kolom ini atau ingin menggunakan kolom yang sama pribadi sebagai cluster admin, Anda cukup menghapus atau memberi komentar di bagian privateRegistry di cluster pengguna Anda file konfigurasi. Jika Anda ingin menggunakan kredensial registry pribadi tertentu untuk cluster pengguna, Anda dapat menentukan privateRegistry untuk sementara seperti ini: privateRegistry: address: PRIVATE_REGISTRY_ADDRESS credentials: username: PRIVATE_REGISTRY_USERNAME password: PRIVATE_REGISTRY_PASSWORD caCertPath: PRIVATE_REGISTRY_CACERT_PATH (CATATAN: Ini hanya perbaikan sementara dan bidang ini sudah tidak digunakan lagi, pertimbangkan untuk menggunakan file kredensial saat mengupgrade ke 1.14.3+.)
Operasi	1,10 dan yang lebih baru	Cloud Service Mesh dan mesh layanan lainnya yang tidak kompatibel dengan Dataplane v2 Dataplane V2 mengambil alih load balancing dan membuat soket kernel, bukan DNAT berbasis paket. Ini berarti bahwa Cloud Service Mesh tidak dapat melakukan pemeriksaan paket karena pod dilewati dan tidak pernah menggunakan IPTables. Ini direpresentasikan dalam mode bebas kube-proxy karena hilangnya konektivitas atau pemilihan rute traffic yang salah untuk layanan dengan Cloud Service Mesh karena file bantuan tidak dapat melakukan pemeriksaan paket. Masalah ini terjadi di semua versi Google Distributed Cloud 1.10, tetapi beberapa versi baru 1.10 (1.10.2+) memiliki solusi. Solusi: Upgrade ke versi 1.11 untuk kompatibilitas penuh atau jika menjalankan versi 1.10.2 atau yang lebih baru, jalankan: kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG Tambahkan bpf-lb-sock-hostns-only: true ke configmap, lalu mulai ulang daemonset anetd: kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
Penyimpanan	1.12+, 1.13.3	kube-controller-manager mungkin melepaskan volume persisten dengan kuat setelah 6 menit kube-controller-manager mungkin kehabisan waktu saat melepaskan PV/PVC setelah 6 menit, dan lepaskan PV/PVC dengan paksa. Log mendetail dari kube-controller-manager tampilkan acara yang mirip dengan berikut ini: $ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446 1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching Untuk memastikan masalah ini terjadi, login ke node dan jalankan perintah berikut: # See all the mounting points with disks lsblk -f # See some ext4 errors sudo dmesg -T Di log kubelet, pesan error seperti berikut akan ditampilkan: Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" : the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount Solusi: Hubungkan ke node yang terpengaruh menggunakan SSH, lalu mulai ulang node.
Upgrade, Update	1,12+, 1,13+, 1,14+	Upgrade cluster terhenti jika driver CSI pihak ketiga digunakan Anda mungkin tidak dapat mengupgrade cluster jika menggunakan CSI pihak ketiga {i>driver<i}. 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 --skip-validation-all sebelumnya.
Operasi	1,10+, 1,11+, 1,12+, 1,13+, 1,14+	gkectl repair admin-master membuat VM master admin tanpa mengupgrade versi hardware vm-nya Node master admin yang dibuat melalui gkectl repair admin-master mungkin menggunakan versi hardware VM yang lebih rendah dari yang diharapkan. Ketika masalah terjadi, Anda akan melihat error dari gkectl diagnose cluster laporan. 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, sebagaimana dijelaskan dalam error , lalu memulai node.
Sistem operasi	1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+	VM merilis sewa DHCP saat dimatikan/dimulai ulang secara tiba-tiba, yang mungkin mengakibatkan perubahan IP Dalam systemd v244, systemd-networkd memiliki perubahan perilaku default pada konfigurasi KeepConfiguration. Sebelum perubahan ini, VM tidak mengirim pesan rilis sewa DHCP ke server DHCP pada mematikan atau memulai ulang. Setelah perubahan ini, VM mengirim pesan tersebut dan mengembalikan IP ke server DHCP. Akibatnya, IP yang dirilis mungkin dialokasikan ulang ke VM lain dan/atau IP yang berbeda mungkin ditetapkan ke VM, yang mengakibatkan konflik IP (di level Kubernetes, bukan level vSphere) dan/atau 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 systemd-networkd perubahan perilaku default. VM yang menjalankan DaemonSet ini tidak akan melepaskan IP ke server DHCP pada mematikan/memulai ulang. IP akan dibebaskan secara otomatis oleh server DHCP kapan 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	Kunci akun layanan akses komponen dihapus total setelah cluster admin diupgrade dari 1.11.x Masalah ini hanya akan memengaruhi cluster admin yang diupgrade dari 1.11.x, dan tidak akan memengaruhi cluster admin yang baru dibuat setelah 1.12. Setelah mengupgrade cluster 1.11.x ke 1.12.x, Kolom component-access-sa-key di Rahasia admin-cluster-creds akan dihapus menjadi kosong. Hal ini dapat diperiksa dengan menjalankan perintah berikut: kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key' Jika Anda mendapati bahwa output-nya kosong, berarti kunci telah dihapus. Setelah kunci akun layanan akses komponen dihapus, menginstal klaster pengguna baru atau meningkatkan klaster pengguna yang ada gagal. Berikut ini daftar beberapa pesan error yang mungkin Anda temui: Kegagalan preflight validasi lambat dengan pesan error: "Failed to create the test VMs: failed to get service account key: service account is not configured." Persiapan 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 Google Cloud Konsol atau gcloud CLI, saat Anda menjalankan gkectl update admin --enable-preview-user-cluster-central-upgrade 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 pada output kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml). Solusi: Menambahkan kembali kunci akun layanan akses komponen ke rahasia 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+	Penskala otomatis cluster tidak berfungsi saat Controlplane V2 diaktifkan Untuk cluster pengguna yang dibuat dengan Controlplane V2 atau model penginstalan baru, kumpulan node yang mengaktifkan penskalaan otomatis selalu menggunakan autoscaling.minReplicas di user-cluster.yaml. Log pod cluster-autoscaler juga menunjukkan bahwa pod tersebut tidak responsif. > 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 kumpulan node dengan `gkectl update cluster` hingga diupgrade ke versi yang memiliki perbaikan
Penginstalan	1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0	CIDR tidak diizinkan dalam file blok IP Saat pengguna menggunakan CIDR dalam file blok IP, validasi konfigurasi akan gagal dengan error berikut: - Validation Category: Config Check - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP: 172.16.20.12/30 Solusi: Sertakan IP individual dalam file blok IP hingga meningkatkan ke versi dengan perbaikan: 1.12.5, 1.13.4, 1.14.1+.
Upgrade, Update	1.14.0-1.14.1	Pembaruan jenis image OS di admin-cluster.yaml tidak menunggu mesin bidang kontrol pengguna dibuat ulang Saat Memperbarui jenis image OS bidang kontrol di admin-cluster.yaml, dan jika cluster pengguna yang sesuai dibuat melalui Controlplane V2, mesin bidang kontrol pengguna mungkin tidak menyelesaikan pembuatan ulang saat perintah gkectl selesai. Solusi: Setelah update selesai, tunggu hingga mesin bidang kontrol pengguna juga menyelesaikan pembuatan ulang dengan memantau jenis image OS node menggunakan kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. mis. Jika memperbarui dari Ubuntu ke COS, kita harus menunggu sampai semua mesin bidang kontrol berubah sepenuhnya dari Ubuntu ke COS bahkan setelah perintah pembaruan selesai.
Operasi	1.10, 1.11, 1.12, 1.13, 1.14.0	Error pembuatan atau penghapusan pod karena token autentikasi akun layanan Calico CNI atau Masalah dengan Calico di Google Distributed Cloud 1.14.0 menyebabkan pembuatan dan penghapusan Pod gagal dengan pesan error berikut output kubectl describe pods: error getting ClusterInformation: connection is unauthorized: Unauthorized Masalah ini hanya terjadi 24 jam setelah klaster dibuat atau diupgrade ke versi 1.14 menggunakan Calico. Cluster admin selalu menggunakan Calico, sedangkan untuk cluster pengguna kolom konfigurasi `enableDataPlaneV2` di user-cluster.yaml, jika kolom itu diatur ke `false`, atau tidak ditentukan, itu berarti Anda menggunakan Calico di bagian . Beberapa node Container install-cni membuat kubeconfig dengan token yang berlaku selama 24 jam. Token ini harus dikirimkan secara berkala diperpanjang oleh Pod calico-node. calico-node Pod tidak dapat memperpanjang token karena tidak memiliki akses ke direktori yang berisi file {i> kubeconfig<i} pada {i>node<i}. Solusi: Masalah ini telah diperbaiki pada Google Distributed Cloud versi 1.14.1. Upgrade ke versi ini atau yang lebih baru. Jika kamu tidak bisa langsung mengupgrade, terapkan patch berikut pada calico-node DaemonSet di cluster admin dan pengguna Anda: kubectl -n kube-system get daemonset calico-node \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \ | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \ | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f - kubectl -n kube-system get daemonset calico-node \ --kubeconfig USER_CLUSTER_KUBECONFIG -o json \ | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \ | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f - Ganti yang berikut: ADMIN_CLUSTER_KUBECONFIG: jalur pada file kubeconfig cluster admin. USER_CLUSTER_CONFIG_FILE: jalur dari file konfigurasi cluster pengguna Anda.
Penginstalan	1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0	Validasi blok IP gagal saat menggunakan CIDR Pembuatan cluster gagal meskipun pengguna memiliki konfigurasi yang benar. Pengguna melihat pembuatan gagal karena cluster tidak memiliki cukup IP. Solusi: CIDR membagi menjadi beberapa blok CIDR yang lebih kecil, seperti 10.0.0.0/30 menjadi 10.0.0.0/31, 10.0.0.2/31. Asalkan ada N+1 CIDR, dengan N adalah jumlah node dalam cluster, ini sudah cukup.
Operasi, Upgrade, Update	1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6	Pencadangan cluster admin tidak menyertakan konfigurasi dan kunci enkripsi rahasia yang selalu aktif Jika fitur enkripsi secret yang selalu aktif diaktifkan bersama dengan pencadangan cluster, pencadangan cluster admin akan gagal menyertakan kunci enkripsi dan konfigurasi yang diperlukan oleh fitur enkripsi secret yang selalu aktif. Oleh karena itu, memperbaiki master admin dengan cadangan ini menggunakan gkectl repair admin-master --restore-from-backup menyebabkan error berikut: Validating admin master VM xxx ... Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")... ERROR Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")... ERROR Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")... ERROR Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master Solusi: Gunakan biner gkectl dari versi patch terbaru yang tersedia untuk versi minor terkait untuk melakukan pencadangan cluster admin setelah operasi cluster penting. Misalnya, jika cluster menjalankan versi 1.10.2, gunakan biner 1.10.5 gkectl untuk melakukan pencadangan cluster admin secara manual seperti yang dijelaskan dalam Mencadangkan dan Memulihkan cluster admin dengan gkectl.
Operasi, Upgrade, Update	1,10 dan yang lebih baru	Membuat ulang VM master admin dengan boot disk baru (misalnya, gkectl repair admin-master) akan gagal jika fitur enkripsi secret yang selalu aktif diaktifkan menggunakan perintah `gkectl update`. Jika fitur enkripsi secret yang selalu aktif tidak diaktifkan saat pembuatan cluster, tetapi diaktifkan nanti menggunakan operasi gkectl update, gkectl repair admin-master akan gagal memperbaiki node bidang kontrol cluster admin. Sebaiknya fitur enkripsi secret yang selalu aktif diaktifkan saat pembuatan cluster. Tidak ada mitigasi saat ini.
Upgrade, Update	1.10	Mengupgrade cluster pengguna pertama dari 1.9 ke 1.10 akan membuat ulang node di cluster pengguna lain Mengupgrade cluster pengguna pertama dari 1.9 ke 1.10 dapat membuat ulang node di cluster pengguna lain pada cluster admin yang sama. Pembuatan ulang dilakukan secara bergelombang. disk_label dihapus dari MachineTemplate.spec.template.spec.providerSpec.machineVariables, yang memicu update pada semua MachineDeployment secara tiba-tiba. Solusi: Lihat langkah-langkah solusi Perkecil skala replika clusterapi-controllers menjadi 0 untuk semua cluster pengguna. kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG Upgrade setiap cluster pengguna satu per satu.
Upgrade, Update	1.10.0	Docker sering dimulai ulang setelah upgrade cluster Mengupgrade cluster pengguna ke 1.10.0 dapat menyebabkan Docker sering dimulai ulang. Anda dapat mendeteksi masalah ini dengan menjalankan kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG Kondisi node akan menunjukkan apakah Docker sering dimulai ulang. Berikut adalah contoh output: Normal FrequentDockerRestart 41m (x2 over 141m) systemd-monitor Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart Untuk memahami akar masalah, Anda perlu melakukan SSH ke node yang memiliki gejala dan menjalankan perintah seperti sudo journalctl --utc -u docker atau sudo journalctl -x Solusi: Menggunakan container untuk runtime container Mengupgrade cluster ke versi terbaru 1.10
Upgrade, Update	1.11, 1.12	Komponen GMP yang di-deploy sendiri tidak dipertahankan setelah diupgrade ke versi 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 gmp-system untuk cluster Anda, komponen tidak dipertahankan saat Anda upgrade ke versi 1.12.x. Mulai versi 1.12, komponen GMP dalam namespace gmp-system dan CRD dikelola oleh stackdriver , dengan flag enableGMPForApplications yang ditetapkan ke false oleh secara default. Jika Anda men-deploy komponen GMP secara manual di namespace sebelum mengupgrade ke versi 1.12, resource akan dihapus oleh stackdriver. Solusi: Cadangkan semua resource kustom (CR) PodMonitoring yang ada. Upgrade semua cluster ke versi 1.12, dan aktifkan Managed Service for Prometheus. Deploy ulang CR PodMonitoring.
Operasi	1.11, 1.12, 1.13.0 - 1.13.1	Objek ClusterAPI tidak ada dalam skenario system snapshot cluster Dalam skenario system, snapshot cluster tidak menyertakan resource apa pun pada namespace default. Namun, beberapa resource Kubernetes seperti objek Cluster API yang ada di bawah 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 dalam hal ini: USER_CLUSTER_KUBECONFIG adalah cluster pengguna {i>kubeconfig<i}.
Upgrade, Update	1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1	Penghapusan cluster pengguna terhenti di pengurasan node untuk penyiapan vSAN Saat menghapus, mengupdate, atau mengupgrade cluster pengguna, node pengosongan mungkin macet dalam skenario berikut: Cluster admin telah menggunakan driver vSphere CSI pada 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 gejala, 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 dapat mengalami bug yang menyebabkan node pengurasan akan terhenti dalam menemukan kubevols, karena implementasi saat ini mengasumsikan bahwa kubevols selalu ada. Solusi: Buat direktori kubevols di datastore tempat node dibuat. Ini ditentukan di kolom vCenter.datastore dalam file user-cluster.yaml atau admin-cluster.yaml.
Konfigurasi	1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14	Cluster Autoscaler clusterrolebinding dan clusterrole dihapus setelah menghapus cluster pengguna. Saat penghapusan cluster pengguna, clusterrole dan clusterrolebinding yang sesuai untuk autoscaler cluster juga akan dihapus. Hal ini memengaruhi semua cluster pengguna lainnya di cluster admin yang sama yang mengaktifkan autoscaler cluster. Hal ini karena clusterrole dan clusterrolebinding yang sama digunakan untuk semua pod autoscaler cluster dalam cluster admin yang sama. Gejalanya adalah sebagai berikut: cluster-autoscaler log kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \ cluster-autoscaler dengan ADMIN_CLUSTER_KUBECONFIG adalah cluster admin {i>kubeconfig<i}. 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: Lihat langkah-langkah solusi Periksa apakah clusterrole dan clusterrolebinding hilang 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	cluster admin cluster-health-controller dan vsphere-metrics-exporter tidak berfungsi setelah menghapus cluster pengguna Saat penghapusan cluster pengguna, clusterrole yang sesuai juga akan dihapus, yang mengakibatkan perbaikan otomatis dan pengekspor metrik vsphere tidak berfungsi Gejalanya adalah sebagai berikut: cluster-health-controller log kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \ cluster-health-controller dengan ADMIN_CLUSTER_KUBECONFIG adalah cluster admin {i>kubeconfig<i}. Berikut adalah contoh pesan error yang mungkin Anda lihat: error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found vsphere-metrics-exporter log kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \ vsphere-metrics-exporter dengan ADMIN_CLUSTER_KUBECONFIG adalah cluster admin {i>kubeconfig<i}. 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: Lihat langkah-langkah 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	gkectl check-config gagal saat validasi image OS Masalah umum yang dapat menggagalkan gkectl check-config tanpa menjalankan gkectl prepare. Hal ini membingungkan karena sebaiknya jalankan perintah sebelum menjalankan gkectl prepare Gejalanya adalah perintah gkectl check-config akan gagal dengan pesan error berikut: Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]} Solusi: Opsi 1: jalankan gkectl prepare untuk mengupload OS image yang tidak ada. Opsi 2: gunakan gkectl check-config --skip-validation-os-images untuk melewati validasi image OS.
Upgrade, Update	1.11, 1.12, 1.13	gkectl update admin/cluster gagal memperbarui grup anti Masalah umum yang dapat menggagalkan gkectl update admin/cluster saat mengupdate anti affinity groups. Gejalanya adalah perintah gkectl update akan gagal dengan pesan error berikut: Waiting for machines to be re-deployed... ERROR Exit with error: Failed to update the cluster: timed out waiting for the condition Solusi: Lihat langkah-langkah solusi Agar update dapat diterapkan, mesin harus dibuat ulang after update yang gagal. Untuk update cluster admin, node add-on admin dan master pengguna harus dibuat ulang Untuk update cluster pengguna, node pekerja pengguna harus dibuat ulang Untuk membuat ulang node pekerja pengguna Opsi 1 Ikuti cara memperbarui kumpulan node dan mengubah CPU atau memori untuk memicu pembuatan ulang node secara berkelanjutan. 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 Ikuti mengubah ukuran bidang kontrol dan ubah CPU atau memori untuk memicu pembuatan ulang node secara berkelanjutan. 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 Menggunakan 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	Node gagal didaftarkan jika nama host yang dikonfigurasi berisi titik Pendaftaran node gagal selama pembuatan, upgrade, update, dan perbaikan otomatis node, jika ipMode.type adalah static dan nama host yang dikonfigurasi di File blok IP berisi satu atau lebih titik. Dalam hal ini, Permintaan Penandatanganan Sertifikat (CSR) untuk node tidak disetujui secara otomatis. Untuk melihat CSR yang tertunda untuk sebuah node, jalankan perintah berikut: kubectl get csr -A -o wide Periksa log berikut untuk 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 berikut: kubectl logs clusterapi-controllers-POD_NAME \ -c clusterapi-controller-manager -n USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG dalam hal ini: ADMIN_CLUSTER_KUBECONFIG adalah milik cluster admin {i>kubeconfig<i}. USER_CLUSTER_NAME adalah nama cluster pengguna. Berikut adalah contoh pesan error yang mungkin Anda lihat: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9" Lihat log kubelet pada node yang bermasalah: journalctl --u kubelet Berikut adalah contoh pesan error yang mungkin Anda lihat: "Error getting node" err="node \"node-worker-vm-1\" not found" Jika Anda menentukan nama domain di ruang isian {i>host <i}dari file blok IP, karakter apa pun setelah titik pertama akan diabaikan. Misalnya, jika Anda menentukan nama host sebagai bob-vm-1.bank.plc, VM nama host dan nama node akan ditetapkan ke bob-vm-1. Bila verifikasi ID node diaktifkan, pemberi persetujuan CSR akan membandingkan nama node dengan nama host di spesifikasi Perangkat, dan gagal merekonsiliasi namanya. Pemberi persetujuan menolak CSR, dan node gagal kerangka kerja internal. Solusi: Cluster pengguna Nonaktifkan verifikasi ID node dengan menyelesaikan langkah-langkah berikut: Tambahkan kolom berikut di file konfigurasi cluster pengguna Anda: disableNodeIDVerification: true disableNodeIDVerificationCSRSigning: true Simpan file, dan perbarui cluster pengguna dengan menjalankan perintah berikut berikut: gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE Ganti yang berikut: ADMIN_CLUSTER_KUBECONFIG: jalur pada file kubeconfig cluster admin. USER_CLUSTER_CONFIG_FILE: jalur dari file konfigurasi cluster pengguna Anda. Cluster Admin Buka resource kustom OnPremAdminCluster untuk pengeditan: kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ edit onpremadmincluster -n kube-system Tambahkan anotasi berikut ke resource kustom: features.onprem.cluster.gke.io/disable-node-id-verification: enabled Mengedit manifes kube-controller-manager di admin bidang kontrol cluster: SSH ke dalam node bidang kontrol cluster admin. Buka manifes kube-controller-manager untuk pengeditan: sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml Temukan daftar controllers: --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning Perbarui bagian ini seperti yang ditunjukkan di bawah: --controllers=*,bootstrapsigner,tokencleaner Buka pengontrol Deployment Cluster API untuk mengedit: kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ edit deployment clusterapi-controllers -n kube-system Ubah nilai node-id-verification-enabled dan node-id-verification-csr-signing-enabled hingga false: --node-id-verification-enabled=false --node-id-verification-csr-signing-enabled=false
Penginstalan, Upgrade, Update	1.11.0-1.11.4	Kegagalan startup mesin bidang kontrol admin yang disebabkan oleh registry pribadi paket sertifikat Pembuatan/upgrade cluster admin terhenti di log berikut selamanya dan akhirnya waktunya habis: Waiting for Machine gke-admin-master-xxxx to become ready... Log pengontrol Cluster API di snapshot cluster eksternal menyertakan log berikut: Invalid value 'XXXX' specified for property startup-data Berikut adalah contoh jalur file untuk log pengontrol Cluster API: kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps VMware has a 64k vApp property size limit. In the identified versions, the data passed via vApp property is close to the limit. When the private registry certificate contains a certificate bundle, it may cause the final data to exceed the 64k limit. Workaround: Only include the required certificates in the private registry certificate file configured in privateRegistry.caCertPath in the admin cluster config file. Or upgrade to a version with the fix when available.
Networking	1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0	NetworkGatewayNodes marked unhealthy from concurrent status update conflict 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 mengambang tambahan ke {i>node<i}. Hal ini dapat mengakibatkan beban pada {i>node <i}lain atau kurangnya redundansi untuk ketersediaan tinggi. Aktivitas Dataplane tidak akan terpengaruh. Pertentangan pada objek networkgatewaygroup menyebabkan beberapa pembaruan status gagal karena terjadi kesalahan dalam penanganan percobaan ulang. Jika terlalu banyak update status gagal, ang-controller-manager akan melihat node sebagai melewati batas waktu detak jantungnya dan menandai node NotHealthy. Kesalahan dalam penanganan percobaan ulang telah diperbaiki di versi yang lebih baru. Solusi: Upgrade ke versi tetap, jika tersedia.
Upgrade, Update	1.12.0-1.12.2, 1.13.0	Kondisi race memblokir penghapusan objek mesin selama dan pembaruan atau upgrade Masalah umum yang dapat menyebabkan upgrade atau update cluster macet saat menunggu objek mesin lama untuk dihapus. Hal ini karena finaler tidak dapat dihapus dari objek mesin. Hal ini memengaruhi semua operasi update berkelanjutan untuk kumpulan node. Gejalanya adalah waktu 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. Di clusterapi-controller log Pod, 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 {i>Error <i}terulang untuk komputer yang sama selama beberapa menit untuk berhasil bahkan tanpa masalah ini, hampir selalu dapat dilakukan dengan cepat, tetapi untuk beberapa kasus yang jarang terjadi, error ini dapat terhenti di proses ini selama beberapa jam. Masalahnya adalah VM yang mendasarinya sudah dihapus di vCenter, tetapi objek mesin terkait tidak dapat dihapus, yang macet di penghapusan finaler karena pembaruan yang sangat sering dari {i>controller<i} lain. Hal ini dapat menyebabkan waktu tunggu perintah gkectl habis, tetapi pengontrol terus merekonsiliasi cluster sehingga proses upgrade atau update pada akhirnya akan 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 pada akhirnya itu sendiri. Berdasarkan analisis dan reproduksi di lingkungan Anda, upgrade pada akhirnya dapat selesai dengan sendirinya tanpa intervensi manual apa pun. Tujuan peringatan dari opsi ini adalah bahwa tidak ada pasti berapa lama waktu yang dibutuhkan penghapusan finaler yang akan dilakukan untuk setiap objek mesin. Bisa Segera jika cukup beruntung, atau bisa berlangsung selama beberapa jam jika rekonsiliasi pengontrol {i> machineset<i} terlalu cepat dan komputer {i>controller<i} tidak pernah mendapat kesempatan untuk menghapus finaler di antara rekonsiliasi. Untungnya, opsi ini tidak memerlukan tindakan apa pun dari tambahan, dan beban kerja tidak akan terganggu. Hanya perlu waktu yang lebih lama untuk menyelesaikan upgrade. Opsi 2: Terapkan anotasi perbaikan otomatis ke semua perangkat lama objek terstruktur dalam jumlah besar. Pengontrol {i>machineset<i} akan memfilter komputer yang memiliki anotasi perbaikan otomatis dan stempel waktu penghapusan bukan nol, dan tidak akan terus mengeluarkan panggilan hapus pada komputer tersebut, hal ini dapat membantu menghindari kondisi race. Kelemahannya adalah pod pada komputer akan langsung dihapus bukannya dikeluarkan, yang berarti ia tidak akan menghormati konfigurasi PDB, hal ini berpotensi menyebabkan periode nonaktif untuk beban kerja Anda. Perintah untuk mendapatkan semua nama mesin: kubectl --kubeconfig CLUSTER_KUBECONFIG get machines Perintah untuk menerapkan anotasi perbaikan otomatis untuk setiap mesin: kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \ machine MACHINE_NAME \ onprem.cluster.gke.io/repair-machine=true Jika Anda mengalami masalah ini dan upgrade atau update masih tidak dapat diselesaikan setelah sekian lama, kontak tim dukungan kami untuk melakukan mitigasi.
Penginstalan, Upgrade, Update	1.10.2, 1.11, 1.12, 1.13	gkectl menyiapkan kegagalan preflight validasi image OS Perintah gkectl prepare gagal dengan: - Validation Category: OS Images - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images. Pemeriksaan preflight gkectl prepare mencakup validasi yang salah. Solusi: Jalankan perintah yang sama dengan flag tambahan --skip-validation-os-images.
Penginstalan	1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13	URL vCenter dengan awalan https:// atau http:// dapat menyebabkan kegagalan startup cluster Cluster admin gagal dibuat karena: 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 dukung "/" atau ":". Solusi: Hapus awalan https:// atau http:// dari Kolom vCenter.Address di cluster admin atau cluster pengguna konfigurasi yaml.
Penginstalan, Upgrade, Update	1.10, 1.11, 1.12, 1.13	gkectl prepare panik di util.CheckFileExists gkectl prepare dapat panik dengan hal berikut stacktrace: 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 {i>registry<i} dengan izin yang salah. Solusi: Untuk memperbaiki masalah ini, jalankan perintah berikut pada admin workstation: 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	Upgrade admin yang dapat dilanjutkan dan gkectl repair admin-master adalah tidak bekerja sama Setelah upaya upgrade cluster admin gagal, jangan jalankan gkectl repair admin-master. Tindakan ini dapat menyebabkan upgrade admin berikutnya upaya untuk gagal dengan masalah seperti daya master admin gagal atau VM tidak dapat diakses. Solusi: Jika Anda pernah mengalami skenario kegagalan ini, hubungi dukungan.
Upgrade, Update	1.10, 1.11	Upgrade cluster admin yang dilanjutkan dapat menyebabkan bidang kontrol admin tidak ada Template VM Jika mesin bidang kontrol admin tidak dibuat ulang setelah dilanjutkan upaya upgrade cluster admin, template VM bidang kontrol admin dihapus. Template VM bidang kontrol admin adalah template admin yang digunakan untuk memulihkan mesin bidang kontrol dengan gkectl repair admin-master Solusi: Template VM bidang kontrol admin akan dibuat ulang selama upgrade cluster admin.
Sistem operasi	1,12, 1,13	cgroup v2 dapat memengaruhi workload Di versi 1.12.0, cgroup v2 (terpadu) diaktifkan secara {i>default<i} untuk Node OS yang Dioptimalkan untuk Container (COS). Hal ini berpotensi menimbulkan ketidakstabilan untuk beban kerja Anda dalam klaster COS. Solusi: Kami beralih kembali ke cgroup v1 (hybrid) di versi 1.12.1. Jika Anda menggunakan node COS, sebaiknya segera tingkatkan ke versi 1.12.1 saat dirilis.
Identitas	1.10, 1.11, 1.12, 1.13	Resource kustom ClientConfig gkectl update mengembalikan perubahan manual yang Anda miliki yang dibuat ke resource kustom ClientConfig. Solusi: Kami sangat menyarankan agar Anda mencadangkan resource ClientConfig setelah setiap perubahan manual.
Penginstalan	1.10, 1.11, 1.12, 1.13	Validasi gkectl check-config gagal: tidak dapat menemukan F5 Partisi BIG-IP Validasi gagal karena partisi F5 BIG-IP tidak dapat ditemukan, bahkan meskipun mereka ada. Masalah dengan F5 BIG-IP API dapat menyebabkan validasi gagal. Solusi: Coba jalankan gkectl check-config lagi.
Penginstalan	1.12	Penginstalan cluster pengguna gagal karena perintah cert-manager/ca-injector masalah pemilu pemimpin Anda mungkin melihat kegagalan instalasi 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: Lihat langkah-langkah solusi Jalankan perintah berikut untuk memitigasi masalah. Pertama, perkecil monitoring-operator agar tidak kembalikan 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 punya satu replika yang berjalan. Tidak yang 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 cert-manager-cainjector deployment 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 ... Mempertahankan monitoring-operator replika pada 0 sebagai mitigasi hingga penginstalan selesai. Jika tidak, perubahan akan dikembalikan. Setelah instalasi 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 hal yang sama langkah lagi untuk memitigasi masalah hingga masalah ini diperbaiki di masa mendatang data.
VMware	1.10, 1.11, 1.12, 1.13	Memulai ulang atau mengupgrade vCenter untuk versi yang lebih rendah dari 7.0U2 Jika vCenter, untuk versi yang lebih rendah dari 7.0U2, dimulai ulang, setelah atau jika tidak, nama jaringan dalam informasi vm dari vCenter adalah salah, dan menyebabkan komputer menggunakan Unavailable status. Hal ini pada akhirnya menyebabkan node otomatis diperbaiki yang baru. Govmomi terkait bug. Solusi: Solusi ini disediakan oleh dukungan VMware: Masalah ini telah diperbaiki di vCenter versi 7.0U2 dan yang lebih baru. Untuk versi yang lebih rendah, klik kanan host, lalu pilih Koneksi > Putuskan koneksi. Berikutnya, hubungkan kembali, yang memaksa update dari grup port VM.
Sistem operasi	1.10, 1.11, 1.12, 1.13	Koneksi SSH ditutup oleh host jarak jauh Untuk Google Distributed Cloud versi 1.7.2 dan yang lebih baru, Ubuntu OS gambar diperkuat dengan Tolok Ukur Server CIS L1. Untuk memenuhi aturan CIS "5.2.16 Pastikan SSH Idle Timeout Interval adalah dikonfigurasi", /etc/ssh/sshd_config memiliki hal berikut pengaturan: ClientAliveInterval 300 ClientAliveCountMax 0 Tujuan setelan ini adalah untuk menghentikan sesi klien setelah 5 menit waktu tidak ada aktivitas. Namun, ClientAliveCountMax 0 nilai tersebut menyebabkan perilaku yang tidak diharapkan. Saat Anda menggunakan sesi ssh pada atau node cluster, koneksi SSH mungkin memutuskan hubungan bahkan klien ssh Anda tidak menganggur, seperti saat menjalankan memakan waktu lama, dan perintah Anda bisa dihentikan dengan pesan berikut: Connection to [IP] closed by remote host. Connection to [IP] closed. Solusi: Anda dapat: Gunakan nohup agar perintah Anda tidak dihentikan pemutusan SSH, nohup gkectl upgrade admin --config admin-cluster.yaml \ --kubeconfig kubeconfig Update sshd_config untuk menggunakan bilangan bukan nol Nilai ClientAliveCountMax. Aturan CIS menyarankan 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 Anda.
Penginstalan	1.10, 1.11, 1.12, 1.13	Penginstalan cert-manager bertentangan Dalam rilis 1.13, monitoring-operator akan menginstal cert-manager di namespace cert-manager. Jika untuk tertentu alasan, Anda perlu menginstal pengelola sertifikat Anda sendiri, petunjuk untuk menghindari konflik: Anda hanya perlu menerapkan solusi ini sekali untuk setiap cluster, dan perubahan akan dipertahankan di seluruh upgrade cluster. Catatan: Satu gejala umum saat menginstal pengelola sertifikat Anda sendiri adalah versi atau image cert-manager (misalnya v1.7.2) dapat dikembalikan ke versi lamanya. Hal ini disebabkan oleh monitoring-operator mencoba merekonsiliasi cert-manager, dan mengembalikan versi dalam proses. Solusi: <pMenghindari konflik selama upgrade Uninstal versi cert-manager Anda. Jika Anda menentukan sumber daya Anda sendiri, Anda mungkin ingin cadangan mereka. Lakukan upgrade. Ikuti petunjuk berikut untuk memulihkan sandi Anda sendiri cert-manager. Memulihkan pengelola sertifikat Anda sendiri di cluster pengguna Skalakan Deployment monitoring-operator ke 0: kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n USER_CLUSTER_NAME \ scale deployment monitoring-operator --replicas=0 Skalakan deployment cert-manager yang dikelola oleh monitoring-operator hingga 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 jika ada. Anda dapat melewati langkah ini jika menggunakan penginstalan pengelola sertifikat default upstream, atau Anda yakin cert-manager diinstal di namespace cert-manager. Jika tidak, salin cert-manager.io/v1 metrics-ca Sertifikat dan Penerbit metrics-pki.cluster.local resource dari cert-manager ke resource cluster namespace dari pengelola sertifikat yang terinstal. relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f1=$(mktemp) f2=$(mktemp) kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get issuer -n cert-manager metrics-pki.cluster.local -o json \ | jq "${relevant_fields}" > $f1 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get certificate -n cert-manager metrics-ca -o json \ | jq "${relevant_fields}" > $f2 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2 Memulihkan pengelola sertifikat Anda sendiri di cluster admin Secara umum, Anda tidak perlu menginstal ulang cert-manager di admin karena cluster admin hanya menjalankan kontrol Google Distributed Cloud workload berbasis platform. Dalam kasus yang jarang terjadi, Anda juga perlu menginstal cert-manager di cluster admin, ikuti petunjuk berikut untuk menghindari konflik. Perlu diperhatikan, jika Anda adalah pelanggan Apigee dan Anda hanya memerlukan cert-manager untuk Apigee, Anda tidak perlu menjalankan admin menggunakan perintah cluster. 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 hingga 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 jika ada. Anda dapat melewati langkah ini jika menggunakan penginstalan pengelola sertifikat default upstream, atau Anda yakin cert-manager diinstal di namespace cert-manager. Jika tidak, salin cert-manager.io/v1 metrics-ca Sertifikat dan Penerbit metrics-pki.cluster.local resource dari cert-manager ke resource cluster namespace dari pengelola sertifikat yang terinstal. 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 &lt;/p
Sistem operasi	1.10, 1.11, 1.12, 1.13	Positif palsu dalam pemindaian kerentanan Docker, containerd, dan runc Docker, {i>containerd<i}, dan runc di {i>image<i} OS Ubuntu yang dikirimkan bersama Google Distributed Cloud disematkan ke versi khusus menggunakan PPA Ubuntu. Hal ini memastikan bahwa setiap perubahan runtime container akan memenuhi syarat oleh Google Distributed Cloud sebelum setiap rilis. Namun, versi khusus tidak dikenal oleh CVE Ubuntu Tracker, yang digunakan sebagai feed kerentanan oleh berbagai CVE alat pemindaian. Oleh karena itu, Anda akan melihat positif palsu (PP) di Docker, hasil pemindaian kerentanan containerd dan runc. Misalnya, Anda mungkin melihat positif palsu berikut dari CVE hasil pemindaian. CVE ini sudah diperbaiki di patch terbaru versi baru Google Distributed Cloud. CVE-2019-16884 CVE-2019-19921 CVE-2020-15157 CVE-2020-15257 Lihat catatan rilis] untuk perbaikan CVE. Solusi: Kanonis mengetahui masalah ini, dan perbaikan dilacak di https://github.com/canonical/sec-cvescan/issues/73.
Upgrade, Update	1.10, 1.11, 1.12, 1.13	Koneksi jaringan antara admin dan cluster pengguna mungkin tidak tersedia dalam waktu singkat selama upgrade cluster non-HA Jika Anda meningkatkan cluster non-HA dari 1,9 ke 1,10, Anda mungkin melihat bahwa kubectl exec, kubectl log, dan webhook terhadap klaster pengguna mungkin tidak tersedia untuk waktu yang singkat. Periode nonaktif ini dapat mencapai satu menit. Hal ini terjadi karena permintaan masuk (kubectl exec, kubectl log, dan webhook) ditangani oleh kube-apiserver untuk cluster pengguna. Pengguna kube-apiserver adalah Statefulset. Dalam cluster non-HA, hanya ada satu replika untuk Statefulset. Jadi selama peningkatan, ada kemungkinan bahwa versi kube-apiserver tidak tersedia saat kube-apiserver baru belum tersedia siap. Solusi: Periode nonaktif ini hanya terjadi selama proses upgrade. Jika Anda menginginkan lebih singkat selama peningkatan versi, sebaiknya Anda beralih ke HA cluster.
Penginstalan, Upgrade, Update	1.10, 1.11, 1.12, 1.13	Pemeriksaan kesiapan konektivitas gagal dalam diagnosis klaster HA setelah pembuatan atau upgrade cluster Jika Anda membuat atau mengupgrade klaster HA dan melihat konektivitas pemeriksaan kesiapan gagal saat didiagnosis cluster. Dalam kebanyakan kasus, hal ini tidak akan memengaruhi fungsi Google Distributed Cloud (kubectl exec, kubectl log dan webhook). Hal ini terjadi karena terkadang satu atau dua dari replika konektivitas mungkin tidak siap untuk jangka waktu tertentu karena jaringan yang tidak stabil atau masalah lainnya. Solusi: Konnektivitas akan pulih dengan sendirinya. Tunggu selama 30 menit hingga 1 jam dan menjalankan kembali diagnosis cluster.
Sistem operasi	1.7, 1.8, 1.9, 1.10, 1.11	/etc/cron.daily/aide masalah lonjakan CPU dan memori Mulai dari Google Distributed Cloud versi 1.7.2, OS Ubuntu gambar telah melalui proses hardening dengan Server CIS L1 Tolok ukur. Hasilnya, skrip cron /etc/cron.daily/aide telah diinstal sehingga pemeriksaan aide dijadwalkan untuk memastikan bahwa aturan Server CIS L1 “1.4.2 Memastikan integritas sistem file diperiksa secara rutin" diikuti. cron job berjalan setiap hari pada pukul 06.25 UTC. Tergantung jumlah pada sistem file, Anda mungkin mengalami lonjakan penggunaan CPU dan memori sekitar waktu tersebut yang disebabkan oleh proses aide ini. Solusi: Jika lonjakan memengaruhi beban kerja, Anda dapat menonaktifkan {i>cron job <i}(tugas cron): sudo chmod -x /etc/cron.daily/aide
Jaringan	1.10, 1.11, 1.12, 1.13	Load balancer dan aturan firewall terdistribusi stateful NSX-T berinteraksi tidak dapat diprediksi Saat men-deploy Google Distributed Cloud versi 1.9 atau yang lebih baru, saat deployment memiliki load balancer paket Seesaw di lingkungan yang menggunakan aturan {i>firewall<i} terdistribusi stateful NSX-T, stackdriver-operator mungkin gagal dibuat gke-metrics-agent-conf ConfigMap dan penyebabnya gke-connect-agent Pod akan berada dalam loop error. Masalah pokoknya adalah bahwa {i>firewall<i} stateful NSX-T menghentikan koneksi dari klien ke API cluster pengguna server melalui load balancer Seesaw karena Seesaw menggunakan alur koneksi. Masalah integrasi dengan firewall terdistribusi NSX-T memengaruhi semua rilis Google Distributed Cloud yang menggunakan Seesaw. Anda mungkin melihat masalah koneksi serupa pada aplikasi Anda saat membuat objek Kubernetes besar yang ukurannya lebih dari 32K. Solusi: Ikuti petunjuk ini untuk menonaktifkan aturan firewall terdistribusi NSX-T, atau menggunakan aturan firewall terdistribusi stateless untuk Seesaw VM. Jika cluster Anda menggunakan load balancer manual, ikuti petunjuk ini untuk mengonfigurasi load balancer Anda agar dapat menyetel ulang klien koneksi saat mendeteksi kegagalan node backend. Tanpa label ini klien server Kubernetes API mungkin berhenti merespons selama beberapa menit saat {i>instance<i} server mati.
Logging dan pemantauan	1.10, 1.11, 1.12, 1.13, 1.14, 1.15	Penagihan pemantauan yang tidak terduga Untuk Google Distributed Cloud versi 1.10 hingga 1.15, beberapa pelanggan memiliki menemukan tagihan tinggi yang tidak terduga untuk Metrics volume pada Halaman Penagihan. Masalah ini hanya mempengaruhi Anda ketika semua keadaan berikut berlaku: Logging dan pemantauan aplikasi diaktifkan (enableStackdriverForApplications=true) Pod Aplikasi memiliki prometheus.io/scrap=true anotasi. (Menginstal Cloud Service Mesh juga dapat menambahkan anotasi ini.) Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini atau tidak, cantumkan metrik buatan pengguna. Jika Anda melihat penagihan untuk metrik yang tidak diinginkan dengan awalan nama external.googleapis.com/prometheus dan juga melihat enableStackdriverForApplications ditetapkan ke benar sebagai respons dari kubectl -n kube-system get stackdriver stackdriver -o yaml, maka masalah ini terjadi pada Anda. Solusi Jika Anda terpengaruh oleh masalah ini, sebaiknya Anda mengupgrade cluster ke versi 1.12 atau yang lebih baru, hentikan penggunaan tanda enableStackdriverForApplications, dan beralihlah ke solusi pemantauan aplikasi baru managed-service-for-prometheus yang tidak lagi bergantung pada anotasi prometheus.io/scrap=true. Dengan solusi baru ini, Anda juga dapat mengontrol pengumpulan log dan metrik secara terpisah untuk aplikasi Anda, dengan flag enableCloudLoggingForApplications dan enableGMPForApplications. Untuk berhenti menggunakan tanda enableStackdriverForApplications, buka objek `stackdriver` untuk mengedit: kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver Hapus baris enableStackdriverForApplications: true, simpan dan tutup editor. Jika Anda tidak dapat beralih dari pengumpulan metrik berbasis anotasi, gunakan langkah-langkah berikut: Temukan Pod dan Service sumber yang memiliki metrik penagihan yang tidak diinginkan. kubectl --kubeconfig KUBECONFIG \ get pods -A -o yaml | grep 'prometheus.io/scrape: "true"' kubectl --kubeconfig KUBECONFIG get \ services -A -o yaml | grep 'prometheus.io/scrape: "true"' Hapus anotasi prometheus.io/scrap=true dari Pod atau Service. Jika anotasi ditambahkan oleh Cloud Service Mesh, pertimbangkan mengonfigurasi Cloud Service Mesh tanpa opsi Prometheus, atau menonaktifkan fitur Penggabungan Metrik Istio.
Penginstalan	1.11, 1.12, 1.13	Penginstal gagal saat membuat datadisk vSphere Penginstal Google Distributed Cloud dapat gagal jika peran khusus terikat di tingkat izin yang salah. Ketika pengikatan peran salah, membuat datadisk vSphere dengan govc mengalami hang dan disk dibuat dengan ukuran 0. Kepada memperbaiki masalah ini, Anda harus mengikat peran khusus di vSphere vCenter tingkat (root). Solusi: Jika Anda ingin mengikat peran khusus di tingkat DC (atau lebih rendah dari {i>root<i}), Anda juga harus mengikat peran {i>read-only<i} ke pengguna di {i>root<i} Tingkat vCenter. Untuk informasi selengkapnya tentang pembuatan peran, lihat Hak istimewa akun pengguna vCenter.
Logging dan pemantauan	1.9.0-1.9.4, 1.10.0-1.10.1	Traffic jaringan yang tinggi ke monitoring.googleapis.com Anda mungkin melihat lalu lintas jaringan yang tinggi ke monitoring.googleapis.com, bahkan dalam cluster baru yang belum memiliki yang dioptimalkan untuk workload pengguna. Masalah ini memengaruhi versi 1.10.0-1.10.1 dan versi 1.9.0-1.9.4. Ini Masalah telah diperbaiki dalam versi 1.10.2 dan 1.9.5. Solusi: Lihat langkah-langkah solusi Upgrade ke versi 1.10.2/1.9.5 atau yang lebih baru. Untuk mengurangi masalah ini pada versi sebelumnya: Perkecil skala `stackdriver-operator`: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system \ scale deployment stackdriver-operator --replicas=0 Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna file kubeconfig cluster. Buka ConfigMap gke-metrics-agent-conf untuk mengedit: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system \ edit configmap gke-metrics-agent-conf Tingkatkan interval pemeriksaan dari 0,1 detik menjadi 13 detik: processors: disk_buffer/metrics: backend_endpoint: https://monitoring.googleapis.com:443 buffer_dir: /metrics-data/nsq-metrics-metrics probe_interval: 13s retention_size_mib: 6144 disk_buffer/self: backend_endpoint: https://monitoring.googleapis.com:443 buffer_dir: /metrics-data/nsq-metrics-self probe_interval: 13s retention_size_mib: 200 disk_buffer/uptime: backend_endpoint: https://monitoring.googleapis.com:443 buffer_dir: /metrics-data/nsq-metrics-uptime probe_interval: 13s retention_size_mib: 200 Tutup sesi pengeditan. Ubah versi gke-metrics-agent DaemonSet menjadi 1.1.0-anthos.8: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system set image daemonset/gke-metrics-agent \ gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
Logging dan pemantauan	1.10, 1.11	gke-metrics-agent sering mengalami error CrashLoopBackOff Untuk Google Distributed Cloud versi 1.10 dan yang lebih baru, `gke-metrics-agent` DaemonSet sering mengalami error CrashLoopBackOff saat `enableStackdriverForApplications` ditetapkan ke `true` di `stackdriver` . Solusi: Untuk mengurangi masalah ini, nonaktifkan pengumpulan metrik aplikasi dengan menjalankan perintah berikut. Perintah ini tidak akan menonaktifkan pengumpulan log aplikasi. Untuk mencegah perubahan berikut tidak dikembalikan, turunkan skala stackdriver-operator: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system scale deploy stackdriver-operator \ --replicas=0 Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna file kubeconfig cluster. Buka ConfigMap gke-metrics-agent-conf untuk mengedit: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system edit configmap gke-metrics-agent-conf Di bagian services.pipelines, jadikan seluruh komentar sebagai komentar Bagian metrics/app-metrics: services: pipelines: #metrics/app-metrics: # exporters: # - googlecloud/app-metrics # processors: # - resource # - metric_to_resource # - infer_resource # - disk_buffer/app-metrics # receivers: # - prometheus/app-metrics metrics/metrics: exporters: - googlecloud/metrics processors: - resource - metric_to_resource - infer_resource - disk_buffer/metrics receivers: - prometheus/metrics Tutup sesi pengeditan. Mulai ulang DaemonSet gke-metrics-agent: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system rollout restart daemonset gke-metrics-agent
Logging dan pemantauan	1.11, 1.12, 1.13	Mengganti metrik yang tidak digunakan lagi di dasbor Jika metrik yang tidak digunakan lagi digunakan di dasbor OOTB, Anda akan melihat beberapa diagram kosong. Untuk menemukan metrik yang tidak digunakan lagi di Monitoring dasbor, jalankan perintah berikut: gcloud monitoring dashboards list > all-dashboard.json # find deprecated metrics cat all-dashboard.json | grep -E \ 'kube_daemonset_updated_number_scheduled\ |kube_node_status_allocatable_cpu_cores\ |kube_node_status_allocatable_pods\ |kube_node_status_capacity_cpu_cores' Metrik yang tidak digunakan lagi berikut harus dimigrasikan ke pengganti. Tidak digunakan lagi Penggantian 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 Menghapus "status node lokal GKE" di Google Cloud Monitoring dasbor. Instal ulang "status node lokal GKE" mengikuti petunjuk ini. Menghapus "Penggunaan node lokal GKE" di Google Cloud Monitoring dasbor. Instal ulang "Penggunaan node lokal GKE" mengikuti petunjuk ini. Menghapus "kondisi vm vSphere lokal GKE" di lapisan Dasbor pemantauan. Instal ulang "kondisi vm vSphere lokal GKE" mengikuti petunjuk ini. Penghentian ini terjadi karena upgrade agen kube-state-metrics dari v1.9 hingga v2.4, yang diperlukan untuk Kubernetes 1.22. Anda dapat mengganti semua yang tidak digunakan lagi kube-state-metrics metrik, yang memiliki awalan kube_, di dasbor kustom atau kebijakan pemberitahuan.
Logging dan pemantauan	1.10, 1.11, 1.12, 1.13	Data metrik tidak diketahui di Cloud Monitoring Untuk Google Distributed Cloud versi 1.10 dan yang lebih baru, data untuk cluster di Cloud Monitoring mungkin berisi metrik ringkasan yang tidak relevan entri seperti berikut: Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile Jenis metrik lain yang mungkin memiliki metrik ringkasan yang tidak relevan sertakan : 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, didukung oleh gke-metrics-agent saat ini.
Logging dan pemantauan	1.10, 1.11, 1.12, 1.13	Metrik tidak ada di beberapa node 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 solusinya. Sebagai [versi 1.9.5+, 1.10.2+, 1.11.0]: tingkatkan cpu untuk gke-metrics-agent dengan mengikuti langkah 1 - 4 Buka referensi stackdriver untuk mengedit: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system edit stackdriver stackdriver Untuk meningkatkan permintaan CPU gke-metrics-agent dari 10m hingga 50m, batas CPU dari 100m ke 200m tambahkan 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 Anda edit 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 Simpan perubahan Anda dan tutup editor teks. Untuk memastikan bahwa perubahan telah diterapkan, jalankan perintah berikut: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system get daemonset gke-metrics-agent -o yaml \ | grep "cpu: 50m" Perintah tersebut menemukan cpu: 50m jika hasil edit Anda telah diterapkan.
Logging dan pemantauan	1.11.0-1.11.2, 1.12.0	Metrik penjadwal dan pengontrol-pengelola tidak ada di cluster admin Jika cluster admin Anda terpengaruh oleh masalah ini, penjadwal dan Metrik pengontrol-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	Metrik penjadwal dan pengontrol-pengelola tidak ada di cluster pengguna Jika cluster pengguna Anda terpengaruh oleh masalah ini, penjadwal dan Metrik pengontrol-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: 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	Gagal mendaftarkan cluster admin selama pembuatan Jika Anda membuat cluster admin untuk versi 1.9.x atau 1.10.0, dan jika cluster admin gagal mendaftar dengan gkeConnect yang disediakan selama pembuatannya, Anda akan mendapatkan pesan 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 Anda mencoba mengupgrade cluster admin ke versi 1.10.y. failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" Solusi: Lihat langkah-langkah solusi Jika error ini terjadi, ikuti langkah-langkah berikut untuk memperbaiki cluster pendaftaran. Setelah melakukan perbaikan ini, Anda dapat mengupgrade admin . Jalankan gkectl update admin untuk mendaftarkan cluster admin dengan kunci akun layanan yang benar. Buat akun layanan khusus untuk mem-patch 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 admin Anda file kubeconfig cluster. Jalankan perintah ini untuk mengupdate OnPremAdminCluster resource kustom. 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 Coba upgrade cluster admin lagi dengan --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 admin Anda file konfigurasi cluster Anda.
Identitas	1.10, 1.11, 1.12, 1.13	Menggunakan GKE Identity Service dapat menyebabkan Hubungkan Agen untuk memulai ulang secara tidak terduga Jika Anda menggunakan Layanan Identitas GKE fitur untuk mengelola GKE Identity Service ClientConfig, Connect Agent mungkin dimulai ulang secara tiba-tiba. Solusi: Jika pernah mengalami masalah pada cluster yang ada, Anda dapat melakukannya salah satu hal berikut: Nonaktifkan GKE Identity Service. Jika Anda menonaktifkan GKE Identity Service, yang tidak akan menghapus layanan yang telah di-deploy Biner GKE Identity Service atau hapus ClientConfig. Untuk menonaktifkan GKE Identity Service, jalankan perintah ini: gcloud container fleet identity-service disable \ --project PROJECT_ID Ganti PROJECT_ID dengan ID cluster project host fleet. Update cluster ke versi 1.9.3 atau yang lebih baru, atau versi 1.10.1 atau nanti, untuk mengupgrade versi Connect Agent.
Jaringan	1.10, 1.11, 1.12, 1.13	Cisco ACI tidak berfungsi dengan Direct Server Return (DSR) Seesaw berjalan dalam mode DSR, dan secara default tidak berfungsi di Cisco ACI karena pembelajaran IP data-plane. Solusi: Solusi yang mungkin dilakukan adalah menonaktifkan pembelajaran IP dengan menambahkan IP Seesaw sebagai IP Virtual L4-L7 dalam Kebijakan Aplikasi Cisco Pengontrol Infrastruktur (APIC). Anda dapat mengkonfigurasi opsi L4-L7 Virtual IP dengan membuka Tenant > Profil Aplikasi > EPG aplikasi atau EPG uSeg. Gagal menonaktifkan pemelajaran IP akan mengakibatkan timbulnya titik akhir IP antara lokasi yang berbeda di fabric Cisco API.
VMware	1.10, 1.11, 1.12, 1.13	vSphere 7.0 Memperbarui 3 masalah VMWare baru-baru ini mengidentifikasi masalah kritis terkait Rilis vSphere 7.0 Pembaruan 3: vSphere ESXi 7.0 Pembaruan 3 (build 18644231) vSphere ESXi 7.0 Pembaruan 3a (build 18825058) vSphere ESXi 7.0 Pembaruan 3b (build 18905247) vSphere vCenter 7.0 Pembaruan 3b (build 18901211) Solusi: VMWare menghapus rilis ini. Anda harus mengupgrade ESXi dan vCenter Server ke versi yang lebih baru.
Sistem operasi	1.10, 1.11, 1.12, 1.13	Gagal memasang volume emptyDir sebagai exec ke dalam Pod yang berjalan pada node COS Untuk Pod yang berjalan pada node yang menggunakan image Container-Optimized OS (COS), Anda tidak dapat memasang volume emptyDir sebagai exec. Ini dipasang sebagai noexec dan Anda akan mendapatkan error berikut: exec user process caused: permission denied. Misalnya, Anda akan melihat jika Anda 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 Di Pod pengujian, jika Anda menjalankan mount | grep test-volume, opsi noexec akan muncul: /dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30) Solusi: Lihat langkah-langkah 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	Update replika kumpulan node cluster tidak berfungsi setelah penskalaan otomatis telah dinonaktifkan pada kumpulan node Replika kumpulan node tidak diupdate setelah penskalaan otomatis diaktifkan dan dinonaktifkan pada kumpulan node. Solusi: Menghapus cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size dan cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size anotasi dari deployment mesin untuk node pool yang sesuai.
Logging dan pemantauan	1.11, 1.12, 1.13	Dasbor pemantauan Windows menampilkan data dari cluster Linux Dari versi 1.11, pada dasbor pemantauan siap pakai, Dasbor status Pod Windows dan dasbor status node Windows juga ditampilkan data dari cluster Linux. Hal ini karena node Windows dan metrik Pod juga diekspos di cluster Linux.
Logging dan pemantauan	1.10, 1.11, 1.12	stackdriver-log-forwarder dalam CrashLoopBackOff yang konstan Untuk Google Distributed Cloud versi 1.10, 1.11, dan 1.12, stackdriver-log-forwarder DaemonSet mungkin memiliki CrashLoopBackOff error jika ada dan kerusakan log yang {i>buffer <i}pada {i>disk<i}. Solusi: Untuk mengurangi masalah ini, kita perlu membersihkan log {i>buffer<i} pada {i>node<i}. Untuk mencegah perilaku yang tidak terduga, turunkan skala stackdriver-log-forwarder: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna file kubeconfig cluster. Deploy DaemonSet pembersihan untuk membersihkan potongan 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 Untuk memastikan pembersihan DaemonSet telah membersihkan semua potongan, Anda dapat menjalankan perintah berikut. Output dari kedua perintah harus sama dengan nomor node Anda dalam 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 Hapus DaemonSet pembersihan: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system delete ds fluent-bit-cleanup Lanjutkan stackdriver-log-forwarder: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Logging dan pemantauan	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16	stackdriver-log-forwarder tidak mengirim log ke Cloud Logging Jika Anda tidak melihat log di Cloud Logging dari cluster, dan Anda perhatikan error berikut di log Anda: 2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0 2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk Sepertinya tingkat input log melebihi batas agen {i>logging<i}, yang menyebabkan stackdriver-log-forwarder tidak mengirim log. Masalah ini terjadi di semua versi Google Distributed Cloud. Solusi: Untuk mengurangi masalah ini, Anda perlu meningkatkan batas sumber daya di agen logging. Buka referensi stackdriver untuk mengedit: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system edit stackdriver stackdriver Untuk meningkatkan permintaan CPU stackdriver-log-forwarder , tambahkan 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 Anda edit 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 Simpan perubahan Anda dan tutup editor teks. Untuk memastikan bahwa perubahan telah diterapkan, jalankan perintah berikut: kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \ | grep "cpu: 1200m" Perintah tersebut menemukan cpu: 1200m jika hasil edit Anda telah diterapkan.
Keamanan	1.13	Layanan Kubelet tidak akan tersedia untuk sementara setelah NodeReady ada periode singkat ketika {i>node<i} siap, tetapi server kubelet sertifikat belum siap. kubectl exec dan kubectl logs tidak tersedia selama puluhan detik ini. Hal ini karena pemberi persetujuan sertifikat server baru memerlukan waktu melihat IP valid node yang diupdate. Masalah ini hanya memengaruhi sertifikat server kubelet, hal ini tidak akan berpengaruh Penjadwalan pod.
Upgrade, Update	1.12	Upgrade cluster admin sebagian tidak memblokir cluster pengguna baru upgrade 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 adalah tetap 1,10. Upgrade cluster pengguna ke 1.12 tidak akan diblokir oleh preflight apa pun pemeriksaan, dan gagal akibat masalah distorsi versi. Solusi: Selesaikan untuk mengupgrade cluster admin ke 1.11 terlebih dahulu, lalu upgrade cluster pengguna menjadi 1.12.
Penyimpanan	1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0	Datastore salah melaporkan ruang kosong yang tidak cukup Perintah gkectl diagnose cluster gagal dengan: Checking VSphere Datastore FreeSpace...FAILURE Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB Validasi dari ruang kosong datastore tidak boleh digunakan untuk kumpulan node cluster, dan telah ditambahkan di gkectl diagnose cluster tanpa sengaja. Solusi: Anda dapat mengabaikan pesan {i>error<i} atau melewatkan validasi menggunakan --skip-validation-infra.
Operasi, Jaringan	1.11, 1.12.0-1.12.1	Gagal menambahkan cluster pengguna baru saat cluster admin menggunakan MetalLB penyeimbang beban Anda mungkin tidak dapat menambahkan cluster pengguna baru jika cluster admin Anda adalah dengan konfigurasi load balancer MetalLB. Proses penghapusan cluster pengguna mungkin macet karena beberapa alasan yang mengakibatkan pembatalan validasi MatalLB ConfigMap. Tidak mungkin untuk menambahkan cluster pengguna baru dalam status ini. Solusi: Anda dapat menghapus paksa cluster pengguna Anda.
Penginstalan, Sistem operasi	1.10, 1.11, 1.12, 1.13	Gagal saat menggunakan Container-Optimized OS (COS) untuk cluster pengguna Jika osImageType menggunakan cos untuk admin cluster, dan saat gkectl check-config dieksekusi setelah admin pembuatan cluster dan sebelum pembuatan cluster pengguna, cluster akan gagal pada: Failed to create the test VMs: VM failed to get IP addresses on the network. VM pengujian dibuat untuk cluster pengguna check-config oleh default menggunakan osImageType yang sama dari cluster admin, dan saat ini VM uji belum kompatibel dengan COS. Solusi: Untuk menghindari pemeriksaan preflight lambat yang membuat VM pengujian, gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
Logging dan pemantauan	1.12.0-1.12.1	Grafana di cluster admin tidak dapat menjangkau cluster pengguna Masalah ini memengaruhi pelanggan yang menggunakan Grafana di cluster admin untuk memantau cluster pengguna di Google Distributed Cloud versi 1.12.0 dan 1.12.1. Error ini berasal dari ketidakcocokan sertifikat pushprox-client pada pengguna ke cluster yang diizinkan di server pushprox di cluster admin. Gejalanya adalah pushprox-client di cluster pengguna yang mencetak log error seperti hal berikut: level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\"" Solusi: Lihat langkah-langkah solusi lakukan langkah-langkah berikut: Menurunkan skala deployment operator pemantauan di cluster admin kube-system. kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --namespace kube-system scale deploy monitoring-operator \ --replicas=0 Mengedit ConfigMap pushprox-server-rbac-proxy-config di namespace admin cluster kube-system. kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --namespace kube-system edit cm pushprox-server-rbac-proxy-config Temukan baris principals untuk external-pushprox-server-auth-proxy pemroses dan benar principal_name untuk semua cluster pengguna dengan menghapus kube-system substring 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."}}}] Mulai ulang deployment pushprox-server di admin dan deployment pushprox-client pada cluster yang terpengaruh cluster pengguna: 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 Langkah sebelumnya akan menyelesaikan masalah tersebut. Setelah cluster diupgrade ke 1.12.2 dan yang lebih baru di mana masalah telah diperbaiki, tingkatkan admin cluster kube-system monitoring-operator agar dapat mengelola pipeline lagi. kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
Lainnya	1.11.3	gkectl repair admin-master tidak menyediakan VM {i>template<i} yang akan digunakan untuk pemulihan Perintah gkectl repair admin-master gagal dengan: Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support gkectl repair admin-master tidak dapat mengambil VM template yang akan digunakan untuk memperbaiki VM bidang kontrol admin jika VM bidang kontrol admin diakhiri dengan karakter t, m, p, atau l. Solusi: Jalankan kembali perintah dengan --skip-validation.
Logging dan pemantauan	1.11, 1.12, 1.13, 1.14, 1.15, 1.16	Kegagalan logging audit cloud karena izin ditolak Cloud Audit Logs memerlukan penyiapan izin khusus yang saat ini hanya dilakukan secara otomatis untuk cluster pengguna melalui GKE Hub. Sebaiknya Anda memiliki minimal satu cluster pengguna yang menggunakan cluster project ID dan akun layanan dengan cluster admin untuk Cloud Audit Logs sehingga cluster admin harus memiliki izin akses. Namun, jika cluster admin menggunakan project ID atau akun layanan yang berbeda dari cluster pengguna mana pun, log audit dari admin akan gagal dimasukkan ke Google Cloud. Gejalanya adalah rangkaian Permission Denied error dalam audit-proxy Pod di cluster admin. Solusi: Lihat langkah-langkah solusi Untuk mengatasi masalah ini, izin akses dapat disiapkan dengan berinteraksi dengan fitur Hub cloudauditlogging: Pertama, periksa apakah akun layanan yang ada dan diizinkan 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 Bergantung pada responsnya, lakukan salah satu hal berikut: Jika Anda menerima error 404 Not_found, artinya tidak ada akun layanan yang diizinkan untuk project ID ini. Anda dapat mengizinkan akun layanan dengan mengaktifkan cloudauditlogging Fitur Hub: 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, ini berarti ada akun layanan yang diizinkan untuk project ini, Anda dapat menggunakan akun layanan dari daftar ini di cluster Anda, atau tambahkan 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 selesaikan masalah di kolom description respons, atau mencadangkan daftar yang diizinkan saat ini, hapus fitur hub cloudauditlogging, dan aktifkan kembali setelah langkah 1 bagian ini lagi. Anda dapat menghapus cloudauditlogging Fitur penghubung 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: Ganti PROJECT_ID dengan cluster project logging audit Anda. Ganti SERVICE_ACCOUNT_EMAIL dengan alamat email tersebut dari akun layanan logging audit.
Operasi, Keamanan	1,11	gkectl diagnose kegagalan pemeriksaan sertifikat Jika stasiun kerja Anda tidak memiliki akses ke node pekerja cluster pengguna, fungsi ini akan mengalami kegagalan seperti berikut saat menjalankan gkectl diagnose: Checking user cluster certificates...FAILURE Reason: 3 user cluster certificates error(s). Unhealthy Resources: Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out Jika stasiun kerja Anda tidak memiliki akses ke node pekerja cluster admin atau node pekerja cluster admin, ia akan mengalami kegagalan berikut saat menjalankan gkectl diagnose: Checking admin cluster certificates...FAILURE Reason: 3 admin cluster certificates error(s). Unhealthy Resources: Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out Solusi: Jika aman untuk mengabaikan pesan ini.
Sistem operasi	1.8, 1.9, 1.10, 1.11, 1.12, 1.13	/var/log/audit/ mengisi ruang disk di VM /var/log/audit/ diisi dengan log audit. Anda dapat memeriksa penggunaan disk dengan menjalankan sudo du -h -d 1 /var/log/audit. Perintah gkectl tertentu di workstation admin, untuk contoh, gkectl diagnose snapshot berkontribusi pada kapasitas disk tingkat penggunaan. Sejak Google Distributed Cloud v1.8, image Ubuntu telah di-hardening dengan CIS Level 2 {i>Benchmark<i}. Dan salah satu aturan kepatuhan, "4.1.2.2 Memastikan log audit tidak dihapus secara otomatis", memastikan setelan yang diaudit max_log_file_action = keep_logs. Hal ini menghasilkan semua audit yang disimpan pada {i>disk<i}. Solusi: Lihat langkah-langkah solusi Stasiun kerja admin Untuk workstation admin, Anda dapat secara manual mengubah status untuk merotasi log secara otomatis, lalu memulai ulang proses audit layanan: 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 log yang diaudit secara otomatis dirotasi setelah menghasilkan lebih dari 250 file (masing-masing berukuran 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: / Perlu diketahui bahwa perubahan konfigurasi yang diaudit ini akan melanggar CIS Level 2 aturan "4.1.2.2 Memastikan log audit tidak dihapus secara otomatis".
Jaringan	1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0	NetworkGatewayGroup IP mengambang bentrok dengan node Anda Pengguna tidak dapat membuat atau mengupdate 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" Dalam versi yang terdampak, kubelet dapat keliru mengikat ke IP mengambang yang ditetapkan ke node dan melaporkannya sebagai alamat node di node.status.addresses. Webhook yang memvalidasi akan memeriksa NetworkGatewayGroup alamat IP mengambang terhadap semua node.status.addresses dalam cluster dan melihatnya sebagai konflik. Solusi: Dalam cluster yang sama tempat pembuatan atau update Objek NetworkGatewayGroup gagal, nonaktifkan untuk sementara webhook yang memvalidasi ANG dan mengirimkan perubahan Anda: Simpan konfigurasi webhook agar dapat dipulihkan di bagian akhir: kubectl -n kube-system get validatingwebhookconfiguration \ ang-validating-webhook-configuration -o yaml > webhook-config.yaml Edit konfigurasi webhook: kubectl -n kube-system edit validatingwebhookconfiguration \ ang-validating-webhook-configuration Hapus item vnetworkgatewaygroup.kb.io dari dan hampir menerapkan perubahan. Buat atau edit objek NetworkGatewayGroup Anda. Terapkan ulang konfigurasi webhook asli: kubectl -n kube-system apply -f webhook-config.yaml
Penginstalan, Upgrade, Update	1.10.0-1.10.2	Waktu tunggu pembuatan atau upgrade cluster admin telah habis Selama upaya upgrade cluster admin, VM bidang kontrol admin mungkin macet selama pembuatan. VM bidang kontrol admin masuk ke antrean tak terbatas selama booting, dan Anda akan melihat error loop tak terbatas di /var/log/cloud-init-output.log file: + echo 'waiting network configuration is applied' waiting network configuration is applied ++ get-public-ip +++ ip addr show dev ens192 scope global +++ head -n 1 +++ grep -v 192.168.231.1 +++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}' +++ awk '{print $2}' ++ echo + '[' -n '' ']' + sleep 1 + echo 'waiting network configuration is applied' waiting network configuration is applied ++ get-public-ip +++ ip addr show dev ens192 scope global +++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}' +++ awk '{print $2}' +++ grep -v 192.168.231.1 +++ head -n 1 ++ echo + '[' -n '' ']' + sleep 1 Hal ini terjadi karena saat Google Distributed Cloud mencoba mendapatkan node IP di skrip startup, kode ini menggunakan grep -v ADMIN_CONTROL_PLANE_VIP untuk melewati VIP bidang kontrol cluster admin yang juga dapat ditugaskan ke NIC. Namun, perintah itu juga melewati alamat IP apa pun yang memiliki awalan VIP bidang kontrol, yang menyebabkan skrip startup menjadi hang. Misalnya, anggaplah VIP bidang kontrol admin cluster 192.168.1.25. Jika alamat IP VM bidang kontrol cluster admin memiliki awalan yang sama, misalnya,192.168.1.254, maka VM bidang kontrol akan terhambat selama pembuatan. Masalah ini juga dapat terpicu jika memiliki imbuhan yang sama dengan VIP bidang kontrol, contoh, 192.168.1.255. Solusi: Jika alasan waktu tunggu pembuatan cluster admin telah habis alamat IP siaran, jalankan perintah berikut di cluster admin VM bidang kontrol: ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192 Ini akan membuat baris tanpa alamat siaran, dan membatalkan pemblokiran proses {i>booting<i}. Setelah skrip startup dibatalkan pemblokirannya, hapus ini baris yang ditambahkan dengan menjalankan perintah berikut: ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192 Namun, jika alasan waktu tunggu pembuatan cluster admin telah habis ke alamat IP VM bidang kontrol, Anda tidak dapat berhenti memblokir skrip startup. Beralihlah ke alamat IP lain, dan buat ulang atau upgrade ke versi 1.10.3 atau yang lebih baru.
Sistem operasi, Peningkatan Versi, Pembaruan	1.10.0-1.10.2	Status cluster admin yang menggunakan image COS akan hilang pada upgrade cluster admin atau perbaikan master admin DataDisk tidak dapat dipasang dengan benar ke node master cluster admin saat menggunakan gambar COS dan status cluster admin yang menggunakan gambar COS akan tersesat saat upgrade cluster admin atau perbaikan master admin. (cluster admin menggunakan gambar COS adalah fitur pratinjau) Solusi: Buat ulang cluster admin dengan osImageType yang disetel ke ubuntu_containerd Setelah Anda membuat cluster admin dengan osImageType yang disetel ke cos, ambil kunci SSH cluster admin dan SSH ke node master admin. Hasil df -h berisi /dev/sdb1 98G 209M 93G 1% /opt/data. Dan lsblk hasil berisi -sdb1 8:17 0 100G 0 part /opt/data
Sistem operasi	1.10	pencarian DNS gagal yang diselesaikan oleh sistem pada .local domain Di Google Distributed Cloud versi 1.10.0, resolusi nama di Ubuntu dirutekan ke pemrosesan lokal yang diselesaikan oleh sistem di 127.0.0.53 secara {i>default<i}. Alasannya adalah bahwa pada {i>image<i} Ubuntu 20.04 yang digunakan dalam versi 1.10.0, /etc/resolv.conf ditautkan secara symlink ke /run/systemd/resolve/stub-resolv.conf, yang menunjukkan 127.0.0.53 stub DNS localhost. Akibatnya, resolusi nama DNS {i>localhost<i} menolak untuk memeriksa server DNS upstream (ditentukan di /run/systemd/resolve/resolv.conf) untuk nama dengan Akhiran .local, kecuali jika nama ditentukan sebagai penelusuran domain. Hal ini menyebabkan pencarian nama .local gagal. Sebagai misalnya, saat startup node, kubelet gagal mengambil gambar dari registry pribadi dengan akhiran .local. Menetapkan Alamat vCenter dengan akhiran .local tidak akan berfungsi di komputer admin. Solusi: Anda dapat menghindari masalah ini untuk node cluster jika Anda menentukan Kolom searchDomainsForDNS di konfigurasi cluster admin Anda dan file konfigurasi cluster pengguna untuk menyertakan domain. Saat ini gkectl update tidak mendukung pembaruan Kolom searchDomainsForDNS. Oleh karena itu, jika Anda belum menyiapkan kolom ini sebelum pembuatan cluster, Anda harus menjalankan SSH ke node dan melewati stub yang diselesaikan oleh sistem lokal mengubah symlink /etc/resolv.conf dari /run/systemd/resolve/stub-resolv.conf (yang berisi 127.0.0.53 stub lokal) ke /run/systemd/resolve/resolv.conf (yang menunjukkan DNS upstream): sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf Sedangkan untuk workstation admin, gkeadm tidak mendukung menentukan domain penelusuran, jadi Anda harus mengatasi masalah ini dengan panduan langkah waktu ini. Solusi ini tidak dapat diterapkan di seluruh pembuatan ulang VM. Anda harus terapkan kembali solusi ini setiap kali VM dibuat ulang.
Penginstalan, Sistem operasi	1.10	IP jembatan Docker menggunakan 172.17.0.1/16, bukan 169.254.123.1/24 Google Distributed Cloud menentukan subnet khusus untuk Docker jembatan alamat IP yang menggunakan --bip=169.254.123.1/24, sehingga ia tidak akan mencadangkan subnet 172.17.0.1/16 default. Namun, di versi 1.10.0, ada {i>bug<i} di Ubuntu OS image yang menyebabkan konfigurasi Docker yang disesuaikan agar diabaikan. Hasilnya, Docker memilih 172.17.0.1/16 default sebagai menghubungkan subnet alamat IP. Hal ini dapat menyebabkan konflik alamat IP jika Anda sudah memiliki beban kerja yang berjalan dalam rentang alamat IP tersebut. Solusi: Untuk mengatasi masalah ini, Anda harus mengganti nama konfigurasi system berikut untuk Docker, lalu mulai ulang layanan: sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \ /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf sudo systemctl daemon-reload sudo systemctl restart docker Verifikasi bahwa Docker memilih alamat IP jembatan yang benar: ip a | grep docker0 Solusi ini tidak dapat dipertahankan di seluruh pembuatan ulang VM. Anda harus mengajukan permohonan kembali solusi ini setiap kali VM dibuat ulang.
Upgrade, Update	1,11	Upgrade ke 1.11 diblokir oleh kesiapan stackdriver Di Google Distributed Cloud versi 1.11.0, ada perubahan definisi resource kustom yang terkait dengan logging dan pemantauan: Nama grup resource kustom stackdriver diubah dari addons.sigs.k8s.io menjadi addons.gke.io; Nama grup resource kustom monitoring dan metricsserver diubah dari addons.k8s.io menjadi addons.gke.io; Spesifikasi resource di atas mulai bertentangan dengan skemanya. Secara khusus, spesifikasi resourceAttrOverride dan storageSizeOverride di resource kustom stackdriver harus memiliki jenis string dalam nilai permintaan serta batas ukuran cpu, memori, dan penyimpanan. Perubahan nama grup ini dibuat untuk mematuhi pembaruan CustomResourceDefinition di Kubernetes 1.22. Anda tidak perlu melakukan tindakan apa pun jika tidak memiliki logika tambahan yang menerapkan atau mengedit resource kustom yang terpengaruh. Proses upgrade Google Distributed Cloud akan menangani migrasi resource yang terpengaruh dan mempertahankan spesifikasi yang sudah ada setelah nama grup diubah. Namun, jika Anda menjalankan logika yang menerapkan atau mengedit resource yang terpengaruh, diperlukan perhatian khusus. Pertama, mereka perlu direferensikan dengan nama grup baru dalam file manifes Anda. Contoh: apiVersion: addons.gke.io/v1alpha1 ## instead of `addons.sigs.k8s.io/v1alpha1` kind: Stackdriver Kedua, pastikan nilai spesifikasi resourceAttrOverride dan storageSizeOverride berjenis string. Contoh: spec: resourceAttrOverride: stackdriver-log-forwarder/stackdriver-log-forwarder limits: cpu: 1000m # or "1" # cpu: 1 # integer value like this would not work memory: 3000Mi Jika tidak, penerapan dan pengeditan tidak akan berpengaruh dan dapat menyebabkan status yang tidak terduga dalam komponen logging dan pemantauan. Gejala yang mungkin terjadi dapat meliputi: Log error rekonsiliasi di onprem-user-cluster-controller, misalnya: potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1} Kegagalan dalam kubectl edit stackdriver stackdriver, misalnya: Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found Jika Anda mengalami error di atas, artinya jenis yang tidak didukung berdasarkan spesifikasi CR stackdriver sudah ada sebelum upgrade. Sebagai solusinya, Anda dapat mengedit CR stackdriver secara manual dengan nama grup lama kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver dan melakukan hal berikut: Mengubah permintaan dan batas resource ke jenis string; Hapus anotasi addons.gke.io/migrated-and-deprecated: true jika ada. Kemudian, lanjutkan atau mulai ulang proses upgrade.
Sistem operasi	1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16	COS VM tidak menampilkan IP saat VM dipindahkan melalui penonaktifan host secara halus Setiap kali ada kesalahan di server ESXi dan fungsi HA vCenter telah diaktifkan untuk server, semua VM di server ESXi yang rusak akan memicu mekanisme vMotion dan dipindahkan ke server ESXi normal lainnya. VM COS yang dimigrasikan akan kehilangan IP-nya. Solusi: Memulai ulang VM
Jaringan	semua versi sebelum 1.14.7, 1.15.0-1.15.3, 1.16.0	Balasan GARP yang dikirim oleh Seesaw tidak menetapkan IP target GARP berkala (Gratuitous ARP) yang dikirim oleh Seesaw setiap 20-an tidak ditetapkan IP target di {i>header<i} ARP. Beberapa jaringan mungkin tidak menerima paket tersebut (seperti Cisco ACI). Hal ini dapat menyebabkan periode nonaktif layanan yang lebih lama setelah otak yang terpisah (karena paket drop VRRP) dipulihkan. Solusi: Picu failover Seeaw dengan menjalankan sudo seesaw -c failover pada salah satu VM Seesaw. Seharusnya memulihkan lalu lintas.
Sistem operasi	1.16, 1.28.0-1.28.200	Kubelet dibanjiri log yang menyatakan bahwa "/etc/kubernetes/manifess" tidak ada pada worker node &quot;staticPodPath&quot; tidak sengaja ditetapkan untuk worker node Solusi: Buat folder "/etc/kubernetes/manifess" secara manual

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.