Masalah umum Google Distributed Cloud dengan air gap 1.13.x

Artifact Registry

Error rekonsiliasi subkomponen sar-failoverregistry

Versi: 1.13.1, 1.13.3, 1.13.4

Gejala: Saat membuat cluster admin root dengan perintah gdcloud system admin-cluster install, operasi dapat gagal jika ada daftar server yang panjang saat bootstrapping. Pesan output error adalah sebagai berikut:

Secret "sar-failoveregistry-backend-parameter" is invalid: data: Too long: must have at most 1048576 bytes

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

  1. Di cluster Kubernetes yang sama dengan subkomponen, cantumkan server dan konfirmasi bahwa setiap resource kustom server memiliki label dengan kunci sebagai cluster.private.gdc.goog/inventory-machine:

    kubectl get servers -n gpc-system

  2. Temukan resource kustom komponen yang terlihat seperti berikut:

      apiVersion: lcm.private.gdc.goog/v1
  kind: Component
  metadata:
    creationTimestamp: "2025-01-06T12:00:41Z"
    generation: 1
    name: sar-v1.14.2-sar-acbf97caf6
    resourceVersion: "3199"
    uid: 681ec5cb-9eb3-423b-ac1d-f6aa27abfd75
  spec:
    name: sar

  3. Di resource kustom komponen System Artifact Registry (SAR), tambahkan pemilih label di server runtimeParameterSources untuk sar-failover-registry:

    1. Melihat resource server yang ada:

      servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system

    2. Perbarui kolom server di resource kustom komponen:

      servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system
    labelSelector:
      - key: cluster.private.gdc.goog/inventory-machine
        operator: "in"
        strValues:
          - "bm-1"
          - "bm-2"
          - "bm-3"

  4. Verifikasi bahwa perubahan pada komponen SAR di langkah sebelumnya diteruskan ke subkomponen sar-failverregistry:

    1. Dapatkan detail komponen SAR:

      kubectl get component | grep sar

    2. Dapatkan detail komponen sar-failoverregistry:

      kubectl get subcomponent sar-failoverregistry -n root

      Gunakan flag -n untuk menentukan namespace.

Pencadangan dan pemulihan

Snapshot gagal karena ruang volume tidak cukup

Versi: Semua versi 1.13.x

Gejala: Ada masalah sesekali dengan pencadangan volume persisten yang dapat memengaruhi alur kerja tugas pencadangan berkala. Untuk beberapa volume dengan laju perubahan yang tinggi, snapshot volume yang diambil untuk pencadangan berkelanjutan dapat menyebabkan volume kehabisan ruang, yang kemudian membuat volume menjadi mode hanya baca.

Solusi: Untuk menghindari potensi dampak pada workload produksi, ikuti langkah-langkah dalam runbook BACK-R0104. Secara opsional, Anda juga dapat menghapus snapshot yang terakumulasi dengan mengikuti runbook BACK-R0106.

Pod bidang kontrol dan agen dimulai ulang karena kurangnya memori

Versi: Semua versi 1.13.x

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

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

Pencadangan gagal untuk snapshot PVC

Versi: Semua versi 1.13.x

Gejala: Kegagalan pencadangan terjadi karena melebihi batas snapshot ONTAP, yaitu 1023 per resource PersistentVolumeClaim (PVC).

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

  1. Perbarui rencana pencadangan agar batas tidak pernah tercapai. Konfigurasi rencana pencadangan untuk melakukan pencadangan setiap jam atau kurangi deleteLockDays menjadi tiga agar jumlah snapshot tidak bertambah lebih dari 1023:

    apiVersion: backup.gdc.goog/v1
kind: BackupPlan
metadata:
  name: test-backup-plan
spec:
  clusterName: system-cluster
  backupSchedule:
    cronSchedule: "*/10 * * * *"
    paused: false
  backupConfig:
    backupScope:
      selectedApplications:
        namespacedNames:
        - name: test-protected-application
          namespace: release-namespace
    backupRepository: gdchservices-backup-repository
    includeVolumeData: true
    volumeStrategy: LocalSnapshotOnly
  retentionPolicy:
    backupDeleteLockDays: LOCK_DAYS
    backupRetainDays: RETENTION_DAYS

    Ganti kode berikut:

    • LOCK_DAYS: mengunci penghapusan cadangan selama jumlah hari yang ditentukan setelah pembuatan cadangan. Gunakan nilai berikut:

      • Jika kolom volumeStrategy ditetapkan ke nilai LocalSnapshotOnly, gunakan nilai 2.
      • Jika kolom volumeStrategy ditetapkan ke nilai ProvisionerSpecific, gunakan nilai 7.

    • RETENTION_DAYS: menghapus cadangan setelah jumlah hari yang ditentukan setelah pembuatan cadangan. Jika kolom volumeStrategy ditetapkan ke nilai LocalSnapshotOnly, gunakan nilai yang kurang dari 3.

  2. Untuk menghapus snapshot berlebih secara manual dari lingkungan Anda menggunakan perintah penghapusan snapshot volume, ikuti langkah-langkah berikut:

    1. Lakukan inisialisasi variabel:

      export RKCNF=/root/release/root-admin/root-admin-kubeconfig
export KCNF=/root/release/org-admin/gdchservices-admin-kubeconfig

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME

      Ganti kode berikut:

      • ORG_NAME: nama organisasi Anda.
      • PVC_NAME: nama resource PVC yang terkait dengan rencana cadangan.

    2. NetApp ONTAP adalah sistem operasi yang digunakan untuk mengelola penyimpanan untuk GDC. Mendapatkan akses ONTAP:

      export USERNAME="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.username}' | base64 -d)"

export MGMT_IP="$(kubectl --kubeconfig ${RKCNF?} get storagecluster -A
-o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

export PASSWORD="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.password}' | base64 -d)"

echo $PASSWORD

    3. Mencantumkan semua snapshot untuk resource PVC yang dipilih:

      ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list

      Gunakan sandi dari langkah sebelumnya untuk login ke mesin di alamat IP yang ditentukan oleh variabel MGMT_IP.

    4. Temukan PVC dengan jumlah snapshot tertinggi:

      grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep snapshot | awk
'{print $2}' | sort | uniq -c

    5. Tetapkan nama resource PVC ke nama resource dengan jumlah snapshot yang tinggi:

      export PV_NAME=

    6. Hapus snapshot untuk resource PVC yang berisi jumlah snapshot tinggi. Batas jumlah snapshot untuk resource PVC adalah 1023:

      for snap_name in `grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep
snapshot | grep ${PV_NAME?} | awk '{print $3}'` do
    echo "volume snapshot delete -vserver ${ORG_NAME} -volume ${PV_NAME} -snapshot $snap_name"
    echo "Y"
done

    7. Login ke ONTAP dan jalankan perintah berikut untuk menghapus snapshot:

      echo $PASSWORD

#Use this password to login to ontap
ssh ${username?}@${mgmt_ip?}

    8. Jalankan perintah yang tercantum di langkah sebelumnya untuk menghapus snapshot. Setelah selesai, keluar dari sesi SSH

  3. Ulangi langkah-langkah penghapusan hingga semua snapshot PVC yang melanggar dibersihkan.

Memulihkan dari cadangan yang tidak kompatibel dengan kuota SVM

Versi: 1.13.1

Gejala: Masalahnya adalah inkompatibilitas antara fitur NetApp. Ketidakcocokan ini mencegah pengiriman kuota tenant dan keberhasilan penerapan pemulihan. Masalah ini hanya terjadi saat memulihkan cadangan ke cluster pengguna yang dibatasi kuotanya.

Solusi: Jika masalah ini terjadi, pemulihan akan gagal dengan pesan error DP volumes are not supported on storage-limit enabled Vserver dan Operator Infrastruktur (IO) harus menonaktifkan kuota untuk cluster pengguna tersebut dan memulai ulang proses pemulihan. Setelah pemulihan selesai, IO harus mengaktifkan kembali kuota tenant dan sistem akan terus berfungsi sebagaimana mestinya. Lihat runbook FILE A0030 untuk mengetahui detail selengkapnya.

Penagihan

Metrik penagihan tidak ditampilkan dengan benar di dasbor penagihan

Versi: 1.13.1

Gejala: Metrik penagihan tidak dipancarkan dengan benar ke cortex karena MetricsProxySidecar tidak ada.

Solusi sementara: Buat resource billing-monetizer MetricsProxySidecar. Kemudian, jalankan skrip untuk memperbarui metricExpression.

  1. Ekspor variabel kubeconfig berikut:

    export KUBECONFIG=KUBECONFIG_PATH

    Ganti variabel KUBECONFIG_PATH dengan jalur ke file kubeconfig untuk cluster admin org. Ikuti langkah-langkah di Service-manual IAM-R0101 untuk membuat file kubeconfig yang diperlukan untuk solusi ini.

  2. Buat resource billing-monetizer MetricsProxySidecaruntuk namespace billing-system dan partner-billing-system:

    Untuk billing-system:

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
  - certificate:
      secretName: billing-monetizer-monitoring-target-platform-obs-cert
    port: 9091
---
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: usagemetering
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8099
    scrapeInterval: 60s
  destinations:
  - port: 9090
    certificate:
      secretName: bil-usagemetering-monitoring-target-cert
EOF

    Untuk partner-billing-system:

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n partner-billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: partner-billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
EOF

  3. Jalankan skrip berikut untuk memperbarui metricExpression. Tindakan ini akan menghapus container_name="monetizer" dari skuconfig, yang mencakup billing_total_cost{container_name="monetizer":

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bc73-b150-e0ea --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bd1a-9464-9df9 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b93c-effb-6d6b --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b871-c5e5-bac1 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig ba38-e4be-ba5d --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bbe8-7b7a-03de --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF

Pengguna gagal membuat BillingAccountBinding karena bug di webhook validasi

Versi: 1.13.0, 1.13.1, 1.13.3

Gejala: Bug ini ada di logika webhook validasi BillingAccountBinding. Jika pengguna mencoba membuat resource BillingAccountBinding, webhook akan menampilkan error permission denied.

Solusi: Untuk membuat resource BillingAccountBinding, beri tahu operator infrastruktur dan buat resource yang sesuai melalui IAC.

Block storage

Pod Grafana macet dalam status Init karena error pemasangan volume.

Versi: 1.13.3

Gejala:

Pod Grafana di namespace anthos-identity-service-obs-system dan platform-obs-obs-system mengalami masalah karena error pemasangan volume.Init Pesan error di log kubelet menunjukkan masalah multi-lampiran. Masalah ini berasal dari bug di Trident, yang gagal mengidentifikasi dan memverifikasi perangkat pokok dengan benar untuk pemetaan LUKS, sehingga menyebabkan error multi-lampiran.

Solusi:

Periksa PVC untuk mengetahui deletionTimestamp. Jika tidak ada deletionTimestamp (migrasi Pod), ikuti langkah-langkah berikut:

  1. Periksa VolumeAttachment untuk PVC guna mengidentifikasi tempat volume saat ini terpasang.
  2. Batasi Nodes dalam cluster yang tidak cocok dengan nilai ini.
  3. Hapus Pod yang gagal, tindakan ini akan menyebabkan Pod dimigrasikan kembali ke Node asli.

Setelah memeriksa, jika ada deletionTimestamp (Penghapusan volume), ikuti langkah-langkah berikut:

  1. Periksa VolumeAttachment untuk PVC guna mengidentifikasi tempat volume saat ini terpasang.

  2. Di Node, keluarkan konten file pelacakannya:

    cat /var/lib/trident/tracking/PVC_NAME.json

  3. Validasi bahwa perangkat LUKS yang ditemukan di kolom devicePath output file pelacakan benar-benar ditutup. Jalur ini tidak boleh ada pada tahap ini:

    stat DEVICE_PATH

  4. Validasi apakah nomor seri saat ini dipetakan ke perangkat multi-jalur.

    1. Salin nilai di kolom iscsiLunSerial pada file pelacakan.

    2. Konversi nilai ini menjadi nilai hex yang diharapkan:

      echo 'iISCSILUNSERIAL' | xxd -l 12 -ps

    3. Dengan nilai baru ini, cari tahu apakah entri multi-jalur masih ada:

      multipath -ll | grep SERIAL_HEX

    4. Jika tidak ada, hapus file pelacakan.

    5. Jika ada, Anda akan melihat nilai serial-hex yang sedikit lebih panjang daripada yang ditelusuri, yang akan disebut multipathSerial. Jalankan perintah berikut dan temukan perangkat blok:

      multipath -ll MULTIPATH_SERIAL

    6. Kemudian, jalankan perintah berikut, dengan perintah terakhir dijalankan secara unik untuk setiap perangkat blok:

      systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

Pod peluncur mesin virtual gagal memetakan volume

Versi: 1.13.1

Gejala:

Anda mungkin melihat peringatan yang terlihat seperti ini:

 Warning  FailedMapVolume  2m50s (x206 over 13h)  kubelet  MapVolume.SetUpDevice failed for volume "pvc-2a68356a-47da-422b-8781-15e3a6fe7ec9" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

Untuk mendiagnosis masalah, ikuti langkah-langkah berikut:

  1. Pastikan volume dan pod berada di node yang sama.
  2. Temukan node tempat pod berada dan periksa kondisinya.
  3. Periksa konektivitas node.
  4. Periksa IPSEC.
  5. Periksa multipath untuk melihat apakah ada zombie.

  6. Periksa log Trident untuk mengetahui langkah mana dalam alur CSI yang mungkin menyebabkan zombie ini:

    kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main

Solusi: Untuk mengatasi masalah ini, ikuti langkah-langkah dalam runbook berikut:

  1. Untuk masalah terkait node, lihat runbook FILE-R0010.
  2. Untuk masalah terkait IPSEC, lihat runbook FILE-R0007.
  3. Untuk masalah terkait LUN zombie, lihat runbook FILE-R0020.
  4. Untuk masalah terkait LUN super zombie, lihat runbook FILE-R0021.

Kegagalan terkait penyimpanan

Versi: 1.13.1

Gejala: Kegagalan terkait penyimpanan dapat diidentifikasi dengan pemberitahuan file_block_zombie_luns_present yang muncul atau pod yang gagal diaktifkan karena masalah pada panggilan MountVolume yang berlanjut selama lebih dari satu loop rekonsiliasi. Waktu tunggu mungkin sekitar dua menit. Pengulangan kegagalan yang sama menunjukkan bahwa ada yang gagal di jalur CSI NodeStage atau NodePublish dan memerlukan solusi. Satu-satunya pengecualian adalah indikasi kegagalan waktu tunggu. Anda mungkin melihat beberapa kegagalan seperti ini:

NMountVolume.SetUp failed for volume "pvc-a63313b2-3e30-4c92-b074-f9fffe0500a4" : rpc error: code = Internal desc = unable to mount device; exit status 32

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: multipath device not found when it is expected

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: failure when reconfiguring multipath

Solusi:

  1. Untuk melihat apakah Node yang memiliki Pod dapat diperbaiki untuk PVC yang gagal, batasi node saat ini tempat pod dijadwalkan dan hapus Pod:

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE

    Pod harus dijadwalkan ke Node yang sama sekali berbeda, yang menyebabkan Trident dipaksa untuk menjalankan NodeStage, NodePublish, NodeUnpublish, dan NodeUnstage sepenuhnya. Tindakan ini mungkin tidak langsung memperbaiki volume karena mungkin masih ada sesi yang terbuka untuk volume ini di Node asli.

  2. Setelah langkah sebelumnya selesai, batalkan cordon node yang dimaksud:

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE

  3. Jika kegagalan masih ada, batasi semua Nodes lainnya kecuali yang tempat Pod awalnya dijadwalkan, lalu hapus Pod. Hal ini akan mengakibatkan Pod dimulai pada Node asli tempat perangkat yang ada mungkin masih berada.

  4. Setelah langkah sebelumnya selesai, hapus cordon pada node yang dimaksud.

  5. Sebagai hasil terakhir untuk menyimpan PV dan datanya, Node dapat di-reboot untuk menghapus kegagalan multipath, udev, dan devmapper di Node. Meskipun langkah ini cukup sulit, kemungkinan besar akan berhasil.

  6. Jika mitigasi sebelumnya gagal menyelesaikan masalah volume, hal ini menunjukkan bahwa data telah rusak dan tidak dapat digunakan. Satu-satunya opsi yang tersisa untuk melanjutkan perilaku penampung yang diinginkan adalah menghapus PV, PVC, dan Pod yang gagal, diikuti dengan memulai ulang node tempat PV dihosting. Tindakan ini akan mengakibatkan hilangnya data sepenuhnya dari apa pun yang telah ditulis ke dalam volume.

Volume persisten yang dibuat dengan ukuran yang salah

Versi: 1.13.1

Gejala: Beban kerja dengan volume persisten dibuat sekitar 16 MiB terlalu kecil. Jika workload bergantung persis pada ukuran yang diiklankan oleh volume persisten, perbedaan kecil akan menyebabkan workload gagal saat diperluas atau disediakan. Masalah ini lebih mungkin terjadi pada volume persisten yang disediakan dengan kelas penyimpanan standard-block dibandingkan dengan yang disediakan dengan kelas penyimpanan standard-rwo. Masalah ini mungkin terjadi pada volume persisten dengan kelas penyimpanan standard-rwo yang menggunakan mode volumemode:block.

Solusi: Alokasikan volume persisten yang setidaknya 16 MiB lebih besar dari yang sebenarnya diperlukan.

Tidak dapat menghapus virtual machine penyimpanan

Versi: 1.13.1

Gejala: StorageVirtualMachine mungkin menampilkan error seperti ini:

 Warning  SVMDeletion  27m (x32 over 4h9m)   StorageVirtualMachine  Reconcile error for svm deletion: failed to delete svm: failed to delete svm volumes: failed to call VolumeCollectionGet: error message: "SVM \"org-2-user\" does not exist. "; error target: "svm.name"

Solusi: Hapus finalizer dari StorageVirtualMachines di namespace organisasi.

Penonaktifan organisasi tidak membersihkan resource

Versi: 1.13.1

Gejala: Saat menonaktifkan organisasi, beberapa resource StorageVirtualMachines tertinggal, misalnya:

  • gpc-system secret/org-2-admin-backup-agent-cert-secret
  • gpc-system secret/org-2-admin-client-cert-secret
  • gpc-system secret/org-2-admin-server-cert-secret
  • gpc-system secret/org-2-admin-svm-credential
  • gpc-system secret/org-2-admin-backup-agent-cert-secret
  • gpc-system secret/org-2-admin-client-cert-secret
  • gpc-system secret/org-2-admin-server-cert-secret
  • gpc-system secret/org-2-admin-svm-credential

Solusi: Hapus resource ini.

Kegagalan rekonsiliasi penghapusan

Versi: 1.13.1

Gejala: Jika StorageVirtualMachine dihapus sebelum pembersihan cluster yang bergantung pada StorageVirtualMachine tersebut, ada potensi untuk melihat masalah saat membersihkan beberapa volume persisten (PV) cluster. Khususnya, jika PV yang dienkripsi LUKS tidak dibersihkan, rahasianya akan mencegah penghapusan namespace tempat PV tersebut berada. Anda mungkin melihat peringatan di log seperti ini:

Warning  ReconcileBackoff  5m35s (x6 over 88m)  ClusterLifecycleReconciler  cluster namespace deletion is not completed: deletion is still ongoing for namespace: /g-org-2-shared-service-cluster

Solusi: Hapus finalizer dari secret g-luks-gdc-vm-disk-* di namespace cluster layanan.

Upgrade bare metal macet

Versi: 1.13.1, 1.13.5, 1.13.6

Gejala: Tugas Ansible macet saat mengumpulkan fakta jika ada LUN Zombie. Menjalankan perintah multipath -ll dapat menunjukkan masalah berikut:

3600a098038314955593f574669785635 dm-11 NETAPP,LUN C-Mode
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 5:0:0:10 sdaf 65:240 failed faulty running
| `- 6:0:0:10 sdau 66:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 7:0:0:10 sdad 65:208 failed faulty running
  `- 8:0:0:10 sdar 66:176 failed faulty running

Anda mungkin juga melihat pesan error berikut:

 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Check inventory] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [set_fact] ****************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.018)       0:00:00.018 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [10.252.151.3]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Verify inventory]********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [assert]******************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.031)       0:00:00.050 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [localhost]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [all] *********************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [Gathering Facts] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.064)       0:00:00.114 ********

Solusi: Periksa konektivitas SSH dengan node target, lalu gunakan runbook berikut: FILE-R0020.

Error multi-lampiran Trident

Versi: 1.13.3

Gejala: Pod dan PVC mungkin terdampar di node yang berbeda dengan pod macet saat menginisialisasi dan menunggu PVC.

Solusi:

  1. Periksa PVC untuk deletionTimestamp:

    kubectl --kubeconfig KUBECONFIGget pvc -n <namespace> | grep deletionTimestamp

  2. Jika tidak ada deletionTimestamp (Migrasi Pod):

    1. Periksa VolumeAttachment untuk PVC guna mengidentifikasi tempat volume terpasang.
    2. Membatasi Node dalam cluster yang tidak cocok dengan nilai ini.
    3. Hapus Pod yang gagal. Tindakan ini akan memigrasikan POD kembali ke Node asli.

  3. Jika ada deletionTimestamp (Penghapusan volume):

    1. Periksa VolumeAttachment untuk PVC guna mengidentifikasi tempat volume terpasang.
    2. Di Node, keluarkan konten file pelacakannya, /var/lib/trident/tracking/PVC_NAME.json.
    3. Validasi bahwa perangkat LUKS yang ditemukan di kolom devicePath dari output file pelacakan benar-benar ditutup. Jalur ini tidak boleh ada pada tahap ini: stat DEVICE_PATH. Jika jalur masih ada, masalah lain sedang terjadi.
    4. Validasi apakah nomor seri dipetakan ke perangkat multi-jalur.
    5. Salin nilai di kolom iscsiLunSerial pada file pelacakan.
    6. Konversi nilai ini menjadi nilai hex yang diharapkan: echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
    7. Dengan nilai baru ini, cari tahu apakah entri multi-jalur masih ada: multipath -ll | grep SERIAL_HEX.
    8. Jika tidak ada, hapus file pelacakan.

    9. Jika ada, Anda akan melihat nilai hex-seri yang sedikit lebih panjang daripada yang Anda telusuri. Catat nilai ini sebagai MULTIPATH_SERIAL. Jalankan multipath -ll MULTIPATH_SERIAL dan Anda akan melihat pesan seperti ini:

      3600a09803831486f2d24575445314678 dm-32 NETAPP,LUN C-Mode
size=8.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:12 sde  8:64   active ready running
| `- 2:0:0:12 sdt  65:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:12 sdbc 67:96  active ready running
  `- 4:0:0:12 sdbe 67:128 active ready running

    10. Jalankan perintah berikut:

      1. systemctl restart iscsid
      2. systemctl restart multipathd
      3. multipath -f MULTIPATH_SERIAL
      4. echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

    11. Jalankan perintah terakhir secara unik untuk setiap perangkat blok.

Error dalam konfigurasi IPsec

Versi: 1.13.4

Gejala: Konfigurasi IPsec ONTAP mengalami error karena pre-shared key (PSK) yang tidak valid berisi 0X yang ditafsirkan sebagai string heksadesimal.

Anda mungkin melihat peringatan seperti ini:

Warning  ONTAPIPSecConfiguration  3m47s (x22 over 75m)  StorageEncryptionConnection  Reconcile error on ONTAP IPSec configuration: failed to call IpsecPolicyCreateDefault: error message: "The specified pre-shared key \"0XxBDkG8iHoAlOc
nCUfHl0AKYzClgGCH\" is not valid because it is not a valid hexadecimal string."; error target: ""

Solusi:

  1. Dapatkan koneksi enkripsi penyimpanan:

    kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

    Cari entri dengan Ready=False dan catat nama PRESHAREKEY. Output-nya mungkin terlihat seperti contoh ini:

    NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR        PRESHAREDKEY                 READY   AGE
vm-5a77b2a2   vm-5a77b2a2        gpu-org-user            192.0.2.0/27   vm-5a77b2a2-pre-shared-key   False   26h

  2. Mesin ini menjalankan org GPU, jadi hapus secrets gpc-system/vm-5a77b2a2-pre-shared-key di gpu-org-admin.

  3. Tunggu hingga sistem membuat ulang secret/vm-5a77b2a2-pre-shared-key.

  4. Cari tugas dengan pola seperti gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2. Perhatikan bahwa 8 karakter terakhir dibuat secara acak. Setelah kunci tersedia lagi, hapus tugas, seperti jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl di gpu-org-admin.

Mesin virtual penyimpanan tidak dibuat

Versi: 1.13.5

Gejala: Layanan Harbor di gpu-org gagal dimulai karena masalah dengan volume penyediaan. Masalah ini disebabkan oleh pod file-storage-backend-controller yang mereferensikan mesin inventaris yang tidak ada.

Anda mungkin melihat error pengontrol penyimpanan seperti ini, yang menunjukkan bahwa InventoryMachine tidak ditemukan:

{"ts":1730135301218.1772,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"StorageEncryptionConnectionGenerator","controllerGroup":"baremetal.cluster.gke.io","controllerKind":"InventoryMachine","InventoryMachine":{"n
ame":"vm-26c89d33","namespace":"@org-1/org-1-admin"},"namespace":"@org-1/org-1-admin","name":"vm-26c89d33","reconcileID":"48ab38a8-385d-4fdb-bd7e-1212f287379c","err":"InventoryMachine.baremetal.cluster.gke.io \"vm-26c89d33\" not found"}

Solusi:

  1. Hapus pod file-storage-backend-controller.
  2. Biarkan pengontrol penyimpanan mengambil ulang mesin inventaris yang ada.

Jaringan intercluster penyimpanan gagal disesuaikan

Versi: 1.13.5, 1.13.6

Gejala: Setelah upgrade, resource kustom StorageCluster di cluster admin root gagal siap karena kesalahan konfigurasi di subnet antar-cluster dalam spesifikasi. Cluster penyimpanan melaporkan Not Ready dan menyertakan peristiwa dengan error ini:

Reconciler error: failed to configure additional networks: failed to configure intercluster LIF: the \"\" Kind is not currently supported

Jika error ini terjadi, klaim subnet antar-cluster yang digunakan oleh cluster penyimpanan tidak menyertakan kolom kind dalam referensi. Setelah memeriksa resource kustom StorageCluster, Anda akan menemukan referensi klaim subnet antar-cluster dengan hanya nama dan namespace seperti ini:

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

Solusi:: Perbarui spesifikasi StorageCluster untuk menyertakan kolom kind: SubnetClaim dalam referensi klaim subnet:

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        kind: SubnetClaim
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

Setelah memperbarui spesifikasi StorageCluster, mulai ulang Deployment file-storage-backend-controller dan verifikasi bahwa cluster penyimpanan sudah siap.

Pengelolaan cluster

Tugas machine-init gagal selama penyediaan cluster

Versi: 1.13.1

Gejala:

  1. Selama penyediaan cluster, tugas machine-init dari node bidang kontrol kedua gagal dengan pesan berikut:

    FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".

  2. Lihat log:

    kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"

    Output menampilkan hasil yang tidak kosong.

Solusi:

  1. Aktifkan/nonaktifkan izin /etc/kubernetes/pki/etcd/ca.crt. Operasi ini sangat sensitif terhadap waktu. Pengalihan izin harus terjadi setelah pekerjaan machine-init sebelumnya dijalankan, tetapi sebelum pekerjaan machine-init berikutnya dijalankan, karena machine-init akan mengganti izin kembali ke root.

  2. Mulai ulang etcd di node kedua untuk memulihkan etcd di node pertama dari loop error.

Setelah menyelesaikan kedua langkah ini, kube-apiserver di node pertama akan mulai berjalan, dan tugas machine-init berikutnya akan berhasil.

Tidak ada konektivitas dari cluster layanan ke bucket penyimpanan objek

Versi: 1.13.1

Gejala: Koneksi untuk pod database yang berjalan di cluster layanan ke bucket penyimpanan objek di cluster admin org gagal.

Solusi: Ikuti petunjuk dalam runbook KUB-R0305.

Pemeriksaan preflight gagal

Versi: 1.13.1

Gejala: Anda mungkin melihat pesan berikut di status objek cluster:

conditions:
    message: Preflight check <cluster> failed
    reason: PreflightCheckFailed
    status: "False"
    type: PreflightCheckSuccessful

Anda juga akan melihat objek PreflightCheck yang sesuai dengan nama dan namespace yang sama dengan objek cluster yang telah ada selama beberapa jam, sementara error atau kegagalan yang ditunjukkan dalam objek PreflightCheck diketahui tidak lagi menjadi masalah.

Solusi: Hapus objek PreflightCheck.

Pembuatan kumpulan node pekerja cluster pengguna gagal

Versi: 1.13.5

Gejala: Pembuatan node pool pekerja cluster pengguna mungkin berhenti merespons untuk salah satu jenis mesin berikut:

  • n2-standard-16-gdc
  • n2-standard-32-gdc
  • n2-highmem-16-gdc
  • n2-highmem-32-gdc

Solusi: Hapus node pool tersebut dan buat ulang dengan memilih jenis mesin lain yang tersedia dari drop-down UI pembuatan cluster pengguna.

Cluster pengguna saat dibuat ulang mungkin macet dalam proses mencocokkan karena pembersihan yang tidak tepat

Versi: 1.13.x

Gejala: Jika cluster pengguna dibuat dengan nama yang sama seperti cluster yang dihapus sebelumnya, cluster tersebut mungkin terus berada dalam status Reconciling tanpa akhir dengan status yang menyebutkan tahap penginstalan add-on ONE.

Solusi: Uninstal addon helm CLUSTER_NAME-abm-overrides dan mulai ulang deployment managed-adm-controller. Ikuti MKS-R0004 untuk mengetahui langkah-langkah mendetail.

Layanan database

Bagian ini berisi masalah umum untuk layanan Database.

Kloning database AlloyDB Omni macet

Versi: Semua versi 1.13.x

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.

Penerapan IOPS memengaruhi performa penyimpanan

Versi: 1.13.1

Solusi: Untuk mengatasi masalah ini, ikuti salah satu opsi berikut:

  • Perbesar ukuran penyimpanan.
  • Ganti kuota IOPS.

Error rekonsiliasi saat mengupgrade subkomponen dbs-fleet

Versi: 1.13.3

Gejala: Saat mengupgrade org root dari 1.13.1 ke 1.13.3, Anda mungkin melihat error rekonsiliasi. Periksa error rekonsiliasi:

kubectl get subcomponent -n ${CLUSTER} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

Error mungkin terlihat seperti ini:

Sub-Component: dbs-fleet - Reconciliation error: E0121 - rollback chart: no ControlPlaneAgentsVersion with the name "alloydbomni-v0.12.46" found

Solusi: Ikuti langkah-langkah dalam runbook OCLCM-R0122.

Pembuatan DBCluster gagal

Versi: 1.13.3

Gejala: Setelah mengupgrade ke 1.13.3, DBcluster baru gagal disesuaikan, dengan error berikut dalam status:

status:
  criticalIncidents:
  - code: DBSE0001
    createTime: ""
    message: Internal. General Controller Error.
    resource:
      component: controller-default
      location: {}
    stackTrace:
    - component: controller-default
      message: 'DBSE0001: Internal. General Controller Error. Failed to reconcile
        Postgres DBCluster [<name>] DBSE0001: Internal.
        General Controller Error. target release is empty in ModuleInstance <name>'

Solusi

Verifikasi bahwa ada CR localrollout yang diakhiri dengan cpa-v0.12.46 dan cpa-v0.12.51 di cluster admin org. Contoh:

kubectl get localrollouts -A

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

Temukan dan hapus CR localrollout yang diakhiri dengan cpa-v0.12.46, sehingga memastikan CR localrollout lainnya tidak terpengaruh.

kubectl get localrollouts -A | grep cpa-v0.12.46

Tindakan ini akan menampilkan daftar seperti ini:

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true

Hapus setiap item:

kubectl delete -n dbs-fleet-system localrollout/dp-alloydbomni-15-5.2--cpa-v0.12.46
...
...

Pastikan bahwa CR localrollout yang diakhiri dengan cpa-v0.12.51 masih ada:

NAMESPACE          NAME                                        PAUSED   IN PROGRESS   FINISHED
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

DNS

DNSSEC harus dinonaktifkan secara eksplisit di resolved.conf

Versi: 1.13.1, 1.13.3, 1.13.4

Gejala: Resolusi DNS gagal di node bare metal atau VM. Untuk mengonfirmasi bahwa resolusi DNS gagal, buat koneksi SSH ke node yang terpengaruh, lalu jalankan systemctl status systemd-resolved. Output-nya berisi baris seperti DNSSEC validation failed for question . IN SOA: no-signature.

Solusi:

  1. Tambahkan baris berikut ke /etc/systemd/resolved.conf di node yang terpengaruh.

    DNSSEC=false

  2. Mulai ulang layanan systemd-resolved:

    systemctl restart systemd-resolved.service

Layanan pelabuhan

Kegagalan pembuatan layanan Harbor

Versi: 1.13.6

Gejala: Pembuatan instance Harbor gagal karena ketidakcocokan namespace yang disebabkan oleh batasan panjang pada nama ServiceIsolationEnvironment. Anda mungkin melihat pesan seperti ini:

Failed to reconcile ODSDatabase: failed to create or update ODS ProjectNetworkPolicy: namespaces "g-dbs-PROJECT_NAME-HARBOR_INSTANCE_NAME" not found

Solusi: Persingkat nama instance Harbor untuk menyelesaikan masalah saat ini. Pastikan panjang gabungan PROJECT_NAME dan HARBOR_INSTANCE_NAME kurang dari 27 karakter.

Menghapus instance Harbor tidak akan menghapus mirror registry terkait

Versi: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8

Gejala: Menghapus instance Harbor tidak menghapus mirror registry terkait. Nodepool mungkin macet dalam status Provisioning. Hal ini disebabkan oleh mirror registri yang dibuat oleh pengontrol MHS tidak dihapus saat instance Harbor dihapus.

Solusi: Anda harus menghapus mirror registri secara manual. Untuk mengurangi masalah ini, ikuti langkah-langkah berikut:

  1. Hubungkan ke cluster admin org. Untuk mengetahui informasi selengkapnya, lihat arsitektur cluster GDC.

  2. Jalankan skrip ini untuk menghapus mirror registri yang cocok dengan nilai variabel lingkungan HARBOR_INSTANCE_URL dari semua cluster Kubernetes yang memiliki label lcm.private.gdc.goog/cluster-type=user:

    LABEL="lcm.private.gdc.goog/cluster-type=user"
ENDPOINT=HARBOR_INSTANCE_URL

while read -r out; do
    info=${out% *}
    ns_name=${info%:*}
    name=${ns_name##*/}
    ns=${ns_name%%/*}
    INDEX=$(kubectl get cluster user-vm-1 -n user-vm-1-cluster -ojson | jq '.spec.nodeConfig.registryMirrors | map(.endpoint=='\"$ENDPOINT\"') | index(true)')
    kubectl patch clusters "${name}" -n "${ns}" --type=json -p="[{'op': 'remove', 'path': '/spec/nodeConfig/registryMirrors/$INDEX'}]"
done <<< $(kubectl get clusters -l "$LABEL" -o jsonpath="$JSONPATH" -A)

    Ganti HARBOR_INSTANCE_URL dengan URL instance Harbor Anda.

Modul keamanan hardware

Lisensi uji coba HSM yang dinonaktifkan masih dapat dideteksi

Versi: 1.13.1, 1.13.3-1.13.11

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

Masa berlaku sertifikat HSM telah berakhir

Versi: 1.13.11

Gejala: Saat mengupgrade org, Anda mungkin melihat peringatan seperti ini:

Warning  Unsuccessful  50m   OrganizationUpgrade  1 error occurred:
          * UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn't after 13h45m23.442682119s, last message was: Cluster upgrade for system cluster: in-progress

org-1-system-cluster mengalami masalah saat mengupgrade versi ABM karena sertifikat HSM (Hardware Security Module) telah habis masa berlakunya.

Anda mungkin juga melihat error seperti contoh ini di iLO server HPE, StorageGRID, atau ONTAP:

Not able to connect SSL to Key Manager server at IP_ADDRESS

Solusi:

Putar sertifikat antarmuka web dan CA root secara manual dengan ksctl:

  1. Menjeda semua CR HSM, HSMCluster, dan HSMTenant.

  2. Buat CA root baru dengan atribut yang disalin dari CA lama. Temukan ID CA lama dengan ksctl ca locals list. Contohnya mungkin terlihat seperti ini:

    ksctl ca locals create --cn example.com --copy-from-ca 6d7f7fa7-df81-44b7-b181-0d3e6f525d46
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:46:25.728332Z",
    "state": "pending",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIHQMHgCAQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAR5pwW1UC1JNg79gkjK2rvnmgaZpGNwb4VxYN3dQCieHtHlYJUu\nQWk56RB9oPw4SKkf/Y1ZwEI4m2mx3d9XFHU7oAAwCgYIKoZIzj0EAwIDSAAwRQIh\nANWTPjkJNcY56lSARN714EBa1gLuvxJlMENVHKEbanooAiA1BQ3sz7mxykL/1t7v\nqRlIpxKGrhw56XC67vz4NvZ4Kg==\n-----END CERTIFICATE REQUEST-----\n",
    "subject": "/CN=example.com",
    "notBefore": "0001-01-01T00:00:00Z",
    "notAfter": "0001-01-01T00:00:00Z",
    "sha1Fingerprint": "21F033940A65657CC6C2C1EA0BB775F14FD5D193",
    "sha256Fingerprint": "31EF6E1316DF039F77DDDB051890CDEBBF67BBE8A14AEE04E01716D30DC90937",
    "sha512Fingerprint": "F200817829A23F30239C33DC2CED8C889954A252EBA2CC12A3977FD5F91239ED7A2A4CCF0EA3D90D50CEF7A779E5C487798AAC75617DB2F29AF7F4794AD66F17",
    "purpose": {}
}

  3. Tanda tangani sendiri CA baru dengan durasi satu tahun. Contohnya mungkin terlihat seperti ini:

    ksctl ca locals self-sign --id b0516120-6b4c-40ed-93f4-35e9fdc690e7 -x 365
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:52:51.976847092Z",
    "state": "active",
    "csr": "",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n",
    "serialNumber": "271910941595574900448900837122680099988",
    "subject": "/CN=example.com",
    "issuer": "/CN=example.com",
    "notBefore": "2025-06-03T18:52:51Z",
    "notAfter": "2026-06-04T18:52:51Z",
    "sha1Fingerprint": "1114AF5ED6DF7D4A9F83A0F8DF5DFEF041A81622",
    "sha256Fingerprint": "93BAD9D44B320EFB446F65FE2A4F3A341147D15AF5315C000ADF644A3C1347A7",
    "sha512Fingerprint": "07386D7461B4013304CF0E0830517EA433E09EAB146A9F106F1B0DED4BBEC78BB4C89EAFAEC37178FE98AC4ACA234B98290D240607D5EA896F03DABF3DB56D5C",
    "purpose": {
            "client_authentication": "Enabled",
            "user_authentication": "Enabled"
    }
}

  4. Perbarui antarmuka web untuk menggunakan CA baru ini untuk pembuatan otomatis sertifikatnya. Contoh mungkin terlihat seperti ini:

    ksctl interfaces modify --name web --auto-gen-ca-id kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7                 
{                                                                                                                                                                      
    "id": "61aab814-2821-43ac-b652-41784b7b06bf",                                                                                                                  
    "name": "web",                                                                                                                                                 
    "mode": "tls-cert-opt-pw-opt",                                                                                                                                 
    "cert_user_field": "CN",                                                                                                                                       
    "auto_gen_ca_id": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",                                                                              
    "trusted_cas": {                                                                                                                                               
            "local": [                                                                                                                                             
                    "kylo:kylo:naboo:localca:6d7f7fa7-df81-44b7-b181-0d3e6f525d46"                                                                                 
            ]                                                                                                                                                      
    },                                                                                                                                                             
    "createdAt": "2023-11-13T22:46:56.251881Z",                                                                                                                    
    "updatedAt": "2025-06-04T19:02:12.710563Z",                                                                                                                    
    "port": 443,                                                                                                                                                   
    "network_interface": "all",                                                                                                                                    
    "interface_type": "web",                                                                                                                                       
    "minimum_tls_version": "tls_1_2",                                                                                                                              
    "maximum_tls_version": "tls_1_3",                                                                                                                              
    "local_auto_gen_attributes": {                                                                                                                                 
            "cn": "web.ciphertrustmanager.local",                                                                                                                  
            "dns_names": [                                                                                                                                         
                    "web.ciphertrustmanager.local"                                                                                                                 
            ],      
...

  5. Buat sertifikat antarmuka web baru, yang ditandatangani oleh CA baru. Flag --url adalah IP pengelolaan HSM (dari kubectl get hsm -n gpc-system). Contohnya mungkin terlihat seperti ini:

    ksctl interfaces auto-gen-server-cert --name "web" --url=https://10.128.52.18
{
    "certificates": "-----BEGIN CERTIFICATE-----\nMIICljCCAjygAwIBAgIRANPuw/42oHZAb9nzAYnrf9MwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTkwOTU5WhcNMjYwNjA0MTg1\nMjUxWjBjMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3Rp\nbjEPMA0GA1UEChMGVGhhbGVzMSUwIwYDVQQDExx3ZWIuY2lwaGVydHJ1c3RtYW5h\nZ2VyLmxvY2FsMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEy9T8uGa/N9ruRJMy\nxy4an+G/OyZjB/8nth1BPxpw5orljbTuOh9toS9c9FiOuMQQ13mGJSImadLP33PR\ngdXcHaOCARwwggEYMA4GA1UdDwEB/wQEAwIDiDATBgNVHSUEDDAKBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFD24KdNn6UeGIvHd/XESfT4kLkn5\nMGIGA1UdEQRbMFmCHHdlYi5jaXBoZXJ0cnVzdG1hbmFnZXIubG9jYWyBIXRlY2hu\naWNhbC5zdXBwb3J0QHRoYWxlc2dyb3VwLmNvbYcECoA0EocECgADAocErBMjAocE\nrBMLAjBeBgNVHR8EVzBVMFOgUaBPhk1odHRwOi8vY2lwaGVydHJ1c3RtYW5hZ2Vy\nLmxvY2FsL2NybHMvYjA1MTYxMjAtNmI0Yy00MGVkLTkzZjQtMzVlOWZkYzY5MGU3\nLmNybDAKBggqhkjOPQQDAgNIADBFAiEAusSKWMoFeTsK+OrbURch7XtMR31XD45E\n+w+wjf2VAk4CIAsHytphizTFQks4qqOMaHm6Ap58uU0HMNGSm0WW6mQY\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n"
}

  6. Pada tahap ini, openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text masih menampilkan sertifikat lama. Anda harus melakukan reboot HSM untuk mengambil sertifikat baru.

    ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot

    Sekarang openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text menampilkan sertifikat baru.

  7. Hapus CA lama dari HSM CR:

    kubectl edit hsm zv-aa-hsm01 -n gpc-system and delete hsm.Spec.RootCACertificates

  8. Lanjutkan HSM: 

    kubectl annotate hsm zv-aa-hsm01 -n gpc-system hsm.security.private.gdc.goog/paused-

    Pastikan HSM menjadi responsif.

  9. Ulangi langkah-langkah ini untuk dua HSM lainnya. CA root yang ditandatangani sendiri yang baru sudah ada karena CA dibagikan di antara HSM dalam cluster. Lewati langkah 2 dan 3, tetapi ulangi langkah 4-8.

  10. Ikuti tugas berat rotasi CA HSM T0008 untuk mengotomatiskan rotasi semua sertifikat, tetapi lewati langkah Selesaikan rotasi dengan menambahkan anotasi rotasi baru ke hsmcluster tempat ca-rotation-finalizing annotation ditambahkan.

Upload nama CA baru ke iLO:

  1. Di antarmuka iLO, buka halaman Administration - Key Manager, lalu klik tab Key Manager.
  2. Ganti nama sertifikat.
  3. Lakukan reboot dingin.
  4. Pastikan handshake SSL mulai berfungsi kembali.

Pengelolaan akses dan identitas

Pod gatekeeper-audit di namespace opa-system sering dimulai ulang

Versi: 1.13.3

Gejala: Periksa status pod gatekeeper-audit-*** di namespace opa-system:

kubectl get pods/gatekeeper-audit-POD_ID -n opa-system-NAMESPACE_ID -n opa-system

Output-nya mungkin terlihat seperti contoh ini:

NAME                                READY   STATUS    RESTARTS        AGE
gatekeeper-audit-58d8c4c777-7hzvm   2/2     Running   987 (12h ago)   12d

Masalah ini disebabkan oleh batas resource yang rendah.

Infrastructure as Code (IAC)

Pembuatan token Gitlab yang berlebihan berisiko mengisi database Gitlab

Versi: 1.13.1

Gejala: Subkomponen iac-manager membuat token baru untuk pengguna configsync-ro berulang kali, meskipun tidak diperlukan. Hal ini dapat menyebabkan database Gitlab penuh dan membuat IAC tidak dapat diakses. Pod pg-gitlab-database-0 di namespace gitlab-system mungkin tidak dapat dimulai dan menampilkan peristiwa seperti:

  Warning  Unhealthy  84s (x18 over 4m14s)   kubelet  Startup probe failed: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  could not write init file

Solusi:

Bekerja samalah dengan kontak Google Anda untuk mendapatkan hotfix_3 untuk rilis 1.13.1 dan terapkan.

Sistem Pengelolaan Kunci (KMS)

Mengubah jenis kunci root akan membuat semua kunci yang ada menjadi tidak valid

Versi: 1.13.x

Gejala: Setelah organisasi dibuat, KMS akan otomatis disediakan dengan kunci root software. Untuk bermigrasi dari kunci root software ke kunci CTM, pengguna melakukan penggantian subkomponen. Tindakan ini mengubah jenis kunci root, yang membuat semua kunci software yang ada di KMS menjadi tidak valid.

Solusi: Hindari mengupdate jenis kunci root jika memungkinkan. Jika Anda memperbarui jenis kunci root, semua kunci yang ada akan menjadi tidak valid.

kms-rootkey-controller CrashLoopBackOff karena OOMKILL

Versi: 1.13.1

Gejala: Jika penggunaan memori kms-rootkey-controller melebihi batas 600Mi, pengontrol akan memasuki CrashLoopBackOff karena status OOMKilled.

Solusi: Buat SubcomponentOverride untuk memperbarui batas memori menjadi 1500Mi. Untuk mengetahui petunjuknya, lihat KMS Runbook 0007. Setelah Anda menyelesaikan langkah-langkah prasyarat dari runbook, jalankan perintah berikut:

  1. Buat resource kustom SubcomponentOverride:

    cat << EOF > ~/kms-rootkey-subcomponentoverride.yaml

    Pada contoh berikut, Anda akan melihat resource kustom SubcomponentOverride yang lengkap:

    apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: kms-rootkey-subcomponentoverride
  namespace: root
spec:
  subComponentRef: kms-rootkey-cm
  backend:
    operableParameters:
      resourcesLimit:
        memory: 1500Mi
EOF

  2. Terapkan resource SubcomponentOverride:

    kubectl --kubeconfig ${KUBECONFIG:?} apply -f ~/kms-rootkey-subcomponentoverride.yaml

kubectl --kubeconfig ${KUBECONFIG:?} describe subcomponentoverride kms-rootkey-subcomponentoverride -n root

Logging

Pencatat audit penyimpanan objek tidak dapat me-resolve host DNS

Versi: 1.13.x

Gejala:

Di cluster admin root, deployment obs-system/log-remote-logger berisi beberapa error seperti berikut:

E1220 17:00:25.247258       1 manager.go:183] Failed to fetch obj audit logs for gce-gpcstgesite01: failed to get authorization token for Grid Management  API: Post "https://objectstorage-grid-mgmt.gpc-system.svc.cluster.local/api/v3/authorize": dial tcp: lookup objectstorage-grid-mgmt.gpc-system.svc.cluster.local: no such host

Solusi: Patch deployment obs-system/log-remote-logger dengan perintah berikut:

kubectl --kubeconfig ${KUBECONFIG:?} patch deployment log-remote-logger -n obs-system -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirstWithHostNet"}}}}'

HaaS Logger menampilkan error di cluster admin root

Versi: 1.13.x

Gejala:

Di cluster admin root, deployment obs-system/log-remote-logger berisi beberapa error seperti berikut:

E0109 17:33:08.917876       1 manager.go:156] Failed to run logger haas: Failed to get log targets: failed to list harborinstances in the cluster: failed to get API group resources: unable to retrieve the complete list of server APIs: artifactregistry.gdc.goog/v1: the server could not find the requested resource

Solusi: Upgrade ke 1.13.8 untuk memperbaiki error. Atau, ubah deployment obs-system/log-remote-logger sebagai berikut:

Dalam argumen penampung remote-logger, perbarui tanda --disabled-loggers untuk menyertakan santricity dan HaaS:

YAML

args:
  - --disabled-loggers=santricity,haas

Santricity Logger gagal

Versi: 1.13.x

Gejala:

Di cluster admin root, deployment obs-system/log-remote-logger berisi beberapa error seperti berikut:

E0109 17:33:10.931737       1 manager.go:183] Failed to fetch santricity audit logs for lb-aa-objs01: failed to get CA cert: failed to get ClusterIssuer internal-root-ca-issuer: no kind is registered for the type v1.ClusterIssuer in scheme "pkg/logging/manager.go:32"

Solusi: Upgrade ke 1.13.8 untuk memperbaiki error.

Log Target Logging dikirim ke project yang salah

Versi: 1.13.x

Gejala: Log DaemonSet obs-system/oplogs-forwarder menampilkan peringatan yang mirip dengan berikut ini:

oplogs-forwarder-2xrfw [2025/01/16 21:02:09] [ warn] [output:loki:log_output_loki_dbs_fleet_system_dbs_fleet] Tenant ID is overwritten platform-obs -> infra-obs
oplogs-forwarder-kxf8p [2025/01/16 21:05:23] [ warn] [output:loki:log_output_loki_workbench_system_nws_lt] Tenant ID is overwritten infra-obs -> platform-obs

Peringatan ini menyebabkan log dirutekan ke project (ID tenant) yang salah. Masalah ini berasal dari bug yang diketahui di Fluent Bit. Untuk mengetahui informasi selengkapnya, lihat masalah Fluent Bit di GitHub.

Solusi: Upgrade ke 1.13.8 untuk memperbaiki error.

Log audit dari namespace platform tidak terlihat oleh PA

Versi: 1.13.x

Gejala: Log audit dari namespace platform terlihat oleh Operator Infrastruktur (IO), bukan Administrator Platform (PA).

Solusi: Tambahkan label observability.gdc.goog/auditlog-destination=pa secara manual ke namespace platform di semua cluster organisasi. Ikuti langkah-langkah berikut untuk menerapkan solusi manual ini:

  1. Tetapkan KUBECONFIG ke cluster target.

  2. Tambahkan label yang diperlukan ke namespace:

    KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform observability.gdc.goog/auditlog-destination=pa --overwrite

  3. Pastikan label berhasil ditambahkan:

    KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform --list

Pod gagal menginisialisasi container

Versi: 1.13.x

Gejala: Pod gagal dibuat dengan error yang mirip dengan berikut:

Events:
│   Type     Reason                  Age                     From     Message                                                                                                                                                 │
│   ----     ------                  ----                    ----     -------                                                                                                                                                 │
│   Warning  FailedCreatePodSandBox  10m (x2080 over 7h40m)  kubelet  Failed to create pod sandbox: mkdir /var/log/pods/org-1_managed-asm-local-readiness-xq75d_9a3275d7-5f16-4d67-8f4a-38fe0993be4a: no space left on device │

Error ini mencegah pod dimulai di node tertentu. Perilaku yang diamati muncul dari kasus ekstrem yang diketahui, yaitu file status logrotate-daemon menjadi terkunci, sehingga mencegah daemon melakukan rotasi file yang diharapkan. Untuk mengonfirmasi error ini, ikuti langkah-langkah berikut:

  1. Tetapkan KUBECONFIG ke cluster target.

  2. Identifikasi instance anthos-audit-logs-forwarder-xxxx yang dijadwalkan di node.

    KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

  3. Ambil log dari instance anthos-audit-logs-forwarder-xxxx yang dijadwalkan di node untuk memverifikasi.

    KUBECONFIG=${KUBECONFIG:?} kubectl logs -n obs-system anthos-audit-logs-forwarder-xxxx -c logrotate-daemon | grep "state file /var/lib/logrotate/status is already locked"

Solusi:

Lakukan langkah-langkah berikut untuk mengatasi masalah ini:

  1. Lakukan pemulihan ruang disk manual di direktori /var/log node.

  2. Tetapkan KUBECONFIG ke cluster target.

  3. Identifikasi node target di cluster.

    KUBECONFIG=${KUBECONFIG:?} kubectl get no -o wide

  4. Hubungkan ke node menggunakan SSH dan kosongkan ruang secara manual di direktori /var/log pada node. logrotate mengelola file di direktori ini.

    /var/log/audit/*/*/*/audit.log
/var/log/audit*/*/*.log
/var/log/auditproxy-*/*.log
/var/log/global-api-*/audit.log
/var/log/ceph/ceph.audit.log
/var/log/fanout/audit/*.log
/var/log/fanout/audit/*/*.log
/var/log/netflow/*.log
/var/log/fanout/operational/*.log
/var/log/fanout/operational/*/*.log

  5. Periksa file log yang berukuran sangat besar (lebih dari 100 MB) atau file yang lebih lama dari beberapa hari. Setelah memiliki file target, Anda dapat memangkas log sebagai berikut:

    truncate -s 1G <target_file>

  6. Identifikasi instance anthos-audit-logs-forwarder-xxxx yang dijadwalkan di node.

    KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

  7. Mulai ulang instance anthos-audit-logs-forwarder-xxxx yang dijadwalkan di node.

    KUBECONFIG=${KUBECONFIG:?} kubectl delete po -n obs-system anthos-audit-logs-forwarder-xxxx

Marketplace

Penarikan image Prisma Cloud gagal

Versi: 1.13.7

Gejala: Pembuatan instance layanan Prisma Cloud dari Marketplace gagal. Masalah ini disebabkan oleh tag gambar yang salah.

Solusi:

  1. Edit deployment twistlock-console untuk mengubah tag image:

    KUBECONFIG=${KUBECONFIG:?} kubectl edit deployment twistlock-console -n ${PROJECT:?}

  2. Temukan baris berikut:

    image: HARBOR_IP/library/twistlock/console:console_33_01_137

  3. Ganti console_33_01_137 dengan console_33.01.137:

    image: HARBOR_IP/library/twistlock/console:console_33.01.137

  4. Verifikasi bahwa pod berjalan dengan benar:

    KUBECONFIG=${KUBECONFIG:?} kubectl get pods -n ${PROJECT:?}

    Output-nya mungkin terlihat seperti contoh ini:

    NAME                                 READY   STATUS    RESTARTS   AGE
twistlock-console-58b578cbf4-5nvbk   1/1     Running   0          2m45s

Pemantauan

Sejumlah besar pemberitahuan dibuat di ServiceNow

Versi: 1.13.x

Gejala:

Setelah mengonfigurasi Monitoring untuk mengirim pemberitahuan ke ServiceNow menggunakan tugas berat MON-T0016 dan MON-T1016, sejumlah besar insiden akan otomatis dibuat di ServiceNow.

Masalah ini memiliki karakteristik berikut:

  • Semua insiden kosong.
  • Hanya cluster admin root dan organisasi gdchservices yang dapat mengirimkan pemberitahuan ke ServiceNow.

Solusi: Ikuti tugas berat MON-T0018 segera setelah menjalankan tugas berat MON-T0016 dan MON-T1016.

Beberapa pemberitahuan duplikat dibuat di ServiceNow

Versi: 1.13.x

Gejala:

Setelah mengonfigurasi Monitoring untuk mengirim pemberitahuan ke ServiceNow menggunakan tugas berat MON-T0016, MON-T1016, dan MON-T0018, beberapa pemberitahuan duplikat dibuat di ServiceNow.

Masalah ini memiliki karakteristik berikut:

  • Beberapa insiden duplikat dibuat untuk beberapa pemberitahuan meskipun setelah menerapkan tugas berat MON-T0018.

Solusi: Ikuti tugas berat MON-T0019 segera setelah menjalankan tugas berat MON-T0016, MON-T1016, dan MON-T0018.

Tidak dapat melihat metrik Vertex AI

Versi: 1.13.1

Gejala: Metrik tidak dikeluarkan oleh pod dvs-frontend-server.

Solusi: Versi 1.13.1 tidak mendukung metrik terenkripsi untuk layanan Vertex AI. Jika layanan Vertex AI tidak diaktifkan selama lebih dari satu jam, mulai ulang pod pengontrol mon-admin.

Error rekonsiliasi di mon-cortex

Versi: 1.13.1, 1.13.9

Gejala: Pod mon-cortex mengalami error rekonsiliasi. Dapatkan status pod mon-cortex:

kubectl get subcomponent mon-cortex -n gpu-org-1-system-cluster

Outputnya mungkin terlihat seperti ini:

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

Pesan seperti ini mungkin dicatat:

message: 'E0100 - deploy: failed to install chart: release mon-cortex-backend
        failed, and has been uninstalled due to atomic being set: context deadline
        exceeded'

Solusi:

  1. Periksa pod Cortex mana yang memberikan pesan seperti ini:

    Warning  FailedMount             11s   kubelet                  MountVolume.MountDevice failed for volume "pvc-0ad24fdc-52ec-4080-8ac0-5784989d1da3" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: could not open LUKS device; could not open LUKS device; could not open LUKS device; exit status 1

  2. Hapus PVC yang terkait dengan pod tersebut dan mulai ulang.

Pod metrics-server-exporter di cluster sistem mengalami error berulang

Versi: 1.13.1

Gejala: Pod metrics-server-exporter dalam cluster sistem mengalami loop error dengan OOMKilled, tetapi tampaknya tidak mencapai batasnya. Mendiagnosis error:

kubectl --kubeconfig $KUBECONFIG describe pod -n mon-system metrics-server-exporter-<id>

Outputnya mungkin terlihat seperti ini:

[...]
Containers:
  [...]
  otel-collector:
    Container ID:  containerd://3a1373de4880cde9e09aa9cacc109a8059ec29d9355aef1f03735fdcdcd45596
    Image:         gcr.io/private-cloud-staging/opentelemetry-collector:v0.93.0-gke.2
    Image ID:      gcr.io/private-cloud-staging/opentelemetry-collector@sha256:2b14f8fe936e725efca24dace1abcc26449d996b1480eab1b25d469a16aac221
    Port:          3113/TCP
    Host Port:     0/TCP
    Command:
      /otelcol
      --config=/conf/otel-collector-config.yaml
      --feature-gates=pkg.translator.prometheus.PermissiveLabelSanitization
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 20 Jun 2024 15:55:35 +0000
      Finished:     Thu, 20 Jun 2024 15:56:57 +0000
    Ready:          False
    Restart Count:  570
    Limits:
      cpu:     200m
      memory:  200Mi
    Requests:
      cpu:        100m
      memory:     100Mi
    Environment:  <none>

Solusi: Kurangi jumlah data yang ditayangkan di endpoint metrik dengan menghapus pod dan membiarkannya dimulai ulang. time-series lama yang disimpan dalam memori akan dihapus saat melakukan hal ini, sehingga mengurangi memori yang diperlukan.

Mengabaikan pesan error rekonsiliasi ObservabilityPipeline

Versi: 1.13

Gejala:

Objek ObservabilityPipeline menampilkan log Reconciler error seperti berikut di pod root-admin-controller:

{"msg":"Reconciler error","controller":"observabilitypipeline","ObservabilityPipeline":{"name":"default","namespace":"infra-obs"},"namespace":"infra-obs","name":"default","err":"unable to reconcile project level ObservabilityPipeline: 1 error occurred:\n\t* failed to get system cluster client to install per project overrides: root admin cluster has no system cluster\n\n"}

Solusi:

Abaikan log yang memenuhi semua kondisi berikut:

  • "controller":"observabilitypipeline"
  • "namespace":"infra-obs"
  • "name":"default"
  • "err" berisi failed to get system cluster client to install per project overrides: root admin cluster has no system cluster

Jika Anda men-debug pemberitahuan karena error rekonsiliasi yang tinggi, abaikan log ini karena merupakan negatif palsu.

ConfigMap mon-prober-backend-prometheus-config akan direset

Versi: 1.13.0 dan 1.13.1

Gejala:

  • Notifikasi MON-A0001 dipicu.

  • ConfigMap mon-prober-backend-prometheus-config direset agar tidak menyertakan tugas probe, misalnya:

    apiVersion: v1
data:
  prometheus.yaml: |
    remote_write:
    - url: http://cortex-tenant.mon-system.svc:9009/push
      name: cortex-tenant
kind: ConfigMap
metadata:
  creationTimestamp: "2024-06-26T14:55:07Z"
  name: mon-prober-backend-prometheus-config
  namespace: mon-system
  resourceVersion: "6606787"
  uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899

Solusi:

Ikuti langkah-langkah berikut untuk menyelesaikan masalah ini:

  1. Tetapkan variabel lingkungan berikut:

    • KUBECONFIG: jalur ke file kubeconfig di cluster.
    • TARGET_CLUSTER: nama cluster tempat Anda menyelesaikan masalah.

  2. Jeda subkomponen mon-prober di semua cluster:

    kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused=true

    Contoh:

    kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused=true

  3. Mulai ulang pengontrol administrator MON di setiap cluster admin:

    kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller

    Prober ConfigMap diisi saat setiap probe didaftarkan.

  4. Ikuti runbook MON-R2009 untuk menonaktifkan suara notifikasi MON-A0001, Blackbox monitoring metrics pipeline down, karena notifikasi ini akan terus muncul.

Komponen gateway toko Cortex mengalami loop error OOMKilled

Versi: 1.13.3

Gejala: Jika Anda melihat error di Grafana saat memuat metrik atau metrik tidak dimuat sama sekali, pod cortex-store-gateway mungkin mengalami loop error.

Untuk mendiagnosis pod cortex-store-gateway dan memeriksa apakah pod tersebut mengalami loop error, tinjau statusnya:

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG describe pod \
  -l app=cortex-store-gateway -n mon-system

Ganti SYSTEM_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig dari cluster sistem.

Jika pod mengalami loop error, outputnya akan terlihat seperti contoh berikut:

State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       OOMKilled
Exit Code:    137

Solusi: Tingkatkan batas memori cortex-store-gateway untuk sementara dengan menggunakan SubcomponentOverride. Untuk mengetahui detail tentang penerapan SubComponentOverride, lihat runbook MON-R2008.

Berikut adalah contoh SubcomponentOverride dengan batas memori yang ditentukan:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: mon-cortex-memory-bump
  namespace: org-1-system-cluster
spec:
  subComponentRef: 'mon-cortex'
  backend:
    operableParameters:
      storeGateway:
          resourcesLimit:
              memory: 16Gi

Biarkan penggantian tetap berlaku hingga semua podcortex-store-gateway memiliki status Ready dan pastikan subkomponen mon-cortex tidak dijeda:

  • Periksa apakah pod cortex-store-gateway memiliki status Ready:

    kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway

    Outputnya akan terlihat seperti contoh berikut jika semua pod memiliki status Ready:

    NAME                   READY   AGE
cortex-store-gateway   3/3     70d

    Kolom READY harus menampilkan nilai N/N agar semua pod siap. Jika tidak, nilai yang ditampilkan adalah 1/3 atau 2/3.

  • Pastikan subkomponen mon-cortex tidak dijeda di organisasi tertentu:

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused

    Ganti kode berikut:

    • ORG_ADMIN_KUBECONFIG: jalur ke file kubeconfig dari cluster admin org.
    • SYSTEM_CLUSTER: nama cluster sistem.

    Jika subkomponen dijeda, output akan menampilkan baris berikut:

    lcm.private.gdc.goog/paused: true

    Jika tidak, outputnya kosong.

Pencadangan penarikan image proxy metrik bidang kontrol Kube di cluster pengguna

Versi: 1.13.3

Gejala: Jika metrik yang terkait dengan kube-scheduler atau kube-controller-manager (misalnya, metrik scheduler_pending_pods dan workqueue_depth) tidak terlihat di Grafana, mungkin ada masalah penarikan kembali image dengan pod kube-control-plane-metrics-proxy.

Untuk mendiagnosis pod kube-control-plane-metrics-proxy dan memeriksa apakah pod tersebut mengalami masalah penarikan image yang tertunda, tinjau statusnya:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe pod \
  -l k8s-app=kube-control-plane-metrics-proxy -n obs-system

Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig dari cluster pengguna.

Jika pod memiliki masalah penarikan image yang berulang, outputnya akan terlihat seperti contoh berikut:

State:          Waiting
Reason:       ImagePullBackOff
Ready:          False
Restart Count:  0

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

  1. Tarik image gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 dari project Harbor gpc-system-container-images. Untuk mengetahui petunjuk dan izin yang diperlukan untuk menarik image, lihat Menarik image dengan Docker.

  2. Kirim image gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 ke project Harbor library. Untuk mengetahui petunjuk dan izin yang diperlukan untuk mengirim image, lihat Mengirim image.

    Project library digunakan untuk artefak yang akan di-deploy ke cluster pengguna.

Pertumbuhan WAL menyebabkan Prometheus menggunakan banyak memori

Versi: 1.13.3

Gejala: Node VM bidang kontrol sistem melaporkan peristiwa NodeHasInsufficientMemory dan EvictionThresholdMet:

kubectl describe node NODE_NAME | grep Events -A100

Outputnya mungkin terlihat seperti contoh berikut:

Events:
  Type     Reason                     Age                   From                   Message
  ----     ------                     ----                  ----                   -------
  Normal   NodeNotReady               12m (x8 over 10d)     node-controller        Node vm-e792c63a status is now: NodeNotReady
  Normal   NodeHasNoDiskPressure      12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID       12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasSufficientPID
  Normal   NodeReady                  12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeReady
  Normal   NodeHasInsufficientMemory  12m (x34 over 13h)    kubelet                Node vm-e792c63a status is now: NodeHasInsufficientMemory
  Warning  EvictionThresholdMet       12m (x64 over 13h)    kubelet                Attempting to reclaim memory
  Normal   TridentServiceDiscovery    11m (x21 over 13h)    csi.trident.netapp.io  [iSCSI] detected on host.
  Normal   NodeHasSufficientMemory    6m52s (x31 over 24d)  kubelet                Node vm-e792c63a status is now: NodeHasSufficientMemory

Prometheus menggunakan banyak memori karena pertumbuhan WAL (write-ahead log), yang memengaruhi memori node. Pertumbuhan WAL dapat terjadi karena Cortex tidak di-deploy, sehingga masalah ini mungkin merupakan konsekuensi dari Cortex yang tidak berfungsi. Instance Prometheus kehilangan konektivitas ke Cortex dalam waktu yang lama, yang selama itu instance tersebut melakukan buffering data dalam memori dan di volume persisten (PV). Saat dihentikan, Prometheus akan memuat semua data di WAL-nya ke dalam memori saat dimulai.

Penyebab utama lainnya mungkin adalah masalah konektivitas jaringan (mesh layanan, fisik, dan jaringan atas).

Solusi: Untuk memulihkan dari status ini, tindakan yang direkomendasikan adalah mengatasi penyebab utama dan membuat Cortex berfungsi dengan baik atau mengatasi masalah konektivitas jaringan. Kemudian, tunggu hingga WAL dari Prometheus selesai. Anda tidak akan kehilangan data, tetapi jika Cortex tidak berfungsi, node tidak akan tersedia selama periode waktu yang diperlukan Cortex untuk pulih.

Atau, Anda dapat menurunkan skala Prometheus STS menjadi nol dan menghapus PV. Tindakan ini mengurangi total waktu node tidak tersedia, tetapi mengakibatkan hilangnya data. Selain itu, selama Cortex tidak berfungsi atau Anda mengalami masalah konektivitas jaringan, Anda harus mengulangi tindakan ini secara berkala. Selama ada masalah koneksi antara Prometheus dan Cortex, PV akan terisi lagi.

Ikuti langkah-langkah berikut untuk menurunkan skala Prometheus STS menjadi nol dan menghapus PV:

  1. Turunkan skala komponen logmon-operator:

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 0

    Ganti ORG_SYSTEM_KUBECONFIG dengan jalur ke file kubeconfig di cluster sistem org.

  2. Turunkan skala komponen anthos-prometheus-k8s:

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale statefulset -n obs-system anthos-prometheus-k8s --replicas 0

  3. Hapus klaim volume persisten:

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG delete pvc -n obs-system anthos-prometheus-k8s-data-anthos-prometheus-k8s-0

  4. Tingkatkan kembali skala logmon-operator:

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 1

  5. Tunggu hingga anthos-prometheus-k8s siap.

Bootstrap multi-zona

Peran cluster tidak ada

Versi: 1.13.1

Gejala: Tidak ada peran khusus untuk bootstrapping multi-zona yang akan digunakan di Tambahkan peran yang diperlukan.

Solusi: Gunakan peran cluster cluster-admin seperti yang ditentukan dalam petunjuk tertaut. Hal ini memberi pengguna lebih dari akses minimum yang diperlukan untuk melakukan tugas selanjutnya.

Resource Bootstrap yang tidak kompatibel

Versi: 1.13.1

Gejala: Resource Bootstrap yang dibuat pada langkah 3 Buat file bootstrap tidak kompatibel dengan logika yang memprosesnya.

Solusi: Edit file YAML yang dihasilkan seperti yang ditentukan di langkah 4.

Resource GlobalAPIZone tidak dibuat di API global

Versi: 1.13.1

Gejala: Control plane tidak membuat resource GlobalAPIZone untuk zona di API global, sehingga komponen yang mengandalkan resource ini tidak berfungsi dengan baik.

Solusi: Buat resource seperti yang ditunjukkan dalam Membuat resource GlobalAPIZone.

Jaringan

Jaringan Grid Node Penyimpanan Objek tidak berfungsi

Versi: 1.13.1, 1.13.3, 1.13.4

Gejala:

  1. Selama fase bootstrap penyimpanan objek, jaringan grid ditampilkan sebagai tidak aktif dari UI penginstal node Admin OBJ.
  2. cables.csv dan Cell CR menunjukkan bahwa nilai MPN di cables.csv adalah QSFP-100G-CU2.5M untuk koneksi antara node objsadmin penyimpanan objek dan TOR Switch.

Penjelasan Di 1.13, kolom MPN di cables.csv digunakan untuk menentukan kecepatan yang ditetapkan pada switch Tor. Jika kecepatan tidak disetel di port ini, peralihan tor ke konektivitas node objsadmin akan gagal. Daftar yang digunakan untuk memetakan MPN ke kecepatan tidak memperhitungkan nilai yang diberikan oleh integrator sistem, sehingga menyebabkan bootstrap penyimpanan objek gagal. Pada sebagian besar penyiapan 1.13, vendor yang digunakan adalah: QSFP-100G-CU2.5M.

Solusi:

  1. Gunakan kubectl get -A cell -oyaml di cluster root-admin untuk menemukan koneksi yang terkait dengan TOR switch dan appliance penyimpanan objek.
  2. Ubah semua kemunculan mpn menjadi "QSFP-100G-CU3M" untuk objsadm -> torsw connect.

Berikut contohnya:

    - endA: "ap-aa-torsw01:Eth1/10"
      endB: "ap-aa-objsadm01:e3a"
      cableType: "DAC"
      mpn: "QSFP-100G-CU3M"
      length: "2m"
      color: "Black"

Node tidak dapat dijangkau

Versi: 1.13.1, 1.13.3, 1.13.4

Gejala:

  1. Selama fase bootstrapping jaringan beberapa switch tidak dapat dijangkau.
  2. Selama fase penginstalan DHCP, beberapa server tidak dapat dijangkau melalui alamat IP iLO-nya.

Solusi:

  1. Muat ulang tombol pengelolaan yang terpengaruh. Lihat runbook PNET-R0018 untuk mengetahui detailnya.

PodCIDR tidak ditetapkan ke node meskipun ClusterCIDRConfig dibuat

Versi: 1.13.1

Gejala: ClusterCIDRConfig adalah objek yang diperlukan untuk menetapkan PodCIDRs. Meskipun ClusterCIDRConfig dibuat, PodCIDRs tidak ditetapkan. Masalah ini terjadi jika ClusterCIDRConfig dibuat pada saat yang sama dengan saat pod ipam-controller melakukan bootstrapping. Pembuatan cluster macet dalam status menyelaraskan.

  1. Periksa apakah objek ClusterCIDRConfig dibuat di cluster:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

    Outputnya mungkin terlihat seperti ini:

    apiVersion: v1
items:
- apiVersion: networking.gke.io/v1alpha1
  kind: ClusterCIDRConfig
  metadata:
    annotations:
      baremetal.cluster.gke.io/managed: "true"
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.gke.io/v1alpha1","kind":"ClusterCIDRConfig","metadata":{"annotations":{"baremetal.cluster.gke.io/managed":"true"},"creationTimestamp":null,"name":"root-admin-control-plane"},"spec":{"ipv4":{"cidr":"172.24.0.0/21","perNodeMaskSize":23},"ipv6":{"cidr":"fd00:1::2:0/112","perNodeMaskSize":119}},"status":{}}
    creationTimestamp: "2024-06-17T05:27:55Z"
    finalizers:
    - networking.kubernetes.io/cluster-cidr-config-finalizer
    generation: 1
    name: root-admin-control-plane
    resourceVersion: "2172"
    uid: d1216fe3-04ed-4356-a105-170d72d56c90
  spec:
    ipv4:
      cidr: 172.24.0.0/21
      perNodeMaskSize: 23
    ipv6:
      cidr: fd00:1::2:0/112
      perNodeMaskSize: 119
kind: List
metadata:
  resourceVersion: ""

  2. Jalankan describe untuk salah satu objek node cluster yang macet dalam proses rekonsiliasi dan periksa apakah ada peristiwa CIDRNotAvailable pada objek node:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

    Peristiwa output mungkin terlihat seperti ini:

      Type     Reason            Age                   From             Message
  ----     ------            ----                  ----             -------
  Normal   CIDRNotAvailable  3m22s (x96 over 21h)  cidrAllocator    Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable
  Warning  ReconcileError    3m22s (x96 over 21h)  ipam-controller  CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs

Solusi:

  1. Mulai ulang pod ipam-controller-manager:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager

  2. Setelah pod ipam-controller-manager dalam status berjalan, periksa apakah podCIDR ditetapkan ke node:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR

    Outputnya mungkin terlihat seperti ini:

    podCIDR: 172.24.4.0/23
podCIDRs:
podCIDR: 172.24.2.0/23
podCIDRs:
podCIDR: 172.24.0.0/23
podCIDRs:

Penyimpangan NTP

Versi: 1.13.1

Gejala: Node VM mengalami penyimpangan atau waktu yang tidak akurat setelah dalam mode tidur atau berjalan selama beberapa waktu.

Solusi:

  1. Buat koneksi SSH ke node VM dan edit file /etc/chrony.conf.
  2. Ganti baris makestep 1.0 3 dengan makestep 1.0 -1.

  3. Mulai ulang layanan chronyd:

    systemctl restart chronyd

Anda hanya perlu melakukan perubahan ini satu kali untuk setiap VM. Perubahan tidak akan ditimpa.

Untuk perbaikan cepat langsung yang lebih cepat untuk melompati waktu, buat koneksi SSH ke node VM dan jalankan chronyc -a makestep.

Log audit SyncServer tidak diuraikan

Versi: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Gejala: Log audit dari SyncServer tidak diuraikan dengan benar oleh log-remote-logger. Beberapa log audit tidak akan tersedia di grafana dan Anda mungkin melihat pesan error di pod root-admin log-remote-logger seperti:

Failed to fetch syncserver audit logs for syncserver-...

Solusi: Log audit masih tersedia di SyncServer. Ikuti NTP-P0002 untuk mengakses UI SyncServer dan melihat log di bagian Logs > Events.

Gagal mengekstrak gambar saat mengganti gambar

Versi: 1.13.3

Gejala: Anda mungkin melihat pesan seperti ini pada objek SwitchImageHostRequest saat melakukan RMA Pengalihan atau saat mem-bootstrap cluster root-admin:

failed to pull or extract image "192.0.2.0:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004

Jika Anda memiliki akses kubectl, gunakan akses tersebut untuk memverifikasi apakah Anda mengalami masalah ini:

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system get switchimagehostrequest -o yaml

Outputnya mungkin terlihat seperti contoh berikut:

kind: SwitchImageHostRequest
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    meta.helm.sh/release-name: pnet-core-assets
    meta.helm.sh/release-namespace: pnet-system
  creationTimestamp: "2024-08-20T04:16:36Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: v1.13.0-pnet-aa505d9004
  namespace: gpc-system
  resourceVersion: "149295"
  uid: f6c5b880-3fdb-4679-acd4-840b52998946
spec:
  fromVersion: v1.13.0-pnet-aa505d9004
  toVersion: v1.13.0-pnet-aa505d9004
status:
  conditions:
  - lastTransitionTime: "2024-08-20T05:10:17Z"
    message: ""
    observedGeneration: 1
    reason: TFTPRunning
    status: "True"
    type: TFTPReady
  - lastTransitionTime: "2024-08-20T04:16:36Z"
    message: 'exception: failed to pull images with config images: [{10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004
      /shared/tftpboot/switch/images}]: failed to pull or extract image "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      failed to pull image from source "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      GET https://10.249.48.5:10443/v2/gdch-switch/os/manifests/v1.13.0-pnet-aa505d9004:
      NOT_FOUND: artifact gdch-switch/os:v1.13.0-pnet-aa505d9004 not found'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: Unknown
    type: Ready

Solusi:

Buat SwitchImageHostRequest secara manual dengan tag gambar yang benar:

  1. Login ke server bootstrapper.

  2. Gunakan gdcloud untuk mengidentifikasi versi gambar peralihan yang benar:

    release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch

    Outputnya mungkin terlihat seperti contoh berikut:

    │   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385

    Dari output ini, versi gambar tombol yang benar adalah 1.13.3-gdch.5385.

  3. Edit objek SwitchImageHostRequest yang melaporkan error:

    kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system edit switchimagehostrequest <SWITCH_IMAGE_HOST_REQUEST_NAME>

  4. Edit atau ganti kolom name, fromVersion, dan toVersion agar sesuai dengan versi gambar peralihan yang diharapkan. Dalam hal ini, nilainya adalah 1.13.3-gdch.5385. Lihat output diff berikut, yang menggambarkan perubahan yang harus dilakukan pada objek SwitchImageHostRequest.

    kind: SwitchImageHostRequest
metadata:
- name: v1.13.0-pnet-aa505d9004
+ name: 1.13.3-gdch.5385
  namespace: gpc-system
spec:
- fromVersion: v1.13.0-pnet-aa505d9004
+ fromVersion: 1.13.3-gdch.5385
- toVersion: v1.13.0-pnet-aa505d9004
+ toVersion: 1.13.3-gdch.5385

Komunikasi pod StatefulSet gagal

Versi: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9, 1.13.10

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

Masalah konektivitas ke instance DBS

Versi: 1.13.0, 1.13.1

Gejala: Instance Layanan Database (DBS) tidak dapat diakses dengan klien database yang menunjukkan waktu tunggu koneksi habis.

Masalah ini dapat muncul melalui komponen sistem lain yang mengandalkan DBS. Misalnya, Penagihan dapat melaporkan pesan error seperti berikut:

DBSE0301: Healthcheck: DB cluster is not healthy. Cannot connect to DBdaemon
DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context
deadline exceeded

Solusi: Kegagalan disebabkan oleh komponen sistem jaringan yang tidak dapat menjadwalkan di cluster layanan organisasi.

  1. Tetapkan variabel lingkungan berikut:

    export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME

    Ganti kode berikut:

    • KUBECONFIG_PATH: jalur ke file kubeconfig cluster admin org.
    • ORG_NAME: nama organisasi Anda, seperti org-1.

  2. Perbarui konfigurasi komponen jaringan agar dapat dijadwalkan:

    kubectl --kubeconfig=KUBECONFIG_PATH kubectl -n g-ORG_NAME-shared-service-cluster   patch addonconfiguration ang-overrides   --type='json'   -p='[{"op": "replace", "path": "/spec/configs/1/patchContent", "value": "apiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n  name: ang-node\n  namespace: kube-system\nspec:\n  template:\n    spec:\n      containers:\n      - name: angd\n      - name: bgpd\n        env:\n        - name: DISABLE_RECEIVED_ROUTES\n          value: \"true\"\n      tolerations:\n      - operator: \"Exists\"\n        effect: \"NoSchedule\""}]'

Konektivitas jaringan dipulihkan setelah beberapa menit.

Mesh cluster tidak dikonfigurasi dengan informasi zona

Versi: 1.13.5

Gejala: VM tidak dapat terhubung ke cluster database dalam project yang sama. Konektivitas ke load balancer internal terpengaruh. Masalah ini disebabkan oleh Clustermesh yang gagal menukar objek layanan di seluruh cluster karena tidak adanya informasi zona dalam konfigurasi nama cluster.

Solusi: Di lingkungan yang di-bootstrap sebagai multizona, lakukan langkah-langkah solusi manual berikut agar load balancer internal berfungsi:

  1. Di cluster admin org, dapatkan nama zona:

    ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME

    Output-nya mungkin terlihat seperti contoh ini:

    zone1

  2. Di cluster admin org, dapatkan ID situs zona:

    SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID

    Output-nya mungkin terlihat seperti contoh ini:

    1

  3. Mencantumkan semua cluster:

    ​​kubectl get clusters -A

    Output-nya mungkin terlihat seperti contoh ini:

    NAMESPACE                        NAME                     ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
g-org-1-shared-service-cluster   g-org-1-shared-service   1.30.0-gke.1592    1.30.0-gke.1592       Running
org-1-system-cluster             org-1-system             1.30.0-gke.1592    1.30.0-gke.1592       Running
user-vm-1-cluster                user-vm-1                1.16.11            1.16.11               Running
user-vm-2-cluster                user-vm-2                1.28.700-gke.150   1.28.700-gke.150      Running

  4. Untuk setiap cluster, buat CILIUM_CLUSTERNAME:

    CLUSTER_NAME=CLUSTER_NAME
CILIUM_CLUSTERNAME=$CLUSTERNAME-zone$SITEID
echo $CILIUM_CLUSTERNAME

    Output-nya mungkin terlihat seperti contoh ini:

    org-1-system-zone1

  5. Untuk setiap cluster, tetapkan parameter lainnya sebagai berikut. Contoh berikut untuk org-1-system:

    CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592

  6. Untuk setiap cluster, buat objek AddOnConfiguration dan simpan di file addonconfig.yaml. Buat file ini untuk semua cluster yang ada dan cluster baru yang Anda buat di masa mendatang:

    Di halaman ini, tetapkan variabel berikut untuk memperbarui contoh kode berikut:

    CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

    apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: AddOnConfiguration
metadata:
  name: cilium-addon
  namespace: CLUSTER_NAMESPACE
spec:
  anthosBareMetalVersions:
  - CLUSTER_VERSION
  configs:
  - name: cilium-config
    namespace: kube-system
    apiVersion: v1
    kind: ConfigMap
    patchContent: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cilium-config
        namespace: kube-system
      data:
        cluster-name: CILIUM_CLUSTERNAME

  7. Terapkan addonconfig.yaml di cluster admin org:

    kubectl apply -f addonconfig.yaml

  8. Di cluster sistem, layanan, dan pengguna, pastikan cluster-name diperbarui di cilium-config pada cluster. Proses ini mungkin memerlukan waktu beberapa saat untuk diperbarui, tetapi langkah ini diperlukan sebelum memulai ulang deployment clustermesh-apiserver.

    kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo

  9. Di cluster sistem, layanan, dan pengguna, mulai ulang deployment clustermesh-apiserver:

    kubectl rollout restart deployment -n kube-system clustermesh-apiserver

Alamat IP EVPN yang salah dibuat

Versi: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Gejala: Alamat IP peering sesi interkoneksi EVPN multi-zona (MZ) yang dibuat oleh Sistem Pengelolaan Aset Hardware (HAMS) tidak diakhiri dengan .65 atau .66, yang salah dan menghentikan sesi BGP EVPN MZ agar tidak dibuat.

Solusi:

Untuk mengatasi masalah ini secara manual, ikuti langkah-langkah berikut:

  1. Mencantumkan semua resource InterconnectSession:

    kubectl get interconnectsession -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig | grep zoneevpnpeering

  2. Tinjau resource InterconnectSession multi-zona EVPN yang dihasilkan yang memiliki nilai interconnectType ZonePeering dan addressFamily EVPN:

    apiVersion: system.private.gdc.goog/v1alpha1
kind: InterconnectSession
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
  creationTimestamp: null
  name: interconnect-session-am-aa-blsw01-zoneevpnpeering-3
  namespace: gpc-system
  labels:
    system.private.gdc.goog/ipv4-session-name-1: interconnect-session-am-aa-blsw01-zoneipv4peering-3
spec:
  interconnectLinkRef:
    name: interconnect-am-aa-blsw01-zoneevpnpeering-3
    namespace: gpc-system
  interconnectType: ZonePeering
  peerIP: 192.168.203.67
  md5HashKey: ""
  peerASN: 65402
  addressFamily: EVPN
status: {}

  3. Untuk setiap resource InterconnectSession yang cocok dengan parameter ini, terapkan perbaikan berikut:

    1. Periksa nama resource kustom sesi interkoneksi.
    2. Jika nama diakhiri dengan angka ganjil, perbarui bagian terakhir alamat IP peer menjadi 65 menggunakan perintah di langkah berikutnya.
    3. Jika nama diakhiri dengan angka genap, perbarui bagian terakhir alamat IP peer menjadi 66 menggunakan perintah di langkah berikutnya.

  4. Ubah resource InterconnectSession dengan alamat IP peer yang salah:

    kubectl edit interconnectsession
interconnect-session-zy-aa-blsw01-zoneevpnpeering-1 -n gpc-system
--kubeconfig=/root/release/root-admin/root-admin-kubeconfig

  5. Terapkan perbaikan ini ke semua resource InterconnectSession yang menyebabkan error.

Dasbor bidang kontrol Upper Networking tidak menampilkan data

Versi: 1.13.7

Gejala: Kueri Prometheus di TestUpperNetworkingMetrics gagal karena metrik tidak ada di cluster org-1-system. Panel clustermesh di dasbor bidang kontrol Jaringan Atas untuk Admin Org IO tidak menampilkan data. Masalah ini berasal dari ketidakcocokan label source_cluster antara Cilium dan sistem pemantauan.

Solusi: Hapus filter source_cluster dari dasbor bidang kontrol UNET untuk menampilkan data.

Error pengalihan yang ditampilkan saat penginstalan jaringan

Versi: 1.13.1

Gejala: Selama penginstalan jaringan, beberapa pesan peringatan kabel ditampilkan. Contoh:

  W0725 18:01:19.127111   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/46<>la-ac-base03:ilo: no speed associated with cable model: 31342 (CAT6 5ft Black)
  W0725 18:01:19.127127   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/33<>la-ac-bm21:LOM1: no speed associated with cable model: 03982 (CAT6 4ft Black)

Pesan error ini dapat diabaikan dengan aman.

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

Penyimpanan objek

Tidak dapat menghapus organisasi penyimpanan

Versi: 1.13.1

Gejala: Penghapusan organisasi mungkin tidak berhasil karena masalah yang mencegah penghapusan SVM selesai. Anda mungkin melihat peringatan seperti ini:

Warning StorageOrganizationDeletion 49m (x97
over 23h) StorageOrganization Reconcile error for storage org
deletion: cannot delete storage organization resources, pre-checks failed:
subnet claim "poc2/poc2-admin-svm-mgmt-network-subnet" exists,
cannot continue before it is deleted

Beberapa peringatan upgrade penyimpanan objek dapat diabaikan

Versi: 1.13.3

Gejala: Saat mengupgrade penyimpanan objek, Anda mungkin melihat peringatan seperti ini:

Type     Reason          Age                From                              Message
  ----     ------          ----               ----                              -------
  Warning  ReconcileError  55m (x2 over 55m)  ObjectStorageAdminNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked

Solusi:

  1. Pastikan setiap node memiliki kredensial SSH yang sesuai dan disimpan dalam secret.

    1. Periksa node admin:

      kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

    2. Periksa node penyimpanan:

      kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

      Output yang berhasil akan terlihat seperti contoh berikut untuk node penyimpanan:

      NAME                                      TYPE     DATA   AGE
gpcstgecn01-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn02-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn03-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h

      Jika secret tidak ditemukan, error akan terlihat seperti ini:

      Error from server (NotFound): secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found

  2. Jika perintah tidak menampilkan error apa pun, Anda dapat mengabaikan error yang dilaporkan oleh rekonsiliator dengan aman.

ObjectStorageStorageNodeReconciler laporan maintenance.gdu.gdu_server_locked

Versi: 1.13.3

Gejala: Menampilkan detail objectstoragestoragenode:

kubectl describe objectstoragestoragenode zv-aa-objs02

Outputnya mungkin terlihat seperti contoh berikut:

Events:
  Type     Reason          Age                    From                                Message
  ----     ------          ----                   ----                                -------
  Warning  ReconcileError  54m (x2 over 54m)      ObjectStorageStorageNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked"}

Solusi: Masalah ini dapat diabaikan. Layanan GDU mungkin terkunci sementara jika menerima terlalu banyak permintaan, tetapi layanan akan dibuka setelah beberapa menit.

Pemeriksaan upgrade Object Storage pasca-penerbangan 1.12.x -> 1.13.x gagal

Versi: 1.13.x

Gejala: CR ObjectStorageUpgrade gagal dengan error

Message:               check "ObjectStorageUpgrade" of operable component "OBJ" failed with reason "BackoffLimitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-objectstorageupgrade] 
Observed Generation:   2
Reason:                PostflightCheckFailed

Pod gpc-system/upgrade-managed-check-objectstorageupgrade gagal dengan error

Error: check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                                                      │
  Usage:                                                                                                                                                                         │
    managed [flags]                                                                                                                                                              │
  Flags:                                                                                                                                                                         │
        --component_name string              preflight check name                                                                                                                │
        --current_version string             current version of the Organization                                                                                                 │
    -h, --help                               help for managed                                                                                                                    │
        --organization-upgrade-name string   the name of current OrganizationUpgrade                                                                                             │
        --target_version string              target version of the Organization                                                                                                  │
  F1023 06:18:01.122723       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                   │
  goroutine 1 [running]:

Penyebab utama: Mengupgrade Komponen Operasional Object Storage dari 1.12.x ke 1.13.x gagal jika cluster KIND bootstrapping belum dinonaktifkan atau dihapus. Meskipun upgrade berhasil, layanan penyimpanan objek umum, seperti membuat bucket baru atau kredensial S3 melalui RBAC Kubernetes, mungkin gagal karena error validasi sertifikat TLS. Hal ini karena pod penyimpanan objek tertentu dalam cluster KIND terus mencoba menginstal sertifikat server TLS endpoint pengelolaan StorageGRID, yang valid di 1.12.x, tetapi mungkin tidak dikenali di 1.13.x. Selama upgrade, StorageGRID menginstal sertifikat server TLS baru yang dapat diverifikasi, tetapi pod cluster KIND menggantinya dengan sertifikat lama yang tidak valid, sehingga menyebabkan error sertifikat TLS.

Solusi: Persyaratan berikut harus benar:

  • Upgrade Object Storage dari 1.12.x ke 1.13.x
  • Cluster bootstrapping (cluster KIND) masih ada

Ikuti langkah-langkah berikut:

  1. Dapatkan kubeconfig yang memiliki izin lihat dan ubah ke resource ObjectStorageSite di cluster bootstrapping (cluster KIND).

  2. Tetapkan alias ke kubectl yang terhubung ke cluster bootstrapping (cluster KIND):

    alias kubectlkind="kubectl --kubeconfig <Full path to the kubeconfig of the bootstrapping cluster>

  3. Dapatkan instance resource kustom ObjectStorageSite dari cluster bootstraper. Harus ada satu instance resource ObjectStorageSite:

    SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')

  4. Tambahkan anotasi jeda penyimpanan objek ke instance resource ObjectStorageSite:

    kubectlkind annotate ObjectStorageSite "${SITENAME:?}" storagegrid.netapp.storage.private.gdc.goog/paused=true

  5. Verifikasi bahwa anotasi jeda penyimpanan objek telah ditambahkan ke instance ObjectStorageSite:

    kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq

  6. Dapatkan kubeconfig yang memiliki akses lihat dan izin patch status ke resource ObjectStorageCluster di cluster admin root.

  7. Tetapkan alias ke kubectl yang terhubung ke cluster admin root:

    alias kubectlrootadmin="kubectl --kubeconfig <Full path to the kubeconfig of the root admin >"

  8. Periksa apakah ada instance resource ObjectStorageCluster di cluster admin root:

    kubectlrootadmin get ObjectStorageCluster

    Jika tidak ada instance resource ObjectStorageCluster, solusi telah selesai. Anda mungkin perlu melakukan prosedur upgrade Object Storage lagi.

  9. Dapatkan URL endpoint pengelolaan dari status resource ObjectStorageSite di cluster bootstrapping:

    MGMT_ENDPOINT=$(kubectlkind get ObjectStorageSite -o jsonpath='{.items[0].status.managementAPIEndpointURL}')

  10. Validasi apakah variabel lingkungan $MGMT_ENDPOINT telah ditetapkan. Endpoint harus dimulai dengan https://:

    echo ${MGMT_ENDPOINT:?}

  11. Lakukan langkah-langkah yang tersisa hanya jika ada tepat satu instance resource ObjectStorageCluster di cluster admin root. Jika tidak, lakukan prosedur upgrade Object Storage lagi:

    kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"

  12. Mulai ulang pod gpc-system/obj-infra-cluster-cm:

    kubectlrootadmin rollout restart deployment -n gpc-system obj-infra-cluster-cm-backend-controller

  13. Verifikasi apakah endpoint pengelolaan telah ditambahkan ke status resource ObjectStorageCluster:

    kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq

  14. Mulai ulang pemeriksaan postlight dengan menghapus tugas Kubernetes pemeriksaan postflight gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>. Tugas akan segera dibuat ulang.

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

    Masa berlaku sertifikat endpoint load balancer StorageGRID telah habis

Versi: 1.13.10, 1.13.11, 1.13.12

Gejala: Proxy penyimpanan objek melaporkan 502 Bad Gateway.

Solusi: Ikuti OBJ T0003.

Sistem operasi

Pod macet dalam status init

Versi: 1.13.1

Gejala: Node melaporkan siap, tetapi akses SSH ke node lambat dan dan top -n 1 menunjukkan > 100 proses zombie.

Solusi:

  1. Ikuti OS-P0001 untuk menguras server. Pengurasan daya mungkin memerlukan waktu lebih dari 20 menit. Jika pengurasan tidak berhasil setelah satu jam, lanjutkan ke langkah berikutnya.

  2. Mulai ulang server dengan membuat koneksi SSH ke server dan mengeluarkan perintah berikut:

    systemctl reboot

  3. Mungkin diperlukan mulai ulang kedua untuk memulihkan server sepenuhnya.

  4. Verifikasi bahwa akses SSH tidak lagi lambat dan jumlah proses zombie jauh lebih rendah, sebaiknya kurang dari 30.

  5. Keluarkan server dari mode hemat daya dengan menyetel maintenance ke false di server.

bm-system-machine-preflight-check Tugas Ansible untuk node bare metal atau VM gagal

Versi: 1.13.1

Gejala: Modul kernel nf_tables tidak dimuat setelah dimulai ulang, sehingga menyebabkan tugas Ansible cluster gagal dengan error Either ip_tables or nf_tables kernel module must be loaded. Masalah ini terjadi saat node bare metal atau VM di-reboot sebelum disediakan sepenuhnya. Pekerjaan Ansible mungkin menampilkan error seperti ini:

fatal: [172.20.128.23]: FAILED! => {"changed": false, "msg": "following are the error messages for each failed preflight check {'check_netw
orking_kernel_module_pass': 'Either ip_tables or nf_tables kernel module must be loaded. Use the command \"modprobe <ip_tables OR nf_tables
>\" to load the module.'}"}

Solusi:

Buat koneksi SSH ke node dan jalankan perintah berikut:

modprobe nf_tables

VM tanpa ruang penyimpanan yang tersisa di perangkat

Versi: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Gejala: Jika direktori log /var/log penuh, Node mungkin macet pada status NotReady dan Pod mungkin gagal dimulai karena error no space left on device. Untuk memeriksanya, jalankan perintah berikut di node dan periksa apakah penggunaannya sekitar 100%.

df -h /var/log
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--var_log   15G   15G   20K 100% /var/log

Solusi:

  1. Login ke node yang mengalami masalah dan bersihkan arsip log lama untuk /var/log/messages.

    find /var/log -name "messages*" -mtime +4 -delete

    Sebaiknya terus terapkan solusi sementara berikut untuk mencegahnya terjadi. Solusinya adalah membuat AnsiblePlaybook dan menerapkan perubahan melalui CR OSPolicy kustom yang bertanggung jawab untuk mengonfigurasi OS target dengan aman (mesin BM+VM). Lihat proses OS-P0005 untuk mengetahui detail selengkapnya.

  2. Tetapkan variabel lingkungan berikut:

    export KUBECONFIG=<the path to the kubeconfig file>

  3. Buat playbook Ansible untuk solusi sementara:

    kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
  name: update-logrotate
  namespace: gpc-system
spec:
  playbook: |
    - name: Set the default context for the /etc/kubernetes path to etc_t
      hosts: all
      gather_facts: no
      tasks:
        - name: Change log rotation for /var/log/messages
          block:
            - name: Check if /etc/logrotate.d/syslog exists
              check_mode: false
              ansible.builtin.stat:
                path: '/etc/logrotate.d/syslog'
              register: syslog_exists
            - name: Comment out /var/log/messages lines in syslog
              ansible.builtin.replace:
                path: '/etc/logrotate.d/syslog'
                regexp: '^/var/log/messages'
                replace: '# /var/log/messages'
              when: syslog_exists.stat.exists
            - name: Change logrotate config for /var/log/messages
              ansible.builtin.blockinfile:
                path: '/etc/logrotate.d/syslog'
                block: |
                  /var/log/messages
                  {
                      daily
                      rotate 4
                      missingok
                      notifempty
                      sharedscripts
                      postrotate
                          /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
                      endscript
                  }
              when: syslog_exists.stat.exists
EOF

  4. Identifikasi inventaris target yang perlu menerapkan perubahan, targetnya bisa berupa InventoryMachine individual atau NodePool. Lihat proses OS-P0005 (2. Identifikasi inventaris target untuk konfigurasi runtime) untuk mengetahui detailnya.

    Contoh OSPolicy berikut menyertakan dua inventaris target di bagian spec.inventory, Anda dapat menambahkan lebih banyak inventaris sesuai kebutuhan.

    kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
  name: manual-update-logrotate
  namespace: gpc-system
spec:
  inventory:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: org-1-system-cluster
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: user-vm-1-cluster
  policy:
    installPlaybook:
      name: update-logrotate
EOF

  5. Validasi

    Lihat proses OS-P0005 (validasi) untuk melacak status eksekusi kebijakan.

Pod macet dalam status ContainerCreating

Versi: 1.13.3, 1.13.5, 1.13.6

Gejala: Node ditampilkan sebagai sehat, tetapi memiliki banyak pod yang macet dalam status ContainerCreating dan Anda tidak dapat membuat koneksi SSH ke server.

Solusi: Lakukan siklus daya pada server dan pastikan Anda dapat membuat koneksi SSH ke node saat server kembali aktif.

Tidak dapat menjalankan SSH ke node yang disediakan

Versi: 1.13.5

Gejala: Node disediakan, tetapi SSH mengalami waktu tunggu habis di IP pengelolaan dan data.

Solusi sementara: Mulai ulang node melalui iLO. Setelah melakukan booting, gunakan SSH untuk login dan nonaktifkan clamonacc dengan systemctl stop clamonacc; systemctl disable clamonacc.

Node Bare Metal gagal di-booting dari image OS terbaru karena booting aman tidak mengenali tanda tangan OS

Versi: 1.13.12

Gejala: Setelah mengupgrade ke versi 1.13.12, jika node di-reboot, OS gagal melakukan booting ke kernel baru. Layar konsol iLO menampilkan masalah terkait boot aman:

../../grub-core/loader/i386/efi/linux.c:385:(hd0,gpt2)/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64 has invalid signature,..:
 ../../grub-core/loader/i386/efi/linux.c:256: you need to load the kernel first.

Solusi:

  1. Untuk setiap node yang gagal di-boot karena masalah ini, buka layar GRUB melalui konsol iLO, lalu pilih Rocky Linux 4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64 sebagai target boot. Prosedur ini membuat node melakukan booting ke kernel baik yang diketahui sebelumnya.

  2. Untuk semua server bare metal yang diupgrade ke versi GDC 1.13.12, lakukan langkah-langkah berikut untuk mencegah kegagalan booting:

    1. Buat koneksi SSH ke server.
    2. Jalankan perintah berikut di server untuk menghapus kernel yang bermasalah:
    dnf remove kernel-core-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64
    1. Pastikan kernel default berhasil disetel kembali ke versi yang berfungsi dengan baik:
    grubby --default-kernel

Hasilnya adalah /boot/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64.

Infrastruktur Operations Suite (OI)

SSA tidak diperlukan untuk Hardware 3.0

Konfigurasi adaptor RAID berbeda untuk Hardware 3.0. Server OIC Hardware 3.0 menggunakan drive yang dienkripsi sendiri, sehingga peluncuran Administrasi Penyimpanan Cerdas (SSA) tidak lagi diperlukan. Diperlukan langkah-langkah tambahan untuk menentukan ID disk berdasarkan per server. Lihat bootstrap server OI.

Keamanan perimeter

Cluster sistem org macet selama bootstrap org

Versi: 1.13.1

Gejala: Selama bootstrap organisasi, cluster sistem org mungkin macet. Pod edr-sidecar-injector dalam status tertunda. Saat mencoba menghapus pod ini, Anda mungkin melihat pesan error seperti ini:

Delete failed with `Internal error occurred: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/"

Pada saat yang sama, beberapa pod yang tertunda lainnya mungkin memiliki pesan error seperti ini:

Error creating: Internal error occurred: failed calling webhook "edr-sidecar-injector.gpc-system.internal": failed to call webhook: Post "https://edr-sidecar-injector.gpc-system.svc:443/mutate?timeout=10s": dial tcp 172.20.3.222:443: connect: connection refused

Sistem memerlukan intervensi manual untuk membuka kuncinya.

Solusi:

  1. Buat duplikat MutatingWebhookConfiguration CR edr-sidecar-injector-webhook-cfg di cluster sistem.
  2. Buat duplikat ValidatingWebhookConfiguration CR gatekeeper-validating-webhook-configuration di cluster sistem.
  3. Hapus CR edr-sidecar-injector-webhook-cfg dan CR gatekeeper-validating-webhook-configuration dari cluster sistem.
  4. Tunggu hingga pod edr-sidecar-injector dan gatekeeper-controller-manager kembali aktif.
  5. Pulihkan CR webhook dengan perintah kubectl apply.

Grup alamat firewall PANW tidak diperbarui dengan perubahan klaim CIDR

Versi: 1.13.1

Gejala: Selama bootstrap, OCIT cidr-claim diperbarui dengan nilai yang benar, tetapi firewall AddressGroups tidak. Pasangan AddressGroups, khususnya vsys1-root-ocit-network-cidr-group dan ocvsys1-root-ocit-network-cidr-group, menggunakan blok jaringan yang tidak tumpang-tindih dengan yang sebenarnya digunakan di OIR. OIR tidak dapat menyelesaikan data zona GDC, dan kueri akan mencapai batas waktu tanpa respons.

Solusi: Setelah perubahan cidr-claim, pastikan AddressGroup diperbarui dengan cidr-claim terbaru dengan memulai ulang deployment fw-core-backend-controller di namespace fw-system pada cluster root-admin.

Server fisik

Bootstrap server gagal karena masalah POST di server HPE

Versi: 1.13.1

Gejala: Bootstrap server gagal saat server gagal melewati proses POST boot up. Login ke ILO dan memeriksa konsol server menampilkan error berikut:

Symptom: An Invalid Opcode Exception has occurred indicating
that the processor tried to execute an invalid, undefined opcode,
or an instruction with invalid prefixes.

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem.

ACTION : Reboot the server.

Solusi:

Dari iLO, klik Power Button, lalu pilih Cold Boot.

Server macet dalam status penyediaan

Versi: 1.13.1, 1.13.3, 1.13.5

Gejala: Server mengalami masalah dalam status penyediaan selama bootstrap server. Periksa status server:

k get servers -A | grep -v availabl

Outputnya mungkin terlihat seperti ini:

NAMESPACE    NAME         AGE   RACK    MACHINE-CLASS               MANAGEMENT-IP   DATA-IP    DATA-IP   BMC-IP           CLUSTER   NODEPOOL   STATE          PROVISION-READY
gpc-system   ag-aa-bm01   21h   ag-aa   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.0         203.0.113.0                         provisioning
gpc-system   ag-ab-bm01   21h   ag-ab   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.1         203.0.113.0                         provisioned    true
gpc-system   ag-ac-bm01   21h   ag-ac   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.2         203.0.113.0                         provisioning

Solusi:

  1. Mulai dhcp secara manual dengan konfigurasi yang didownload dari cluster KIND. Dalam contoh ini, /tmp/dhcp.conf adalah konfigurasi DHCP dari cluster KIND:

    docker run  -d -it --network host --name dnsmasq -v /tmp/dhcp.conf:/etc/dnsmasq.conf --cap-add=NET_ADMIN --restart always 198.51.100.255/gpc-system-container-images/private-cloud-staging/dnsmasq:VERSION

    Ganti VERSION dengan versi rilis seperti yang dijelaskan dalam petunjuk upgrade di Upgrade komponen File Manual untuk Cluster Admin Root & Org, misalnya 1.13.1-gdch.525.

  2. Periksa konfigurasi BIOS di server dan pastikan NetworkBoot tidak diaktifkan untuk NIC dataplane (bernama dalam pola Slot{i}Nic{i}).

  3. Periksa BIOS dengan panggilan API:

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword

    Dengan $bmcUser dan $bmcPassword adalah sandi untuk ILO, yang dapat ditemukan di file atau direktori cellcfg dalam secret bernama bmc-credentials-<server-name>, misalnya, bmc-credentials-ai-aa-bm01. Pastikan output perintah ini menampilkan Slot1Nic1: Disabled.

  4. Jika salah satu Slot{i}Nic{i} tersebut memiliki NetworkBoot, nonaktifkan dengan BIOS settings API.

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios/settings -u $bmcUser:$bmcPassword -X PATCH -d '{"Attributes": {"Slot{i}Nic{i}":"Disabled"}}' -H 'content-type: application/json'

    Ganti Slot{i}Nic{i} dengan nama slot yang memiliki masalah dalam payload.

  5. Mulai ulang server.

Server DL380a gagal melakukan penyediaan

Versi: 1.13.3, 1.13.4, 1.13.5

Gejala: Penyediaan server gagal pada tugas enkripsi untuk model HPE DL380a. Status CR Server macet di available selama bootstrap server:

# server name
export SERVER_NAME=

kubectl --kubeconfig "${KUBECONFIG:?must be set}" get servers ${SERVER_NAME} -n gpc-system

Solusi:

  1. Ikuti IAM-R0004 untuk membuat KUBECONFIG bagi root-admin-cluster.

  2. Ikuti PLATAUTH-G0001 untuk membuat kunci SSH root-id_rsa untuk CLUSTER_NS=root.

  3. Jeda server dengan menambahkan anotasi server.system.private.gdc.goog/paused ke resource kustom server:

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused=''

  4. Login ke server dari IP pengelolaan:

    export MGMT_IP=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -o=jsonpath='{.spec.managementNetwork.ips[0]}')

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

  5. Mengaktifkan enkripsi secara manual:

    /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force

/opt/MegaRAID/storcli/storcli64 /c0 delete securitykey

/opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j

    Anda akan mendapatkan output perintah yang mirip dengan:

    root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Drive Secure Erase Succeeded.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 delete securitykey
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = None

Controller Properties :
=====================

------------------------
Ctrl Method     Result
------------------------
  0 delete Key Success
------------------------

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Success",
                "Description" : "None"
        },
        "Response Data" : {
                "Controller Properties" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "Please reboot the system for the changes to take effect"
                        }
                ]
        }
}
]
}

    Jika Anda mendapati perintah terakhir tidak berhasil atau Anda melihat error seperti "Status EKM BIOS tidak valid", coba mulai ulang server dan iLO, lalu jalankan kembali langkah ini.

    root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Failure",
                "Description" : "None",
                "Detailed Status" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "-",
                                "ErrMsg" : "Invalid BIOS EKM status",
                                "ErrCd" : 255
                        }
                ]
        }
}
]
}

    Jika perintah terakhir berhasil, mulai ulang server seperti yang diinstruksikan.

  6. Buat drive logis secara manual:

    Setelah server selesai di-reboot, login ke server dari IP pengelolaan lagi dan cantumkan semua drive yang tersedia:

    ssh $MGMT_IP -i ~/.ssh/root-id_rsa

/opt/MegaRAID/storcli/storcli64 /c0 show j

    Output perintah terakhir mungkin terlihat seperti contoh ini:

    {
  "Controllers":[
  {
    "Command Status" : {
      "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
      "Operating system" : "Linux 5.4.0-1072-fips",
      "Controller" : 0,
      "Status" : "Success",
      "Description" : "None"
    },
    "Response Data" : {
      "Product Name" : "HPE MR416i-o Gen11",
      "Serial Number" : "******",
      "PCI Slot Number" : 17,
      "SAS Address" : "******",
      "PCI Address" : "00:12:00:00",
      "System Time" : "09/12/2024 23:32:48",
      "Mfg. Date" : "09/15/23",
      "Controller Time" : "09/12/2024 23:32:47",
      "FW Package Build" : "52.26.3-5379",
      "BIOS Version" : "7.26.00.0_0x071A0000",
      "FW Version" : "5.260.03-3985",
      "Driver Name" : "megaraid_sas",
      "Driver Version" : "07.713.01.00-rc1",
      "Current Personality" : "RAID-Mode ",
      "Vendor Id" : 4096,
      "Device Id" : 4322,
      "SubVendor Id" : 5520,
      "SubDevice Id" : 808,
      "Host Interface" : "PCI-E",
      "Device Interface" : "SAS-12G",
      "Bus Number" : 18,
      "Device Number" : 0,
      "Function Number" : 0,
      "Domain ID" : 0,
      "Security Protocol" : "SPDM-1.0.0",
      "Physical Drives" : 8,
      "Drive LIST" : [
        {
          "EID:Slt" : "252:1",
          "DID" : 0,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:2",
          "DID" : 1,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:3",
          "DID" : 2,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:4",
          "DID" : 3,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:5",
          "DID" : 4,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:6",
          "DID" : 5,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:7",
          "DID" : 6,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:8",
          "DID" : 7,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        }
      ],
      "Enclosures" : 1,
      "Enclosure LIST" : [
        {
          "EID" : 252,
          "State" : "OK",
          "Slots" : 8,
          "PD" : 8,
          "PS" : 0,
          "Fans" : 0,
          "TSs" : 0,
          "Alms" : 0,
          "SIM" : 0,
          "Port#" : "2I"
        }
      ]
    }
  }
  ]
}

    Anda harus menyimpan 2 ID EID:Slt dengan Size sama dengan 1.60 TB, dalam hal ini:

    252:1,252:2

    Kemudian, buat drive logis menggunakan ID EID:Slt:

    /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

    Output perintah terakhir akan terlihat seperti contoh ini:

    /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Add LD Succeeded.

  7. Mock status enkripsi disk di CR Server.

    Edit status CR Server:

    kubectl edit-status --kubeconfig "${KUBECONFIG:?must be set}" server ${SERVER_NAME:?} -n gpc-system

    Tambahkan atau ubah status DiskEncryptionEnabled menjadi benar (true):

      - lastTransitionTime: "<time>"
    message: ""
    observedGeneration: 1
    reason: DiskEncryptionJobSucceeded
    status: "True"
    type: DiskEncryptionEnabled

  8. Hapus tugas enkripsi server jika ada:

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" delete job server-encrypt-and-create-logical-drive-${SERVER_NAME:?} -n gpc-system

  9. Lanjutkan server agar penyediaan dilanjutkan:

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused-

Penghapusan aman gagal tanpa lisensi

Versi: 1.13.5

Gejala: Jika server mengalami masalah saat penginstalan server, Anda mungkin melihat status di CR server seperti ini:

- lastTransitionTime: "2024-09-10T20:28:33Z"
   message: 'unable to trigger secure erase: unable to complete secure erase
     for server "zx-ad-bm07": failed to post payload to /redfish/v1/Systems/1/Actions/Oem/Hpe/HpeComputerSystemExt.SecureSystemErase:
     400: {"error":{"code":"iLO.0.10.ExtendedInfo","message":"See @Message.ExtendedInfo
     for more information.","@Message.ExtendedInfo":[{"MessageId":"iLO.2.27.LicenseKeyRequired"}]}}'
   reason: Succeeded
   status: "False"
   type: BMCConfigPreinstallSecureEraseTriggered

Solusi: Ikuti petunjuk dalam runbook SERV-R0014.

Keamanan Platform

Penyelesaian BYO SubCA tidak memverifikasi apakah sertifikat memiliki kunci publik yang cocok

Versi: 1.13.1

Gejala: Saat mode PKI BYO SubCA membuat permintaan penandatanganan sertifikat (CSR) baru saat sertifikat yang ditandatangani sebelumnya diupload ke SubCA, rekonsiliator tidak memeriksa apakah CSR baru cocok dengan sertifikat lama yang ditandatangani, dan menandai resource kustom (CR) cert-manager CertificateRequest sebagai Ready. Hal ini terjadi selama perpanjangan sertifikat SubCA atau rotasi manual. Pengontrol cert-manager mencoba memperbarui status CR Certificate, yang memicu pesan error berikut:

The certificate request has failed to complete and will be retried: Error signing certificate: error creating x509 │
│  certificate: x509: provided PrivateKey doesn't match parent's PublicKey

Solusi:

Ikuti petunjuk untuk mengupload sertifikat SubCA BYO bertanda tangan baru untuk CSR baru.

Masalah cert-manager menyebabkan penerbitan PKI BYO dengan ACME tidak berhasil

Versi: 1.13.1

Gejala: Kegagalan terjadi pada penerbitan atau perpanjangan pertama sertifikat BYO dengan Automatic Certificate Management Environment (ACME). Saat menjalankan perintah untuk memeriksa status sertifikat, Anda akan melihat bahwa sertifikat tersebut not ready:

kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert

Outputnya terlihat mirip dengan yang berikut ini:

status:
  conditions:
  - lastTransitionTime: "2024-07-23T17:27:02Z"
    message: 'reconciling Certificate status failed: cert-manager Certificate CR "default-wildcard-cert-pki-ct"/"pki-system" is not ready'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: "False"
    type: Ready

Solusi:

Mulai ulang deployment cert-manager di cluster admin organisasi:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

kubectl rollout restart deployment/cert-manager -n cert-manager

Pengelola resource

Status project tidak tersedia dari konsol GDC

Versi: 1.13.1+

Gejala: Konsol GDC tidak menampilkan status project. Project yang tidak dalam status Ready tidak dapat mendukung resource baru atau memproses modifikasi baru pada resource yang ada. Karena tidak dapat mengonfirmasi status project, tidak jelas kapan resource project dapat dikelola, yang menyebabkan error saat mencoba tindakan project baru.

Solusi: Lihat runbook RM-R0100 untuk mencetak status project menggunakan kubectl CLI.

Upgrade

bm-system dan tugas lainnya macet

Versi: 1.13.1

Gejala: bm-system dan tugas lain yang menjalankan playbook ansible macet di gathering facts.

Solusi: Masukkan nama node yang macet dan jalankan multipath -ll | grep failed dan multipath -ll | grep #. Jika ada hasil yang tidak kosong,ikuti runbook FILE R0020 dan FILE R0021.

IP pengelolaan tidak dapat dijangkau

Versi: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Gejala: Selama upgrade, IP pengelolaan server tidak dapat dijangkau, khususnya setelah pengalihan.

Dengan Rocky Linux, saat rute statis ditambahkan, IP tujuan yang digunakan untuk mencapai rute statis harus dapat dijangkau sebelum rute statis ditambahkan. Jika switch dimulai ulang setelah upgrade OS, IP pengelolaan tersebut mungkin tidak dapat dijangkau untuk sementara.

Solusi: Buat koneksi SSH ke server menggunakan alamat IP data dan mulai ulang layanan jaringan untuk membuat ulang rute statis yang hilang:

systemctl restart NetworkManager.service

Nomor versi untuk storagecluster tidak ditampilkan

Versi: 1.13.3

Gejala: Setelah upgrade, CR StorageCluster tidak menampilkan nilai untuk kolom status StorageVersion.

Periksa versi:

kubectl --kubeconfig <var>ROOT_ADMIN_KUBECONFIG</var> get StorageCluster -n gpc-system

Ikuti langkah-langkah dalam solusi sementara, jika kolom versi kosong.

Solusi: Mulai ulang deployment file-storage-backend-controller:

kubectl --kubeconfig  <var>ROOT_ADMIN_KUBECONFIG</var> rollout restart deployment -n file-system file-storage-backend-controller

Server Bare Metal macet pada status penyediaan

Versi: 1.13.1

Gejala:

Server bare metal macet pada status 'penyediaan' dalam waktu yang lama saat organisasi sedang dibuat.

Solusi:

Konfigurasi BIOS server mungkin telah berubah sehingga server menggunakan Kartu jaringan yang salah untuk Pxebooting.

Ikuti langkah-langkah berikut untuk menonaktifkan booting jaringan NIC dataplane.

  • Akses yang diperlukan:
    • Anda memerlukan akses ke kredensial administrator BMC server yang mengalami masalah.
    • Ikuti IAM-R0005 untuk Mendapatkan peran hardware-admin ClusterRole di cluster root-admin selama 1 jam.
    • Ikuti IAM-R0004 untuk Membuat KUBECONFIG bagi cluster root-admin.

  1. Tetapkan nama server yang macet.

    export SERVER_NAME=

  2. Tetapkan IP dan kredensial BMC server.

    export ip=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.ip}')
export BMC_CREDENTIALS_SECRET=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.credentialsRef.name}')
export user=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.username}' | base64 -d)
export pass=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.password}' | base64 -d)

  3. Identifikasi slot PCIe kartu jaringan dataplane di server.

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}

    Misalnya, output berikut menunjukkan bahwa kartu jaringan diinstal di Slot 3.

    ["s3p1","s3p2"]

    Tetapkan variabel PCIEslot:

    export DATA_NIC_SLOT=3

  4. Pastikan booting jaringan tidak dinonaktifkan.

    curl -ks -u $user:$pass https://$ip/redfish/v1/systems/1/bios/settings  | jq .Attributes | grep "Slot${DATA_NIC_SLOT}NicBoot1"

    Jika hasilnya adalah "NetworkBoot", Anda harus menonaktifkannya secara eksplisit.

  5. Gunakan BMC untuk menonaktifkan fungsi booting jaringan pada kartu jaringan dataplane.

    Ganti "Slot3" dalam perintah berikut dengan nomor slot yang sebenarnya.

    curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/systems/1/bios/settings/ -X PUT --data '{"Attributes":{"Slot3NicBoot1":"Disabled"}}' | jq

    lalu mulai ulang komputer.

    curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/Systems/1/Actions/ComputerSystem.Reset/ -X POST -d '{"ResetType": "ForceRestart"}' | jq

    Server memerlukan waktu 10 hingga 15 menit untuk kembali aktif, dan secara otomatis melanjutkan proses penyediaan.

Upgrade penyimpanan objek menampilkan error selama pemeriksaan pasca-penerbangan atau pra-penerbangan

Versi: 1.13.1

Gejala: Pemeriksaan sebelum penerbangan atau pemeriksaan setelah penerbangan gagal dengan error. Periksa log:

kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410

Error mungkin terlihat seperti ini:

 03:42:05.701163       1 upgrade_check.go:276] 1 error occurred:
      * Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource {Role vm-system g-vm-image-bucket-reader    }

   Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

  F0410 03:42:05.701901       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

Solusi:

  1. Jika error terjadi selama pemeriksaan setelah penerbangan dan semua pemeriksaan lainnya selesai tanpa error, lewati pemeriksaan setelah penerbangan. Saat upgrade dimulai ulang, Anda juga harus melewati pemeriksaan pra-penerbangan menggunakan kubeconfig admin root:

    kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

    Misalnya, jika error terjadi di org-1, perintahnya akan terlihat seperti ini:

    kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

  2. Jika error terjadi selama pemeriksaan pra-penerbangan dan semua pemeriksaan pra-penerbangan lainnya selesai tanpa error, lewati pemeriksaan pra-penerbangan:

    kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

    Misalnya, jika error terjadi di org-1, perintahnya akan terlihat seperti ini:

    kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

Anda mungkin perlu menerapkan solusi ini lebih dari sekali jika gagal diterapkan.

Rollback upgrade Helm

Versi: 1.13.3

Gejala: Masalah upgrade Helm menyebabkan serangkaian rollback, sehingga gagal menemukan Certificate dan ServiceEntry. Anda mungkin melihat pesan seperti ini:

REVISION        UPDATED                         STATUS          CHART                                   APP VERSION             DESCRIPTION
91              Thu Jul 18 13:26:42 2024        deployed        iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Upgrade complete
9138            Fri Jul 19 22:21:56 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9139            Fri Jul 19 22:22:04 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9140            Fri Jul 19 22:22:16 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9141            Fri Jul 19 22:22:30 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9142            Fri Jul 19 22:22:35 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9143            Fri Jul 19 22:22:42 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9144            Fri Jul 19 22:22:48 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9145            Fri Jul 19 22:22:56 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9146            Fri Jul 19 22:23:04 2024        failed          iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found

Solusi: Ikuti langkah-langkah dalam runbook OCLCM-R0122.

Upgrade node atau ABM terhenti karena pod dhcp-tftp-core-server tidak dikosongkan

Versi: 1.13.3, 1.14.4, 1.14.5

Gejala: Upgrade node mungkin macet. Di status mesin bare metal, pod dhcp-tftp-core-server tidak dikuras. Anda mungkin melihat pesan seperti ini:

bareMetalMachineDrainingStatus:
    currentDrainingStage: SystemCriticalPriorityClass
    podsYetToDrain:
    - name: dhcp-tftp-core-server-7ffcfcbb97-6wlg7
      namespace: dhcp-system
      resourceVersion: "5005530"
      uid: f77826ea-1d57-46ff-a699-f42faa36c1d2

Solusi: Hapus paksa pod dhcp-tftp-core-server-* untuk melanjutkan. Perintah terlihat seperti ini:

kubectl delete pod dhcp-tftp-core-server-7ffcfcbb97-6wlg7 -n dhcp-system --force

OrganizationUpgrade macet di tahap upgrade node

Versi: 1.13.3

Gejala: OrganizationUpgrade macet di tahap upgrade node. Anda mungkin melihat pesan seperti ini:

  Last Transition Time: 2024-08-27T12:37:40Z
    Message:             observed the following reason: [JobRunning]
    Observed Generation: 614
    Reason:              Unsuccessful
    Status:              Unknown
    Type:                service/Node

Solusi:

  1. Periksa upgradetaskrequestCR di cluster root ka get upgradetaskrequest -n gpc-system. Periksa apakah node masih dalam status berjalan. Pastikan perangkat macet pada tugas untuk layanan.

    spec:
    clusterType: service
Last Transition Time: 024-08-27T12:37:40Z
  Message:            job gpc-system/v1.13.0-os-aa505d9004-upg-task-org-1-os-node-upgra-czwwd is running
  Observed Generation: 1
  Reason:              JobRunning
  Status:              Unknown
  Type:                Succeeded

  2. Buat CR nodeupgrade secara manual untuk setiap klaim nodepool:

    export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get nodepoolclaims -n g-org-1-shared-service-cluster
NAME                                                     AGE
control-plane-node-pool                                  34d
dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   34d
shared-service-default-worker                            34d

  3. Buat CR nodeupgrade untuk setiap klaim nodepool. Detail anotasi upgrade.private.gdc.goog/target-release-version harus diperoleh dari nama CRMD OS target:

    kubectl get crmd  --kubeconfig ${ROOT_ADMIN_KUBECONFIG} | grep "os"
os-1.13.1-gdch.525                     35d
os-v1.13.0-os-4175a6dce6               27d
os-v1.13.0-os-aa505d9004               5d18h

  4. Gunakan versi dari sini dalam anotasi upgrade.private.gdc.goog/target-release-version:

    kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get crmd os-v1.13.0-os-aa505d9004 -o json | jq -r '.spec.config.vmNodeImage'
rocky-86-1.13-v20240731-1.13-r191

  5. Terapkan yaml berikut untuk setiap nodepoolclaim:

        apiVersion: upgrade.private.gdc.goog/v1alpha1
    kind: NodeUpgrade
    metadata:
      annotations:
        upgrade.private.gdc.goog/target-release-version: VERSION
      name: NAME
      labels:
        addon.private.gdc.goog/cluster-type: service
      namespace: NAMESPACE
    spec:
      inFlightConf:
        maxConcurrentNodes: 1
      nodePoolClaimRef:
        name: NAME
        namespace: NAMESPACE
      nodeType: Virtual
      software:
        osImage:
          name: NAME
          version: VERSION

  6. Setelah upgrade node selesai untuk node cluster layanan, perbarui status CR UpgradeTaskRequest menjadi Benar, sehingga upgrade organisasi dilanjutkan ke tahap berikutnya:

        kubectl patch upgradetaskrequest  upg-task-org-1-os-node-upgrade-task-pckxn --type='json' -p='[{"op": "replace", "path": "/status/conditions/0/status", "value": "True"}]' --subresource=status -n gpc-system --kubeconfig /root/release/root-admin/root-admin-kubeconfig

  7. Upgrade organisasi kini akan dilanjutkan ke tahap berikutnya, dan status untuk layanan atau node akan selesai:

    Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

Kernel gagal membuat penampung

Versi: 1.13.3

Gejala: Kernel gagal mengalokasikan memori cgroups sehingga menyebabkan kegagalan dalam membuat penampung baru.

Anda mungkin melihat pesan seperti ini:

Conditions:
  Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          Message
  ----                          ------    -----------------                 ------------------                ------                          -------
  FrequentContainerdRestart     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentContainerdRestart     containerd is functioning properly
  KernelDeadlock                False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KernelHasNoDeadlock             kernel has no deadlock
  ReadonlyFilesystem            False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   FilesystemIsNotReadOnly         Filesystem is not read-only
  ContainerRuntimeUnhealthy     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 10:52:30 +0000   ContainerRuntimeIsHealthy       Container runtime on the node is functioning properly
  FrequentUnregisterNetDevice   False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentUnregisterNetDevice   node is functioning properly
  KubeletUnhealthy              False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KubeletIsHealthy                kubelet on the node is functioning properly
  FrequentKubeletRestart        False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentKubeletRestart        kubelet is functioning properly
  FrequentDockerRestart         False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentDockerRestart         docker is functioning properly
  MemoryPressure                Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  DiskPressure                  Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  PIDPressure                   Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  Ready                         Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

[root@zv-aa-bm01 ~]# journalctl -u kubelet -f | grep cilium-agent
Aug 29 17:29:47 zv-aa-bm01 kubelet[48625]: E0829 17:29:47.941493   48625 pod_workers.go:1298]
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"cilium-agent\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=cilium-agent pod=anetd-pvmz4_kube-system(db55cbd2-36e3-4d20-8c6b-edbb5191232d)\"" pod="kube-system/anetd-pvmz4" podUID="db55cbd2-36e3-4d20-8c6b-edbb5191232d"
Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

dan node menggunakan sejumlah besar cgroup:

# cat /proc/cgroups | grep memory
memory  12      380360  1

Solusi:

Pelajari salah satu hal berikut:

  1. Jalankan echo 3 > /proc/sys/vm/drop_caches di node, lalu mulai ulang kubelet.
  2. Jika metode sebelumnya tidak berhasil, coba mulai ulang node.

Kegagalan konektivitas sesekali ke VIP cluster eksternal

Versi: 1.13.3

Gejala: Kegagalan koneksi terputus-putus ke IP Virtual (VIP) cluster eksternal, seperti VIP bidang kontrol, VIP istio-gateway, atau VIP Harbor, akan menghasilkan error dial tcp :: connect: no route to host.

Untuk mendiagnosis masalah ini, ikuti langkah-langkah berikut:

  1. Hubungkan ke cluster admin root. Solusi ini mengasumsikan bahwa Anda men-debug alamat IP di cluster admin root. Jika Anda men-debug masalah konektivitas dengan cluster Kubernetes lainnya seperti cluster admin org. atau cluster sistem org., ubah nilai KUBECONFIG ke jalur kubeconfig cluster yang benar.

  2. Ada dua kategori IP yang diketahui dapat terpengaruh. Periksa apakah Border Gateway Protocol (BGP) mengiklankan alamat IP ke switch top-of-rack (ToR):

    • Jika IP adalah alamat IP bidang kontrol Kubernetes seperti 192.0.2.100, gunakan perintah ini untuk mendapatkan informasi konfigurasi:

      KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`

      Ganti KUBECONFIG dengan jalur ke file kubeconfig Anda di cluster admin root.

    • Untuk beberapa konfigurasi, resource kustom BGPAdvertisedRoute menentukan rute mana dalam alamat IP yang diiklankan ke jaringan atau sistem lain menggunakan BGP. Jika alamat IP diiklankan oleh resource kustom BGPAdvertisedRoute, gunakan perintah ini untuk mendapatkan informasi konfigurasi:

      TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP

      Ganti TARGET_IP_ADDRESS dengan alamat IP yang mengalami masalah konektivitas terputus-putus.

  3. Periksa status resource kustom BGPSession. BGPSessionmewakili setiap sesi peering BGP yang dibuat antara cluster Kubernetes dan peer BGP eksternal. Periksa log pod BGPAdvertiser dan verifikasi bahwa semua resource BGPSession berada dalam status Established:

    KUBECONFIG=KUBECONFIG
kubectl get pods -l app=bgpadvertiser -n kube-system

# Based on the name of pods, check their logs
kubectl logs pod/bgpadvertiser-gpc-adhoc-6a265a03vm-worker-node0-zone1 -n
kube-system --kubeconfig=$KUBECONFIG`

    Output pod BGPAdvertiser yang berfungsi dengan baik berisi cuplikan berikut:

    I0904 04:32:19.999906       1 main.go:217] BGP advertiser serving...\
time="2024-09-04T04:32:25Z" level=info msg="Peer Up" Key=10.200.0.1
State=BGP_FSM_OPENCONFIRM Topic=Peer\

  4. Verifikasi kestabilan koneksi. Buat dan jalankan skrip untuk memeriksa apakah konektivitas terputus-putus atau tidak stabil:

    1. Buat skrip:

      #!/bin/bash

TARGET=$1
CNT=0
for i in {1..100}; do
    output=$(curl --no-progress-meter -k https://$TARGET 2>&1)
    if echo "$output" | grep -q "No route to host"; then
            CNT=$((CNT+ 1))
            echo "Attempt $i: $output"
    fi
    sleep 0.1
done
echo "$CNT out of 100 runs hit No route to host error"

    2. Jalankan skrip:

      ./script.sh TARGET_IP_ADDRESS:PORT

      Ganti PORT dengan nomor port yang mengalami masalah.

      Jika koneksi Anda bermasalah, Anda akan melihat output seperti berikut:

      Attempt 2: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 4: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 7: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host`

  5. Output sebelumnya mengonfirmasi masalah ini. Periksa rute di switch TOR untuk melihat apakah konfigurasi switch TOR adalah sumber masalahnya.

    Dengan asumsi traffic dihentikan untuk contoh alamat IP 192.0.2.201 dan diiklankan oleh resource BGPAdvertisedRoute, periksa hop di resource BGPAdvertisedRoute untuk mengidentifikasi potensi titik kegagalan:

    apiVersion: networking.gke.io/v1
kind: BGPAdvertisedRoute
metadata:
  annotations:
    bgploadbalancer.networking.gke.io/servicename: istio-ingressgateway
    bgploadbalancer.networking.gke.io/servicens: istio-system
  creationTimestamp: "2024-08-20T19:03:02Z"
  generation: 150
  name: default-istio-system-istio-ingressgateway-rj2fv
  namespace: kube-system
  ownerReferences:
  - apiVersion: networking.gke.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: BGPLoadBalancer
    name: default
    uid: f681f3e5-c66a-45d6-a3ac-9d7ae26f555f
  resourceVersion: "27133500"
  uid: 8ede0c81-3aba-40ce-a441-4aec334b41bd
spec:
  bgpPeerNames:
  - 192.0.2.6-peer-10.0.1.1
  - 192.0.2.5-peer-10.0.1.0
  - 192.0.2.5-peer-10.0.1.1
  - 192.0.2.6-peer-10.0.1.0
  nextHops:
  - 192.0.2.2
  - 192.0.2.3
  - 192.0.2.4
  prefix: 192.0.2.201/32

  6. Lihat alamat IP di kolom nextHops. Untuk setiap alamat IP, temukan nama server. Contoh:

    - 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01

  7. Output ini menunjukkan bahwa hop berikutnya menuju server di rak aa dan rak ab. Login ke switch TOR di rak aa dan ab, lalu bandingkan rute di kedua rak:

    show ip route 192.0.2.201 vrf root-external-vrf

  8. Jika rute berbeda antara switch TOR di kedua rak, Anda mengalami masalah yang dapat diatasi dengan solusi sementara ini. Output untuk masalah ini akan terlihat seperti berikut:

    zt-aa-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w1d, bgp-65070, external, tag 64513

zt-aa-torsw02# sh ip route 192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w3d, bgp-65070, external, tag 64513

zt-ab-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 10.249.88.2, [200/0], 1w1d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w1d, bgp-65070, internal, tag 64513

zt-ab-torsw02# sh ip route  192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 192.0.2.2, [200/0], 1w3d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w3d, bgp-65070, internal, tag 64513

    Dalam output ini, rute di rak aa berada dalam status yang diharapkan dengan menampilkan tiga next hop yang tercantum terhadap awalan. Namun, di rack ab, awalan hanya memiliki dua hop berikutnya. Saat traffic yang ditujukan ke awalan di-hash ke rak ab, node yang sesuai dengan next hop yang tidak ada tidak pernah menerima traffic dan jaringan mengalami masalah konektivitas.

Ikuti solusi untuk mengurangi masalah ini.

Solusi:

Solusi ini membantu mengatasi masalah konektivitas terputus-putus ke alamat IP tertentu dalam cluster Kubernetes.

Untuk mengurangi masalah ini, Anda harus menerapkan beberapa perubahan konfigurasi pada sesi BGP antara switch gabungan. Aggregate (AGG) mengalihkan traffic gabungan dari beberapa switch TOR. Ikuti langkah-langkah berikut untuk memperbarui semua konfigurasi yang diperlukan:

  1. File konfigurasi bernama switchstaticconfig merepresentasikan konfigurasi statis pada satu switch. Download file switchstaticconfig untuk kedua tombol AGG:

    export KUBECONFIG=KUBECONFIG
kubectl get switchstaticconfig za-ab-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ab-aggsw01-static-config.yaml
kubectl get switchstaticconfig za-ac-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ac-aggsw01-static-config.yaml

  2. Dapatkan nomor Autonomous System Number (ASN) lingkungan:

    root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030

    Output ini menampilkan nilai ASN 65030. Anda harus menggunakan nilai ASN apa pun yang ditampilkan di sini pada langkah-langkah berikutnya.

  3. Alamat IP loopback pada switch AGG berfungsi sebagai alamat yang stabil dan selalu aktif untuk pengelolaan, perutean, dan pemecahan masalah, meskipun koneksi jaringan lainnya tidak berfungsi. Dapatkan alamat IP loopback dari setiap switch AGG:

    root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'

    Outputnya terlihat mirip dengan yang berikut ini:

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  4. Perbarui staticswitchconfig untuk tombol AGG za-ab-aggsw01. Tambahkan cuplikan ini ke bagian config:

    spec:
  config: |

route-map onlydefault permit 10
match ip address prefix default
router bgp ASN
      neighbor LOOPBACK_ADDRESS
  address-family l2vpn evpn
      route-map onlydefault in

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1

    Ganti kode berikut:

    • ASN: nilai ASN dari langkah sebelumnya. Dalam contoh ini, nilainya adalah 65030.
    • LOOPBACK_ADDRESS: Ini adalah alamat IP loopback switch AGG za-ac-aggsw01. Dalam contoh ini, nilainya adalah 192.0.2.2.

  5. Terapkan update yang sama ke switch AGG lainnya, za-ac-aggsw01. Anda harus memberikan alamat loopback yang benar. Alamat IP loopback berbeda untuk setiap switch:

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  6. Buat dan jalankan skrip yang sama yang digunakan untuk mendiagnosis masalah pada langkah ini untuk memverifikasi bahwa perbaikan berhasil. Output tidak menampilkan pesan error.

Error Incorrect version of Trident muncul selama upgrade

Versi: 1.13.3, 1.13.4, 1.13.5

Gejala: Saat mengupgrade dari versi yang lebih rendah dari 1.13.3, ontap menampilkan error Incorrect version of Trident. Anda mungkin melihat pesan seperti ini:

Status:
  Conditions:
  Last Transition Time: 2024-08-27T15:19:07Z
  Message:              Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke5
  Observed Generation:  1
  Reason:               QualificationFailed
  Status:               False
  Type:                 AllComplete
  Events:

Solusi:

  1. Perbarui releasemetadata versi yang Anda upgrade:

    export KUBECONFIG=<point to ROOT Admin Kubeconfig>
To get the list of all releasemetadata:
`kubectl get releasemetadata`

    Outputnya mungkin terlihat seperti:

    NAME AGE 1.12.2-gdch.785 24d 1.12.4-gdch.96 13d 1.13.3-gdch.5548 11h

  2. Pilih versi yang akan Anda upgrade seperti yang disebutkan dalam contoh berikut:

    kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml

  3. Perbarui tridentVersion di bagian fileBlockStorage pada .yaml ke versi yang disebutkan dalam error. Jika pesan error terlihat seperti ini:

    Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5

    Ubah tridentVersion menjadi v23.10.0-gke.5 di releasemetadata.yaml.

    Misalnya, jika nilai aslinya adalah: infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6,

    Ubah menjadi nilai berikut:

    infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5.

  4. Terapkan perubahan:

    kubectl apply -f releasemetadata.yaml

  5. Terapkan upgrade penyimpanan ontap lagi.

Pod gagal dijadwalkan

Versi: 1.13.3. 1.13.4, 1.13.5

Gejala: Selama penyediaan cluster pengguna, beberapa pod gagal dijadwalkan. Anda mungkin melihat pesan seperti ini:

0/6 nodes are available: 1 Insufficient cpu. preemption: 0/6 nodes are available: 6 No preemption victims found for incoming pod

Solusi:

Tingkatkan skala node pool bidang kontrol cluster pengguna:

  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch addresspoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/size', 'value': 5}]"
  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch nodepoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/nodeCount', 'value': 5}]"

Upgrade gagal di subkomponen iac-zoneselection-global

Versi: 1.13.1

Gejala: Selama upgrade ke 1.13.3, terjadi error pada subkomponen iac-zoneselection-global. Anda mungkin melihat pesan seperti ini:

== Subcomponents with failures in root org ===
Sub-Component: iac-zoneselection-global - Reconciliation error: E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
        * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Events: Type     Reason               Age                   From          Message
----     ------               ----                  ----          -------
Warning  ReconciliationError  119s (x521 over 20h)  Subcomponent  E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
         * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Solusi:

Mengupgrade ke 1.13.3 akan memperbaiki error tersebut.

Tugas pemeriksaan upgrade telah melewati batas waktu

Versi: 1.12.x, 1.13.x

Gejala: Selama upgrade organisasi, pemeriksaan upgrade menampilkan status False dengan alasan DeadlineExceeded. Anda mungkin melihat pesan seperti ini:

  Preflight Check:                                                                                                                                                                                                          
    Conditions:                                                                                                                                                                                                             
      Last Transition Time:  2024-10-29T18:57:47Z                                                                                                                                                                           
      Message:               the result has status: False, reason: PreflightCheckFailed, and err: [check "OPAUpgrade" of operable component "OPA" failed with reason "DeadlineExceeded", no existing pods found, check "Arti
actAvailability" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods foun
d, check "IAMUpgrade" of operable component "IAM" failed with reason "DeadlineExceeded", no existing pods found, check "NodeHealth" of operable component "OS" failed with reason "DeadlineExceeded", no existing pods found
, check "DNSHealth" of operable component "DNS" failed with reason "DeadlineExceeded", no existing pods found, check "AdminClusterCheck" of operable component "UPORC" failed with reason "DeadlineExceeded", no existing po
ds found[]                                                                                                                                                                                                                  
      Observed Generation:   3                                                                                                                                                                                              
      Reason:                PreflightCheckFailed                                                                                                                                                                           
      Status:                False                                                                                                                                                                                          
      Type:                  Succeeded                                                                                                                                                                                      
    Start Time:              2024-10-29T17:57:47Z

Solusi:

  1. Hapus tugas pemeriksaan upgrade yang gagal yang sesuai dengan pemeriksaan upgrade yang gagal.
  2. Tunggu hingga tugas pemeriksaan upgrade dibuat ulang.
  3. Periksa log tugas yang dibuat ulang dan pilah masalahnya.

Add-on meta-monitoring gagal karena lokasi strongswan berada di direktori runtime yang berbeda

Versi: 1.12.x, 1.13.x

Gejala: Selama upgrade ke 1.13.4 atau 1.13.5, add-on meta-monitoring gagal:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIGget addons -A | grep meta-monitoring
org-1-system-cluster                                      meta-monitoring                                      false                                        false                                      1.12.4-gdch.96

Periksa add-on:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get -n org-1-system-cluster addon meta-monitoring -o yaml

Pesan kondisi mungkin terlihat seperti ini:

status:
  conditions:
  - lastTransitionTime: "2024-11-19T02:57:30Z"
    message: 'Error occurred during addon installation: failed to rollback chart:
      create: failed to create: Internal error occurred: failed calling webhook "validation.gatekeeper.sh":
      failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/admit?timeout=3s":
      context deadline exceeded'
    observedGeneration: 2
    reason: InstallationError
    status: "False"
    type: Deployed

Solusi:

  1. Pastikan sesi BGP di Org System Cluster gagal, misalnya:

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get bgpsessions -A
NAME                                           LOCAL ASN   PEER ASN   LOCAL IP        PEER IP     STATE   LAST REPORT
10.252.122.10-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.32           
10.252.122.10-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.33           
10.252.122.11-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.32           
10.252.122.11-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.33           
172.20.128.3-peer-10.0.1.48-za-aa-bm02-hltg2   64513       65030      172.20.128.3    10.0.1.48           
172.20.128.3-peer-10.0.1.49-za-aa-bm02-hqblq   64513       65030      172.20.128.3    10.0.1.49

  2. Pastikan Pod ang-node mengalami masalah pada ContainerCreating, misalnya:

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get pods -n kube-system -l app=ang-node
NAME                                                 READY   STATUS              RESTARTS        AGE
ang-node-5c6c8                                       0/3     ContainerCreating   0               2d21h
ang-node-6skkl                                       0/3     ContainerCreating   0               2d14h
ang-node-7d7dj                                       0/3     ContainerCreating   0               2d20h
ang-node-9l4xc                                       0/3     ContainerCreating   0               2d17h

    Error berikut akan muncul:

    Warning  FailedMount  112s (x2056 over 2d21h)  kubelet  MountVolume.SetUp failed for volume "vici" : hostPath type check failed: /var/run/strongswan is not a directory

  3. Terapkan perubahan berikut pada ang-overrides AddonConfiguration di cluster Admin Org:

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG edit addonconfiguration ang-overrides -n org-1-system-cluster

    Ubah kode berikut:

                volumes:
            - hostPath:
                path: /var/run/strongswan
                type: Directory
              name: vici

    ke alamat berikut:

                volumes:
            - hostPath:
                path: /var/run
                type: Directory
              name: vici

  4. Setelah sekitar satu menit, konfirmasi bahwa Pod ang-node sekarang dalam status Running:

    NAME             READY   STATUS    RESTARTS   AGE
ang-node-7hj5q   3/3     Running   0          15s
ang-node-xps2m   3/3     Running   0          34s
ang-node-krx8p   3/3     Running   0          34s
ang-node-cbm1a   3/3     Running   0          34s

  5. Pastikan sesi BGP di Org System Cluster kini berjalan.

  6. Add-on meta-monitoring akan melanjutkan ke tahap berikutnya.

Upgrade org root macet karena kegagalan tugas tanda tangan

Versi: 1.13.3, 1.13.4

Gejala: Saat mengupgrade dari 1.13.3 ke 1.13.4, Anda mungkin melihat pesan seperti ini:

Message:       [the result has status: False, reason: PreflightCheckFailed, and err: check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, the result has status: Unknown, reason: UpgradeCheckJobsInProgress

Solusi:

  1. Nonaktifkan pemeriksaan pra-penerbangan:

    kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok

  2. Hapus tugas artifact-signature-verification-*** yang gagal.

  3. Tunggu hingga upgrade root selesai.

  4. Opsional: Aktifkan pemeriksaan pra-peluncuran jika lingkungan diupgrade ke 1.13.4 atau yang lebih baru.

Setelah pengontrol berada di 1.13.4, upgrade tidak akan mengalami masalah ini.

Upgrade organisasi tenant gagal pada tahap pemeriksaan Preflight dengan ErrImagePull

Versi: 1.13.3

Gejala: Upgrade organisasi tenant gagal pada tahap pemeriksaan pra-penerbangan dengan ErrImagePull untuk pod validasi paket. Anda mungkin melihat pesan seperti ini:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get po -n package-validation-system  | grep artifact-signature-verification

Pod menampilkan error ImagePullBackOff:

kubectl describe po -n package-validation-system POD_NAME

Error penarikan image ditampilkan, seperti contoh berikut:

Name:             artifact-signature-verification-20240823224755-4ppkt
Namespace:        package-validation-system
Priority:         0
Service Account:  package-validation
Node:             ak-ab-base02/203.0.113.250
Start Time:       Fri, 23 Aug 2024 22:47:55 +0000
Labels:           batch.kubernetes.io/controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  batch.kubernetes.io/job-name=artifact-signature-verification-20240823224755
                  controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  job-name=artifact-signature-verification-20240823224755
Annotations:      <none>
Status:           Pending
IP:               203.0.113.255
IPs:
  IP:           203.0.113.255
Controlled By:  Job/artifact-signature-verification-20240823224755
Containers:
  artifact-signature-verification:
    Container ID:
    Image:          gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
...
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned package-validation-system/artifact-signature-verification-20240823224755-4ppkt to ak-ab-base02
  Normal   Pulling    7m25s (x4 over 9m22s)   kubelet            Pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Failed to pull image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to pull and unpack image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to resolve reference "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": unexpected status from HEAD request to https://203.0.113.255/v2/private-cloud-staging/signature-verifier/manifests/v1.13.0-uporc-aa505d9004?ns=gcr.io: 401 Unauthorized
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Error: ErrImagePull
  Warning  Failed     7m3s (x6 over 9m11s)    kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m11s (x17 over 9m11s)  kubelet            Back-off pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"

Solusi:

Lewati pemeriksaan preflight:

kubectl annotate -n gpc-system organization ORG_NAME \
upgrade.private.gdc.goog/skip-preflight-check=ok

Tidak dapat menemukan serviceaccount selama upgrade organisasi root

Versi: 1.13.8, 1.13.9

Gejala: Selama upgrade ke 1.13.8, deployment addon untuk RBAC gagal jika ada upgrade sebelumnya yang dilakukan dan add-on sudah ada. Gejalanya dapat berada di salah satu tahap berikut:

  1. pemeriksaan sebelum atau sesudah penerbangan
  2. tahap apa pun yang melibatkan tugas upgrade dan pesan menunjukkan bahwa tugas sedang berjalan meskipun tugas macet. Pesan status.conditions menunjukkan bahwa tugas berjalan dalam waktu yang lama, yang mengindikasikan adanya masalah.

Untuk memeriksa apakah ada kegagalan pemeriksaan pendahuluan upgrade, periksa status objek OrganizationUpgrade yang sesuai untuk organisasi yang melakukan upgrade:

  kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml

  1. Jika tugas gagal di PreflightCheck, tugas mungkin menampilkan kegagalan seperti ini atau pesan UpgradeCheckRBACDeploymentInProgress:

      - lastTransitionTime: "2024-09-27T00:28:21Z"
    message: ""
    observedGeneration: 2
    reason: Unknown
    status: "False"
    type: PreflightCheck

  2. Jika tugas gagal pada tahap AnthosBareMetal (ABM) saat tugas sedang berjalan, output berikut akan ditampilkan:

    - Last Transition Time:  2024-09-26T19:55:13Z
  message:               observed the following reason: [JobRunning]
  observedGeneration:    3
  reason:                Unsuccessful
  status:                Unknown
  type:                  root-admin/AnthosBareMetal

  3. Jika kegagalan terjadi dalam pemeriksaan, upgradecheckrequest CR akan gagal:

    kubectl get upgradecheckrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

    Output-nya mungkin terlihat seperti contoh ini:

    NAME                                   AGE
upgrade-check-root-postflight-xc7p8    6h32m

  4. Jika kegagalan terjadi pada tugas, CR upgradetaskrequests akan gagal:

    kubectl get upgradetaskrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

    Output-nya mungkin terlihat seperti contoh ini:

    NAME                                          AGE
upg-task-org-1-mz-mz-location-upgrade-5n6wp   2d19h

  5. Jika kegagalan menunjukkan error RBAC saat mencari akun layanan, periksa apakah add-on sebelumnya telah di-deploy:

    Type     Reason        Age                   From            Message
----     ------        ----                  ----            -------
Warning  FailedCreate  38s (x11 over 5m41s)  job-controller  Error creating: pods "v1.13.0-mz-2837f80328-upg-task-root-mz-mz-location-jkv69-" is forbidden: error looking up service account gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

Solusi:

  1. Periksa apakah add-on sebelumnya di-deploy:

      Type     Reason        Age                    From            Message
  ----     ------        ----                   ----            -------
  Warning  FailedCreate  4m30s (x101 over 99m)  job-controller  Error creating: pods "v1.13.0-os-2837f80328-upg-task-root-os-node-upgrad-fdblm-" is forbidden: error looking up service account gpc-system/upgrade-task-os-sa-v1.13.0-os-2837f80328: serviceaccount "upgrade-task-os-sa-v1.13.0-os-2837f80328" not foundcount gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

  2. Dapatkan add-on sebelumnya yang ada untuk komponen yang sama, upgrade-task-mz untuk tugas:

    kubectl get addons -n gpc-system | grep upgrade-task
upgrade-task-mz-lsqzc            true       true    v1.13.0-mz-7cf810d7a5

  3. Hapus add-on ini:

    kubectl delete addon -n gpc-system upgrade-task-mz-lsqzc upgrade-task-os-px5wj
addon.addon.private.gdc.goog "upgrade-task-mz-lsqzc" deleted

  4. Setelah menghapus add-on, hapus juga upgradetaskrequest atau upgradecheckrequest yang sesuai. Elemen tersebut akan dibuat ulang.

    kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc

  5. Lanjutkan pemantauan upgradetaskrequest, upgradecheckrequest yang baru dibuat atau tugas yang sesuai secara langsung.

Upgrade gagal di shared-service-cluster upgrade

Versi: 1.13.3

Gejala: Upgrade Anthos Bare metal macet dengan satu atau beberapa mesin bare metal. Semua mesin bare metal lainnya telah berhasil diupgrade atau belum memulai upgrade. Satu mesin bare metal dalam mode pemeliharaan, tetapi masih menampilkan versi sebelumnya untuk kolom ABM VERSION dan DESIRED ABM VERSION saat ini.

Ikuti Anthos bare metal untuk mendapatkan status dan detail baremetalmachine untuk cluster:

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

Output yang diharapkan:

NAME           CLUSTER                  READY   INSTANCEID                  MACHINE         ABM VERSION        DESIRED ABM VERSION
192.0.2.0      g-org-1-shared-service   true    baremetal://192.0.2.0       192.0.2.0       1.29.300-gke.185   1.29.300-gke.185
192.0.2.18     g-org-1-shared-service   true    baremetal://192.0.2.18      192.0.2.18      1.29.300-gke.185   1.29.300-gke.185
192.0.2.19     g-org-1-shared-service   true    baremetal://192.0.2.19      192.0.2.19      1.29.300-gke.185   1.29.300-gke.185
192.0.2.10     g-org-1-shared-service   true    baremetal://192.0.2.10      192.0.2.10      1.29.300-gke.185   1.29.300-gke.185
192.0.2.22     g-org-1-shared-service   true    baremetal://192.0.2.22      192.0.2.22      1.29.300-gke.185   1.29.300-gke.185
192.0.2.9      g-org-1-shared-service   true    baremetal://192.0.2.9       192.0.2.9       1.29.0-gke.1449    1.29.0-gke.1449 

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG} ${MACHINE_IP}  -o json | jq '.status.underMaintenance'

Output yang Diharapkan:

true

Solusi:

  1. Keluarkan mesin inventaris dari mode pemeliharaan:

    export InventoryMachineName=$(kubectl --kubeconfig=${ADMIN_KUBECONFIG} get inventorymachines -A  -o json | jq '.items[] | select(.spec.address=="${MACHINE_IP}") | .metadata.name')
kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" patch inventorymachine/${InventoryMachineName:?} --type=merge  -p '{"spec": {"maintenance": false}}'

  2. Tunggu hingga mesin inventaris keluar dari mode pemeliharaan. Proses ini dapat memerlukan waktu hingga 10 menit.

    kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" wait inventorymachine/${InventoryMachineName} --for=jsonpath=.status.maintenance=true --timeout=600s

  3. Pantau baremetalmachine untuk melihat bahwa mesin melihat update versi ABM yang dipilih.

    kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

Penginstalan add-on system-dashboards gagal

Versi: 1.13.5

Gejala: Upgrade dari 1.12.4 ke 1.13.5 gagal saat upgrade add-on untuk add-on system-dashboards:

│ Status:                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                  │
│     Last Transition Time:  2024-10-22T00:34:54Z                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to rollback chart: no ConfigMap with the name "cluster-etcd-platform-obs" found                    │
│     Observed Generation:   2                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                   │
│     Status:                False

Solusi: Ikuti langkah-langkah dalam runbook OCLCM-R0122.

NodeUpgradeTask CR macet pada kondisi NodeOSInPlaceUpgradePostProcessingCompleted

Versi: 1.13.5

Gejala: Selama upgrade ke 1.13.5, NodeUpgradeTask CR mengalami masalah pada kondisi NodeOSInPlaceUpgradePostProcessingCompleted.

Periksa apakah tugas os-artifact-collector yang sesuai telah selesai. Jika tugas macet selama berjam-jam, pesan berikut akan ditampilkan:

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

Solusi:

  1. Hapus tugas atau pod untuk memaksa percobaan ulang.

Distribusi gambar gagal selama upgrade

Versi: 1.13.5

Gejala: Distribusi gambar gagal selama upgrade dari 1.12.4 ke 1.13.x:

Error: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
F1018 02:04:46.191627       1 main.go:88] VM Image Distributor quit: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
goroutine 1 [running]:

Periksa pod obj-proxy di gpc-system di org untuk melihat bahwa pod tersebut gagal melakukan verifikasi sertifikat:

E1021 19:10:31.710076       1 token_source.go:185] Unable to rotate token: failed to initialize aisClient: failed to initialise AIS client: failed to obtain login config from the provided path "https://console.org-1.zone1.google.gdch.test/.well-known/login-config" with error: unable to parse centralized login config file: unsuccessful get request to config URL (https://console.org-1.zone1.google.gdch.test/.well-known/login-config) with error: Get "https://console.org-1.zone1.google.gdch.test/.well-known/login-config": tls: failed to verify certificate: x509: certificate signed by unknown authority

Solusi:

  1. Mulai ulang pod obj-proxy menggunakan KUBECONFIG organisasi yang gagal:

    export KUBECONFIG=<ORG_KUBECONFIG>
kubectl delete pods -n gpc-system -l name=obj-proxy-manager

  2. Periksa log untuk obj-proxy: 

    kubectl get pods -n gpc-system | grep obj-proxy

    Output yang diharapkan adalah sebagai berikut:

    obj-proxy-gdgzp                                                1/1     Running     0              5d1h
obj-proxy-nhnsm                                                1/1     Running     0              5d1h
obj-proxy-wrxlq                                                1/1     Running     0              5d1h

  3. Periksa log pod yang tersedia, misalnya: 

    kubectl logs obj-proxy-gdgzp -n gpc-system

  4. Tugas distribusi gambar akan selesai setelah menerapkan solusi sementara.

Node gagal selama upgrade cluster pengguna

Versi: 1.13.3

Gejala: Tugas yang berjalan di node gagal selama upgrade cluster pengguna dan menampilkan pesan error seperti ini:

 Reason: mkdir: cannot create directory '/root/.ansible/tmp/ansible-tmp-1727810181.4584012-29-114086005628321': No space left on device

  1. Login ke node dan periksa apakah partisi penuh:

    df -h /

    Output-nya mungkin terlihat seperti contoh ini:

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--root   31G   31G  120K 100% /

  2. Periksa apakah /etc/kubernetes/tmp menggunakan ruang penyimpanan yang besar: du -s /etc/kubernetes/tmp. Masalah ini terjadi saat Kubernetes membuat lebih banyak cadangan dari biasanya.

Solusi:

  1. Hapus semua cadangan di rm -f /etc/kubernetes/tmp/*:

    df -h /

    Output-nya mungkin terlihat seperti contoh ini:

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/m

Upgrade admin root dibuat ulang dan gagal untuk pemeriksaan pra-penerbangan

Versi: 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9

Gejala: Upgrade organisasi root gagal untuk pemeriksaan pra-peluncuran, misalnya:

│   Preflight Check:                                                                                                                                                             │
│     Conditions:                                                                                                                                                                │
│       Last Transition Time:  2024-10-28T14:17:31Z                                                                                                                              │
│       Message:               [the result has status: False, reason: PreflightCheckFailed, and err: check "ASMStable" of operable component "ASM" failed with reason "BackoffLi │
│ mitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-asmstable-4dw66-cld74, gpc-system/upgrade-managed-check-asmstable-4dw66-k8xk5, gpc-system/upgrade-m │
│ anaged-check-asmstable-4dw66-wtc6q, gpc-system/upgrade-managed-check-asmstable-4dw66-l9b6v, gpc-system/upgrade-managed-check-asmstable-4dw66-nf62h, gpc-system/upgrade-managed │
│ -check-asmstable-4dw66-6m7p2, gpc-system/upgrade-managed-check-asmstable-4dw66-4mqmb], the result has status: Unknown, reason: UpgradeCheckJobsInProgress, and err: upgrade ch │
│ eck jobs in progress for Operable Components: haas,bil]                                                                                                                        │
│       Observed Generation:   2                                                                                                                                                 │
│       Reason:                PreflightCheckFailed                                                                                                                              │
│       Status:                False                                                                                                                                             │
│       Type:                  Succeeded                                                                                                                                         │
│     Start Time:              2024-10-28T14:46:42Z

Cluster root-admin dan kubeapiserver untuk root-admin telah diupgrade ke versi abm yang dipilih.

Contoh:

export KUBECONFIG=<path to root admin kubeconfig>
kubectl describe kubeapiserver root-admin -n root
kubectl get cluster root-admin -n root

Contoh output untuk kubectl describe kubeapiserver root-admin -n root:

Name:         root-admin
Namespace:    root
Labels:       lcm.private.gdc.goog/cluster-type=root-admin
              lcm.private.gdc.goog/cluster-version=1.29.600-gke.108
              lcm.private.gdc.goog/component-version=v1.13.0-oclcm-f4c190e0f2

Contoh output untuk kubectl get cluster root-admin -n root:

NAME         ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
root-admin   1.29.600-gke.108   1.29.600-gke.108      Running

Solusi

Terapkan lewati pemeriksaan awal untuk melanjutkan upgrade:

export KUBECONFIG=<path to root admin kubeconfig>
kubectl delete organizationupgrade root -n gpc-system && kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok 
kubectl delete organizationupgrade root -n gpc-system

Namespace platform-obs-obs-system atau platform-obs macet dalam status menghentikan

Versi: 1.13.5

Gejala: Addon gagal di-deploy selama upgrade atau bootstrap dan menampilkan pesan error seperti ini: 

 export KUBECONFIG=ROOT_ADMIN
 kubectl get addon -n org-1 system-alerts system-dashboards

Output berikut akan ditampilkan:

  NAME                DEPLOYED   READY   VERSION
  system-alerts
  system-dashboards   false      false   1.12.4-gdch.96

Jika status DEPLOYED atau READY menampilkan false atau kosong, periksa add-on masing-masing untuk mengetahui errornya, misalnya:

  export KUBECONFIG=ROOT_ADMIN
  kubectl describe addon -n org-1 system-alerts

Output berikut akan ditampilkan:

  ...
  ... unable to create new content in namespace platform-obs-obs-system because it is being terminated                             
  ...

Add-on diblokir karena mencoba membuat konten di namespace yang sedang dihapus. Pemblokiran ini tetap ada karena penghapusan namespace juga diblokir.

Solusi:

  1. Sebelum memulai upgrade, beri anotasi pada project untuk mencegah penghapusan:

    export KUBECONFIG=ORG_ADMIN
kubectl annotate project -n gpc-system platform-obs helm.sh/resource-policy="keep"

    Output berikut akan ditampilkan:

    project.resourcemanager.gdc.goog/platform-obs annotated
kubectl annotate project -n gpc-system platform-obs-obs-system helm.sh/resource-policy="keep"
project.resourcemanager.gdc.goog/platform-obs-obs-system annotated

    Jika lingkungan sudah mengalami gejala yang dijelaskan sebelumnya, lakukan solusi sementara berikut:

  2. Penghapusan namespace diblokir karena resource dengan finalizer. Untuk melanjutkan penghapusan, hapus finalizer menggunakan skrip yang disediakan: 

      export KUBECONFIG=ORG_ADMIN
  function rm_finalizer() {
      export TYPE=$1
      export NS=$2
      RESOURCES=$(kubectl get $TYPE -n $NS --no-headers -o custom-columns=":metadata.name")
      for rc in $RESOURCES; do
          kubectl patch $TYPE $rc -n $NS \
                  --type json \
                  --patch '{"metadata":{"finalizers":[]}}' --type=merge
      done
    }
    rm_finalizer "monitoringrule" "platform-obs-obs-system"
    rm_finalizer "monitoringrule" "platform-obs"
    rm_finalizer "loggingrule" "platform-obs"
```
Note: Use a bash terminal (default on bootstrappers) to run the script.

  3. Tunggu penghapusan resource. Setelah menjalankan skrip, hapus resource dan namespace yang terhenti. Anda mungkin perlu menjalankan skrip lagi jika namespace masih terjebak dalam status penghentian. Setelah dihentikan, namespace akan dibuat ulang secara otomatis. Verifikasi bahwa namespace dibuat ulang dan dalam status AKTIF:

      export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system

    Output berikut akan ditampilkan:

      NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s

    Dengan namespace aktif, add-on yang macet akan di-deploy dalam beberapa menit. Pastikan status DEPLOYED dan READY-nya kini benar:

      export KUBECONFIG=ROOT_ADMIN
  kubectl get addon -n org-1 system-alerts system-dashboards

    Output berikut akan ditampilkan:

      NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998

Loop error UPORC di cluster KIND selama bootstrap

Versi: 1.13.x

Gejala: Deployment uporc-root-backend-controller di bawah namespace uporc-system mengalami loop error di cluster KIND.

Solusi:

  1. Periksa apakah objek ComponentGroupReleaseMetadata dan ReleaseMetadata cocok:

    export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata

    Jika objek cocok, tidak diperlukan solusi.

  2. Jika objek tidak cocok, hubungi tim UPORC untuk mendapatkan bantuan karena hal ini dapat menunjukkan masalah mendasar lainnya.

Upgrade node gagal

Versi: 1.13.6

Gejala: Upgrade node gagal di NodeOSInPlaceUpgradeCompleted.

  1. Periksa log tugas os-upgrade ospolicy.
  2. Jika log menyertakan error yang menunjukkan bahwa file konfigurasi rusak, masuk ke mesin node dan periksa konten file secara manual untuk melihat apakah file tersebut rusak. Error log mungkin menyebutkan kode error configparser.DuplicateOptionError dan file /etc/yum.repos.d/gdch.repo.

Solusi: Hanya jika Anda telah mengonfirmasi bahwa file rusak, hapus file /etc/yum.repos.d/gdch.repo yang rusak secara manual di node yang rusak.

Pekerjaan ansible untuk upgrade akan membuat ulang file secara otomatis, sebagai bagian dari playbook ansible.

### CR NodeUpgradeTask macet pada kondisi NodeOSInPlaceUpgradePostProcessingCompleted

Versi: 1.13.5

Gejala: Selama upgrade ke 1.13.5, NodeUpgradeTask CR mengalami masalah pada kondisi NodeOSInPlaceUpgradePostProcessingCompleted.

Periksa apakah tugas os-artifact-collector yang sesuai telah selesai. Jika tugas macet selama berjam-jam, pesan berikut akan ditampilkan:

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

Solusi:

  1. Hapus tugas atau pod untuk memaksa percobaan ulang.

NodeUpgradeTask CR macet pada kondisi NodeBIOSFirmwareUpgradeCompleted

Versi: 1.13.5

Gejala: Selama upgrade ke 1.13.5, NodeUpgradeTask CR mengalami masalah pada kondisi NodeBIOSFirmwareUpgradeCompleted.

Periksa apakah kondisi NodeBIOSFirmwareUpgradeCompleted yang sesuai mengalami masalah dengan kondisi berikut yang ditampilkan:

  {
  "lastTransitionTime": "2024-12-03T04:03:37Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "InProgress",
  "status": "False",
  "type": "NodeBIOSFirmwareUpgradeCompleted"
  }

Solusi:

  1. Di CR NodeUpgrade, edit "U30 v3.20 (05/29/2024)" menjadi "U30 v3.20 (05/27/2024)" secara manual.

Upgrade cluster diblokir karena node gagal memasuki mode pemeliharaan

Versi: 1.13.5, 1.13.6, 1.13.7

Gejala: Upgrade cluster (admin org, sistem, atau cluster pengguna) diblokir karena node gagal memasuki mode pemeliharaan.

Cluster menampilkan MaintenanceMode yang ditetapkan ke true, tetapi Status macet di false saat menjalankan perintah berikut:

kubectl get baremetalmachines -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenace

Output berikut akan ditampilkan:

NAMESPACE           NAME            MaintenanceMode   Status
user-vm-1-cluster   10.8.4.22       true              false
user-vm-1-cluster   10.8.4.23       false             false
user-vm-1-cluster   10.8.4.24       false             false
user-vm-1-cluster   172.20.128.13   false             false
user-vm-1-cluster   172.20.128.14   false             false
user-vm-1-cluster   172.20.128.15   false             false

Solusi:

Tetapkan KUBECONFIG ke file kubeconfig cluster yang berisi node yang tidak dikuras. Cluster dapat berupa cluster pengguna atau cluster layanan bersama.

for VM in $(kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers | grep "baremetal.cluster.gke.io/maintenance" | awk '{print $1}'); do
  for i in {1..50}; do
    kubectl delete po -n kube-system $(kubectl get po -A -o wide  | grep ang | grep -e $VM| awk '{print $2}');
  done
done

Waktu tunggu yang persisten selama root awal organizationupgrade

Versi: 1.13.3

Gejala: Jika anotasi abaikan masa pemeliharaan ada selama upgrade organisasi, CR organizationupgrade akan di-patch berulang kali, sehingga mereset progres.

Solusi:

Jeda subkomponen rm-org dan turunkan skala replika rm-org-backend-controller.

  1. Jika alias tidak dideklarasikan, jalankan:

    alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"

  2. Jeda subkomponen dan turunkan skala deployment untuk rm-org:

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG annotate subcomponent -n root rm-org lcm.private.gdc.goog/paused=true
kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=0

  3. Setelah upgrade cluster selesai, turunkan skala deployment:

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

Subkomponen obj-syslog-server gagal rekonsiliasi di organisasi root

Versi: 1.13.3, 1.13.4, 1.13.5, 1.13.6

Gejala: Selama upgrade ke versi 1.13.x, subkomponen obj-syslog-server ditemukan dalam status ReconciliationError:

root        obj-syslog-server     ReconciliationError

dengan kondisi yang mirip dengan:

Sub-Component: obj-syslog-server - Reconciliation error: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded

Last Transition Time: 2024-09-17T21:49:25Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     ReconciliationError
     Status:True
     Type: Reconciling
     Last Transition Time: 2024-09-17T21:49:23Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     Reason: DeployError
     Status: False
     Type: Deployed

Anda mungkin melihat bahwa pod, syslog-server-abcdefg-wxyz, berada dalam status CrashLoopBackOff dengan error berikut:

       containerID: containerd://65d460176a1dcae412af698fa02fa5ffb0c5f0ef9bf0d0e2111ef88845630827
       exitCode: 128
       finishedAt: "2024-09-18T19:14:45Z"
       message: 'failed to create containerd task: failed to create shim task: OCI
         runtime create failed: runc create failed: unable to start container process:
         error during container init: error mounting "/var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2"
         to rootfs at "/etc/ssl/certs/obs-ca-cert.pem": mount /var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2:/etc/ssl/certs/obs-ca-cert.pem
         (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown'
       reason: StartError
       startedAt: "1970-01-01T00:00:00Z"

Solusi:

Untuk mengembalikan subkomponen ke status normal, hapus volumeMounts yang tidak diperlukan.

  1. Edit deployment saat ini:

    export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

    kubectl edit deployments syslog-server -n istio-system

  2. Hapus volumeMounts yang tidak diperlukan di spec.containers.volumeMounts. Hapus jalur pemasangan berikut:

        - mountPath: /etc/ssl/certs/obs-ca-cert.pem
      name: observability-ca
      readOnly: true1.
      subPath: ca.crt
    - mountPath: /etc/ssl/certs/obj-ca-cert.pem
      name: obj-ca
      readOnly: true
      subPath: ca.crt

  3. Terapkan perubahan dan subkomponen akan kembali ke ReconciliationCompleted setelah perubahan diterapkan.

Upgrade ABM atau Node terhenti di maintenanceMode false

Versi: 1.13.4

Gejala: Node macet saat upgrade cluster AnthosBaremetal dan node tidak memasuki mode pemeliharaan.

Periksa baremetalmachine di node cluster layanan, misalnya:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

Solusi:

Mulai ulang anthos-cluster-operator untuk menyebarkan BMM.MaintenanceMode:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

Upgrade gagal saat upgrade add-on atat-webhooks untuk org tenant

Versi: 1.13.5

Gejala: Upgrade add-on atat-webhooks gagal dipulihkan:

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

Anda mungkin melihat pesan seperti ini:

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

Periksa pod untuk atat-webhooks-parameters-*****: 

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

Anda mungkin melihat error seperti ini:

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

Solusi:

  1. Membuat salinan portofolio saat ini:

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

    kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

  2. Update portfolio-org-1 Pop End Date ke tanggal mendatang:

    kubectl delete portfolios -n atat-system portfolio-org-1

    Jika perintah ini berhenti merespons, hapus kondisi .Metadata.Finalizers dari portofolio aktif sebelum menghapus portofolio. Kondisinya mungkin terlihat seperti ini:

    │     portfolio.finalizers.atat.config.google.com

  3. Terapkan kembali file YAML yang disalin:

    kubectl apply -f portfolio-org-1

  4. Periksa kembali tanggal untuk memastikan bahwa portofolio dan configmap telah diperbarui.

  5. Jika tugas tidak pulih, hapus tugas atat-webhooks-parameters yang gagal dan tugas akan pulih. Tunggu hingga selesai:

    kubectl delete jobs -n org-1 atat-webhooks-parameters

Postflight atau upgrade-check gagal karena error DeadlineExceeded atau BackoffLimitExceeded.

Versi: 1.13.8

Gejala:

Saat mengupgrade 1.13.7 ke 1.13.8, pemeriksaan pasca-peluncuran masih dalam status tertunda dan menampilkan error DeadlineExceeded atau BackoffLimitExceeded.

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

Solusi:

Identifikasi tempat terjadinya kegagalan tugas:

  1. Periksa apakah tugas gagal selama pemeriksaan pra-penerbangan atau pasca-penerbangan:

    kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  2. Periksa apakah tugas gagal selama upgrade:

    kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  3. Hapus tugas:

    kubectl delete jobs -n gpc-system CHECK_NAME

Pemeriksaan upgrade mencakup hasil yang tidak relevan dengan tingkat pemeriksaan

Versi: 1.13.x

Gejala:

Pemeriksaan upgrade organisasi mungkin gagal karena hasil yang disertakan secara tidak benar dari tingkat lainnya. Misalnya, pemeriksaan organisasi root dapat menampilkan hasil organisasi tenant, atau pemeriksaan organisasi tenant dapat menampilkan hasil cluster pengguna.

Contoh log kegagalan untuk pemeriksaan organisasi root:

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

Solusi:

Lewati pemeriksaan preflight atau postflight sepenuhnya dengan:

Preflight:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Setelah penerbangan:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok

Vertex AI

API terlatih menampilkan status Enabling di antarmuka pengguna

Versi: 1.13.1

Gejala: MonitoringTarget menampilkan status Not Ready saat cluster pengguna sedang dibuat, sehingga menyebabkan API yang telah dilatih sebelumnya terus menampilkan status Enabling di antarmuka pengguna.

Solusi:

  1. Buka menu di browser Chrome Anda (ikon tiga titik).
  2. Klik Alat lainnya > Alat developer untuk membuka konsol.
  3. Klik tab Network di konsol.
  4. Temukan permintaan ai-service-status.
  5. Klik tab Response dalam permintaan ai-service-status untuk menampilkan isi permintaan tersebut.
  6. Pastikan semuanya sudah siap kecuali komponen MonitoringTarget dan LoggingTarget.

Fungsi API terlatih streaming_recognize Speech-to-Text gagal

Versi: 1.13.3

Gejala: Saat memanggil fungsi API Speech-to-Text yang telah dilatih sebelumnya streaming_recognize, masalah pada library klien menyebabkan pesan error 400 yang mirip dengan berikut ini:

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

Solusi: Gunakan skrip Python berikut agar fungsi streaming_recognize dapat berfungsi:

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

Ganti kode berikut:

Skrip Python memperkenalkan perbedaan berikut antara fungsi streaming_recognize dan recognize agar solusi untuk streaming_recognize berfungsi:

  • Baris 4: Pernyataan import tambahan dibandingkan dengan skrip recognize (from google.cloud.speech_v1p1beta1.services.speech import client).
  • Baris 18: Klien ditampilkan oleh client.SpeechClient(), bukan speech_v1p1beta1.SpeechClient().

Pod dan layanan frontend Translation gagal diinisialisasi

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

Gejala: Selama upgrade, cluster DB Translation dibuat ulang, yang menyebabkan rahasia cluster sistem ODS secret-store menjadi tidak berlaku dan tidak sinkron. Oleh karena itu, pod dan layanan frontend Terjemahan gagal diinisialisasi.

Solusi:

Hapus secret di cluster sistem:

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

Ganti SYSTEM_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig di cluster sistem.

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

Polling status tugas tidak didukung untuk batchTranslateDocument API

Versi: 1.13.3

Gejala: Vertex AI tidak mendukung operasi GET dan LIST di API layanan Terjemahan. Memanggil Translation BatchTranslateDocument API akan menampilkan operasi yang berjalan lama yang mirip dengan contoh berikut:

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

Masalah ini disebabkan oleh batasan APIP (otorisasi) yang mencegah Anda memanggil endpoint secara langsung. Endpoint tidak mendukung polling status tugas, dan Anda tidak dapat melakukan operasi GET pada operasi yang berjalan lama karena batasan APIP.

Solusi: Sebagai Operator Aplikasi (AO), tinjau status tugas dengan memeriksa folder s3_destination Anda secara rutin dan cari file output tugas yang baru dibuat. Jika folder berisi file output, tugas berhasil diselesaikan.

Permintaan batchTranslateDocument dapat menyebabkan masalah performa

Versi: 1.13.3

Gejala: Layanan terjemahan dokumen batch membaca satu atau beberapa file input pengguna dan menulis file output terjemahan dan pemrosesan sementara di StorageGRID. Klien curl baru dibuat untuk setiap tindakan baca-tulis karena penggunaan ulang klien gagal.

Klien curl S3 dalam biner adalah penggunaan satu kali, yang berarti bahwa setiap klien hanya dapat melakukan satu tindakan baca-tulis pada bucket StorageGRID. Oleh karena itu, klien curl baru dibuat setiap kali komunikasi dengan klien StorageGRID dilakukan dari server batchTranslateDocument untuk membaca dan menulis file dalam bucket.

Namun, hal ini tidak optimal untuk klien curl. Hal ini dapat menyebabkan masalah berikut:

  • Penurunan performa: peningkatan latensi dan penurunan throughput
  • Kehabisan resource: overhead memori dan CPU serta kehabisan soket
  • Server kelebihan beban: pembatasan kapasitas atau pembatasan

Konsol GDC menampilkan status yang tidak konsisten setelah mengaktifkan API terlatih

Versi: 1.13.3

Gejala: Saat Anda pertama kali mengaktifkan API terlatih, konsol GDC mungkin menampilkan status yang tidak konsisten setelah beberapa menit untuk layanan yang diaktifkan. Konsol GDC mengalihkan status Enabling kembali ke Disabled dan menampilkan tombol Aktifkan lagi di antarmuka pengguna meskipun layanan sebenarnya sedang diaktifkan.

Solusi: Status akan menjadi konsisten setelah beberapa menit, dan layanan akan mencerminkan status yang benar.

Untuk memverifikasi status layanan, buka tab Network di konsol browser dan periksa status permintaan ai-service-status. Payload harus menunjukkan bahwa operator L2 diaktifkan.

Permintaan terjemahan dengan lebih dari 250 karakter menyebabkan pod translation-prediction-server error

Versi: 1.13.3

Gejala: Saat Anda mengirim permintaan Terjemahan dengan sekitar 250 karakter atau lebih (termasuk permintaan terjemahan dokumen), pod translation-prediction-0 atau translation-prediction-1 mungkin mengalami error, sehingga memerlukan pemuatan ulang model. Pemuatan ulang model terjadi secara otomatis, dan proses ini dapat memerlukan waktu sekitar 30 menit untuk diselesaikan.

Masalah ini disebabkan oleh batasan pada penampung Terjemahan.

Solusi: Pisahkan permintaan Terjemahan agar panjangnya kurang dari 250 karakter. Rentang antara 200 dan 250 karakter aman untuk semua bahasa. Tidak ada tindakan lain yang diperlukan untuk mengurangi masalah jika permintaan yang panjang menyebabkan pod mengalami error.

GPUAllocation untuk cluster layanan bersama tidak dikonfigurasi dengan benar

Versi: 1.13.3

Gejala: Workload Vertex AI tidak dapat dijadwalkan karena kurangnya resource GPU yang memadai. Misalnya, jika Anda tidak dapat melihat atau mengaktifkan endpoint layanan Vertex AI, hal ini dapat disebabkan oleh kurangnya resource GPU yang memadai.

Masalah penyediaan resource ini dapat disebabkan oleh beberapa resource GPUAllocation yang berada dalam cluster layanan bersama yang tidak memiliki anotasi berikut:

processed: "true"

Solusi:

  1. Ikuti IAM-R0004 untuk membuat file kubeconfig untuk g-ORG_NAME-shared-service-cluster.

  2. Mencantumkan semua alokasi GPU di cluster layanan yang tidak memiliki anotasi processed: "true":

    kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

    Outputnya mirip dengan hal berikut ini:

    zi-ad-bm08

  3. Untuk resource GPUAllocation yang tidak dialokasikan, buka di editor:

    kubectl edit gpuallocation -n vm-system NODE_NAME

  4. Edit alokasi GPU berdasarkan jumlah total alokasi GPU yang ada di cluster layanan:

    • Jika hanya ada satu resource kustom alokasi GPU, tambahkan anotasi processed: "true" ke resource tersebut dan ubah spesifikasinya agar seperti berikut:

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • Jika ada dua resource kustom alokasi GPU, temukan yang tanpa anotasi processed: "true", tambahkan anotasi processed: "true" ke resource tersebut, dan ubah spesifikasinya agar seperti berikut:

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • Jika ada empat resource kustom alokasi GPU, temukan yang tanpa anotasi processed: "true", tambahkan anotasi processed: "true" ke resource tersebut, dan ubah spesifikasinya agar seperti berikut:

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0

  5. Simpan perubahan pada resource kustom GPUAllocation dan konfirmasi bahwa status alokasinya diperbarui menjadi true:

    kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

    Outputnya mirip dengan hal berikut ini:

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

Saat mengupgrade dari versi 1.9.x ke 1.13.3, pengontrol OCLCM menampilkan error

Versi: 1.13.3

Gejala: Saat mengupgrade dari versi 1.9.x ke 1.13.3, pengontrol Operable Component Lifecycle Management (OCLCM) untuk subkomponen Vertex AI mungkin menampilkan error. Masalah ini disebabkan oleh error pada tugas add-on ai_platform. Error yang Anda terima selama upgrade menunjukkan bahwa OCLCM tidak dapat mentransfer kepemilikan komponen Vertex AI ini.

Berikut adalah komponen Vertex AI yang terpengaruh di cluster admin org:

Nama Namespace
aip-l1operator-deployment ai-system
aip-l2operator-deployment ai-system
aip-web-plugin-frontend ai-system
aip-web-plugin-backend ai-system
aip-l1operator-sa ai-system
aip-l2operator-sa ai-system
aip-web-plugin-sa ai-system
aip-l1operator-role T/A
aip-l2operator-role T/A
aip-web-plugin-role T/A
aip-l1operator-rolebinding T/A
aip-l2operator-rolebinding T/A
aip-web-plugin-rolebinding T/A
aip-l1operator-log ai-system
aip-l2operator-log ai-system
aip-web-plugin-frontend-log ai-system
aip-web-plugin-backend-log ai-system
log-rule-aipl-a004 platform-obs
mon-rule-aipl-a0001 platform-obs
mon-rule-aipl-a0003 platform-obs
aip-l1operator-mon ai-system
aip-l1operator-mon-cm ai-system
aip-l2operator-mon ai-system
aip-l2operator-mon-cm ai-system
aip-l1operator-webhook-svc ai-system
aip-web-plugin-frontend-svc ai-system
aip-web-plugin-backend-svc ai-system
aip-web-plugin-frontend-virtualsvc ai-system
aip-web-plugin-backend-virtualsvc ai-system
aip-l1operator-selfsigned-issuer ai-system
aip-l1operator-serving-cert ai-system
aip-l1operator-validating-webhook ai-system
aip-l1operator-mutating-webhook ai-system

Solusi: Untuk mengatasi masalah ini, Anda harus menghapus komponen Vertex AI yang terpengaruh secara manual dari cluster admin org. Kemudian, Vertex AI versi baru berbasis OCLCM akan menginstal ulang paket tersebut.

Hapus komponen Vertex AI yang terpengaruh secara manual di cluster admin org:

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

Ganti kode berikut:

  • ORG_ADMIN_CLUSTER_KUBECONFIG: jalur ke file kubeconfig di cluster admin org.
  • NAMESPACE: namespace komponen Vertex AI yang ingin Anda hapus. Jika komponen tidak memiliki namespace, hapus -n NAMESPACE dari perintah.
  • COMPONENT_NAME: nama komponen Vertex AI yang ingin Anda hapus.

Contoh berikut menunjukkan cara menghapus komponen aip-l1operator-deployment yang ada di namespace ai-system pada cluster admin org:

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

Permintaan terjemahan dapat menghasilkan kode error RESOURCE_EXHAUSTED

Versi: 1.13.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.13.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: ORG_ADMIN_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true

    Ganti ORG_ADMIN_NAMESPACE dengan namespace cluster admin org.

  2. Terapkan resource kustom SubcomponentOverride ke cluster admin org:

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

    Ganti ORG_ADMIN_KUBECONFIG dengan jalur ke file kubeconfig di cluster admin org.

Layanan terlatih Vertex AI tidak tersedia

Versi: 1.13.7, 1.13.9

Gejala: Layanan OCR dan Terjemahan Vertex AI gagal dimulai karena masalah penjadwalan Kubernetes. Anda mungkin melihat peringatan seperti ini di log:

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

Solusi: Tambahkan lebih banyak node pekerja ke kumpulan default dan hapus pod di node GPU sehingga workload AI dapat dijadwalkan.

Mesin virtual

Impor image BYO gagal untuk image qcow2 dan raw

Versi: 1.13.1, 1.13.3

Gejala: Saat image VM lokal diimpor menggunakan CLI gdcloud compute images import, status impor macet di WaitingForTranslationVM atau ImportJobNotCreated. Hal ini karena disk sementara yang dibuat untuk menerjemahkan atau mengimpor menggunakan ukuran yang sama persis dengan image qcow2/raw, tetapi LUKS menambahkan overhead beberapa MiB yang menyebabkan penyediaan disk gagal.

Solusi:

Buat VirtualMachineImageImport baru secara manual dengan nama image yang sama, tetapi dengan spec.minimumDiskSize yang lebih besar

Misalnya, jika ini adalah perintah yang digunakan untuk mengimpor gambar:

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

Jika VirtualMachineImageImport asli yang dibuat secara otomatis oleh CLI memiliki minimumDiskSize sebagai X Gi, buat yang baru dengan X+1 Gi. Nilai didasarkan pada ukuran gambar yang diimpor. Untuk qcow2, ukurannya adalah ukuran virtual, misalnya 20Gi harus diganti dengan 21Gi.

Ganti nilai placeholder berdasarkan cara CLI dipanggil.

  1. Temukan VirtualMachineImageImport:

    kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml

    Jika objek tidak ada, picu kembali perintah gdcloud compute images import .... Setelah output konsol bertransisi dari Uploading image to .. ke Image import has started for ..., tekan ctrl+c agar image lokal diupload ke penyimpanan objek dan VirtualMachineImageImport dipertahankan sebagai referensi untuk membuat yang baru.

  2. Buat VirtualMachineImageImport baru dengan minimumDiskSize yang lebih besar:

    apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

Penyediaan disk dari image gagal

Versi: 1.13.1, 1.13.3

Gejala: Saat menyediakan disk dari image kustom, minimumDiskSize mungkin terlalu dekat dengan ukuran virtual, sehingga menyebabkan penyediaan disk gagal. Disk VM dalam status tertunda, tetapi tidak pernah disediakan.

Solusi: Buat disk baru secara manual dengan spec.minimumDiskSize yang lebih besar.

Plugin perangkat NVIDIA DaemonSet gagal saat cluster memiliki GPU

Versi: 1.13.3

Gejala: Plugin perangkat NVIDIA DaemonSet gagal dengan pesan driver rpc error di node cluster dengan GPU:

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Ganti KUBECONFIG dengan jalur ke file kubeconfig di cluster.

Anda akan mendapatkan output yang mirip dengan contoh berikut:

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

Masalah ini menyebabkan GPU tidak tersedia untuk mesin virtual (VM) dan pod. Implikasinya didasarkan pada jenis cluster berikut:

  • Cluster sistem: Resource kustom GPUAllocation tidak dibuat untuk node bare metal tersebut, dan GPU di node tersebut tidak dikonfigurasi dalam mode VM untuk digunakan oleh cluster layanan dan pengguna. Lihat solusi untuk cluster sistem guna mengatasi masalah ini.
  • Cluster layanan atau pengguna: Resource kustom GPUAllocation tidak dibuat untuk node VM tersebut, dan GPU di node tersebut tidak dapat digunakan oleh pod di cluster. Lihat solusi untuk layanan atau cluster pengguna guna mengatasi masalah ini.

Solusi untuk cluster sistem:

Ikuti langkah-langkah berikut untuk menyelesaikan masalah di cluster sistem:

  1. Tetapkan variabel lingkungan KUBECONFIG dengan jalur ke file kubeconfig di cluster sistem. Untuk mengetahui detailnya, lihat buku pedoman IAM-R0004.

  2. Identifikasi node yang mengalami masalah:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    Output harus mencetak nama node dan alamat IP node Kubernetes.

    Jika ada beberapa node, jalankan langkah-langkah di semua node tersebut. Dalam hal ini, outputnya akan terlihat seperti contoh berikut:

    Node:                 yy-ab-bm04/172.20.128.26

  3. Tetapkan variabel lingkungan NODE_NAME dengan nama node, misalnya:

    export NODE_NAME=yy-ab-bm04

  4. Buat koneksi SSH dengan node. Untuk mengetahui detailnya, lihat buku pedoman PLATAUTH-G0001.

  5. Verifikasi bahwa node memiliki GPU:

    nvidia-smi -L

    Output harus mencetak GPU di node seperti dalam contoh berikut:

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

  6. Aktifkan mode persistensi di GPU:

    nvidia-smi -pm 1

    Tindakan ini memastikan bahwa driver NVIDIA selalu dimuat sehingga plugin perangkat tidak mengalami waktu tunggu habis.

    Output harus terlihat seperti contoh berikut:

    Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.

  7. Keluar dari sesi SSH:

    exit

  8. Pastikan plugin perangkat berjalan dengan membuat kueri DaemonSet:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. Pastikan resource kustom GPUAllocation dibuat dan dikonfigurasi dalam mode VM:

    kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    Output harus terlihat seperti contoh berikut:

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

Solusi untuk layanan atau cluster pengguna:

Ikuti langkah-langkah berikut untuk menyelesaikan masalah di layanan atau cluster:

  1. Tetapkan variabel lingkungan KUBECONFIG dengan jalur ke file kubeconfig di cluster layanan atau pengguna. Untuk mengetahui detailnya, lihat buku pedoman IAM-R0004.

  2. Identifikasi node yang mengalami masalah:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    Output harus mencetak nama node dan alamat IP node Kubernetes.

    Jika ada beberapa node, jalankan langkah-langkah di semua node tersebut. Dalam hal ini, outputnya akan terlihat seperti contoh berikut:

    Node:                 vm-948fa7f4/172.20.128.21

  3. Tetapkan variabel lingkungan NODE_NAME dengan nama node, misalnya:

    export NODE_NAME=vm-948fa7f4

  4. Buat koneksi SSH dengan node. Untuk mengetahui detailnya, lihat buku pedoman PLATAUTH-G0001.

  5. Verifikasi bahwa node memiliki GPU:

    nvidia-smi -L

    Output harus mencetak GPU di node seperti dalam contoh berikut:

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

  6. Aktifkan mode persistensi di GPU:

    nvidia-smi -pm 1

    Tindakan ini memastikan bahwa driver NVIDIA selalu dimuat sehingga plugin perangkat tidak mengalami waktu tunggu habis.

    Output harus terlihat seperti contoh berikut:

    Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.

  7. Keluar dari sesi SSH:

    exit

  8. Pastikan plugin perangkat berjalan dengan membuat kueri DaemonSet:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. Pastikan resource kustom GPUAllocation dibuat dan dikonfigurasi dalam mode VM:

    kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    Output harus terlihat seperti contoh berikut:

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

VM cluster sistem belum siap

Versi: 1.13.3

Gejala: VM cluster sistem belum siap. Anda mungkin melihat pesan seperti ini:

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

Solusi:

  1. Temukan VirtualMachineInstance, lalu hapus.
  2. Mulai ulang VM baru.

Ruang sementara laporan volume data tidak ditemukan

Versi: 1.13.3, 1.13.4

Gejala: Saat membuat disk VM, volume data dilaporkan berhasil:

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

Namun, pod pengimpor, seperti importer-gdc-vm-disk-vm-ce34b8ea-disk crash loop dengan pesan seperti ini:

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

Solusi: Hapus pod pengimpor setelah mengonfirmasi bahwa status volume data adalah Succeeded.

VM dalam project dengan nama yang melebihi 45 karakter akan tetap dalam status dihentikan

Versi: 1.13.5

Gejala: Saat membuat VM, VM tetap dalam status Stopped jika nama project memiliki lebih dari 45 karakter.

Solusi: Buat project dengan nama yang tidak lebih dari 45 karakter.

Alokasi GPU tidak ada di cluster layanan

Versi: 1.13.5

Gejala: GPUAllocation tidak ada di cluster layanan bersama gpu-org. Anda mungkin melihat pesan saat mendapatkan alokasi GPU:

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

Outputnya akan terlihat seperti ini: 

No resources found

Solusi:

  1. Tambahkan taint ke node GPU:

    taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

  2. Hapus taint untuk mengizinkan penjadwalan pod virt-launcher VM.

Tidak dapat menjadwalkan VM pekerja cluster layanan bersama

Versi: 1.13.6

Gejala: VM pekerja Kubernetes gagal dijadwalkan karena resource CPU yang tidak memadai pada node yang ditentukan, meskipun GPU tersedia. Anda mungkin melihat peristiwa seperti ini:

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

Solusi:

  1. Hentikan VM non-GPU secara manual untuk membebaskan resource CPU.
  2. Setelah VM yang tertunda dijadwalkan, mulai VM non-GPU.