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:

Pilih kategori masalah Anda:

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

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

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:

  1. Hapus konfigurasi Otorisasi Biner dari file konfigurasi Anda. Untuk petunjuk penyiapan, lihat panduan penginstalan Otorisasi Biner hari ke-2 untuk GKE di VMware.
  2. 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

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:

  1. Mendapatkan objek mesin yang dicerminkan dan menyimpannya ke file lokal untuk dicadangkan tujuan.
  2. 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
  3. 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.
  4. Jalankan kembali gkectl upgrade cluster untuk melanjutkan upgrade
Konfigurasi, Penginstalan 1,15, 1,16, 1,28, 1,29

Untuk cluster admin HA atau cluster pengguna ControlPlane V2, 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

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 "namapengguna1@example.com", bukan "namapengguna1".

Upgrade, Update 1.28.0 - 1.28.500

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:

  1. Hubungkan ke mesin master admin yang gagal menggunakan SSH.
  2. 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:

  1. Hubungkan ke mesin master admin menggunakan SSH. Untuk mengetahui detailnya, lihat Menggunakan SSH untuk terhubung ke node cluster admin.
  2. 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
    
  3. Simpan perubahan ke /etc/startup/pki-yaml.sh.
  4. Jalankan /opt/bin/master.sh untuk membuat sertifikat dan menyelesaikan {i>startup<i} mesin.
  5. Jalankan gkectl upgrade admin lagi untuk mengupgrade admin .
  6. Setelah upgrade selesai, rotasikan leaf certificate untuk kedua admin serta cluster pengguna, seperti yang dijelaskan dalam Memulai rotasi.
  7. 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 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

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

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

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

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

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

Solusi:

  • Nonaktifkan multipathd
Update 1,15, 1,16

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

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

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

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

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

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:

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

  1. Menyenyapkan notifikasi dari UI Pengelola Pemberitahuan.
  2. Jika tidak dapat menampilkan notifikasi, tinjau langkah-langkah berikut untuk menyembunyikan positif palsu:
    1. Menurunkan skala operator pemantauan menjadi 0 replika sehingga agar modifikasi dapat dipertahankan.
    2. 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.
    3. Mulai ulang Prometheus dan Alertmanager Statefulset untuk mengambil konfigurasi baru.
  3. 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 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

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

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

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

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:

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

Jika penyediaan volume dinamis dengan Driver 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

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:

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

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:

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

Saat Anda mengupgrade cluster admin dari versi 1.15.x ke 1.16.x, atau menambahkan 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:

  1. 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.
  2. Tambahkan onprem.cluster.gke.io/skip-project-location-sameness-validation: true dan menyimpan resource kustom.
  3. 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

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:

  1. Dapatkan nama semua objek Validasi:
             kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
               -n USER_CLUSTER_NAME-gke-onprem-mgmt 
            
  2. Untuk setiap objek Validasi, jalankan perintah berikut untuk menghapus 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

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:

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

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

Upgrade 1.15.0-1.15.4

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:

  1. Nonaktifkan secretsEncryption di cluster admin file konfigurasi, lalu mengupdate cluster menggunakan perintah berikut:
    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
  2. 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.
  3. Update manifes Pod statis kms-plugin.yaml di /etc/kubernetes/manifests untuk memperbarui --kek-id agar sesuai dengan kid di kunci enkripsi asli.
  4. Mulai ulang Pod statis kms-plugin dengan memindahkan /etc/kubernetes/manifests/kms-plugin.yaml ke lokasi lainnya direktori lalu memindahkannya kembali.
  5. 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:

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

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

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

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

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

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+

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

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+

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

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:

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

    Anotasi jalankan ulang adalah:

    onprem.cluster.gke.io/server-side-preflight-rerun: true
  2. Pantau progres upgrade dengan memeriksa kolom status 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:

  1. Tambahkan file info build /etc/cloud/build.info dengan konten berikut. Hal ini menyebabkan pemeriksaan preflight berjalan secara lokal di workstation admin, bukan di server.
    gke_on_prem_version: GKE_ON_PREM_VERSION
    Contoh:
    gke_on_prem_version: 1.16.0-gke.669
  2. Jalankan kembali perintah upgrade.
  3. Setelah upgrade selesai, hapus file build.info.
Buat 1.16.0-1.16.5, 1.28.0-1.28.100

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

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:

  1. SSH ke node bidang kontrol pengguna, karena node tersebut adalah cluster pengguna bidang kontrol v1, node bidang kontrol pengguna berada di cluster admin.
  2. Mulai ulang kubelet menggunakan perintah berikut:
        sudo systemctl restart kubelet
        
    Setelah mulai ulang, kubelet dapat merekonstruksi stage global mount dengan benar.
Upgrade, Update 1.16.0

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:

  1. Mulai ulang mesin yang gagal untuk membuat ulang objek node yang dihapus.
  2. 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
          
  3. Jalankan kembali perintah upgrade/update.
Operasi 1.16

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:
    1. 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
                
    2. Jalankan kembali gkectl upgrade cluster
  • Cluster Admin:
    1. 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
                
    2. 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}'
                
    3. 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.

Operasi 1.16.0, 1.16.1, 1.16.2, 1.16.3

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:

  1. Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `.
  2. Perbarui nama pengguna atau sandi vCenter di kredensial file konfigurasi.
  3. 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:

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

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

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:

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

    Anda akan melihat tiga template VM untuk cluster admin.

  3. Salin nama template VM yang cocok dengan nama mesin 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

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

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

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

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

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.

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

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

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

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

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

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

  1. 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
  2. Upgrade cluster admin+pengguna khusus Linux ke 1.12 setelah mengikuti panduan pengguna upgrade untuk versi minor target yang sesuai.
  3. (Pastikan untuk melakukan langkah ini sebelum mengupgrade ke 1.13) Pastikan enableWindowsDataplaneV2: true dikonfigurasi di CR OnPremUserCluster. Jika tidak, cluster akan 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
  4. Upgrade cluster admin+pengguna khusus Linux ke versi 1.13 setelah mengikuti upgrade panduan pengguna.
  5. 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
  6. Tambahkan kembali konfigurasi kumpulan node Windows ke user-cluster.yaml dengan kolom OSImage yang ditetapkan ke template VM Windows yang baru dibuat.
  7. 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

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

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

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

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

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

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:
  1. 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
  2. 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 -
  3. Hapus rahasia kunci penandatanganan ksa sebelumnya:
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Perbarui kolom data.data di configmap ksa-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
  5. Nonaktifkan webhook validasi untuk mengedit informasi versi di resource kustom OnPremUserCluster:
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
    webhooks:
    - name: vonpremnodepool.onprem.cluster.gke.io
      rules:
      - apiGroups:
        - onprem.cluster.gke.io
        apiVersions:
        - v1alpha1
        operations:
        - CREATE
        resources:
        - onpremnodepools
    - name: vonpremusercluster.onprem.cluster.gke.io
      rules:
      - apiGroups:
        - onprem.cluster.gke.io
        apiVersions:
        - v1alpha1
        operations:
        - CREATE
        resources:
        - onpremuserclusters
    '
  6. 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
  7. Tunggu hingga cluster pengguna target siap, Anda dapat memeriksa statusnya dengan:
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
    get onpremusercluster
  8. Pulihkan webhook validasi untuk cluster pengguna:
    kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
    webhooks:
    - name: vonpremnodepool.onprem.cluster.gke.io
      rules:
      - apiGroups:
        - onprem.cluster.gke.io
        apiVersions:
        - v1alpha1
        operations:
        - CREATE
        - UPDATE
        resources:
        - onpremnodepools
    - name: vonpremusercluster.onprem.cluster.gke.io
      rules:
      - apiGroups:
        - onprem.cluster.gke.io
        apiVersions:
        - v1alpha1
        operations:
        - CREATE
        - UPDATE
        resources:
        - onpremuserclusters
    '
  9. Hindari rotasi kunci penandatanganan KSA lainnya hingga cluster meng-upgrade ke versi yang telah diperbaiki.
Operasi 1.13.1+, 1.14, 1., 1.16

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

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

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

    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,

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

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

    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,
    1. Tambahkan pasangan nilai kunci palsu seperti "foo: bar" ke file kunci SA Connect-register Anda
    2. Jalankan gkectl update admin untuk mendaftarkan ulang cluster admin.

    Konfigurasi 1.15.0

    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

    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

    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

    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

    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

    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

    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:

    1. Dapatkan UID Pod yang tidak dapat menulis ke volumenya:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
          POD_NAME --namespace POD_NAMESPACE \
          -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Gunakan PersistentVolumeKlaim untuk mendapatkan nama PersistentVolume:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
          PVC_NAME --namespace POD_NAMESPACE \
          -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Tentukan nama node tempat Pod dijalankan:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
          --namespace POD_NAMESPACE \
          -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Mendapatkan akses powershell ke node, baik melalui SSH atau vSphere dan antarmuka web Anda.
    5. Menetapkan variabel lingkungan:
      PS C:\Users\administrator> pvname=PV_NAME
      PS C:\Users\administrator> podid=POD_UID
    6. 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
    7. Pastikan disk adalah readonly:
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Hasilnya seharusnya True.
    8. Tetapkan readonly ke false.
      PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
      PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Hapus Pod agar dapat dimulai ulang:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
          --namespace POD_NAMESPACE
    10. 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

    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:

    1. Dapatkan nama rahasia vsphere-csi-secret:
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Perbarui data rahasia vsphere-csi-secret yang Anda dapatkan dari langkah di atas:
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
        "{\"data\":{\"config\":\"$( \
          kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
            | base64 -d \
            | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
            | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
            | base64 -w 0 \
          )\"}}"
    3. Mulai ulang vsphere-csi-controller:
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. Anda dapat melacak status peluncuran dengan:
      kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Setelah deployment berhasil diluncurkan, vsphere-csi-secret yang telah diupdate 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 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

    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

    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

    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:

    1. Hapus namespace gke-connect:
      kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. 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:

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

    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

    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:

    1. Buka Metrics Explorer di konsol Google Cloud:

      Buka Metrics Explorer

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

    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:

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

      Ganti CLUSTER_ENDPOINT dengan VIP bidang kontrol dan port load balancer bidang kontrol untuk (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.

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

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

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

        Dalam perintah berikut, KUBE_APISERVER_POD adalah nama Pod kube-apiserver di cluster 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:

    1. 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
    2. Periksa log GKE Identity Service untuk mengetahui konteks token yang tidak valid:
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
          --kubeconfig KUBECONFIG
    3. Untuk mendapatkan payload token yang terkait dengan setiap konteks token yang tidak valid, 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
    4. Untuk mendekode token dan melihat nama pod sumber dan namespace, salin token ke debugger di jwt.io.
    5. Mulai ulang pod yang diidentifikasi dari token.
    Operasi 1.8, 1.9, 1.10

    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

    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+

    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

    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

    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

    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

    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

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

    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+

    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+

    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

    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+

    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

    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

    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

    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

    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

    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

    Operasi, Upgrade, Update 1,10 dan yang lebih baru

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

    Upgrade, Update 1.10.0

    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:

    Upgrade, Update 1.11, 1.12

    Jika Anda menggunakan Google Distributed Cloud versi di bawah 1.12, dan telah menyiapkan komponen Prometheus yang dikelola Google (GMP) secara manual di 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:

    Operasi 1.11, 1.12, 1.13.0 - 1.13.1

    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

    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

    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:

    Konfigurasi 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    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:

    Konfigurasi 1.12.1-1.12.3, 1.13.0-1.13.2

    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

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

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

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

    Solusi:

    Penginstalan, Upgrade, Update 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    Pendaftaran node gagal selama pembuatan, upgrade, update, dan perbaikan otomatis node, 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:

    1. Tambahkan kolom berikut di file konfigurasi cluster pengguna Anda:
      disableNodeIDVerification: true
      disableNodeIDVerificationCSRSigning: true
    2. 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

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

    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

    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

    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

    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

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

    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

    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

    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

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

    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:

    VMware 1.10, 1.11, 1.12, 1.13

    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:

    1. Masalah ini telah diperbaiki di vCenter versi 7.0U2 dan yang lebih baru.
    2. Untuk versi yang lebih rendah, klik kanan host, lalu pilih Koneksi > Putuskan koneksi. Berikutnya, hubungkan kembali, yang memaksa update dari grup port VM.
    Sistem operasi 1.10, 1.11, 1.12, 1.13

    Untuk Google Distributed Cloud versi 1.7.2 dan yang lebih baru, 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

    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

    1. Uninstal versi cert-manager Anda. Jika Anda menentukan sumber daya Anda sendiri, Anda mungkin ingin cadangan mereka.
    2. Lakukan upgrade.
    3. 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

    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.

    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

    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

    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

    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

    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

    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:

    1. Temukan Pod dan Service sumber yang memiliki metrik penagihan yang tidak diinginkan.
      kubectl --kubeconfig KUBECONFIG \
        get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
      kubectl --kubeconfig KUBECONFIG get \
        services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Hapus anotasi prometheus.io/scrap=true dari Pod atau Service. Jika anotasi ditambahkan oleh 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 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

    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:

    Logging dan pemantauan 1.10, 1.11

    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.

    1. 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.
    2. Buka ConfigMap gke-metrics-agent-conf untuk mengedit:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system edit configmap gke-metrics-agent-conf
    3. Di bagian services.pipelines, jadikan seluruh 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
    4. Tutup sesi pengeditan.
    5. Mulai ulang DaemonSet gke-metrics-agent:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system rollout restart daemonset gke-metrics-agent
    Logging dan pemantauan 1.11, 1.12, 1.13

    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 lagiPenggantian
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods
    kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods
    kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Solusi:

    Untuk mengganti metrik yang tidak digunakan lagi

    1. Menghapus "status node lokal GKE" di Google Cloud Monitoring dasbor. Instal ulang "status node lokal GKE" mengikuti petunjuk ini.
    2. Menghapus "Penggunaan node lokal GKE" di Google Cloud Monitoring dasbor. Instal ulang "Penggunaan node lokal GKE" mengikuti petunjuk ini.
    3. Menghapus "kondisi vm vSphere lokal GKE" di lapisan Dasbor pemantauan. Instal ulang "kondisi vm vSphere lokal GKE" mengikuti petunjuk ini.
    4. 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

    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

    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

    1. Buka referensi stackdriver untuk mengedit:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system edit stackdriver stackdriver
    2. 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
    3. Simpan perubahan Anda dan tutup editor teks.
    4. 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

    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

    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

    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:

    Identitas 1.10, 1.11, 1.12, 1.13

    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

    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

    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

    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:

    Upgrade, Update 1.10, 1.11, 1.12, 1.13

    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

    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

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

    1. Untuk mencegah perilaku yang tidak terduga, turunkan skala stackdriver-log-forwarder:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna file kubeconfig cluster.
    2. 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
    3. 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
    4. Hapus DaemonSet pembersihan:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
        -n kube-system delete ds fluent-bit-cleanup
    5. Lanjutkan stackdriver-log-forwarder:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
        -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging dan pemantauan 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

    Jika Anda tidak melihat log di Cloud Logging dari cluster, dan Anda 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.

    1. Buka referensi stackdriver untuk mengedit:
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          --namespace kube-system edit stackdriver stackdriver
    2. 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
    3. Simpan perubahan Anda dan tutup editor teks.
    4. 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

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

    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

    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

    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

    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:

    Lainnya 1.11.3

    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

    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:

    Operasi, Keamanan 1,11

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

    Jaringan 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    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:

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

    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

    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

    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

    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

    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:

    1. Mengubah permintaan dan batas resource ke jenis string;
    2. 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

    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

    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

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