| Penginstalan |
1.9.0
1.9.1
1.9.2 |
Terkadang iLO tidak dapat mengambil kunci dari HSM
Gejala:
`server.status.conditions` memiliki entri dengan jenis `KeyManagerConfigured` dan status `True`, tetapi tidak ada yang memiliki jenis `DiskEncryptionEnabled`. Ada pod yang gagal bernama `server-encrypt-and-create-logical-drive-$SERVER-xxxxx` dengan error `"ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0`. Gagal melakukan SSH di pod karena kunci tidak valid.
Solusi:
Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:
Buka iLO UI > Information > Diagnostics > Reset untuk mereset iLO. Jika selama reset, iLO menampilkan bahwa server sedang dalam uji mandiri saat dinyalakan (POST), mulai ulang alur penyediaan:
Jika penginstalan admin-cluster berhasil:
export KUBECONFIG=<root-admin-kubeconfig path>
Perbarui kunci SSH:
Ambil kunci SSH publik saat ini (perhatikan bahwa kunci ini mungkin telah diubah dan dengan demikian berbeda dari /root/.ssh/id_rsa.pub
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
Masukkan kunci publik di configmap ironic-vars:
kubectl -n gpc-system edit cm/ironic-vars
Tambahkan IRONIC_RAMDISK_SSH_KEY: \ Mulai ulang ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
Sediakan ulang komputer untuk menginstal ulang IPA:
Cadangkan bmc-credential-$SERVER karena menghapus bmh juga akan menghapus rahasia
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
Hapus dari file atribut yang tidak berlaku seperti: last-applied, creationtimestamp, finalizer, ownerreference, resourceversion, uid.
Hapus BareMetalHost:
kubectl -n gpc-system delete bmh/$SERVER
Ambil Secret bmc-credentials-$SERVER atau cadangan sebelumnya dari cellcfg dan terapkan.
Minta server untuk melakukan sesuatu yang berbeda.
Untuk menghapus status BMH yang di-cache:
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
Tunggu hingga server disediakan. Tonton cara pembuatan objek BMH. Anda mungkin perlu menghapus tugas enkripsi untuk memicu ulang.
|
| Operasi |
1.9.0
1.9.1
1.9.2 |
Gejala:
Status VM tetap ada dengan STATUS dari Provisioning atau Starting saat storageClassName adalah standard-block.
Solusi:
Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:
Verifikasi bahwa STATUS VM menampilkan Provisioning atau Starting:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG adalah jalur file kubeconfig cluster sistem.
PROJECT adalah project GDC tempat VM berada.
Opsional: Dapatkan detail status tambahan:
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME adalah nama VM yang tidak responsif.
Hapus VM:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME adalah nama namespace Anda.
Verifikasi bahwa penghapusan berhasil:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
Hasil yang mirip dengan berikut ini mengonfirmasi keberhasilan:
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
Hapus semua disk VM tersebut:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME Ganti nama setiap disk Anda dengan DISK_NAME_1 dan DISK_NAME_2 hingga DISK_NAME_N dan pastikan semua disk tercantum. Verifikasi bahwa penghapusan berhasil:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
Hasil yang mirip dengan berikut ini mengonfirmasi keberhasilan:
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_1" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_2" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_N" not found
Buat ulang VM dan disk.
Mulai ulang VM.
|
| Operasi |
1.9.2 |
Gejala:
gdcloud system container-registry load-oci gagal dengan error. Jika Anda menjalankan kembali perintah, perintah akan berjalan untuk jangka waktu yang berbeda dan gagal pada titik yang berbeda dalam proses seperti push atau pemberian tag ulang, tetapi dengan error yang serupa.
Solusi:
Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:
Ekspor KUBECONFIG ke kubeconfig admin root:
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- Keluarkan perintah ini untuk menskalakan kembali
deployment/root-admin-tftp-manager-controller menjadi 0 replika:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- Lakukan operasi yang gagal.
- Tingkatkan skala
deployment/root-admin-tftp-manager-controller menjadi 1 replika:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| Operasi |
1.9.1
1.9.2
1.9.3 |
Gejala:
gdcloud system container-registry load-oci gagal dengan error. Jika Anda menjalankan kembali perintah, perintah akan berjalan untuk jangka waktu yang berbeda dan gagal pada titik yang berbeda dalam proses seperti push atau pemberian tag ulang, tetapi dengan error yang serupa.
Solusi:
Abaikan pesan ini dengan aman. Panel ini akan menghilang setelah beberapa saat.
|
| Operasi |
1.9.2 |
Solusi:
Untuk mengatasi masalah ini, mulai ulang pod yang mengalami masalah.
|
| Operasi |
1.9.0
1.9.1
1.9.2 |
Gejala:
Status kondisi Server Siap adalah "False" dan Pesan berisi "job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...". Log tugas yang gagal berisi "Failed to connect to the host via ssh ... Permission denied (publickey)."
Solusi:
Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:
Ambil kunci SSH publik saat ini dari cluster admin root:
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -dTempatkan kunci ke dalam configmap ironic-vars:
kubectl -n gpc-system edit cm/ironic-vars Tambahkan atau ganti IRONIC_RAMDISK_SSH_KEY yang ada:
<SSH public key>
Mulai ulang deployment Ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic Untuk setiap server yang terpengaruh:
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| Operasi |
1.9.2 |
Solusi:
Untuk menghindari masalah kekurangan alamat IP, tetapkan ukuran CIDR Pod ke /21 atau lebih tinggi saat membuat cluster pengguna dengan ketersediaan tinggi.
|
| Penginstalan |
1.9.2 |
Solusi:
Untuk mengatasi masalah ini, mulai ulang pod.
Lihat runbook MON-R0001 untuk mengetahui detailnya.
|
| Autentikasi platform |
1.9.13 |
Gejala:
Semua tugas cplb-init dan storage-ipsec-config-bm-XXXXX menampilkan pesan berikut: Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out.
Solusi:
1. Periksa apakah bgp vrf tidak berfungsi di aggswitch.
2. Periksa apakah ada perubahan yang belum di-commit untuk konfigurasi penyiapan baru di firewall.
3. Hapus semua securitypolicyrules yang memiliki organisasi yang dihapus dalam namanya dan mulai ulang root-admin-controller.
|
| Upgrade |
1.9.1
1.9.2
1.9.11 |
Gejala:
Server telah .status.bareMetalHostStatus.provisionState macet di deprovisioning selama lebih dari 20 menit.
Alamat IP pengelolaan server yang diupgrade disertakan dalam output salah satu perintah berikut:
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,option:tftp-server
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,tag:ipxe,option:bootfile-name
Solusi:
Untuk mengatasi masalah ini, jalankan:
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| Upgrade |
1.9.1
1.9.2
1.9.10
1.9.11
1.9.12
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18 |
Gejala:
Satu tugas upgrade di NodeUpgrade belum selesai selama lebih dari 2 jam.
NodeUpgradeTask yang sesuai mengalami error pada kondisi NodeResumeCompleted dan belum selesai selama lebih dari 1 jam.
bm-system-x.x.x.x-machine-init pekerjaan belum selesai dalam waktu yang lama. x.x.x.x adalah alamat node.
Solusi:
Untuk menemukan alamat node yang tidak sehat, lihat x.x.x.x dari tugas bm-system-x.x.x.x-machine-init yang terhenti.
Untuk menemukan node panel kontrol yang berfungsi baik untuk node yang tidak berfungsi baik, lakukan langkah-langkah berikut:
- Temukan nodepool node yang tidak responsif.
Periksa node pool bidang kontrol di cluster yang sama dengan node yang tidak sehat tersebut dan pilih alamat dari .spec.address node pool bidang kontrol tersebut.
Di bootstrapper atau OC IT, jalankan:
HEALTHY_CP_NODE_IP=Y.Y.Y.Y # Needs to be entered.
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
HARBOR=$(ka get harborcluster harbor -n harbor-system -o=jsonpath="{.spec.externalURL}")
REGISTRY=${HARBOR#https://}
# Download `etcdctl`.
docker run --rm -v $(pwd):/workspace --workdir /workspace ${REGISTRY}/library/anthos-baremetal-release/etcd:v3.4.21-0-gke.1 /bin/sh -c "cp /usr/local/bin/etcdctl /workspace/etcdctl"
scp etcdctl "root@$HEALTHY_CP_NODE_IP:/root/etcdctl"
# SSH into the healthy control plane node.
ssh $HEALTHY_CP_NODE_IP
Di dalam node bidang kontrol yang berfungsi dengan baik, jalankan:
UNHEALTHY_NODE_IP=X.X.X.X # Needs to be entered.
UNHEALTHY_MEMBER=$(ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member list | grep $UNHEALTHY_NODE_IP | cut -d',' -f1)
ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member remove $UNHEALTHY_MEMBER
|
| Upgrade |
1.9.1
1.9.2 |
Gejala:
Pod ODS Fleet Operator mengalami loop error.
Untuk memeriksa status pod, jalankan:
ko get pods -n ods-fleet-operator
Error pemilihan pemimpin yang mirip dengan berikut muncul di log ODS Fleet Operator:
E0413 18:06:48.614127 1 leaderelection.go:330] error retrieving resource lock ods-fleet-system/af0cf209.dbadmin.gdc.goog: Get "https://172.20.0.1:443/apis/coordination.k8s.io/v1/namespaces/ods-fleet-system/leases/af0cf209.dbadmin.gdc.goog": context deadline exceeded
I0413 18:06:48.614214 1 leaderelection.go:283] failed to renew lease ods-fleet-system/af0cf209.dbadmin.gdc.goog: timed out waiting for the condition
E0413 18:06:48.614460 1 main.go:473] "setup: problem running manager" err="leader election lost" log_name="l1_controller"
Untuk memeriksa log ODS Fleet Operator, jalankan:
ko logs deployment/fleet-controller-manager -n ods-fleet-system
Pesan berikut akan ditampilkan:
Message: Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgrade error: post-upgrade hooks failed: timed out waiting for the condition: timed out waiting for the condition.
Solusi:
Untuk mengedit deployment, jalankan:
ko edit deployment -n ods-fleet-system fleet-controller-manager
ku edit deployment oracle-controller-manager -n ods-oracle-system
ku edit deployment pg-controller-manager -n ods-postgres-system
Pastikan untuk mengedit kolom resources penampung manager sebagai berikut:
Sebelum:
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
Sesudah:
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| Upgrade |
1.9.2
1.9.3 |
Gejala:
Pesan error berikut akan muncul:
nvidia-driver-init run the action: init, with options: skip_driver
nvidia-driver-init Find the nvidia card, label this node
nvidia-driver-init node/MACHINE_NAME not labeled
nvidia-driver-init enable nvidia container runtime for ubuntu/debian system
nvidia-driver-init install nvidia container runtime package
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container1_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container1:amd64 (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container1:amd64 (1.12.0-1) ...
nvidia-driver-init Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container-tools_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container-tools (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container-tools (1.12.0-1) ...
nvidia-driver-init dpkg: regarding .../nvidia-container-toolkit-base_1.12.0-1_amd64.deb containing nvidia-container-toolkit-base:
nvidia-driver-init nvidia-container-toolkit-base breaks nvidia-container-toolkit (<= 1.10.0-1)
nvidia-driver-init nvidia-container-toolkit (version 1.8.1-1) is present and installed.
nvidia-driver-init dpkg: error processing archive var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb (--install):
nvidia-driver-init installing nvidia-container-toolkit-base would break nvidia-container-toolkit, and
nvidia-driver-init deconfiguration is not permitted (--auto-deconfigure might help)
nvidia-driver-init Errors were encountered while processing:
nvidia-driver-init var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb
Solusi:
Untuk memperbaiki masalah ini, lakukan langkah-langkah berikut:
Login ke semua node GPU yang disediakan:
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
Hapus paket lama:
root@MACHINE_NAME:~# dpkg -r nvidia-container-runtime nvidia-container-toolkit
(Reading database ... 92154 files and directories currently installed.)
Removing nvidia-container-runtime (3.8.1-1) ...
Removing nvidia-container-toolkit (1.8.1-1) ...
Hapus pod kubevm-gpu-driver-daemonset yang macet. Tindakan ini akan memulai ulang penginstalan:
# kug get pods -A | grep gpu | grep Init
(Opsional) Jika penginstalan add-on kehabisan waktu, mulai ulang penginstalan add-on:
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| Upgrade |
1.9.10
1.9.11 |
Gejala:
gpcbackup-agent-0 menampilkan failed to stage volume: iSCSI login failed dan gagal melakukan penahapan volume.
Periksa apakah pod gagal melampirkan volume. Contoh berikut menggunakan kubeconfig cluster sistem:
-
Deskripsikan pod:
kos describe pod -n gpc-backup-system gpcbackup-agent-0
Jika pod gagal, output yang mirip dengan contoh berikut akan ditampilkan:
Warning FailedMount 24m (x1064 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[kube-api-access-cr45d gpcbackup-agent-vol]: timed out waiting for the condition
Warning FailedMount 9m18s (x4109 over 7d17h) kubelet MountVolume.MountDevice failed for volume "pvc-5df41864-63c5-4589-9569-036fa011f64c" : rpc error: code = Internal desc = failed to stage volume: iSCSI login failed
Warning FailedMount 4m32s (x3840 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[gpcbackup-agent-vol kube-api-access-cr45d]: timed out waiting for the condition
-
Periksa node tempat pod gagal:
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
Anda akan mendapatkan output yang mirip dengan contoh berikut:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none]
-
Dapatkan pod netapp-trident di node yang sama dengan pod gpcbackup-agent-0 yang gagal:
kos get pod -o wide -n netapp-trident
Anda akan mendapatkan output yang mirip dengan contoh berikut:
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
Periksa log pod netapp-trident di node yang sama dengan pod gpcbackup-agent-0 yang gagal:
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
Anda akan mendapatkan output yang mirip dengan contoh berikut:
time="2024-01-25T17:35:29Z" level=error msg="Failed to discover targets" error="process killed after timeout" output= portal="172.20.131.41:3260" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
time="2024-01-25T17:35:29Z" level=error msg="unable to ensure iSCSI target exists: failed to discover targets: process killed after timeout" err="failed to discover targets: process killed after timeout" iface=default requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI targetIqn="iqn.1992-08.com.netapp:sn.944e1654ac1c11ee86b0d039ea524d51:vs.26" tp="172.20.131.41:3260"
time="2024-01-25T17:35:29Z" level=error msg="GRPC error: rpc error: code = Internal desc = failed to stage volume: iSCSI login failed" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
Solusi:
Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:
-
Dapatkan nama InventoryMachine:
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
Konfirmasi bahwa tugas sebelumnya ada:
export ORG_ADMIN_KUBECONFIG=[path to the org admin kubeconfig]
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-"${INV_MACH}"
Anda akan mendapatkan output yang mirip dengan berikut ini:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
Hapus tugas:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Anda akan mendapatkan output yang mirip dengan berikut ini:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Pastikan StorageEncryptionConnection ada:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Anda akan mendapatkan output yang mirip dengan berikut ini:
NAME INVENTORYMACHINE STORAGEVIRTUALMACHINE STORAGECIDR PRESHAREDKEY READY AGE
vm-e2b9792a vm-e2b9792a org-1-user 172.20.131.32/27 vm-e2b9792a-pre-shared-key True 19d
-
Hapus StorageEncryptionConnection.
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Anda akan mendapatkan output yang mirip dengan berikut ini:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Mulai ulang pod root-admin-controller:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout restart deploy -n gpc-system root-admin-controller && kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout status deploy -n gpc-system root-admin-controller
-
Konfirmasi bahwa tugas baru telah dibuat ulang dan berhasil dijalankan:
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
Anda akan mendapatkan output yang mirip dengan berikut ini:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| Upgrade |
1.9.10
1.9.11 |
Gejala:
Pod registry Harbor menampilkan pesan error yang mirip dengan berikut ini:
Warning FailedMount 6m52s (x718 over 2d14h) kubelet Unable to attach or mount volumes: unmounted volumes=[storage], unattached volumes=[registry-config authentication-htpasswd internal-certificates sto │
│ age[]: timed out waiting for the condition
Solusi:
Untuk mengatasi masalah ini, ikuti langkah-langkah berikut:
-
Periksa Persistent Volume Claim (PVC) registry Harbor dan catat nama volume PVC:
kubectl get pvc harbor-registry -n harbor-system
-
Untuk memeriksa apakah lampiran volume berada di node yang sama dari pod registry Harbor, buat daftar volumeattachment dan temukan yang terkait dengan nama volume:
kubectl get volumeattachment | grep [volume-name]
-
Jika lampiran volume berada di node yang berbeda dari pod Harbor registry, hapus volumeattachment:
kubectl delete volumeattachment [volumeattachment-name]
-
Mulai ulang pod registry Harbor.
Sekarang, registry Harbor di cluster admin root harus dalam kondisi baik dan upgrade node berhasil diselesaikan.
|
| Penginstalan |
1.9.2
1.9.3
1.9.4
1.9.5
|
Gejala:
Pesan error berikut akan muncul:
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Log pod berisi hal berikut:
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
Versi CoreDNS adalah 1.8.6.
Solusi:
Untuk mengatasi masalah ini, mulai ulang deployment coredns.
Setelah KUBECONFIG disetel untuk cluster yang benar, jalankan:
kubectl rollout restart deployment coredns -n kube-system
Nama cluster pengguna adalah bagian dari pesan error.
Untuk menemukan file kubeconfig di /root/release/user/, temukan kubeconfig: org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
Jika file kubeconfig tidak ada, buat file tersebut sebagai berikut:
export KUBECONFIG=/root/release/org-admin/org-1-admin-kubeconfig
kubectl get secrets -n user-vm-1-cluster user-vm-1-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/user-vm-1-user-kubeconfig
|
| Upgrade |
1.9.2
1.9.3 |
Gejala:
Pesan error berikut akan muncul:
Warning ReconcileBackoff 43m (x9 over 61m) OrganizationUpgrade [UPG1402: unable to set AddOn selector labels for root-admin cluster: Operation cannot be fulfilled on clusters.baremetal.cluster.gke.io "root-admin": the object has been modified; please apply your changes to the latest version and try again, UPG9900: unable to update status: OrganizationUpgrade.upgrade.private.gdc.goog "root" is invalid: [status.errorStatus.errors[0]. errorResource.name: Required value, status.errorStatus.errors[0].errorResource.namespace: Required value]]
Masalah ini biasanya bersifat sementara dan akan hilang.
|
| Penginstalan |
1.9.3 |
Penginstalan add-on gagal dengan error berikut:
Error occurred during addon installation: failed to install chart: release netapp-trident failed, and has been uninstalled due to atomic being set: failed post-install: timed out waiting for the condition.
Solusi:
Penginstalan add-on mungkin gagal karena node berada dalam status NotReady. Periksa apakah node dalam status NotReady menggunakan:
kubectl get nodes
Dapatkan detail untuk node yang berada dalam status NotReady:
$ kubectl describe node | grep PodCIDRs
Untuk cluster yang mengalami masalah ini, node tidak memiliki PodCIDR yang ditetapkan, misalnya:
PodCIDRs:
For a healthy cluster, all the nodes should have PodCIDRs assigned to it(CIDR shown here is for example purposes only and might vary on the actual cluster based in the Configured ClusterCIDR): eg.
PodCIDRs: 192.168.6.0/24
Untuk memperbaiki masalah ini, mulai ulang deployment ipam-controller di cluster yang terpengaruh:
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| Upgrade |
1.9.3 |
Upgrade gagal dengan error berikut:
Rollback "netapp-trident" failed: cannot patch "netapp-trident-csi-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp 172.20.5.144:443: i/o timeout && cannot patch "netapp-trident-server-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-client-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-selfsigned-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded.
Solusi:
Perbarui kolom AddOnSet abm-overrides's <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> secara manual ke nama AddOnSetTemplate versi yang diinginkan di namespace yang sama dengan cluster yang diupgrade.</code.spec.addonsettemplateref<>
|
| Penginstalan |
1.9.3 |
Gejala:
Pengontrol admin armada gagal siap sehingga pengujian TestCreateFleetAdminCluster atau TestSimOverlayCreateFleetAdminCluster gagal. Pengontrol admin armada terjebak dalam loop error. Error berikut ada di log pengontrol admin armada: Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced.
Solusi:
Deploy CRD Logmon ke cluster admin org. Mulai ulang pengontrol admin armada.
|
| Penginstalan |
1.9.3 |
Gejala:
Pesan error berikut akan muncul:
k8s_mt_system_cluster_healthcheck_test.go:147: system cluster did not become ready in time: cluster "org-1-system-cluster/org-1-system" did not become healthy in time: [waitingForClusterHealth] WaitForSuccess gave up [...] unable to retrieve logs for pod "anthos-prometheus-k8s-0" [...] pod "anthos-prometheus-k8s-0" in namespace "obs-system" is not ready yet. [...] Message:containers with unready status: [config-reload prometheus-server] [...]
Solusi:
Untuk mengatasi masalah ini, mulai ulang deployment dan daemonset di cluster:
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
Catatan: Jalankan perintah berikut sebelum memulai ulang deployment dan daemonset untuk mengarah ke cluster yang benar:
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| Upgrade |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
Gejala:
Pod tidak dapat dijadwalkan karena CPU tidak mencukupi.
Solusi:
Untuk cluster pengguna yang sudah ada dan dibuat dengan node pekerja n2-standard-4, tambahkan NodePool n2-standard-8 baru dengan tiga node ke cluster ini sebelum mengupgrade. Untuk cluster pengguna baru, buat dengan satu NodePool n2-standard-8 dengan minimal tiga node. Lihat Membuat cluster pengguna untuk beban kerja penampung untuk mengetahui detailnya.
|
| Operasi |
1.9.0
1.9.2
1.9.3
1.9.4 |
Gejala:
Instance VM PHASE menampilkan Scheduling dan READY
tetap False, tidak pernah mencapai status True. Hal ini
memengaruhi dua jenis mesin, seperti yang tercantum untuk solusi. Jenis mesin lainnya tidak terpengaruh dan tidak memerlukan solusi.
Solusi:
- Saat membuat cluster pengguna yang menggunakan GPU A100 40G, selalu pilih jenis mesin a2-highgpu-1g-gdc dari UI.
- Saat membuat cluster pengguna yang menggunakan GPU A100 80G, selalu pilih jenis mesin a2-ultragpu-1g-gdc dari UI.
|
| Operasi |
1.9.0
1.9.2
1.9.3
1.9.4 |
Gejala:
Untuk node pool dengan instance VM yang memiliki ukuran memori lebih besar dari 32 GB,
instance VM dapat tampak berjalan, lalu berhenti, dan berjalan lagi; mungkin mengulangi
urutan ini. Pada akhirnya, error OOMKilled kehabisan memori akan terjadi dan instance akan gagal.
Berikut adalah tiga jenis VM yang terpengaruh:
- n2-highmem-8-gdc: Memori 64 GB
- a2-highgpu-1g-gdc: Memori 85 GB
- a2-ultragpu-1g-gdc: Memori 170 GB
Solusi:
- Verifikasi jenis mesin Anda:
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- Cari jenis VM di
spec.compute.virtualMachineTypeName dalam output Anda.
- Jika jenis VM adalah salah satu dari tiga jenis yang tercantum
edit
configmap untuk menyertakan penggantian memori:
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- Tambahkan bagian
memory.guest dan resources.overcommitGuestOverhead
seperti yang Anda lihat dalam contoh berikut:
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
- Di
memory, ubah guest agar memiliki nilai berikut:
- Untuk n2-highmem-8-gdc, buat MEMORY_SIZE
63.6G.
- Untuk a2-highgpu-1g-gdc, buat MEMORY_SIZE
84G.
- Untuk a2-ultragpu-1g-gdc, buat MEMORY_SIZE
168G.
- Ulangi langkah ini untuk semua VM yang terpengaruh.
|
| Upgrade |
1.9.4 |
Gejala:
Tugas bm-system-* mengalami error pada langkah Gathering Facts. Saat mencoba melakukan SSH ke server secara manual, PTY allocation request failed on channel 0 ditampilkan.
Solusi:
Mulai ulang server menggunakan salah satu cara berikut:
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
UI iLO kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| Upgrade |
1.9.4
1.9.10 |
Gejala:
Upgrade gagal karena tugas backup-ipsec-* gagal.
Solusi:
Ikuti langkah-langkah berikut:
Temukan kunci pra-bagi di namespace gpc-system di cluster admin org. Kuncinya diberi nama <node-name>-pre-shared-key.
Untuk mendapatkan hash kunci dari yaml pre-shared-key node yang berfungsi, gunakan kubectl get --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig -n gpc-system secret <not-failed-node-name>-pre-shared-key -o=jsonpath='{.data.pre-shared-key}' | awk '{ print $1 }'.
Perhatikan bahwa Anda harus mendapatkan hash kunci dari node selain node tempat upgrade IPsec gagal. Terapkan hash untuk pre-shared key ini ke rahasia pre-shared-key node yang gagal di gpc-system di cluster admin org. Hapus objek storageencryptionconnection yang memiliki nama yang sama dengan node yang gagal di cluster admin root. Hapus tugas storage-ipsec-config-<node-name> terkait di cluster admin org. Hapus tugas upgrade backup-ipsec-for-upgrade-<node-name> terkait.
|
| Upgrade |
1.9.4 |
Gejala:
Mengupgrade cluster org membutuhkan waktu yang lama.
Solusi:
Tunggu hingga clamav mati dengan sendirinya.
|
| Upgrade |
1.9.5 |
Gejala:
Sertifikat yang berbeda ditampilkan:
echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBqjCCAS+gAwIBAgIQSve6hYhac9nZr/u/l/hPzjAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTcwMzQ3MjhaFw0yODA3MTUwMzQ3
MjhaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MHYwEAYHKoZIzj0CAQYFK4EEACID
YgAEsGCynvjnSNNIdz3PxpEqvogHAITWyB3jJbA6jxQhics5MYuq2biaqLg38Ly1
3mF6CRh9Tzroxg2Wtu339McKTAC/7v61ZsbGXbj3eQiTECJut/a55BekG7FcwVG/
btbAo0IwQDAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQUUh1ZUS9CUIHgQmJZTj8m3MIINS8wCgYIKoZIzj0EAwMDaQAwZgIxALDea5fh
IeafRNzR3pjYRgW++TCYZU3XVSJ04K8eIBy1wz1XRDR5SWFgJ/ejWZGUagIxAIQP
9A42lzd7gyqaAAlRB+TQ0sMJMOOyNl0gFg5ZVyhGdJfsZpv1XrcLcqX3tejydw==
-----END CERTIFICATE-----
echo $(kubectl get secret ca-cert-10.2.2.101.10443 -n anthos-creds -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBazCCARKgAwIBAgIQKkDVSpMZf9CQEHxx7UFPmDAKBggqhkjOPQQDAjAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTYwOTQzMTlaFw0yNDA3MTUwOTQz
MTlaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEI4hXIh65Zc8sWaPQL9gqz3lrq22A1XJsRrMwl/pk3vZiNLGS3+Tt9tXc
WDP74IbinOxZ1Auw08e3s4sxCahfyqNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1Ud
EwEB/wQFMAMBAf8wHQYDVR0OBBYEFN8ob6e8WeFELnVKPSdtMfyvRP95MAoGCCqG
SM49BAMCA0cAMEQCIF8P5THYBHcOdcn1u7zi+Y4jwDTdLAeaDZbVxUDEK2EaAiBW
zilvR3YvW7h5OdSUsgFkSQ42FcSIoNHWYNSZx16CeQ==
-----END CERTIFICATE-----
Solusi:
Catatan: Rotasi sertifikat harbor-harbor-https sebelum langkah-langkah berikut.
Ikuti langkah-langkah berikut:
Ada salinan data sertifikat yang disimpan dalam secret di dalam cluster. Setelah merotasi sertifikat harbor-harbor-https, Anda juga harus memperbarui salinan rahasia.
- Ambil URL Artifact Registry.
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- Perbarui salinan secret sertifikat Artifact Registry di setiap namespace.
Mendapatkan semua namespace yang menyimpan salinan rahasia sertifikat Artifact Registry.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
Perbarui salinan secret sertifikat Artifact Registry di setiap namespace.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done
- Untuk cluster root-admin, Anda juga perlu mengupdate perbaikan bernama salinan secret sertifikat yang disebut
ca-cert-in-cluster-registry di namespace anthos-creds.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n anthos-creds patch secret/ca-cert-in-cluster-registry -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"
- Perbarui
registry-cert yang disimpan di namespace kube-system.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n kube-system patch secret/registry-cert -p "{\"data\":{\"registry-cert\":\"${cert_data}\"}}"
- Jika Anda mengganti sertifikat untuk cluster org-admin, Anda juga perlu memperbarui salinan rahasia sertifikat yang ada di cluster root-admin.
Mendapatkan semua namespace yang menyimpan salinan rahasia sertifikat Artifact Registry.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
Perbarui salinan secret sertifikat Artifact Registry di setiap namespace.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done .
|
| Upgrade |
1.10.0
1.10.1 |
Gejala:
Setelah memulai OrganizationUpgrade, pod
kube-apiserver tidak berjalan di satu atau beberapa node.
- Identifikasi node tempat upgrade diblokir:
kubectl get po -n kube-system -l component=kube-apiserver
Outputnya akan terlihat seperti ini:
NAME READY STATUS RESTARTS AGE
kube-apiserver-ah-aa-bm01 1/1 Running 0 12h
kube-apiserver-ah-ab-bm01 1/1 Running 0 11h
kube-apiserver-ah-ac-bm01 1/1 Error 0 12h
- Buat koneksi SSH ke node yang baru saja diupdate:
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
Anda akan melihat status penampung sebagai Exited:
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
- Periksa log pod
Exited:
crictl logs f1771b8aad929
Outputnya akan terlihat seperti ini:
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
Tanda dikonfigurasi dalam file /etc/kubernetes/manifests/kube-apiserver.yaml:
root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
Solusi:
Hapus tanda dari file /etc/kubernetes/manifests/kube-apiserver.yaml.
- Mencadangkan file:
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- Hapus baris:
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- Konfirmasi bahwa baris telah dihapus:
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- Tampilkan daftar container
kube-apiserver:
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet akan otomatis mengambil perubahan dan memulai pod
kube-apiserver:
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- Ulangi langkah-langkah ini untuk semua node yang terpengaruh.
|
| Upgrade |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
Gejala:
Loop error deployment kube-state-metrics di
organisasi setelah rotasi sertifikat. Masalah ini dapat menyebabkan hilangnya data pemantauan.
|
| Upgrade |
1.9.6 |
Gejala:
Setelah upgrade, node pekerja menjadi tidak seimbang.
Solusi:
Seimbangkan node pekerja secara manual:
- Untuk workload pod, hapus pod dalam deployment.
- Untuk beban kerja VM, hapus virt-launcher tanpa mengubah objek GVM bidang kontrol.
|
| Upgrade |
1.9.6 |
Saat mengupgrade dari 1.9.5 ke 1.9.6, ada kemungkinan plugin perangkat GPU tidak dapat dimulai.
Gejala:
Anda mungkin melihat error berikut yang memblokir kesiapan runtime VM
dan proses upgrade:
Failed to initialize NVML: could not load NVML library
Solusi:
- Periksa apakah
nvidia-container-runtime dikonfigurasi dengan benar di node:
- Buat koneksi SSH ke node yang Anda duga mengalami
masalah.
- Dapatkan daftar pod:
crictl pods
- Periksa pod:
crictl inspectp $pod_hash | grep runtimeOption -A1
Jika output terlihat seperti ini, node telah dikonfigurasi dengan benar. Jika
output tidak terlihat seperti ini, berarti nvidia-container-runtime
tidak dikonfigurasi di node:
binary_name": "/usr/bin/nvidia-container-runtime"
- Jika
nvidia-container-runtime tidak dikonfigurasi dengan benar, mulai ulang containerd untuk menyelesaikan masalah:
systemctl restart containerd
|
| Upgrade |
1.9.7 |
Saat mengupgrade ke 1.9.7, firmware node pool cluster admin root tetap dalam status in process.
Gejala:
- Untuk sisi
NodeUpgrade, lihat solusi Waktu tunggu server artefak:
NodeUpgrade macet dalam status in process dan Kondisi untuk NodeROMFirmwareUpgradeCompleted dalam status Nodeupgradetask selalu tidak selesai.- URL di
spec.firmware.firmwarePackages.url dalam objek NodeUpgrade mungkin mengalami masalah saat terhubung, misalnya:
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
- Untuk sisi
Harbor, lihat solusi alternatif Server artefak tidak sah:
- Di log server artefak, error terkait akses tidak sah ke repositori mungkin ditampilkan:
gdch-hpe-firmware/ilo, misalnya:
root@bootstrapper:~# kubectl --kubeconfig ${KUBECONFIG} logs -n gpc-system -l name=artifact-registry-services-artifact-server -f
artifact-server I1108 05:20:28.084320 1 artifact_server.go:171] Pulling artifact at path /artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU=
artifact-server E1108 05:20:28.159685 1 artifact_server.go:194] Error fetching image 10.249.23.11:10443/gdch-hpe-firmware/ilo:ilo5: GET https://10.249.23.11:10443/v2/gdch-hpe-firmware/ilo/manifests/ilo5: UNAUTHORIZED: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull
- Di project Harbor,
gdch-hpe-firmware harus memiliki Spec.harborProjectConfig.accessLevel sebagai private:
kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
Solusi:
|
| Jaringan yang lebih rendah |
1.9.0 - 1.9.6 |
Gejala:
Sesi BGP tidak berfungsi di jaringan internal organisasi. Hanya satu endpoint peering BGP internal organisasi yang ditambahkan ke Objek TORSwitchInternal.
Solusi:
Ubah secara eksplisit subnet yang digunakan di {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim agar tidak tumpang-tindih dengan resource AddressPoolClaim serupa milik organisasi lain.
- Menyelidiki gejala:
- Untuk setiap cluster sistem organisasi, jalankan:
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- Periksa kolom
State setiap objek BGPSession untuk mengetahui State dari NotEstablished. Catat LocalIP setiap NotEstablished BGPSession terkait untuk digunakan nanti.
- Tentukan apakah
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" adalah penyebab utama:
- Untuk setiap organisasi aktif, jalankan:
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- Cari kolom
ClusterIP output (kolom ke-3) untuk menemukan LocalIPs yang tercantum di langkah 1.b. Catat LocalIP yang cocok dengan entri di kolom ke-3 output untuk digunakan nanti. Jika ada beberapa cluster admin organisasi yang berbeda, dengan output dari 2.a berisi LocalIP yang tercantum di langkah 1.b, lanjutkan ke langkah 3.
- Menyelesaikan IP yang tumpang-tindih yang digunakan untuk cluster sistem organisasi.
- Jalankan:
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- Catat jumlah objek
SubnetClaim yang ditampilkan dari kueri di 3.a. Nilai ini harus sama dengan jumlah organisasi aktif.
- Untuk setiap baris, catat Namespace (kolom 1), dan blok CIDR (kolom 3). Blok CIDR setiap baris harus sama dengan blok CIDR setiap baris lainnya.
- Untuk setiap organisasi, lakukan langkah-langkah berikut:
- Buka objek
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim di cluster admin organisasi milik organisasi tersebut.
- Hitung
Start IP klaim kumpulan alamat node pekerja organisasi tersebut. Untuk melakukannya, ambil blok CIDR dari 3.c dan kolom Size di AddressPoolClaim dari 3.d.i. Mulai dari IP kedua terakhir di blok CIDR, hitung mundur Size IP. Ini adalah Start IP baru untuk organisasi pertama (digunakan pada langkah 3.d.iii). Untuk setiap organisasi tambahan, hitung mundur Size IP detik, dimulai dari Start IP baru organisasi sebelumnya.
Contoh:
CIDR block: 10.0.0.0/24
org-1, org-2, & org-3 AddressPoolClaim Size: 2
- New org-1 startIPAddress: 10.0.0.252
- New org-2 startIPAddress: 10.0.0.250
- New org-3 startIPAddress: 10.0.0.248
- Di
AddressPoolClaim dari langkah 3.c.i, tambahkan kolom berikut di kolom Spec:
staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
Gunakan perintah berikut:
`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
Hasilnya harus terlihat seperti berikut jika Anda menggunakan org-1 dari 3.d.ii misalnya:
apiVersion: system.private.gdc.goog/v1alpha1
kind: AddressPoolClaim
metadata:
name: org-1-system-bgp-flat-ip-ipv4-apc
namespace: org-1-system-cluster
...
spec:
category: InternalOverlayNetwork
...
parentReference:
name: worker-node-network-subnet
type: SubnetClaim
size: 2
staticIPRanges:
- startIPAddress: 10.0.0.252
size: 2
status:
allocatedIPRanges: ...
...
- Lakukan pembersihan untuk menghindari Sesi BGP yang tidak perlu pada hardware TORSwitch.
- Untuk mencantumkan semua resource
TORSwitchInternal yang perlu diperbarui, jalankan:
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- Untuk setiap
TORSwitchInternals yang tercantum dalam output perintah sebelumnya, jalankan perintah berikut:
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- Untuk semua objek
TORSwitchInternal, hapus semua entri dari daftar .spec.ebgpNeighbors yang memiliki NeighborIP yang sama dengan LocalIP dari langkah 2.b. Misalnya, LocalIP dari 2.2.2.2 dicatat dari langkah 2.b. Berikut adalah contoh TORSwitchInternal sebelum dan sesudah langkah pembersihan.
Sebelum pembersihan:
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
- md5SecretReference: {}
neighborIP: 2.2.2.2
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
Setelah pembersihan. Perhatikan entri ebgpNeighbor yang dihapus:
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- Validasi dengan melakukan Langkah 1 dan mengonfirmasi bahwa semua objek
BGPSession States telah kembali ke Established. Mungkin diperlukan waktu sekitar 10 menit agar semua modifikasi diterapkan ke konfigurasi TORSwitch GDC fisik.
|
| Upgrade |
1.9.7 - 1.9.21 |
Selama upgrade, ada kemungkinan upgrade node dan sistem operasi tidak berjalan.
Gejala:
Anda mungkin melihat node yang memiliki status Ready, SchedulingDisabled selama beberapa jam.
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG get no
NAME STATUS ROLES AGE VERSION
aa-bm01 Ready, SchedulingDisabled control-plane 52d v1.27.4-gke.500
ab-bm01 Ready control-plane 52d v1.27.4-gke.500
ac-bm01 Ready control-plane 52d v1.27.4-gke.500
Solusi:
- Ikuti runbook PLATAUTH-SSH 0001 untuk mendapatkan kunci SSH untuk node yang dimaksud. Setelah terhubung ke node dengan SSH, jalankan perintah berikut:
multipath -ll | grep fail
- Lanjutkan ke langkah berikutnya hanya jika output terlihat mirip dengan berikut ini:
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
| |- 7:0:0:7 sdad 65:208 failed faulty running
| `- 8:0:0:7 sdae 65:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:0:7 sdac 65:192 failed faulty running
`- 5:0:0:7 sdab 65:176 failed faulty running
- Jalankan perintah berikut untuk memperbaiki masalah:
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| Upgrade |
1.9.8-1.9.21 |
Gejala:
Jika upgrade cluster ABM terhenti selama lebih dari 2 jam, pengurasan node mungkin diblokir.
Solusi:
Operasi berikut menggunakan cluster admin root sebagai contoh ${TARGET_KUBECONFIG} mengacu pada `kubeconfig` untuk cluster ABM target yang pengosongan nodenya diblokir, ${KUBECONFIG} mengacu pada kubeconfig untuk cluster yang mengelola cluster ABM target. Untuk cluster admin root, keduanya merujuk ke kubeconfig admin root.
Selesaikan langkah-langkah berikut untuk melihat apakah upgrade cluster ABM macet:
- Periksa node yang macet saat pengurasan:
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
Hasilnya seperti:
{"10.200.0.2": 2}
Artinya, untuk node "10.200.0.2", dua pod sedang dikuras.
- Periksa apakah pod masih dikuras dari node (disebut sebagai
${NODE_BEING_DRAINED}):
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
Jumlah pod output harus sama dengan jumlah pod yang dikuras yang dilaporkan pada langkah sebelumnya.
Untuk setiap pod yetToDrain seperti yang tercantum di langkah 1, periksa status pod:
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
Jika pod dalam status Running, atau jika pod audit-logs-loki-0 atau loki-0 dalam namespace obs-system dan pod tidak memiliki peristiwa yang mengeluhkan unable to unmount volume, hapus pod secara eksplisit dengan grace-period.
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- Untuk semua kasus lain saat pod macet saat dikuras, eskalasikan ke layanan on-call.
- Pantau hingga pengurasan node selesai.
- Ulangi langkah pertama jika node lain mengalami masalah pengurasan.
|
| Upgrade |
1.9.6
1.9.7
1.9.8
|
Rilis 1.9 dengan artefak bertanda tangan tidak dapat didistribusikan karena
flag Override di DistributionPolicy disetel
ke false, yang mencegahnya didistribusikan jika ada
artefak dengan nama yang sama di tujuan pendaftaran.
Gejala:
Anda mungkin mengalami masalah berikut:
- Artefak dengan tanda tangan dikirim. Log mungkin terlihat seperti ini:
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- Gagal mengirimkan artefak. Log mungkin terlihat seperti ini:
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- Artefak 404 tidak ditemukan. Log mungkin terlihat seperti ini:
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- Distribusi artefak gagal.
Solusi:
Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:
- Perbarui resource kustom (CR)
DistributionPolicy untuk
menetapkan Spec.Override ke true.
- Picu ulang replikasi dengan mengikuti buku pedoman SAR-1005.
- Setelah menjalankan replikasi baru berhasil, perbarui
ManualDistribution CR execution-ids di
Annotation dengan ID eksekusi yang berhasil.
|
| Modul keamanan hardware (HSM) |
1.9.9 |
HSM mungkin melaporkan ServicesNotStarted secara berkala yang
dapat menyebabkan server bare metal tidak menjadi sehat dan melaporkan pesan
berikut:
"message": "failed to get master key name"
Gejala:
Anda mungkin mengalami masalah berikut:
Solusi:
Untuk mengatasi masalah ini, lakukan langkah-langkah berikut untuk memulai ulang HSM yang mengalami masalah:
- Instal alat
kstl dari HSM pertama dengan menjalankan perintah berikut:
export HSM_NAME=`kubectl get hsm \
-n gpc-system -o jsonpath={.items[0].metadata.name} | tr -d '"'`
export HSM_MGMT_IP=$(kubectl get hsm $HSM_NAME \
--namespace gpc-system \
--output jsonpath="{.spec.managementNetwork.ip}")
curl --insecure \
https://$HSM_MGMT_IP/downloads/ksctl_images.zip \
--output ksctl_images.zip
mkdir -p ~/bin
unzip ksctl_images.zip -d ~/bin
cp ~/bin/ksctl-linux-amd64 ~/bin/ksctl
export PATH=$PATH:~/bin
mkdir -p $HOME/.ksctl
export ADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "admin" | grep -v "luna-admin" | grep -v "ksadmin"`
export ADMIN_PW=$(kubectl get secrets $ADMIN_SECRET_NAME -n hsm-system -o jsonpath="{.data.password}" | base64 -d)
export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $HOME/.ksctl/ssh-privatekey
chmod 0600 $HOME/.ksctl/ssh-privatekey
cat << EOF > $HOME/.ksctl/config.yaml
KSCTL_URL: https://$HSM_MGMT_IP:443
KSCTL_USERNAME: admin
KSCTL_PASSWORD: '$ADMIN_PW'
KSCTL_NOSSLVERIFY: true
EOF
- Pastikan bahwa HSM mengalami masalah saat memulai ulang. Untuk setiap HSM yang macet
di
ServicesNotStarted, dapatkan
$HSM_MGMT_IP dan verifikasi bahwa layanan tidak berfungsi:
ksctl services status --url=https://$HSM_MGMT_IP
- Menjeda semua HSM, cluster HSM, dan tenant HSM:
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
- Buat koneksi SSH ke HSM saat layanan tidak berfungsi:
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- Pastikan Anda berada di HSM yang benar. Periksa apakah Anda membuat koneksi SSH dengan
$HSM_MGMT_IP yang benar.
- Mulai ulang HSM pertama dari dalam HSM:
ksadmin@ciphertrust:~ sudo reboot
- Tunggu hingga HSM pertama menjadi responsif dari luar HSM:
watch -c ksctl services status --url=https://$HSM_MGMT_IP
Langkah ini mungkin memerlukan waktu sekitar lima menit agar HSM dimulai ulang.
- Ulangi langkah-langkah ini untuk HSM lain yang layanannya tidak berfungsi.
- Lanjutkan HSM, cluster HSM, dan tenant HSM:
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
- Pastikan semuanya cocok. Mungkin perlu waktu lima hingga sepuluh menit agar HSM dapat disesuaikan.
|
| Pemantauan |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9 |
Gejala:
Notifikasi alertmanager-servicenow-webhook tidak mencapai ServiceNow di cluster sistem organisasi untuk versi GDC sebelum 1.11.3. Log berisi pesan error read: connection reset by peer. Masalah ini disebabkan oleh kurangnya label untuk mengaktifkan traffic keluar. Jika webhook perlu berkomunikasi antar-organisasi, webhook harus menggunakan NAT keluar.
Solusi:
Anda harus mengaktifkan traffic keluar untuk alertmanager-servicenow-webhook di cluster sistem organisasi. Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:
- Tetapkan prasyarat yang diperlukan:
- Instal antarmuka command line (CLI) gdcloud.
- Dapatkan jalur ke file kubeconfig dari cluster admin root dan admin org. Simpan jalur di variabel lingkungan
ROOT_KUBECONFIG dan ORG_SYSTEM_KUBECONFIG.
- Minta Admin Keamanan Anda untuk memberi Anda peran Observability Admin (
observability-admin) di namespace obs-system untuk cluster admin root dan admin org.
- Konfirmasi bahwa masalah ada di lingkungan Anda:
- Dapatkan deployment
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- Melihat log untuk deployment
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
Jika log berisi pesan error read: connection reset by peer, masalah tersebut ada dan Anda harus melanjutkan langkah-langkah solusi ini.
- Tambahkan label traffic keluar:
- Dapatkan file YAML deployment
alertmanager-servicenow-webhook saat ini:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml && \
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Tambahkan label keluar ke file YAML deployment
alertmanager-servicenow-webhook:
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Ganti file YAML deployment
alertmanager-servicenow-webhook dengan pembaruan:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
Deployment harus dimulai ulang secara otomatis.
- Verifikasi bahwa masalah telah diperbaiki dengan menjalankan kembali langkah-langkah Pastikan masalah ada di lingkungan Anda. Pesan error log tidak boleh ditampilkan. Jika tidak, eskalasikan ke tim engineering.
Strategi rollback:
Jika langkah-langkah solusi gagal atau Anda melihat penurunan metrik, kembalikan file YAML deployment alertmanager-servicenow-webhook ke keadaan semula:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| Upgrade |
1.9.10 |
Gejala:
Upgrade terhenti di langkah NodeMaintain.
gpc-system org-1-admin-control-plane-node-poolphdzg 1 in-progress 3h58m
Status: Tasks:
Name: zp-aa-bm06 Task Status: finished
Name: zp-aa-bm04
Task Status: finished
Name: zp-aa-bm05
Task Status: in-progress
Upgrade Status: in-progress
Events: none
nodeupgradetask untuk node pool yang sedang berlangsung menampilkan:
Status: Conditions: Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: Succeeded
Status: True
Type: PreUpgradeValidationCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: InProgress
Status: False
Type: NodeMaintainCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message: Observed Generation:1
Reason: Reconciling
Status: Unknown
Type: Succeeded
│ Data IP:10.249.20.4 bm-5f3d1782
│ Start Time: 2023-11-09T18:26:31Z
│ Events: none
Solusi:
Ikuti langkah-langkah berikut:
- Dapatkan nama deployment cap-controller-manager.
kubectl --kubeconfig ${KUBECONFIG} get deployment -n kube-system | grep cap-controller-manager
cap-controller-manager-1.28.0-gke.435 1/1 1 1 30h
- Tentukan nama cap-controller-manager (misalnya: cap-controller-manager-1.28.0-gke.435):
export CAP_DEPLOYMENT_NAME=
- Mulai ulang cap-controller-manager.
kubectl --kubeconfig ${KUBECONFIG} rollout restart deployment ${CAP_DEPLOYMENT_NAME} -n kube-system
deployment.apps/cap-controller-manager-1.28.0-gke.435 restarted
|
| Upgrade |
1.9.10 |
Gejala:
Upgrade macet di langkah pemeriksaan pasca-upgrade AdminClusterHealth.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
Objek organisasi menampilkan:
NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
Solusi:
Ikuti langkah-langkah berikut:
Gunakan perintah berikut untuk melewati pra-penerbangan:
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| Upgrade |
1.9.9 |
Gejala:
NodeUpgradeTask mungkin memiliki kondisi failed to monitor failover registry recreation: failed to monitor job: job not complete yang menghalangi penyelesaian tugas.
Solusi:
Untuk mengatasi masalah ini, mulai ulang tugas:
- Hapus tugas bernama
create-failover-registry-*** yang memiliki penyelesaian "0/1".
- Hapus anotasi
failover-registry-creation-job-name dari objek Server yang sedang diupgrade.
Pengontrol akan otomatis membuat tugas lagi.
|
| Upgrade |
1.9.20 |
Gejala:
Node gagal pada tugas backup-ipsec-for-upgrade-bm.
I0512 01:05:55.949814 7 main.go:24] BuildDate: 2023-04-01T15:48:57Z
I0512 01:05:55.949920 7 main.go:25] Version: 1.9.2-gdch.135.dirty
"
Solusi:
Hapus tugas `backup-ipsec-for-upgrade-bm` dan tunggu hingga tugas tersebut dibuat ulang.
|
| Google Distributed Cloud |
1.9.9 |
Gejala:
Node pool bidang kontrol tidak siap karena cluster etcd gagal dimulai. Anda mungkin mengalami masalah berikut:
--- FAIL: TestPlan (27563.26s)
--- FAIL: TestPlan/TestMTSystemClusterHealth (3445.24s)
k8s_mt_system_cluster_healthcheck_test.go:149: FATAL FLAKE: TestMTSystemClusterHealth: system cluster did not become ready in time: NodePool org-1-system-cluster/control-plane-node-pool didn't get ready: NodePool "control-plane-node-pool" is not ready
Error Routing:
{
"Name": "NODEPOOL_NOT_READY_ERR",
"Description": "NodePool is not ready",
"OwnerTeam": "Cluster Management",
"OwnerLDAP": "",
"TrackingBug""
}
FAIL
Solusi:
Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:
- Periksa apakah pembuatan cluster terhenti pada tugas inisialisasi mesin.
Tugas kubeadm join gagal karena:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
Tugas kubeadm reset gagal karena:
panic: runtime error: invalid memory address or nil pointer dereference
- Gunakan SSH untuk terhubung ke node panel kontrol yang berfungsi.
- Jalankan perintah
etcdctl untuk membersihkan data yang sudah tidak digunakan.
- Periksa langganan
etcd:
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member list
5feb7ac839625038, started, vm-72fed95a, https://10.252.164.11:2380, https://10.252.164.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://10.252.164.12:2380, https://10.252.164.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://10.252.164.10:2380, , false
- Hapus keanggotaan yang sudah tidak berlaku:
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member remove bd1949bcb70e2cb5
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
|
| Pencadangan dan pemulihan VM |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
Gejala:
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:
Internal error occurred: failed calling webhook
"vvirtualmachinebackupplantemplates.virtualmachine.gdc.goog":
failed to call webhook: Post "https://vmm-vm-controller-webhooks.vm-system.svc:443/validate-virtualmachine-gdc-goog-v1-virtualmachinebackupplantemplate?timeout=10s":
context deadline exceeded
Solusi:
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.
|
| Upgrade |
1.9.9 |
Gejala:
Upgrade gagal menjalankan tugas pencadangan ipsec karena error template berikut:
"msg": "An unhandled exception occurred while templating '{'changed': True, 'stdout': 'connections {\\n # A connection id defined for this specific connection\\n pol_client {\\n children {\\n pol_cli
Solusi:
Ikuti langkah-langkah berikut:
Login ke node tempat tugas upgrade gagal. Simpan swanctl.conf sebagai cadangan. Hapus baris dengan tanda kurung kurawal dalam file /etc/swanctl/swanctl.conf. Hapus tugas backup-ipsec-for-upgrade yang gagal dan tunggu hingga tugas tersebut dibuat ulang, lalu tugas berikutnya berhasil diselesaikan. Tambahkan kembali baris yang dihapus pada langkah 3 ke /etc/swanctl/swanctl.conf.
|
| Platform node |
1.9.6
1.9.7
1.9.8
1.9.9 |
Saat upgrade firmware dimulai di cluster admin root, setelah salah satu
node menyelesaikan upgrade node, node tersebut tampak macet.
Gejala:
nodeupgradetask macet di tahap
NodeResumeCompleted.- Tugas
machine-init gagal dan log menunjukkan bahwa
kubeadm join gagal.
- Anda tidak dapat membuat koneksi SSH ke node menggunakan alamat IP
bidang data.
Masalah ini disebabkan oleh node yang diupgrade tidak lagi menerima traffic jaringan masuk.
Solusi:
- Periksa log
job/nodeupgradetask yang gagal untuk mencatat alamat IP dan mencari tahu node mana yang bermasalah.
- Mulai ulang pod
anetd-client dari node yang terpengaruh.
- Verifikasi koneksi SSH di IP dataplane ke node yang terpengaruh.
Langkah opsional untuk penyelidikan lebih lanjut:
- Shell ke dalam container agen cilium dari salah satu pod anetd yang berfungsi.
- Jalankan cilium-bugtool dan tunggu sekitar 10 detik. Alat ini menyimpan
log di direktori
/var/log/network/policy_action.log.
- Cari
deny untuk melihat apakah traffic ditolak:
grep -r "deny" /var/log/network/ to
Perhatikan server mana yang ditolak, kemungkinan node bare metal admin root.
|
| Upgrade |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Gejala:
- Upgrade gagal pada add-on
atat-webhooks.
- Label add-on ATAT yang sudah tidak berlaku dapat menyebabkan upgrade Organisasi gagal.
Contoh:
Invalid value: "TO1234": The current date 2024-05-06 is not within the valid range of this TaskOrder: 2023-12-16 - 2024-04-16.
Solusi:
Pengguna harus memperbarui label add-on ATAT portofolio mereka. Ikuti runbook ATAT-R0003 untuk menyelesaikan masalah ini.
|
| Upgrade |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Gejala:
- Upgrade OS node di bare metal tenant org gagal saat mengupgrade dari 1.9.12 ke 1.9.13. Pesan berikut akan muncul:
Reason: Succeeded
Status: True
Type: NodeMaintainCompleted
Last Transition Time: 2024-05-06T18:25:20Z
Message: the ssh cert rotation job is still in progress
Observed Generation: 1
Reason: ReconcileBackoff
Status: Unknown
Type: Succeeded
Last Transition Time: 2024-05-06T18:27:42Z
-
SSH generation fails. The following message appears:
"tasks": [
{
"hosts": {
"10.248.4.72": {
"action": "gather_facts",
"changed": false,
"msg": "Failed to connect to the host via ssh: Certificate invalid: name is not a listed principal\r\nHost key verification failed
.",
"unreachable": true
}
},
"task": {
"duration": {
"end": "2024-05-06T19:47:11.284055Z",
"start": "2024-05-06T19:47:11.146536Z"
},
"id": "98f2b32d-e15c-fe27-2225-00000000001c",
"name": "Gathering Facts"
}
} ]
Solusi:
- Hapus anotasi
cluster.private.gdc.goog/ssh-trusted-ca-versions di CR server admin root dan admin org.
- Hapus tugas ansible yang gagal. Tugas baru dibuat secara otomatis karena anotasi
cluster.private.gdc.goog/host-key-rotation-in-progress
ditandai benar di CR server.
- Setelah rotasi, anotasi
cluster.private.gdc.goog/ssh-trusted-ca-versions ditambahkan kembali ke CR server.
|
| Node, Upgrade |
1.9.* |
Gejala:
Setelah upgrade, pod di beberapa node bare metal akan mengalami masalah di status CrashLoopBackOff, dan
iptables -L -v -n | grep CILIUM di node akan menampilkan hasil kosong.
Solusi:
Untuk mengatasi masalah ini, selesaikan langkah-langkah berikut:
- Jalankan perintah berikut:
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force.
- Jalankan
iptables -L -v -n | grep CILIUM lagi dan verifikasi bahwa ada output.
|
| Logging |
1.9.14
1.9.15 |
Gejala:
Pod audit-logs-loki-0 berada dalam status CrashLoopBackOff.
Verifikasi status pod:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
Dengan SYSTEM_KUBECONFIG adalah jalur ke file kubeconfig.
Error Loki ditampilkan seperti pada output berikut, dengan CrashLoopBackOff adalah statusnya:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
Solusi:
Untuk mengatasi masalah ini, selesaikan langkah-langkah berikut:
- Ekspor jalur ke file kubeconfig ke variabel lingkungan yang disebut
SYSTEM_KUBECONFIG.
- Turunkan skala operator Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Perkecil skala resource Loki:
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- Hapus klaim volume persisten (PVC)
audit-logs-loki-storage-audit-logs-loki-0 dan loki-storage-loki-0.
- Hapus volume persisten (PV)
obs-system/loki-storage-loki-0 dan obs-system/audit-logs-loki-storage-audit-logs-loki-0.
- Tingkatkan skala operator Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- Ikuti langkah-langkah untuk memperbarui konfigurasi logging dari versi 1.9.
- Periksa apakah pod
audit-logs-loki-0 sedang berjalan:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
Status Running harus ditampilkan dalam output seperti dalam contoh berikut:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| Infrastruktur sebagai kode |
1.9.16 |
Gejala:
Saat mengupgrade ke 1.9.16, penginstalan add-on Gitlab gagal. Anda
mungkin melihat error seperti ini:
Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgr │
│ ade error: timed out waiting for the condition: deployments/gitlab-sidekiq-all-in-1-v2: release gitlab failed: client rate limiter Wait returned an error: ra │
│ te: Wait(n=1) would exceed context deadline
Pod postgres, seperti gpc-system/gitlab-postgresql-0,
berada dalam status penghentian.
Solusi:
- Hapus secara paksa pod postgres yang macet dalam status menghentikan:
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- Pastikan pod postgres dibuat ulang setelah dihapus.
|
| Pengelolaan akses dan identitas |
1.9.19
1.9.20 |
Gejala:
Saat mengupgrade dari 1.9.18 dan mencoba mengakses
konsol GDC, Anda mungkin melihat pesan berikut:
Authentication failed, please contact your system administrator
Solusi:
- Dapatkan CA yang diperlukan:
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- Buka file konfigurasi klien untuk diedit:
kubectl edit clientconfig -n kube-public default
- Temukan
certificateAuthorityData di konfigurasi klien dan perbarui CA yang diperlukan menggunakan jalur berikut: spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
