Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Masalah umum Google Distributed Cloud (khusus software) untuk VMware

Halaman ini mencantumkan semua masalah umum terkait Google Distributed Cloud di VMware. 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

Update

1.29.0

Setelah memigrasikan cluster pengguna ke Controlplane V2, cluster admin PDB server metrik mungkin menjadi tidak dikonfigurasi dengan benar

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

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

Gejala:

Output dari diagnostik cluster admin mencakup informasi berikut

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

Solusi:

Jalankan perintah berikut untuk menghapus PDB:

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

Penginstalan, Upgrade, dan update

1.28.0-1.28.600,1.29.0-1.29.100

Webook Otorisasi Biner memblokir plugin CNI agar mulai menyebabkan salah satu nodepool gagal muncul

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

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

Solusi:

Hapus konfigurasi Otorisasi Biner dari file konfigurasi Anda. Untuk petunjuk penyiapan, lihat panduan penginstalan Otorisasi Biner hari ke-2 untuk GKE di VMware.

Untuk berhenti memblokir node yang tidak responsif selama proses pembuatan cluster saat ini, hapus konfigurasi webhook Otorisasi Biner di cluster pengguna untuk sementara menggunakan perintah berikut.

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

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

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

Upgrade

1,16, 1,28, 1,29

Upgrade cluster pengguna CPV2 terhenti karena mesin yang dicerminkan dengan `deletionTimestamp`

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

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

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

Solusi:

Mendapatkan objek mesin yang dicerminkan dan menyimpannya ke file lokal untuk dicadangkan tujuan.

Jalankan perintah berikut untuk menghapus finaler dari jendela yang dicerminkan komputer dan menunggu hingga dihapus dari cluster pengguna.

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

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

Konfigurasi, Penginstalan

1,15, 1,16, 1,28, 1,29

Kegagalan pembuatan cluster karena VIP bidang kontrol di subnet yang berbeda

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

Solusi:

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

Penginstalan, Upgrade, Update

1.29.0 - 1.29.100

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

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

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

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

Solusi:

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

Upgrade, Update

1.28.0 - 1.28.500

Upgrade cluster admin gagal untuk cluster yang dibuat di versi 1.10 atau lebih cepat

Saat mengupgrade cluster admin dari 1.16 ke 1.28, bootstrap komputer master admin baru mungkin gagal membuat bidang kontrol CA {i>root<i}. Masalah ini disebabkan oleh perubahan pada cara sertifikat yang dibuat untuk server Kubernetes API versi 1.28 dan yang lebih baru. Tujuan direproduksi kembali untuk cluster yang dibuat pada versi 1.10 dan sebelumnya, telah ditingkatkan hingga 1.16 dan sertifikat {i>leaf<i} tidak dirotasi sebelum upgrade.

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

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

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

Solusi:

Hubungkan ke mesin master admin menggunakan SSH. Untuk mengetahui detailnya, lihat Menggunakan SSH untuk terhubung ke node cluster admin.

Edit /etc/startup/pki-yaml.sh. Find (Menemukan) authorityKeyIdentifier=keyidset dan ubah menjadi authorityKeyIdentifier=keyid,issuer di bagian untuk ekstensi berikut: apiserver_ext, client_ext, etcd_server_ext, dan kubelet_server_ext. Sebagai contoh:

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

Simpan perubahan ke /etc/startup/pki-yaml.sh.
Jalankan /opt/bin/master.sh untuk membuat sertifikat dan menyelesaikan {i>startup<i} mesin.
Jalankan gkectl upgrade admin lagi untuk mengupgrade admin .
Setelah upgrade selesai, rotasikan leaf certificate untuk kedua admin serta cluster pengguna, seperti yang dijelaskan dalam Memulai rotasi.
Setelah rotasi sertifikat selesai, lakukan pengeditan yang sama pada /etc/startup/pki-yaml.sh seperti yang Anda lakukan sebelumnya, dan jalankan /opt/bin/master.sh.

Konfigurasi

1.29.0

Pesan peringatan yang salah untuk cluster dengan Dataplane V2 diaktifkan

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

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

Ada {i>bug<i} di {i>gkectl<i} yang menyebabkannya selalu menampilkan peringatan ini sebagai selama dataplaneV2.forwardMode tidak digunakan, meskipun Anda telah menetapkan enableDataplaneV2: true dalam cluster Anda file konfigurasi Anda.

Solusi:

Anda dapat mengabaikan peringatan ini dengan aman.

Konfigurasi

1.28.0-1.28.400, 1.29.0

Laporan pemeriksaan preflight penginstalan cluster admin HA salah jumlah IP statis yang diperlukan

Saat Anda membuat cluster admin HA, pemeriksaan preflight akan menampilkan pesan error yang salah berikut ini:

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

Persyaratan untuk cluster admin dengan ketersediaan tinggi (HA) 1,28 dan yang lebih tinggi tidak benar karena tidak lagi memiliki node add-on. Selain itu, karena 3 IP node bidang kontrol cluster admin ditentukan dalam Bagian network.controlPlaneIPBlock di cluster admin file konfigurasi, IP dalam file blok IP hanya diperlukan untuk {i>node<i} bidang kontrol cluster pengguna kubeception.

Solusi:

Untuk melewati pemeriksaan preflight yang salah dalam rilis yang tidak tetap, tambahkan --skip-validation-net-config ke gkectl perintah.

Operasi

1.29.0-1.29.100

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

Jika Anda memigrasikan dari cluster admin non-HA ke cluster admin HA, Connect Agent di cluster admin kehilangan koneksi ke gkeconnect.googleapis.com dengan pesan error "Gagal memverifikasi JWT tanda tangan". Hal ini karena selama migrasi, kunci penandatanganan KSA diubah, sehingga pendaftaran ulang diperlukan untuk memperbarui JWK OIDC.

Solusi:

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

Pertama-tama, dapatkan nama deployment gke-connect:

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

Hapus deployment gke-connect:

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

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

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

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

Setelah solusinya (mungkin perlu beberapa menit bagi pengontrol untuk menyelesaikan rekonsiliasi), Anda dapat memverifikasi bahwa pesan "Gagal verifikasi tanda tangan JWT Error 400 hilang dari log gke-connect-agent:

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

Penginstalan, Sistem operasi

1.28.0-1.28.500, 1.29.0

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

Google Distributed Cloud menentukan subnet khusus, --bip=169.254.123.1/24, untuk IP jembatan Docker di Konfigurasi Docker untuk mencegah pemesanan Subnet 172.17.0.1/16. Namun, dalam versi 1.28.0-1.28.500 dan 1.29.0, layanan Docker tidak dimulai ulang setelah Google Distributed Cloud menyesuaikan konfigurasi Docker karena adanya regresi dalam gambar. Hasilnya, Docker memilih 172.17.0.1/16 default sebagai subnet alamat IP jembatannya. Hal ini dapat menyebabkan konflik alamat IP jika Anda sudah memiliki beban kerja yang berjalan dalam rentang alamat IP tersebut.

Solusi:

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

sudo systemctl restart docker

Verifikasi bahwa Docker memilih alamat IP jembatan yang benar:

ip a | grep docker0

Solusi ini tidak dapat dipertahankan di seluruh pembuatan ulang VM. Anda harus mengajukan permohonan kembali solusi ini setiap kali VM dibuat ulang.

update

1.28.0-1.28.400, 1.29.0-1.29.100

Penggunaan beberapa antarmuka jaringan dengan CNI standar tidak berfungsi

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

Beberapa antarmuka jaringan dengan plugin CNI ini tidak akan berfungsi.

Solusi:

Upgrade ke versi dengan perbaikan jika Anda menggunakan fitur ini.

update

1,15, 1,16, 1,28

Dependensi trident Netapp mengganggu driver CSI vSphere

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

Solusi:

Nonaktifkan multipathd

Update

1,15, 1,16

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

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

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

Solusi:

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

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

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

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

Konfigurasi

1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200

Setelan default kolom `controlPlaneNodePort` adalah 30968 jika Spesifikasi `manualLB` kosong

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

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

Solusi:

Tentukan manualLB.controlPlaneNodePort: 0 di konfigurasi cluster admin Anda untuk cluster admin HA:

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

Penyimpanan

1.28.0-1.28.100

nfs-common tidak ada di image OS Ubuntu

nfs-common tidak ada di OS image Ubuntu yang dapat menyebabkan masalah untuk pelanggan yang menggunakan {i>driver<i} yang bergantung pada NFS seperti NetApp.

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

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

Solusi:

Pastikan node Anda dapat mendownload paket dari Kanonis.

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

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

Penyimpanan

1.28.0-1.28.100

Kolom kebijakan penyimpanan tidak ada di template konfigurasi cluster admin

SPBM di cluster admin didukung pada versi 1.28.0 dan yang lebih baru. Tapi bidang vCenter.storagePolicyName tidak ada di template file konfigurasi.

Solusi:

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

Logging dan pemantauan

1.28.0-1.28.100

Kubernetes Metadata API tidak mendukung VPC-SC

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

Solusi:

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

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

lalu jalankan

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

Upgrade, Update

1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

Pengontrol clusterapi dapat mengalami error jika cluster admin dan cluster pengguna apa pun yang mengaktifkan ControlPlane V2 menggunakan kredensial vSphere yang berbeda

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

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

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

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

Solusi:

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

Logging dan pemantauan

1,14

dll. tingginya jumlah permintaan GRPC yang gagal di Prometheus Alert Manager

Prometheus mungkin melaporkan peringatan yang mirip dengan contoh berikut:

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

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

Periksa metrik grpc_server_handled_total mentah terhadap grpc_method yang diberikan dalam pesan pemberitahuan. Di sini misalnya, periksa label grpc_code untuk Watch.

Anda dapat memeriksa metrik ini menggunakan Cloud Monitoring dengan Kueri MQL:
```
fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
```
Notifikasi pada semua kode selain OK dapat dikirimkan dengan aman diabaikan jika kode tidak termasuk salah satu dari yang berikut ini:
```
Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded
```

Solusi:

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

Menyenyapkan notifikasi dari UI Pengelola Pemberitahuan.
Jika tidak dapat menampilkan notifikasi, tinjau langkah-langkah berikut untuk menyembunyikan positif palsu:
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.
Jika kode termasuk dalam salah satu kasus yang bermasalah, periksa {i>etcd<i} dan log kube-apiserver untuk men-debug lebih lanjut.

Jaringan

1.16.0-1.16.2, 1.28.0

Koneksi yang aktif dalam waktu lama NAT keluar akan terputus

Koneksi NAT keluar mungkin terputus setelah 5 hingga 10 menit koneksi yang tersambung jika tidak ada lalu lintas data.

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

Masalah ini terjadi karena pembersihan sampah memori yang tidak sengaja menghapus entri {i>conntrack<i} yang dianggap {i>daemon <i}tidak digunakan. Perbaikan upstream diintegrasikan ke dalam anetd untuk memperbaiki perilaku tersebut.

Solusi:

Tidak ada solusi yang mudah, dan kami belum melihat masalah di versi 1.16 dari perilaku ini. Jika Anda melihat sambungan jangka panjang yang terputus karena masalah ini, solusinya adalah menggunakan beban kerja pada {i>node<i} yang sama dengan alamat IP keluar, atau untuk mengirim pesan secara konsisten di TCP koneksi jarak jauh.

Operasi

1,14, 1,15, 1,16

Penanda tangan CSR mengabaikan `spec.expirationSeconds` saat menandatangani sertifikat

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

Solusi:

Jika Anda terpengaruh oleh masalah ini, Anda dapat memperbarui cluster pengguna dengan menambahkan disableNodeIDVerificationCSRSigning: true pada pengguna file konfigurasi cluster dan jalankan gkectl update cluster untuk mengupdate cluster dengan konfigurasi ini.

Jaringan, Peningkatan Versi, Pembaruan

1.16.0-1.16.3

Validasi load balancer cluster pengguna gagal untuk `disable_bundled_ingress`

Jika Anda mencoba nonaktifkan traffic masuk yang dipaketkan untuk cluster yang ada, perintah gkectl update cluster gagal dengan error mirip dengan contoh berikut:

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

Error ini terjadi karena gkectl memeriksa beban alamat IP traffic masuk balancer selama pemeriksaan preflight. Meskipun pemeriksaan ini tidak diperlukan saat menonaktifkan traffic masuk yang dipaketkan, gkectl pemeriksaan preflight gagal saat disableBundledIngress disetel ke true.

Solusi:

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

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

Untuk informasi selengkapnya, lihat cara menonaktifkan traffic masuk yang dipaketkan untuk cluster yang ada.

Upgrade, Update

1.13, 1.14, 1.15.0-1.15.6

Update cluster admin gagal setelah rotasi CA

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

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

Solusi:

Jika Anda terpengaruh oleh masalah ini, Anda dapat memperbarui cluster admin dengan menggunakan flag --disable-update-from-checkpoint dengan Perintah gkectl update admin:

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

Saat Anda menggunakan flag --disable-update-from-checkpoint, perintah {i>update<i} tidak menggunakan file checkpoint sebagai sumber kebenaran selama update cluster. File checkpoint masih diperbarui untuk digunakan di masa mendatang.

Penyimpanan

1.15.0-1.15.6, 1.16.0-1.16.2

Pemeriksaan preflight Workload CSI gagal karena kegagalan startup Pod

Selama pemeriksaan preflight, pemeriksaan validasi Beban Kerja CSI menginstal Pod di namespace default. Pod Workload CSI memvalidasi bahwa {i>Driver<i} CSI vSphere sudah diinstal dan dapat melakukan pengaturan volume penyediaan resource. Jika Pod ini tidak dimulai, pemeriksaan validasi Workload CSI gagal.

Ada beberapa masalah umum yang dapat mencegah Pod ini dimulai:

Jika Pod belum menetapkan batas resource, yang akan terjadi beberapa cluster dengan webhook penerimaan terinstal, Pod tidak dapat dimulai.
Jika Cloud Service Mesh diinstal di cluster dengan injeksi file bantuan Istio otomatis diaktifkan di default CSI, Pod Workload CSI tidak dapat dimulai.

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

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

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

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

Jika batas resource tidak ditetapkan dengan benar untuk Pod Workload CSI, status pekerjaan berisi pesan {i>error<i} seperti berikut:

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

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

kubectl label namespace default istio.io/rev-

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

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

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

Operasi

1.16.0-1.16.2

Saat Anda masuk ke komputer admin yang dikelola pengguna, gkectl update cluster mungkin habis waktu tunggunya dan gagal memperbarui cluster pengguna. Hal ini terjadi jika versi cluster admin adalah 1.15 dan Anda menjalankan gkectl update admin sebelum Anda menjalankan gkectl update cluster. Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba mengupdate cluster:

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

Selama update cluster admin 1.15, validation-controller yang memicu pemeriksaan preflight akan dihapus dari cluster. Jika Anda kemudian mencoba memperbarui cluster pengguna, pemeriksaan preflight akan berhenti waktu tunggu habis.

Solusi:

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

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

Setelah persiapan selesai, jalankan gkectl update cluster lagi untuk memperbarui cluster pengguna

Operasi

1.16.0-1.16.2

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

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

Karena validation-controller ditambahkan di 1.16, saat menggunakan 1.15 admin mengelompokkan validation-controller yang bertanggung jawab untuk memicu pemeriksaan preflight tidak ada. Oleh karena itu, saat mencoba membuat cluster pengguna, pemeriksaan preflight hang sampai waktu tunggu habis.

Solusi:

Jalankan perintah berikut untuk men-deploy validation-controller:

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

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

Upgrade, Update

1.16.0-1.16.2

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

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

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

Update atau upgrade cluster admin memerlukan onprem-admin-cluster-controller untuk merekonsiliasi admin cluster yang sama. Saat status cluster admin dipulihkan di jenis cluster, webhook cluster admin tidak dapat membedakan apakah Objek OnPremAdminCluster ditujukan untuk pembuatan cluster admin, atau melanjutkan operasi pembaruan atau {i>upgrade<i}. Beberapa khusus buat validasi dipanggil saat mengupdate dan mengupgrade secara tiba-tiba.

Solusi:

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

Edit resource cluster onpremadminclusters:
```
kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Ganti yang berikut:
- ADMIN_CLUSTER_NAME: nama cluster admin.
- ADMIN_CLUSTER_KUBECONFIG: jalur pada file kubeconfig cluster admin.
Tambahkan onprem.cluster.gke.io/skip-project-location-sameness-validation: true dan menyimpan resource kustom.
Bergantung pada jenis cluster admin, selesaikan salah satu langkah-langkah berikut:
- Untuk cluster admin non-HA yang memiliki file checkpoint: tambahkan parameter disable-update-from-checkpoint dalam perintah update, atau tambahkan parameter `disable-upgrade-from-checkpoint` dalam perintah upgrade. Ini parameter hanya diperlukan saat berikutnya Anda menjalankan Perintah update atau upgrade:
  - ```
  gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint
```
- ```
gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --disable-upgrade-from-checkpoint
```
- Untuk cluster admin dengan ketersediaan tinggi (HA) atau file checkpoint dinonaktifkan: mengupdate atau mengupgrade cluster admin seperti biasa. Tidak ada parameter tambahan diperlukan pada perintah pembaruan atau {i>upgrade<i}.

Operasi

1.16.0-1.16.2

Gagal menghapus cluster pengguna saat menggunakan workstation admin yang dikelola pengguna

Saat Anda masuk ke komputer admin yang dikelola pengguna, gkectl delete cluster mungkin habis waktu tunggunya dan gagal menghapus cluster pengguna. Hal ini terjadi jika Anda pertama kali menjalankan gkectl di workstation yang dikelola pengguna untuk membuat, memperbarui, atau mengupgrade cluster pengguna. Ketika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba menghapus cluster:

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

Selama penghapusan, cluster akan menghapus semua objeknya terlebih dahulu. Tujuan penghapusan objek Validasi (yang dibuat saat pembuatan, {i>update<i}, atau upgrade) terhenti di fase penghapusan. Hal ini sering terjadi karena finaler memblokir penghapusan objek, yang menyebabkan penghapusan cluster gagal.

Solusi:

Dapatkan nama semua objek Validasi:

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

Untuk setiap objek Validasi, jalankan perintah berikut untuk menghapus finaler dari objek Validation:
```
      kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
        -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
      
```
Setelah menghapus finaler dari semua objek Validasi, objek ini dihapus dan operasi penghapusan cluster pengguna selesai secara otomatis. Anda tidak perlu melakukan tindakan tambahan.

Jaringan

1,15, 1,16

Traffic gateway NAT keluar ke server eksternal gagal

Jika Pod sumber dan Pod gateway NAT keluar berada di dua node pekerja, traffic dari Pod sumber tidak dapat menjangkau layanan IT perusahaan mereka. Jika Pod terletak di host yang sama, koneksi ke layanan atau aplikasi eksternal berhasil.

Masalah ini disebabkan oleh {i>vSphere<i} menjatuhkan paket VXLAN saat {i>tunnel<i} penggabungan diaktifkan. Ada masalah umum pada NSX dan VMware yang hanya mengirimkan traffic gabungan pada port VXLAN yang dikenal (4789).

Solusi:

Ubah port VXLAN yang digunakan oleh Cilium menjadi 4789:

Edit ConfigMap cilium-config:

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

Tambahkan kode berikut ke cilium-config ConfigMap:
```
tunnel-port: 4789
```

Mulai ulang DaemonSet anetd:

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

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

Upgrade

1.15.0-1.15.4

Upgrade cluster admin yang mengaktifkan enkripsi secret yang selalu aktif akan gagal

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

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

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

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

Solusi

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

Nonaktifkan secretsEncryption di cluster admin file konfigurasi, lalu mengupdate cluster menggunakan perintah berikut:
```
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
```
Saat VM master admin yang baru dibuat, lakukan SSH ke VM master admin, dan mengganti kunci baru pada {i>disk <i} dengan yang lama dari cadangan. Kuncinya ada di /opt/data/gke-k8s-kms-plugin/generatedkeys di master admin.
Update manifes Pod statis kms-plugin.yaml di /etc/kubernetes/manifests untuk memperbarui --kek-id agar sesuai dengan kid di kunci enkripsi asli.
Mulai ulang Pod statis kms-plugin dengan memindahkan /etc/kubernetes/manifests/kms-plugin.yaml ke lokasi lainnya direktori lalu memindahkannya kembali.
Lanjutkan upgrade admin dengan menjalankan gkectl upgrade admin lagi.

Mencegah kegagalan upgrade

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

Cadangkan cluster admin.
Nonaktifkan secretsEncryption di cluster admin file konfigurasi, lalu mengupdate cluster menggunakan perintah berikut:
```
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
```
Upgrade cluster admin.
Mengaktifkan kembali enkripsi rahasia yang selalu aktif.

Penyimpanan

1,11-1,16

Error disk dan kegagalan pemasangan saat menggunakan Pelacakan Pemblokiran yang Diubah (CBT)

Google Distributed Cloud tidak mendukung Changes Block Tracking (CBT) di {i>disk<i}. Beberapa perangkat lunak cadangan menggunakan fitur CBT untuk melacak status {i>disk<i} dan melakukan pencadangan, yang menyebabkan {i> disk<i} tidak dapat terhubung ke VM yang menjalankan Google Distributed Cloud. Untuk informasi selengkapnya, lihat Pusat Informasi VMware artikel ini.

Solusi:

Jangan mencadangkan VM Google Distributed Cloud, sebagai software pencadangan pihak ketiga dapat menyebabkan CBT diaktifkan pada {i>disk<i} mereka. Tidak perlu kembali mengubah VM ini.

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

Jika Anda sudah memiliki disk dengan CBT yang diaktifkan, ikuti Langkah-langkah Penyelesaian di Pusat Informasi VMware artikeluntuk menonaktifkan CBT di Disk First Class.

Penyimpanan

1,14, 1,15, 1,16

Kerusakan data pada NFSv3 ketika paralel menambahkan ke file bersama dilakukan dari beberapa {i>host<i}

Jika Anda menggunakan susunan penyimpanan Nutanix untuk menyediakan pembagian NFSv3 ke Anda mungkin akan mengalami kerusakan data atau ketidakmampuan Pod untuk berjalan dengan sukses. Masalah ini disebabkan oleh masalah kompatibilitas umum antara versi VMware dan Nutanix tertentu. Untuk selengkapnya lihat informasi terkait Pusat Informasi VMware artikel ini.

Solusi:

Artikel Pusat Informasi VMware sudah usang karena menunjukkan bahwa tidak ada resolusi saat ini. Untuk mengatasi masalah ini, update ke versi terbaru ESXi di host Anda dan ke versi Nutanix terbaru di penyimpanan Anda .

Sistem operasi

1.13.10, 1.14.6, 1.15.3

Ketidakcocokan versi antara kubelet dan bidang kontrol Kubernetes

Untuk rilis Google Distributed Cloud tertentu, kubelet yang berjalan di versi yang berbeda dari bidang kontrol Kubernetes. Terdapat ketidakcocokan karena biner kubelet yang dimuat sebelumnya di OS image menggunakan versi yang berbeda.

Tabel berikut mencantumkan ketidakcocokan versi yang teridentifikasi:

Versi Google Distributed Cloud	versi kubelet	Versi Kubernetes
1.13.10	v1.24.11-gke.1200	v1.24.14-gke.2100
1.14.6	v1.25.8-gke.1500	v1.25.10-gke.1200
1.15.3	v1.26.2-gke.1001	v1.26.5-gke.2100

Solusi:

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

Upgrade, Update

1.15.0-1.15.4

Upgrade atau update cluster admin dengan versi CA yang lebih tinggi dari 1 gagal

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

    CAVersion must start from 1

Solusi:

Menurunkan skala deployment auto-resize-controller di untuk menonaktifkan perubahan ukuran otomatis node. Ini diperlukan karena kolom baru diperkenalkan ke Resource Kustom cluster admin di 1.15 dapat menyebabkan error pointer nol di auto-resize-controller.
```
 kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
      
```

Jalankan perintah gkectl dengan tanda --disable-admin-cluster-webhook.Contoh:

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

Operasi

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

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

Ketika gugus Controlplane V2 non-HA dihapus, gugus tersebut akan tertahan di node hingga kehabisan waktu.

Solusi:

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

Atau, lakukan langkah-langkah berikut:

Hapus semua VM cluster dari vSphere. Anda dapat menghapus VM melalui UI vSphere, atau jalankan perintah berikut:
```
      govc vm.destroy
```
.

Hapus otomatis cluster lagi:

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

Penyimpanan

1.15.0+, 1.16.0+

Tugas pemasangan volume CNS yang konstan muncul setiap menit untuk PVC/PV dalam hierarki setelah mengupgrade ke versi 1.15+

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

Solusi:

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

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

Mulai ulang pod pengontrol vSphere CSI:

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

Penyimpanan

1.16.0

Peringatan palsu yang dilihat oleh PVC

Jika sebuah cluster berisi volume persisten vSphere intree, perintah gkectl diagnose dan gkectl upgrade mungkin mengumpulkan peringatan palsu terhadap klaim volume persisten (PVC) saat memvalidasi setelan penyimpanan cluster. Pesan peringatan terlihat seperti berikut ini

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

Solusi:

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

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

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

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

Upgrade, Update

1.15.0+, 1.16.0+

Rotasi kunci akun layanan gagal saat beberapa kunci sudah tidak berlaku

Jika cluster Anda tidak menggunakan registry pribadi, dan komponen Anda akses kunci akun layanan dan Pemantauan log (atau pendaftaran Connect) masa berlaku kunci akun layanan sudah habis, saat Anda putar kunci akun layanan, gkectl update credentials gagal dengan error yang mirip dengan berikut ini:

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

Solusi:

Pertama, rotasikan kunci akun layanan akses komponen. Meskipun yang sama ditampilkan, Anda seharusnya dapat merotasi setelah rotasi kunci akun layanan akses komponen.

Jika update masih belum berhasil, hubungi Cloud Customer Care untuk mengatasi masalah ini.

Upgrade

1.16.0-1.16.5

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

Selama upgrade cluster pengguna, setelah pengontrol cluster pengguna diupgrade ke 1.16, jika Anda memiliki cluster pengguna 1,15 lainnya yang dikelola oleh cluster admin yang sama, mesin master penggunanya mungkin akan dibuat ulang secara tidak terduga.

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

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

Solusi saat mengupgrade cluster pengguna menggunakan Konsol Google Cloud:

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

Opsi 2: Lakukan langkah-langkah berikut:

Tambahkan anotasi jalankan ulang secara manual dengan perintah berikut:

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

Anotasi jalankan ulang adalah:

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

Pantau progres upgrade dengan memeriksa kolom status di OnPremUserCluster.

Solusi saat mengupgrade cluster pengguna menggunakan workstation admin Anda sendiri:

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

Opsi 2: Lakukan langkah-langkah berikut:

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

Buat

1.16.0-1.16.5, 1.28.0-1.28.100

Pemeriksaan preflight akan gagal jika nama host tidak ada dalam file blok IP.

Selama pembuatan cluster, jika Anda tidak menentukan nama host untuk setiap IP di file blok IP, pemeriksaan {i>preflight<i} akan gagal dengan pesan error berikut:

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

Ada bug dalam pemeriksaan preflight yang menganggap nama host kosong sebagai duplikat.

Solusi:

Opsi 1: Gunakan versi yang memiliki perbaikan.

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

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

Upgrade, Update

1.16

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

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

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

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

Dan Anda akan melihat peristiwa seperti:

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

Solusi:

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

Upgrade, Update

1.16.0

Node bidang kontrol gagal dibuat

Selama upgrade atau update cluster admin, kondisi race mungkin menyebabkan pengelola pengontrol cloud vSphere menghapus {i>node<i} bidang kontrol. Ini menyebabkan clusterapi-controller macet menunggu node dibuat, dan bahkan upgrade/update waktunya habis. Dalam hal ini, output dari gkectl perintah upgrade/update mirip dengan yang berikut ini:

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

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

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

Berikut adalah contoh pesan error dari perintah di atas:

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

Solusi:

Mulai ulang mesin yang gagal untuk membuat ulang objek node yang dihapus.

SSH ke setiap node bidang kontrol dan memulai ulang pod statis pengelola pengontrol cloud vSphere:

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

Jalankan kembali perintah upgrade/update.

Operasi

1.16

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

Upgrade cluster 1.15 atau pembuatan cluster 1.16 dengan IP statis akan gagal jika ada duplikat nama {i>host<i} di pusat data yang sama. Kegagalan ini terjadi karena Pengelola pengontrol cloud vSphere gagal menambahkan IP eksternal dan penyedia ID pada objek node. Hal ini menyebabkan waktu tunggu proses upgrade/pembuatan cluster habis.

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

Cluster Admin:

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

Cluster pengguna (kubeception):

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

Cluster pengguna: (Controlplane V2):

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

Berikut adalah contoh pesan error:

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

Periksa apakah nama host diduplikasi di pusat data:

Anda dapat menggunakan pendekatan berikut untuk memeriksa apakah nama {i>host<i} diduplikasi, dan lakukan solusinya jika diperlukan.

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

Contoh perintah dan output:

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

Solusi yang Anda lakukan bergantung pada operasi yang gagal.

Solusi untuk upgrade:

Lakukan solusi untuk jenis cluster yang berlaku.

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

Perbarui nama host mesin yang terpengaruh di admin-ip-block.yaml ke nama yang unik dan picu update otomatis:

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

Jika ini adalah cluster admin non-HA, dan Anda menemukan vm master admin menggunakan nama host duplikat, Anda juga perlu:
Dapatkan nama mesin master admin

          kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A

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

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

Pastikan nama host telah diperbarui di objek mesin master admin:

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

Jalankan kembali upgrade cluster admin dengan checkpoint dinonaktifkan:

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

Solusi untuk penginstalan:

Lakukan solusi untuk jenis cluster yang berlaku.

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

Operasi

1.16.0, 1.16.1, 1.16.2, 1.16.3

`$` dan ` tidak didukung di nama pengguna atau sandi vSphere

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

Mengupgrade cluster pengguna 1.15 dengan Controlplane V2 yang diaktifkan ke versi 1.16
Mengupgrade cluster admin dengan ketersediaan tinggi (HA) 1,15 ke versi 1.16
Membuat cluster pengguna 1.16 dengan Controlplane V2 diaktifkan
Membuat cluster admin dengan ketersediaan tinggi (HA) 1.16

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

Solusi untuk upgrade:

Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `.
Perbarui nama pengguna atau sandi vCenter di credentials file konfigurasi.
Picu update cluster secara paksa.

Cluster pengguna:

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

Cluster Admin:

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

Solusi untuk penginstalan:

Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus $ dan `.
Perbarui nama pengguna atau sandi vCenter di credentials file konfigurasi.
Lakukan solusi untuk jenis cluster yang berlaku.

Cluster Admin:
1. Hapus mesin node admin.
2. Hapus disk data.
3. Hapus file checkpoint cluster admin.
4. Jalankan kembali gkectl create admin.
Cluster pengguna:
1. Membersihkan resource.
2. Jalankan kembali gkectl create cluster.

Penyimpanan

1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

Kegagalan pembuatan PVC setelah node dibuat ulang dengan nama yang sama

Setelah {i>node<i} dihapus dan kemudian dibuat ulang dengan nama {i>node<i} yang sama, ada sedikit kemungkinan bahwa PersistentVolumeKlaim (PVC) berikutnya pembuatan gagal dengan error seperti berikut:

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

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

Solusi:

Mulai ulang pod pengontrol vSphere CSI:

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

Operasi

1.16.0

Perbaikan gkectl admin-master menampilkan error kubeconfig unmarshall

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

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

Solusi:

Tambahkan flag --admin-master-vm-template= ke perintah tersebut, lalu menyediakan template VM mesin yang akan diperbaiki:

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

Untuk menemukan template VM mesin:

Buka halaman Hosts and Clusters di klien vSphere.
Klik Template VM dan filter menurut nama cluster admin.
Anda akan melihat tiga template VM untuk cluster admin.
Salin nama template VM yang cocok dengan nama mesin Anda memperbaiki dan menggunakan nama {i>template<i} dalam perintah perbaikan.

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

Jaringan

1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

Melihat VM rusak karena kapasitas disk hampir penuh

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

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

Kesalahan ini menunjukkan bahwa kapasitas {i>disk<i} pada VM rendah karena yang berjalan di Seesaw VM tidak dikonfigurasi dengan rotasi log yang benar.

Solusi:

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

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

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

Operasi

1.13, 1.14.0-1.14.6, 1.15

Terjadi error pada kunci publik SSH admin setelah upgrade atau update cluster admin

Saat Anda mencoba mengupgrade (gkectl upgrade admin) atau mengupdate (gkectl update admin) cluster admin yang tidak memiliki Ketersediaan Tinggi dengan checkpoint diaktifkan, upgrade atau update mungkin akan gagal dengan pesan error seperti berikut ini:

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

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

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

Solusi:

Jika Anda tidak dapat melakukan upgrade ke versi patch Google Distributed Cloud setelah perbaikan ini, hubungi Dukungan Google untuk mendapatkan bantuan.

Upgrade

1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

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

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

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

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

Solusi:

Batalkan pendaftaran cluster admin:

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

dan lanjutkan mengupgrade cluster admin. Anda mungkin melihat pesan status `gagal untuk error register cluster` untuk sementara. Setelah beberapa waktu, data tersebut akan diupdate secara otomatis.

Upgrade, Update

1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

Anotasi link resource cluster admin yang terdaftar tidak dipertahankan

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

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

Solusi:

Batalkan pendaftaran cluster admin:

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

dan daftarkan ulang ke cluster admin lagi.

Jaringan

1.15.0-1.15.2

CoreDNS `orderPolicy` tidak dikenali

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

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

Solusi:

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

Edit template yang ada:

kubectl edit cm -n kube-system coredns-template

Ganti konten template dengan berikut ini:

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

Upgrade, Update

1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

Status OnPremAdminCluster tidak konsisten antara checkpoint dan CR sebenarnya

Kondisi race tertentu dapat menyebabkan status OnPremAdminCluster menjadi tidak konsisten antara checkpoint dan CR aktual. Jika masalah terjadi, Anda mungkin mengalami error berikut saat mengupdate cluster admin setelah mengupgradenya:

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

Untuk mengatasi masalah ini, Anda harus mengedit checkpoint atau menonaktifkan checkpoint untuk upgrade/update. Hubungi tim dukungan kami untuk menggunakan solusi ini.

Operasi

1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Proses rekonsiliasi mengubah sertifikat admin pada cluster admin

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

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

Sertifikat yang tidak valid dapat menyebabkan perintah berikut kehabisan waktu dan error yang ditampilkan:
- gkectl create admin
- gkectl upgrade amdin
- gkectl update admin
Perintah ini dapat menampilkan error otorisasi seperti berikut:
```
Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
```

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

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

Solusi:

Upgrade ke versi Google Distributed Cloud setelah perbaikan: 1.13.10+, 1.14.6+, 1.15.2+. Jika upgrade tidak dapat dilakukan, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.

Jaringan, Operasi

1.10, 1.11, 1.12, 1.13, 1.14

Komponen Gateway Jaringan Anthos dihapus atau tertunda karena tidak ada kelas prioritas

Pod gateway jaringan di kube-system mungkin menampilkan status Pending atau Evicted, seperti yang ditunjukkan dalam contoh {i>output<i} yang ringkas:

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

Error ini menunjukkan peristiwa penghapusan atau ketidakmampuan untuk menjadwalkan Pod karena resource node. Karena Pod Gateway Jaringan Anthos tidak PriorityClass memiliki prioritas default yang sama dengan workload lainnya. Jika node memiliki resource yang terbatas, Pod gateway jaringan mungkin dikeluarkan. Perilaku ini sangat buruk untuk ang-node DaemonSet, karena Pod harus dijadwalkan pada node tertentu dan tidak melakukan migrasi.

Solusi:

Upgrade ke versi 1.15 atau yang lebih baru.

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

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

Upgrade, Update

1.12, 1.13, 1.14, 1.15.0-1.15.2

upgrade cluster admin gagal setelah mendaftarkan cluster ke gcloud

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

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

Hapus namespace gke-connect:

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG

Dapatkan nama cluster admin:

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

Hapus keanggotaan fleet:

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME

dan lanjutkan upgrade cluster admin.

Operasi

1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

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

Hal ini tidak memengaruhi fungsi pengambilan snapshot karena snapshot masih mencakup semua log yang dikumpulkan oleh default dengan menjalankan journalctl pada node cluster. Oleh karena itu, tidak ada informasi proses debug yang terlewat.

Penginstalan, Upgrade, Update

1,9+, 1,10+, 1,11+, 1,12+

`gkectl prepare windows` gagal

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

Solusi:

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

Catatan: Kami memiliki opsi untuk menyelesaikan masalah ini di versi Anda saat ini tanpa harus meningkatkan sepenuhnya ke versi 1.13, tetapi akan membutuhkan lebih banyak panduan langkah selanjutnya, hubungi tim dukungan kami jika Anda ingin mempertimbangkan menggunakan opsi ini.

Opsi 1: Upgrade Biru/Hijau

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

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

Opsi 2: Menghapus kumpulan node Windows dan menambahkannya kembali saat mengupgrade ke Google Distributed Cloud 1.13

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

Menghapus kumpulan node Windows yang ada dengan menghapus node pool Windows konfigurasi dari file user-cluster.yaml, lalu jalankan perintah:
```
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
```
Upgrade cluster admin+pengguna khusus Linux ke 1.12 setelah mengikuti panduan pengguna upgrade untuk versi minor target yang sesuai.
(Pastikan untuk melakukan langkah ini sebelum mengupgrade ke 1.13) Pastikan enableWindowsDataplaneV2: true dikonfigurasi di CR OnPremUserCluster. Jika tidak, cluster akan tetap menggunakan node pool Docker untuk Windows, yang tidak akan kompatibel dengan template VM Windows 1.13 yang baru dibuat dan belum menginstal Docker. Jika tidak dikonfigurasi atau disetel ke salah (false), perbarui cluster Anda untuk menyetelnya ke benar (true) di user-cluster.yaml, lalu jalankan:
```
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
```
Upgrade cluster admin+pengguna khusus Linux ke versi 1.13 setelah mengikuti upgrade panduan pengguna.

Siapkan template VM Windows menggunakan 1.13 gkectl:

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

Tambahkan kembali konfigurasi kumpulan node Windows ke user-cluster.yaml dengan kolom OSImage yang ditetapkan ke template VM Windows yang baru dibuat.

Mengupdate cluster untuk menambahkan kumpulan node Windows

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

Penginstalan, Upgrade, Update

1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Konfigurasi `RootDistanceMaxSec` tidak diterapkan untuk `ubuntu` node

Nilai default 5 detik untuk RootDistanceMaxSec adalah digunakan pada {i>node<i}, bukan 20 detik yang seharusnya sesuai dengan konfigurasi Anda. Jika Anda memeriksa log startup {i>node<i} dengan melakukan SSH ke VM, yang terletak di `/var/log/startup.log`, Anda dapat menemukan hal berikut {i>error<i}:

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

Menggunakan RootDistanceMaxSec selama 5 detik dapat menyebabkan sistem jam tidak sinkron dengan server NTP ketika penyimpangan jam lebih besar dari 5 detik.

Solusi:

Terapkan DaemonSet berikut ke cluster Anda untuk mengonfigurasi RootDistanceMaxSec:

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

Upgrade, Update

1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

`gkectl update admin` gagal karena kolom `osImageType` kosong

Jika Anda menggunakan gkectl versi 1.13 untuk mengupdate versi 1.12 Anda, Anda mungkin melihat error berikut:

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

Jika Anda menggunakan gkectl update admin untuk versi 1.13 atau 1.14 , Anda mungkin melihat pesan berikut dalam responsnya:

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

Jika memeriksa log gkectl, Anda mungkin melihat bahwa beberapa termasuk menyetel osImageType dari string kosong ke ubuntu_containerd.

Kesalahan pembaruan ini disebabkan oleh pengisian ulang yang tidak tepat Kolom osImageType di konfigurasi cluster admin karena yang diperkenalkan dalam versi 1.9.

Solusi:

Upgrade ke versi Google Distributed Cloud setelah perbaikan. Jika mengupgrade ini tidak memungkinkan bagi Anda, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.

Pemasangan, Keamanan

1.13, 1.14, 1.15, 1.16

SNI tidak berfungsi pada cluster pengguna dengan Controlplane V2

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

Solusi:

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

Penginstalan

1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

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

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

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

Solusi:

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

Upgrade, Update

1.12.0-1.12.4

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

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

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

Upgrade, Update

1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Update cluster pengguna gagal setelah rotasi kunci penandatanganan KSA

Setelah Anda memutar Kunci penandatanganan KSA, lalu mengupdate cluster pengguna, gkectl update mungkin gagal dengan pesan error berikut:

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

Solusi:

Ubah versi kunci penandatanganan KSA Anda kembali ke 1, tetapi pertahankan data kunci terbaru:

Periksa rahasia di cluster admin pada namespace USER_CLUSTER_NAME, dan dapatkan nama rahasia kunci penandatanganan ksa:
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
```

Salin rahasia kunci penandatanganan ksa, dan beri nama rahasia yang disalin sebagai service-account-cert:

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

Hapus rahasia kunci penandatanganan ksa sebelumnya:

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

Perbarui kolom data.data di configmap ksa-signed-key-rotation-stage ke '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}':
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
```

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

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

Update kolom spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation menjadi 1 di resource kustom OnPremUserCluster Anda:
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
```

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

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

Pulihkan webhook validasi untuk cluster pengguna:

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

Hindari rotasi kunci penandatanganan KSA lainnya hingga cluster meng-upgrade ke versi yang telah diperbaiki.

Operasi

1.13.1+, 1.14, 1., 1.16

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

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

Solusi:

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

Penginstalan, Upgrade, Update

1.13.8, 1.14.4

jenis cluster mengambil image container dari `docker.io`

Jika Anda membuat cluster admin versi 1.13.8 atau versi 1.14.4, atau meng-upgrade cluster admin ke versi 1.13.8 atau 1.14.4, jenis cluster menarik image container berikut dari docker.io:

docker.io/kindest/kindnetd

docker.io/kindest/local-path-provisioner

docker.io/kindest/local-path-helper

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

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

Respons berisi entri seperti berikut:

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

Image container ini harus dipramuat di container cluster jenis gambar. Namun, v0.18.0 telah masalah dengan image container yang dimuat sebelumnya, sehingga mereka akan ditarik dari internet secara tidak sengaja.

Solusi:

Jalankan perintah berikut di workstation admin, saat ada cluster admin sedang menunggu dibuat atau diupgrade:

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

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

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

Operasi

1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

Failover gagal pada cluster pengguna HA Controlplane V2 dan cluster admin saat jaringan memfilter permintaan GARP duplikat

Jika VM cluster Anda terhubung dengan {i>switch<i} yang memfilter permintaan GARP duplikat (ARP) duplikat, pemilihan pemimpin keepalive mungkin mengalami kondisi race, yang menyebabkan beberapa {i>node<i} memiliki entri tabel ARP yang salah.

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

Solusi:

Jalankan perintah berikut di setiap node bidang kontrol dari cluster yang terpengaruh:

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

Upgrade, Update

1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

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

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

Solusi:

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

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

Penginstalan

1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1

Pembuatan cluster admin tidak gagal saat terjadi error pendaftaran cluster

Bahkan ketika pendaftaran cluster gagal selama pembuatan cluster admin, perintah gkectl create admin tidak gagal saat terjadi error dan mungkin berhasil. Dengan kata lain, pembuatan cluster admin bisa "berhasil" tanpa terdaftar ke suatu fleet.

Untuk mengidentifikasi gejala, Anda dapat mencari pesan error berikut dalam log `gkectl create admin`,

Failed to register admin cluster

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

Solusi:

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

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

Upgrade, Update

1.10, 1.11, 1.12, 1.13.0-1.13.1

Pendaftaran ulang cluster admin mungkin dilewati selama upgrade cluster admin

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

Solusi:

Periksa apakah cluster ditampilkan di antara cluster yang terdaftar. Sebagai langkah opsional, Login ke cluster setelah menyiapkan autentikasi. Jika cluster masih terdaftar, Anda dapat melewati petunjuk berikut untuk mencoba kembali pendaftaran. Untuk cluster yang diupgrade ke versi 1.12 dan yang lebih baru, ikuti petunjuk untuk mencoba kembali pendaftaran cluster admin setelah pembuatan cluster. Untuk cluster yang diupgrade ke versi sebelumnya,

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

Konfigurasi

1.15.0

Pesan error palsu tentang `vCenter.dataDisk`

Untuk cluster admin dengan ketersediaan tinggi, gkectl prepare menampilkan pesan {i>error <i}yang keliru ini:

vCenter.dataDisk must be present in the AdminCluster spec

Solusi:

Anda dapat mengabaikan pesan error ini dengan aman.

VMware

1.15.0

Pembuatan kumpulan node gagal karena aturan afinitas Host VM yang redundan

Selama pembuatan kumpulan node yang menggunakan Afinitas Host VM, kondisi race dapat mengakibatkan beberapa Aturan afinitas Host VM dibuat dengan nama yang sama. Hal ini dapat menyebabkan pembuatan kumpulan node gagal.

Solusi:

Hapus aturan redundan lama agar pembuatan kumpulan node dapat dilanjutkan. Aturan ini diberi nama [USER_CLUSTER_NAME]-[HASH].

Operasi

1.15.0

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

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

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

Solusi:

Perintah ini bersifat idempoten. {i>Tcpdump<i} dapat berjalan kembali dengan aman sampai perintah berhasil.

Upgrade, Update

1.15.0

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

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

Solusi:

Anda dapat mengabaikan Pod yang gagal dengan aman atau menghapusnya secara manual.

Keamanan, Konfigurasi

1.15.0-1.15.1

OnPremUserCluster tidak siap karena kredensial registry pribadi

Jika Anda menggunakan kredensial yang disiapkan dan {i>registry<i} pribadi, tetapi Anda belum mengonfigurasi kredensial yang disiapkan untuk registry pribadi Anda, {i>OnPremUserCluster<i} mungkin belum siap, dan Anda mungkin melihat pesan error berikut:

failed to check secret reference for private registry …

Solusi:

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

Upgrade, Update

1.15.0

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

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

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

Solusi:

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

Penyimpanan

1,15, 1,16

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

Dalam kondisi tertentu, disk dapat dipasang sebagai hanya baca ke Windows node. Hal ini menyebabkan volume terkait bersifat hanya baca di dalam Pod. Masalah ini kemungkinan besar terjadi jika sekumpulan node baru menggantikan node lama yang sama (misalnya, upgrade cluster atau pembaruan kumpulan node). Stateful yang sebelumnya bekerja dengan baik mungkin tidak dapat menulis ke pada kumpulan node baru.

Solusi:

Dapatkan UID Pod yang tidak dapat menulis ke volumenya:

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

Gunakan PersistentVolumeKlaim untuk mendapatkan nama PersistentVolume:

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

Tentukan nama node tempat Pod dijalankan:

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

Mendapatkan akses powershell ke node, baik melalui SSH atau vSphere dan antarmuka web Anda.

Menyetel variabel lingkungan:

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

Identifikasi nomor {i>disk<i} yang terkait dengan PersistentVolume:

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

Pastikan disk adalah readonly:

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

Hasilnya seharusnya True.

Tetapkan readonly ke false.

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

Hapus Pod agar dapat dimulai ulang:

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

Pod akan dijadwalkan ke node yang sama. Namun, seandainya Pod mendapatkan dijadwalkan ke {i>node<i} baru, Anda mungkin perlu mengulangi langkah sebelumnya pada {i>node<i} baru.

Upgrade, Update

1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

`vsphere-csi-secret` tidak diupdate setelah `gkectl update credentials vsphere --admin-cluster`

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

Solusi:

Dapatkan nama rahasia vsphere-csi-secret:

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

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

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

Mulai ulang vsphere-csi-controller:

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

Anda dapat melacak status peluncuran dengan:
```
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
```
Setelah deployment berhasil diluncurkan, vsphere-csi-secret yang telah diupdate akan digunakan oleh pengontrol.

Upgrade, Update

1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

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

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

Solusi:

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

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

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

Upgrade, Update

1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

Deployment ulang bidang kontrol tambahan tepat setelah `gkectl upgrade cluster`

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

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

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

Solusi:

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

Upgrade, Update

1.12.7

Rilis buruk 1.12.7-gke.19 telah dihapus

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

Solusi:

Gunakan rilis 1.12.7-gke.20 sebagai gantinya.

Upgrade, Update

1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

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

Jika Anda memperbarui kredensial registry menggunakan salah satu metode berikut:

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

Anda mungkin mendapati gke-connect-agent terus menggunakan versi lama gambar atau pod gke-connect-agent tidak dapat diambil karena ke ImagePullBackOff.

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

Solusi:

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

Hapus namespace gke-connect:

kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect

Deploy ulang gke-connect-agent dengan register asli kunci akun layanan (tidak perlu memperbarui kunci):

Untuk cluster admin:

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

Untuk cluster pengguna:

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

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

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

Opsi 3: Anda dapat menambahkan rahasia pull image default untuk cluster Anda di deployment gke-connect-agent dengan:

Salin rahasia default ke namespace gke-connect:

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

Dapatkan nama deployment gke-connect-agent:

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

Tambahkan rahasia default ke deployment gke-connect-agent:

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

Penginstalan

1,13, 1,14

Kegagalan pemeriksaan konfigurasi LB manual

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

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

Solusi:

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

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

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

Operasi

1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, dan 1.14

dll. kelaparan smartwatch

Cluster yang menjalankan dlld versi 3.4.13 atau sebelumnya mungkin mengalami menonton kelaparan dan pengawasan sumber daya non-operasional, yang dapat menyebabkan masalah berikut:

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

Masalah ini dapat menyebabkan cluster tidak berfungsi.

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

Solusi

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

Untuk melihat metrik ini di Metrics Explorer:

Buka Metrics Explorer di konsol Google Cloud:
Buka Metrics Explorer
Pilih tab Configuration
Luaskan Pilih metrik, masukkan Kubernetes Container di panel filter, lalu gunakan submenu untuk memilih metrik:
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

GKE Identity Service dapat menyebabkan latensi bidang kontrol

Saat cluster dimulai ulang atau diupgrade, GKE Identity Service dapat memperoleh kewalahan dengan traffic yang terdiri dari token JWT kedaluwarsa yang diteruskan dari kube-apiserver ke GKE Identity Service selama webhook otentikasi. Meskipun GKE Identity Service tidak {i>crashloop <i}menjadi tidak responsif dan berhenti melayani permintaan lebih lanjut. Masalah ini pada akhirnya menyebabkan latensi bidang kontrol yang lebih tinggi.

Masalah ini telah diperbaiki dalam rilis Google Distributed Cloud berikut:

1.12.6+
1.13.6+
1.14.2+

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

Periksa apakah endpoint GKE Identity Service dapat dijangkau secara eksternal:
```
curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
```
Ganti CLUSTER_ENDPOINT dengan VIP bidang kontrol dan port load balancer bidang kontrol untuk (misalnya, 172.16.20.50:443).

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

Periksa log kube-apiserver dan GKE Identity Service:

Periksa log GKE Identity Service:

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

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

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

Periksa log kube-apiserver untuk cluster Anda:

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

Cluster Admin:

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

Cluster pengguna:

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

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

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

Solusi

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

Tingkatkan level verbositas GKE Identity Service ke 9:

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

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

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

Untuk mendapatkan payload token yang terkait dengan setiap konteks token yang tidak valid, mengurai setiap rahasia akun layanan terkait dengan perintah berikut:
```
kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
```
Untuk mendekode token dan melihat nama pod sumber dan namespace, salin token ke debugger di jwt.io.
Mulai ulang pod yang diidentifikasi dari token.

Operasi

1.8, 1.9, 1.10

Masalah peningkatan penggunaan memori pada pod pemeliharaan etcd

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

Solusi:

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

Opsi 2: Jika Anda menggunakan versi patch yang lebih lama dari 1.9.6 dan 1.10.3, Anda perlu menurunkan skala pod pemeliharaan etcd untuk admin dan cluster pengguna:

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

Operasi

1.9, 1.10, 1.11, 1.12, 1.13

Melewatkan health check pod bidang kontrol cluster pengguna

Pengontrol kondisi cluster dan perintah gkectl diagnose cluster melakukan serangkaian health check, termasuk health check pod di seluruh namespace. Namun, pod mulai melewati pod bidang kontrol pengguna secara tidak sengaja. Mode bidang kontrol v2 tidak akan memengaruhi cluster Anda.

Solusi:

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

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

Upgrade, Update

1,6+, 1,7+

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

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

Solusi:

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

Jaringan

1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

Melihat kegagalan validasi pada pembuatan load balancer

gkectl create loadbalancer gagal dengan pesan error berikut:

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

Hal ini terjadi karena file grup jungkat-jungkit sudah ada. Dan pemeriksaan preflight mencoba memvalidasi load balancer jungkat-jungkit yang tidak ada.

Solusi:

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

Jaringan

1,14

Waktu tunggu aplikasi yang disebabkan oleh kegagalan penyisipan tabel conntrack

Google Distributed Cloud versi 1.14 rentan terhadap netfilter kegagalan penyisipan tabel pelacakan koneksi (conntrack) saat menggunakan {i>image<i} sistem operasi Ubuntu atau COS. Kegagalan penyisipan menyebabkan acak aplikasi telah habis dan dapat terjadi bahkan ketika tabel conntrack memiliki ruang untuk entri baru. Kegagalan disebabkan oleh perubahan {i>kernel<i} 5.15 dan yang lebih tinggi yang membatasi penyisipan tabel berdasarkan rantai paruh.

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

sudo conntrack -S

Responsnya akan terlihat seperti ini:

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

Jika nilai chaintoolong dalam respons adalah bukan nol nomor tersebut, Anda terpengaruh oleh masalah ini.

Solusi

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

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

Ganti TABLE_SIZE dengan ukuran baru dalam byte. Tujuan nilai ukuran tabel default adalah 262144. Sebaiknya Anda menetapkan bernilai 65.536 kali jumlah inti pada {i>node<i}. Misalnya, jika node Anda memiliki delapan core, tetapkan ukuran tabel ke 524288.

Jaringan

1.13.0-1.13.2

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

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

Alasannya adalah karena kedua deployment ini menoleransi semua taint, termasuk taint node Windows.

Solusi:

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

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

Hapus spec.template.spec.tolerations berikut:

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

Dan tambahkan toleransi berikut:

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

Konfigurasi

1.14.0-1.14.2

File kredensial registry pribadi cluster pengguna tidak dapat dimuat

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

[FAILURE] Docker registry access: Failed to login.

Solusi:

Jika Anda tidak ingin menentukan kolom ini atau ingin menggunakan kolom yang sama pribadi sebagai cluster admin, Anda cukup menghapus atau memberi komentar di bagian privateRegistry di cluster pengguna Anda file konfigurasi.
Jika Anda ingin menggunakan kredensial registry pribadi tertentu untuk cluster pengguna, Anda dapat menentukan privateRegistry untuk sementara seperti ini:
```
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
```
(CATATAN: Ini hanya perbaikan sementara dan bidang ini sudah tidak digunakan lagi, pertimbangkan untuk menggunakan file kredensial saat mengupgrade ke 1.14.3+.)

Operasi

1,10 dan yang lebih baru

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

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

Ini direpresentasikan dalam mode bebas kube-proxy karena hilangnya konektivitas atau pemilihan rute traffic yang salah untuk layanan dengan Cloud Service Mesh karena file bantuan tidak dapat melakukan pemeriksaan paket.

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

Solusi:

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

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

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

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

Penyimpanan

1.12+, 1.13.3

`kube-controller-manager` mungkin melepaskan volume persisten dengan kuat setelah 6 menit

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

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

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

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

# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

Di log kubelet, pesan error seperti berikut akan ditampilkan:

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

Solusi:

Hubungkan ke node yang terpengaruh menggunakan SSH, lalu mulai ulang node.

Upgrade, Update

1,12+, 1,13+, 1,14+

Upgrade cluster terhenti jika driver CSI pihak ketiga digunakan

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

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

Solusi:

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

Operasi

1,10+, 1,11+, 1,12+, 1,13+, 1,14+

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

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

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

Solusi:

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

Sistem operasi

1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+

VM merilis sewa DHCP saat dimatikan/dimulai ulang secara tiba-tiba, yang mungkin mengakibatkan perubahan IP

Dalam systemd v244, systemd-networkd memiliki perubahan perilaku default pada konfigurasi KeepConfiguration. Sebelum perubahan ini, VM tidak mengirim pesan rilis sewa DHCP ke server DHCP pada mematikan atau memulai ulang. Setelah perubahan ini, VM mengirim pesan tersebut dan mengembalikan IP ke server DHCP. Akibatnya, IP yang dirilis mungkin dialokasikan ulang ke VM lain dan/atau IP yang berbeda mungkin ditetapkan ke VM, yang mengakibatkan konflik IP (di level Kubernetes, bukan level vSphere) dan/atau IP pada VM, yang dapat merusak cluster dengan berbagai cara.

Misalnya, Anda mungkin melihat gejala berikut.

UI vCenter menunjukkan bahwa tidak ada VM yang menggunakan IP yang sama, tetapi

kubectl get
        nodes -o wide

menampilkan node dengan IP duplikat.

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

Node baru gagal dimulai karena error calico-node

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

Solusi:

Deploy DaemonSet berikut di cluster untuk mengembalikan systemd-networkd perubahan perilaku default. VM yang menjalankan DaemonSet ini tidak akan melepaskan IP ke server DHCP pada mematikan/memulai ulang. IP akan dibebaskan secara otomatis oleh server DHCP kapan masa sewa berakhir.

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

Operasi, Upgrade, Update

1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

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

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

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

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

Jika Anda mendapati bahwa output-nya kosong, berarti kunci telah dihapus.

Setelah kunci akun layanan akses komponen dihapus, menginstal klaster pengguna baru atau meningkatkan klaster pengguna yang ada gagal. Berikut ini daftar beberapa pesan error yang mungkin Anda temui:

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

Solusi:

Menambahkan kembali kunci akun layanan akses komponen ke rahasia secara manual dengan menjalankan perintah berikut:

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

Operasi

1.13.0+, 1.14.0+

Penskala otomatis cluster tidak berfungsi saat Controlplane V2 diaktifkan

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

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

Pod autoscaler cluster dapat ditemukan dengan menjalankan perintah berikut.

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

Solusi:

Nonaktifkan penskalaan otomatis di semua kumpulan node dengan `gkectl update cluster` hingga diupgrade ke versi yang memiliki perbaikan

Penginstalan

1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

CIDR tidak diizinkan dalam file blok IP

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

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

Solusi:

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

Upgrade, Update

1.14.0-1.14.1

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

Saat Memperbarui jenis image OS bidang kontrol di admin-cluster.yaml, dan jika cluster pengguna yang sesuai dibuat melalui Controlplane V2, mesin bidang kontrol pengguna mungkin tidak menyelesaikan pembuatan ulang saat perintah gkectl selesai.

Solusi:

Setelah update selesai, tunggu hingga mesin bidang kontrol pengguna juga menyelesaikan pembuatan ulang dengan memantau jenis image OS node menggunakan kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. mis. Jika memperbarui dari Ubuntu ke COS, kita harus menunggu sampai semua mesin bidang kontrol berubah sepenuhnya dari Ubuntu ke COS bahkan setelah perintah pembaruan selesai.

Operasi

1.10, 1.11, 1.12, 1.13, 1.14.0

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

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

  error getting ClusterInformation: connection is unauthorized: Unauthorized

Masalah ini hanya terjadi 24 jam setelah klaster dibuat atau diupgrade ke versi 1.14 menggunakan Calico.

Cluster admin selalu menggunakan Calico, sedangkan untuk cluster pengguna kolom konfigurasi `enableDataPlaneV2` di user-cluster.yaml, jika kolom itu diatur ke `false`, atau tidak ditentukan, itu berarti Anda menggunakan Calico di bagian .

Beberapa node Container install-cni membuat kubeconfig dengan token yang berlaku selama 24 jam. Token ini harus dikirimkan secara berkala diperpanjang oleh Pod calico-node. calico-node Pod tidak dapat memperpanjang token karena tidak memiliki akses ke direktori yang berisi file {i> kubeconfig<i} pada {i>node<i}.

Solusi:

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

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

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

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

Ganti yang berikut:

ADMIN_CLUSTER_KUBECONFIG: jalur pada file kubeconfig cluster admin.
USER_CLUSTER_CONFIG_FILE: jalur dari file konfigurasi cluster pengguna Anda.

Penginstalan

1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

Validasi blok IP gagal saat menggunakan CIDR

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

Solusi:

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

Operasi, Upgrade, Update

1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

Pencadangan cluster admin tidak menyertakan konfigurasi dan kunci enkripsi rahasia yang selalu aktif

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

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

Solusi:

Gunakan biner gkectl dari versi patch terbaru yang tersedia untuk versi minor terkait untuk melakukan pencadangan cluster admin setelah operasi cluster penting. Misalnya, jika cluster menjalankan versi 1.10.2, gunakan biner 1.10.5 gkectl untuk melakukan pencadangan cluster admin secara manual seperti yang dijelaskan dalam Mencadangkan dan Memulihkan cluster admin dengan gkectl.

Operasi, Upgrade, Update

1,10 dan yang lebih baru

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

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

Upgrade, Update

1.10

Mengupgrade cluster pengguna pertama dari 1.9 ke 1.10 akan membuat ulang node di cluster pengguna lain

Mengupgrade cluster pengguna pertama dari 1.9 ke 1.10 dapat membuat ulang node di cluster pengguna lain pada cluster admin yang sama. Pembuatan ulang dilakukan secara bergelombang.

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

Solusi:

Lihat langkah-langkah solusi

Perkecil skala replika clusterapi-controllers menjadi 0 untuk semua cluster pengguna.

kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Upgrade setiap cluster pengguna satu per satu.

Upgrade, Update

1.10.0

Docker sering dimulai ulang setelah upgrade cluster

Mengupgrade cluster pengguna ke 1.10.0 dapat menyebabkan Docker sering dimulai ulang.

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

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

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

Untuk memahami akar masalah, Anda perlu melakukan SSH ke node yang memiliki gejala dan menjalankan perintah seperti sudo journalctl --utc -u docker atau sudo journalctl -x

Solusi:

Menggunakan container untuk runtime container
Mengupgrade cluster ke versi terbaru 1.10

Upgrade, Update

1.11, 1.12

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

Jika Anda menggunakan Google Distributed Cloud versi di bawah 1.12, dan telah menyiapkan komponen Prometheus yang dikelola Google (GMP) secara manual di gmp-system untuk cluster Anda, komponen tidak dipertahankan saat Anda upgrade ke versi 1.12.x.

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

Solusi:

Cadangkan semua resource kustom (CR) PodMonitoring yang ada.
Upgrade semua cluster ke versi 1.12, dan aktifkan Managed Service for Prometheus.
Deploy ulang CR PodMonitoring.

Operasi

1.11, 1.12, 1.13.0 - 1.13.1

Objek ClusterAPI tidak ada dalam skenario `system` snapshot cluster

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

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

Solusi:

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

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

dalam hal ini:

USER_CLUSTER_KUBECONFIG adalah cluster pengguna {i>kubeconfig<i}.

Upgrade, Update

1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

Penghapusan cluster pengguna terhenti di pengurasan node untuk penyiapan vSAN

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

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

Untuk mengidentifikasi gejala, jalankan perintah di bawah:

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

Berikut adalah contoh pesan error dari perintah di atas:

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

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

Solusi:

Buat direktori kubevols di datastore tempat node dibuat. Ini ditentukan di kolom vCenter.datastore dalam file user-cluster.yaml atau admin-cluster.yaml.

Konfigurasi

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

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

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

Gejalanya adalah sebagai berikut:

cluster-autoscaler log

kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler

ADMIN_CLUSTER_KUBECONFIG

2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

Solusi:

Lihat langkah-langkah solusi

Periksa apakah clusterrole dan clusterrolebinding hilang di cluster admin

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

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

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

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
  resources: ["clusters"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
  resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
  resources: ["onpremuserclusters"]
  verbs: ["get", "list", "watch"]
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  resourceNames: ["cluster-autoscaler"]
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
  - ""
  resources:
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - ""
  resources:
  - pods/eviction
  verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
  resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["poddisruptionbudgets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "csinodes"]
  verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["cluster-autoscaler-status"]
  verbs: ["get", "update", "patch", "delete"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: cluster-autoscaler
  name: cluster-autoscaler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-autoscaler
subjects:
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_1 
  - kind: ServiceAccount
  name: cluster-autoscaler
  namespace:  NAMESPACE_OF_USER_CLUSTER_2 
  ...

Konfigurasi

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

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

Saat penghapusan cluster pengguna, clusterrole yang sesuai juga akan dihapus, yang mengakibatkan perbaikan otomatis dan pengekspor metrik vsphere tidak berfungsi

Gejalanya adalah sebagai berikut:

cluster-health-controller log

kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller

ADMIN_CLUSTER_KUBECONFIG

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

ADMIN_CLUSTER_KUBECONFIG

vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

Solusi:

Lihat langkah-langkah solusi

Terapkan yaml berikut ke cluster admin

Untuk vsphere-metrics-exporter

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: vsphere-metrics-exporter
rules:
  - apiGroups:
      - cluster.k8s.io
    resources:
      - clusters
    verbs: [get, list, watch]
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: vsphere-metrics-exporter
  name: vsphere-metrics-exporter
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: vsphere-metrics-exporter
subjects:
  - kind: ServiceAccount
    name: vsphere-metrics-exporter
    namespace: kube-system

Untuk cluster-health-controller

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-health-controller-role
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - "*"

Konfigurasi

1.12.1-1.12.3, 1.13.0-1.13.2

`gkectl check-config` gagal saat validasi image OS

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

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

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

Solusi:

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

Opsi 2: gunakan gkectl check-config --skip-validation-os-images untuk melewati validasi image OS.

Upgrade, Update

1.11, 1.12, 1.13

`gkectl update admin/cluster` gagal memperbarui grup anti

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

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

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

Solusi:

Lihat langkah-langkah solusi

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

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

Untuk update cluster pengguna, node pekerja pengguna harus dibuat ulang

Untuk membuat ulang node pekerja pengguna

Opsi 1
Ikuti cara memperbarui kumpulan node dan mengubah CPU atau memori untuk memicu pembuatan ulang node secara berkelanjutan.

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

kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG

Untuk membuat ulang node master pengguna

Opsi 1
Ikuti mengubah ukuran bidang kontrol dan ubah CPU atau memori untuk memicu pembuatan ulang node secara berkelanjutan.

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

kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

Untuk membuat ulang node add-on admin

Menggunakan kubectl delete untuk membuat ulang mesin satu per satu

kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG

Penginstalan, Upgrade, Update

1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

Node gagal didaftarkan jika nama host yang dikonfigurasi berisi titik

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

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

kubectl get csr -A -o wide

Periksa log berikut untuk pesan error:

Lihat log di cluster admin untuk Penampung clusterapi-controller-manager di Pod clusterapi-controllers:

kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

Jika Anda menentukan nama domain di ruang isian {i>host <i}dari file blok IP, karakter apa pun setelah titik pertama akan diabaikan. Misalnya, jika Anda menentukan nama host sebagai bob-vm-1.bank.plc, VM nama host dan nama node akan ditetapkan ke bob-vm-1.

Bila verifikasi ID node diaktifkan, pemberi persetujuan CSR akan membandingkan nama node dengan nama host di spesifikasi Perangkat, dan gagal merekonsiliasi namanya. Pemberi persetujuan menolak CSR, dan node gagal kerangka kerja internal.

Solusi:

Cluster pengguna

Nonaktifkan verifikasi ID node dengan menyelesaikan langkah-langkah berikut:

Tambahkan kolom berikut di file konfigurasi cluster pengguna Anda:

disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true

Simpan file, dan perbarui cluster pengguna dengan menjalankan perintah berikut berikut:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
```
Ganti yang berikut:
- ADMIN_CLUSTER_KUBECONFIG: jalur pada file kubeconfig cluster admin.
- USER_CLUSTER_CONFIG_FILE: jalur dari file konfigurasi cluster pengguna Anda.

Cluster Admin

Buka resource kustom OnPremAdminCluster untuk pengeditan:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system

Tambahkan anotasi berikut ke resource kustom:

features.onprem.cluster.gke.io/disable-node-id-verification: enabled

Mengedit manifes kube-controller-manager di admin bidang kontrol cluster:
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
```

Buka pengontrol Deployment Cluster API untuk mengedit:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system

Ubah nilai node-id-verification-enabled dan node-id-verification-csr-signing-enabled hingga false:
```
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
```

Penginstalan, Upgrade, Update

1.11.0-1.11.4

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

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

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

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

Invalid value 'XXXX' specified for property startup-data

Berikut adalah contoh jalur file untuk log pengontrol Cluster API:

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

Networking

1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

`NetworkGatewayNodes` marked unhealthy from concurrent status update conflict

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

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

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

Status NotHealthy mencegah pengontrol menetapkan IP mengambang tambahan ke {i>node<i}. Hal ini dapat mengakibatkan beban pada {i>node <i}lain atau kurangnya redundansi untuk ketersediaan tinggi.

Aktivitas Dataplane tidak akan terpengaruh.

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

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

Solusi:

Upgrade ke versi tetap, jika tersedia.

Upgrade, Update

1.12.0-1.12.2, 1.13.0

Kondisi race memblokir penghapusan objek mesin selama dan pembaruan atau upgrade

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

Gejalanya adalah waktu perintah gkectl habis dengan pesan error berikut:

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

Di clusterapi-controller log Pod, error-nya seperti di bawah ini:

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

{i>Error <i}terulang untuk komputer yang sama selama beberapa menit untuk berhasil bahkan tanpa masalah ini, hampir selalu dapat dilakukan dengan cepat, tetapi untuk beberapa kasus yang jarang terjadi, error ini dapat terhenti di proses ini selama beberapa jam.

Masalahnya adalah VM yang mendasarinya sudah dihapus di vCenter, tetapi objek mesin terkait tidak dapat dihapus, yang macet di penghapusan finaler karena pembaruan yang sangat sering dari {i>controller<i} lain. Hal ini dapat menyebabkan waktu tunggu perintah gkectl habis, tetapi pengontrol terus merekonsiliasi cluster sehingga proses upgrade atau update pada akhirnya akan selesai.

Solusi:

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

Opsi 1: Tunggu hingga upgrade selesai pada akhirnya itu sendiri.

Berdasarkan analisis dan reproduksi di lingkungan Anda, upgrade pada akhirnya dapat selesai dengan sendirinya tanpa intervensi manual apa pun. Tujuan peringatan dari opsi ini adalah bahwa tidak ada pasti berapa lama waktu yang dibutuhkan penghapusan finaler yang akan dilakukan untuk setiap objek mesin. Bisa Segera jika cukup beruntung, atau bisa berlangsung selama beberapa jam jika rekonsiliasi pengontrol {i> machineset<i} terlalu cepat dan komputer {i>controller<i} tidak pernah mendapat kesempatan untuk menghapus finaler di antara rekonsiliasi.

Untungnya, opsi ini tidak memerlukan tindakan apa pun dari tambahan, dan beban kerja tidak akan terganggu. Hanya perlu waktu yang lebih lama untuk menyelesaikan upgrade.
Opsi 2: Terapkan anotasi perbaikan otomatis ke semua perangkat lama objek terstruktur dalam jumlah besar.

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

Kelemahannya adalah pod pada komputer akan langsung dihapus bukannya dikeluarkan, yang berarti ia tidak akan menghormati konfigurasi PDB, hal ini berpotensi menyebabkan periode nonaktif untuk beban kerja Anda.

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

Jika Anda mengalami masalah ini dan upgrade atau update masih tidak dapat diselesaikan setelah sekian lama, kontak tim dukungan kami untuk melakukan mitigasi.

Penginstalan, Upgrade, Update

1.10.2, 1.11, 1.12, 1.13

`gkectl` menyiapkan kegagalan preflight validasi image OS

Perintah gkectl prepare gagal dengan:

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

Pemeriksaan preflight gkectl prepare mencakup validasi yang salah.

Solusi:

Jalankan perintah yang sama dengan flag tambahan --skip-validation-os-images.

Penginstalan

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

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

Cluster admin gagal dibuat karena:

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

URL digunakan sebagai bagian dari kunci Rahasia, yang tidak dukung "/" atau ":".

Solusi:

Hapus awalan https:// atau http:// dari Kolom vCenter.Address di cluster admin atau cluster pengguna konfigurasi yaml.

Penginstalan, Upgrade, Update

1.10, 1.11, 1.12, 1.13

`gkectl prepare` panik di `util.CheckFileExists`

gkectl prepare dapat panik dengan hal berikut stacktrace:

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

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

Masalahnya adalah gkectl prepare membuat direktori sertifikat {i>registry<i} dengan izin yang salah.

Solusi:

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

sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS

Upgrade, Update

1.10, 1.11, 1.12, 1.13

Upgrade admin yang dapat dilanjutkan dan `gkectl repair admin-master` adalah tidak bekerja sama

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

Solusi:

Jika Anda pernah mengalami skenario kegagalan ini, hubungi dukungan.

Upgrade, Update

1.10, 1.11

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

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

Solusi:

Template VM bidang kontrol admin akan dibuat ulang selama upgrade cluster admin.

Sistem operasi

1,12, 1,13

cgroup v2 dapat memengaruhi workload

Di versi 1.12.0, cgroup v2 (terpadu) diaktifkan secara {i>default<i} untuk Node Container Optimized OS (COS). Hal ini berpotensi menimbulkan ketidakstabilan untuk beban kerja Anda dalam klaster COS.

Solusi:

Kami beralih kembali ke cgroup v1 (hybrid) di versi 1.12.1. Jika Anda menggunakan node COS, sebaiknya segera tingkatkan ke versi 1.12.1 saat dirilis.

Identitas

1.10, 1.11, 1.12, 1.13

Resource kustom ClientConfig

gkectl update mengembalikan perubahan manual yang Anda miliki yang dibuat ke resource kustom ClientConfig.

Solusi:

Kami sangat menyarankan agar Anda mencadangkan resource ClientConfig setelah setiap perubahan manual.

Penginstalan

1.10, 1.11, 1.12, 1.13

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

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

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

Solusi:

Coba jalankan gkectl check-config lagi.

Penginstalan

1.12

Penginstalan cluster pengguna gagal karena perintah cert-manager/ca-injector masalah pemilu pemimpin

Anda mungkin melihat kegagalan instalasi karena cert-manager-cainjector dalam crashloop, saat apiserver/etcd lambat:

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

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

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

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

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

Solusi:

Lihat langkah-langkah solusi

Jalankan perintah berikut untuk memitigasi masalah.

Pertama, perkecil monitoring-operator agar tidak kembalikan perubahan ke Deployment cert-manager:

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

Edit Deployment cert-manager-cainjector untuk menonaktifkan pemilihan pemimpin, karena kita hanya punya satu replika yang berjalan. Tidak yang diperlukan untuk satu replika:

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

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

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

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

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

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

Setelah setiap upgrade, perubahan akan dikembalikan. Lakukan hal yang sama langkah lagi untuk memitigasi masalah hingga masalah ini diperbaiki di masa mendatang data.

VMware

1.10, 1.11, 1.12, 1.13

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

Jika vCenter, untuk versi yang lebih rendah dari 7.0U2, dimulai ulang, setelah atau jika tidak, nama jaringan dalam informasi vm dari vCenter adalah salah, dan menyebabkan komputer menggunakan Unavailable state. Hal ini pada akhirnya menyebabkan node otomatis diperbaiki yang baru.

Govmomi terkait bug.

Solusi:

Solusi ini disediakan oleh dukungan VMware:

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

Sistem operasi

1.10, 1.11, 1.12, 1.13

Koneksi SSH ditutup oleh host jarak jauh

Untuk Google Distributed Cloud versi 1.7.2 dan yang lebih baru, Ubuntu OS gambar diperkuat dengan Tolok Ukur Server CIS L1.

Untuk memenuhi aturan CIS "5.2.16 Pastikan SSH Idle Timeout Interval adalah dikonfigurasi", /etc/ssh/sshd_config memiliki hal berikut pengaturan:

ClientAliveInterval 300
ClientAliveCountMax 0

Tujuan setelan ini adalah untuk menghentikan sesi klien setelah 5 menit waktu tidak ada aktivitas. Namun, ClientAliveCountMax 0 nilai tersebut menyebabkan perilaku yang tidak diharapkan. Saat Anda menggunakan sesi ssh pada atau node cluster, koneksi SSH mungkin memutuskan hubungan bahkan klien ssh Anda tidak menganggur, seperti saat menjalankan memakan waktu lama, dan perintah Anda bisa dihentikan dengan pesan berikut:

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

Solusi:

Anda dapat:

Gunakan nohup agar perintah Anda tidak dihentikan pemutusan SSH,

nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig

Update sshd_config untuk menggunakan bilangan bukan nol Nilai ClientAliveCountMax. Aturan CIS menyarankan untuk menggunakan nilai kurang dari 3:
```
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd
```

Pastikan Anda menghubungkan kembali sesi SSH Anda.

Penginstalan

1.10, 1.11, 1.12, 1.13

Penginstalan `cert-manager` bertentangan

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

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

Catatan: Satu gejala umum saat menginstal pengelola sertifikat Anda sendiri adalah versi atau image cert-manager (misalnya v1.7.2) dapat dikembalikan ke versi lamanya. Hal ini disebabkan oleh monitoring-operator mencoba merekonsiliasi cert-manager, dan mengembalikan versi dalam proses.

Solusi:

<pMenghindari konflik selama upgrade

Uninstal versi cert-manager Anda. Jika Anda menentukan sumber daya Anda sendiri, Anda mungkin ingin cadangan mereka.

Lakukan upgrade.

Ikuti petunjuk berikut untuk memulihkan sandi Anda sendiri cert-manager.

Memulihkan pengelola sertifikat Anda sendiri di cluster pengguna

Skalakan Deployment monitoring-operator ke 0:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n USER_CLUSTER_NAME \ scale deployment monitoring-operator --replicas=0

Skalakan deployment cert-manager yang dikelola oleh monitoring-operator hingga 0:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-cainjector\ --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-webhook --replicas=0

Instal ulang versi cert-manager Anda. Pulihkan resource kustom jika ada.

Anda dapat melewati langkah ini jika menggunakan penginstalan pengelola sertifikat default upstream, atau Anda yakin cert-manager diinstal di namespace cert-manager. Jika tidak, salin cert-manager.io/v1 metrics-ca Sertifikat dan Penerbit metrics-pki.cluster.local resource dari cert-manager ke resource cluster namespace dari pengelola sertifikat yang terinstal.
relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f1=$(mktemp) f2=$(mktemp) kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get issuer -n cert-manager metrics-pki.cluster.local -o json \ | jq "${relevant_fields}" > $f1 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get certificate -n cert-manager metrics-ca -o json \ | jq "${relevant_fields}" > $f2 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1 kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

Memulihkan pengelola sertifikat Anda sendiri di cluster admin

Secara umum, Anda tidak perlu menginstal ulang cert-manager di admin karena cluster admin hanya menjalankan kontrol Google Distributed Cloud workload berbasis platform. Dalam kasus yang jarang terjadi, Anda juga perlu menginstal cert-manager di cluster admin, ikuti petunjuk berikut untuk menghindari konflik. Perlu diperhatikan, jika Anda adalah pelanggan Apigee dan Anda hanya memerlukan cert-manager untuk Apigee, Anda tidak perlu menjalankan admin menggunakan perintah cluster.

Skalakan deployment monitoring-operator ke 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n kube-system scale deployment monitoring-operator --replicas=0

Skalakan deployment cert-manager yang dikelola oleh monitoring-operator hingga 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager \ --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-cainjector \ --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ -n cert-manager scale deployment cert-manager-webhook \ --replicas=0

Instal ulang versi cert-manager Anda. Pulihkan resource kustom jika ada.

Anda dapat melewati langkah ini jika menggunakan penginstalan pengelola sertifikat default upstream, atau Anda yakin cert-manager diinstal di namespace cert-manager. Jika tidak, salin cert-manager.io/v1 metrics-ca Sertifikat dan Penerbit metrics-pki.cluster.local resource dari cert-manager ke resource cluster namespace dari pengelola sertifikat yang terinstal.
relevant_fields=' { apiVersion: .apiVersion, kind: .kind, metadata: { name: .metadata.name, namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE" }, spec: .spec } ' f3=$(mktemp) f4=$(mktemp) kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n get issuer -n cert-manager metrics-pki.cluster.local -o json \ | jq "${relevant_fields}" > $f3 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ get certificate -n cert-manager metrics-ca -o json \ | jq "${relevant_fields}" > $f4 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3 kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4

</p

Sistem operasi

1.10, 1.11, 1.12, 1.13

Positif palsu dalam pemindaian kerentanan Docker, containerd, dan runc

Docker, {i>containerd<i}, dan runc di {i>image<i} OS Ubuntu yang dikirimkan bersama Google Distributed Cloud disematkan ke versi khusus menggunakan PPA Ubuntu. Hal ini memastikan bahwa setiap perubahan runtime container akan memenuhi syarat oleh Google Distributed Cloud sebelum setiap rilis.

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

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

Lihat catatan rilis] untuk perbaikan CVE.

Solusi:

Kanonis mengetahui masalah ini, dan perbaikan dilacak di https://github.com/canonical/sec-cvescan/issues/73.

Upgrade, Update

1.10, 1.11, 1.12, 1.13

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

Jika Anda meningkatkan cluster non-HA dari 1,9 ke 1,10, Anda mungkin melihat bahwa kubectl exec, kubectl log, dan webhook terhadap klaster pengguna mungkin tidak tersedia untuk waktu yang singkat. Periode nonaktif ini dapat mencapai satu menit. Hal ini terjadi karena permintaan masuk (kubectl exec, kubectl log, dan webhook) ditangani oleh kube-apiserver untuk cluster pengguna. Pengguna kube-apiserver adalah Statefulset. Dalam cluster non-HA, hanya ada satu replika untuk Statefulset. Jadi selama peningkatan, ada kemungkinan bahwa versi kube-apiserver tidak tersedia saat kube-apiserver baru belum tersedia siap.

Solusi:

Periode nonaktif ini hanya terjadi selama proses upgrade. Jika Anda menginginkan lebih singkat selama peningkatan versi, sebaiknya Anda beralih ke HA cluster.

Penginstalan, Upgrade, Update

1.10, 1.11, 1.12, 1.13

Pemeriksaan kesiapan konektivitas gagal dalam diagnosis klaster HA setelah pembuatan atau upgrade cluster

Jika Anda membuat atau mengupgrade klaster HA dan melihat konektivitas pemeriksaan kesiapan gagal saat didiagnosis cluster. Dalam kebanyakan kasus, hal ini tidak akan memengaruhi fungsi Google Distributed Cloud (kubectl exec, kubectl log dan webhook). Hal ini terjadi karena terkadang satu atau dua dari replika konektivitas mungkin tidak siap untuk jangka waktu tertentu karena jaringan yang tidak stabil atau masalah lainnya.

Solusi:

Konnektivitas akan pulih dengan sendirinya. Tunggu selama 30 menit hingga 1 jam dan menjalankan kembali diagnosis cluster.

Sistem operasi

1.7, 1.8, 1.9, 1.10, 1.11

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

Mulai dari Google Distributed Cloud versi 1.7.2, OS Ubuntu gambar telah melalui proses hardening dengan Server CIS L1 Tolok ukur.

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

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

Solusi:

Jika lonjakan memengaruhi beban kerja, Anda dapat menonaktifkan {i>cron job <i}(tugas cron):

sudo chmod -x /etc/cron.daily/aide

Jaringan

1.10, 1.11, 1.12, 1.13

Load balancer dan aturan firewall terdistribusi stateful NSX-T berinteraksi tidak dapat diprediksi

Saat men-deploy Google Distributed Cloud versi 1.9 atau yang lebih baru, saat deployment memiliki load balancer paket Seesaw di lingkungan yang menggunakan aturan {i>firewall<i} terdistribusi stateful NSX-T, stackdriver-operator mungkin gagal dibuat gke-metrics-agent-conf ConfigMap dan penyebabnya gke-connect-agent Pod akan berada dalam loop error.

Masalah yang mendasarinya adalah bahwa firewall stateful NSX-T terdistribusi menghentikan koneksi dari klien ke API cluster pengguna server melalui load balancer Seesaw karena Seesaw menggunakan alur koneksi. Masalah integrasi dengan firewall terdistribusi NSX-T memengaruhi semua rilis Google Distributed Cloud yang menggunakan Seesaw. Anda mungkin melihat masalah koneksi serupa pada aplikasi Anda saat membuat objek Kubernetes besar yang ukurannya lebih dari 32K.

Solusi:

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

Jika cluster Anda menggunakan load balancer manual, ikuti petunjuk ini untuk mengonfigurasi load balancer Anda agar dapat menyetel ulang klien koneksi saat mendeteksi kegagalan node backend. Tanpa label ini klien server Kubernetes API mungkin berhenti merespons selama beberapa menit saat {i>instance<i} server mati.

Logging dan pemantauan

1.10, 1.11, 1.12, 1.13, 1.14, 1.15

Penagihan pemantauan yang tidak terduga

Untuk Google Distributed Cloud versi 1.10 hingga 1.15, beberapa pelanggan memiliki menemukan tagihan tinggi yang tidak terduga untuk Metrics volume pada Halaman Penagihan. Masalah ini hanya mempengaruhi Anda ketika semua keadaan berikut berlaku:

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

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

Solusi

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

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

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

Hapus baris enableStackdriverForApplications: true, simpan dan tutup editor.

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

Temukan Pod dan Service sumber yang memiliki metrik penagihan yang tidak diinginkan.

kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'

Hapus anotasi prometheus.io/scrap=true dari Pod atau Service. Jika anotasi ditambahkan oleh Cloud Service Mesh, pertimbangkan mengonfigurasi Cloud Service Mesh tanpa opsi Prometheus, atau menonaktifkan fitur Penggabungan Metrik Istio.

Penginstalan

1.11, 1.12, 1.13

Penginstal gagal saat membuat datadisk vSphere

Penginstal Google Distributed Cloud dapat gagal jika peran khusus terikat di tingkat izin yang salah.

Ketika pengikatan peran salah, membuat datadisk vSphere dengan govc mengalami hang dan disk dibuat dengan ukuran 0. Kepada memperbaiki masalah ini, Anda harus mengikat peran khusus di vSphere vCenter tingkat (root).

Solusi:

Jika Anda ingin mengikat peran khusus di tingkat DC (atau lebih rendah dari {i>root<i}), Anda juga harus mengikat peran {i>read-only<i} ke pengguna di {i>root<i} Tingkat vCenter.

Untuk informasi selengkapnya tentang pembuatan peran, lihat Hak istimewa akun pengguna vCenter.

Logging dan pemantauan

1.9.0-1.9.4, 1.10.0-1.10.1

Traffic jaringan yang tinggi ke monitoring.googleapis.com

Anda mungkin melihat lalu lintas jaringan yang tinggi ke monitoring.googleapis.com, bahkan dalam cluster baru yang belum memiliki yang dioptimalkan untuk workload pengguna.

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

Solusi:

Lihat langkah-langkah solusi

Upgrade ke versi 1.10.2/1.9.5 atau yang lebih baru.

Untuk mengurangi masalah ini pada versi sebelumnya:

Perkecil skala `stackdriver-operator`:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system \
    scale deployment stackdriver-operator --replicas=0

Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna file kubeconfig cluster.

Buka ConfigMap gke-metrics-agent-conf untuk mengedit:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system \
    edit configmap gke-metrics-agent-conf

Tingkatkan interval pemeriksaan dari 0,1 detik menjadi 13 detik:

  processors:
    disk_buffer/metrics:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-metrics
      probe_interval: 13s
      retention_size_mib: 6144
  disk_buffer/self:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-self
      probe_interval: 13s
      retention_size_mib: 200
    disk_buffer/uptime:
      backend_endpoint: https://monitoring.googleapis.com:443
      buffer_dir: /metrics-data/nsq-metrics-uptime
      probe_interval: 13s
      retention_size_mib: 200

Tutup sesi pengeditan.

Ubah versi gke-metrics-agent DaemonSet menjadi 1.1.0-anthos.8:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  \
  --namespace kube-system  set image daemonset/gke-metrics-agent \
  gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8

Logging dan pemantauan

1.10, 1.11

`gke-metrics-agent` sering mengalami error CrashLoopBackOff

Untuk Google Distributed Cloud versi 1.10 dan yang lebih baru, `gke-metrics-agent` DaemonSet sering mengalami error CrashLoopBackOff saat `enableStackdriverForApplications` ditetapkan ke `true` di `stackdriver` .

Solusi:

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

Untuk mencegah perubahan berikut tidak dikembalikan, turunkan skala stackdriver-operator:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
```
Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna file kubeconfig cluster.

Buka ConfigMap gke-metrics-agent-conf untuk mengedit:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf

Di bagian services.pipelines, jadikan seluruh komentar sebagai komentar Bagian metrics/app-metrics:

services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics

Tutup sesi pengeditan.

Mulai ulang DaemonSet gke-metrics-agent:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent

Logging dan pemantauan

1.11, 1.12, 1.13

Mengganti metrik yang tidak digunakan lagi di dasbor

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

gcloud monitoring dashboards list > all-dashboard.json

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

Metrik yang tidak digunakan lagi berikut harus dimigrasikan ke pengganti.

Tidak digunakan lagi	Penggantian
`kube_daemonset_updated_number_scheduled`	`kube_daemonset_status_updated_number_scheduled`
`kube_node_status_allocatable_cpu_cores` `kube_node_status_allocatable_memory_bytes` `kube_node_status_allocatable_pods`	`kube_node_status_allocatable`
`kube_node_status_capacity_cpu_cores` `kube_node_status_capacity_memory_bytes` `kube_node_status_capacity_pods`	`kube_node_status_capacity`
`kube_hpa_status_current_replicas`	`kube_horizontalpodautoscaler_status_current_replicas`

Solusi:

Untuk mengganti metrik yang tidak digunakan lagi

Menghapus "status node lokal GKE" di Google Cloud Monitoring dasbor. Instal ulang "status node lokal GKE" mengikuti petunjuk ini.
Menghapus "Penggunaan node lokal GKE" di Google Cloud Monitoring dasbor. Instal ulang "Penggunaan node lokal GKE" mengikuti petunjuk ini.
Menghapus "kondisi vm vSphere lokal GKE" di lapisan Dasbor pemantauan. Instal ulang "kondisi vm vSphere lokal GKE" mengikuti petunjuk ini.

Penghentian ini terjadi karena upgrade agen kube-state-metrics dari v1.9 hingga v2.4, yang diperlukan untuk Kubernetes 1.22. Anda dapat mengganti semua yang tidak digunakan lagi kube-state-metrics metrik, yang memiliki awalan kube_, di dasbor kustom atau kebijakan pemberitahuan.

Logging dan pemantauan

1.10, 1.11, 1.12, 1.13

Data metrik tidak diketahui di Cloud Monitoring

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

Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary

Meskipun metrik jenis ringkasan ini ada dalam daftar metrik, didukung oleh gke-metrics-agent saat ini.

Logging dan pemantauan

1.10, 1.11, 1.12, 1.13

Metrik tidak ada di beberapa node

Anda mungkin mendapati bahwa metrik berikut tidak ada di beberapa, tetapi tidak semua, node:

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

Solusi:

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

Buka referensi stackdriver untuk mengedit:

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

Untuk meningkatkan permintaan CPU gke-metrics-agent dari 10m hingga 50m, batas CPU dari 100m ke 200m tambahkan resourceAttrOverride berikut ke manifes stackdriver :

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi

Resource yang Anda edit akan terlihat seperti berikut:

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Simpan perubahan Anda dan tutup editor teks.
Untuk memastikan bahwa perubahan telah diterapkan, jalankan perintah berikut:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
```
Perintah tersebut menemukan cpu: 50m jika hasil edit Anda telah diterapkan.

Logging dan pemantauan

1.11.0-1.11.2, 1.12.0

Metrik penjadwal dan pengontrol-pengelola tidak ada di cluster admin

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

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

Solusi:

Upgrade ke v1.11.3+, v1.12.1+, atau v1.13+.

1.11.0-1.11.2, 1.12.0

Metrik penjadwal dan pengontrol-pengelola tidak ada di cluster pengguna

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

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

Solusi:

Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.13.0 dan yang lebih baru. Upgrade cluster Anda ke versi yang memiliki perbaikan.

Penginstalan, Upgrade, Update

1.10, 1.11, 1.12, 1.13

Gagal mendaftarkan cluster admin selama pembuatan

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

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

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

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

Solusi:

Lihat langkah-langkah solusi

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

Jalankan gkectl update admin untuk mendaftarkan cluster admin dengan kunci akun layanan yang benar.

Buat akun layanan khusus untuk mem-patch Resource kustom OnPremAdminCluster.

export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

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

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

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

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: modify-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: modify-admin-role
subjects:
- kind: ServiceAccount
  name: modify-admin
  namespace: kube-system
EOF

Ganti ADMIN_CLUSTER_KUBECONFIG dengan jalur admin Anda file kubeconfig cluster.

Jalankan perintah ini untuk mengupdate OnPremAdminCluster resource kustom.

export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG

SERVICE_ACCOUNT=modify-admin

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

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

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

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

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

# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
    --header "Authorization: Bearer $TOKEN" -XPATCH \
    -H "Content-Type: application/merge-patch+json" \
    --cacert /tmp/ca.crt \
    --data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
    $APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status

Coba upgrade cluster admin lagi dengan --disable-upgrade-from-checkpoint.
```
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-upgrade-from-checkpoint
```
Ganti ADMIN_CLUSTER_CONFIG dengan jalur admin Anda file konfigurasi cluster Anda.

Identitas

1.10, 1.11, 1.12, 1.13

Menggunakan GKE Identity Service dapat menyebabkan Hubungkan Agen untuk memulai ulang secara tidak terduga

Jika Anda menggunakan Layanan Identitas GKE fitur untuk mengelola GKE Identity Service ClientConfig, Connect Agent mungkin dimulai ulang secara tiba-tiba.

Solusi:

Jika pernah mengalami masalah pada cluster yang ada, Anda dapat melakukannya salah satu hal berikut:

Nonaktifkan GKE Identity Service. Jika Anda menonaktifkan GKE Identity Service, yang tidak akan menghapus layanan yang telah di-deploy Biner GKE Identity Service atau hapus ClientConfig. Untuk menonaktifkan GKE Identity Service, jalankan perintah ini:
```
gcloud container fleet identity-service disable \
    --project PROJECT_ID
```
Ganti PROJECT_ID dengan ID cluster project host fleet.
Update cluster ke versi 1.9.3 atau yang lebih baru, atau versi 1.10.1 atau nanti, untuk mengupgrade versi Connect Agent.

Jaringan

1.10, 1.11, 1.12, 1.13

Cisco ACI tidak berfungsi dengan Direct Server Return (DSR)

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

Solusi:

Solusi yang mungkin dilakukan adalah menonaktifkan pembelajaran IP dengan menambahkan IP Seesaw sebagai IP Virtual L4-L7 dalam Kebijakan Aplikasi Cisco Pengontrol Infrastruktur (APIC).

Anda dapat mengkonfigurasi opsi L4-L7 Virtual IP dengan membuka Tenant > Profil Aplikasi > EPG aplikasi atau EPG uSeg. Gagal menonaktifkan pemelajaran IP akan mengakibatkan timbulnya titik akhir IP antara lokasi yang berbeda di fabric Cisco API.

VMware

1.10, 1.11, 1.12, 1.13

vSphere 7.0 Memperbarui 3 masalah

VMWare baru-baru ini mengidentifikasi masalah kritis terkait Rilis vSphere 7.0 Pembaruan 3:

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

Solusi:

VMWare menghapus rilis ini. Anda harus mengupgrade ESXi dan vCenter Server ke versi yang lebih baru.

Sistem operasi

1.10, 1.11, 1.12, 1.13

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

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

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

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

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

Solusi:

Lihat langkah-langkah solusi

Terapkan resource DaemonSet, misalnya:

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

Upgrade, Update

1.10, 1.11, 1.12, 1.13

Update replika kumpulan node cluster tidak berfungsi setelah penskalaan otomatis telah dinonaktifkan pada kumpulan node

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

Solusi:

Menghapus cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size dan cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size anotasi dari deployment mesin untuk node pool yang sesuai.

Logging dan pemantauan

1.11, 1.12, 1.13

Dasbor pemantauan Windows menampilkan data dari cluster Linux

Dari versi 1.11, pada dasbor pemantauan siap pakai, Dasbor status Pod Windows dan dasbor status node Windows juga ditampilkan data dari cluster Linux. Hal ini karena node Windows dan metrik Pod juga diekspos di cluster Linux.

Logging dan pemantauan

1.10, 1.11, 1.12

`stackdriver-log-forwarder` dalam CrashLoopBackOff yang konstan

Untuk Google Distributed Cloud versi 1.10, 1.11, dan 1.12, stackdriver-log-forwarder DaemonSet mungkin memiliki CrashLoopBackOff error jika ada dan kerusakan log yang {i>buffer <i}pada {i>disk<i}.

Solusi:

Untuk mengurangi masalah ini, kita perlu membersihkan log {i>buffer<i} pada {i>node<i}.

Untuk mencegah perilaku yang tidak terduga, turunkan skala stackdriver-log-forwarder:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'

Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna file kubeconfig cluster.

Deploy DaemonSet pembersihan untuk membersihkan potongan yang rusak:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF

Untuk memastikan pembersihan DaemonSet telah membersihkan semua potongan, Anda dapat menjalankan perintah berikut. Output dari kedua perintah harus sama dengan nomor node Anda dalam cluster:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

Hapus DaemonSet pembersihan:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup

Lanjutkan stackdriver-log-forwarder:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'

Logging dan pemantauan

1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

`stackdriver-log-forwarder` tidak mengirim log ke Cloud Logging

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

2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk

Sepertinya tingkat input log melebihi batas agen {i>logging<i}, yang menyebabkan stackdriver-log-forwarder tidak mengirim log. Masalah ini terjadi di semua versi Google Distributed Cloud.

Solusi:

Untuk mengurangi masalah ini, Anda perlu meningkatkan batas sumber daya di agen logging.

Buka referensi stackdriver untuk mengedit:

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

Untuk meningkatkan permintaan CPU stackdriver-log-forwarder , tambahkan resourceAttrOverride berikut ke manifes stackdriver :

spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi

Resource yang Anda edit akan terlihat seperti berikut:

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi

Simpan perubahan Anda dan tutup editor teks.

Untuk memastikan bahwa perubahan telah diterapkan, jalankan perintah berikut:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"

Perintah tersebut menemukan cpu: 1200m jika hasil edit Anda telah diterapkan.

Keamanan

1.13

Layanan Kubelet tidak akan tersedia untuk sementara setelah NodeReady

ada periode singkat ketika {i>node<i} siap, tetapi server kubelet sertifikat belum siap. kubectl exec dan kubectl logs tidak tersedia selama puluhan detik ini. Hal ini karena pemberi persetujuan sertifikat server baru memerlukan waktu melihat IP valid node yang diupdate.

Masalah ini hanya memengaruhi sertifikat server kubelet, hal ini tidak akan berpengaruh Penjadwalan pod.

Upgrade, Update

1.12

Upgrade cluster admin sebagian tidak memblokir cluster pengguna baru upgrade

Upgrade cluster pengguna gagal dengan:

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

Cluster admin tidak diupgrade sepenuhnya, dan versi statusnya adalah tetap 1,10. Upgrade cluster pengguna ke 1.12 tidak akan diblokir oleh preflight apa pun pemeriksaan, dan gagal akibat masalah distorsi versi.

Solusi:

Selesaikan untuk mengupgrade cluster admin ke 1.11 terlebih dahulu, lalu upgrade cluster pengguna menjadi 1.12.

Penyimpanan

1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

Datastore salah melaporkan ruang kosong yang tidak cukup

Perintah gkectl diagnose cluster gagal dengan:

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

Validasi dari ruang kosong datastore tidak boleh digunakan untuk kumpulan node cluster, dan telah ditambahkan di gkectl diagnose cluster tanpa sengaja.

Solusi:

Anda dapat mengabaikan pesan {i>error<i} atau melewatkan validasi menggunakan --skip-validation-infra.

Operasi, Jaringan

1.11, 1.12.0-1.12.1

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

Proses penghapusan cluster pengguna mungkin macet karena beberapa alasan yang mengakibatkan pembatalan validasi MatalLB ConfigMap. Tidak mungkin untuk menambahkan cluster pengguna baru dalam status ini.

Solusi:

Anda dapat menghapus paksa cluster pengguna Anda.

Penginstalan, Sistem operasi

1.10, 1.11, 1.12, 1.13

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

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

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

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

Solusi:

Untuk menghindari pemeriksaan preflight lambat yang membuat VM pengujian, gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.

Logging dan pemantauan

1.12.0-1.12.1

Grafana di cluster admin tidak dapat menjangkau cluster pengguna

Masalah ini memengaruhi pelanggan yang menggunakan Grafana di cluster admin untuk memantau cluster pengguna di Google Distributed Cloud versi 1.12.0 dan 1.12.1. Error ini berasal dari ketidakcocokan sertifikat pushprox-client pada pengguna ke cluster yang diizinkan di server pushprox di cluster admin. Gejalanya adalah pushprox-client di cluster pengguna yang mencetak log error seperti hal berikut:

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

Solusi:

Lihat langkah-langkah solusi

lakukan langkah-langkah berikut:

Menurunkan skala deployment operator pemantauan di cluster admin kube-system.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy monitoring-operator \
    --replicas=0

Mengedit ConfigMap pushprox-server-rbac-proxy-config di namespace admin cluster kube-system.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --namespace kube-system edit cm pushprox-server-rbac-proxy-config

Temukan baris principals untuk external-pushprox-server-auth-proxy pemroses dan benar principal_name untuk semua cluster pengguna dengan menghapus kube-system substring dari pushprox-client.metrics-consumers.kube-system.cluster. Konfigurasi baru akan terlihat seperti berikut:

permissions:
- or_rules:
    rules:
    - header: { name: ":path", exact_match: "/poll" }
    - header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]

Mulai ulang deployment pushprox-server di admin dan deployment pushprox-client pada cluster yang terpengaruh cluster pengguna:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client

Langkah sebelumnya akan menyelesaikan masalah tersebut. Setelah cluster diupgrade ke 1.12.2 dan yang lebih baru di mana masalah telah diperbaiki, tingkatkan admin cluster kube-system monitoring-operator agar dapat mengelola pipeline lagi.
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
```

Lainnya

1.11.3

`gkectl repair admin-master` tidak menyediakan VM {i>template<i} yang akan digunakan untuk pemulihan

Perintah gkectl repair admin-master gagal dengan:

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

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

Solusi:

Jalankan kembali perintah dengan --skip-validation.

Logging dan pemantauan

1.11, 1.12, 1.13, 1.14, 1.15, 1.16

Kegagalan logging audit cloud karena izin ditolak

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

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

Solusi:

Lihat langkah-langkah solusi

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

Pertama, periksa apakah akun layanan yang ada dan diizinkan Cloud Audit Logs di project Anda:

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging

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

Dalam perintah di atas:

Ganti PROJECT_ID dengan cluster project logging audit Anda.
Ganti SERVICE_ACCOUNT_EMAIL dengan alamat email tersebut dari akun layanan logging audit.

Operasi, Keamanan

1,11

`gkectl diagnose` kegagalan pemeriksaan sertifikat

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

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

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

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

Solusi:

Jika aman untuk mengabaikan pesan ini.

Sistem operasi

1.8, 1.9, 1.10, 1.11, 1.12, 1.13

`/var/log/audit/` mengisi ruang disk di VM

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

Perintah gkectl tertentu di workstation admin, untuk contoh, gkectl diagnose snapshot berkontribusi pada kapasitas disk tingkat penggunaan.

Sejak Google Distributed Cloud v1.8, image Ubuntu telah di-hardening dengan CIS Level 2 {i>Benchmark<i}. Dan salah satu aturan kepatuhan, "4.1.2.2 Memastikan log audit tidak dihapus secara otomatis", memastikan setelan yang diaudit max_log_file_action = keep_logs. Hal ini menghasilkan semua audit yang disimpan pada {i>disk<i}.

Solusi:

Lihat langkah-langkah solusi

Stasiun kerja admin

Untuk workstation admin, Anda dapat secara manual mengubah status untuk merotasi log secara otomatis, lalu memulai ulang proses audit layanan:

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

Setelan di atas akan membuat log yang diaudit secara otomatis dirotasi setelah menghasilkan lebih dari 250 file (masing-masing berukuran 8 M).

Node cluster

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

Perlu diketahui bahwa perubahan konfigurasi yang diaudit ini akan melanggar CIS Level 2 aturan "4.1.2.2 Memastikan log audit tidak dihapus secara otomatis".

Jaringan

1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

`NetworkGatewayGroup` IP mengambang bentrok dengan node Anda

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

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

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

Solusi:

Dalam cluster yang sama tempat pembuatan atau update Objek NetworkGatewayGroup gagal, nonaktifkan untuk sementara webhook yang memvalidasi ANG dan mengirimkan perubahan Anda:

Simpan konfigurasi webhook agar dapat dipulihkan di bagian akhir:

kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml

Edit konfigurasi webhook:

kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration

Hapus item vnetworkgatewaygroup.kb.io dari dan hampir menerapkan perubahan.
Buat atau edit objek NetworkGatewayGroup Anda.

Terapkan ulang konfigurasi webhook asli:

kubectl -n kube-system apply -f webhook-config.yaml

Penginstalan, Upgrade, Update

1.10.0-1.10.2

Waktu tunggu pembuatan atau upgrade cluster admin telah habis

Selama upaya upgrade cluster admin, VM bidang kontrol admin mungkin macet selama pembuatan. VM bidang kontrol admin masuk ke antrean tak terbatas selama booting, dan Anda akan melihat error loop tak terbatas di /var/log/cloud-init-output.log file:

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

Hal ini terjadi karena saat Google Distributed Cloud mencoba mendapatkan node IP di skrip startup, kode ini menggunakan grep -v ADMIN_CONTROL_PLANE_VIP untuk melewati VIP bidang kontrol cluster admin yang juga dapat ditugaskan ke NIC. Namun, perintah itu juga melewati alamat IP apa pun yang memiliki awalan VIP bidang kontrol, yang menyebabkan skrip startup menjadi hang.

Misalnya, anggaplah VIP bidang kontrol admin cluster 192.168.1.25. Jika alamat IP VM bidang kontrol cluster admin memiliki awalan yang sama, misalnya,192.168.1.254, maka VM bidang kontrol akan terhambat selama pembuatan. Masalah ini juga dapat terpicu jika memiliki imbuhan yang sama dengan VIP bidang kontrol, contoh, 192.168.1.255.

Solusi:

Jika alasan waktu tunggu pembuatan cluster admin telah habis alamat IP siaran, jalankan perintah berikut di cluster admin VM bidang kontrol:
```
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
```
Ini akan membuat baris tanpa alamat siaran, dan membatalkan pemblokiran proses {i>booting<i}. Setelah skrip startup dibatalkan pemblokirannya, hapus ini baris yang ditambahkan dengan menjalankan perintah berikut:
```
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
```
Namun, jika alasan waktu tunggu pembuatan cluster admin telah habis ke alamat IP VM bidang kontrol, Anda tidak dapat berhenti memblokir skrip startup. Beralihlah ke alamat IP lain, dan buat ulang atau upgrade ke versi 1.10.3 atau yang lebih baru.

Sistem operasi, Peningkatan Versi, Pembaruan

1.10.0-1.10.2

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

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

Solusi:

Buat ulang cluster admin dengan osImageType yang disetel ke ubuntu_containerd

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

Sistem operasi

1.10

pencarian DNS gagal yang diselesaikan oleh sistem pada `.local` domain

Di Google Distributed Cloud versi 1.10.0, resolusi nama di Ubuntu dirutekan ke pemrosesan lokal yang di-resolve oleh sistem di 127.0.0.53 secara {i>default<i}. Alasannya adalah bahwa pada {i>image<i} Ubuntu 20.04 yang digunakan dalam versi 1.10.0, /etc/resolv.conf ditautkan secara symlink ke /run/systemd/resolve/stub-resolv.conf, yang menunjukkan 127.0.0.53 stub DNS localhost.

Akibatnya, resolusi nama DNS {i>localhost<i} menolak untuk memeriksa server DNS upstream (ditentukan di /run/systemd/resolve/resolv.conf) untuk nama dengan Akhiran .local, kecuali jika nama ditentukan sebagai penelusuran domain.

Hal ini menyebabkan pencarian nama .local gagal. Sebagai misalnya, saat startup node, kubelet gagal mengambil gambar dari registry pribadi dengan akhiran .local. Menetapkan Alamat vCenter dengan akhiran .local tidak akan berfungsi di komputer admin.

Solusi:

Anda dapat menghindari masalah ini untuk node cluster jika Anda menentukan Kolom searchDomainsForDNS di konfigurasi cluster admin Anda dan file konfigurasi cluster pengguna untuk menyertakan domain.

Saat ini gkectl update tidak mendukung pembaruan Kolom searchDomainsForDNS.

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

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

Sedangkan untuk workstation admin, gkeadm tidak mendukung menentukan domain penelusuran, jadi Anda harus mengatasi masalah ini dengan panduan langkah waktu ini.

Solusi ini tidak dapat diterapkan di seluruh pembuatan ulang VM. Anda harus terapkan kembali solusi ini setiap kali VM dibuat ulang.

Penginstalan, Sistem operasi

1.10

IP jembatan Docker menggunakan `172.17.0.1/16`, bukan `169.254.123.1/24`

Google Distributed Cloud menentukan subnet khusus untuk Docker jembatan alamat IP yang menggunakan --bip=169.254.123.1/24, sehingga ia tidak akan mencadangkan subnet 172.17.0.1/16 default. Namun, di versi 1.10.0, ada {i>bug<i} di Ubuntu OS image yang menyebabkan konfigurasi Docker yang disesuaikan agar diabaikan.

Hasilnya, Docker memilih 172.17.0.1/16 default sebagai menghubungkan subnet alamat IP. Hal ini dapat menyebabkan konflik alamat IP jika Anda sudah memiliki beban kerja yang berjalan dalam rentang alamat IP tersebut.

Solusi:

Untuk mengatasi masalah ini, Anda harus mengganti nama konfigurasi system berikut untuk Docker, lalu mulai ulang layanan:

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

sudo systemctl daemon-reload

sudo systemctl restart docker

Verifikasi bahwa Docker memilih alamat IP jembatan yang benar:

ip a | grep docker0

Solusi ini tidak dapat dipertahankan di seluruh pembuatan ulang VM. Anda harus mengajukan permohonan kembali solusi ini setiap kali VM dibuat ulang.

Upgrade, Update

1,11

Upgrade ke 1.11 diblokir oleh kesiapan stackdriver

Di Google Distributed Cloud versi 1.11.0, ada perubahan definisi resource kustom yang terkait dengan logging dan pemantauan:

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

Perubahan nama grup ini dibuat untuk mematuhi pembaruan CustomResourceDefinition di Kubernetes 1.22.

Anda tidak perlu melakukan tindakan apa pun jika tidak memiliki logika tambahan yang menerapkan atau mengedit resource kustom yang terpengaruh. Proses upgrade Google Distributed Cloud akan menangani migrasi resource yang terpengaruh dan mempertahankan spesifikasi yang sudah ada setelah nama grup diubah.

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

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

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

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

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

Log error rekonsiliasi dalam 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}

Terjadi kegagalan dalam kubectl edit stackdriver stackdriver, misalnya:

Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

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

Mengubah permintaan dan batas resource ke jenis string;
Hapus anotasi addons.gke.io/migrated-and-deprecated: true jika ada.

Kemudian, lanjutkan atau mulai ulang proses upgrade.

Sistem operasi

1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16

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

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

Solusi:

Memulai ulang VM

Jaringan

semua versi sebelum 1.14.7, 1.15.0-1.15.3, 1.16.0

Balasan GARP yang dikirim oleh Seesaw tidak menetapkan IP target

GARP berkala (Gratuitous ARP) yang dikirim oleh Seesaw setiap 20-an tidak ditetapkan IP target di {i>header<i} ARP. Beberapa jaringan mungkin tidak menerima paket tersebut (seperti Cisco ACI). Hal ini dapat menyebabkan periode nonaktif layanan yang lebih lama setelah otak yang terpisah (karena paket drop VRRP) dipulihkan.

Solusi:

Picu failover Seeaw dengan menjalankan sudo seesaw -c failover pada salah satu VM Seesaw. Seharusnya memulihkan lalu lintas.

Sistem operasi

1.16, 1.28.0-1.28.200

Kubelet dibanjiri log yang menyatakan bahwa "/etc/kubernetes/manifess" tidak ada pada worker node

"staticPodPath" tidak sengaja ditetapkan untuk worker node

Solusi:

Buat folder "/etc/kubernetes/manifess" secara manual

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Masalah umum Google Distributed Cloud (khusus software) untuk VMware

Setelah memigrasikan cluster pengguna ke Controlplane V2, cluster admin PDB server metrik mungkin menjadi tidak dikonfigurasi dengan benar

Webook Otorisasi Biner memblokir plugin CNI agar mulai menyebabkan salah satu nodepool gagal muncul

Upgrade cluster pengguna CPV2 terhenti karena mesin yang dicerminkan dengan deletionTimestamp

Kegagalan pembuatan cluster karena VIP bidang kontrol di subnet yang berbeda

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

Upgrade cluster admin gagal untuk cluster yang dibuat di versi 1.10 atau lebih cepat

Pesan peringatan yang salah untuk cluster dengan Dataplane V2 diaktifkan

Laporan pemeriksaan preflight penginstalan cluster admin HA salah jumlah IP statis yang diperlukan

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

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

Penggunaan beberapa antarmuka jaringan dengan CNI standar tidak berfungsi

Dependensi trident Netapp mengganggu driver CSI vSphere

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

Setelan default kolom controlPlaneNodePort adalah 30968 jika Spesifikasi manualLB kosong

nfs-common tidak ada di image OS Ubuntu

Kolom kebijakan penyimpanan tidak ada di template konfigurasi cluster admin

Kubernetes Metadata API tidak mendukung VPC-SC

Pengontrol clusterapi dapat mengalami error jika cluster admin dan cluster pengguna apa pun yang mengaktifkan ControlPlane V2 menggunakan kredensial vSphere yang berbeda

dll. tingginya jumlah permintaan GRPC yang gagal di Prometheus Alert Manager

Koneksi yang aktif dalam waktu lama NAT keluar akan terputus

Penanda tangan CSR mengabaikan spec.expirationSeconds saat menandatangani sertifikat

Validasi load balancer cluster pengguna gagal untuk disable_bundled_ingress

Update cluster admin gagal setelah rotasi CA

Pemeriksaan preflight Workload CSI gagal karena kegagalan startup Pod

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

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

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

Gagal menghapus cluster pengguna saat menggunakan workstation admin yang dikelola pengguna

Traffic gateway NAT keluar ke server eksternal gagal

Upgrade cluster admin yang mengaktifkan enkripsi secret yang selalu aktif akan gagal

Solusi

Mencegah kegagalan upgrade

Error disk dan kegagalan pemasangan saat menggunakan Pelacakan Pemblokiran yang Diubah (CBT)

Kerusakan data pada NFSv3 ketika paralel menambahkan ke file bersama dilakukan dari beberapa {i>host<i}

Ketidakcocokan versi antara kubelet dan bidang kontrol Kubernetes

Upgrade atau update cluster admin dengan versi CA yang lebih tinggi dari 1 gagal

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

Tugas pemasangan volume CNS yang konstan muncul setiap menit untuk PVC/PV dalam hierarki setelah mengupgrade ke versi 1.15+

Peringatan palsu yang dilihat oleh PVC

Rotasi kunci akun layanan gagal saat beberapa kunci sudah tidak berlaku

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

Pemeriksaan preflight akan gagal jika nama host tidak ada dalam file blok IP.

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

Node bidang kontrol gagal dibuat

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

$ dan ` tidak didukung di nama pengguna atau sandi vSphere

Kegagalan pembuatan PVC setelah node dibuat ulang dengan nama yang sama

Perbaikan gkectl admin-master menampilkan error kubeconfig unmarshall

Melihat VM rusak karena kapasitas disk hampir penuh

Terjadi error pada kunci publik SSH admin setelah upgrade atau update cluster admin

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

Anotasi link resource cluster admin yang terdaftar tidak dipertahankan

CoreDNS orderPolicy tidak dikenali

Status OnPremAdminCluster tidak konsisten antara checkpoint dan CR sebenarnya

Proses rekonsiliasi mengubah sertifikat admin pada cluster admin

Komponen Gateway Jaringan Anthos dihapus atau tertunda karena tidak ada kelas prioritas

upgrade cluster admin gagal setelah mendaftarkan cluster ke gcloud

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

gkectl prepare windows gagal

Konfigurasi RootDistanceMaxSec tidak diterapkan untuk ubuntu node

gkectl update admin gagal karena kolom osImageType kosong

SNI tidak berfungsi pada cluster pengguna dengan Controlplane V2

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

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

Update cluster pengguna gagal setelah rotasi kunci penandatanganan KSA

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

jenis cluster mengambil image container dari docker.io

Failover gagal pada cluster pengguna HA Controlplane V2 dan cluster admin saat jaringan memfilter permintaan GARP duplikat

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

Pembuatan cluster admin tidak gagal saat terjadi error pendaftaran cluster

Pendaftaran ulang cluster admin mungkin dilewati selama upgrade cluster admin

Pesan error palsu tentang vCenter.dataDisk

Pembuatan kumpulan node gagal karena aturan afinitas Host VM yang redundan

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

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

OnPremUserCluster tidak siap karena kredensial registry pribadi

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

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

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

Upgrade cluster pengguna CPV2 terhenti karena mesin yang dicerminkan dengan `deletionTimestamp`

Setelan default kolom `controlPlaneNodePort` adalah 30968 jika Spesifikasi `manualLB` kosong

Penanda tangan CSR mengabaikan `spec.expirationSeconds` saat menandatangani sertifikat

Validasi load balancer cluster pengguna gagal untuk `disable_bundled_ingress`

`$` dan ` tidak didukung di nama pengguna atau sandi vSphere

CoreDNS `orderPolicy` tidak dikenali

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

`gkectl prepare windows` gagal

Konfigurasi `RootDistanceMaxSec` tidak diterapkan untuk `ubuntu` node

`gkectl update admin` gagal karena kolom `osImageType` kosong

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

jenis cluster mengambil image container dari `docker.io`

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

Pesan error palsu tentang `vCenter.dataDisk`

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

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

`vsphere-csi-secret` tidak diupdate setelah `gkectl update credentials vsphere --admin-cluster`

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

Deployment ulang bidang kontrol tambahan tepat setelah `gkectl upgrade cluster`

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

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

`kube-controller-manager` mungkin melepaskan volume persisten dengan kuat setelah 6 menit

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

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

Objek ClusterAPI tidak ada dalam skenario `system` snapshot cluster

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

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

`gkectl check-config` gagal saat validasi image OS

`gkectl update admin/cluster` gagal memperbarui grup anti

`NetworkGatewayNodes` marked unhealthy from concurrent status update conflict

`gkectl` menyiapkan kegagalan preflight validasi image OS

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

`gkectl prepare` panik di `util.CheckFileExists`

Upgrade admin yang dapat dilanjutkan dan `gkectl repair admin-master` adalah tidak bekerja sama

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

Penginstalan `cert-manager` bertentangan

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