Masalah umum Google Distributed Cloud dengan air gap 1.14.x

Pencadangan dan pemulihan

Edit rencana pemulihan cadangan cluster rusak

Versi: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Gejala:

Resource kustom RestorePlan tidak dapat diedit menggunakan konsol GDC.

Solusi:

Buat paket pemulihan baru, lalu hapus paket pemulihan lama, atau edit paket pemulihan menggunakan kubectl CLI.

Ukuran disk sumber tidak valid

Versi: 1.14.4, 1.14.5

Gejala: UI salah menampilkan ukuran disk sebagai 0 MB dan waktu pembuatannya sebagai "Tidak Diketahui" karena perubahan model data backend setelah migrasi ke arsitektur organisasi v2.

Solusi: Tidak ada metode alternatif untuk melihat informasi ini melalui UI.

Pod bidang kontrol dan agen dimulai ulang karena kurangnya memori

Versi: 1.14.3, 1.14.4

Gejala: Pod agen dan bidang kontrol dapat dimulai ulang jika kehabisan memori.

Solusi: Tingkatkan memori untuk pod bidang kontrol dan agen dengan mengikuti petunjuk dalam buku pedoman BACK-R0005. Tingkatkan memori untuk pod menjadi 2 GiB.

SLO pencadangan dan pemulihan tidak diterapkan

Versi: 1.14.3, 1.14.4

Gejala: Metrik dan pemberitahuan Tujuan Tingkat Layanan (SLO) GDC tidak dikonfigurasi secara default, karena definisi resource kustom yang diperlukan tidak diinstal. Pemberitahuan ini digunakan di Grafana.

Solusi: Untuk mengaktifkan SLO untuk pencadangan dan pemulihan di GDC, ikuti buku panduan BACK-T0001.

Kebijakan retensi tidak diterapkan pada cadangan yang diimpor

Versi: Semua versi Google Distributed Cloud (GDC) dengan air gap dapat terpengaruh.

Gejala: Melampirkan repositori cadangan ke cluster akan menyinkronkan semua metadata pencadangan dan pemulihan, serta memperlakukan repositori sebagai cadangan yang diimpor. Pencadangan yang diimpor ini dilewati secara salah selama rekonsiliasi, yang berarti kebijakan retensi diabaikan dan pencadangan dipertahankan tanpa batas waktu.

Solusi: Cadangan yang diimpor diberi label backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME. Untuk mengizinkan rekonsiliasi normal dan penerapan kebijakan retensi, hapus label dari cadangan menggunakan perintah kubectl berikut:

1. Tetapkan variabel lingkungan yang diperlukan:

   export KUBECONFIG=KUBECONFIG
   export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
   export NAMESPACE=BACKUP_PLAN_NAMESPACE
   

   Ganti kode berikut:

   • KUBECONFIG: jalur ke file kubeconfig.
   • BACKUP_REPOSITORY_NAME: nama repositori cadangan.
   • NAMESPACE: namespace yang berisi rencana cadangan.

2. Mencantumkan semua cadangan yang diimpor:

   kubectl get backups.backup.gdc.goog -n $NAMESPACE -l backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME
   

3. Hapus label sesuai kebutuhan:

   • Hapus label dari semua cadangan:

     kubectl get backups.backup.gdc.goog -l
     backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME -n $NAMESPACE
     -o json | jq -r '.items[].metadata.name' | xargs -I{} kubectl label -n
     $NAMESPACE backups.backup.gdc.goog {} backup.gdc.goog/imported-repository-
     

   • Menghapus label untuk satu cadangan:

     export BACKUP_NAME= kubectl label backups.backup.gdc.goog $BACKUP_NAME -n
     $NAMESPACE backup.gdc.goog/imported-repository-
     

Pencadangan VM sebagian gagal

Versi: 1.14.3, 1.14.4

Gejala: Jika satu VM dari banyak VM gagal dicadangkan, seluruh pencadangan VM ditandai sebagai gagal.

Solusi: Batasi jumlah VM per rencana pencadangan.

Membersihkan resource pencadangan yang tidak terkait setelah penghapusan cluster pengguna atau layanan

Versi: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Gejala: Saat cluster pengguna atau layanan dihapus, resource agen pencadangan terkait (seperti StatefulSet, Pod, secret, dll.) yang dibuat di infrastruktur org dan cluster pengelolaan tidak akan dihapus secara otomatis. Hal ini dapat menyisakan resource yang tidak terkait dan jika cluster dibuat dengan nama yang sama lagi, pod agen pencadangan tidak berfungsi.

Solusi: Resource tanpa induk ada di namespace khusus di cluster infrastruktur org. Untuk membersihkannya, Anda harus menghapus namespace ini.

1. Tetapkan file kubeconfig untuk cluster pengelolaan dan infrastruktur organisasi.

   export ORG_INFRA_KUBECONFIG=<path_to_org_infra_kubeconfig>
   export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
   

2. Identifikasi namespace resource yang tidak memiliki induk. Namespace mengikuti pola gpc-backup-<cluster-name>-system. Contoh:

   • gpc-backup-user-vm-1-cluster-system
   • gpc-backup-user-vm-2-cluster-system
   • gpc-backup-g-org-1-shared-service-cluster-system

3. Hapus namespace. Tindakan ini akan menghapus semua resource di dalamnya, termasuk StatefulSet dan Pod agen pencadangan di infrastruktur serta rahasia di cluster pengelolaan.

   # Replace <namespace-name> with the actual namespace
   kubectl delete namespace <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
   kubectl delete namespace <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
   

4. Untuk mengonfirmasi bahwa pembersihan berhasil, jalankan perintah get all lagi.

   # Replace <namespace-name> with the actual namespace
   kubectl get all -n <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
   kubectl get all -n <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
   

   Perintah sekarang akan gagal karena namespace tidak ada lagi. Anda akan melihat error seperti Error from server (NotFound): namespaces "<namespace-name>" not found.

Penghapusan VirtualMachineRestore tidak didukung melalui CLI atau UI

Versi: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Gejala: Pengontrol VirtualMachineRestore tidak otomatis membersihkan resource pokok (VolumeRestore, Restore) setelah penghapusan resource VirtualMachineRestore. Hal ini memerlukan pembersihan manual. Hal ini berlaku baik saat menghapus menggunakan kubectl delete maupun UI.

Solusi: Solusinya adalah menghapus resource dependen secara manual dalam urutan yang benar, lalu menghapus finalizer dari resource VirtualMachineRestore.

1. Tetapkan file kubeconfig untuk mengarah ke cluster pengelolaan.

   export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
   

2. Identifikasi VirtualMachineRestore yang akan dihapus dan namespace-nya.

   export VM_RESTORE_NAME=<vm-restore-to_be_deleted>
   export NAMESPACE=<namespace-of-vm-restore>
   

3. Temukan dan hapus resource VolumeRestore terkait. Label ini dibuat dengan label yang menautkannya ke VirtualMachineRestore.

   # Find and delete all associated VolumeRestores.
   kubectl delete volumerestores.backup.gdc.goog --all-namespaces -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

4. Temukan dan hapus resource Restore terkait. Label ini dibuat dengan label yang menautkannya ke VirtualMachineRestore.

   # Find and delete all associated Restores.
   kubectl delete restores.backup.gdc.goog -n "${NAMESPACE:?}" -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

5. Sekarang, lakukan kubectl delete jika belum dilakukan dan hapus finalizer dari resource VirtualMachineRestore. Ini adalah langkah terakhir yang memungkinkan pengumpul sampah Kubernetes menghapus resource.

   kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"
   

6. Verifikasi penghapusan.

   kubectl get virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

   Perintah akan menampilkan error NotFound, yang mengonfirmasi bahwa resource telah dihapus.

Pod bidang kontrol cadangan mengalami error karena memori tidak mencukupi

Versi: 1.14.4 dan yang lebih baru

Gejala: Pod gpcbackup-controlplane-controller di namespace sistem gpc-backup dari cluster infra organisasi menampilkan status CrashLoopBackOff. Jika error ini terjadi, operasi pencadangan dan pemulihan akan gagal, berhenti merespons, atau tidak berfungsi seperti yang diharapkan.

Solusi: Tingkatkan batas memori untuk deployment gpcbackup-controlplane-controller dengan mengikuti BACK-R0005. Metode ini menerapkan SubcomponentOverride untuk menyesuaikan permintaan dan batas CPU serta memori.

Penghapusan cluster pengguna macet

Versi: 1.14.7 dan yang lebih baru

Gejala: Cluster macet dalam status penghapusan karena masalah finalizer.

Solusi: Periksa apakah volume penyimpanan memiliki hubungan SnapMirror sebelum menghapus cluster. Untuk mengetahui informasi selengkapnya, lihat BACK-R0109.

Pemulihan macet karena klaim volume persisten yang menunggu keputusan

Versi: 1.14.3 dan yang lebih baru

Gejala: Pengontrol klaim volume persisten (PVC) terkadang tidak dapat berkomunikasi dengan agen pencadangan di cluster infrastruktur organisasi. Meskipun masalah ini tidak memengaruhi fungsi pencadangan, masalah ini dapat menyebabkan operasi pemulihan volume macet dalam status Pending dan akhirnya waktu habis. Masalah ini memengaruhi operasi pemulihan yang melibatkan pemulihan volume, seperti fitur pemulihan Layanan Database untuk cloning dan pemulihan beban kerja pengguna.

Jika masalah ini muncul, operasi pemulihan berikutnya dalam cluster yang terpengaruh akan gagal hingga Anda memulai ulang agen pencadangan yang sesuai secara manual.

Untuk mengonfirmasi bahwa masalah pemulihan Anda terkait dengan masalah khusus ini, Anda harus menyelidiki log agen pencadangan:

1. Ikuti IAM-R0005 untuk mendapatkan peran BACK Debugger (back-cluster-debugger) yang diperlukan dengan menerapkan resource ExpirationClusterRoleBinding.

2. Ikuti IAM-R0004 untuk membuat file kubeconfig untuk cluster infrastruktur organisasi. Semua agen pencadangan berjalan di cluster infrastruktur organisasi.

3. Identifikasi agen pencadangan yang memfasilitasi pemulihan:

   kubectl --kubeconfig ORG_INFRA_KUBECONFIG get statefulsets \
       --all-namespaces | grep gpcbackup-agent
   

   Ganti ORG_INFRA_KUBECONFIG dengan jalur ke file kubeconfig cluster infrastruktur org.

   Outputnya mirip dengan hal berikut ini:

   NAMESPACE                                          NAME                                     READY   AGE
   gpc-backup-g-org-1-shared-service-cluster-system   gpcbackup-agent-g-org-1-shared-service   1/1     22d
   gpc-backup-system                                  gpcbackup-agent                          1/1     22d
   gpc-backup-system                                  gpcbackup-agent-cp                       1/1     22d
   gpc-backup-user-vm-1-cluster-system                gpcbackup-agent-user-vm-1                1/1     22d
   gpc-backup-user-vm-2-cluster-system                gpcbackup-agent-user-vm-2                1/1     22d
   

   Baca output dan tentukan agen pencadangan yang sesuai dengan pemulihan Anda. Misalnya, jika namespace set berstatus yang terpengaruh dari output adalah gpc-backup-user-vm-1-cluster-system, maka agen pencadangan adalah gpcbackup-agent-user-vm-1.

4. Telusuri pesan error di log set berstatus untuk mengonfirmasi masalah:

   kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
       -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
   

   Ganti kode berikut:

   • ORG_INFRA_KUBECONFIG: jalur ke file kubeconfig cluster infrastruktur org.

   • BACKUP_AGENT: agen pencadangan yang Anda identifikasi pada langkah sebelumnya.

   • NAMESPACE: namespace yang Anda identifikasi di langkah sebelumnya.

   Jika ada log yang cocok, Anda mengalami masalah umum ini.

Solusi: Untuk mengatasi masalah ini, selesaikan langkah-langkah berikut:

1. Mulai ulang agen pencadangan:

   kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
      statefulsets/BACKUP_AGENT -n NAMESPACE
   

   Ganti kode berikut:

   • ORG_INFRA_KUBECONFIG: jalur ke file kubeconfig cluster infrastruktur org.

   • BACKUP_AGENT: agen pencadangan yang Anda identifikasi saat mengonfirmasi masalah.

   • NAMESPACE: namespace yang Anda identifikasi saat mengonfirmasi masalah.

   Outputnya mirip dengan hal berikut ini:

   statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
   

2. Tunggu hingga 20 menit agar operasi yang tertunda dilanjutkan secara otomatis.

Anda dapat melakukan pemulihan lain untuk cluster tujuan yang sama setelah agen cadangan selesai dimulai ulang. Setelah Anda menyelesaikan solusi ini, tidak ada efek samping. Anda hanya perlu menyelesaikan solusi ini satu kali per cluster yang terpengaruh.

Pengelolaan cluster

Subkomponen kub-gpu-controller tidak sesuai

Versi: 1.14.3

Gejala: Subkomponen g-gdchservices-shared-service-cluster/kub-gpu-controller di organisasi gdchservices tidak disesuaikan. Output berikut akan ditampilkan:

│ Message: Reconciliation error: E0321 - runtime parameter: configRunner error
| (full log in oclcm-configrunner pod): rpc error: code = Unknown desc = failed
| to execute binary: exit status 1. Output:
│ <
│ I framework.go:159] "Reading input secret"
| inputSecretKey="g-gdchservices-shared-service-cluster/kub-gpu-controller-backend-parameter"
│ I framework.go:175] "Processing job" jobType=parameter
│ Error: no matched clusterName
│ >

Kegagalan ini mencegah mesin GPU dimulai di organisasi gdchservices.

Solusi: Lakukan upgrade ke versi 1.14.4+ untuk mengurangi masalah ini.

Cluster Standard tidak dapat menghapus kumpulan node

Versi: 1.14.3, 1.14.4, 1.14.5

Tetap: 1.14.6

Gejala: Penghapusan node pool yang tidak digunakan lagi dari cluster standar gagal dan node pool tidak dihapus dalam jangka waktu yang diharapkan. Cluster standar berada dalam pratinjau pribadi dan mungkin tidak tersedia untuk semua pelanggan.

Solusi: Hapus node pool yang sudah tidak digunakan secara manual.

Cluster macet dalam status penghapusan

Versi: 1.14.6 dan yang lebih baru

Gejala: Saat menghapus cluster Kubernetes, cluster tersebut mungkin macet dalam status Deleting. Periksa status cluster Anda dengan menjalankan perintah berikut:

kubectl get cluster CLUSTER_NAME -n platform \
    --kubeconfig MANAGEMENT_API_SERVER

Outputnya mirip dengan hal berikut ini:

NAMESPACE    NAME             STATE         K8S VERSION
platform     test-cluster     Deleting      1.28.15-gke.100

Anda juga dapat memverifikasi masalah dengan memeriksa status namespace cluster:

kubectl describe ns/CLUSTER_NAME-cluster \
    --kubeconfig MANAGEMENT_API_SERVER

Outputnya mirip dengan hal berikut ini:

Name:         test-cluster
Labels:       kubernetes.io/metadata.name=test-cluster
Status:       Terminating
Conditions:
  Type                            Status    LastTransitionTime      Reason                Message
  ----                            ------    ------------------      ------                -------
  NamespaceContentRemaining       True      DATE                    SomeResourcesRemain   Some resources are remaining: backendservices.networking.gdc.goog has 1 resource instances, forwardingruleinternals.networking.gdc.goog has 1 resource instances
  NamespaceFinalizersRemaining    True      DATE                    SomeFinalizersRemain  Some content in the namespace has finalizers remaining: backendservice.finalizers.networking.gdc.goog in 2 resource instances

Namespace cluster macet dalam status Terminating, dan kondisi NamespaceContentRemaining dan NamespaceFinalizersRemaining ditetapkan sebagai True.

Solusi: Untuk mengatasi masalah ini, selesaikan langkah-langkah berikut:

1. Patch API aturan penerusan:

   kubectl patch forwardingruleinternals.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
       cluster-control-plane-vip-fr -p '{"metadata":{"finalizers":[]}}' --type='merge'
   

2. Membuat patch API layanan backend:

   kubectl patch backendservices.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
       cluster-control-plane-vip-bes -p '{"metadata":{"finalizers":[]}}' --type='merge'
   

Layanan database

Bagian ini berisi masalah umum untuk layanan Database.

Kloning database AlloyDB Omni macet

Versi: 1.14.6 dan sebelumnya

Tetap: 1.14.7

Gejala: Saat pengguna meng-clone cluster AlloyDB Omni dari titik waktu tertentu, cluster database yang di-clone akan mengalami error DBSE0005 dan tidak dapat siap. Resource restore.alloydb yang sesuai mengalami masalah di fase "ProvisionInProgress".

Solusi: Untuk mengatasi masalah ini, pilih titik waktu dengan cermat dari COMPLETETIME pencadangan yang berhasil.

Mencantumkan cadangan AlloyDB Omni yang tersedia untuk dikloning dari server API pengelolaan.

kubectl get backups.alloydb -n source-dbcluster-namespace

Contoh output:

NAMESPACE   NAME                         PHASE       COMPLETETIME
db1         backupplan1-20240908215001   Succeeded   2024-09-08T21:37:38Z
db1         backupplan1-20240909215001   Succeeded   2024-09-09T21:16:18Z
db1         backupplan1-20240910215001   Succeeded   2024-09-10T21:09:38Z
db1         backupplan1-20240911215001   Succeeded   2024-09-11T21:50:47Z

Pilih nilai COMPLETETIME sebagai titik waktu untuk clone. Perhatikan bahwa waktu menggunakan UTC.

DNS

GlobalCustomerRootDNSServerNotReachable memicu pemberitahuan palsu

Versi: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7, 1.14.8

Gejala: Pemberitahuan DNS DNS-A0021 diaktifkan yang menunjukkan GlobalCustomerRootDNSServerNotReachable. CR Probe untuk global-customer-root-dns di org-mp tidak memiliki egress: true dalam spesifikasi.

Solusi:

1. Tetapkan jalur KUBECONFIG untuk org-mgmt:

   export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG
   

2. Jeda subkomponen core-mz yang mengelola CR probe:

   kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" annotate subcomponent  -n global-kube-system dns-core-mz lcm.private.gdc.goog/paused=true
   

3. Edit CR probe saat ini dari org-mp:

   kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" edit probes -n dns-system global-customer-root-dns
   

4. Perbarui spesifikasi untuk menyertakan egress: True dan terapkan perubahan. Perhatikan bahwa CLUSTER_NAME dan GLOBAL_CUSTOMER_ROOT_IP tidak berubah.

   apiVersion: prober.private.gdc.goog/v1alpha1
   kind: Probe
   metadata:
     name: global-customer-root-dns
   spec:
     egress: True
     matchClusters:
     - CLUSTER_NAME
     probeJobs:
     - moduleName: dns_udp_global_customer_root
       name: healthy-dns-global-customer-root
       targets:
       - GLOBAL_CUSTOMER_ROOT_IP
   

Solusi ini memperbaiki pemeriksa dan semua notifikasi palsu akan mereda dalam 15 menit.

Penyimpanan file/blok

Tidak dapat memasang volume berbagi file di VM

Versi: 1.14.6, 1.14.7

Gejala: Terjadi kegagalan untuk mengupdate izin penyimpanan jaringan saat node baru ditambahkan ke cluster, yang dapat menyebabkan permintaan pemasangan NFS ditolak. Anda mungkin melihat error access denied by server saat memasang berbagi file NFS.

Solusi: Mulai ulang rekonsiliasi file-share atau proxy-group, atau ubah resource FileShare untuk memicu update.

Firewall

Aturan kebijakan keamanan tidak ada untuk alamat di CR Subnet

Versi: 1.14.3

Gejala: Organisasi tidak dapat dijangkau karena grup alamat firewall tidak ada di resource kustom subnet global yang dibuat oleh pelanggan di server API global organisasi.

Solusi: Ikuti langkah-langkah dalam manual servis FW-G0002 untuk menambahkan aturan kebijakan keamanan secara manual guna mengizinkan traffic.

Firewall GDC menolak traffic menuju OIR untuk bidang pengelolaan dan data

Versi: 1.14.3, 1.14.4

Gejala: Setelah resource kustom OCITTopology di-deploy, konektivitas antara bidang data dan bidang pengelolaan OIR dan GDC menjadi terganggu.

Solusi: Ikuti langkah-langkah dalam manual servis FW-G0002 untuk menambahkan aturan kebijakan keamanan secara manual di cluster admin root agar memungkinkan traffic.

Aturan kebijakan keamanan berikut diperlukan:

  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-igress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  —-
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-ingress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt

Ganti kode berikut:

• OCIT_CIDR: rentang alamat IP di kolom ocitCIDR pada Kuesioner Input Pelanggan (CIQ).
• MGMT_CIDR: rentang alamat IP di kolom oobManagementCIDRs pada Kuesioner Input Pelanggan (CIQ).
• ZONE_INFRA_CIDR: rentang alamat IP di kolom zoneInfraCIDRs pada Kuesioner Input Pelanggan (CIQ).

Firewall GDC menolak traffic lintas zona lintas organisasi

Versi: 1.14.3, 1.14.4, 1.14.5

Gejala: Traffic lintas organisasi lintas zona diblokir secara default oleh firewall.

Solusi: Ikuti langkah-langkah dalam runbook untuk menambahkan aturan kebijakan keamanan secara manual guna mengizinkan traffic.

Firewall tidak mendukung AttachmentGroup yang ID-nya sama dengan nama organisasi

Versi: 1.14.3 dan yang lebih baru

Gejala: Setelah AttachmentGroup di-deploy, jika kolom identifier dalam objek AttachmentGroup tersebut sama dengan orgName, firewall gagal mem-parsing objek ini dan update konfigurasi firewall akan macet. Contoh AttachmentGroup yang bermasalah adalah sebagai berikut:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed

Solusi: Hindari penggunaan nama organisasi sebagai ID. Ada beberapa opsi untuk memperbaiki AttachmentGroup yang buruk.

Pilih salah satu opsi berikut untuk memperbaiki AttachmentGroup yang bermasalah.

• Tambahkan string ke akhir ID asli dengan simbol tanda hubung:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg-orgdx
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

• Tambahkan string di awal ID asli dengan simbol tanda hubung:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: orgdx-myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

• Ganti ID asli dengan string yang berbeda:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: dxidentifier
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

Pelabuhan

Rahasia CLI Harbor menjadi tidak valid setelah pencadangan dan pemulihan

Versi: 1.14.3

Gejala: Setelah pencadangan dan pemulihan Harbor, rahasia CLI menjadi tidak valid dan harus dibuat lagi.

Solusi: Untuk mengurangi masalah ini, ikuti langkah-langkah berikut:

1. Login ke Harbor dengan akun pengguna IAP.
2. Klik nama pengguna Anda, lalu pilih Profil pengguna.
3. Klik Lainnya.
4. Buat secret CLI lain secara otomatis atau manual.

Untuk mengetahui informasi selengkapnya tentang Harbor di GDC, lihat Ringkasan Harbor.

Tugas pencadangan dan pemulihan Harbor bersaing untuk mendapatkan izin

Versi: 1.14.3, 1.14.4

Gejala: Jika ada beberapa instance Harbor dalam project pengguna yang berbeda, operasi pencadangan dan pemulihan akan bersaing untuk kontrol akses berbasis peran dan mengalami tingkat kegagalan yang tinggi.

Solusi: Untuk memitigasi masalah ini, ikuti langkah-langkah berikut untuk membuat binding peran secara manual untuk setiap namespace tempat instance Harbor dibuat:

1. Tetapkan variabel lingkungan yang diperlukan:

   INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
   INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
   

   Ganti kode berikut:

   • INFRA_CLUSTER_KUBECONFIG: jalur ke file kubeconfig cluster Infra.
   • INSTANCE_NAMESPACE: namespace tempat instance Managed Harbor Service (MHS) Harbor dibuat.

2. Buat binding peran untuk solusi sementara:

   kubectl --kubeconfig ${INFRA_CLUSTER_KUBECONFIG:?} create \
   rolebinding ${INSTANCE_NAMESPACE:?}-mhs-backup-manual-rolebinding \
   --role=haas-backup-secret-access-role --serviceaccount=${INSTANCE_NAMESPACE:?}-haas-system:haas-backup-sa \
   --namespace=haas-system
   

Ukuran cadangan Harbor menampilkan nilai 0

Versi: 1.14.3, 1.14.4

Gejala: Pengukuran ukuran cadangan untuk cadangan Harbor belum diterapkan saat ini. Di konsol GDC, kolom SizeBytes menampilkan nilai 0 dan kolom Size menampilkan nilai 0 MB. Konfigurasi ini adalah perilaku yang diharapkan untuk saat ini.

Error izin pada resource pencadangan di halaman konsol Harbor Registry

Versi: 1.14.3, 1.14.4

Gejala: Jika Anda tidak memiliki peran Admin Instance Harbor, Anda akan melihat error izin pada resource cadangan saat melihat halaman Harbor Container Registry di konsol GDC. Error ini ditampilkan karena informasi cadangan baru saja ditambahkan ke halaman Harbor Container Registry, tetapi izin baca untuk resource cadangan belum diberikan ke peran IAM selain Admin Instance Harbor.

Elemen konsol GDC lainnya di halaman Harbor Container Registry tetap berfungsi seperti yang diharapkan. Untuk mengetahui informasi selengkapnya tentang peran di GDC, lihat Definisi peran.

Halaman rotasi sandi database macet

Versi: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Gejala: Error ditampilkan terkait autentikasi untuk permintaan ke DB, seperti failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)) dan banyak permintaan rotasi yang dibuat secara otomatis ada untuk satu rahasia yang dapat dirotasi.

Solusi: Hapus permintaan rotasi tambahan yang belum siap untuk secret yang dapat dirotasi.

1. Tetapkan KUBECONFIG ke server API MP.

2. Ekspor namespace:

   NAMESPACE=haas-system
   

3. Temukan apakah ada secret yang dapat dirotasi di haas-system yang belum siap:

   kubectl get rotatablesecrets -n ${NAMESPACE?}
   

   Output-nya mungkin terlihat seperti contoh ini:

   NAME                        CREDENTIALID   READY     AGE
   haasdb-pw-ar-test           HAAS-0002      True      109d
   haasdb-pw-gardener-harbor   HAAS-0002      True      178d
   haasdb-pw-haas-alice        HAAS-0002      Unknown   166d
   haasdb-pw-myinstance        HAAS-0002      True      80d
   haasdb-pw-osd               HAAS-0002      True      158d
   haasdb-pw-saptest           HAAS-0002      True      91d
   

4. Ekspor nama secret yang dapat dirotasi, misalnya:

   ROTATABLE_SECRET=haasdb-pw-haas-alice
   

5. Menghapus permintaan rotasi tambahan yang belum siap:

   CUR_ROTATABLE_SECRET=$(kubectl get rotatablesecret ${ROTATABLE_SECRET?} -n ${NAMESPACE?} -ojsonpath='{.status.currentRotationRequestRef.name}')
   
   kubectl get rotationrequests -n ${NAMESPACE?} -o json | jq -r --arg rotatableSecret "${ROTATABLE_SECRET?}" --arg curRotatableSecret "${CUR_ROTATABLE_SECRET?}" '.items[] | select(.metadata.ownerReferences[0]? | .name==$rotatableSecret) | select(.status.conditions[0]? | .type=="Ready" and .status=="False") | select(.metadata.name != $curRotatableSecret) | .metadata.name' | xargs -r kubectl delete rotationrequests -n ${NAMESPACE?}
   

Modul keamanan hardware

Lisensi uji coba HSM yang dinonaktifkan masih dapat terdeteksi

Versi: 1.14.3, 1.14.4, 1.14.5

Gejala: Karena masalah umum yang ada di CipherTrust Manager, lisensi uji coba yang dinonaktifkan masih dapat terdeteksi dan dapat memicu peringatan kedaluwarsa palsu.

Solusi: Lihat HSM-R0003 untuk memverifikasi lisensi normal yang aktif dan menghapus lisensi uji coba yang dinonaktifkan.

Kebocoran deskriptor file host-daemon HSM

Versi: 1.14.x

Gejala: Jika HSM berjalan lebih dari 30 hari, kebocoran deskriptor file dapat menyebabkan layanan host-daemon berhenti merespons, sehingga menghasilkan error ServicesNotStarted.

Solusi: Mulai ulang layanan host-daemon. Untuk melakukannya, minta Operator Infrastruktur (IO) Anda untuk terhubung ke HSM melalui SSH sebagai pengguna ksadmin dan jalankan perintah berikut:

sudo systemctl restart host-daemon

Jika tidak berhasil, IO Anda dapat Mulai Ulang HSM yang Tidak Sehat.

HSM gagal dengan error ValidateNetworkConfig setelah booting

Versi: 1.14.x

Gejala: Resource kustom HSM tidak memasuki status Ready dan gagal karena error ValidateNetworkConfig. Error ini menampilkan pesan berikut: data0 interface MAC address {} is not active. Error ini terjadi jika sistem di-reboot dan antarmuka data utama yang berbeda ditetapkan.

Solusi: Ikuti runbook HSM-R0059 dan terapkan kembali konfigurasi jaringan HSM untuk jaringan data. Runbook ini aman untuk diikuti meskipun lebih dari satu HSM mengalami error ini.

KESEHATAN

Pemberitahuan SLO alarm palsu

Versi: 1.14.3

Gejala: SLO successRange dipicu secara keliru.

Solusi: Minta Operator Infrastruktur (IO) untuk memverifikasi apakah pemberitahuan tersebut adalah masalah yang sebenarnya atau alarm palsu.

Untuk melakukannya, saat pemberitahuan dipicu, ikuti runbook yang sesuai untuk mengatasi penyebab mendasar dari pemberitahuan Service Level Objective (SLO).

1. Kasus Satu: Jika runbook berhasil menyelesaikan masalah, dan pemberitahuan berhenti muncul, IO dapat menutup insiden terkait.

2. Kasus Dua: Jika runbook telah selesai, tetapi pemberitahuan terus muncul, hal ini menunjukkan potensi alarm palsu. Periksa apakah SLO rusak:

   kubectl get servicelevelobjective {SLO_NAME} -n {SLO_NAMESPACE} -o yaml --kubeconfig root-admin-kubeconfig| awk '/successRange/ { found1 = 1 } /labelFilter/ { found2 = 1 } END { if (found1 && found2) print "Broken 1.14.3 SLO detected"; else print "SLO does not have a known 1.14.3 issue" }'
   

3. Berdasarkan output: jika mengonfirmasi bahwa pemberitahuan adalah alarm palsu, IO kemudian harus membisukan pemberitahuan dalam instance air-gapped GDC; jika tidak, eskalasikan ke Dukungan Cloud.

4. Dalam kedua kasus tersebut, IO harus menghubungi Dukungan Cloud untuk memverifikasi bahwa komponen yang dapat dioperasikan dalam kondisi baik.

Konfigurasi SLO berbasis pengukur tidak valid

Versi: 1.14.3, 1.14.4

Gejala: Sebagian Tujuan Tingkat Layanan (SLO) tidak akan mengisi peristiwa baik, buruk, atau total karena kesalahan konfigurasi. SLO yang dimaksud didasarkan pada alat pengukur Prometheus dan harus dikonfigurasi dengan tepat.

Solusi:

Versi 1.14.3: Tidak ada solusi. Akibatnya, pemberitahuan SLO tidak akan diaktifkan untuk SLO yang terpengaruh.

Versi 1.14.4: Tersedia solusi untuk memperbaiki SLO. Untuk mengatasi masalah ini, setelan isGauge: true harus diterapkan ke spesifikasi SLO.

Contoh konfigurasi pengukur untuk SLO:

```yaml
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: ServiceLevelObjective
metadata:
  namespace: infra-obs
  name: fw-packet-discard-errors-slo
spec:
  successRange:
  - resource: fw
    description: Firewall packet discard rate with errors SLO
    runbookURL: FW-R0006
    goal: "0.995"
    isGauge: true
    period: 30d
    metricName: fw_packet_discard_errors_ps
    max: 2
```

Daftar SLO yang diketahui dan diperbaiki dengan setelan ini adalah:

• SLO Firewall:
  • fw-packet-discard-errors-slo
  • fw-packet-discard-no-error-slo
  • fw-packet-discard-unknown-protocol-slo
  • fw-uptime-slo
• SLO File:
  • file-ontap-appliance-availability-slo
  • file-ipsec-networking-availability-slo
  • file-ontap-networking-availability-slo
  • file-iscsi-client-availability-slo
  • file-multipath-client-availability-slo
  • file-trident-client-availability-slo

Pengelolaan akses dan identitas

Kegagalan pembuatan binding peran IAM

Versi: 1.14.3

Gejala: Nama binding peran IAM dibuat oleh sistem. Nama ini memiliki panjang maksimum 63 karakter, dalam format user-idp-prefix-rolename. Jika nama yang dibuat melebihi batas 63 karakter, pengikatan peran tidak dapat dibuat. Akibatnya, izin yang ditentukan menggunakan peran standar atau kustom tidak akan ditetapkan kepada pengguna.

Solusi: Pembuatan binding peran mungkin berhasil jika nama peran kustom atau standar sangat pendek, misalnya, 4-5 karakter.

Gagal membuat binding peran IAM untuk project-service-accounts

Versi: 1.14.3 1.14.4 1.14.5 1.14.6

Gejala: Akun layanan project (PSA) dengan peran organization-iam-admin tidak dapat menggunakan perintah gdcloud projects add-iam-policy-binding untuk menetapkan peran lain untuk dirinya sendiri, seperti peran project-iam-admin. Kekurangan ini mencegah PSA mengelola izinnya sendiri.

Solusi: Pastikan Anda memiliki peran organization-iam-admin. Kemudian, tetapkan peran project-iam-admin untuk diri Anda di namespace project PSA target, dan tetapkan peran project-iam-admin untuk PSA. Penyiapan izin ini memungkinkan PSA menetapkan izin tambahan untuk dirinya sendiri atau PSA lain.

Project baru mengalami penundaan dalam pembuatan peran bawaan

Versi: 1.14.3

Gejala: Saat project baru dibuat, project tersebut tidak memiliki peran default, seperti project-bucket-object-admin.

Solusi: Tunggu 15-60 menit, atau mulai ulang pengontrol iam-org-admin-cm-backend-controller secara manual di namespace iam-system pada cluster infrastruktur organisasi.

Konsol GDC tidak dapat membuat binding peran pertama

Versi: 1.14.4

Gejala: Saat membuat binding peran pertama untuk identitas layanan baru menggunakan konsol GDC, pembuatan binding peran dilaporkan berhasil, tetapi sebenarnya tidak berfungsi. Tindakan lebih lanjut pada identitas layanan akan gagal dan tidak berpengaruh, termasuk menambahkan binding peran tambahan atau menghapus binding peran.

Solusi: Gunakan gdcloud CLI untuk membuat binding peran pertama untuk identitas layanan. Semua tindakan mendatang dengan identitas layanan yang dilakukan menggunakan konsol GDC akan berfungsi dengan benar setelah binding peran pertama dilampirkan. Untuk mengetahui informasi selengkapnya, lihat Menetapkan binding peran ke identitas layanan.

AO tidak dapat memberikan akses ke peran di cluster infrastruktur untuk diri mereka sendiri

Versi: 1.14.3. 1.14.4

Tetap: Hotfix 21 1.14.3

Gejala: AOs tidak dapat memberikan akses ke peran apa pun di cluster infrastruktur untuk diri mereka sendiri atau pengguna lain.

Solusi: Pengguna AO harus menghubungi IO untuk mendapatkan akses yang diperlukan. IO dapat menggunakan IAC untuk memberikan akses yang diperlukan kepada pengguna AO.

Token akun layanan yang ada menjadi tidak valid

Versi: 1.14.3

Tetap: Hotfix 21 1.14.3

Gejala: Token akun layanan yang ada yang dikeluarkan oleh cluster pengguna menjadi tidak valid karena argumen apiserver service-account-issuer diubah setelah cluster dalam status berjalan setelah bootstrap. Masalah ini menyebabkan pod, misalnya, pod dengan container sidecar istio-proxy, di cluster pengguna gagal melakukan autentikasi menggunakan token akun layanan dan token akun layanan akan memerlukan waktu berjam-jam untuk di-refresh dengan konfigurasi baru.

Solusi: Mulai ulang pod secara manual di cluster pengguna agar token akun layanan diperbarui dengan konfigurasi baru.

Infrastructure as Code (IAC)

Kegagalan rekonsiliasi subkomponen karena namespace tidak ada

Versi: 1.14.3

Gejala: Subkomponen gagal merekonsiliasi. Hal ini terjadi karena namespace config-management-monitoring yang diperlukan tidak dibuat secara otomatis di cluster gdchservices-mp.

Solusi: Buat namespace config-management-monitoring di cluster gdchservices-mp menggunakan manifes berikut:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    configmanagement.gke.io/system: "true"
  name: config-management-monitoring
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep

Pengumpulan metrik IAC ConfigSync gagal

Versi: 1.14.3, 1.14.4

Gejala: Masalah pada subsistem pemantauan ConfigSync IAC mencegah deployment otel-collector dimulai. Metrik ConfigSync tidak dikumpulkan untuk pemantauan dan pemberitahuan.

Solusi: Selesaikan langkah-langkah berikut di cluster root-admin:

1. Jeda subkomponen iac-configsync-mon.
2. Edit objek MetricsProxySidecar/iac-configsync-metrics di namespace config-management-monitoring.

3. Di YAML MetricsProxySidecar/iac-configsync-metrics, temukan hal berikut:

   spec:
     [...]
     destinations:
     - certificate:
         secretName: iac-configsync-mon-target-cert
   

   Ubah bagian ini menjadi seperti berikut:

   spec:
     [...]
     destinations:
     - certificate:
         secretName: iac-configsync-mon-mon-target-cert
   

4. Mulai ulang deployment otel-collector di namespace config-management-monitoring.

IAC RootSync gagal

Versi: 1.14.3

Gejala: Ada masalah dalam menyinkronkan resource ConfigSync dari Gitlab ke cluster karena tidak adanya secret iac-creds . iac-creds tidak dirotasi karena masalah iacmanager.

Solusi: Selesaikan langkah-langkah berikut di cluster:

1. Ikuti runbook IAC-R0015 untuk mengatasi masalah kredensial IAC rahasia yang hilang. Rotasi kredensial pengelola IaC dan ConfigSync.

Inventaris

Audit inventaris gagal mencocokkan data

Versi: 1.14.3

Gejala: Subkomponen inv-audit gagal menyelaraskan, karena HarborRobotAccount hanya tersedia di bidang pengelolaan.

Solusi: Buat penonaktifan suara di AlertManager untuk menonaktifkan suara notifikasi component_reconciliation_errors selama component: inv.

Sistem pengelolaan kunci

KMS yang dikonfigurasi untuk menggunakan kunci root CTM tidak melakukan failover saat HSM tidak tersedia

Versi: 1.14.x

Gejala: Beberapa permintaan ke KMS gagal saat HSM tidak tersedia dan ada HSM lain yang tersedia yang dapat digunakan. Masalah ini hanya berlaku jika KMS dikonfigurasi untuk menggunakan kunci root CTM.

Solusi: Hapus HSM yang tidak tersedia dari HSMCluster dengan mengikuti buku panduan HSM-P0006. Kemudian, mulai ulang deployment kms-backend:

kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart deployment/kms-backend -n kms-system

Perintah ini akan memulai ulang pod kms-backend dan membangun kembali koneksi ke HSM di HSMCluster.

Load balancer

Pembuatan load balancer global gagal karena CIDR subnet habis

Versi: 1.14.3

Gejala: Pembuatan load balancer eksternal atau internal global gagal karena alamat IP yang tidak mencukupi di subnet global. Sistem tidak dapat mengalokasikan alamat IP secara dinamis untuk load balancer global karena pengontrol yang menggunakan jalur kode yang salah. Load balancer hanya mereferensikan satu subnet, dan jika subnet tersebut tidak memiliki alamat IP lain yang tersedia, tidak ada cara untuk beralih ke subnet lain. Keterbatasan ini menyebabkan error ditampilkan.

Solusi: Anda harus membuat subnet sendiri dan membuat alamat IP statis untuk resource ForwardingRule. Untuk mengetahui informasi selengkapnya tentang cara membuat subnet, lihat Mengonfigurasi subnet untuk jaringan workload. Saat membuat resource ForwardingRule, Anda dapat menentukan subnet di kolom cidrRef.

Versi: 1.14.3

Gejala: Objek load balancer tidak memasuki status Ready.

Solusi: Anda harus membuat resource Backend dengan kolom spec yang memiliki nilai. Resource Backend mengidentifikasi endpoint untuk load balancer. Tidak memberikan nilai untuk kolom spec dapat menyebabkan status error.

Memodifikasi resource load balancer tidak menyelaraskan layanan

Versi: 1.14.3

Gejala: Memodifikasi resource kustom load balancer tidak merekonsiliasi layanan load balancer.

Solusi: Untuk mengurangi masalah ini, hapus dan buat ulang load balancer dengan menghapus resource BackendService dan ForwardingRule dari load balancer tersebut.

Nama zona yang salah tidak ditolak

Versi: 1.14.3

Gejala: Resource BackendService global tidak menolak nama zona yang salah. Jika nama zona salah, load balancer akan gagal, bukan memvalidasi dan menolak konfigurasi.

Solusi: Anda harus memberikan nama zona yang benar yang sedang digunakan. Jika load balancer dikonfigurasi dengan tidak benar, resource kustom load balancer harus dihapus dan dibuat ulang.

Error webhook load balancer global dan zonal

Versi: 1.14.3

Gejala: Error berikut ditampilkan:

Error from server (InternalError): error when creating "STDIN": Internal error
occurred: failed calling webhook
"projectnetworkpolicies.networking.global.gdc.goog": failed to call webhook:
Post
"https://unet-global-org-cm-webhooks.unet-system.svc/validate-networking-global-gdc-goog-v1-projectnetworkpolicy?timeout=10s":
context deadline exceeded

Solusi: Untuk mengurangi masalah ini, mulai ulang dan hapus pod unet-global-cm:

root@bootstrapper-zone1:~# k8s.org get pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh   1/1     Running   42 (7h22m ago)   9d

root@bootstrapper-zone1:~# k8s.org delete pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh

Logging

Pod Loki mengalami error atau dihentikan karena kehabisan memori selama pemutaran ulang WAL

Versi: 1.14.3, 1.14.4, 1.14.5

Gejala:

Pod audit-logs-loki-io di namespace obs-system akan memasuki status CrashLoopBackOff. Hal ini disebabkan oleh kegagalan pemeriksaan keaktifan yang prematur atau penghentian Out Of Memory (OOM) selama pemutaran ulang Write-Ahead Log (WAL), karena nilai wal_replay_ceiling yang melebihi batas memori pod.

Solusi:

Ikuti langkah-langkah berikut untuk menyesuaikan konfigurasi Loki agar memungkinkan pemutaran ulang WAL yang berhasil. Perubahan akan diterapkan ke cluster yang terpengaruh (misalnya, root-admin atau org-infra)

1. Tetapkan KUBECONFIG=/path/to/affected-cluster.kubeconfig sebagai variabel lingkungan.

2. Jeda LoggingPipelineReconciler untuk mencegah pengontrol mengembalikan perubahan manual. Terapkan manifes ini:

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: log-logging-pipeline-pause
     namespace: root
   spec:
     subComponentRef: "log-admin"
     backend:
       operableParameters:
         controller:
           disableReconcilers: "LoggingPipelineReconciler"
   

   Pastikan penggantian aktif. Output harus menyertakan "disable-reconcilers=LoggingPipelineReconciler".

   kubectl get deploy -n obs-system log-admin-backend-controller -o jsonpath='{.spec.template.spec.containers[0].args}' --kubeconfig=${KUBECONFIG} | jq
   

3. Turunkan replay_memory_ceiling di ConfigMap audit-logs-loki-io-cm menjadi 8GB.

   kubectl edit cm audit-logs-loki-io-cm -n obs-system --kubeconfig=${KUBECONFIG}
   

   Ubah bagian wal:

   [...]
     wal:
       replay_memory_ceiling: 8GB ## <-- Change to 8GB
   [...]
   

4. Opsional: Menskalakan proxy objek. Jika pod obj-proxy mendekati batas resource, skala deployment untuk menangani peningkatan beban selama pemulihan.

   a. Periksa penggunaan resource:

   kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
   

   b. Jika penggunaan tinggi, skala deployment:

   kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
   

   c. Anda juga dapat meningkatkan batas memori pod (misalnya, dari 12000Mi menjadi 16000Mi) jika diperlukan.

5. Tingkatkan ukuran PVC untuk pod yang terpengaruh (misalnya, loki-storage-audit-logs-loki-io-0 dari 70Gi hingga 75Gi) untuk mencegah tekanan disk. Ikuti prosedur internal SUPP-R001 untuk mengubah ukuran PVC. Mulai ulang pada langkah berikutnya akan menerapkan ukuran baru.

6. Tambahkan startupProbe ke StatefulSet audit-logs-loki-io untuk memberikan waktu bagi pemutaran ulang WAL sebelum pemeriksaan keaktifan dimulai. Menyimpan perubahan akan memicu mulai ulang berkelanjutan pod (5-10 menit).

   kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}
   

   Tambahkan startupProbe ini ke spesifikasi penampung audit-logs-loki-io:

   startupProbe:
     failureThreshold: 1000
     httpGet:
       path: /ready
       port: loki
       scheme: HTTP
     periodSeconds: 10
     successThreshold: 1
     timeoutSeconds: 10
   

Memverifikasi solusi

1. Periksa Status Pod dan StatefulSet: Pastikan semua pod audit-logs-loki-io berstatus Running dan StatefulSet menampilkan semua replika sebagai siap.

   kubectl get po -n obs-system -l app=audit-logs-loki-io --kubeconfig=${KUBECONFIG}
   kubectl get sts -n obs-system audit-logs-loki-io --kubeconfig=${KUBECONFIG}
   

2. Konfirmasi bahwa PVC telah diubah ukurannya. Output yang diharapkan adalah 75Gi.

   kubectl get pvc -n obs-system loki-storage-audit-logs-loki-io-0 -o jsonpath='{.status.capacity.storage}' --kubeconfig=${KUBECONFIG} ; echo
   

3. Konfirmasi keberhasilan pemulihan WAL dengan memeriksa log pod untuk pesan errors=false.

   kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"
   

4. Pastikan penggunaan untuk direktori /wal di dalam pod rendah.

   kubectl exec -n obs-system audit-logs-loki-io-0 -c audit-logs-loki-io --kubeconfig=${KUBECONFIG} -- df -Ph /wal
   

5. Periksa Status Cincin Loki:

   a. Teruskan port layanan Loki:

   DATA_IP=$(ip -br -4 a s dev bond0| awk '{print $3}' | cut -d / -f 1)
   kubectl port-forward -n obs-system svc/audit-logs-loki-io --address $DATA_IP 43100:3100 --kubeconfig=${KUBECONFIG}
   

   b. Pastikan semua instance responsif di http://<DATA_IP>:43100/ring.

Membersihkan penggantian dan proxy objek

Setelah verifikasi berhasil, lakukan langkah-langkah pembersihan berikut.

1. Hapus Penggantian Subkomponen:

   kubectl delete subcomponentoverride log-logging-pipeline-pause -n root --kubeconfig=${KUBECONFIG}
   

2. Jika Anda menskalakan deployment obj-proxy, kembalikan ke ukuran aslinya.

Pemantauan

Webhook AlertManager gagal mengirimkan pemberitahuan untuk beberapa cluster

Versi: 1.14.3

Gejala: Webhook AlertManager gagal mengirim permintaan dan notifikasi pemberitahuan ke ServiceNow dari cluster selain cluster admin root atau cluster tempat instance ServiceNow berada. Oleh karena itu, pemberitahuan tidak dibuat di ServiceNow untuk organisasi.

Anda dapat mengidentifikasi bahwa webhook gagal mengirimkan pemberitahuan jika Anda berulang kali menerima pesan log error. Ikuti langkah-langkah berikut untuk mencari error yang berulang:

1. Ekspor variabel lingkungan:

   export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
   

   Ganti MGMT_API_KUBECONFIG dengan jalur ke file kubeconfig server Management API.

2. Temukan pod:

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} get pods \
     -n mon-system -o name | grep mon-alertmanager-servicenow-webhook-backend-
   

3. Dapatkan log:

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} logs POD_NAME -n mon-system
   

   Ganti POD_NAME dengan nama pod.

4. Cari error berulang yang terlihat seperti berikut:

   Errorsendingtherequest ... read: connection reset by peer
   

Catatan: Error yang melibatkan CHANGE_ME menunjukkan bahwa webhook ini belum disiapkan. Masalah ini hanya ada untuk cluster yang tidak memiliki instance ServiceNow.

Solusi: Solusi yang direkomendasikan untuk masalah ini adalah menjeda dua subkomponen, satu untuk pemberitahuan meta-pemantauan dan satu untuk pemberitahuan reguler. Kemudian, ganti label egress.networking.gke.io/enabled: "true" dengan networking.private.gdc.goog/infra-access: enabled di deployment mon-alertmanager-servicenow-webhook-backend cluster yang terpengaruh. Dengan label ini, pod dapat berkomunikasi dengan cluster infrastruktur lain tanpa mengandalkan gateway keluar.

Ikuti langkah-langkah berikut untuk menerapkan solusi sementara yang direkomendasikan:

1. Ekspor variabel lingkungan:

   export ROOT_KUBECONFIG=ROOT_KUBECONFIG
   export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
   export ORG=ORG
   

   Ganti kode berikut:

   • ROOT_KUBECONFIG: jalur ke file kubeconfig cluster admin root.
   • MGMT_API_KUBECONFIG: jalur ke file kubeconfig server Management API.
   • ORG: namespace organisasi.

2. Menjeda subkomponen:

   • Jeda subkomponen mon-alertmanager-servicenow-webhook:

   kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-alertmanager-servicenow-webhook" \
     -n "${ORG}" lcm.private.gdc.goog/paused=true
   

   • Jeda subkomponen mon-meta-monitoring:

   kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-meta-monitoring" \
     -n "${ORG}" lcm.private.gdc.goog/paused=true
   

3. Perbarui deployment mon-alertmanager-servicenow-webhook-backend yang mencakup sebagian besar pemberitahuan:

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
     -n mon-system mon-alertmanager-servicenow-webhook-backend
   

4. Ganti label di spec.template.metadata.labels dari egress.networking.gke.io/enabled: "true" menjadi networking.private.gdc.goog/infra-access: "enabled".

5. Perbarui deployment meta-alertmanager-servicenow-webhook yang mencakup pemberitahuan terkait stack pemantauan:

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
     -n mon-system meta-alertmanager-servicenow-webhook
   

6. Ganti label di spec.template.metadata.labels dari egress.networking.gke.io/enabled: "true" menjadi networking.private.gdc.goog/infra-access: "enabled".

Atau, Anda dapat menggunakan Grafana untuk melihat pemberitahuan yang sama.

Insiden ServiceNow terkadang diduplikasi

Versi: 1.14.3

Gejala: Anda mungkin melihat insiden ServiceNow duplikat untuk pod yang sama.

Solusi: Anda dapat mengidentifikasi tiket duplikat dengan mencocokkan sidik jari dalam deskripsi insiden.

Metrik infrastruktur mungkin terlalu sensitif

Versi: 1.14.3

Gejala: Anda mungkin melihat alarm untuk pemberitahuan oclcm-reconciler-success-rate.

Solusi: Anda dapat menyenyapkan pemberitahuan dengan aman. Ini adalah peringatan yang terlalu berisik dan kami sedang berupaya meningkatkan kualitas sinyalnya.

Metrik rekonsiliasi mungkin terlalu sensitif

Versi: 1.14.3, 1.14.4, 1.14.5

Gejala: Anda mungkin melihat alarm untuk pemberitahuan component_reconciliation_errors.

Solusi: Anda dapat menyenyapkan pemberitahuan dengan aman dengan mengikuti runbook MON-R2009. Ini adalah notifikasi yang terlalu berisik.

Dua peringatan palsu terbuka di cluster admin root

Versi: 1.14.3

Gejala: Notifikasi MON-A0001_slow dan MON-A0001_fast berada dalam status aktif di cluster admin root.

Insiden di ServiceNow akan terlihat seperti contoh berikut:

number        priority        sys_created_on        u_organization_id   short_description   active
INC004043     1 - Critical    2025-04-30 08:29:00   root                MON-A0001_slow      true
INC0040427    1 - Critical    2025-04-30 08:28:55   root                MON-A0001_fast      true

Insiden tersebut memiliki deskripsi berikut:

Description:
Message: "Blackbox monitoring metrics pipeline down"
Runbook URL: MON-R0001
Generator URL: cortex.mon-system.svc:9009/graph?g0.expr=%28mon_metrics_pipeline_error_rate1h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29+and+mon_metrics_pipeline_error_rate5m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29%29+or+%28mon_metrics_pipeline_error_rate6h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29+and+mon_metrics_pipeline_error_rate30m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29%29&g0.tab=1
AlertCode: MON-A0001
Severity: critical
Cluster: org-1-admin
Namespace: <no value>
Pod Name: <no value>
fingerprint: 3b386f1373178e97

Catatan: Kolom u_organization_id menampilkan nilai root, tetapi cluster dalam deskripsi adalah ORG_NAME-admin. Anda dapat menemukan pemberitahuan di instance Grafana pada cluster admin root.

Solusi: Ikuti langkah-langkah berikut untuk menyelesaikan masalah hanya di cluster admin root:

1. Hapus label monitoring.gdc.goog/metamonitoring-project=mon-system di mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

2. Hapus semua aturan perekaman dengan nama mon_metrics_pipeline_absent dan nilai label cluster ORG_NAME-admin dari mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

   Contoh berikut menunjukkan aturan perekaman mon_metrics_pipeline_absent yang akan dihapus:

   Expr:               absent(probe_success{job="mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric",cluster="gdchservices-admin"}) OR on() vector(0)
       Labels:
         _source_project:  blackbox-monitoring-obs-system
         Cluster:          gdchservices-admin
         Job:              mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric
       Record:             mon_metrics_pipeline_absent
   

Peringatan MON_A0001_slow dan MON_A0001_fast akan kembali ke status Normal setelah beberapa menit (sekitar 40 menit).

Pengelola pengontrol admin root menampilkan tingkat error yang tinggi

Versi: 1.14.3

Gejala: Anda mungkin melihat alarm untuk pemberitahuan ControllerReconciliationErrorRateHigh. Pengelola pengontrol akan menampilkan log yang menyatakan: ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

Solusi: Anda dapat menonaktifkan pengontrol yang menyebabkan error dengan aman.

1. Ekspor variabel lingkungan:

   export ROOT_KUBECONFIG=ROOT_KUBECONFIG
   

2. Edit deployment pengelola pengontrol admin root:

   kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
     -n gpc-system root-admin-controller
   

   Dalam penampung manager, jika belum ada argumen --disable-reconcilers, tambahkan argumen dengan nilai --disable-reconcilers=ApplianceStorageTunnelReconciler. Jika ada, tambahkan rekonsiliasi ApplianceStorageTunnelReconciler dengan koma. Contoh: --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler

Log error harus kosong.

Dasbor KUB tidak menampilkan data di semua panel PA

Versi: 1.14.3

Gejala: Dasbor KUB tidak menampilkan data di semua panel di Grafana untuk Admin Platform.

Solusi: Jeda subkomponen KSM dan perbarui monitoringtarget dan metricsproxysidecar:

1. Menjeda subkomponen:

   export SUBCOMPONENT_NAME=mon-kube-state-metrics
   export SUBCOMPONENT_NAMESPACE=ORG_NAME
   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true
   

   Ganti kode berikut:

   • ORG_NAME: nama organisasi
   • ROOT_ADMIN_KUBECONFIG: jalur ke kubeconfig root-admin

2. Tambahkan kode berikut ke mon-kube-state-metrics-metrics-proxy metricsproxysidecar di bagian .spec.destinations:

     - certificate:
     secretName: mon-pa-kube-state-metrics-cert
   port: 8091
   

   metricsproxysidecar yang diperbarui mungkin terlihat seperti ini:

   ...
   spec:
     containerName: otel-collector
     destinations:
     - certificate:
         secretName: mon-io-kube-state-metrics-cert
       port: 8090
     - certificate:
         secretName: mon-pa-kube-state-metrics-cert
       port: 8091
     resources:
       limits:
   ...
   

3. Hapus bagian matchClusters: dari mon-pa-kube-state-metrics monitoringtarget spec. mon-pa-kube-state-metrics monitoringtarget spec yang diperbarui mungkin terlihat seperti ini:

   ...
   spec:
     podMetricsEndpoints:
       metricsRelabelings:
       - action: replace
         replacement: platform-obs
         targetLabel: _gdch_project
       path:
         value: /metrics
       port:
         value: 8091
       scheme:
         value: http
       scrapeInterval: 60s
       scrapeTimeout: 45s
     selector:
       matchLabels:
         monitoringtarget: mon-kube-state-metrics
   

Izin salah dikonfigurasi untuk peran observability-admin-debugger

Versi: 1.14.3, 1.14.4

Gejala: IO tidak dapat memulai ulang pod cortex atau prometheus di namespace mon-system.

Solusi:

Untuk organisasi:

1. Jeda subkomponen iam-common.

2. Perbarui observability-admin-debugger/iam-system roleTemplate menjadi berikut:

   apiVersion: iam.private.gdc.goog/v1alpha1
   kind: RoleTemplate
   metadata:
     name: observability-admin-debugger
     namespace: iam-system
   spec:
     metadata:
       roleType: predefined
       hierarchyLevel: org
       persona: infra-operator
       displayName: "Observability Admin"
       bindingType: rolebinding
       roleNamespace: "mon-system"
       operableComponent: IAM
     rules:
     - apiGroups:
       - "apps"
       resources:
       - "deployments"
       resourceNames:
       - "logmon-operator"
       - "cortex-tenant"
       - "meta-blackbox-exporter"
       - "blackbox-exporter"
       verbs:
       - "*"
     - apiGroups:
       - "apps"
       resources:
       - "statefulsets"
       resourceNames:
       - "anthos-prometheus-k8s"
       - "meta-prometheus"
       - "mon-prober-backend-prometheus"
       - "primary-prometheus-shard0-replica0"
       - "primary-prometheus-shard0-replica1"
       - "primary-prometheus-shard1-replica0"
       - "primary-prometheus-shard1-replica1"
       verbs:
       - "*"
     - apiGroups:
       - ""
       resources:
       - "secrets"
       resourceNames:
       - "anthos-prometheus-scrape-cert"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       - "anthos-prometheus-etcd-scrape"
       verbs:
       - "*"
     - apiGroups:
       - "cert-manager.io"
       resources:
       - "certificates"
       resourceNames:
       - "anthos-prometheus-scrape"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       verbs:
       - "get"
       - "list"
       - "watch"
   

Untuk admin utama:

1. Jeda subkomponen iam-common.

2. Perbarui observability-admin-debugger-root/iam-system roleTemplate menjadi berikut:

   apiVersion: iam.private.gdc.goog/v1alpha1
   kind: RoleTemplate
   metadata:
     name: observability-admin-debugger
     namespace: iam-system
   spec:
     metadata:
       roleType: predefined
       hierarchyLevel: org
       persona: infra-operator
       displayName: "Observability Admin"
       bindingType: rolebinding
       roleNamespace: "mon-system"
       operableComponent: IAM
     rules:
     - apiGroups:
       - "apps"
       resources:
       - "deployments"
       resourceNames:
       - "logmon-operator"
       - "cortex-tenant"
       - "meta-blackbox-exporter"
       - "blackbox-exporter"
       verbs:
       - "*"
     - apiGroups:
       - "apps"
       resources:
       - "statefulsets"
       resourceNames:
       - "anthos-prometheus-k8s"
       - "meta-prometheus"
       - "mon-prober-backend-prometheus"
       - "primary-prometheus-shard0-replica0"
       - "primary-prometheus-shard0-replica1"
       - "primary-prometheus-shard1-replica0"
       - "primary-prometheus-shard1-replica1"
       verbs:
       - "*"
     - apiGroups:
       - ""
       resources:
       - "secrets"
       resourceNames:
       - "anthos-prometheus-scrape-cert"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       - "anthos-prometheus-etcd-scrape"
       verbs:
       - "*"
     - apiGroups:
       - "cert-manager.io"
       resources:
       - "certificates"
       resourceNames:
       - "anthos-prometheus-scrape"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       verbs:
       - "get"
       - "list"
       - "watch"
   

Peran debugger Grafana tidak ada

Versi: 1.14.3, 1.14.4

Gejala: Peran grafana-debugger-cp tidak ada di namespace project shadow observability (*-obs-system). Pengguna tidak dapat diberi serangkaian izin yang tepat yang diperlukan untuk men-debug masalah terkait grafana.

Solusi: Buat resource kustom ClusterRoleTemplate berikut di infra-cp, dan gunakan ClusterRole yang dibuat untuk mendapatkan izin grafana-debugger yang sesuai.

apiVersion: iam.private.gdc.goog/v1alpha1
kind: ClusterRoleTemplate
metadata:
  name: grafana-debugger-cp
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: infra-cp
    persona: infra-operator
    displayName: "Grafana Admin"
    bindingType: rolebinding
    operableComponent: MON
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "grafana-proxy-server"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "grafana"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    resourceNames:
    - "grafana-0"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    verbs:
    - "get"
    - "list"
    - "watch"
  - apiGroups:
    - "monitoring.private.gdc.goog"
    resources:
    - "datasources"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"
  - apiGroups:
    - "monitoring.global.private.gdc.goog"
    resources:
    - "datasourcereplicas"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"

Metrik dan log lintas zona tidak terlihat setelah penambahan Zona baru

Versi: 1.14.*

Gejala: Dasbor grafana tidak menampilkan log dan metrik untuk zona yang baru ditambahkan.

Solusi 1: Mulai ulang deployment datasource-proxy:

kubectl KUBECONFIG=${KUBECONFIG_ORG} rollout restart deployment datasource-proxy -n mon-system

Tindakan ini akan memulai ulang pod datasource-proxy dan memperbarui konfigurasi endpoint lintas zona untuk zona yang baru ditambahkan.

Finalizer MonitoringTarget memblokir penghapusan namespace

Versi: 1.14.3, 1.14.4

Gejala: Namespace tidak dihapus dan ada cluster yang tidak sehat di organisasi terkait.

Solusi: Hapus finalizer secara manual dari resource kustom MonitoringTarget yang memblokir penghapusan namespace.

Penghapusan project terhenti karena finalizer tertunda dasbor dan sumber data

Versi: 1.14.3, 1.14.4

Diperbaiki: Hotfix 1.14.3 22

Gejala: Project tidak dihapus dan menghentikan namespace yang memiliki error seperti contoh berikut:

Some resources are remaining: dashboards.observability.gdc.goog has 2 resource instances, datasources.monitoring.private.gdc.goog has 2 resource instances.

Solusi: Hapus finalizer dasbor dan sumber data secara manual.

Metrik dari KSM tidak terlihat

Versi: 1.14.3

Diperbaiki: Hotfix 1.14.3 22

Gejala: Dasbor KUB menampilkan No Data di semua panel.

Solusi: Jeda subkomponen KSM dan perbarui monitoringtarget dan metricsproxysidecar.

1. Jeda subkomponen:

   export SUBCOMPONENT_NAME=mon-kube-state-metrics
   export SUBCOMPONENT_NAMESPACE=ORG_NAME
   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true
   

   Ganti kode berikut:

   • ORG_NAME: nama organisasi.
   • ROOT_ADMIN_KUBECONFIG: jalur ke kubeconfig root-admin.

2. Tambahkan kode berikut ke mon-kube-state-metrics-metrics-proxy metricsproxysidecar di .spec.destinations:

   - certificate:
     secretName: mon-pa-kube-state-metrics-cert
   port: 8091
   

   mon-kube-state-metrics-metrics-proxy metricsproxysidecar yang diperbarui akan terlihat seperti contoh ini:

   ...
   spec:
     containerName: otel-collector
     destinations:
     - certificate:
         secretName: mon-io-kube-state-metrics-cert
       port: 8090
     - certificate:
         secretName: mon-pa-kube-state-metrics-cert
       port: 8091
     resources:
       limits:
   ...
   

3. Hapus bagian matchClusters: dari spesifikasi monitoringtarget mon-pa-kube-state-metrics. Spesifikasi monitoringtarget mon-pa-kube-state-metrics yang diperbarui akan terlihat seperti ini:

   ...
   spec:
     podMetricsEndpoints:
       metricsRelabelings:
       - action: replace
         replacement: platform-obs
         targetLabel: _gdch_project
       path:
         value: /metrics
       port:
         value: 8091
       scheme:
         value: http
       scrapeInterval: 60s
       scrapeTimeout: 45s
     selector:
       matchLabels:
         monitoringtarget: mon-kube-state-metrics`
   

Pipeline Metrik sistem tidak berfungsi

Versi: 1.14.3

Gejala: Pemberitahuan MON-A0001 aktif meskipun setelah mengikuti buku pedoman MON-R0001.

Solusi:

1. Jika masalah terlihat di cluster admin, buat SubcomponentOverride berikut di root-admin menggunakan buku panduan IAC-R0004. Untuk cluster lain seperti pengguna, perimeter, atau bersama, buat SubcomponentOverride di ${ORG}-mp.

   kind: SubcomponentOverride
   metadata:
     name: mon-cortex-tenant
     namespace: <NAMESPACE>
   spec:
     backend:
       operableParameters:
         concurrency: 1024
         resourcesLimit:
           cpu: "8"
           memory: 16Gi
     subComponentRef: mon-cortex-tenant
   

2. Temukan NAMESPACE yang benar:

   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"
   

   Outputnya adalah sebagai berikut:

   org-1-mp             mon-cortex-tenant                      27h   ReconciliationCompleted
   org-1                mon-cortex-tenant                      46h   ReconciliationCompleted
   root                 mon-cortex-tenant                      47h   ReconciliationCompleted
   

   Namespace-nya adalah root, jika pipeline tidak berfungsi untuk root-admin, atau org-1, jika pipeline tidak berfungsi untuk org-1 admin:

   kubectl --kubeconfig=ORG_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"
   

   Outputnya adalah sebagai berikut:

   g-org-1-perimeter-cluster        mon-cortex-tenant                     40h   ReconciliationCompleted
   g-org-1-shared-service-cluster   mon-cortex-tenant                     40h   ReconciliationCompleted
   user-vm-1-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
   user-vm-2-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
   

   Di sini, namespace yang benar bisa berupa g-org-1-perimeter-cluster, g-org-1-shared-service-cluster, user-vm-1-cluster, atau user-vm-2-cluster, bergantung pada cluster mana yang mengalami gangguan pipeline metrik sistem.

3. Setelah menerapkan SubcomponentOverride, mulai ulang deployment cortex-tenant di cluster masing-masing. Periksa apakah nilai telah diperbarui di cluster masing-masing:

   kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
   

4. Perbarui kolom konkurensi.

5. Mulai ulang deployment cortex-tenant:

   kubectl --kubeconfig ${KUBECONFIG:?} rollout restart deployment/cortex-tenant -n mon-system
   

Multi-tenancy

Konsol tidak menunjukkan kegagalan pembuatan node pool

Versi: 1.14.4, 1.14.5, 1.14.6

Tetap: 1.14.7

Gejala: Di konsol GDC, saat pembuatan kumpulan node gagal, UI menampilkan pesan creation in progress yang salah, yang menunjukkan bahwa kumpulan node berhasil dibuat.

Solusi: Gunakan gdcloud CLI untuk memvalidasi pembuatan kumpulan node.

Multizona

Zona yang tidak dapat diakses mengalihkan ke halaman autentikasi

Versi: 1.14.x

Gejala: Saat zona tidak dapat diakses, konsol GDC akan mengalihkan ke halaman yang menampilkan error autentikasi. Namun, tidak dapat diaksesnya zona mungkin tidak disebabkan oleh masalah autentikasi, tetapi mungkin disebabkan oleh gangguan zonal.

Solusi: Gunakan URL zona untuk mengatasi masalah ini. Jika URL zonal juga tidak berfungsi, minta Operator Infrastruktur (IO) Anda untuk mendiagnosis apakah zona yang Anda terima mengalami masalah autentikasi sedang tidak aktif.

Peran untuk melihat zona menggunakan gcloud CLI tidak diterapkan

Versi: 1.14.x

Gejala: Peran IAM yang diperlukan untuk menggunakan perintah gdcloud zones list tidak diterapkan ke semesta GDC secara default. Peran yang tidak ada, yang tidak tersedia sebagai peran bawaan, menghalangi kemampuan untuk menggunakan gdcloud CLI guna mencantumkan zona.

Solusi: Terapkan peran IAM global-zone-viewer dan resource binding peran ke server API global:

1. Buat file YAML peran, seperti global-zone-viewer.yaml, dengan konten berikut:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: global-zone-viewer
     namespace: mz-system
   rules:
   - apiGroups:
     - location.mz.global.private.gdc.goog
     resources:
     - zones
     verbs:
     - get
     - list
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: global-zone-viewer-binding
     namespace: mz-system
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: global-zone-viewer
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

2. Terapkan file YAML ke server API global organisasi:

   kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f global-zone-viewer.yaml
   

Pengikatan peran ini mengautentikasi semua pengguna dalam sistem untuk melihat zona menggunakan gdcloud zones list.

Error login URL konsol global yang terjadi sesekali

Versi: 1.14.x

Gejala: Saat login ke konsol GDC dengan URL global, Anda mungkin menerima error yang menyatakan bahwa sesi Anda tidak lagi valid. Error ini dapat disebabkan oleh bug jaringan yang mendasarinya, dan bukan representasi akurat dari status sesi Anda.

Solusi: Login ke konsol GDC dengan URL zona untuk mengelola resource global dari dalam setiap zona. Untuk mengetahui informasi selengkapnya tentang cara mengganti konteks zona dari konsol GDC, lihat Mengelola resource di seluruh zona.

Jaringan

Menyesuaikan urutan zona MultiZoneNetworkConfig menyebabkan kegagalan penggantian konfigurasi

Versi: Semua versi 1.14.x dapat terpengaruh.

Gejala:

1. Status READY untuk sakelar Top of Rack (ToR) adalah False. Hal ini dapat dikonfirmasi dengan menjalankan perintah berikut:

   kubectl get torswitches -A
   

2. Penggantian konfigurasi switch gagal dengan error yang menunjukkan bahwa entri sudah ada. Hal ini dapat dilihat di log penggantian konfigurasi switch. Pesan errornya mirip dengan yang berikut ini:

   % Insertion failed - entry already exists
   

Masalah ini disebabkan oleh penyesuaian urutan zona dalam MultiZoneNetworkConfig. Sistem membuat nomor urut untuk aturan daftar akses BGP berdasarkan posisi setiap zona dalam daftar konfigurasi. Jika urutan zona diubah, sistem akan membuat aturan baru dengan nomor urut yang berbeda yang bertentangan dengan aturan yang sudah ada di switch.

Solusi:

Untuk mengatasi masalah ini, hapus konfigurasi daftar akses jalur AS BGP yang bentrok secara manual dari setiap switch ToR yang terpengaruh. Hal ini memungkinkan sistem menyelaraskan dan menerapkan konfigurasi yang benar.

1. Buat koneksi SSH ke setiap switch ToR yang tidak dalam status Ready.

2. Masuk ke mode konfigurasi global:

   config t
   

3. Hapus konfigurasi daftar akses yang bertentangan:

   no ip as-path access-list other-zones
   

4. Keluar dari mode konfigurasi.

Setelah perintah ini dieksekusi di semua switch yang terpengaruh, rekonsiliator akan menerapkan konfigurasi yang benar, dan switch akan bertransisi ke status READY.

Masa berlaku penerapan config-replace

Versi: Semua versi 1.14.x dapat terpengaruh.

Gejala:

Sejumlah besar Daftar Kontrol Akses (ACL) menyebabkan waktu tunggu habis saat mengonfigurasi switch jaringan. Resource kustom BorderLeafSwitch tidak dalam status Ready, dan saat membuat koneksi SSH dengan switch yang belum siap, status Commit expiry akan terlihat.

Misalnya, perintah berikut menunjukkan status:

sh config-replace log verify

Outputnya mirip dengan hal berikut ini:

  Config-replace type: atomic .replace_tmp_11924
  Start Time: Wed Jul 09 18:08:33 2025
  Operation Status: Success
  Commit Status: Commit expiry

Solusi::

Pada versi 1.14.3 atau 1.14.7+, edit resource kustom SubcomponentOverride bernama pnet-core-override di namespace root, dan tambahkan kolom httpTimeout ke .spec.operableParameters.netDevGW.

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-core-override
  namespace: root
spec:
  backend:
    bootstrapParameters:
      enableMetricsEncryption: true
    operableParameters:
      disableNetworkReconcilerFeatures: ""
      enableOperationStoragePVC: false
      netDevGW:
        httpTimeout: 10m
  subComponentRef: pnet-core

Tunggu selama 15 menit agar infrastruktur otomatisasi dapat mengirimkan konfigurasi baru ke switch. Konfigurasi httpTimeout sesuai kebutuhan hingga pesan Commit expiry hilang.

Pada versi 1.14.4, 1.14.5, dan 1.14.6, lakukan config-replace secara manual dan terapkan perubahan.

1. Menjeda tombol:

   export SWITCH_NAME=SWITCH_NAME # example: aa-aa-blsw01
   export SWITCH_TYPE=SWITCH_TYPE # example: borderleafswitch
   
   kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused="true"
   

2. Ikuti runbook PNET-P0001 untuk mendapatkan akses tombol.

3. Temukan konfigurasi yang akan diganti:

   switch-cli# dir | grep new_config
   

4. Selesaikan config-replace:

   switch-cli# configure replace <new_config_file>
   

   Proses ini mungkin memerlukan waktu lebih dari lima menit.

5. Setelah config-replace berhasil, lakukan commit perubahan:

   switch-cli# configure replace commit
   

6. Lanjutkan pengalihan:

   kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused-
   

Deployment dengan ASN BGP 4 byte gagal

Versi: 1.14.3, 1.14.4

Gejala: Mengonfigurasi Border Gateway Protocol (BGP) dengan Nomor Sistem Otonom (ASN) 4 byte pada switch jaringan menyebabkan kegagalan konfigurasi. Tanpa konfigurasi BGP yang diterapkan dengan benar, jaringan dalam zona GDC tersebut mungkin tidak dapat membuat perutean yang tepat, sehingga menyebabkan masalah konektivitas, ketidakmampuan untuk mengiklankan rute, atau ketidakstabilan jaringan secara umum. Belum ada solusinya untuk saat ini.

Traffic anycast global diblokir

Versi: 1.14.3

Gejala: Traffic yang menuju ke endpoint anycast global diblokir oleh Daftar Kontrol Akses (ACL).

Solusi:

Untuk mengatasi masalah saat traffic anycast global diblokir oleh Daftar Kontrol Akses (ACL), Anda perlu membuat resource kustom SubcomponentOverride di cluster admin root untuk secara eksplisit mengizinkan traffic ke blok CIDR anycast server DNS global. Ikuti langkah-langkah berikut:

1. Temukan semua blok CIDR anycast global. Untuk menemukan blok CIDR anycast global yang akan diupdate, ikuti langkah-langkah berikut:

   1. Terhubung ke server API global root.

   2. Mencantumkan semua resource kustom subnet di semua namespace menggunakan perintah:

      kubectl get subnet -A
      

   3. Memfilter output untuk menemukan resource subnet tempat filter metadata.name berisi kata kunci anycast.

   4. Untuk setiap resource subnet yang ditemukan dengan anycast dalam namanya, catat nilai spec.subnet. Nilai ini merepresentasikan blok CIDR anycast global.

2. Di cluster admin root, buat resource kustom SubcomponentOverride bernama pnet-trafficpolicy-dc-override di namespace root. Untuk setiap subnet anycast yang Anda identifikasi pada langkah sebelumnya, tambahkan aturan seperti yang ditunjukkan dalam file YAML:

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: pnet-trafficpolicy-dc-override
     namespace: root
   spec:
     backend:
       operableParameters:
         breakglassRules:
           default-traffic-policy-data:
           - IPVersions:
             - IPv4
             L4Protocol: IP
             action: Accept
             description: INTERCONNECT_RULE_DESCRIPTION
             destinationEndPoint:
               host:
                 hostPrefix: GLOBAL_ANYCAST_CIDR
               port:
                 portType: ANY
             direction: Ingress
             enforcePoints:
             - enableLogging: false
               enforcePointType: DataInterconnect
             sourceEndPoint:
               host:
                 hostType: ANY
               port:
                 portType: ANY
           - IPVersions:
             - IPv4
             L4Protocol: IP
             action: Accept
             description: HAIRPIN_RULE_DESCRIPTION
             destinationEndPoint:
               host:
                 hostType: ANY
               port:
                 portType: ANY
             direction: Ingress
             enforcePoints:
             - enableLogging: false
               enforcePointType: DataHairpin
             sourceEndPoint:
               host:
                 hostPrefix: GLOBAL_ANYCAST_CIDR
               port:
                 portType: ANY
     subComponentRef: pnet-trafficpolicy-dc
   

   Ganti kode berikut:

   • INTERCONNECT_RULE_DESCRIPTION: teks deskriptif untuk aturan jaringan interkoneksi.
   • GLOBAL_ANYCAST_CIDR: blok CIDR anycast global, seperti 136.125.38.128/28. Untuk setiap anycast yang Anda temukan di langkah sebelumnya, buat aturan menggunakan file YAML ini.
   • HAIRPIN_RULE_DESCRIPTION: Teks deskriptif untuk aturan jaringan hairpin.

Kegagalan DCI parsial menyebabkan kehilangan traffic

Versi: 1.14.3

Gejala: Jika kedua link Interkoneksi Pusat Data (DCI) yang menghubungkan switch leaf border zona ke switch operator, atau jika switch leaf border zona mengalami kegagalan hardware, sekitar 50% traffic jaringan lintas zona akan hilang.

Nama VRF terlalu panjang

Versi: 1.14.2

Gejala: Anda mungkin melihat pesan seperti contoh ini, yang menunjukkan bahwa switch tidak dalam kondisi baik saat menjalankan perintah ini:

sh config-replace log verify

Output-nya mungkin terlihat seperti contoh ini:

Operation            : Config-replace to user config
Checkpoint file name : .replace_tmp_20791
Scheme               : tmp
Cfg-replace done By  : admin
Cfg-replace mode     : atomic
Verbose              : disabled
Start Time           : Fri, 20:03:38 08 Nov 2024
Start Time UTC       : Fri, 20:03:38 08 Nov 2024
-------------------------------------------
Command : snmp-server context gdch-services-orginfrainternal-vrf vrf gdch-servic
es-orginfrainternal-vrf, parse error : -20, mode : /exec/configure/vrf
Failed to parse: snmp-server context gdch-services-orginfrainternal-vrf vrf gdch
-services-orginfrainternal-vrf
Configuration above is invalid or not supported via CR/rollback feature

Solusi: Nama CR organisasi dapat berisi maksimum 19 karakter.

Komunikasi pod StatefulSet gagal

Versi: 1.14.3, 1.14.4

Diperbaiki: Hotfix 23 1.14.3, 1.14.5

Gejala: Masalah atau gangguan konektivitas karena penghapusan objek Cilium Endpoint (CEP) tidak ditangani dengan benar setelah pod StatefulSet dimulai ulang. Hal ini dapat menyebabkan identitas endpoint yang tidak dikelola menyebabkan kebijakan jaringan secara keliru membatalkan traffic yang sah. Pod yang terpengaruh dapat diverifikasi dengan memeriksa tidak adanya objek CEP yang sesuai:

kubectl get cep -A | grep [*POD_IP*]

Solusi: Mulai ulang pod StatefulSet yang terpengaruh untuk memperbarui UID-nya dan memuat ulang metadata terkait:

kubectl rollout restart statefulset [*STATEFULSET_NAME*] -n [*NAMESPACE*]

Node tidak dapat dijangkau di Jaringan Data

Ini adalah masalah langka yang dapat terjadi jika pod anetd terjebak dalam loop error.

Resource kernel yang penting untuk konektivitas node dapat mengalami masalah dalam status yang rusak.

Panduan ini menguraikan gejala masalah ini serta langkah-langkah yang dapat dilakukan untuk menyelesaikan masalah tersebut.

Versi:

Semua versi Google Distributed Cloud (GDC) dengan air gap dapat terpengaruh.

Gejala:

Jika masalah ini terjadi, Anda mungkin melihat gejala berikut:

• Node macet dalam status NotReady
• Mendeskripsikan node akan menampilkan pesan kubelet:kubelet was found unhealthy; repair flag : true
• Akses SSH ke node tidak dapat dilakukan di Jaringan Data

Solusi:

Gunakan petunjuk berikut untuk memperbaiki setiap node yang tidak sehat:

1. Dapatkan alamat IP Pengelolaan node yang terpengaruh:

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get -n gpc-system servers/NODE_NAME -ojsonpath='{.spec.managementNetwork.ips[0]}'
   

2. Dapatkan akses SSH ke node yang terpengaruh.

3. Hubungkan ke node menggunakan SSH menggunakan alamat IP Pengelolaan node.

4. Di node, jalankan perintah berikut, lalu tutup koneksi SSH:

   tc filter del dev bond0 egress
   

5. Mulai ulang daemonset anetd untuk cluster dengan node yang terpengaruh:

   kubectl --kubeconfig AFFECTED_CLUSTER_KUBECONFIG rollout restart ds/anetd -n kube-system
   

Membuat PNP izinkan-semua-egress menolak traffic yang tidak terduga

Versi:

Semua versi Google Distributed Cloud (GDC) dengan air gap dapat terpengaruh.

Gejala: Kebijakan jaringan project (PNP) allow-all-egress mengizinkan traffic ke endpoint dalam project dan endpoint eksternal di luar cluster, tetapi tidak mengizinkan traffic ke endpoint sistem. Masalah ini dapat menyebabkan akses ke sistem dan layanan pihak pertama diblokir, seperti resolusi DNS dan penyimpanan objek.

PNP allow-all-egress mungkin terlihat seperti berikut:

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-all-egress
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - {}

Solusi: Hapus allow-all-egress PNP. Secara default, setelah Perlindungan pemindahan data yang tidak sah dinonaktifkan, traffic diizinkan ke project dan endpoint eksternal di luar endpoint cluster dan sistem.

kubectl delete pnp  [*ALLOW_ALL_EGRESS_PNP_NAME*] -n [*NAMESPACE*]

Masalah dasbor Grafana SLO ketersediaan lintas zona multi-zona

Versi: 1.14.3

Gejala: Di Grafana, dasbor SLO pnet-cross-zone-availability tidak menampilkan metrik apa pun.

Solusi: Ikuti runbook PNET-P0001 untuk mendapatkan akses switch dan memeriksa status konektivitas serta sesi BGP multi-zona secara manual.

Gateway ingress bidang data dan pengelolaan gagal melakukan rekonsiliasi

Versi: 1.14.3

Gejala: Subkomponen asm-dataplane-ingress atau asm-management-ingress gagal merekonsiliasi dengan error berikut:

message: 'Reconciliation error: E0111 - upgrade chart: cannot patch "management-ingress-gateway" with kind BackendService: BackendService.networking.gdc.goog "management-ingress-gateway" is invalid: spec.targetPorts: Invalid value: "array": TargetPorts list is immutable'

Nilai lain yang mungkin ada dalam string error, bukan BackendService, adalah ForwardingRuleInternal dan ForwardingRuleExternal. Demikian pula, nama resource mungkin dataplane-ingress-gateway, dataplane-ingress-gateway-global, atau management-ingress-gateway-global, bukan management-ingress-gateway.

Solusi: Identifikasi apakah resource ada di server API pengelolaan atau server API global. Hal ini dapat disimpulkan dari versi API jenis resource dalam string error. Misalnya, resource dengan akhiran networking.gdc.goog ada di server API pengelolaan, sedangkan resource dengan akhiran networking.global.gdc.goog ada di server API global.

Setelah mengidentifikasi server API, hapus resource menggunakan file kubeconfig yang sesuai. Contoh:

kubectl --kubeconfig API_SERVER_KUBECONFIG delete Backendservice dataplane-ingress-gateway -n istio-system

Halaman kebijakan jaringan project tidak mendukung kolom pemilih project di ProjectNetworkPolicy API

Versi: 1.14.3, 1.14.4

Gejala: Saat Anda membuat kebijakan jaringan project yang menyertakan kolom projectSelector dan melihatnya di konsol GDC, UI akan menampilkan semua project yang dipilih untuk kebijakan, bukan project di kolom projectSelector.

Solusi: Gunakan API untuk membuat dan membaca kebijakan jaringan project yang menyertakan kolom projectSelector.

Sistem operasi

Penyediaan server gagal

Versi: 1.14.3

Gejala: Selama penyediaan server, error 401 berikut mungkin ditampilkan pada resource kustom BaremetalHost yang sesuai saat mendownload image OS dari registry Harbor, dan server mengalami loop pelepasan penyediaan dan penyediaan ulang.

Untuk memeriksa error ini, jelaskan resource kustom BaremetalHost:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG describe baremetalhost SERVER_NAME -n gpc-system

Output-nya mungkin terlihat seperti contoh ini:

Normal  InspectionComplete     14m    metal3-baremetal-controller  Hardware inspection completed
Normal  ProvisioningStarted    5m39s  metal3-baremetal-controller  Image provisioning started for https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24
.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ==
Normal  ProvisioningError      5m28s  metal3-baremetal-controller  Image provisioning failed: Failed to prepare to deploy: Validation of image href https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk
4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ== failed, reason: Got HTTP code 401 instead of 200 in response to HEAD request.
Normal  DeprovisioningStarted  5m17s  metal3-baremetal-controller  Image deprovisioning started

Solusi:

1. Dapatkan nama dan namespace nodePoolClaim tempat server berada:

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get server SERVER_NAME -n gpc-system -ojson | jq '.spec.nodePoolClaimRef'
   

   Output-nya mungkin terlihat seperti contoh ini:

   {
   "name": "control-plane-extension-pool-o2-standard1-96-gdc-metal",
   "namespace": "gpu-org-lancer"
   }
   

2. Dapatkan nama image OS dari NodePoolClaim:

   kubectl get nodepoolclaim NODEPOOLCLAIM_NAME -n NODEPOOLCLAIM_NAMESPACE -o json | jq '.spec.machineSpec.osImageName'
   

3. Dapatkan URL image OS dari OSImageMetadata:

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get osimagemetadata OS_IMAGE_NAME -o json | jq '.commonMetadata.servingURL'
   

4. Perbarui resource kustom Server dengan URL image OS terbaru:

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG patch server SERVER_NAME -n gpc-system --type=json -p='[{"op": "replace", "path": "/spec/image/urlSpec/url", "value" : "'OS_IMAGE_URL'"}]'
   

OS NodeUpgrade mungkin macet di langkah NodeOSInPlaceUpgradePostProcessingCompleted

Versi: 1.14.3, 1.14.4

Gejala:

Selama upgrade node, NodeUpgradeTask macet di langkah NodeOSInPlaceUpgradePostProcessingCompleted dengan error Reconciler dengan pesan failed verifying delta after upgrade dan tidak dapat diselesaikan. Error ini menunjukkan bahwa proses verifikasi upgrade menemukan perbedaan paket yang tidak terduga di node. Secara khusus, paket ini mengidentifikasi paket yang masih dalam status "perlu diupgrade" atau muncul sebagai paket "hanya di versi baru" setelah upaya upgrade.

Pesan error mencantumkan paket tertentu yang gagal diverifikasi. Contoh cuplikan:

{"ts":1748758118826.9954,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"NodeUpgradeTask","controllerGroup":"upgrade.private.gdc.goog","controllerKind":"NodeUpgradeTask","NodeUpgradeTask":{"name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","namespace":"lancer-org1"},"namespace":"lancer-org1","name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","reconcileID":"26585774-7059-46b7-a0f7-0e627b2a2bb5","err":"failed verifying delta after upgrade: 2 errors occurred:\n\t* failed to make \"need-upgrade\" empty, found\n  - bind-export-libs\n  from: 9.11.36-16.el8_6.86ciq_lts.2\n  to: 9.11.36-16.el8_6.86ciq_lts.4\n...\n- strongswan-sqlite\n  from: 5.9.10-1.el8_6.ciqlts\n  to: 5.9.10-2.el8\n\t* failed to make \"only-in-new\" empty, found lsof=4.93.2-1.el8\nstrace=5.13-4.el8\n\n"}

Gejala ini mungkin disebabkan oleh dua masalah. Deteksi masalah mana yang menjadi penyebabnya terlebih dahulu:

1. Cause-A: Mesin tidak dapat dijangkau sehingga menyebabkan OSArtifactSnapShot menjadi tidak aktif.

   Periksa apakah node yang sedang diupgrade masih responsif atau tidak, dan apakah tugas OSArtifactSnapShot yang sesuai gagal.

   Jika OSArtifactSnapShot sudah tidak berlaku dan perangkat tidak dapat dijangkau selama lebih dari 20 menit, lanjutkan ke Mitigation-A. Jika tidak, lanjutkan memeriksa Cause-B.

2. Cause-B: Kegagalan upgrade RPM tanpa interaksi pengguna

   Dalam kasus yang jarang terjadi, upgrade RPM pada mesin dapat gagal tanpa pemberitahuan setelah upgrade sebagian. Harus ada dua ConfigMap yang berisi perbedaan paket sebelum dan setelah upgrade:

   in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
   in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
   

   Jika 'after-upgrade' berisi lebih sedikit paket daripada configmap 'before-upgrade', berarti upgrade dibatalkan secara diam-diam dan tidak semua paket diupgrade. Lanjutkan ke Mitigation-B.

Solusi:

Mitigation-A: perbaiki mesin yang tidak dapat dijangkau

Coba perbaiki mesin dengan memulai ulang. Jika mesin masih tidak dapat dijangkau setelah upaya reboot, hubungi tim SERV untuk mendapatkan bantuan lebih lanjut. Setelah komputer dapat dijangkau kembali, hapus OSArtifactSnapShot untuk memaksa rekonsiliasi. Setelah OSArtifactSnapShot disesuaikan, NodeUpgradeTask harus melanjutkan ke langkah berikutnya.

Mitigation-B: coba lagi NodeUpgradeTask

1. Lakukan SSH ke mesin yang sedang diupgrade, dan kumpulkan log berikut untuk pemecahan masalah di masa mendatang. File berikut harus dikumpulkan:

   • /var/log/dnf.log
   • /var/log/dnf.rpm.log
   • dnf history > dnf_history.log
   • rpm -qa --last > rpm_last.log

2. Hapus NodeUpgradeTask yang gagal. Tindakan ini akan memicu percobaan ulang NodeUpgradeTask pada node tertentu. NodeUpgradeTask baru harus menyelesaikan upgrade RPM dan melanjutkan ke langkah berikutnya.

OS NodeUpgrade mungkin macet di langkah pembuatan server paket

Versi: 1.14.3, 1.14.4

Gejala:

Jika NodeUpgrade CR dibuat dan dilanjutkan serta tetap berada di in-progress selama lebih dari 30 menit, CR tersebut mungkin gagal tanpa pemberitahuan pada tahap pembuatan server paket. Gejalanya adalah NodeUpgrade tetap dengan: .status.upgradeStatus=in-progress, tetapi tidak ada .status.tasks yang dimuat:

status:
  duration: 0s
  upgradeStatus: in-progress

Untuk mengonfirmasi lebih lanjut bahwa hal ini gagal saat pembuatan server paket, baca log pengontrol upgrade OS:

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Jika log pengontrol menampilkan failed to create package server dan failed to create package repo server DNS registration dengan alasan mendetail (salah satu dari berikut ini)

• spec.fqdnPrefix already used in an existing DNS registration
• name already used in an existing DNS.

Kemudian, hal ini menunjukkan bahwa beberapa resource server paket lain yang digunakan oleh NodeUpgrade lain masih aktif dan berkonflik dengan resource yang akan dibuat untuk NodeUpgrade yang saat ini mengalami masalah.

Solusi:

Untuk mengonfirmasi lebih lanjut, Anda dapat memeriksa resource server paket sebenarnya (dari API tertentu, seperti dnsregistration.network.private.gdc.goog di server API pengelolaan cluster yang mengelola CR NodeUpgrade) dan menemukan NodeUpgrade yang memiliki resource tersebut. Jika NodeUpgrade yang memiliki DNSRegistration telah selesai, tetapi resource DNSRegistration masih belum dihapus, Anda dapat menghapus objek DNSRegistration jika semua objek NodeUpgrade yang dirujuk telah selesai.

1. Mencantumkan semua CR DNSRegistration untuk server paket NodeUpgrade:

   kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | grep nu-bm
   

2. Kueri CR pemilik NodeUpgrade untuk satu DNSRegistration tertentu:

   kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | jq -r '.metadata.annotations."package-server-owners"'
   

Upgrade OS node dapat mengalami masalah dan berhenti di tahap mana pun dalam prosesnya

Versi: 1.14.4, 1.14.5, 1.14.6

Gejala:

NodeUpgradeTask CR masih di bawah in-progress selama lebih dari 2 jam, meskipun mungkin dapat melengkapi otomatis jika diberi waktu yang cukup.

CR NodeUpgradeTask sedang dalam proses selama lebih dari dua jam. Meskipun pada akhirnya dapat melengkapi otomatis, masalah yang mendasarinya adalah ketidakmampuan os-policy-reconciler untuk mengelola volume besar CR OSPolicy secara efisien. Masalah ini terjadi selama langkah NodeOSInPlaceUpgradeCompleted.

Untuk mengonfirmasi lebih lanjut kegagalan ini selama pembuatan server paket, lihat log pengontrol upgrade OS.

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Jika log pengontrol tidak memiliki entri OSPolicy dari NodeUpgradeTask, hal ini menunjukkan bahwa pengontrol kelebihan beban.

Solusi:

Jeda semua CR OSPolicy yang tidak penting selama proses upgrade.

"storage cp" file besar menyebabkan kube-api org-mgmt down

Versi: 1.14.3 dan yang lebih baru

Gejala: Selama operasi gdcloud storage cp atau operasi gdcloud system container-registry load-oci dari workstation OIC, ada sedikit kemungkinan bahwa akses ke org-infra akan hilang, diikuti dengan kube-api org-mgmt yang tidak berfungsi. Ini adalah masalah yang jarang terjadi dan pengumpulan data untuk tim engineering akan sangat membantu.

Solusi: Jika masalah ini terjadi, coba langkah-langkah berikut:

1. Untuk setiap node bidang kontrol (CP), jalankan uptime untuk melihat apakah node dimulai ulang dalam 24 jam terakhir.
2. Catat waktu mulai ulang.
3. Periksa error kernel pada setiap node CP yang terjadi tepat sebelum mulai ulang dengan menjalankan dmesg | grep -i 'kernel panic'.
4. Di setiap node CP, periksa apakah kartu NIC Mellanox sudah diinstal dengan melakukan: lspci | grep -i eth | grep -i mellanox. Jika tidak ada NIC Mellanox, berhenti membaca masalah umum ini.

5. Di setiap node CP, periksa setelan jaringan ini di data0:

   [root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
   rx-checksumming: off
   generic-receive-offload: on
   large-receive-offload: off
   rx-gro-hw: on  # <--- Check this value
   

   Jika rx-gro-hw (lihat di atas) disetel ke "off" di semua node, maka berhenti membaca masalah umum ini.

6. Kumpulkan beberapa informasi untuk Google guna membantu mendiagnosis masalah:

   k8s.org get po -n anthos-identity-service -l k8s-app=ais
   
   k8s.org get po -n management-kube-system
   
   k8s.org get po -n kube-system -l component=kube-apiserver
   
   k8s.org get nodes -l node-role.kubernetes.io/control-plane
   

7. Di setiap node CP, jalankan perintah berikut:

   dmesg | grep -i 'kernel panic'
   
   journalctl -u disable-rx-gro-hw.service
   
   systemctl status disable-rx-gro-hw
   
   modinfo mlx5_core | grep ^version:
   

8. Untuk mengatasi masalah setelan jaringan, rx-gro-hw harus diaktifkan off, dengan menjalankan perintah berikut di semua node CP:

   ethtool -K data0 rx off gro off lro off
   ethtool -K data1 rx off gro off lro off
   ethtool -K bond00 rx off gro off lro off
   

9. Periksa kembali setelan:

   [root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
   rx-checksumming: off
   generic-receive-offload: on
   large-receive-offload: off
   rx-gro-hw: off # <--- Check this, should be "off"
   

10. Coba lagi operasi asli, seperti gdcloud storage cp atau gdcloud system container-registry load-oci. Jika masih terjadi kegagalan, hubungi tim engineering.

Layanan Inti Infrastruktur Operations Suite (OIC)

Performa Jumphost yang buruk

Versi: Semua versi Google Distributed Cloud (GDC) dengan air gap dapat terpengaruh.

Gejala: Operasi browser atau sistem memerlukan waktu yang terlalu lama untuk menyelesaikan operasi.

Solusi:

Tingkatkan jumlah vCPU di Jumphost melalui pengelola Hyper-V di BM03 dan BM04:

1. Pilih VM Jumphost, lalu klik settings di panel tindakan.
2. Pilih Prosesor, lalu tingkatkan jumlah di Jumlah Prosesor Virtual menjadi 4 atau lebih, bergantung pada workload.
3. Ulangi untuk Jumphost yang tersisa.

Pengelola resource

Tidak dapat menghapus project di konsol GDC

Versi: 1.14.3, 1.14.4

Gejala: Konsol GDC menyediakan tombol hapus Hapus untuk project yang ada di halaman Detail project, tetapi tombol tersebut tidak berfungsi.

Solusi: Untuk menghapus project yang ada, Anda harus menggunakan gdcloud CLI. Untuk mengetahui informasi selengkapnya, lihat Menghapus project.

Playbook Ansible organisasi tidak ada

Versi: 1.14.3

Gejala: Saat membuat organisasi, tugas create-ansible-playbooks yang membuat playbook Ansible yang diperlukan gagal tanpa pemberitahuan. Playbook Ansible yang tidak ada menyebabkan masalah seperti virtual machine perimeter yang tidak ada dan masalah saat membuat organisasi global.

Solusi: Ikuti runbook OS-R0009 untuk membuat playbook Ansible organisasi yang tidak ada secara manual.

Organisasi global asimetris menampilkan konfigurasi zona yang tidak ada

Versi: 1.14.4

Gejala: Saat membuat organisasi global v1 dengan hanya sebagian konfigurasi organisasi zonal, semua zona tetap menampilkan status replika organisasi. Misalnya, jika Anda memiliki semesta GDC dengan tiga zona, tetapi hanya membuat konfigurasi organisasi per zona untuk dua zona, zona ketiga masih menampilkan status replika yang salah untuk organisasi per zona ketiga yang tidak ada.

Untuk mengonfirmasi status yang salah, cetak status organisasi global:

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get organization \
    ORG_NAME -n gpc-system -o yaml

Output YAML akan terlihat mirip dengan berikut ini:

...

- name: zone3
  replicaStatus:
    systemInfo:
      cidrInfo: {}
  rolloutStatus:
    conditions:
    - lastTransitionTime: "2025-03-12T02:09:21Z"
      message: ""
      observedGeneration: 1
      reason: Current
      status: "True"
      type: Synced
    - lastTransitionTime: "2025-03-12T02:09:22Z"
      message: rollout succeeded
      observedGeneration: 1
      reason: RolloutSucceeded
      status: "True"
      type: Replicated

...

Perhatikan bahwa hal ini hanya terjadi untuk organisasi v1, karena konfigurasi zonal asimetris tidak didukung untuk organisasi v2.

Solusi: Anda dapat mengabaikan status replika yang salah, karena organisasi zonal tidak ada kecuali jika Anda membuatnya secara khusus.

Cluster

Kumpulan node pekerja cluster infrastruktur tidak dihapus

Versi: 1.14.3, 1.14.4

Gejala: Saat menghapus node pool pekerja dari spesifikasi CR Organization, node pool tidak otomatis dihapus, yaitu, perintah kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} masih menampilkan node pool yang akan dihapus.

# Organization CR example
apiVersion: resourcemanager.private.gdc.goog/v1alpha1
kind: Organization
...
spec:
  resourceCapacities:
    workloadServers:
      o2-standard1-96-gdc-metal: 4 # worker node pool to remove
...

Solusi: Setelah menghapus kumpulan node pekerja dari spesifikasi CR Organization, hapus CR NodePoolClaim untuk kumpulan node ini secara manual dari cluster admin root dengan menjalankan perintah: sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

Tunggu hingga NodePoolClaim dan CR NodePool terkait dihapus sepenuhnya, yaitu perintah kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} tidak lagi menampilkan kumpulan node pekerja.

Penyimpanan

Bucket yang dibuat dengan perintah gdcloud config set zone gagal dihapus

Versi: 1.14.7 dan yang lebih baru

Gejala: Bucket yang dibuat dengan perintah gdcloud config set zone gagal dihapus, karena masalah izin, karena perintah mencoba beroperasi di zona yang salah.

Solusi: Gunakan konsol untuk menyetel zona tertentu untuk bucket, atau ganti flag --zone dengan --location dalam perintah gcloud.

Pengaktifan pemberitahuan SLO OBJ

Versi: 1.14.3, 1.14.4

Gejala: Pemberitahuan SLO untuk OBJ diaktifkan karena error ErrFailedStreamingDecryptRequest di OBJ Proxy: obj-list-object-ops-availability-slo, obj-rw-object-ops-error-rate-slo.

Solusi: Menyenyapkan pemberitahuan. Error tersebut salah diidentifikasi sebagai error sistem padahal disebabkan oleh pengguna yang menghentikan koneksi yang tidak dihitung terhadap SLO.

ETag Kosong UploadPart S3

Versi: 1.14.3

Gejala: Setelah mengirim permintaan UploadPart, Anda mendapatkan kode status 200 Success dalam pesan respons, tetapi kolom ETag kosong. Error ini terjadi karena InternalServerError terjadi akibat gangguan jaringan dan kode status tidak diperbarui menjadi 500 InternalServerError.

Solusi: Coba lagi permintaan seolah-olah sebelumnya gagal.

Pod gagal di-mount karena error mkfs.ext4 Trident

Versi: 1.14.3

Gejala: Setelah mencoba memasang pod, Anda mengamati bahwa semua pod yang bertransisi ke atau dari node tertentu gagal. Pesan error rpc: DeadlineExceeded desc = context deadline exceeded muncul, yang menunjukkan bahwa node mengalami masalah. Saat pesan ini muncul, Anda tidak dapat melakukan operasi Trident tambahan pada node yang dimaksud. Volume yang menyajikan data tidak terpengaruh, tetapi volume yang dipindahkan ke dan dari node mungkin mengalami gangguan.

Solusi:

1. Periksa log Trident di node yang coba dipasang oleh pod dan verifikasi bahwa antrean bertambah. Log mungkin terlihat seperti berikut:

   2025-01-24T00:27:22.783599667Z time="2025-01-24T00:27:22Z" level=debug msg="Attempting to acquire shared lock (NodeUnstageVolume-pvc-0f04a9c5-00fc-4c3c-9fc1-6730598f7caa); 421 position in the queue." lock=csi_node_server logLayer=csi_frontend requestID=94c8ad12-6479-4e1c-8791-118b565d6c6b requestSource=CSI workflow="node_server=unstage"
   

2. Login ke node dan lihat output dmesg. Log mungkin terlihat seperti berikut:

   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:144.
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:160.
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   

3. Setelah mengonfirmasi bahwa Anda mengalami error mkfs.ext4 Trident, reboot node.

Trident gagal membuat volume karena error yang sudah ada

Versi: 1.14.3

Gejala:

PVC tidak disediakan dan menampilkan peristiwa seperti berikut:

failed to create cloned volume {pvc-bab6bc52-fd37-4ead-a57b-e833e14c172a} on backend iscsi-san: volume trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a already exists

Jika peristiwa ini terjadi, PVC tidak akan disediakan hingga Anda melakukan solusi.

Solusi:

Ikuti langkah-langkah berikut untuk menyelesaikan masalah ini:

1. Catat nama volume internal dari peristiwa. Misalnya, contoh peristiwa yang ditampilkan di bagian Gejala menunjukkan nama volume internal trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a.
2. Ikuti runbook FILE-R0105 untuk mengakses ONTAP.

3. Hapus volume:

   volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a
   

file_block_iscsi_sessions_unhealthy alert melaporkan positif palsu

Versi: 1.14.3

Gejala: Di beberapa lingkungan, pemberitahuan file_block_iscsi_sessions_unhealthy akan muncul yang menunjukkan bahwa satu atau beberapa node mengalami kegagalan iSCSI. Pengontrol file-observability menggunakan pengumpul metrik kustom untuk melacak kondisi sesi iSCSI di setiap node Kubernetes, tetapi dalam beberapa kasus, pengumpul metrik tidak dapat mengurai output perintah iscsiadm dan melaporkan nol sesi iSCSI yang berjalan meskipun iSCSI memiliki sesi yang sehat.

Solusi:

Ikuti langkah-langkah berikut untuk memverifikasi bahwa iSCSI tidak mengalami masalah dan menonaktifkan pemberitahuan jika pemberitahuan tersebut sebenarnya positif palsu:

1. Dari halaman explore di Grafana, jalankan kueri fb_sessions_running_count{job="file-observability-backend-target.file-system"}. Kueri menampilkan metrik untuk setiap node dalam cluster. Jika ada node yang melaporkan metrik fb_sessions_running_count sebesar 0, catat nama node tersebut.

2. Untuk setiap node dengan metrik fb_sessions_running_count yang menampilkan 0, jalankan perintah berikut:

   1. Buat koneksi SSH dengan node yang terpengaruh.

   2. Jalankan perintah iscsiadm -m session. Anda akan melihat beberapa baris yang ditampilkan. Setiap baris adalah sesi iSCSI yang sedang berjalan. Jika tidak ada yang ditampilkan dari perintah atau ada error dalam output, eskalasikan masalah ini ke tim engineering pemblokiran file.

   3. Jika perintah sebelumnya berhasil menampilkan sesi iSCSI, berarti Anda telah mengonfirmasi bahwa pemberitahuan untuk node ini adalah positif palsu.

3. Jika Anda mengonfirmasi bahwa semua node yang terpengaruh memiliki sesi iSCSI yang sehat dan menyebabkan pemberitahuan dipicu secara keliru, buat peredaman di AlertManager untuk meredam pemberitahuan file_block_iscsi_sessions_unhealthy.

Notifikasi file_block_storage_disk_failure diaktifkan untuk disk cadangan

Versi: 1.14.3

Gejala: Di beberapa lingkungan, pemberitahuan file_block_storage_disk_failure akan muncul yang menunjukkan bahwa satu atau beberapa disk di ONTAP tidak dalam kondisi baik. Pengontrol file-observability menggunakan pengumpul metrik kustom untuk melacak kondisi setiap disk di ONTAP, tetapi di rilis GDC sebelumnya, pengumpul tidak menganggap disk cadangan sebagai responsif dan akan memicu pemberitahuan untuk disk cadangan.

Solusi:

Ikuti langkah-langkah berikut untuk memverifikasi bahwa disk adalah suku cadang dan menonaktifkan pemberitahuan untuk disk:

1. Dari halaman explore di Grafana, jalankan kueri disks_labels_healthy{job="file-observability-backend-target.file-system"}. Kueri akan menampilkan metrik untuk setiap disk di ONTAP. Jika ada disk yang melaporkan metrik 0 (tidak sehat), catat nama disk tersebut.

2. Untuk setiap disk dengan metrik disks_labels_healthy yang menampilkan 0, jalankan perintah berikut:

   1. SSH ke cluster ONTAP dan jalankan perintah disk show -disk <disk-name> -fields state menggunakan nama disk yang dikumpulkan dari kueri metrik.

   2. Pastikan output perintah menunjukkan bahwa status disk adalah present atau spare. Jika disk berada dalam status lain selain present atau spare, eskalasikan masalah ini ke tim engineering pemblokiran file.

   3. Jika disk yang dimaksud melaporkan present atau spare, kami dapat mengonfirmasi bahwa pemberitahuan tidak akan muncul untuk disk ini. Buat periode senyap di AlertManager untuk menyenyapkan notifikasi file_block_storage_disk_failure dengan label disk_name yang ditetapkan ke nama disk.

3. Setelah jeda dibuat untuk semua disk cadangan, buka Grafana untuk memverifikasi bahwa pemberitahuan telah berhenti dikirim.

Peringatan file_block_storage_node_peer_connection_unhealthy diaktifkan setelah koneksi dipulihkan

Versi: 1.14.3

Gejala: Di beberapa lingkungan, pemberitahuan file_block_storage_node_peer_connection_unhealthy akan muncul yang menunjukkan bahwa satu atau beberapa koneksi antara node ONTAP gagal. Pengontrol file-observability menggunakan pengumpul metrik kustom untuk melacak kondisi koneksi ini. Ada masalah umum yang menyebabkan pemberitahuan ini terus muncul meskipun setelah koneksi yang gagal dipulihkan.

Solusi:

Ikuti langkah-langkah berikut untuk memverifikasi bahwa koneksi antar-node responsif dan menonaktifkan pemberitahuan untuk node:

1. Dari halaman explore di Grafana, jalankan kueri storage_node_peer_connections{job="file-observability-backend-target.file-system"}. Kueri ini menampilkan metrik untuk setiap koneksi antara node penyimpanan dalam cluster. Jika ada koneksi yang melaporkan metrik storage_node_peer_connections sebesar 0, catat label source_node, destination_ip, dan storage_cluster_name dari metrik tersebut.

2. Untuk setiap metrik storage_node_peer_connections yang menampilkan 0, jalankan perintah berikut:

   1. Buat koneksi SSH dengan cluster penyimpanan ONTAP dari label storage_cluster_name.

   2. Jalankan perintah berikut di cluster ONTAP menggunakan nilai dari label source_node dan destination_ip:

   ping -node <node-name> -destination <destination-ip> -verbose -show-detail
   

   Jika perintah ping gagal, eskalasikan masalah ke tim engineering pemblokiran file. Jika perintah ping berhasil, hal ini mengonfirmasi bahwa koneksi node dalam kondisi baik dan pemberitahuan dipicu secara keliru.

   1. Buat peredaman di AlertManager untuk meredam pemberitahuan file_block_storage_node_peer_connection_unhealthy dengan label source_node dan destination_ip yang ditetapkan ke node sumber dan IP tujuan dari metrik.

3. Setelah pembungkaman dibuat untuk semua node yang sehat, buka Grafana untuk memverifikasi bahwa pemberitahuan telah berhenti dikirim.

Peringatan file_block_nodes_not_reachable akan muncul setelah koneksi dipulihkan

Versi: 1.14.3

Gejala: Di beberapa lingkungan, pemberitahuan file_block_nodes_not_reachable diaktifkan yang menunjukkan bahwa satu atau beberapa koneksi dari layanan IPsec di node Kubernetes ke ONTAP gagal. Pengontrol file-observability menggunakan pengumpul metrik kustom untuk melacak kondisi koneksi ini. Ada masalah umum yang menyebabkan pemberitahuan ini terus muncul meskipun setelah koneksi yang gagal dipulihkan.

Solusi:

Ikuti langkah-langkah berikut untuk memverifikasi bahwa koneksi pada node responsif dan menonaktifkan pemberitahuan untuk node:

1. Dari halaman explore di Grafana, jalankan kueri fb_all_nodes_reachable{job="file-observability-backend-target.file-system"}. Kueri menampilkan metrik untuk setiap node dalam cluster. Jika ada node yang melaporkan metrik fb_all_nodes_reachable sebesar 0, catat nama node tersebut.

2. Untuk setiap node dengan metrik fb_all_nodes_reachable yang menampilkan 0, jalankan perintah berikut:

   1. Buat koneksi SSH dengan node yang terpengaruh.

   2. Jalankan perintah berikut:

      journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh
      

      Perintah akan mencoba melakukan ping ke ontap menggunakan semua koneksi IPsec. Jika ada ping yang gagal dalam perintah, eskalasikan masalah ke tim engineering pemblokiran file. Jika perintah ping berhasil, hal itu mengonfirmasi bahwa koneksi node dalam kondisi baik dan pemberitahuan dipicu secara keliru.

   3. Jika semua ping dalam perintah berhasil, kita telah mengonfirmasi bahwa koneksi di node dalam kondisi baik dan pemberitahuan dipicu secara keliru. Buat peredaman di AlertManager untuk meredam notifikasi file_block_nodes_not_reachable dengan label node_name yang ditetapkan ke nama node.

3. Setelah pembungkaman dibuat untuk semua node yang sehat, buka Grafana untuk memverifikasi bahwa pemberitahuan telah berhenti dikirim.

Peringatan file_block_storage_high_node_total_latency muncul selama beban kerja berat

Versi: 1.14.3

Gejala: Pemberitahuan file_block_storage_high_node_total_latency mungkin dipicu di lingkungan tertentu karena beban kerja berat pada node penyimpanan. Pemberitahuan ini akan tetap ada hingga beban kerja ini diproses sepenuhnya. Meskipun performa baca dan tulis pada volume cepat, node penyimpanan masih dapat melaporkan latensi tinggi untuk operasi blok tertentu.

Solusi:

Untuk memverifikasi latensi volume yang baik dan menonaktifkan pemberitahuan latensi node penyimpanan, ikuti langkah-langkah berikut:

1. Periksa Pemberitahuan Latensi Volume:

   1. Di Grafana, pastikan bahwa pemberitahuan file_block_storage_high_volume_write_latency dan file_block_storage_high_volume_read_latency tidak dipicu dan melaporkan waktu latensi yang optimal untuk volume.

2. Lakukan eskalasi jika Latensi Volume Tinggi:

   1. Jika pemberitahuan penulisan volume atau pembacaan volume diaktifkan, hal ini menunjukkan latensi tinggi di seluruh sistem penyimpanan. Eskalasikan masalah ini ke tim engineering pemblokiran file.

3. Nonaktifkan Pemberitahuan Latensi Node (jika volume dalam kondisi baik):

   1. Jika notifikasi penulisan volume dan pembacaan volume dalam kondisi baik, notifikasi latensi node kemungkinan adalah positif palsu.

   2. Buat pembungkaman di AlertManager untuk pemberitahuan file_block_storage_high_node_total_latency.

   3. Setelah membuat peredaman, buka Grafana untuk mengonfirmasi bahwa pemberitahuan telah berhenti dipicu.

Upgrade node yang diblokir

Versi: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Gejala: Pemblokiran ini terjadi saat LUN (Logical Unit Number) menjadi hanya baca, sering kali karena masalah pada snapshot. Jika hal ini terjadi, node akan dibatasi untuk memindahkan pod yang terpengaruh ke node lain. Karena proses upgrade node memiliki pra-pemeriksaan untuk memastikan bahwa node tidak dikarantina, status ini mencegah upgrade dilanjutkan.

Solusi: Nonaktifkan subkomponen file-read-only-lun-cleanup secara manual sebelum memulai proses upgrade:

1. Identifikasi setiap organisasi yang terpengaruh.

2. Terapkan SubcomponentOverride untuk setiap organisasi di lingkungan.

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: file-read-only-lun-cleanup
     namespace: ORG_NAMESPACE
   spec:
     subComponentRef: "file-read-only-lun-cleanup"
     disable: true
   

3. Pastikan tidak ada node di organisasi yang terpengaruh yang dikarantina:

   1. Mencantumkan node di organisasi:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes
      

      Outputnya mirip dengan hal berikut ini:

      NAME                STATUS                     ROLES           AGE   VERSION
      admin-node0-zone1   Ready,SchedulingDisabled   control-plane   14h   v1.30.8-gke.200
      admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      

      Catat nama node yang memiliki status SchedulingDisabled. Untuk contoh output ini, node yang dikarantina adalah admin-node0-zone1.

   2. Batalkan pembatasan node yang menampilkan status SchedulingDisabled dari langkah sebelumnya:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
      

   3. Pastikan semua node sudah siap:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes
      

      Outputnya mirip dengan hal berikut ini:

      NAME                STATUS                     ROLES           AGE   VERSION
      admin-node0-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      

Pemberitahuan file_block_zombie_luns_present diaktifkan setelah error multipath diselesaikan

Versi: 1.14.3 dan yang lebih baru

Gejala: Pemberitahuan file_block_zombie_luns_present mungkin dipicu di lingkungan tertentu karena pengontrol file-observability gagal mengurai output perintah multipath -ll. Situasi ini menyebabkan pemberitahuan LUN zombie terus diaktifkan meskipun layanan multipath dalam kondisi baik di semua node.

Solusi:

Untuk memverifikasi layanan multipath yang berfungsi dengan baik di node yang dimaksud, ikuti langkah-langkah berikut:

1. Dari halaman explore di Grafana, jalankan kueri zombie_lun_exists{job="file-observability-backend-target.file-system"}. Kueri menampilkan metrik untuk setiap node dalam cluster. Jika ada node yang melaporkan metrik zombie_lun_exists sebesar 1, catat nama node tersebut.

2. Untuk setiap node dengan metrik zombie_lun_exists yang menampilkan 1, jalankan perintah berikut:

   1. Buat koneksi SSH dengan node yang terpengaruh.

   2. Jalankan perintah berikut:

      multipath -ll
      

      Perintah ini menampilkan informasi tentang semua perangkat blok yang dikelola oleh layanan multipath. Pastikan tidak ada perangkat blok yang berisi string failed undef unknown atau string failed faulty running dalam statusnya.

   3. Jika ada perangkat yang memiliki status failed faulty running, ikuti buku panduan FILE-R0020 untuk mengatasi LUN zombie.

   4. Jika ada perangkat yang memiliki status failed undef unknown, ikuti buku panduan FILE-R0021 untuk mengatasi LUN super zombie.

3. Nonaktifkan suara notifikasi LUN zombie, jika node dalam kondisi baik:

   1. Jika tidak ada perangkat blokir yang tidak valid ditemukan di salah satu node, pemberitahuan LUN zombie adalah positif palsu.

   2. Buat pembungkaman di AlertManager untuk pemberitahuan file_block_zombie_luns_present.

   3. Setelah membuat peredaman, buka ServiceNow untuk mengonfirmasi bahwa pemberitahuan telah berhenti dikirim.

Tidak dapat menghapus bucket kosong dari Konsol

Versi: 1.14.4 dan yang lebih baru

Gejala: Di konsol GDC, Anda tidak dapat menghapus bucket kosong. Bucket mungkin memiliki penanda penghapusan dan berpotensi memiliki versi objek lain jika pembuatan versi objek diaktifkan dengan kebijakan retensi. Anda mungkin melihat error seperti ini:

can't delete bucket containing empty objects: Delete the bucket inside to delete
the object

Solusi: Gunakan perintah gdcloud storage rm -a untuk menghapus objek, termasuk penanda penghapusan, agar bucket dapat dihapus.

Artifact Registry Sistem

Tugas replikasi Harbor macet

Versi: 1.14.3

Gejala: Tugas replikasi artefak Harbor macet. Masalah ini memblokir distribusi artefak ke organisasi dan menghentikan pembuatan organisasi.

Solusi: Untuk mengurangi masalah ini, ikuti langkah-langkah dalam runbook SAR-R1010.

Status error sementara tidak dihapus saat merekonsiliasi resource kustom akun robot Harbor

Versi: 1.14.3

Gejala: Pemberitahuan CustomResourceErrorStatusAlert yang diberi label kind=HarborRobotAccount dan code=SAR2002 dipicu secara keliru. Misalnya, pemberitahuan palsu memiliki kolom message yang ditetapkan ke "Error getting robot: failed to list robots: 503 Service Unavailable".

Solusi: Minta Operator Infrastruktur (IO) untuk memverifikasi apakah pemberitahuan tersebut adalah masalah yang sebenarnya atau alarm palsu, dan nonaktifkan pemberitahuan jika itu adalah alarm palsu, sesuai dengan petunjuk berikut.

Saat notifikasi dipicu, ikuti runbook SAR-E2002 untuk mengidentifikasi dan mengatasi penyebab utama notifikasi.

Karena masalah yang diketahui ini, meskipun runbook berhasil mengatasi penyebab yang mendasarinya, pemberitahuan dapat terus dipicu secara keliru. Terus periksa status error objek resource kustom (CR) HarborRobotAccount (HRD) target yang diberi tahu:

1. Tetapkan variabel lingkungan yang diperlukan:

   export KUBECONFIG=KUBECONFIG
   export HRD_NAME=HRD_NAME
   export HRD_NAMESPACE=HRD_NAMESPACE
   

   Ganti kode berikut:

   • KUBECONFIG: jalur ke file kubeconfig.
   • HRD_NAME: nama CR HarborRobotAccount target.
   • HRD_NAMESPACE: namespace yang berisi CR HarborRobotAccount target.

2. Periksa status error CR target HarborRobotAccount:

   kubectl get harborrobotaccount ${HRD_NAME?} -n ${HRD_NAMESPACE?} -ojsonpath='{.status.errorStatus} {"\n"}'
   

Jika nilai lastUpdateTime menunjukkan bahwa kolom errorStatus terakhir diperbarui lebih dari 30 menit yang lalu, pemberitahuan tersebut adalah alarm palsu. Untuk mengurangi alarm palsu, nonaktifkan notifikasi dalam instance GDC dengan air gap dengan mengikuti runbook MON-R2009.

Peringatan palsu untuk notifikasi SAR-R0003

Versi: 1.14.3 dan yang lebih baru

Gejala: Pemberitahuan dengan kode SAR-R0003, OC SAR, dan tingkat keparahan critical dipicu secara keliru.

Solusi: Ikuti buku pedoman MON-R2009 untuk menyenyapkan pemberitahuan.

Sistem Penjualan Tiket

Server MID ServiceNow gagal dimulai dengan benar

Versi: 1.14.3

Tetap: 1.14.4

Gejala: MID Server ServiceNow, yang terintegrasi dengan Splunk, gagal mendaftar ke ServiceNow saat startup karena ketidakcocokan versi.

Solusi:

1. Jeda subkomponen ts-mid-server.

KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true

1. Mengganti string versi MID Server.

KUBECONFIG=GDCHSERVICES_ADMIN_KUBECONFIG kubectl set env statefulset/midserver-set -n support MID_CONFIG_mid__pinned__version=washingtondc-12-20-2023__patch5-06-21_06-26-2024_1335

Upgrade

Anotasi cluster layanan bersama tidak diperbarui setelah upgrade cluster berhasil

Versi: 1.14.4

Gejala: CR perimeter dan cluster layanan bersama untuk clusters.baremetal.cluster.gke.io mencerminkan versi GKE yang benar setelah upgrade. CR clusters.cluster.gdc.goog masih menampilkan versi GKE sebelumnya.

Solusi: Perbarui anotasi upgrade.gdc.goog/version di clusters.baremetal.cluster.gke.io ke nama UserClusterMetadata baru yang sesuai dengan versi GKE yang diupgrade.

Upgrade node admin org macet

Versi: 1.14.6

Tetap: 1.14.7

Gejala: Proses upgrade node untuk bidang kontrol admin organisasi gdchservices macet. Upgrade node gagal karena tidak dapat membuat koneksi SSH ke node, sehingga menghasilkan error Connection timed out.

Upgrade add-on macet

Versi: 1.14.6

Tetap: 1.14.7

Gejala: Upgrade add-on untuk cluster admin root macet selama upgrade dari versi 1.14.x sebelumnya ke 1.14.6. Pesan status mungkin menunjukkan bahwa upgrade telah melampaui batas waktu yang diperkirakan:

message: 'UPG1401: addon upgrade expected to finish within 2h0m0s but hasn''t
      after 8h8m24.00395866s, last message was: Addon upgrade for root-admin cluster
      in progress'

Solusi: Perbarui secara manual spec.addOnSetTemplateRef resource root-admin addonset agar mengarah ke template yang benar untuk versi baru.

Laporan dukungan gagal

Versi: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Tetap: 1.14.7

Gejala: Perintah gdcloud resource-support get-report gagal saat dijalankan untuk cluster pengguna karena masalah izin.

Boot VM mungkin macet setelah upgrade node OS selesai

Versi: 1.14.6

Gejala: Selama upgrade 1.14.3 ke 1.14.6, virtual machine di cluster perimeter atau layanan bersama gagal di-boot dan tidak dapat dijangkau setelah upgrade OS.

Misalnya, perintah berikut dapat mengonfirmasi masalah:

kubectl --kubeconfig CP_KUBECONFIG logs -n VM_NAMESPACE VIRT_LAUNCHER_POD_NAME -c guest-console-log

Output log konsol VM menampilkan pesan kernel panic yang mirip dengan berikut ini:

[    2.005806] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.008100] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 #1
[    2.011153] Hardware name: KubeVirt None/RHEL, BIOS 1.14.0-2 04/01/2014
[    2.013401] Call Trace:
[    2.015365]  dump_stack+0x41/0x60
[    2.016641]  panic+0xe7/0x2ac
[    2.017864]  mount_block_root+0x2be/0x2e6
[    2.019176]  ? do_early_param+0x95/0x95
[    2.020287]  prepare_namespace+0x135/0x16b
[    2.021476]  kernel_init_freeable+0x210/0x23a
[    2.022724]  ? rest_init+0xaa/0xaa
[    2.023721]  kernel_init+0xa/0x110
[    2.024698]  ret_from_fork+0x1f/0x40
[    2.025913] Kernel Offset: 0x33c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.028706] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

Solusi: Selesaikan langkah-langkah berikut untuk mengatasi masalah ini:

1. Tetapkan variabel lingkungan berikut:

   export MP_KUBECONFIG=MANAGEMENT_API_KUBECONFIG
   export CP_KUBECONFIG=ORG_INFRA_KUBECONFIG
   export VM_NAMESPACE=VM_NAMESPACE
   export VM_NAME=FAILED_VM_NAME
   

2. Hentikan VM yang gagal:

   kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE \
       $VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'
   

3. Buka editor untuk melepaskan boot disk dari VM yang gagal:

   kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME
   

4. Ganti boot disk dengan nama placeholder dalam spesifikasi VM:

   # Several lines of code are omitted here.
   spec:
     disks:
     - boot: true
       virtualMachineDiskRef:
         # This is a random placeholder name you put here. Doesn't need to exist
         name: VM_DISK_PLACEHOLDER_NAME
   

5. Buat secret skrip startup:

   cat <<'EOF' > script
   #!/bin/bash
   username="newuser"
   password="Lime+blaze8legend"
   sudo useradd -m -s /bin/bash "$username"
   echo "$username:$password" | sudo chpasswd
   sudo usermod -aG sudo "$username"
   EOF
   
   kubectl --kubeconfig=$MP_KUBECONFIG create secret generic configure-password -n $VM_NAMESPACE --from-file=script
   

6. Buat VM pembantu:

   1. Dapatkan image VM untuk boot disk VM. Image tidak boleh memiliki keluarga OS yang sama dengan boot disk node VM yang bermasalah, jadi gunakan grep untuk menemukan image Ubuntu:

      # find the latest ubuntu-20.04 OS version
      UBUNTU_OS_VERSION=$(kubectl --kubeconfig $MP_KUBECONFIG get vmimage -A --sort-by=.metadata.creationTimestamp | grep ubuntu-20.04 | tail -n 1 | awk '{print $2}')
      

   2. Buat boot disk VM dan VM. Buat boot disk baru dan VM baru dengan skrip startup dan disk sekunder yang terpasang untuk akses konsol:

      kubectl --kubeconfig $MP_KUBECONFIG apply -n $VM_NAMESPACE -f - <<EOF
      apiVersion: virtualmachine.gdc.goog/v1
      kind: VirtualMachineDisk
      metadata:
        name: HELPER_VM_BOOT_DISK_NAME
      spec:
        source:
          image:
            name: UBUNTU_OS_VERSION
            namespace: vm-system
        size: 20Gi
      ---
      apiVersion: virtualmachine.gdc.goog/v1
      kind: VirtualMachine
      metadata:
        name: HELPER_VM_NAME
      spec:
        compute:
          virtualMachineType: n3-standard-2-gdc
        disks:
        - virtualMachineDiskRef:
            name: HELPER_VM_NAME-disk
          boot: true
          autoDelete: true
        - virtualMachineDiskRef:
            name: PROBLEM_VM_BOOT_DISK
          autoDelete: false
        startupScripts:
        - scriptSecretRef:
            name: configure-password
          name: configure-password
      EOF
      

   3. Pastikan VM helper sedang berjalan:

      kubectl --kubeconfig $MP_KUBECONFIG get gvm -n ${VM_NAMESPACE} HELPER_VM_NAME
      

7. Konsol ke VM helper dan buat ulang initramfs:

   1. Konsol ke VM helper:

      kubectl virt console HELPER_VM_NAME  -n ${VM_NAMESPACE} --kubeconfig=$CP_KUBECONFIG
      

   2. Gunakan kredensial berikut:

      username="newuser"

      password="Lime+blaze8legend"

   3. Pasang partisi disk yang terpasang:

      sudo mkdir /mnt/kernelpanic/
      sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
      sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
      sudo mount /dev/sdb2 /mnt/kernelpanic/boot/
      sudo mount /dev/sdb1 /mnt/kernelpanic/boot/efi/
      sudo mount /dev/rocky/rl-home /mnt/kernelpanic/home/
      sudo mount /dev/rocky/rl-var /mnt/kernelpanic/var/
      sudo mount /dev/rocky/rl-var_tmp /mnt/kernelpanic/var/tmp/
      sudo mount /dev/rocky/rl-var_log /mnt/kernelpanic/var/log/
      sudo mount /dev/rocky/rl-var_log_audit /mnt/kernelpanic/var/log/audit/
      sudo mount /dev/rocky/rl-tmp /mnt/kernelpanic/tmp/
      
      sudo mount -t sysfs sysfs /mnt/kernelpanic/sys/
      sudo mount -t proc procfs /mnt/kernelpanic/proc/
      sudo mount -t devtmpfs devtmpfs /mnt/kernelpanic/dev/
      sudo mount -t devpts devpts /mnt/kernelpanic/dev/pts/
      sudo mount -o bind /dev/pts/ /mnt/kernelpanic/dev/pts/
      

   4. Buat koneksi chroot ke direktori pemasangan, dan buat ulang initramfs:

      sudo chroot /mnt/kernelpanic/
      dracut --regenerate-all --force
      

   5. Pastikan initramfs baru untuk versi kernel baru 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 dibuat:

      ls /boot/initramfs-* -l
      

      Outputnya terlihat mirip dengan yang berikut ini:

      -rw-------. 1 root root 184937778 Feb  5  2025 /boot/initramfs-0-rescue-e4d67258cb64499f98609307ac4a93e8.img
      -rw-------. 1 root root 119867729 Aug  7 17:35 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.6.1.x86_64.img
      -rw-------. 1 root root  35321114 Aug  7 17:36 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.img
      

8. Hentikan VM helper:

   kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE HELPER_VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'
   

9. Lepaskan disk dari VM helper:

   1. Buka spesifikasi VM helper di editor:

      kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE HELPER_VM_NAME
      

   2. Hapus kode berikut dari file YAML:

      - virtualMachineDiskRef:
          name: PROBLEM_VM_BOOT_DISK
        autoDelete: false
      

10. Pasang kembali boot disk ke VM yang gagal:

    1. Buka spesifikasi VM yang gagal di editor:

       kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME
       

    2. Perbarui spesifikasi seperti berikut:

       # Several lines of code are omitted here.
       spec:
         disks:
         - boot: true
           virtualMachineDiskRef:
             name: PROBLEM_VM_BOOT_DISK
       

11. Mulai VM yang gagal:

    kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE $VM_NAME --type='merge' -p='{"spec": {"runningState": "Running"}}'
    

12. Pastikan upgrade telah diperbaiki:

    1. Periksa apakah resource kustom Node untuk VM ini menampilkan Ready dan menggunakan versi kernel yang lebih baru 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64:

       kubectl --kubeconfig=$CP_KUBECONFIG get node NODE_NAME -owide
       

       Outputnya mirip dengan hal berikut ini:

       NAME          STATUS   ROLES           AGE    VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION                               CONTAINER-RUNTIME
       vm-45b03137   Ready    worker          139d   v1.30.12-gke.300   10.204.0.7    <none>        Rocky Linux 8.6 (Green Obsidian)   4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64   containerd://1.6.38-gke.0
       

    2. Periksa versi kernel setelah membuat koneksi SSH ke VM:

       uname -a
       

       Output harus menampilkan versi kernel baru 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.

Ingester tetap tidak responsif dan tidak otomatis dilupakan setelah upgrade

Versi: 1.14.x

Gejala: Subkomponen log-infra tidak dalam kondisi baik setelah upgrade. Untuk memeriksa, jalankan: none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra Untuk memeriksa kondisi subkomponen, Anda harus menggunakan kubeconfig cluster induk untuk KUBECONFIG dan namespace cluster saat ini untuk CLUSTER_NAMESPACE. Perintah ini akan menampilkan STATUS subkomponen. Jika STATUS bukan ReconciliationCompleted, subkomponen tersebut tidak responsif di cluster tersebut.

Beberapa pod Loki di cluster tidak sehat. Untuk mencantumkan semua pod Loki, jalankan: none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' Perintah ini menampilkan semua pod Loki, termasuk kolom STATUS dan READY-nya. Pod dianggap tidak sehat jika STATUS-nya bukan Running atau jika beberapa containernya tidak siap. Kolom READY, yang diformat sebagai a/b, menunjukkan jumlah penampung yang siap a dari total b. Pod dalam kondisi baik jika a dan b sama.

Periksa log untuk mengetahui pod Loki yang tidak sehat: none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

Contoh log output dari pod yang tidak sehat menyerupai berikut ini:

level=warn ts=2024-12-21T05:01:42.331048596Z caller=ingester.go:385 component=ingester msg="autoforget have seen 2 unhealthy ingesters out of 3, network may be partitioned, skip forgeting ingesters this round"
level=warn ts=2024-12-21T05:01:45.928939929Z caller=lifecycler.go:291 component=ingester msg="found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring." ring=ingester err="instance 10.99.196.153:9095 past heartbeat timeout"

Solusi: Untuk menghapus pengumpul data yang tidak responsif dari ring Loki, lihat runbook AL-R0031.

Vertex AI

Permintaan terjemahan dapat menghasilkan kode error RESOURCE_EXHAUSTED

Versi: 1.14.3

Gejala: Setelah mengirim permintaan terjemahan, Anda mendapatkan kode error RESOURCE_EXHAUSTED dalam pesan respons. Error ini terjadi saat Anda melebihi batas frekuensi sistem. Resource telah habis, seperti kuota per pengguna, kueri maksimum per detik, atau seluruh sistem file kehabisan ruang.

Solusi: Minta Operator Infrastruktur (IO) Anda untuk memulai ulang shard backend layanan terjemahan. Kemudian, kirim permintaan terjemahan lagi dengan penundaan yang lebih lama antar-permintaan atau dengan mengirim permintaan yang lebih pendek.

batchTranslateDocument menampilkan error 503

Versi: 1.14.3

Gejala: Setelah mengirim permintaan batchTranslateDocument, Anda mendapatkan kode error 503 "Batch Document translation is not implemented" dalam pesan respons. Error ini terjadi karena metode BatchTranslateDocument memerlukan layanan Aspose, yang hanya di-deploy saat parameter yang dapat dioperasikan enableRAG ditetapkan ke true di cluster.

Solusi: Minta Operator Infrastruktur (IO) Anda untuk menyetel parameter enableRAG yang dapat dioperasikan ke true di cluster admin org dengan mengikuti langkah-langkah berikut:

1. Buat resource kustom SubcomponentOverride dalam file YAML bernama vai-translation.yaml dengan parameter yang dapat dioperasikan enableRAG disetel ke true:

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: "vai-translation"
     namespace: SHARED_SERVICE_CLUSTER_NAMESPACE
   spec:
     subComponentRef: "vai-translation"
     backend:
       operableParameters:
         enableRAG: true
   

   Ganti SHARED_SERVICE_CLUSTER_NAMESPACE dengan namespace cluster layanan bersama.

2. Terapkan resource kustom SubcomponentOverride ke cluster admin org:

   kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
   

   Ganti ORG_MGMT_KUBECONFIG dengan jalur ke file kubeconfig pengelolaan di cluster admin org.

Pod dan layanan frontend Terjemahan atau OCR gagal diinisialisasi.

Versi: 1.11.x, 1.12.x, 1.13.x, 1.14.x

Gejala: Selama upgrade, cluster DB dibuat ulang, yang menyebabkan rahasia ODS secret-store di cluster shared-service menjadi tidak berlaku dan tidak tersinkron. Oleh karena itu, pod dan layanan frontend Terjemahan atau OCR gagal diinisialisasi.

Solusi:

Hapus secret di cluster shared-service:

kubectl --kubeconfig SHARED_SERVICEG_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n VAI_API_NAMESPACE

Ganti SHARED_SERVICE_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig di cluster shared-service.

Jika layanan yang bermasalah adalah Translation, ganti VAI_API_NAMESPACE dengan "g-vai-translation-sie"; jika layanan yang bermasalah adalah OCR, ganti VAI_API_NAMESPACE dengan "g-vai-ocr-sie".

Pengontrol membuat ulang secret secara otomatis dan menyinkronkannya kembali dengan cluster DB.

Vertex AI Search

Komponen penelusuran yang terjebak dalam status merekonsiliasi

Versi: 1.14.6

Gejala: Subkomponen vaisearch-conversation dan vaisearch-frontend mengalami masalah pada status Reconciling jika tidak ada resource kustom SearchConfig yang dibuat di organisasi.

Solusi: Masalah ini dapat diabaikan. Setelah pembuatan resource kustom SearchConfig, subkomponen harus menyelesaikan rekonsiliasi.

Server

Rotasi kredensial BIOS macet di tahap reset-requested

Versi: 1.14.4

Gejala: Rotasi kredensial BIOS macet dalam status reset-requested. Anda dapat memverifikasi hal ini dengan memeriksa anotasi gdch.cluster.gke.io/rotation-status untuk secret bios-credentials server:

kubectl get secret bios-credentials-SERVER_NAME -n gpc-system -o jsonpath='{.metadata.annotations.gdch\.cluster\.gke\.io/rotation-status}'

Ganti SERVER_NAME dengan nama server. Output perintah adalah reset-requested jika rotasi terhenti.

Solusi: Untuk menyelesaikan rotasi kredensial BIOS, ikuti runbook SERV-R0018.

Server yang diinstal sebelumnya tidak dapat menyediakan

Versi: 1.14.6

Gejala: Server gagal disediakan setelah dihentikan penyediaannya dan disediakan ulang, khususnya terkait dengan masalah pengelolaan kunci iLO (Integrated Lights-Out) dan HSM (Hardware Security Module). Server, yang sebelumnya merupakan bagian dari organisasi yang dinonaktifkan, mengalami error selama penyediaan gambar, yang menunjukkan ketidakmampuan untuk menemukan perangkat yang sesuai, sering kali karena disk yang terkunci dari kunci lama atau yang dihapus. Anda mungkin melihat error seperti ini:

No suitable device was found for deployment - root device hints were not
provided and all found block devices are smaller than 4294967296B

Solusi: Hapus dan instal ulang server yang terpengaruh untuk membantu server tersebut berada dalam status yang disediakan. Untuk mengetahui informasi selengkapnya, lihat SERV-R0020 dan SERV-R0021. runbook.

Mesin virtual

Impor gambar gagal

Versi: 1.14.4. 1.14.5

Tetap: 1.14.6

Gejala: Impor gambar menggunakan perintah gdcloud compute images import gagal dengan error Unauthorized, karena waktu tunggu sesi habis.

Solusi: Gunakan KRM API untuk impor image Anda sendiri, bukan gdcloud CLI.

Impor gambar KRM memerlukan waktu yang lama

Versi: 1.14.6 dan yang lebih baru

Gejala: Impor image menggunakan KRM API membutuhkan waktu lama untuk diselesaikan. Resource VirtualMachineImageImport tetap dalam status TranslationJobInProgress untuk jangka waktu yang lama, yang menunjukkan bahwa fase terjemahan tidak selesai seperti yang diharapkan. Pod image-translation memasuki status CrashLoopBackOff.

Solusi:

1. Coba impor lagi dengan membuat resource VirtualMachineImageImport baru dengan nama yang berbeda.
2. Pantau status VirtualMachineImageImport dengan memeriksa resource secara berkala hingga statusnya berubah menjadi WaitingForTranslationJob. Untuk mengetahui informasi selengkapnya, lihat runbook VMM R0007.