Cluster penyimpanan untuk pencadangan volume menggunakan server DNS eksternal, bukan penerus, yang mencegah pencadangan volume menyelesaikan endpoint penyimpanan objek tingkat org. Pada versi 1.12, traffic pencadangan memerlukan
rute baru ke setiap organisasi.
Solusi:
IO harus mengupdate cluster penyimpanan untuk mengaktifkan penyelesaian DNS tingkat organisasi,
dan untuk membuat rute dari antarmuka logis (LIF) replikasi ke
endpoint penyimpanan objek di setiap organisasi. Salin dan tempel
perintah berikut dari bootstrapper.
Mengirim permintaan ke gateway ingress admin org dari node ONTAP gagal karena
tidak ada rute dari subnet cadangan ke bidang kontrol org.
Solusi:
IO harus mengupdate cluster penyimpanan untuk mengaktifkan penyelesaian DNS tingkat organisasi,
dan untuk membuat rute dari antarmuka logis (LIF) replikasi ke
endpoint penyimpanan objek di setiap organisasi. Salin dan tempel
perintah berikut dari bootstrapper.
Jika repositori cadangan tidak memiliki status error apa pun, tetapi
notifikasi untuk repositori tersebut muncul, metrik notifikasi untuk repositori
tersebut mungkin muncul karena error. Ini adalah masalah umum di 1.12.0, dan telah diperbaiki
di 1.12.4. Penyebab masalah ini adalah bahwa repositori cadangan
secara berkala mencoba terhubung ke penyimpanan objek sebagai pemeriksaan kondisi, dan
memasuki status tidak responsif jika gagal terhubung. Namun, jika
repositori cadangan pulih, metrik untuk menunjukkan kondisinya tidak akan
beralih kembali dengan benar, sehingga menyebabkan pemberitahuan tetap berada dalam
status aktif tanpa batas.
Untuk mengatasi masalah ini, Anda dapat menghapus dan membuat ulang repositori cadangan secara manual untuk mereset metrik kondisinya. Ikuti langkah-langkah dalam
buku pedoman BACK-R0003 untuk membuat ulang repositori cadangan.
Pesan error: bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found
Subkomponen bil-storage-system-cluster gagal merekonsiliasi karena tugas yang sudah tidak berlaku. billing-storage-system-init-job-628 dan billing-storage-system-init-job-629 tetap ada setelah penyelesaian yang berhasil.
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 apakah ada deletionTimestamp. Jika tidak ada deletionTimestamp (migrasi Pod), ikuti langkah-langkah berikut:
Periksa VolumeAttachment untuk PVC guna mengidentifikasi tempat volume saat ini terpasang.
Batasi Nodes dalam cluster yang tidak cocok dengan nilai ini.
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:
Periksa VolumeAttachment untuk PVC guna mengidentifikasi tempat volume saat ini terpasang.
Di Node, keluarkan konten file pelacakannya:
cat/var/lib/trident/tracking/PVC_NAME.json
Validasi bahwa perangkat LUKS yang ditemukan di kolom devicePath dari output file pelacakan benar-benar ditutup. Jalur ini tidak boleh ada pada tahap ini:
statDEVICE_PATH
Validasi apakah nomor seri saat ini dipetakan ke perangkat multi-jalur.
Salin nilai di kolom iscsiLunSerial pada file pelacakan.
Konversi nilai ini menjadi nilai hex yang diharapkan:
echo'iISCSILUNSERIAL>'|xxd-l12-ps
Dengan nilai baru ini, cari tahu apakah entri multi-jalur masih ada:
multipath-ll|grepSERIAL_HEX
Jika tidak ada, hapus file pelacakan.
Jika ada, Anda akan melihat nilai hex serial yang sedikit lebih panjang daripada yang ditelusuri, yang akan disebut multipathSerial. Jalankan perintah berikut dan temukan perangkat blok:
multipath-llMULTIPATH_SERIAL
Kemudian, jalankan perintah berikut, dengan perintah terakhir dijalankan secara unik untuk setiap perangkat blok:
kubectl--kubeconfig=ADMIN_KUBECONFIGlogs-pkube-apiserver-{first_node_name}-nkube-system|grep"etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"
Output menampilkan hasil yang tidak kosong.
Solusi:
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 menggantikan
izin kembali ke root.
Mulai ulang etcd di node kedua untuk memulihkan
etcd di node pertama dari loop error.
Setelah menyelesaikan dua langkah ini, kube-apiserver di node pertama mulai
berjalan, dan tugas machine-init berikutnya berhasil.
Setelah Anda selesai menyiapkan ekspor ke sistem SIEM eksternal, input SIEM tidak disertakan dalam pipeline pemrosesan Fluent Bit dan log server Kubernetes API tidak ada di SIEM ini.
Saat mengupgrade dari versi 1.12.2 ke 1.12.4, jika node dihapus lalu ditambahkan kembali, proses machine-init untuk node tersebut mungkin gagal.
Kegagalan ini terjadi karena traffic jaringan dari node yang ditambahkan kembali ke layanan bidang kontrol penting ditolak oleh kebijakan ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes.
Error ini ditandai oleh pesan status dalam contoh output ini:
Tambahkan CIDR ini ke ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, khususnya ke kolom .spec.ingress.fromCIDR. Terapkan perubahan ini di cluster admin root dengan perintah:
Mendapatkan CIDR untuk organisasi (misalnya, org-1) dari CIDRClaim/org-external-cidr -n org-1 (khususnya kolom .status.ipv4AllocationStatus.allocatedCidrBlocks). Perintah ini dijalankan terhadap cluster admin root untuk mendapatkan CIDR 'org-1':
Tambahkan CIDR ini ke ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, khususnya ke kolom .spec.ingress.fromCIDR. Terapkan perubahan ini di cluster admin org yang sesuai dengan perintah:
Di node bare metal cluster sistem, dua container anetd tidak dapat dihentikan. Setelah menghentikan proses secara paksa, memulai ulang kubelet dan containerd, pod anetd dibuat ulang, tetapi semua container mengalami masalah podInit dan containerd melaporkan pesan error:
Hal ini memblokir Container Network Interface (CNI) agar tidak dimulai dan menghentikan penjadwalan pod lainnya.
Solusi:
Lakukan mitigasi berikut untuk mencegah status node ini:
Jangan menjadwalkan lebih dari 10 PVC sekaligus pada satu node. Tunggu hingga mereka terpasang sebelum menjadwalkan lebih banyak. Hal ini paling terlihat saat mencoba membuat VM.
Perbarui file /etc/lvm/lvm.conf di setiap node untuk menyertakan baris: filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] dalam blok devices{}
Jika node memasuki status yang menunjukkan waktu tunggu untuk pemasangan dan pemasangan volume, atau tidak dapat menghapus volume, periksa jumlah proses vg yang tertunda di node untuk mengidentifikasi apakah node berada dalam status yang sangat buruk ini. Cara paling andal untuk memperbaiki node dalam status ini adalah dengan memulai ulang node.
Ada mode kegagalan lain yang mungkin dialami. Mode kegagalan tersebut memiliki tanda tangan berikut pada upaya pemasangan: mount(2) system call failed: No space left on device. Hal ini mungkin berasal dari propagasi pemasangan pada node. Periksa ini dengan menjalankan cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c. Jika salah satu dari nilai ini menunjukkan nilai yang lebih besar dari satu, hapus pod yang menggunakannya, dan hal ini akan memicu pelepasan. Jika tidak berhasil, lepaskan jalur tersebut secara manual. Jika Anda masih mengalami masalah, mulai ulang perangkat.
Dalam skenario tertentu, karena kondisi persaingan, Google Distributed Cloud (GDC) yang terisolasi
gagal membuat ACL switch yang diperlukan untuk resource kustom Kubernetes
selama bootstrap awal Distributed Cloud.
Saat menyediakan Server selama pembuatan cluster apa pun,
ada kemungkinan server ditandai telah disediakan, tetapi tidak memiliki
kondisi Provision-Ready. Akibatnya, NodePool tidak dapat menggunakan server ini. Contoh pesan peristiwa
error di NodePool mungkin terlihat seperti ini:
SERVER_NAME=ROOT_ADMIN_KUBECONFIG=ILO_IP=$(kubectlgetservers${SERVER_NAME}-ngpc-system--template={{.spec.bmc.ip}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG})SECRET_NAME=$(kubectlgetsecrets-ogo-template='{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}'-ngpc-system--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|grepbmc|grep${SERVER_NAME})ILO_USER=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.username}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)ILO_PASS=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.password}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)# Perform iLO Resetcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset--data'{"ResetType":"ForceRestart"}'-XPOST|jq
# Perform server power cycle, start with power off target servercurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"ForceOff"}'|jq.
# Verify target server powered off successfullycurl-kqs-u${ILO_USER}:${ILO_PASS}https://${ILO_IP}/redfish/v1/Systems/1|jq'.PowerState'# Power server backcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/jsonls "-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"On"}'|jq.
Dalam kasus yang jarang terjadi, prosedur reset iLO sebelumnya mungkin tidak sepenuhnya menyelesaikan
masalah, sehingga perlu dilakukan penyediaan ulang server. Lihat runbook OS-P0002
dan OS-P0003 untuk mengetahui prosedur mendetailnya.
Anda tidak dapat menemukan nxos.10.3.1.bin, tetapi menemukan sesuatu yang serupa
seperti nxos64-cs.10.3.1.F.bin di direktori bootflash
switch.
Solusi:
Di mesin bootstrapper, selesaikan langkah-langkah berikut. Anda harus
menyelesaikan langkah-langkah ini saat proses pra-penginstalan sedang berlangsung. Jika ada
beberapa folder /tmp/preinstall-bootstrap-, terapkan perubahan
ke folder saat ini yang digunakan oleh proses pra-penginstalan dengan memeriksa
log proses pra-penginstalan. Jika Anda perlu memulai ulang perintah pra-penginstalan, tindakan ini juga akan membuat folder /tmp/preinstall-bootstrap- baru.
Masalah ini disebabkan oleh pembersihan tugas upgrade yang tidak tepat. Anda
tidak perlu melakukan tindakan apa pun dan tugas dapat dibiarkan dalam status error berulang.
Hal ini menjadi masalah bagi server yang tidak menyinkronkan waktu. konfigurasi tidak diterapkan dengan benar dan harus diubah ke namespace
lain agar dapat diterapkan dengan benar.
Solusi:
Terapkan langkah-langkah berikut ke semua cluster:
Mencantumkan kebijakan OS yang ada:
kubectlgetospolicies-nntp-system
Output menampilkan admin-ntp-policy atau worker-ntp-policy.
Edit file dengan mengubah metadata.namespace dari
ntp-system menjadi gpc-system, dan menghapus
status: line dan semua yang ada setelahnya.
Terapkan file yang telah diedit ke cluster:
kubectlapply-fntp-ospolicy.yaml
Tunggu beberapa menit hingga pengontrol menerapkan kebijakan OS.
Buat koneksi SSH ke salah satu node yang menerapkan OSPolicy, lalu jalankan cat /etc/chrony.conf. Output menampilkan pesan di awal file bahwa file tersebut dikelola oleh ansible dan server nist.time.gov atau ntp.pool telah dihapus dari konfigurasi.
Proses pencadangan dan pemulihan VM tidak dapat dimulai oleh pengguna karena
setelan kontrol akses berbasis peran (RBAC) dan skema yang tidak tepat di pengelola VM.
Nama rencana pencadangan VM tidak boleh lebih dari 63 karakter.
Misalnya, Anda mungkin melihat pesan error ini:
Nama rencana pencadangan VM adalah gabungan dari nama VirtualMachineBackupPlanTemplate, jenis resource (yaitu vm atau vm-disk), dan nama resource tersebut. String gabungan ini harus tetap kurang dari 63 karakter.
Untuk melakukannya, buat nama resource ini tetap pendek saat membuatnya. Untuk mengetahui detail tentang pembuatan resource ini, lihat Membuat dan memulai instance VM dan Membuat rencana pencadangan untuk VM.
Beban kerja Database Service disediakan dan dikonfigurasi dalam project terpisah di cluster sistem Distributed Cloud. Meskipun project digunakan untuk menerapkan batas administratif di Distributed Cloud, project tidak berdampak pada cara dan tempat beban kerja dieksekusi. Oleh karena itu, workload ini dapat berbagi infrastruktur komputasi yang mendasarinya dengan instance database lain dan berbagai sistem bidang kontrol.
Solusi:
Untuk beban kerja database yang memerlukan isolasi tambahan, pengguna dapat meminta pembuatan kumpulan node di cluster sistem. Node pool ini, yang harus dirujuk selama pembuatan project, memastikan workload database disediakan dan dieksekusi di infrastruktur komputasi khusus. Konfigurasi node pool terisolasi harus diselesaikan oleh Operator Infrastruktur.
Untuk AlloyDB Omni versi 15.2.1, jika beberapa cluster AlloyDB Omni dibuat di node yang sama, cluster yang terakhir dibuat akan mengalami error dalam status merekonsiliasi. Mendapatkan log postgresql dengan perintah
Selama deployment pelanggan, nama pengguna administrator file secret.yaml harus admin. Sebagai gantinya, file berisi TO-BE-FILLED setelah pembuatan pertama. Nama pengguna admin harus digunakan untuk menginisialisasi konfigurasi pertama ke firewall, dan melalui IP loopback admin\admin
Solusi:
Pastikan TO-BE-FILLED tidak ada di kredensial firewall berikut:
CELL_ID/CELL_ID-secret.yaml
CELL_ID-ab-rack/CELL_ID-secret.yaml
CELL_ID-ac-rack/CELL_ID-secret.yaml
Pastikan semua akun administrator firewall memiliki nama pengguna admin.
Kebijakan firewall IDPS default tidak mendukung IP kustom organisasi untuk Direct Connect (DX) Interconnect. Akibatnya, pembuatan organisasi dengan IP kustom gagal karena IP kustom tidak dapat terhubung ke Harbor di admin root.
Solusi:
Untuk membuka blokir traffic, buat SecurityPolicyRule secara manual untuk IP kustom organisasi dan deploy ke firewall IDPS. Ikuti langkah-langkah dalam runbook FW-G0002 untuk menyelesaikan langkah-langkah berikut:
1. Buat SecurityPolicyRule ingress di sistem virtual firewall root untuk mengizinkan IP kustom organisasi mengakses Harbor root
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.
Ikuti langkah-langkah dalam runbook HSM T0016 untuk memperpanjang masa berlaku sertifikat server, jika tanggal Not After berada dalam 30 hari dari hari ini.
Mengonfigurasi webhook ServiceNow akan menyebabkan Lifecycle Management (LCM) merekonsiliasi ulang dan mengembalikan perubahan yang dilakukan pada objek ConfigMapmon-alertmanager-servicenow-webhook-backend dan objek Secretmon-alertmanager-servicenow-webhook-backend di namespace mon-system.
Solusi:
Jeda subkomponen LCM agar perubahan terjadi tanpa dikembalikan:
Dapatkan jalur ke file kubeconfig dari cluster admin root dan admin org. Simpan jalur di variabel lingkungan ROOT_ADMIN_KUBECONFIG dan ORG_ADMIN_KUBECONFIG.
Jeda subkomponen LCM di salah satu cluster berikut:
Beberapa metrik dari cluster pengguna tidak dikumpulkan. Masalah ini memengaruhi cluster VM pengguna, tetapi tidak memengaruhi cluster sistem.
Anda dapat melihat log berikut dari server Prometheus:
prometheus-serverts=2024-02-21T16:07:42.300Zcaller=dedupe.go:112component=remotelevel=warnremote_name=cortex-remote-writeurl=http://cortex-tenant.mon-system.svc:9009/pushmsg="Failed to send batch, retrying"err="server returned HTTP status 500 Internal Server Error: 2 errors occurred:"
Anda dapat melihat log berikut dari tenant Cortex:
cortex-tenanttime="2024-02-23T18:03:44Z"level=errormsg="proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host"
Solusi:
Ikuti langkah-langkah berikut untuk menyelesaikan masalah:
Dapatkan jalur ke file kubeconfig cluster. Simpan jalur di variabel lingkungan KUBECONFIG.
Metrik yang ditujukan untuk instance Grafana Infrastructure Operator dapat berada di instance Grafana Platform Administrator, dan sebaliknya. Masalah ini disebabkan oleh permintaan load balancing ASM di seluruh batas cluster, yang memiliki tenant default yang berbeda.
Solusi:
Solusi ini memerlukan akses ke sumber private-cloud dan kemampuan untuk meluncurkan update komponen. Anda harus mengubah konfigurasi mesh untuk membatasi layanan cortex-tenant agar hanya menerima traffic dari cluster lokal, dan men-deploy komponen ASM.
Saat mengupgrade dari 1.11.0 ke 1.11.3, upgrade node gagal untuk NodeOSInPlaceUpgradeCompleted.
kalogs-ngpc-systemos-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn|grepGDCH-OS-ANSIBLE-CHECK-A50[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":true,
"msg":""},
"execution":{"success":false,
"msg":"errors found when simluating play execution on host: 10.3.20.9",
"tasks":[{"task":"os/upgrade : Copy GRUB file to BOOT location",
"error":"Source /boot/efi/EFI/ubuntu/grubx64.efi not found"}]}},
"diff":null
}
Solusi:
Login ke mesin bare metal yang sedang diupgrade. Periksa apakah fstab memiliki /boot/efi dan direktori telah di-mount:
Jalankan mount -a dan periksa apakah direktori sudah di-mount:
# mount -a
root@mb-aa-bm04:~#ls/boot/efi/
EFI
Lanjutkan pemeriksaan di sini. Jalankan perintah berikut:
C
# Ensure all three cmds prints `Files are identical`if["$(sha256sum/boot/efi/EFI/ubuntu/shimx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/BOOTX64.EFI|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grubx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/grubx64.efi|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fi
Jika tidak semua file identik, jalankan perintah ini di komputer, dan ulangi pemeriksaan.
Tugas mulai ulang VM gagal setelah solusi manual untuk pod os-policy. Pesan berikut akan ditampilkan:
kologsos-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp-ngpc-system
playbook:server-reboot.yaml
{"custom_stats":{},
"global_custom_stats":{},
"plays":[{"play":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.694226Z"},
"id":"5251f140-5a01-5cce-6150-000000000006",
"name":"Run OS Upgrade Tasks"},
"tasks":[{"hosts":{"172.20.128.10":{"action":"setup",
"changed":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out",
"unreachable":true}},
"task":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.704562Z"},
"id":"5251f140-5a01-5cce-6150-00000000000b",
"name":"os/reboot : Gather OS distribution information"}}]}],
"stats":{"172.20.128.10":{"changed":0,
"failures":0,
"ignored":0,
"ok":0,
"rescued":0,
"skipped":0,
"unreachable":1}}}[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out"},
"execution":{"success":false,
"msg":"",
"tasks":null
}},
"diff":null
}[GDCH-OS-ANSIBLE-CHECK]
Error:reachabilityerr:Failedtoconnecttothehostviassh:ssh:connecttohost172.20.128.10port22:Connectiontimedout
Selama upgrade, subkomponen pemilah komunikasi OPA tidak diinstal di cluster sistem. Namun, batasan diinstal dan webhook untuk menerapkannya juga diinstal.
Beberapa pod dalam cluster sistem mungkin macet dalam status TaintToleration:
Pod dengan nama penampung istio-proxy belum siap dan memiliki status ImagePullBackOff dengan peristiwa Back-off pulling image "auto".
Solusi:
Verifikasi bahwa webhook mutating istio-revision-tag-default ada di cluster. Jika tidak, tunggu sekitar 10 menit untuk melihat apakah sistem pulih secara otomatis. Jika tidak, eskalasikan masalah ini.
Jika webhook mutating ada, hapus pod yang bermasalah dan verifikasi bahwa pod tersebut kembali aktif. .spec.containers[].image tidak boleh berupa auto, harus terlihat seperti gambar sebenarnya yang mirip dengan berikut: gcr.io/gke-release/asm/proxyv2:<image version>.
Saat mengupgrade dari 1.11.1 ke 1.12.1, ValidatingWebhookConfigurations, MutatingWebhookConfigurations, dan MonitoringRules yang di-deploy oleh komponen Log mungkin gagal diupgrade.
Solusi:
Pastikan Anda memiliki kubectl dan dapat mengakses buku pedoman IAM-R0004 untuk mendapatkan KUBECONFIG bagi cluster admin root.
Hapus ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook dari cluster admin root:
Tingkatkan memori pada setiap pengumpul data, tingkatkan jumlah pengumpul data, atau keduanya. Anda dapat melakukannya dengan men-deploy SubcomponentOverride di cluster admin org, seperti yang ditunjukkan dalam contoh berikut:
apiVersion:lcm.private.gdc.goog/v1
kind:SubcomponentOverride
metadata:
name:mon-cortex-ingester-override
namespace:org-1-system-cluster
spec:
backend:
operableParameters:
ingester:
resourcesLimit:
memory:"6Gi"# 6Gi is the default, increase to add more memory to each ingesterreplicas:4# 4 is the default, increase to create more ingester instances.subComponentRef:mon-cortex
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. Status baremetalmachine menampilkan kegagalan pemeriksaan check_registry_mirror_reachability_pass.
kubectl--kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG}getbaremetalmachines-A-ojson|jq'.items[] | select(.status.underMaintenace != .spec.maintenanceMode) | .metadata.name as $name | .status.underMaintenace as $statm | .spec.maintenanceMode as $specm | .status.conditions[] | select(.status == "False") | select(.type == "MaintenaceModeHealthCheckReady")'
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. HealthChecks menampilkan error tidak ada netutil.
{"lastHealthcheck":{"error":{"code":"500",
"reason":"[Errno 2] No such file or directory: /usr/local/bin/abm-tools10.5.23.4/netutil"},
"lastCompletedTime":"2024-09-14T05:11:39Z",
"lastStatus":"Error",
"monitoredComponentVersion":"1.28.900-gke.112",
"version":"1.28.900-gke.112"},
"lastScheduledTime":"2024-09-14T05:26:00Z"}
Solusi:
Hapus Tugas Kubernetes yang sesuai dengan HealthCheck yang gagal
Saat mengupgrade dari 1.11.x ke 1.12.1, NodeUpgrade berisi beberapa versi untuk model hardware yang sama, sehingga memblokir verifikasi upgrade firmware.
Solusi:
Lakukan langkah-langkah berikut untuk mengubah NodeUpgrade CR spec:
Jika upgrade ditujukan untuk server HPE Gen10 (GDC-4D), hapus firmware model ilo6. Jika tidak, hapus firmware model ilo5.
Bagian untuk mempertahankan entri dengan redfishVersion terbaru untuk setiap deskripsi.
Misalnya, jika kedua entri berikut ada, hanya simpan entri yang memiliki 2.98 Oct 10 2023:
Node diharapkan berada dalam mode pemeliharaan selama upgrade. Jika satu node sedang dalam pemeliharaan, Anda mungkin tidak memiliki cukup resource untuk menjadwalkan harbor-db.
Solusi:
Untuk memperbaiki masalah ini, lakukan langkah-langkah berikut:
Objek StatefulSet Prometheus dikonfigurasi secara salah dengan class penyimpanan standard, bukan standard-rwo. Masalah ini menyebabkan kegagalan startup objek StatefulSet Anthos Prometheus dari komponen pemantauan.
Masalah ini terjadi karena rekonsiliator ObservabilityPipeline hanya menetapkan nilai ini pada penginstalan pertama, dan rekonsiliator ObsProjectInfra memantau resource kustom cluster.
Solusi:
Mulai ulang deployment fleet-admin-controller di cluster admin org untuk mengatasi masalah ini.
Subkomponen mon-common harus men-deploy objek Telemetri Istio di cluster admin org untuk mencegah audit mencatat semua permintaan untuk Cortex. Namun, file manifes tidak disertakan dalam file build.
Solusi:
Ikuti langkah-langkah berikut untuk men-deploy objek Telemetri Istio di cluster admin org:
Buat file YAML yang menentukan resource kustom (CR) Telemetri Istio di namespace mon-system cluster admin org:
# Disable access logging from workloads internal to GDCH.# Telemetry CR to disable Istio access logs from obs-system namespace.
apiVersion:telemetry.istio.io/v1alpha1
kind:Telemetry
metadata:
name:disable-audit-logging
namespace:mon-system
spec:
accessLogging:
-providers:
-name:otel
disabled:true
Terapkan file manifes ke cluster admin org di namespace mon-system:
Prober ConfigMap diisi saat setiap probe didaftarkan.
Ikuti runbook MON-R2009 untuk menonaktifkan suara notifikasi MON-A0001, Blackbox monitoring metrics pipeline down, karena notifikasi ini akan terus muncul.
Saat mengupgrade dari 1.11.x ke 1.12.1, firewall host memblokir download image switch karena ketidakcocokan antarmuka yang digunakan oleh firewall host.
Solusi:
Terapkan solusi berikut sebelum mengupgrade, hanya jika Anda mengupgrade
dari 1.11.x ke 1.12.x.
Perbarui cluster admin root dan admin org.
Dapatkan nama dan namespace nodepool untuk node bare metal admin root
dan node bare metal admin org. Untuk cluster root-admin, gunakan
kubeconfig root-admin. Perintah berikut mencantumkan inventaris
mesin dan memfilter daftar menurut mesin bare metal:
Switch jaringan yang sudah dimuat sebelumnya dengan versi yang lebih rendah dari 9.3.10 gagal melakukan bootstrap karena versi switch yang diharapkan adalah 10.3(4a).
Solusi:
Upgrade firmware switch secara manual dari 9.3.5 ke 9.3.10, lalu dari 9.3.10 ke 10.3.4a.
conditions:
-lastTransitionTime:"2024-03-28T01:37:20Z"message:'Reconciliation error: E0100 - deploy: failed to install chart: release file-netapp-trident-backend failed, and has been uninstalled due to atomic being set: cannot patch "standard-rwo" with kind StorageClass: StorageClass.storage.k8s.io "standard-rwo" is invalid: parameters: Forbidden: updates to parameters are forbidden. && cannot patch "standard-block" with kind StorageClass: StorageClass.storage.k8s.io "standard-block" is invalid: parameters: Forbidden: updates to parameters are forbidden.'observedGeneration:1reason:ReconciliationError
status:"True"type:Reconciling
Dalam contoh ini, dua class penyimpanan gagal: standard-rwo
dan standard-block.
Solusi:
Hapus StorageClasses yang gagal dibuat oleh tugas,
seperti standard-rwo, standard-block, standard-rwo-non-luks, dan standard-block-non-luks.
Picu pembuatan ulang StorageClasses dengan memulai ulang oclcm-backend-controller untuk cluster Anda
(root-admin controller untuk cluster admin root dan org, org-admin controller untuk cluster sistem dan pengguna).
Untuk versi 1.12.4, pastikan class penyimpanan yang diinstal memiliki anotasi disk.gdc.goog/luks-encrypted: yang ditetapkan ke benar (tidak termasuk class penyimpanan non-luks). Jika anotasi tidak disetel ke benar (true), ulangi langkah 1 dan 2.
Mulai ulang deployment netapp-trident dan netapp-trident DaemonSet di cluster.
Verifikasi bahwa rahasia LUKS telah dibuat untuk resource PersistentVolumeClaim (PVC) Anda. Setiap PVC harus memiliki secret dalam format g-luks-$pvc_name.
Pastikan subkomponen file-netapp-trident tidak memiliki error dalam status.
Node pool dalam cluster pengguna yang berjalan di Kubernetes versi 1.27.x mungkin tidak diinisialisasi, sehingga menyebabkan cluster pengguna tidak dapat menangani workload container.
Solusi:
Jangan membuat cluster pengguna dengan Kubernetes versi 1.27.x.
VMRuntime di cluster target (dapat berupa cluster admin atau sistem) memiliki status VMRuntime.ready = false dan network-controller-manager di namespace kube-system tertunda
Menghapus deployment network-controller-manager akan otomatis membuat ulang deployment dengan sertifikat yang diperlukan oleh operator VMM. Deployment akan memasuki status Running dan selanjutnya status VMRuntime akan berubah menjadi ready=true.
Pod pengimpor VM mengalami loop error dan volume data macet dalam status
mengimpor selama lebih dari 90 menit. Status pod mungkin
terlihat seperti ini:
message:'Reconciliation error: E0111 - upgrade chart: release unet-nodenetworkpolicy-infra-assets failed, and has been rolled back due to atomic being set: cannot patch "mgmt-network" with kind Network: admission webhook "vnetwork.networking.gke.io" denied the request: Network.networking.gke.io "mgmt-network" is invalid: Spec.NodeInterfaceMatcher: Forbidden: Field is immutable'observedGeneration:2
Solusi:
Jika kegagalan terjadi di root, pada langkah-langkah berikut, ganti KUBECONFIG dengan kubeconfig admin root.
Jika kegagalan terjadi di org, ganti KUBECONFIG dengan kubeconfig admin org pada langkah-langkah berikut.
File mungkin memiliki pesan berikut di bagian backendStatus.
message:'E0100 - deploy: failed to install chart: release file-observability-backend failed, and has been uninstalled due to atomic being set: deployments.apps "file-observability-backend-controller" not found'
Solusi:
Periksa namespace file-system untuk memverifikasi bahwa namespace tersebut tidak berhenti di org-admin cluster:
Jalankan ksctl system info get --url=https://HSM_MANAGEMENT_IP untuk memverifikasi bahwa semua versi HSM telah diupgrade ke .Spec.TargetVersionctmclusterupgraderequest:
Perbarui kolom Status.FirmwareVersion setiap HSM ke versi yang diupgrade seperti yang diperoleh pada langkah sebelumnya:
Contoh:
kubectledit-statushsmHSM_NAME-ngpc-system
Perbarui status kondisi terakhir ctmclusterupgraderequest.status.conditions dari False menjadi True. Setelah itu, status kondisi terakhir hsmupgraderequest.status.conditions juga menjadi benar.
Selama upgrade
IP pengelolaan server tidak dapat dijangkau, khususnya setelah upgrade
OS switch.
Dengan Rocky Linux, saat rute statis ditambahkan, IP tujuan yang digunakan
untuk mencapai rute statis harus dapat dijangkau sebelum rute statis
ditambahkan. Jika switch melakukan booting 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:
Saat men-deploy organisasi gdchservices secara manual, sistem tiket
tidak memiliki upstream yang berfungsi, tidak ada VM yang dibuat, dan pod midserver
tidak berfungsi di cluster gdchservices-system dalam namespace support.
Solusi:
Buat resource kustom TicketingSystem baru dengan image VM yang benar di cluster gdchservices-admin:
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:
Jika error terjadi selama pemeriksaan pra-peluncuran dan semua pemeriksaan pra-peluncuran lainnya selesai tanpa error, lewati pemeriksaan pra-peluncuran:
Skema Portfolio telah berubah di GDC versi 1.12. Kolom portfolioName telah difaktorkan ulang ke portfolioID. Temukan file YAML yang berisi resource kustom portofolio yang disebutkan dalam pesan error. Ganti nama kolom portfolioName menjadi portfolioID.
Tugas siem-*-preinstall di namespace root dan org-1 pada cluster admin root berulang kali gagal.
Solusi:
Tugas akan gagal jika gerbang fitur SIEMComponent dinonaktifkan. Kegagalan tidak menunjukkan bahwa komponen rusak. Penyelesaian komponen SIEM dapat dijeda jika gangguan terlalu mengganggu, tetapi umumnya disarankan untuk membiarkan komponen diaktifkan jika memungkinkan. Jika rekonsiliasi komponen dijeda, maka harus diaktifkan kembali secara manual saat penginstalan komponen SIEM tidak lagi dibatasi dalam upgrade mendatang.
Pisahkan output. Perbaiki satu cluster dalam satu waktu. Output-nya mungkin
terlihat seperti ini:
NAME
bm-2bca8e3f
bm-4caa4f4e
Buat file playbook & kebijakan:
apiVersion:system.private.gdc.goog/v1alpha1
kind:AnsiblePlaybook
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
playbook:|-name:Addadevicefilterto/etc/lvm/lvm.conf
hosts:all
gather_facts:no
tasks:
# Change lvm.conf-name:Configurelvmforfilteringout"dm"and"sg"devices
ansible.builtin.lineinfile:
path:/etc/lvm/lvm.conf
insertafter:'^(\s+|)devices(\s+|)\{'line:' filter = [ \"r|/dev/dm.|\", \"r|/dev/sg.|\" ]'---
apiVersion:system.private.gdc.goog/v1alpha1
kind:OSPolicy
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
interval:
period:1m
inventory:
# this is the inventory from step 1 above,# see the syntex belowpolicy:
installPlaybook:
name:lvm-conf-device-filter-node-update
Bagian inventaris sebelumnya harus diisi seperti contoh ini.
Tambahkan satu paragraf per node yang ditemukan di Langkah 1. Anda akan melakukan satu cluster
dalam satu waktu, jadi isi bagian inventaris dengan node untuk satu cluster.
Masalah ini terjadi jika lingkungan sebelumnya di-deploy dengan 1.11
lalu diupgrade ke 1.12. Saat membuat cluster atau organisasi baru di
versi 1.12.x, Rocky OS, bukan Ubuntu OS, dipilih untuk
penyediaan node virtual machine dan bare metal karena versi Rocky OS
yang ditentukan dalam CR ReleaseMetadata dan
Userclustermetadata.
Solusi:
Terapkan solusi sementara berikut sebelum membuat organisasi baru:
Periksa apakah ada CR OrganizationUpgrade yang tidak dalam status
Succeeded: true:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')STATUS=$(kubectl--kubeconfig=KUBECONFIGgetorganizationupgrade${NAME}-n${NAMESPACE}-ojson|jq'.status.conditions[] | select(.type=="Succeeded") | .status')if[["$STATUS"!="True"]];thenecho"Not in Succeeded: true state, stop following operations"fidone
Jika demikian, eskalasikan masalah ini kepada tim engineering sebelum melanjutkan ke langkah berikutnya.
Hapus semua CR OrganizationUpgrade yang ada untuk menghindari
upgrade OS node yang tidak disengaja:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')echo"Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE"kubectl--kubeconfig=KUBECONFIGdeleteOrganizationUpgrade$NAME-n$NAMESPACEdone
Tentukan versi GDC target untuk pembuatan organisasi baru. Harus ada ReleaseMetadata yang sesuai untuk versi target ini:
TARGET_RELEASE=
Identifikasi CR OSImageMetadata terbaru untuk target
Ubuntu OS di cluster admin root dan tentukan variabel OS_VERSION:
Pastikan variabel menggunakan versi major.minor.patch yang sama,
seperti 1.12.4, dengan TARGET_RELEASE. Jika tidak, eskalasikan ke tim
engineering sebelum melanjutkan ke langkah berikutnya.
Perbarui target ReleaseMetadata untuk menggunakan OS_VERSION Ubuntu di cluster admin root:
Perbarui target UserclusterMetadata untuk menggunakan OS_VERSION Ubuntu
di cluster admin root dan cluster admin org
untuk setiap org. Jalankan perintah berikut untuk setiap cluster:
Saat image VM lokal diimpor menggunakan
CLI gdcloud compute images import, status impor akan
berhenti di WaitingForTranslationVM atau
ImportJobNotCreated. Hal ini karena disk sementara
yang dibuat untuk menerjemahkan atau mengimpor menggunakan ukuran yang sama persis dengan image qcow2 atau raw
tetapi LUKS menambahkan overhead beberapa MiB yang menyebabkan penyediaan disk
gagal.
Solusi:
Buat VirtualMachineImageImport baru secara manual dengan
nama gambar yang sama, tetapi dengan spec.minimumDiskSize yang lebih besar. Misalnya, jika perintah berikut digunakan untuk mengimpor gambar:
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. Dalam
kasus qcow2, ukurannya adalah ukuran virtual, misalnya 20Gi harus
diganti dengan 21Gi.
Ganti nilai placeholder berdasarkan cara CLI dipanggil.
Jika objek tidak ada, picu perintah gdcloud compute images import ...
lagi. 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 untuk referensi guna
membuat yang baru.
Buat VirtualMachineImageImport baru dengan
minimumDiskSize yang lebih besar:
Pod importer-image-import-$VMII di namespace project cluster sistem mengalami error dengan error berikut: Unable to process data: Unable to transfer source data to target file: unable to write to file: stream error: stream ID 1; NO_ERROR; received from peer`). Objek VMII VirtualMachineImageImport memiliki kondisi Type Ready dengan Status False dan Reason TranslationInProgress setelah 2 jam memulai impor.
Solusi:
Untuk meningkatkan kecepatan, ubah ukuran disk minimum image menjadi 200 GiB sebagai berikut:
Perhatikan bahwa untuk menghapus dan menerapkan ValidatingWebhookConfiguration, Anda memerlukan kubeconfig admin cluster untuk cluster admin org. Anda bisa mendapatkan runbook berikut IAM-R0004.
Jika Anda menggunakan gdcloud untuk memulai impor, perhatikan bahwa tidak ada cara untuk memberikan parameter minimumDiskSize. Anda harus membuat objek VMII, dan mengubah VMII seperti yang ditunjukkan pada perintah sebelumnya.
Proses VirtualMachineImageImport berlanjut, tetapi macet lagi di langkah berikutnya. Di namespace project dalam cluster sistem, Anda melihat tugas image-import-$VMII terus gagal dengan error: error: stream error: stream ID x; NO_ERROR; received from peer. Pada tahap ini, impor gambar selesai. Gambar akhir diupload ke penyimpanan objek, tetapi VirtualMachineImage tidak ada. Anda dapat membuat VirtualMachineImage secara manual sebagai berikut:
`$NAME` harus cocok dengan `VMII.ImageMetadata.Name`, dan `$OS_NAME` dapat berupa salah satu dari [`ubuntu-2004`, `ubuntu-2204`, `windows-2019`, `rhel-8`] dan harus cocok dengan jenis image yang diimpor.
Deployment istio-eastwestgateway di namespace
istio-system mengalami masalah, dengan peristiwa pod yang menampilkan error
Back-off pulling image "auto" dari
kubelet.
Untuk mendiagnosis masalah, periksa apakah mutatingwebhookconfiguration bernama istio-revision-tag-default ada di cluster yang sama dengan
deployment gateway yang macet.
Ubah configMap cortex-config di cluster sistem
dan tetapkan waktu tunggu untuk memcached dalam index_cache ke dua detik sehingga
konfigurasi index_cache terlihat seperti ini:
Lokasi penginstal fluent-bit diubah menjadi operations_center\bin\fluent-bit-win64.msi.
Copy-ConfigHostFiles.ps1 mengharapkan penginstal klien fluent-bit
agar cocok dengan pola fluent-bit-*-win64.*.
Penginstal gagal menemukan penginstal karena pola tersebut tidak lagi cocok.
Lokasi penginstal Nessus diubah menjadi operations_center\bin\NessusAgent-x64.msi.
Copy-ConfigHostFiles.ps1 mengharapkan penginstal klien
cocok dengan nama file /NessusAgent-10.4.1-x64.msi.
Penginstal gagal menemukan penginstal karena pola tersebut tidak lagi cocok.
Buka tab Konfigurasi, lalu klik Grup Ketersediaan Tinggi.
Buka tampilan detail setiap grup HA dan catat alamat IP Virtual (VIP).
Buat grup HA baru:
Nama Grup: Pola nama adalah ORGANIZATION_NAME-ha
. Dalam hal ini, nilainya adalah org-2-ha.
Deskripsi Grup: Gunakan grup HA yang ada untuk pola deskripsi.
Antarmuka: Pilih semua eth2.
Urutan prioritas: Antarmuka utama harus memiliki prioritas tertinggi.
SubnetCIDR: Kolom ini diisi secara otomatis oleh StorageGRID.
Pastikan subnet cocok dengan status.ipv4SubnetStatus.cidrBlock
di SubnetClaimexternal-objectstorage-client-lif-cidr.
IP virtual: IP berikutnya dalam rentang IP yang tersedia. IP tidak boleh berkonflik dengan IP yang dicadangkan, IP klien Admin Node, dan VIP grup HA yang ada.
Saat mengupgrade org root dari 1.12.2 ke 1.12.4, subkomponen
iac-gitlab memiliki status rekonsiliasi yang sedang berlangsung.
Untuk mendiagnosis masalah, periksa log prometheus, misalnya:
Lihat pesan error sebelumnya dan catat namespace dan nama
deployment. Dalam contoh ini, NAME adalah
iam-authzpdp-backend-server dan NAMESPACE adalah
iam-system.
Perhatikan pod yang tidak memiliki semua container yang siap. Dalam hal ini
POD_NAME adalah iam-authzpdp-backend-server-6875654c4b-pvscg
yang memiliki salah satu dari dua penampung yang belum siap, yang ditunjukkan oleh status 1/2. Jika ada lebih dari satu pod seperti ini, ulangi langkah berikutnya
untuk setiap pod yang terpengaruh.
Hapus pod yang tidak sepenuhnya responsif:
kubectldeletepod-nNAMESPACEPOD_NAME>
Jalankan kembali perintah dari Langkah 2. Perhatikan bahwa semua pod seharusnya
sudah sehat sekarang. Langkah ini mungkin memerlukan waktu beberapa menit.
Jika pod yang dihapus tidak digantikan oleh pod yang responsif, buka tiket
dukungan.
Selama upgrade organisasi tenant dari 1.12.2 ke 1.12.4, upgrade subkomponen opa gatekeeper gagal dengan ReconciliationError.
Solusi:
Edit objek mutatingwebhookconfigurationedr-sidecar-injector-webhook-cfg cluster pengguna yang terpengaruh. Jika ada lebih dari satu cluster pengguna yang terpengaruh, ulangi langkah-langkah untuk setiap cluster pengguna yang terpengaruh:
Edit bagian webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values untuk menambahkan dua nilai berikut ke dalamnya:
Saat mengupgrade dari 1.12.2 ke 1.12.4, ansibleplaybook tidak diupgrade sebagai bagian dari upgrade cluster. Perbaikan yang diupdate di ansibleplaybook tidak diterapkan dan memblokir os-policy yang menjalankan ansibleplaybook versi sebelumnya.
Saat membuat organisasi baru, Anda mungkin melihat waktu tunggu habis untuk subkomponen core-dns di log:
[INFO]192.0.2.0:60741-40400"A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000828817s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.A:readudp10.244.4.184:59927->192.0.2.1:53:i/otimeout
[INFO]192.0.2.0:51401-5813"AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000585231s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.AAAA:readudp10.244.4.184:48542->192.0.2.1:53:i/otimeout
Solusi:
Perbarui layanan gpc-coredns-forwarder-udp
dan layanan gpc-coredns-forwarder-tcp cluster admin root,
lalu tambahkan rentang IP baru Anda di rentang sumber load balancer.
Jika perubahan CR diganti, jeda subkomponen dns-core
dengan anotasi lcm.private.gdc.goog/paused="true".
Saat mengupgrade dari 1.12.2 ke 1.12.4, subkomponen file-netapp-trident mengalami masalah saat menghapus StorageClasses. Status berikut ditampilkan:
status:
backendStatus:
conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
-lastTransitionTime:"2024-04-08T00:12:53Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-05-01T10:10:08Z"message:Fetchedparametersfromdefault,runtime
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-05-02T06:04:04Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:DeployError
status:"False"type:Deployed
-lastTransitionTime:"2024-04-23T06:50:12Z"message:Readinesscheckjobpassed
observedGeneration:1reason:ReadinessCheckDone
status:"True"type:Ready
deploymentFinished:falselastDeployTimestamp:"2024-05-02T06:03:16Z"readyAfterDeploy:trueversion:""conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'Reconciliation error: E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
crdsStatus:
conditions:
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Noparameterstofetch
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-04-07T08:02:34Z"message:Readinesssourceisempty
observedGeneration:2reason:ReadinessCheckSkipped
status:"True"type:Ready
-lastTransitionTime:"2024-05-01T18:37:52Z"message:Ready
observedGeneration:2reason:ReconciliationCompleted
status:"False"type:Reconciling
deploymentFinished:truelastDeployTimestamp:"2024-05-02T06:04:03Z"readyAfterDeploy:trueversion:1.12.3-gdch.312
Solusi:
Jeda subkomponen file-netapp-trident:
## Set KUBECONFIG to root-admin KUBECONFIGexportKUBECONFIG=ROOT_ADMIN_KUBECONFIGkubectlannotatesubcomponentfile-netapp-trident-n$cluster_namespacelcm.private.gdc.goog/paused=true
Hapus StorageClasses yang gagal dibuat oleh tugas,
seperti standard-rwo, standard-block, standard-rwo-non-luks, dan standard-block-non-luks:
Picu pembuatan ulang StorageClasses dengan memulai ulang oclcm-backend-controller untuk cluster Anda
(pengontrol root-admin untuk cluster admin org. dan root, pengontrol admin org. untuk cluster sistem dan pengguna):
Verifikasi bahwa rahasia LUKS telah dibuat untuk resource PersistentVolumeClaim (PVC) Anda. Setiap PVC harus memiliki secret dalam format g-luks-$pvc_name.
kubectlgetsecret-n$pvc_namespaceg-luks-$pvc_name
Pastikan subkomponen file-netapp-trident tidak memiliki error dalam status:
Pod primary-prometheus-shardX-replicaX terlihat di
namespace obs-system dan namespace
mon-system. Jika primary-prometheus-shardX-replicaX hanya ada di namespace obs-system setelah upgrade 1.12, berarti masalahnya tidak diketahui dan solusi sementara tidak boleh dilakukan.
Perilaku yang dimaksud adalah
primary-prometheus-shardX-replicaX hanya ada di namespace
mon-system setelah upgrade 1.12 selesai.
Solusi:
Hapus primary-prometheus-shardX-replicaX
StatefulSet secara manual di namespace obs-system.
Jangan menghapus StatefulSet primary-prometheus-shardX-replicaX
di namespace mon-system.
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 merekonsiliasi:
Periksa apakah objek ClusterCIDRConfig dibuat di
cluster:
Jalankan describe untuk salah satu objek node cluster yang
macet dalam proses rekonsiliasi dan periksa apakah ada peristiwa CIDRNotAvailable
pada objek node:
MonitoringTarget menampilkan status Not Ready saat cluster pengguna sedang dibuat, sehingga API yang telah dilatih sebelumnya terus menampilkan status Enabling di antarmuka pengguna.
Solusi:
Buka menu di browser Chrome Anda (ikon tiga titik).
Klik Alat lainnya > Alat developer untuk membuka konsol.
Klik tab Network di konsol.
Temukan permintaan ai-service-status.
Klik tab Response dalam permintaan ai-service-status untuk menampilkan konten permintaan tersebut.
Pastikan semuanya sudah siap kecuali komponen MonitoringTarget dan LoggingTarget.
Saat mengupgrade penyimpanan objek, Anda mungkin melihat peringatan seperti ini:
TypeReasonAgeFromMessage
-------------------------
WarningReconcileError55m(x2over55m)ObjectStorageAdminNodeReconcilerReconcileerror,retrying:errorstoringthesshcreds:500InternalServerError: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:
Pastikan setiap node memiliki kredensial SSH yang sesuai dan disimpan dalam secret.
Selama upgrade, cluster DB Terjemahan dibuat ulang, yang menyebabkan secret cluster sistem ODS secret-store menjadi tidak berlaku dan tidak sinkron. Oleh karena itu, pod dan layanan frontend Terjemahan gagal diinisialisasi.
Server tidak dapat terhubung ke pengelola kunci, sehingga status server tidak dapat tersedia. Masalah ini menyebabkan tugas
server-encrypt-and-create-logical-drive gagal dan cluster
admin tidak siap. Anda mungkin melihat error dalam log tugas seperti ini:
Loki hanya memiliki satu volume persisten (PV) untuk write-ahead log (WAL) dan indeks. WAL dapat mengisi PV jika pod Loki tidak dapat terhubung ke bucket penyimpanan selama berjam-jam. Jika PV tidak memiliki ruang yang tersisa, Loki tidak dapat dipulihkan kecuali jika Anda menghapus PV dan memulai ulang StatefulSet.
Solusi:
Untuk memulihkan pod Loki dari status ini, Anda harus menurunkan skala StatefulSet yang sesuai dan menghapus PV tanpa ruang yang tersisa.
Ikuti langkah-langkah berikut untuk memulihkan pod Loki:
Pastikan IO Tool Container diinstal di workstation. Untuk mengetahui detailnya, lihat panduan pengoperasian OOPS-P0065.
Untuk mendapatkan izin yang Anda perlukan untuk mengedit resource, minta Admin Keamanan Anda untuk memberi Anda peran berikut:
observability-viewer
observability-admin
Tetapkan variabel lingkungan KUBECONFIG dengan jalur ke file kubeconfig di cluster admin root. Untuk mengetahui detailnya, lihat buku pedoman IAM-R0004.
Tetapkan variabel lingkungan ORG_NAME dengan nama organisasi yang terpengaruh.
Simpan konten berikut dalam file YAML bernama log-admin-overrides.yaml:
Tetapkan variabel lingkungan KUBECONFIG dengan jalur ke file kubeconfig di cluster tempat pod Loki yang terpengaruh berjalan. Untuk mengetahui detailnya, lihat buku pedoman IAM-R0004.
Tetapkan variabel lingkungan LOKI_POD_NAME dengan nama pod Loki yang terpengaruh.
Tetapkan variabel lingkungan KUBECONFIG dengan jalur ke file kubeconfig di cluster admin organisasi yang terpengaruh. Untuk mengetahui detailnya, lihat buku pedoman IAM-R0004.
Edit konten dalam file YAML log-admin-overrides.yaml sebagai berikut:
Tugas dijadwalkan secara berkelanjutan. Segera setelah tugas dihentikan, tugas baru dijadwalkan. Tugas yang dijadwalkan secara berkelanjutan adalah:
unet-networkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-readiness
unet-userclusterpolicy-assets-parameter
unet-clustermesh-backend-parameter
unet-clustermesh-backend-readiness
Solusi:
Jeda subkomponen berikut:
unet-networkpolicy
unet-nodenetworkpolicy
unet-nodenetworkpolicy
unet-userclusterpolicy
unet-clustermesh
Lanjutkan subkomponen setiap kali ada perubahan pada rahasia fleet-info di cluster admin root. Masalah ini terjadi saat ada perubahan pada switch pengelolaan instance, seperti kr get managementswitches -A atau perubahan pada cidrclaim di namespace Organisasi.
Lanjutkan subkomponen setiap kali ada perubahan pada resource NodePool di cluster admin org. Batalkan jeda subkomponen sebelum memulai.
Saat mengupgrade dari 1.12.2 ke 1.12.4, upstream yang berfungsi baik untuk ServiceNow tidak tersedia. Anda mungkin melihat pesan berikut: failed to stage volume: LUKS passphrase cannot be empty.
Class penyimpanan system-performance-rwo tidak diaktifkan untuk LUKS. Lampiran volume menunjukkan bahwa PVC diaktifkan LUKS.
Reconciler akan menelusuri secret dengan frasa sandi LUKS. Karena lampiran volume menyatakan bahwa volume tersebut diaktifkan LUKS dan kelas penyimpanan tidak diaktifkan LUKS, frasa sandi rahasia tidak dibuat.
Solusi:
Dapatkan Kubeconfig untuk cluster root atau org-admin tempat masalah muncul:
exportKUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG}
Hapus class penyimpanan system-performance-rwo dan buat ulang:
May2223:08:00control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthoskubelet[3751]:time="2024-05-22T23:08:00Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
……
May2223:09:04control-1kubelet[3751]:time="2024-05-22T23:09:04Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
Proses runc init dibekukan, sehingga mencegah kubelet menghapus pod cgroup.
Solusi:
Gunakan skrip berikut untuk menemukan proses yang memblokir penghapusan cgroup:
# Find matching cgroup directoriesMATCHING_CGROUPS=$(find/sys/fs/cgroup-typed-name"*74353c*")if[-z"$MATCHING_CGROUPS"];thenecho"No cgroups found containing 'd06aac'."exit0fiecho"Matching cgroups:"forcgroupin$MATCHING_CGROUPS;doecho"- $cgroup"# Print cgroup path# Check if cgroup.procs existsif[-f"$cgroup/cgroup.procs"];thenecho" Processes:"# List PIDs in cgroup.procsforpidin$(cat"$cgroup/cgroup.procs");do# Get process detailsps-opid,comm,cmd--no-headers$pid2>/dev/null# Suppress errors if process doesn't existdoneelseecho" No cgroup.procs file found."# Handle cases where cgroup.procs is missingfiecho# Add a newline for better readabilitydone
Periksa status freezer menggunakan cat freezer.state. Statusnya harus FROZEN.
Echo "THAWED" > freezer.state
cgroup berhasil dihapus. Kubelet berhenti mengirim spam ke log.
Periksa anotasi dan label project PTaaS gdch-perftest dan bucket perftest-bucket-reports di namespace perftest gdch-perftest. Bucket mungkin tidak memiliki label: app.kubernetes.io/managed-by=Helm dan anotasi: meta.helm.sh/release-name=perf-ptaas-assets dan meta.helm.sh/release-namespace=gdch-perftest.
Tambahkan label dan anotasi ini secara manual:
Periksa anotasi project PTaaS gdch-perftest. Project mungkin salah dikonfigurasi dengan anotasi: meta.helm.sh/release-name=perf-ptaas-assets.
Ubah anotasi ini menjadi meta.helm.sh/release-name=perf-ptaas-backend:
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-23 UTC."],[],[]]
