에어 갭이 적용된 Google Distributed Cloud 1.12.x 알려진 문제

카테고리	식별된 버전	문제 및 해결 방법
백업 및 복원	1.12.1	볼륨 백업이 조직 수준 객체 스토리지 엔드포인트를 해결하지 않음 볼륨 백업용 스토리지 클러스터는 포워더 대신 외부 DNS 서버를 사용하므로 볼륨 백업이 조직 수준 객체 스토리지 엔드포인트를 확인할 수 없습니다. 버전 1.12에서는 백업 트래픽에 각 조직으로 연결되는 새 경로가 필요합니다. 해결 방법: IO는 조직 수준 DNS 확인을 사용 설정하고 각 조직의 복제 논리 인터페이스 (LIF)에서 객체 스토리지 엔드포인트로의 경로를 만들기 위해 스토리지 클러스터를 업데이트해야 합니다. 부트스트래퍼에서 다음 명령어를 복사하여 붙여넣습니다. KUBECONFIG 환경 변수를 설정합니다. export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig 스토리지 클러스터를 찾습니다. storage_cluster=$(kubectl get storagecluster -n gpc-system | awk 'NR == 2{print $1}') 인스턴스 외부 CIDR을 찾습니다. instance_external_cidr=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -ojsonpath='{.spec.ipv4Spec.staticCidrBlocks}') 포워더를 사용하고 인스턴스 외부 CIDR로 라우팅하도록 스토리지 클러스터를 업데이트합니다. kubectl patch storagecluster "${storage_cluster}" -n gpc-system --type='json' -p='[{"op": "replace", "path": "/spec/additionalNetworks/0/destinationSubnets", "value": '"${instance_external_cidr}"'}, {"op": "replace", "path": "/spec/dnsConfig/serviceRef/name", "value": "gpc-coredns-forwarder-udp"}]' 변경사항이 구현되도록 컨트롤러를 다시 시작합니다. kubectl rollout restart deploy/file-storage-backend-controller -n file-system
백업 및 복원	1.12.1	조직으로의 백업 경로가 실패함 증상 백업 서브넷에서 조직 컨트롤 플레인으로의 경로가 없기 때문에 ONTAP 노드에서 조직 관리자 인그레스 게이트웨이를 컬링하는 데 실패합니다. 해결 방법: IO는 조직 수준 DNS 확인을 사용 설정하고 각 조직의 복제 논리 인터페이스 (LIF)에서 객체 스토리지 엔드포인트로의 경로를 만들기 위해 스토리지 클러스터를 업데이트해야 합니다. 부트스트래퍼에서 다음 명령어를 복사하여 붙여넣습니다. KUBECONFIG 환경 변수를 설정합니다. export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig 스토리지 클러스터를 찾습니다. storage_cluster=$(kubectl get storagecluster -n gpc-system | awk 'NR == 2{print $1}') 인스턴스 외부 CIDR을 찾습니다. instance_external_cidr=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -ojsonpath='{.spec.ipv4Spec.staticCidrBlocks}') 포워더를 사용하고 인스턴스 외부 CIDR로 라우팅하도록 스토리지 클러스터를 업데이트합니다. kubectl patch storagecluster "${storage_cluster}" -n gpc-system --type='json' -p='[{"op": "replace", "path": "/spec/additionalNetworks/0/destinationSubnets", "value": '"${instance_external_cidr}"'}, {"op": "replace", "path": "/spec/dnsConfig/serviceRef/name", "value": "gpc-coredns-forwarder-udp"}]' 변경사항이 구현되도록 컨트롤러를 다시 시작합니다. kubectl rollout restart deploy/file-storage-backend-controller -n file-system
백업 및 복원	1.12.4	백업된 영구 볼륨은 삭제할 수 없습니다 증상 영구 볼륨이 스냅 미러 관계에 있으면 삭제할 수 없습니다. 해결 방법: IO는 볼륨과의 SnapMirror 관계를 대상으로 삭제합니다. KUBECONFIG 환경 변수를 설정합니다. export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig 문제가 있는 PV 이름을 변수에 저장합니다. PV_NAME={ PV_NAME } 내부 볼륨 이름을 가져옵니다. volume_name=$(kubectl get pv ${PV_NAME?} -o jsonpath='{.spec.csi.volumeAttributes.internalName}') FILE-A0006 런북의 단계에 따라 ONTAP에 액세스합니다. 이전에 수집한 비밀번호를 사용하여 이 볼륨과의 관계를 소스로 삭제합니다. ssh ${username?}@${mgmt_ip?} snapmirror delete -source-volume ${volume_name?} -destination-path "*" # enter the password collected from the breakglass secret
백업 및 복원	1.12.0 1.12.1 1.12.2	백업 저장소가 실제로 정상임 백업 저장소에 오류 상태가 없는데 알림이 발생한 경우 저장소의 알림 측정항목이 잘못 발생한 것일 수 있습니다. 이는 1.12.0에서 알려진 문제이며 1.12.4에서 해결되었습니다. 이 문제의 원인은 백업 저장소가 상태 점검으로 객체 스토리지에 주기적으로 연결을 시도하고 연결에 실패하면 비정상 상태가 되기 때문입니다. 하지만 백업 저장소가 복구되면 상태를 나타내는 측정항목이 제대로 다시 전환되지 않아 알림이 무기한 트리거 상태로 유지됩니다. 이 문제를 해결하려면 백업 저장소를 수동으로 삭제하고 다시 만들어 상태 측정항목을 재설정하면 됩니다. BACK-R0003 런북의 단계에 따라 백업 저장소를 다시 만듭니다.
결제	1.12.4	bil-storage-system-cluster - Reconciliation error: E0121 하위 구성요소가 실패함 증상 오류 메시지: bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found bil-storage-system-cluster 하위 구성요소가 오래된 작업으로 인해 조정되지 않습니다. billing-storage-system-init-job-628 및 billing-storage-system-init-job-629는 성공적으로 완료된 후에도 유지됩니다. 해결 방법: 다음 단계를 완료합니다. 오래된 결제 작업을 백업합니다. cd /root/USERNAME kubectl --kubeconfig /root/release/gdchservices/gdchservices-system-kubeconfig get jobs billing-storage-system-init-job-628 -n billing-system -o yaml > billing-storage-system-init-job-628.yaml kubectl --kubeconfig /root/release/gdchservices/gdchservices-system-kubeconfig get jobs billing-storage-system-init-job-629 -n billing-system -o yaml > billing-storage-system-init-job-629.yaml 하위 구성요소를 일시중지합니다. export SUBCOMPONENT_NAME=bil-storage-system-cluster export SUBCOMPONENT_NAMESPACE=gdchservices-system-cluster kubectl annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true 오래된 작업을 삭제합니다. oclcm-backend-controller를 다시 시작합니다. 하위 구성요소의 일시중지를 해제합니다.
블록 스토리지	1.12.4	볼륨 마운트 오류로 인해 Grafana 포드가 Init 상태로 멈춤 증상 anthos-identity-service-obs-system 및 platform-obs-obs-system 네임스페이스의 Grafana 포드가 볼륨 마운트 오류로 인해 Init 상태로 멈춰 있습니다. kubelet 로그의 오류 메시지는 다중 연결 문제를 나타냅니다. 이 문제는 Trident의 버그로 인해 발생합니다. 이 버그로 인해 LUKS 매핑의 기본 기기를 제대로 식별하고 확인할 수 없어 다중 연결 오류가 발생합니다. 해결 방법: 삭제 타임스탬프가 있는지 PVC를 확인합니다. deletionTimestamp가 없는 경우 (포드 마이그레이션) 다음 단계를 따르세요. PVC의 VolumeAttachment를 확인하여 볼륨이 현재 연결된 위치를 파악합니다. 이 값과 일치하지 않는 클러스터의 Nodes을 차단합니다. 실패한 Pod를 삭제합니다. 그러면 원래 Node로 다시 이전됩니다. 확인 후 deletionTimestamp (볼륨 삭제)가 있는 경우 다음 단계를 따르세요. PVC의 VolumeAttachment를 확인하여 볼륨이 현재 연결된 위치를 파악합니다. Node에서 추적 파일의 콘텐츠를 출력합니다. cat /var/lib/trident/tracking/PVC_NAME.json 추적 파일 출력의 devicePath 필드에서 찾은 LUKS 기기가 실제로 닫혀 있는지 확인합니다. 이 시점에서 이 경로는 존재하지 않아야 합니다. stat DEVICE_PATH 일련번호가 현재 멀티 경로 기기에 매핑되어 있는지 확인합니다. 추적 파일의 iscsiLunSerial 필드 값을 복사합니다. 이 값을 예상되는 16진수 값으로 변환합니다. echo 'iISCSILUNSERIAL>' | xxd -l 12 -ps 이 새 값으로 멀티 경로 항목이 아직 있는지 확인합니다. multipath -ll | grep SERIAL_HEX 존재하지 않으면 추적 파일을 삭제합니다. 있는 경우 검색한 것보다 약간 긴 16진수 값이 표시되며 이를 multipathSerial라고 합니다. 다음을 실행하고 블록 기기를 찾습니다. multipath -ll MULTIPATH_SERIAL 그런 다음 다음 명령어를 실행합니다. 마지막 명령어는 각 블록 기기에 대해 고유하게 실행됩니다. systemctl restart iscsid systemctl restart multipathd multipath -f MULTIPATH_SERIAL echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete
클러스터 관리	1.12.0 1.12.1 1.12.2 1.12.4	클러스터 프로비저닝 중에 machine-init 작업이 실패함 증상 클러스터 프로비저닝 중에 두 번째 컨트롤 플레인 노드의 machine-init 작업이 다음 메시지와 함께 실패합니다. FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5". 로그를 조회합니다. kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied" 출력에 비어 있지 않은 결과가 표시됩니다. 해결 방법: /etc/kubernetes/pki/etcd/ca.crt 권한을 전환합니다. 이 작업은 시간에 매우 민감합니다. 권한 전환은 이전 machine-init 작업 실행 후 다음 machine-init 작업 실행 전에 이루어져야 합니다. machine-init가 권한을 루트로 다시 덮어쓰기 때문입니다. 두 번째 노드에서 etcd를 다시 시작하여 첫 번째 노드의 etcd를 비정상 종료 루프에서 복구합니다. 이 두 단계를 완료하면 첫 번째 노드의 kube-apiserver가 실행되기 시작하고 다음 machine-init 작업이 성공합니다.
클러스터 관리	1.12.2	필수 IPv4 PodCIDR을 사용할 수 없음 증상 cilium 에이전트에 다음 경고가 표시됩니다. level=warning msg="Waiting for k8s node information" error="required IPv4 PodCIDR not available" subsys=k8s 해결 방법: 삭제하려는 노드의 IP 주소를 확인합니다. NodePool 커스텀 리소스의 spec.nodes에서 IP 주소를 삭제합니다. 노드가 NodePool에서 완전히 삭제될 때까지 기다립니다. 노드가 삭제되지 않으면 force-remove를 실행합니다. baremetal.cluster.gke.io/force-remove=true 주석을 Machine 커스텀 리소스에 추가합니다. kubectl -n org-1-system-cluster annotate machine IP_ADDRESS baremetal.cluster.gke.io/force-remove=true NodePool 커스텀 리소스의 spec.nodes에 IP 주소를 다시 추가합니다.
로깅	1.12.0 1.12.1	Kubernetes API 서버 로그가 SIEM 대상으로 전달되지 않음 증상 외부 SIEM 시스템으로 내보내기를 설정한 후 SIEM 입력이 Fluent Bit 처리 파이프라인에 포함되지 않으며 Kubernetes API 서버 로그가 이 SIEM에 표시되지 않습니다.
네트워킹	1.12.4	업그레이드 중에 machine-init 작업이 실패함 증상 버전 1.12.2에서 1.12.4로 업그레이드할 때 노드가 삭제된 후 다시 추가되면 해당 노드의 machine-init 프로세스가 실패할 수 있습니다. 이 오류는 다시 추가된 노드에서 필수 컨트롤 플레인 서비스로의 네트워크 트래픽이 정책 ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes에 의해 거부되기 때문에 발생합니다. 이 오류는 이 예시 출력의 상태 메시지에서 강조 표시됩니다. Feb 17 18:52:52.330: 30.0.0.9:41046 (world) <> 30.0.0.7:2379 (host) policy-verdict:none INGRESS DENIED (TCP Flags: SYN) Feb 17 18:52:52.330: 30.0.0.9:41046 (world) <> 30.0.0.7:2379 (host) Policy denied DROPPED (TCP Flags: SYN) 해결 방법: 이 문제를 완화하려면 다음 단계를 따르세요. 루트 관리자 클러스터의 경우: CIDRClaim/org-external-cidr -n root (특히 .status.ipv4AllocationStatus.allocatedCidrBlocks 필드)에서 CIDR을 가져옵니다. 루트 관리자 클러스터에서 다음 명령어를 실행합니다. ROOTCIDRs=$(ka get cidrclaim/org-external-cidr -n root -o json | jq '.status.ipv4AllocationStatus.allocatedCidrBlocks') 이러한 CIDR을 ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, 특히 .spec.ingress.fromCIDR 필드에 추가합니다. 다음 명령어를 사용하여 루트 관리자 클러스터에 이 변경사항을 적용합니다. ka get ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes -o json \ | jq '.spec.ingress += [{"fromCIDR":'"${ROOTCIDRs}"'}]' \ | ka apply -f - 조직 관리자 클러스터의 경우: 조직의 CIDR을 가져옵니다 (예: CIDRClaim/org-external-cidr -n org-1 (특히 .status.ipv4AllocationStatus.allocatedCidrBlocks 필드)에서 org-1을 가져옵니다. 이 명령어는 루트 관리자 클러스터에 대해 실행되어 'org-1'의 CIDR을 가져옵니다. ORGCIDRs=$(ka get cidrclaim/org-external-cidr -n org-1 -o json | jq '.status.ipv4AllocationStatus.allocatedCidrBlocks') 이러한 CIDR을 ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, 특히 .spec.ingress.fromCIDR 필드에 추가합니다. 다음 명령어를 사용하여 해당 조직 관리자 클러스터에 이 변경사항을 적용합니다. ko get ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes -o json \ | jq '.spec.ingress += [{"fromCIDR":'"${ORGCIDRs}"'}]' \ | ko apply -f - 이 변경사항은 업그레이드를 시작하기 전에 한 번만 실행하면 됩니다.
네트워킹	1.12.0 1.12.1	VM 및 컨테이너 업데이트, 종료, 예약 관련 문제 증상 시스템 클러스터의 베어메탈 노드에서 두 개의 anetd 컨테이너를 종료할 수 없습니다. 프로세스를 강제 중지하고 kubelet 및 containerd를 다시 시작한 후 anetd 포드가 다시 생성되지만 모든 컨테이너가 podInit에 멈춰 있고 containerd에서 다음 오류 메시지를 보고합니다. `failed to create containerd task: failed to create shim task: context deadline exceeded: unknown`. 이렇게 하면 컨테이너 네트워크 인터페이스 (CNI)가 시작되지 않고 다른 포드가 예약되지 않습니다. 해결 방법: 이 노드 상태를 방지하려면 다음 완화 조치를 실행하세요. 단일 노드에서 한 번에 10개 이상의 PVC를 예약하지 마세요. 더 많은 항목을 예약하기 전에 마운트될 때까지 기다리세요. 이 문제는 VM을 만들려고 할 때 가장 두드러졌습니다. 모든 노드에서 /etc/lvm/lvm.conf 파일을 업데이트하여 devices{} 블록에 filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] 줄을 포함합니다. 노드에서 볼륨 연결 및 마운트의 시간 초과가 표시되거나 볼륨을 삭제할 수 없는 상태가 되면 노드에서 중단된 vg 프로세스의 수를 확인하여 노드가 이와 같이 특히 좋지 않은 상태인지 확인합니다. 이 상태의 노드를 수정하는 가장 안정적인 방법은 노드를 다시 시작하는 것입니다. 경험할 수 있는 또 다른 장애 모드가 있습니다. 이 실패 모드에는 마운트 시도에 다음 서명이 있습니다. mount(2) system call failed: No space left on device 이는 노드의 마운트 전파로 인한 것일 수 있습니다. cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c를 실행하여 이를 확인합니다. 이 중 하나라도 1보다 큰 값을 표시하면 이를 사용하는 포드를 삭제해야 마운트 해제가 트리거됩니다. 이 방법이 작동하지 않으면 해당 경로를 수동으로 마운트 해제하세요. 그래도 문제가 해결되지 않으면 재부팅하세요.
네트워킹	1.12.2	초기 부트스트랩 프로세스 중에 GDC가 트래픽 정책에서 스위치 ACL을 만들지 못함 특정 시나리오에서 경합 상태로 인해 Google Distributed Cloud (GDC) 에어 갭이 분산 클라우드의 초기 부트스트랩 중에 필요한 스위치 ACL Kubernetes 커스텀 리소스를 만들지 못합니다. 증상 스위치 ACL CR을 나열합니다. kubectl get switchacls -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig 이 명령어의 출력은 생성된 관리 스위치 ACL (mgmt-switch-acl)이 없음을 나타냅니다. No resources found in gpc-system namespace. 해결 방법: 트래픽 정책 CR을 나열합니다. kubectl get trafficpolicies -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig 출력에 두 개의 트래픽 정책 Kubernetes CR이 반환됩니다. NAME AGE NAME default-traffic-policy-data 4d17h default-traffic-policy-data default-traffic-policy-mgmt 4d17h default-traffic-policy-mgmt default-traffic-policy-mgmt 트래픽 정책 Kubernetes CR을 수정합니다. kubectl edit trafficpolicies default-traffic-policy-mgmt -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig 이 파일의 마지막 정책 규칙으로 이동합니다. 파일 끝에 있을 수 있습니다. 마지막 정책 규칙의 설명 필드를 식별합니다. 필드는 다음과 같이 표시될 수 있습니다. Deny All rule for Management Network 이 설명을 수정하고 설명 줄의 시작 부분에 The를 추가합니다. The Deny All rule for Management Network 파일을 저장하고 종료합니다. Kubernetes 스위치 ACL CR을 다시 나열합니다. kubectl get switchacls -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig 출력에 관리 스위치 ACL (mgmt-switch-acl)이 나열됩니다. NAME AGE NAME mgmt-switch-acl 23h mgmt-switch-acl
물리적 서버	1.12.1 1.12.2	NodePool에 생성 중에 알 수 없는 상태의 서버가 있음 증상 클러스터를 만드는 동안 Server를 프로비저닝하면 서버가 프로비저닝된 것으로 표시되지만 Provision-Ready 조건이 누락될 수 있습니다. 따라서 NodePool가 이 서버를 사용할 수 없습니다. NodePool의 오류 이벤트 메시지 예시는 다음과 같습니다. Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ReconcileError xxx Server policy failure PolicyPreflightCompleted(UnreachableError): {PolicyPreflightCompleted False 3 2023-11-07 22:10:56 +0000 UTC UnreachableError reachability err: Failed to connect to the host via ssh: ssh: connect to host xx.xx.xx.xx port 22: Connection timed out} 해결 방법: 다음 스크립트를 실행하여 ILO를 재설정합니다. SERVER_NAME= ROOT_ADMIN_KUBECONFIG= ILO_IP=$(kubectl get servers ${SERVER_NAME} -n gpc-system --template={{.spec.bmc.ip}} --kubeconfig=${ROOT_ADMIN_KUBECONFIG}) SECRET_NAME=$(kubectl get secrets -o go-template='{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}' -n gpc-system --kubeconfig=${ROOT_ADMIN_KUBECONFIG} | grep bmc | grep ${SERVER_NAME}) ILO_USER=$(kubectl get secrets ${SECRET_NAME} -n gpc-system --template={{.data.username}} --kubeconfig=${ROOT_ADMIN_KUBECONFIG} | base64 -d) ILO_PASS=$(kubectl get secrets ${SECRET_NAME} -n gpc-system --template={{.data.password}} --kubeconfig=${ROOT_ADMIN_KUBECONFIG} | base64 -d) # Perform iLO Reset curl -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"}' -X POST | jq # Perform server power cycle, start with power off target server curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X POST https://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset --data '{"ResetType":"ForceOff"}' | jq . # Verify target server powered off successfully curl -kqs -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Systems/1 | jq '.PowerState' # Power server back curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/jsonls " -H "OData-Version: 4.0" -X POST https://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset --data '{"ResetType":"On"}' | jq . 드물지만 위의 iLO 재설정 절차로 문제가 완전히 해결되지 않는 경우 서버를 다시 프로비저닝해야 합니다. 자세한 절차는 OS-P0002 및 OS-P0003 런북을 참고하세요.
물리적 서버	1.12.2	테넌트 조직에서 노드 펌웨어 업그레이드가 실패함 증상 베어메탈 노드 업그레이드가 3시간 이상 in-progress 상태로 멈춰 있습니다. 해결 방법: SERV-R0005 런북의 단계를 따릅니다.
네트워킹	1.12.1	여러 스위치에서 사전 설치 스크립트가 실패함 증상 POAP가 계속 실패하고 POAP 로그에 다음과 같은 메시지가 표시됩니다. 2024 Feb 27 20:20:25 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO26391GHS]-MAC[98:A2:C0:F8:60:6A] - Running: 'nxos.10.3.1.bin' - /script.sh 2024 Feb 27 20:20:25 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[FDO26391GHS]-MAC[98:A2:C0:F8:60:6A] - Target: 'nxos64-cs.10.3.4a.M.bin' - /script.sh nxos.10.3.1.bin를 찾을 수 없지만 스위치의 bootflash 디렉터리에서 nxos64-cs.10.3.1.F.bin와 같은 비슷한 항목을 찾을 수 있습니다. 해결 방법: 부트스트래퍼 머신에서 다음 단계를 완료합니다. 사전 설치 프로세스가 진행 중일 때 이 단계를 완료해야 합니다. /tmp/preinstall-bootstrap- 폴더가 여러 개 있는 경우 사전 설치 프로세스의 로그를 확인하여 사전 설치 프로세스에서 사용 중인 현재 폴더에 변경사항을 적용합니다. 사전 설치 명령어를 다시 시작해야 하는 경우 이 작업은 새 /tmp/preinstall-bootstrap- 폴더도 만듭니다. /tmp/preinstall-bootstrap-RANDOM_NUMBER 폴더로 이동합니다. 폴더 내에서 poap.py 파일을 찾습니다. 이 파일에서 md5 체크섬이 있는 줄을 완전히 삭제하여 head -n 4 poap.py가 다음과 같이 표시되도록 합니다. #!/bin/env python3 import glob import os import pkgutil 동일한 파일에서 version_to_image_file에 다음 행을 추가합니다. "nxos.10.2.1.bin": "nxos64.10.2.1.F.bin", "nxos.10.2.2.bin": "nxos64-cs.10.2.2.F.bin", "nxos.10.2.3.bin": "nxos64-cs.10.2.3.F.bin", "nxos.10.2.4.bin": "nxos64-cs.10.2.4.M.bin", "nxos.10.2.5.bin": "nxos64-cs.10.2.5.M.bin", "nxos.10.2.6.bin": "nxos64-cs.10.2.6.M.bin", "nxos.10.2.7.bin": "nxos64-cs.10.2.7.M.bin", "nxos.10.3.1.bin": "nxos64-cs.10.3.1.F.bin", "nxos.10.3.2.bin": "nxos64-cs.10.3.2.F.bin", 업데이트된 파일의 섹션은 다음과 같습니다. version_to_image_file = { "nxos.10.2.1.bin": "nxos64.10.2.1.F.bin", "nxos.10.2.2.bin": "nxos64-cs.10.2.2.F.bin", "nxos.10.2.3.bin": "nxos64-cs.10.2.3.F.bin", "nxos.10.2.4.bin": "nxos64-cs.10.2.4.M.bin", "nxos.10.2.5.bin": "nxos64-cs.10.2.5.M.bin", "nxos.10.2.6.bin": "nxos64-cs.10.2.6.M.bin", "nxos.10.2.7.bin": "nxos64-cs.10.2.7.M.bin", "nxos.10.3.1.bin": "nxos64-cs.10.3.1.F.bin", "nxos.10.3.2.bin": "nxos64-cs.10.3.2.F.bin", "nxos.10.3.3.bin": "nxos64-cs.10.3.3.F.bin", "nxos.10.3.4a.bin": "nxos64-cs.10.3.4a.M.bin", } md5sum poap.py를 실행하여 md5 합계를 가져오고 poap.py에 다시 추가하여 head -n 4 poap.py가 다음과 같이 표시되도록 합니다. #!/bin/env python3 #md5sum="396bed5a5f579b80da5fac6edf0b590c" import glob import os
네트워킹	1.12.1	hairpinlink 커스텀 리소스가 누락되어 1.11.x에서 1.12.1로 업그레이드할 수 없음 pnet 컨트롤러가 hairpinlink 커스텀 리소스 (CR)를 성공적으로 생성하지 못하므로 1.11.x에서 1.12.1로 업그레이드할 수 없습니다. 해결 방법: 업그레이드 후 루트 관리자 클러스터에서 clusterroles/pnet-core-backend-controllers-role 파일을 수정합니다. hairpinlinks을 검색하고 create,update,delete 권한을 리소스에 추가합니다. hairpinlinks 및 hairpinbgpsessions CR이 생성되었는지 확인합니다.
NTP 서버	1.12.1	다시 시작 후 NTP 릴레이 서버 포드가 비정상 종료됨 증상 kubectl get pods 명령어를 실행할 때 다음 메시지가 표시될 수 있습니다. ntp-system ntp-relay-server-75bbf 1/2 CrashLoopBackOff 123 (5m12s ago) 24h 로그에 활성 프로브 경고가 표시될 수 있습니다. Warning BackOff 5m55s (x82 over 28m) kubelet Back-off restarting failed container ntp-image in pod ntp-relay-server-75bbf_ntp-system(28e4e28f-4f99-4c6e-8c26-d271f0c7995c) Warning Unhealthy <invalid> (x37 over 35m) kubelet Liveness probe failed: Leap status is Not synchronised 이 문제로 인해 서버의 시간이 동기화되지 않을 수 있습니다. 해결 방법: 수정할 ntp daemonset을 엽니다. kubectl edit daemonset/ntp-relay-server -n ntp-system timeoutSeconds: 30 줄까지 livenessProbe: 섹션을 삭제합니다. ntp-image 컨테이너에 다음 섹션을 추가합니다. securityContext: capabilities: add: - SYS_TIME 그러면 다음과 같은 구성이 생성됩니다. containers: - name: ntp-image image: "DOCKER_REGISTRY/DOCKER_REPOSITORY/ntp-relay-server:DOCKER_TAG" imagePullPolicy: Always securityContext: capabilities: add: - SYS_TIME 수정할 OS NTP 정책을 엽니다. kubectl edit ospolicy/bm-ntp-policy -n gpc-system 정책 섹션에서 모든 NTP IP 주소를 삭제합니다. 그런 다음 정책은 다음과 같이 표시됩니다. policy: installPlaybook: extraVars: ntp_servers: {} name: server-ntp-config secrets: {}
NTP 서버	1.12.1	다시 시작 후 ntp-relay-job-xxxx 포드가 비정상 종료됨 증상 kubectl get pods 명령어를 실행할 때 다음 메시지가 표시될 수 있습니다. NAMESPACE NAME READY STATUS RESTARTS AGE ntp-system ntp-relay-job-1707869137-kd7p4 0/1 CrashLoopBackOff 3 (15s ago) 59s 이 문제는 업그레이드 작업이 적절하게 정리되지 않아 발생합니다. 조치가 필요하지 않으며 작업이 비정상 종료 루프 상태로 유지될 수 있습니다.
NTP 서버	1.12.2	노드 OS의 시간이 동기화되지 않음 증상 시스템 클러스터 로그에 다음 메시지가 표시될 수 있습니다. INFO: task umount:200725 blocked for more than 120 seconds. 동기화된 시간을 유지하지 않는 서버의 경우 문제가 됩니다. 구성이 올바르게 적용되지 않으며 올바르게 적용되려면 다른 네임스페이스로 변경해야 합니다. 해결 방법: 모든 클러스터에 다음 단계를 적용합니다. 기존 OS 정책을 나열합니다. kubectl get ospolicies -n ntp-system 출력에 admin-ntp-policy 또는 worker-ntp-policy이 표시됩니다. 정책 이름을 기반으로 .yaml 파일에 저장합니다. kubectl get ospolicy/admin-ntp-policy -n ntp-system -o yaml > ntp-ospolicy.yaml kubectl get ospolicy/worker-ntp-policy -n ntp-system -o yaml > ntp-ospolicy.yaml metadata.namespace을 ntp-system에서 gpc-system로 변경하고 status: line 및 그 뒤의 모든 항목을 삭제하여 파일을 수정합니다. 수정된 파일을 클러스터에 적용합니다. kubectl apply -f ntp-ospolicy.yaml 컨트롤러가 OS 정책을 적용할 때까지 몇 분 정도 기다립니다. OSPolicy가 적용되는 노드 중 하나에 SSH 연결을 설정하고 cat /etc/chrony.conf를 실행합니다. 출력에는 파일 시작 부분에 ansible로 관리되며 구성에서 nist.time.gov 또는 ntp.pool 서버가 삭제되었다는 메시지가 표시됩니다.
VM 백업 및 복원	1.12.0	VM 웹훅 설정으로 인해 사용자가 VM 백업 및 복원 절차를 시작할 수 없음 증상 VM 관리자의 부적절한 역할 기반 액세스 제어 (RBAC) 및 스키마 설정으로 인해 사용자가 VM 백업 및 복원 프로세스를 시작할 수 없습니다. VM 백업 계획 이름은 63자를 초과할 수 없습니다. 예를 들어 다음과 같은 오류 메시지가 표시될 수 있습니다. 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 해결 방법: VM 백업 계획 이름은 VirtualMachineBackupPlanTemplate 이름, 리소스 유형 (vm 또는 vm-disk) 및 해당 리소스의 이름을 연결한 것입니다. 연결된 문자열은 63자(영문 기준) 미만이어야 합니다. 이를 위해 이러한 리소스를 만들 때 이름을 짧게 유지하세요. 이러한 리소스 생성에 대한 자세한 내용은 VM 인스턴스 만들기 및 시작 및 VM 백업 계획 만들기를 참고하세요.
데이터베이스 서비스	1.12.0	데이터베이스 서비스 워크로드는 시스템 클러스터 내에서 작동합니다 증상 데이터베이스 서비스 워크로드는 분산 클라우드 시스템 클러스터의 별도 프로젝트 내에서 프로비저닝되고 구성됩니다. 프로젝트는 Distributed Cloud에서 관리 경계를 적용하는 데 사용되지만 워크로드가 실행되는 방식과 위치에는 영향을 미치지 않습니다. 따라서 이러한 워크로드는 다른 데이터베이스 인스턴스 및 다양한 컨트롤 플레인 시스템과 기본 컴퓨팅 인프라를 공유할 수 있습니다. 해결 방법: 추가 격리가 필요한 데이터베이스 워크로드의 경우 사용자가 시스템 클러스터에 노드 풀 생성을 요청할 수 있습니다. 프로젝트를 만드는 동안 참조해야 하는 이 노드 풀은 데이터베이스 워크로드가 전용 컴퓨팅 인프라에서 프로비저닝되고 실행되도록 합니다. 격리된 노드 풀의 구성은 인프라 운영자가 완료해야 합니다.
데이터베이스 서비스	1.12.2	AlloyDB Omni DBCluster가 조정 상태에서 멈춤 증상 AlloyDB Omni 버전 15.2.1의 경우 동일한 노드에 여러 AlloyDB Omni 클러스터를 만들면 마지막으로 만든 클러스터가 조정 상태에서 멈춥니다. 명령어로 postgresql 로그 가져오기 kubectl --kubeconfig $ORG_SYSTEM_KUBECONFIG exec -ti $DATABASE_POD_NAME -n $SHADOW_NS -- cat /obs/diagnostic/postgresql.log 다음과 비슷한 스택 트레이스와 함께 데이터베이스가 시작될 수 없다는 메시지가 표시됩니다. 2024-08-19 21:20:15.594 UTC: [9400/walwriter] LOG: [auxprocess.c:129] BaseInit started for AuxProcType: walwriter 2024-08-19 21:20:15.595 UTC: [9400/walwriter] LOG: [auxprocess.c:131] BaseInit finished for AuxProcType: walwriter *** SIGABRT received at time=1724102415 on cpu 25 *** PC: @ 0x7f03140a9d3c (unknown) (unknown) 2024-08-19 21:20:15.601 UTC: [9399/client backend] alloydbadmin@localhost(33906) [unknown] postgres 66c3b70f.24b7 57P03:FATAL: [postmaster.c:2601] the database system is not yet accepting connections 2024-08-19 21:20:15.601 UTC: [9399/client backend] alloydbadmin@localhost(33906) [unknown] postgres 66c3b70f.24b7 57P03:DETAIL: Consistent recovery state has not been yet reached. @ 0x5557f3b17e31 208 absl::AbslFailureSignalHandler() @ 0x7f031405afd0 4677136 (unknown) @ 0x7f0314e75b20 (unknown) (unknown) [PID: 9400] : *** SIGABRT received at time=1724102415 on cpu 25 *** [PID: 9400] : PC: @ 0x7f03140a9d3c (unknown) (unknown) [PID: 9400] : @ 0x5557f3b17f75 208 absl::AbslFailureSignalHandler() [PID: 9400] : @ 0x7f031405afd0 4677136 (unknown) [PID: 9400] : @ 0x7f0314e75b20 (unknown) (unknown) 해결 방법: 1. 데이터베이스 포드로 셸 kubectl --kubeconfig $ORG_SYSTEM_KUBECONFIG exec -ti $DATABASE_POD_NAME -n $SHADOW_NS -- bash 2. /mnt/disks/pgsql/data/postgresql.conf.d/ 아래에 구성 파일을 수동으로 만듭니다. echo "enable_lux_wal_writer = off" > /mnt/disks/pgsql/data/postgresql.conf.d/55user.conf 3. 데이터베이스를 다시 시작하여 구성 파일을 로드합니다. supervisorctl restart postgres 4. 데이터베이스가 다음과 비슷한 출력으로 성공적으로 시작됩니다. Chose default config file: /etc/supervisor/supervisord.conf postgres: ERROR (not running) postgres: started
방화벽	1.12.0	방화벽 부트스트랩 secret.yaml에 TO-BE-FILLED가 포함됨 증상 고객 배포 중에 secret.yaml 파일 관리자 사용자 이름은 admin이어야 합니다. 대신 파일에는 첫 번째 생성 후 TO-BE-FILLED이 포함됩니다. admin 사용자 이름을 사용하여 방화벽과 루프백 IP admin\admin에 첫 번째 구성을 초기화해야 합니다. 해결 방법: 다음 방화벽 사용자 인증 정보에 TO-BE-FILLED가 없는지 확인합니다. CELL_ID/CELL_ID-secret.yaml CELL_ID-ab-rack/CELL_ID-secret.yaml CELL_ID-ac-rack/CELL_ID-secret.yaml 모든 방화벽 관리자 계정의 사용자 이름이 admin인지 확인합니다.
방화벽	1.12.2	첫 번째 노드에서 bm-system-machine-init이 실패함 증상 기본 IDPS 방화벽 정책은 Direct Connect (DX) Interconnect의 조직 맞춤 IP를 지원하지 않습니다. 따라서 맞춤 IP가 루트 관리자의 Harbor에 연결할 수 없으므로 맞춤 IP를 사용한 조직 생성이 실패합니다. 해결 방법: 트래픽을 차단 해제하려면 조직 맞춤 IP의 SecurityPolicyRule를 수동으로 만들고 IDPS 방화벽에 배포하세요. 런북 FW-G0002의 단계에 따라 다음 단계를 완료합니다. 1. 조직 맞춤 IP가 루트 Harbor에 액세스할 수 있도록 루트 방화벽 가상 시스템에 인그레스 SecurityPolicyRule 만들기 apiVersion: firewall.private.gdc.goog/v1alpha2 kind: SecurityPolicyRule metadata: labels: firewall.private.gdc.goog/policy-type: idps name: root-default-ingress-ORG_NAME-custom namespace: root spec: action: allow destination: addresses: - root-external-group zones: - vsys1-gpc firewallVirtualSystemRef: name: vsys1-root priority: 150 profile: group: gdch-threat-profile-group type: group service: option: selected ports: - ports: "123" protocol: UDP - ports: "1122" protocol: TCP - ports: "5140" protocol: TCP - ports: "10443" protocol: TCP source: addresses: - org.customIPConfig.externalCIDRs # example: 30.0.0.0/22 zones: - vsys1-cp 2. 루트가 조직 APIServer에 액세스할 수 있도록 조직 방화벽 vsys에 인그레스 SecurityPolicyRule 만들기 apiVersion: firewall.private.gdc.goog/v1alpha2 kind: SecurityPolicyRule metadata: labels: firewall.private.gdc.goog/policy-type: idps name: ORG_NAME-custom-default-ingress-root namespace: ORG_NAME # example: gpu-org-1 spec: action: allow destination: addresses: - org.customIPConfig.externalCIDRs # example: 30.0.0.0/22 zones: - ORG_VSYS_ID-gpc # example: vsys3-gpc firewallVirtualSystemRef: name: ORG_VSYS_ID-ORG_NAME # example: vsys3-gpu-org-1 priority: 110 profile: group: gdch-threat-profile-group type: group service: option: selected ports: - ports: "22" protocol: TCP - ports: "5140" protocol: TCP - ports: "6443" protocol: TCP - ports: "10443" protocol: TCP source: addresses: - root-external-group zones: - ORG_VSYS_ID-cp # example: vsys3-cp 3. 방화벽 구성 교체를 트리거하여 SecurityPolicyRules를 배포합니다.
하드웨어 보안 모듈	1.12.0 1.12.1 1.12.2 1.12.4	HSM 비활성화 체험판 라이선스는 여전히 감지 가능 증상 CipherTrust Manager의 기존 알려진 문제로 인해 비활성화된 평가판 라이선스가 계속 감지될 수 있으며 잘못된 만료 경고가 트리거될 수 있습니다. 해결 방법: HSM-R0003을 참고하여 활성 일반 라이선스를 확인하고 비활성화된 평가판 라이선스를 삭제합니다.
하드웨어 보안 모듈	1.12.0	KMS 삭제 시 하드웨어 보안 모듈이 예기치 않게 작동함 증상 KMS CTMKey를 삭제할 때 하드웨어 보안 모듈 (HSM)이 예기치 않게 작동합니다. 예를 들어 조직에서 KMS 서비스가 시작되지 않을 수 있습니다. 해결 방법: 사용자는 KMS 루트 키 대신 KMS 키를 삭제하여 데이터를 암호화 삭제할 수 있으며 이는 CTMKey로 나타납니다.
하드웨어 보안 모듈	1.12.0 1.12.1 1.12.2	하드웨어 보안 모듈의 순환 가능한 보안 비밀이 알 수 없는 상태임 증상 알 수 없는 순환 가능한 보안 비밀 목록을 가져옵니다. kubectl get rotatablesecret -A | grep -i unknown 출력은 다음과 같이 표시될 수 있습니다. gpc-system yz-aa-hsm01-kmip-certificate HSM-0016 Unknown gpc-system yz-aa-hsm01-nae-certificate HSM-0016 3d19h <invalid> Unknown gpc-system yz-aa-hsm01-web-certificate HSM-0016 2d <invalid> Unknown 요구사항: 루트 관리자 클러스터에 대한 액세스 jq 도구 IAM-R0004에 따라 루트 관리자 클러스터의 KUBECONFIG를 생성합니다. IAM-R0005에 따라 루트 관리자 클러스터에서 clusterrole/hsm-admin를 획득합니다. 해결 방법: HSM의 데이터 네트워크 IP 주소 목록을 가져옵니다. kubectl --kubeconfig ${KUBECONFIG:?} get hsm -A -o json | jq -r '.items[] | "\(.spec.dataNetwork.ip)"' 출력은 다음과 같이 표시될 수 있습니다. 10.89.3.2 10.89.3.3 10.89.3.4 이전 단계의 각 HSM 데이터 네트워크 IP 주소에 대해 다음 단계를 따르세요. IP 주소를 HSM_DATA_IP 변수로 내보냅니다. export HSM_DATA_IP=HSM_DATA_IP_ADDRESS 웹 (포트 443), nae (포트 9000), kmip (포트 5696) 서버 인증서를 가져와 인증서의 유효성을 검사합니다. openssl s_client -showcerts -connect $HSM_DATA_IP:443 2>/dev/null | openssl x509 -text openssl s_client -showcerts -connect $HSM_DATA_IP:9000 2>/dev/null | openssl x509 -text openssl s_client -showcerts -connect $HSM_DATA_IP:5696 2>/dev/null | openssl x509 -text 출력은 다음과 같이 표시될 수 있습니다. Validity Not Before: Mar 12 20:36:58 2024 GMT Not After : Jun 16 20:36:58 2026 GMT Not After 날짜가 오늘로부터 30일 이내인 경우 HSM T0016 런북의 단계에 따라 서버 인증서를 갱신합니다.
모니터링	1.12.0	조직을 만들 때 노드 내보내기 도구 인증서가 준비되지 않을 수 있음 증상 조직을 만들 때 인증서가 준비되지 않습니다. $ kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig get certificate -n mon-system NAME READY SECRET AGE mon-node-exporter-backend-consumers False mon-node-exporter-backend-consumers-cert 20h mon-node-exporter-backend-providers False mon-node-exporter-backend-providers-cert 20h `SecretForwarder`로 인해 보안 비밀이 계속 존재합니다. $ kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig get secret -n mon-system | grep -E "node-exporter.+cert" mon-node-exporter-backend-consumers-cert kubernetes.io/tls 3 20h mon-node-exporter-backend-providers-cert kubernetes.io/tls 3 20h 해결 방법: 인증서를 다시 만들고 삭제하지 않도록 수명 주기 관리자를 일시중지합니다. kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n org-1-system-cluster lcm.private.gdc.goog/paused="true" kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n user-vm-1-cluster lcm.private.gdc.goog/paused="true" kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n user-vm-2-cluster lcm.private.gdc.goog/paused="true" kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig delete certificate -n mon-system mon-node-exporter-backend-consumers mon-node-exporter-backend-providers node-exporter는 사용자 클러스터에서 조정되지 않습니다.
모니터링	1.12.0 1.12.1 1.12.2	ServiceNow 웹훅을 구성하면 LCM이 다시 조정되고 mon-system 네임스페이스에서 ConfigMap 및 Secret 객체에 적용된 변경사항이 되돌려집니다. 증상 ServiceNow 웹훅을 구성하면 수명 주기 관리 (LCM)가 mon-system 네임스페이스에서 ConfigMap 객체 mon-alertmanager-servicenow-webhook-backend 및 Secret 객체 mon-alertmanager-servicenow-webhook-backend에 적용된 변경사항을 다시 조정하고 되돌립니다. 해결 방법: 변경사항이 되돌려지지 않도록 LCM 하위 구성요소를 일시중지합니다. 루트 관리자 및 조직 관리자 클러스터의 kubeconfig 파일 경로를 가져옵니다. 경로를 각각 ROOT_ADMIN_KUBECONFIG 및 ORG_ADMIN_KUBECONFIG 환경 변수에 저장합니다. 다음 클러스터 중 하나에서 LCM 하위 구성요소를 일시중지합니다. 루트 관리자 클러스터에서 LCM 하위 구성요소를 일시중지합니다. kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG annotate subcomponent mon-alertmanager-servicenow-webhook -n root lcm.private.gdc.goog/paused="true" 조직 관리자 클러스터에서 LCM 하위 구성요소를 일시중지합니다. kubectl --kubeconfig $ORG_ADMIN_KUBECONFIG annotate subcomponent mon-alertmanager-servicenow-webhook -n org-1-system-cluster lcm.private.gdc.goog/paused="true"
모니터링	1.12.0	사용자 클러스터의 측정항목이 수집되지 않습니다. 증상 사용자 클러스터의 일부 측정항목이 수집되지 않습니다. 이 문제는 사용자 VM 클러스터에 영향을 미치지만 시스템 클러스터에는 영향을 미치지 않습니다. Prometheus 서버에서 다음 로그를 확인할 수 있습니다. prometheus-server ts=2024-02-21T16:07:42.300Z caller=dedupe.go:112 component=remote level=warn remote_name=cortex-remote-write url=http://cortex-tenant.mon-system.svc:9009/push msg="Failed to send batch, retrying" err="server returned HTTP status 500 Internal Server Error: 2 errors occurred:" Cortex 테넌트에서 다음 로그를 확인할 수 있습니다. cortex-tenant time="2024-02-23T18:03:44Z" level=error msg="proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host" 해결 방법: 이 문제를 해결하려면 다음 단계를 따르세요. 클러스터의 kubeconfig 파일 경로를 가져옵니다. KUBECONFIG 환경 변수에 경로를 저장합니다. 사용자 VM 클러스터에 스텁 서비스를 배포합니다. kubectl --kubeconfig $KUBECONFIG apply -f - &lt&ltEOF apiVersion: v1 kind: Service metadata: labels: app: cortex name: cortex spec: ports: - protocol: TCP targetPort: 9009 port: 9009 name: cortex type: ClusterIP sessionAffinity: ClientIP EOF Cortex 테넌트 배포를 다시 시작합니다. kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n mon-system cortex-tenant
모니터링	1.12.0	기본 Prometheus가 클러스터 경계를 넘어 Cortex 테넌트로 측정항목을 전송함 증상 인프라 운영자의 Grafana 인스턴스를 위한 측정항목이 플랫폼 관리자의 Grafana 인스턴스에 있을 수 있으며 그 반대의 경우도 마찬가지입니다. 이 문제는 기본 테넌트가 서로 다른 클러스터 경계에서 ASM 부하 분산 요청이 발생하기 때문에 발생합니다. 해결 방법: 이 해결 방법에는 private-cloud 소스에 대한 액세스 권한과 구성요소 업데이트를 출시할 수 있는 기능이 필요합니다. 메시 구성을 변경하여 cortex-tenant 서비스가 로컬 클러스터의 트래픽만 수신하도록 제한하고 ASM 구성요소를 출시해야 합니다. manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml 파일을 엽니다. meshConfig 필드에 serviceSettings 필드를 도입합니다. meshConfig 필드는 원래 다음 예와 같습니다. ... profile: minimal revision: 1-19 meshConfig: localityLbSetting: enabled: false ... 따라서 meshConfig 필드를 다음 예시와 같이 변경해야 합니다. profile: minimal revision: 1-19 meshConfig: serviceSettings: - settings: clusterLocal: true hosts: - 'cortex-tenant.mon-system.svc.cluster.local' localityLbSetting: enabled: false ASM 구성요소를 클러스터에 출시합니다.
업그레이드	1.12.0	NodeOSInPlaceUpgradeCompleted 노드 업그레이드 실패 증상 1.11.0에서 1.11.3으로 업그레이드하는 동안 NodeOSInPlaceUpgradeCompleted의 노드 업그레이드가 실패합니다. ka logs -n gpc-system os-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn | grep GDCH-OS-ANSIBLE-CHECK -A 50 [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 } 해결 방법: 업그레이드 중인 베어메탈 머신에 로그인합니다. fstab에 /boot/efi이 있고 디렉터리가 마운트되어 있는지 확인합니다. # cat /etc/fstab LABEL=cloudimg-rootfs / ext4 defaults 0 1 LABEL=UEFI /boot/efi vfat umask=0077 0 1 lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 3.5T 0 disk ├─sda1 8:1 0 3.5T 0 part / ├─sda2 8:2 0 64.3M 0 part ├─sda14 8:14 0 4M 0 part └─sda15 8:15 0 106M 0 part nodeupgradetask 일시중지 mount -a을 실행하고 디렉터리가 마운트되었는지 확인합니다. # mount -a root@mb-aa-bm04:~# ls /boot/efi/ EFI 여기에서 확인을 진행하세요. 다음 명령어를 실행합니다. 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 }')" ]; then echo "Files are identical."; else echo "Files are different."; fi if [ "$(sha256sum /boot/efi/EFI/ubuntu/grubx64.efi | awk '{ print $1 }')" == "$(sha256sum /boot/efi/EFI/BOOT/grubx64.efi| awk '{ print $1 }')" ]; then echo "Files are identical."; else echo "Files are different."; fi if [ "$(sha256sum /boot/efi/EFI/ubuntu/grub.cfg | awk '{ print $1 }')" == "$(sha256sum /boot/efi/EFI/ubuntu/grub.cfg | awk '{ print $1 }')" ]; then echo "Files are identical."; else echo "Files are different."; fi 파일이 모두 동일하지 않으면 머신에서 이 명령어를 실행하고 검사를 반복합니다. /usr/local/update-efi-files.sh nodeupgradetask 일시중지 해제
업그레이드	1.12.0	스위치 업그레이드에서 install add bootflash://.. 명령어를 실행하지 못함 증상 스위치 업그레이드에서 bootflash를 추가하지 못함: Conditions: Last Transition Time: 2024-01-10T20:06:30Z Message: exception: add and activate package nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm: nx-api RPC request failed with status code 400 and body "{\n\t\"jsonrpc\":\t\"2.0\",\n\t\"error\":\t{\n\t\t\"code\":\t-32602,\n\t\t\"message\":\t\"Invalid params\",\n\t\ t\"data\":\t{\n\t\t\t\"msg\":\t\"Adding the patch (/nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm)\\n\\n[### ] 10%\\n[#│ # [] 10%\\n[##### ] 20%\\n[####### ] 30%\\n[######### ] 40%\\n[######### ] 4 0%\\n[####################] 100%\\n[####################] 100%\\nInstall operation 21 failed because this patch already exists. at Wed Jan 10 2 1:00:06 2024\\n\\n\"\n\t\t}\n\t},\n\t\"id\":\t1\n}" for requests "install add bootflash:///nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm activate forced" 해결 방법: 실패한 스위치에 로그인하고 패키지의 스위치에서 install activate 명령어를 실행합니다. install activate nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm
업그레이드	1.12.1, 1.12.2, 1.12.4	1.11.x에서 1.12.1로 업그레이드할 때 노드 업그레이드가 MaintenanceModeHealthCheckReady 드레인되지 않음 오류로 인해 중단됨 증상 클러스터 업그레이드가 1시간 이상 중단되었습니다. 베어메탈 머신 유지보수 모드 상태와 사양이 일치하지 않습니다. 예를 들면 명령어는 다음과 같습니다. kubectl get baremetalmachines -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenance 표시됩니다. root 10.252.135.4 false true 베어메탈 머신 실행 전 검사 작업에 다음 오류 메시지가 표시됩니다. The error was: 'dict object' has no attribute 'stdout'\n\nThe error appears to be in '/playbook/roles/machine_check_common/tasks/main.yaml': line 215, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Check if bypass the time check in node agent mode\n ^ here\n"} 해결 방법: 다음 명령어를 사용하세요. export KUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG} kubectl get cluster -A kubectl annotate cluster ${CLUSTER_NAME} -n=${CLUSTER_NAMESPACE} "baremetal.cluster.gke.io/bypass-check=ntp"
노드 OS	1.11.3	os-policy 포드의 수동 해결 방법 후 VM 노드가 재부팅 시 멈춤 증상 os-policy 포드의 수동 해결 방법 후 VM 재부팅 작업이 실패합니다. 다음 메시지가 표시됩니다. ko logs os-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp -n gpc-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: reachability err: Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out 해결 방법: VM을 중지했다가 다시 시작하면 문제가 해결됩니다. VM 시작 및 중지의 안내를 따릅니다.
상위 네트워킹	1.12.0	사용자 VM 클러스터가 FailedCreatePodSandBox 경고와 함께 ContainerCreating 상태에서 멈춤 증상 사용자 VM 클러스터가 멈추고 ContainerCreating 상태인 포드를 설명하면 다음 경고가 표시됩니다. # kubectl --kubeconfig path/to/usercluster_kubeconfig describe pods/bm-system-machine-preflight-check-172.204c807f67d2cab60d5d8q58q -n user-vm-1-cluster Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedCreatePodSandBox 108s (x62 over 79m) kubelet (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "ec4d2021ae9d76adf49a6d3c88d678b3b5d9 50990daa6ffee3fcfeed8291dfa8": plugin type="cilium-cni" name="cilium" failed (add): Unable to create endpoint: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests 해결 방법: NET-P0001 런북의 단계에 따라 시스템 클러스터에서 anetd를 다시 시작합니다.
시스템 아티팩트 레지스트리	1.12.1	ABM 업그레이드 후 Harbor 비정상 종료 루프 증상 루트 조직을 1.11.1에서 1.12.1로 업그레이드할 때 부가기능 단계에서 Helm 풀 오류와 함께 업그레이드가 실패할 수 있습니다. harbor-system harbor-harbor-harbor-core-657d86bcf8-zl8d2 1/1 Running 0 14h harbor-system harbor-harbor-harbor-core-7d66b4c7c-7g6t4 0/1 CrashLoopBackOff 155 (76s ago) 12h 해결 방법: 지원 요청을 제출합니다. 자세한 내용은 지원 요청을 참고하세요.
업그레이드	1.12.0	시스템 클러스터의 일부 포드가 TaintToleration 상태로 멈출 수 있음 증상 업그레이드 중에 OPA 게이트키퍼 하위 구성요소가 시스템 클러스터에 설치되지 않습니다. 하지만 제약 조건이 설치되고 이를 적용하는 웹훅이 설치됩니다. 시스템 클러스터의 여러 포드가 TaintToleration 상태로 멈춰 있을 수 있습니다. mon-system mon-cortex-pre-upgrade-job-mn29x 0/1 TaintToleration 0 96m <none> zb-aa-bm07 <none> <none> mon-system mon-kube-state-metrics-backend-d49b868dc-fmp62 0/2 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none> mon-system primary-prometheus-shard1-replica0-0 0/3 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none> netapp-trident netapp-trident-controller-7ffb4c5f89-rvwjj 0/5 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none> obs-system alertmanager-0 0/2 TaintToleration 0 98m <none> zb-aa-bm07 <none> <none> obs-system audit-logs-loki-io-0 0/3 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none> obs-system log-audit-backend-failure-detector-6lgsq 0/1 TaintToleration 0 105m <none> zb-aa-bm07 <none> <none> obs-system meta-alertmanager-0 0/1 TaintToleration 0 102m <none> zb-aa-bm07 <none> <none> obs-system meta-alertmanager-servicenow-webhook-5679f48895-ggkg6 0/2 TaintToleration 0 102m <none> zb-aa-bm07 <none> <none> platform-obs-obs-system grafana-proxy-server-7b6b79f787-2x92t 0/2 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none> vm-system gdch-rocky-yum-repo-distributor-zfwp6 0/1 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none> vm-system gdch-rocky-yum-repo-server-568768c97b-c9hm2 0/2 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
Istio	1.12.1	Back-off pulling image "auto" 이벤트가 있는 ImagePullBackOff 상태의 포드 증상 컨테이너 이름이 istio-proxy인 포드가 준비되지 않았으며 Back-off pulling image "auto" 이벤트와 함께 ImagePullBackOff 상태가 있습니다. 해결 방법: istio-revision-tag-default 변형 웹훅이 클러스터에 있는지 확인합니다. 그렇지 않으면 시스템이 자동 복구될 때까지 약 10분 정도 기다립니다. 그렇지 않은 경우 문제를 에스컬레이션합니다. 변형 웹훅이 있는 경우 문제가 있는 포드를 삭제하고 다시 시작되는지 확인합니다. .spec.containers[].image는 auto가 아니어야 하며, 다음과 같은 실제 이미지처럼 보여야 합니다(gcr.io/gke-release/asm/proxyv2:<image version>).
로깅	1.12.1	로그 구성요소에서 배포한 ValidatingWebhookConfigurations, MutatingWebhookConfigurations, MonitoringRules이 업그레이드되지 않을 수 있음 증상 1.11.1에서 1.12.1로 업그레이드할 때 로그 구성요소에서 배포한 ValidatingWebhookConfigurations, MutatingWebhookConfigurations, MonitoringRules가 업그레이드되지 않을 수 있습니다. 해결 방법: kubectl이 있고 IAM-R0004 런북에 액세스하여 루트 관리자 클러스터의 KUBECONFIG를 가져올 수 있는지 확인합니다. 루트 관리자 클러스터에서 ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook를 삭제합니다. kubectl delete validatingwebhookconfiguration root-admin-private-logging-validation-webhook 루트 관리자 클러스터에서 MutatingWebhookConfiguration root-admin-private-logging-defaulter-webhook를 삭제합니다. kubectl delete mutatingwebhookconfiguration root-admin-private-logging-defaulter-webhook 루트 관리자 클러스터에서 ValidatingWebhookConfiguration root-admin-logging-webhook를 삭제합니다. kubectl delete validatingwebhookconfiguration root-admin-logging-webhook 루트 관리자 클러스터의 infra-obs 네임스페이스에서 MonitoringRule operational-logs-alerts을 삭제합니다. kubectl delete monitoringrule operational-logs-alerts -n infra-obs 루트 관리자 클러스터의 infra-obs namespace에서 MonitoringRules audit-logs-alerts, audit-logs-sli-syslog-prober, audit-logs-sli-filelog-prober, audit-logs-sli-fluentbit-to-loki, audit-logs-sli-fluentbit-to-splunk, audit-logs-sli-fluentbit-backlog, audit-logs-sli-loki-ingester-failed-rate, audit-logs-sli-loki-io-up, audit-logs-sli-loki-pa-up을 삭제합니다. kubectl delete monitoringrule audit-logs-alerts audit-logs-sli-syslog-prober audit-logs-sli-filelog-prober audit-logs-sli-fluentbit-to-loki audit-logs-sli-fluentbit-to-splunk audit-logs-sli-fluentbit-backlog audit-logs-sli-loki-ingester-failed-rate audit-logs-sli-loki-io-up audit-logs-sli-loki-pa-up -n infra-obs 루트 관리자 클러스터에서 하위 구성요소 log-admin가 준비되었는지 확인합니다. export RECONCILING="`kubectl get subcomponent log-audit -n root -o json | jq '.status.conditions | .[] | select(.type == "Reconciling") | .status'`" ; if [[ $RECONCILING =~ "False" ]]; then echo "log-audit is ready"; else echo "log-audit is not ready"; fi 성공하면 명령어가 log-audit is ready를 출력합니다. 그렇지 않으면 출력은 log-audit is not ready입니다. 루트 관리자 클러스터에서 하위 구성요소 log-admin가 준비되었는지 확인합니다. export RECONCILING="`kubectl get subcomponent log-operational -n root -o json | jq '.status.conditions | .[] | select(.type == "Reconciling") | .status'`" ; if [[ $RECONCILING =~ "False" ]]; then echo "log-operational is ready"; else echo "log-operational is not ready"; fi 성공하면 명령어가 log-operational is ready를 출력합니다. 그렇지 않으면 출력은 log-operational is not ready입니다.
로깅	1.12.1	감사 로그 및 운영 로그가 수집되지 않음 log-infra-backend-preinstall 작업의 문제로 인해 감사 로그 및 운영 로그 Loki가 설치되지 않고 로그가 수집되지 않습니다. 증상 시스템 클러스터에 CrashLoopBackoff가 표시될 수 있습니다. obs-system anthos-log-forwarder-5ghbm 2/3 CrashLoopBackOff 135 (3m52s ago) 15h
로깅	1.12.1	cortex-ingester 포드에 OOMKilled 상태가 표시됨 증상 mon-system 네임스페이스의 포드에 OOMKilled 상태가 표시될 수 있습니다. NAMESPACE NAME READY STATUS RESTARTS AGE mon-system cortex-ingester-0 1/2 OOMKilled 6 (3h5m ago) 11h 해결 방법: 각 인제스터의 메모리를 늘리거나 인제스터 수를 늘리거나 둘 다 늘립니다. 다음 예와 같이 조직 관리자 클러스터에 SubcomponentOverride를 배포하면 됩니다. 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 ingester replicas: 4 # 4 is the default, increase to create more ingester instances. subComponentRef: mon-cortex
업그레이드	1.12.1	1.11.x에서 1.12.1로 업그레이드할 때 registy_mirror의 상태 점검 실패로 인해 클러스터 노드가 유지보수 모드를 종료하지 못할 수 있음 증상 1.11.x에서 1.12.1로 업그레이드할 때 다음 오류 메시지와 함께 노드 업그레이드가 실패합니다. { "lastTransitionTime": "2024-02-13T22:53:36Z", "message": "following checks failed, ['check_registry_mirror_reachability_pass']", "observedGeneration": 3, "reason": "JobStatus", "status": "False", <---- "type": "MaintenanceModeHealthCheckReady" }, 해결 방법: 다음 명령어를 사용하세요. kubectl --kubeconfig=${ROOT_OR_ORG_ADMIN_KUBECONFIG} annotate cluster ${CLUSTER_NAME} -n=${CLUSTER_NAMESPACE} "baremetal.cluster.gke.io/maintenance-mode-ignore-healthcheck=true"
업그레이드	1.12.1, 1.12.2, 1.12.4	check_registry_mirror_reachability_pass 검사 실패로 인해 OrganizationUpgrade가 anthosBareMetal, addOn 또는 node 단계에서 멈춥니다. 증상 1. OrganizationUpgrade가 anthosBareMetal, addOn 또는 node 단계에서 멈춰 있고 Succeeded 조건에 Unknown 상태가 표시됩니다. kubectl --kubeconfig=${ROOT_ADMIN_KUBECONFIG} get organizationupgrade -n gpc-system ${ORG_NAME} -o yaml 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: 1 reason: ABMUpgradeTimeout status: Unknown type: Succeeded startTime: "2024-09-12T12:10:55Z" node:{} 2. 베어메탈 머신 상태에 check_registry_mirror_reachability_pass 확인 실패가 표시됩니다. kubectl --kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG} get baremetalmachines -A -o json | 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")' { "lastTransitionTime": "2024-02-13T19:17:27Z", "message": "following checks failed, ['check_registry_mirror_reachability_pass']", "observedGeneration": 3, "reason": "JobStatus", "status": "False", "type": "MaintenaceModeHealthCheckReady" }, 해결 방법: 다음 명령어를 사용하세요. export KUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG} kubectl get cluster -A kubectl annotate cluster ${CLUSTER_NAME} -n=${CLUSTER_NAMESPACE} "baremetal.cluster.gke.io/maintenance-mode-ignore-healthcheck=true"
업그레이드	1.12.1, 1.12.2, 1.12.4	상태 확인 오류로 인해 netutil.을(를) 찾을 수 없으며 OrganizationUpgrade가 anthosBareMetal, addOn 또는 node 단계에서 멈춤 증상 1. OrganizationUpgrade가 anthosBareMetal, addOn 또는 node 단계에서 멈춰 있고 Succeeded 조건에 Unknown 상태가 표시됩니다. kubectl --kubeconfig=${ROOT_ADMIN_KUBECONFIG} get organizationupgrade -n gpc-system ${ORG_NAME} -o yaml 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: 1 reason: ABMUpgradeTimeout status: Unknown type: Succeeded startTime: "2024-09-12T12:10:55Z" node:{} 2. 상태 확인에 netutil가 누락되었다는 오류가 표시됩니다. kubectl --kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG} get healthchecks -n kube-system -o json | jq '.items[].status | select(.lastHealthcheck.lastStatus == "Error")' { "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" } 해결 방법: 실패한 상태 점검에 해당하는 Kubernetes 작업 삭제 kubectl --kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG} get job -A -l Command=machine-health-check --field-selector status.successful=0 NAMESPACE NAME COMPLETIONS DURATION AGE root bm-system-10.200.0.2-machine-28771464 0/1 67m 67m root bm-system-10.200.0.2-machine-28771524 0/1 7m33s 7m33s kubectl --kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG} delete job -A -l Command=machine-health-check --field-selector status.successful=0 job.batch "bm-system-10.200.0.2-machine-28771464" deleted job.batch "bm-system-10.200.0.2-machine-28771524" deleted
VM 관리자	1.12.1	1.11.x에서 1.12.x로 업그레이드할 때 포드가 너무 많아 VM이 준비되지 않을 수 있음 증상 1.11.x에서 1.12.x로 업그레이드할 때 포드가 너무 많아 VM이 준비되지 않아 베어메탈 노드 드레이닝이 차단될 수 있습니다. 해결 방법: VM을 다시 시작합니다.
물리적 서버	1.12.1	NodeUpgrade에 동일한 하드웨어 모델의 여러 버전이 포함되어 있어 펌웨어 업그레이드 확인이 차단됨 증상 1.11.x에서 1.12.1로 업그레이드할 때 NodeUpgrade에 동일한 하드웨어 모델의 여러 버전이 포함되어 펌웨어 업그레이드 확인이 차단됩니다. 해결 방법: 다음 단계에 따라 NodeUpgrade CR spec를 수정하세요. HPE Gen10 서버 (GDC-4D)를 업그레이드하는 경우 ilo6 모델 펌웨어를 삭제합니다. 그렇지 않으면 ilo5 모델 펌웨어를 삭제합니다. 각 설명에 대해 최신 redfishVersion가 있는 항목을 유지하는 섹션 예를 들어 다음 두 항목이 모두 있는 경우 2.98 Oct 10 2023이 있는 항목만 유지합니다. - description: SystemBMC model: ilo5 redfishVersion: 2.98 Oct 10 2023 - description: SystemBMC model: ilo5 redfishVersion: 2.95 Jul 19 2023
물리적 서버	1.12.1	서버가 프로비저닝 상태에서 멈춤 증상 서버가 켜지기를 기다리는 동안 Ironic이 시간 초과되었습니다. 상태가 cleaning 상태에서 clean failed, available로 변경됩니다. 2024-02-23 18:53:00.659 1 DEBUG ironic.api.method [req-3a22ed15-d5cd-4d77-bb0b-0e7a3042e793 - - - - -] Client-side error: Node facc133f-898c-46d4-974b-92e3560892d5 is locked by host 10.128.120.2, please retry after the current operation is completed. format_exception /usr/lib/python3.6/site-packages/ironic/api/method.py:124 스위치가 켜져 있는지 확인합니다. curl -kqs -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Systems/1 | jq '.PowerState' 스위치가 켜져 있으면 출력에 "On"가 반환됩니다. 해결 방법: 문제가 있는 서버에서 image 블록을 삭제하고 서버가 사용 가능한 상태로 돌아올 때까지 기다립니다. 사용 가능해지면 image 블록을 다시 추가합니다.
물리적 서버	1.12.2	서버 부트스트랩 실패 증상 다음과 같은 디버그 메시지가 표시될 수 있습니다. [DEBUG] GET https://172.22.240.103/redfish/v1/ 2024/03/22 21:46:46 [DEBUG] GET https://172.22.240.111/redfish/v1/Systems/1/ panic: runtime error: invalid memory address or nil pointer dereference 이 문제는 iLO 오류가 무시되고 HTTP 응답이 즉시 반환되지 않고 읽혀서 nil 포인터 역참조가 발생하는 경우에 발생합니다.
시스템 아티팩트 레지스트리	1.12.1	1.11.x에서 1.12.1로 업그레이드할 때 Harbor 클러스터 상태가 unhealthy일 수 있음 증상 1.11.1에서 1.12.1로 업그레이드하면 Harbor 클러스터 상태가 다음 오류와 함께 unhealthy가 될 수 있습니다. root@abc-bootstrapper:/home/ubuntu# ka get harborclusters -A NAMESPACE NAME PUBLIC URL STATUS harbor-system harbor https://10.252.119.11:10443 unhealthy 진단 단계: harborclusters의 상태를 확인합니다. root@abc-bootstrapper:/home/ubuntu# ka get harborclusters -A NAMESPACE NAME PUBLIC URL STATUS harbor-system harbor https://10.252.119.11:10443 unhealthy 비정상인 경우 Harbor 구성요소의 상태를 확인합니다. root@abc-bootstrapper:~# ka get pods -n harbor-system NAME READY STATUS RESTARTS AGE harbor-harbor-harbor-core-68d9764d8c-rgg4h 0/1 Running 0 3d2h harbor-harbor-harbor-exporter-54d559fdb8-nzjk7 1/1 Running 0 3d2h harbor-harbor-harbor-jobservice-6f5db4779-sqmlc 1/1 Running 0 3d2h harbor-harbor-harbor-portal-8458c847dc-z2l6n 1/1 Running 0 3d4h harbor-harbor-harbor-registry-7577f5d9d6-qp45c 3/3 Running 0 3d4h harbor-operator-harbor-operator-755b5cfc96-x2bxh 1/1 Running 0 3d4h harbor-operator-redisoperator-bf96ffc59-5d457 1/1 Running 0 3d4h harbor-operator-redisoperator-bf96ffc59-tbd8j 1/1 Running 0 3h38m harbor-operator-redisoperator-bf96ffc59-vlqfl 1/1 Running 0 3h38m pg-harbor-db-0 0/3 Pending 0 3h37m pg-harbor-db-monitor-776b946c74-c7pt9 0/1 Pending 0 3h38m rfr-harbor-redis-0 1/1 Running 0 3d4h rfr-harbor-redis-1 1/1 Running 0 3d4h rfr-harbor-redis-2 1/1 Running 0 3h37m rfs-harbor-redis-64d9d8df4f-fds79 1/1 Running 0 3d4h rfs-harbor-redis-64d9d8df4f-p9l9h 1/1 Running 0 3d3h rfs-harbor-redis-64d9d8df4f-x5x8c 1/1 Running 0 3h38m harbor-core 및 pg-harbor-db가 준비되지 않은 경우 harbor-db의 상태를 확인합니다. root@abc-bootstrapper:~# ka get dbclusters.postgresql.dbadmin.gdc.goog harbor-db -n harbor-system NAME PRIMARYENDPOINT PRIMARYPHASE DBCLUSTERPHASE harbor-db 172.20.0.146 InProgress DBClusterReconciling harbor-db가 InProgress 모드인 경우 root-admin-control-plane 노드가 UNDERMAINTENANCE 모드인지 확인합니다. root@abc-bootstrapper:~# ka get nodepool -A NAMESPACE NAME READY RECONCILING STALLED UNDERMAINTENANCE UNKNOWN org-1 admin-control-plane-node-pool 0 0 0 0 0 root root-admin-control-plane 3 0 0 1 0 업그레이드 중에 노드가 유지보수 모드에 있어야 합니다. 노드 하나가 유지보수 중이면 harbor-db를 예약할 리소스가 부족할 수 있습니다. 해결 방법: 이 문제를 해결하려면 다음 단계를 따르세요. KUBECONFIG 설정 : export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig dbs 컨트롤러를 축소합니다. kubectl scale --replicas=0 deployment -n dbs-fleet-system fleet-controller-manager kubectl scale --replicas=0 deployment -n dbs-postgres-system pg-controller-manager 포드 템플릿에서 우선순위 클래스 이름을 system-cluster-critical 또는 system-node-critical로 설정합니다. kubectl patch statefulset pg-harbor-db -n harbor-system --type='json' \ -p='[{"op": "add", "path": "/spec/template/spec/priorityClassName", "value": "system-cluster-critical"}]' pg-harbor-db 포드를 다시 시작합니다. kubectl delete pods -n harbor-system pg-harbor-db-0 harborcluster가 정상 상태인지 확인한 후 dbs 컨트롤러를 다시 확장합니다. kubectl scale --replicas=1 deployment -n dbs-fleet-system fleet-controller-manager kubectl scale --replicas=1 deployment -n dbs-postgres-system pg-controller-manager
시스템 아티팩트 레지스트리	1.12.2	작업 서비스 포드가 준비되지 않음 증상 작업 서비스 포드가 준비되는 데 문제가 있습니다. Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Unhealthy 35m (x8153 over 3d16h) kubelet Readiness probe failed: Get "https://172.16.1.142:8443/api/v1/stats": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) Warning Unhealthy 10m (x60 over 13h) kubelet Readiness probe failed: Get "https://172.16.1.142:8443/api/v1/stats": context deadline exceeded Normal Pulled 5m47s (x1733 over 3d16h) kubelet Container image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7" already present on machine Warning BackOff 43s (x21352 over 3d16h) kubelet Back-off restarting failed container jobservice in pod harbor-harbor-harbor-jobservice-6f59fbf974-q9h9g_harbor-system(51ab9697-98b9-4315-9ab9-f67b19a28d0a) 해결 방법: 작업 서비스 포드를 다시 시작합니다. kubectl delete pod POD_NAME -n NAMESPACE 출력 형식은 다음과 같습니다. Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m20s default-scheduler Successfully assigned harbor-system/harbor-harbor-harbor-jobservice-6f59fbf974-p872s to zx-ab-bm02 Normal Pulling 2m15s kubelet Pulling image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7" Normal Pulled 2m12s kubelet Successfully pulled image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7" in 3.25s (3.25s including waiting) Normal Created 2m12s kubelet Created container jobservice Normal Started 2m12s kubelet Started container jobservice 부트스트래퍼에서 조직 상태를 가져옵니다. kubectl get org -A 출력은 다음과 같이 표시될 수 있습니다. NAMESPACE NAME CURRENT VERSION DESIRED VERSION READY gpc-system org-1 1.12.1-gdch.402 1.12.1-gdch.402 True gpc-system org-2 1.12.1-gdch.402 1.12.1-gdch.402 True gpc-system root 1.12.1-gdch.402 1.12.1-gdch.402 True
모니터링	1.12.1	1.11.x에서 1.12.1로 업그레이드할 때 Cortex 버킷 삭제가 실패할 수 있음 증상 1.11.1에서 1.12.1로 업그레이드할 때 Cortex 버킷 삭제가 다음 오류와 함께 실패할 수 있습니다. upgrade_post_root_org_validation.go:74: unable to create cortex client to check metrics creating Cortex client failed: can't make a metrics API because of an error getting the Cortex pod: unable to find any matching cortex pods using list options / label selector: {TypeMeta:{Kind: APIVersion:} LabelSelector:app=cortex FieldSelector: Watch:false AllowWatchBookmarks:false ResourceVersion: ResourceVersionMatch: TimeoutSeconds: Limit:0 Continue: SendInitialEvents:} upgrade_post_root_org_validation.go:117: Bucket(s) not ready: 3 errors occurred: * Bucket "obs-system/cortex-metrics-alertmanager" not ready * Bucket "obs-system/cortex-metrics-blocks" not ready * Bucket "obs-system/cortex-metrics-ruler" not ready 해결 방법: 다음 단계를 따라 bucket을 강제로 삭제하세요. MON-R0017 작업의 단계를 완료하여 StorageGRID UI에 액세스합니다. UI에서 bucket로 이동합니다. 버킷의 객체 삭제 버튼을 클릭하여 데이터를 삭제합니다.
모니터링	1.12.0 1.12.1 1.12.2	구성에서 측정항목 스토리지 클래스가 잘못 정의됨 증상 Prometheus StatefulSet 객체가 standard-rwo 대신 standard 스토리지 클래스로 잘못 구성되어 있습니다. 이 문제로 인해 모니터링 구성요소에서 Anthos Prometheus StatefulSet 객체의 시작이 실패합니다. 이 문제는 ObservabilityPipeline 리컨실러가 첫 번째 설치에서만 이 값을 설정하고 ObsProjectInfra 리컨실러가 클러스터 커스텀 리소스를 감시하기 때문에 발생합니다. 해결 방법: 조직 관리자 클러스터에서 fleet-admin-controller 배포를 다시 시작하여 문제를 해결합니다.
모니터링	1.12.2	mon-common 하위 구성요소가 Istio 원격 분석을 배포하지 않음 증상 mon-common 하위 구성요소는 Cortex의 모든 요청에 대한 감사 로깅을 방지하기 위해 조직 관리자 클러스터에 Istio 원격 분석 객체를 배포해야 합니다. 하지만 매니페스트 파일은 빌드 파일에 포함되지 않습니다. 해결 방법: 다음 단계를 따라 조직 관리자 클러스터에 Istio 원격 분석 객체를 배포합니다. 조직 관리자 클러스터의 mon-system 네임스페이스에 Istio 원격 분석 커스텀 리소스 (CR)를 정의하는 YAML 파일을 만듭니다. # 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 mon-system 네임스페이스의 조직 관리자 클러스터에 매니페스트 파일을 적용합니다. kubectl apply -f disable-audit-logging.yaml
모니터링	1.12.0 1.12.1 1.12.2	mon-prober-backend-prometheus-config ConfigMap이 재설정됨 증상 MON-A0001 알림이 트리거됩니다. mon-prober-backend-prometheus-config ConfigMap이 프로브 작업을 포함하지 않도록 재설정됩니다. 예를 들면 다음과 같습니다. apiVersion: v1 data: prometheus.yaml: | remote_write: - url: http://cortex-tenant.mon-system.svc:9009/push name: cortex-tenant kind: ConfigMap metadata: creationTimestamp: "2024-06-26T14:55:07Z" name: mon-prober-backend-prometheus-config namespace: mon-system resourceVersion: "6606787" uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899 해결 방법: 이 문제를 해결하려면 다음 단계를 따르세요. 다음 환경 변수를 설정합니다. KUBECONFIG: 클러스터의 kubeconfig 파일 경로입니다. TARGET_CLUSTER: 문제를 해결하는 클러스터의 이름입니다. 모든 클러스터에서 mon-prober 하위 구성요소를 일시중지합니다. kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused=true 예를 들면 다음과 같습니다. kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused=true 각 관리자 클러스터에서 MON 관리자 컨트롤러를 다시 시작합니다. kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller 프로브가 등록될 때마다 프로버 ConfigMap이 채워집니다. 이 알림은 계속 발생하므로 런북 MON-R2009에 따라 MON-A0001 알림 Blackbox monitoring metrics pipeline down을 음소거합니다.
노드 플랫폼	1.12.1	1.11.x에서 1.12.x로 업그레이드할 때 스위치 이미지 다운로드 포드가 ErrImagePull 상태에서 멈출 수 있습니다. 증상 1.11.x에서 1.12.x로 업그레이드할 때 스위치 이미지 다운로드 포드가 다음 경고와 함께 ErrImagePull 상태로 멈출 수 있습니다. Warning Failed 145m (x4 over 169m) kubelet Failed to pull image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330": failed to pull and unpack image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330": failed to resolve reference "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330": failed to do request: Head "https://10.252.119.4:5000/v2/library/private-cloud-staging/switch-image-downloader/manifests/1.12.1-gdch.330?ns=gcr.io": dial tcp 10.252.119.4:5000: connect: no route to host Warning Failed 45m (x262 over 25h) kubelet Failed to pull image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330": failed to pull and unpack image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330": failed to resolve reference "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330": pulling from host 10.252.119.11:10443 failed with status code [manifests 1.12.1-gdch.330]: 401 Unauthorized Normal Pulling 40m (x287 over 26h) kubelet Pulling image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" Normal BackOff 22s (x6504 over 25h) kubelet Back-off pulling image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" 해결 방법: 이 문제를 해결하려면 이미지 pnet-core-switch-image-downloader에 switch-image-downloader 태그를 다시 지정하세요.
노드 플랫폼	1.12.1	1.11.x에서 1.12.1로 업그레이드할 때 호스트 방화벽이 스위치 이미지 다운로드를 차단함 증상 1.11.x에서 1.12.1로 업그레이드할 때 호스트 방화벽에서 사용하는 인터페이스가 일치하지 않아 호스트 방화벽이 스위치 이미지 다운로드를 차단합니다. 해결 방법: 1.11.x에서 1.12.x로 업그레이드하는 경우에만 업그레이드 전에 다음 해결 방법을 적용하세요. 루트 관리자 및 조직 관리자 클러스터를 업데이트합니다. 루트 관리자 베어메탈 노드와 조직 관리자 베어메탈 노드의 노드 풀 이름과 네임스페이스를 가져옵니다. 루트 관리자 클러스터의 경우 루트 관리자 kubeconfig를 사용합니다. 다음 명령어는 머신 인벤토리를 나열하고 베어 메탈 머신별로 목록을 필터링합니다. kubectl --kubeconfig=KUBECONFIG get inventorymachines -l cluster.private.gdc.goog/provisioner=baremetal-provisioner.cluster.private.gdc.goog -o json | jq -c -r '.items[].spec.nodePoolRef | [.name, .namespace] | @csv | sub("\"";"";"g")' | sort | uniq 출력에 노드 풀 이름과 네임스페이스가 표시됩니다. admin-control-plane-node-pool,org-1 root-admin-control-plane,root 출력의 값은 다음을 나타냅니다. ORG_ADMIN_NODEPOOL_NAME: admin-control-plane-node-pool ORG_ADMIN_NODEPOOL_NAMESPACE: org-1 ROOT_ADMIN_NODEPOOL_NAME: root-admin-control-plane ROOT_ADMIN_NODEPOOL_NAMESPACE: root 노드에서 eth0의 이름을 mgmt0로 바꾸려면 루트 관리자 및 조직 관리자 클러스터에서 다음 객체를 만드세요. apiVersion: system.private.gdc.goog/v1alpha1 kind: AnsiblePlaybook metadata: name: eth0-to-mgmt0-int-rename namespace: gpc-system spec: playbook: | - name: Rename interface from eth0 to mgmt0 hosts: all gather_facts: no tasks: - name: Rename interface in netplan file ansible.builtin.lineinfile: path: /etc/netplan/50-cloud-init.yaml regexp: '^(.*)set-name: eth0(.*)$' line: '\1set-name: mgmt0\2' backrefs: true register: netplan - name: Disable cloud-init network configuration ansible.builtin.lineinfile: path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg line: 'network: {config: disabled}' state: present create: true - name: Restart netplan command: netplan apply when: netplan.changed --- apiVersion: system.private.gdc.goog/v1alpha1 kind: OSPolicy metadata: name: interface-renaming namespace: gpc-system labels: ospolicy.system.private.gdc.goog/override-maintenance: "true" spec: interval: period: 1m inventory: - apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool name: ${ORG_ADMIN_NODEPOOL_NAME} namespace: ${ORG_ADMIN_NODEPOOL_NAMESPACE} - apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool name: ${ROOT_ADMIN_NODEPOOL_NAME} namespace: ${ROOT_ADMIN_NODEPOOL_NAMESPACE} policy: installPlaybook: name: eth0-to-mgmt0-int-rename 앞의 YAML 파일이 배포되면 NODEPOOL_NAME 및 NODEPOOL_NAMESPACE 필드가 각 클러스터의 모든 노드 풀 목록으로 채워집니다. 실제 루트 관리자 노드 풀과 조직 관리자 노드 풀 이름이 있는 루트 관리자 클러스터의 yaml 파일 예시는 다음과 같습니다. apiVersion: system.private.gdc.goog/v1alpha1 kind: AnsiblePlaybook metadata: name: eth0-to-mgmt0-int-rename namespace: gpc-system spec: playbook: | - name: Rename interface from eth0 to mgmt0 hosts: all gather_facts: no tasks: - name: Rename interface in netplan file ansible.builtin.lineinfile: path: /etc/netplan/50-cloud-init.yaml regexp: '^(.*)set-name: eth0(.*)$' line: '\1set-name: mgmt0\2' backrefs: true register: netplan - name: Disable cloud-init network configuration ansible.builtin.lineinfile: path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg line: 'network: {config: disabled}' state: present create: true - name: Restart netplan command: netplan apply when: netplan.changed --- apiVersion: system.private.gdc.goog/v1alpha1 kind: OSPolicy metadata: name: interface-renaming namespace: gpc-system labels: ospolicy.system.private.gdc.goog/override-maintenance: "true" spec: interval: period: 1m inventory: - apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool name: admin-control-plane-node-pool namespace: org-1 - apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool name: root-admin-control-plane namespace: root policy: installPlaybook: name: eth0-to-mgmt0-int-rename 루트 관리자 클러스터에 YAML 파일을 적용합니다. kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG -f YAML_FILE_NAME 시스템 클러스터를 업데이트합니다. 머신 인벤토리를 가져오고 베어메탈 머신별로 목록을 필터링합니다. kubectl --kubeconfig=_ORG_ADMIN_KUBECONFIG get inventorymachines -l cluster.private.gdc.goog/provisioner=baremetal-provisioner.cluster.private.gdc.goog -o json | jq -c -r '.items[].spec.nodePoolRef | [.name, .namespace] | @csv | sub("\"";"";"g")' | sort | uniq 출력은 다음과 같습니다. worker-node-pool-o1-highgpu1-48-gdc-metal,org-1-system-cluster 출력의 값은 다음을 나타냅니다. SYSTEM_CLUSTER_NODEPOOL_NAME: worker-node-pool-o1-highgpu1-48-gdc-metal SYSTEM_CLUSTER_NODEPOOL_NAMESPACE: org-1-system-cluster NODEPOOL_NAME 및 NODEPOOL_NAMESPACE 필드는 이전 명령어의 출력 목록에서 채워집니다. 시스템 클러스터에서 다음 객체를 만들어 노드에서 eth0의 이름을 mgmt0로 바꾸고 OS 정책을 업데이트합니다. apiVersion: system.private.gdc.goog/v1alpha1 kind: AnsiblePlaybook metadata: name: eth0-to-mgmt0-int-rename namespace: gpc-system spec: playbook: | - name: Rename interface from eth0 to mgmt0 hosts: all gather_facts: no tasks: - name: Rename interface in netplan file ansible.builtin.lineinfile: path: /etc/netplan/50-cloud-init.yaml regexp: '^(.*)set-name: eth0(.*)$' line: '\1set-name: mgmt0\2' backrefs: true register: netplan - name: Disable cloud-init network configuration ansible.builtin.lineinfile: path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg line: 'network: {config: disabled}' state: present create: true - name: Restart netplan command: netplan apply when: netplan.changed --- apiVersion: system.private.gdc.goog/v1alpha1 kind: OSPolicy metadata: name: interface-renaming namespace: gpc-system labels: ospolicy.system.private.gdc.goog/override-maintenance: "true" spec: interval: period: 1m inventory: - apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool name: ${SYSTEM_CLUSTER_NODEPOOL_NAME} namespace: ${SYSTEM_CLUSTER_NODEPOOL_NAMESPACE} policy: installPlaybook: name: eth0-to-mgmt0-int-rename 실제 노드 풀 이름이 있는 시스템 클러스터의 yaml 파일 예는 다음과 같습니다. apiVersion: system.private.gdc.goog/v1alpha1 kind: AnsiblePlaybook metadata: name: eth0-to-mgmt0-int-rename namespace: gpc-system spec: playbook: | - name: Rename interface from eth0 to mgmt0 hosts: all gather_facts: no tasks: - name: Rename interface in netplan file ansible.builtin.lineinfile: path: /etc/netplan/50-cloud-init.yaml regexp: '^(.*)set-name: eth0(.*)$' line: '\1set-name: mgmt0\2' backrefs: true register: netplan - name: Disable cloud-init network configuration ansible.builtin.lineinfile: path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg line: 'network: {config: disabled}' state: present create: true - name: Restart netplan command: netplan apply when: netplan.changed --- apiVersion: system.private.gdc.goog/v1alpha1 kind: OSPolicy metadata: name: interface-renaming namespace: gpc-system labels: ospolicy.system.private.gdc.goog/override-maintenance: "true" spec: interval: period: 1m inventory: - apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool name: worker-node-pool-o1-highgpu1-48-gdc-metal namespace: org-1-system-cluster policy: installPlaybook: name: eth0-to-mgmt0-int-rename 조직 관리자 클러스터에 yaml 파일을 적용합니다. kubectl --kubeconfig=ORG_ADMIN_KUBECONFIG -f YAML_FILE_NAME
하위 네트워킹	1.12.2	버전이 9.3.10보다 낮은 버전으로 미리 로드된 네트워크 스위치는 부트스트랩에 실패할 수 있음 증상 버전이 9.3.10보다 낮은 버전으로 미리 로드된 네트워크 스위치는 스위치의 예상 버전이 10.3(4a)이므로 부트스트랩에 실패합니다. 해결 방법: 스위치 펌웨어를 9.3.5에서 9.3.10으로, 9.3.10에서 10.3.4a로 수동으로 업그레이드합니다.
하위 네트워킹	1.12.2	org-admin 노드에 대한 일부 연결 시간이 초과됨 증상 스위치의 인증서가 만료되어 스위치에 최신 구성이 없기 때문에 스위치에서 연결이 끊어집니다. 해결 방법: 스위치에서 인증서를 순환합니다. 새 인증서를 활성화합니다. nxapi certificate httpskey keyfile bootflash:api-private-key.pem nxapi certificate httpscrt certfile bootflash:api-certificate.pem nxapi certificate enable
파일 및 블록 스토리지	1.12.1 1.12.2 1.12.4	1.11.1에서 1.12.1, 1.12.2 또는 1.12.4로 업그레이드할 때 file-netapp-trident 하위 구성요소 출시가 실패할 수 있음 증상 Linux Unified Key Setup (LUKS) 하위 구성요소는 업그레이드 중에 다시 배포되지 않습니다. file-netapp-trident 하위 구성요소를 확인하려면 다음을 실행하세요. 별칭 설정: alias ka='kubectl --kubeconfig=/path/to/root-admin/root-admin-kubeconfig' alias ko='kubectl --kubeconfig=/path/to/org-admin/org-admin-kubeconfig' 하위 구성요소를 가져옵니다. ka get subcomponent -n root file-netapp-trident -o yaml ko get subcomponent -n root file-netapp-trident -o yaml 출력은 다음과 같이 표시될 수 있습니다. 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: 1 reason: ReconciliationError status: "True" type: Reconciling 이 예시에서는 standard-rwo 및 standard-block의 두 스토리지 클래스가 실패했습니다. 해결 방법: 작업에서 만들지 못한 StorageClasses(예: standard-rwo, standard-block, standard-rwo-non-luks, standard-block-non-luks)를 삭제합니다. 클러스터의 oclcm-backend-controller(루트 및 조직 관리자 클러스터의 경우 루트 관리자 컨트롤러, 시스템 및 사용자 클러스터의 경우 조직 관리자 컨트롤러)를 다시 시작하여 StorageClasses의 다시 생성을 트리거합니다. 버전 1.12.4의 경우 설치된 스토리지 클래스에 disk.gdc.goog/luks-encrypted: 주석이 true로 설정되어 있는지 확인합니다 (비 luks 스토리지 클래스 제외). 주석이 true로 설정되지 않은 경우 1단계와 2단계를 반복합니다. 클러스터에서 netapp-trident 배포와 netapp-trident DaemonSet을 다시 시작합니다. PersistentVolumeClaim (PVC) 리소스에 LUKS 보안 비밀이 생성되었는지 확인합니다. 모든 PVC에는 g-luks-$pvc_name 형식의 비밀이 있어야 합니다. file-netapp-trident 하위 구성요소의 상태에 오류가 없는지 확인합니다.
객체 스토리지	1.12.2	루트 조직 업그레이드 후 객체 스토리지 버킷이 준비되지 않을 수 있음 증상 루트 조직을 1.12.1에서 1.12.x로 업그레이드한 후 업그레이드 후 검증이 다음 오류와 함께 실패합니다. upgrade_post_root_org_validation.go:121: Bucket(s) not ready: 8 errors occurred: * Bucket "atat-system/invoice-export-bucket" not ready * Bucket "mon-system/cortex-metrics-alertmanager" not ready * Bucket "mon-system/cortex-metrics-blocks" not ready * Bucket "mon-system/cortex-metrics-ruler" not ready * Bucket "obs-system/audit-logs-loki-io" not ready * Bucket "obs-system/cortex-metrics-alertmanager" not ready * Bucket "obs-system/cortex-metrics-blocks" not ready * Bucket "obs-system/cortex-metrics-ruler" not ready 해결 방법: 업그레이드를 시작하기 전에 파이널라이저를 수동으로 추가합니다.
클러스터 관리	1.12.1, 1.12.2	Kubernetes 버전 1.27.x를 사용하는 사용자 클러스터에 노드 풀이 초기화되지 않을 수 있음 증상 Kubernetes 버전 1.27.x에서 실행되는 사용자 클러스터 내의 노드 풀이 초기화되지 않아 사용자 클러스터가 컨테이너 워크로드를 처리하지 못할 수 있습니다. 해결 방법: Kubernetes 버전 1.27.x를 사용하여 사용자 클러스터를 만들지 마세요.
가상 머신	1.12.0	소스 이미지에 기본값이 있는 경우 이미지 변환에서 패키지를 가져오지 못함 증상 Ubuntu 소스 이미지에 sources.list의 기본 APT 소스가 포함된 경우 이미지 변환 단계에서 VM 이미지 가져오기가 실패합니다. 해결 방법: 소스 이미지에서 /var/lib/apt/lists/ 디렉터리가 비어 있는지 확인합니다.
가상 머신	1.12.2	가져오기 프로그램 포드가 실패하거나 멈춤 증상 가져오기 도구 포드 목록을 가져옵니다. kubectl get pods -A | grep import 출력은 다음과 같이 표시될 수 있습니다. user-vm-1-cluster importer-vm-1b19e25c-disk-8dwzz 0/1 ContainerCreating 0 2d9h user-vm-1-cluster importer-vm-72b96d39-disk-frv4f 0/1 CreateContainerError 124 (43h ago) 2d9h user-vm-1-cluster importer-vm-c7a7a320-disk-qjgt2 0/1 CreateContainerError 124 (43h ago) 2d9h user-vm-2-cluster importer-vm-06ca7e94-disk-b66fz 0/1 CreateContainerError 124 (43h ago) 2d9h user-vm-2-cluster importer-vm-7e63b71b-disk-jxqfz 0/1 CreateContainerError 116 (43h ago) 2d9h user-vm-2-cluster importer-vm-e0651556-disk-k8scf 0/1 CreateContainerError 123 (43h ago) 2d9h 로그에 다음과 같은 이벤트가 표시될 수 있습니다. Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 2m14s (x1630 over 2d9h) attachdetach-controller AttachVolume.Attach failed for volume "pvc-2000efe0-b4a0-4856-899b-7e0c9fd33405" : rpc error: code = Unknown desc = error publishing ontap-san driver: problem mapping LUN /vol/trident_pvc_2000efe0_b4a0_4856_899b_7e0c9fd33405/lun0: results: {http://www.netapp.com/filer/admin results} status,attr: failed reason,attr: No such LUN exists errno,attr: 9017 lun-id-assigned: nil 해결 방법: 오류 메시지에서 PersistentVolumeClaim(PVC) 이름을 가져옵니다(예: pvc-2000efe0-b4a0-4856-899b-7e0c9fd33405). 이 이름으로 PersistentVolume (PV)를 조회하고 나중에 사용할 수 있도록 spec.csi.volumeAttributes.internalName을 기록해 둡니다. FILE-A0006 런북의 단계에 따라 스토리지 클러스터에 SSH 연결을 설정합니다. 볼륨을 표시하고 명령어가 반환하는 vserver 이름을 기록합니다. volume show -volume INTERNAL_NAME 볼륨을 오프라인으로 전환합니다. volume offline -volume INTERNAL_NAME -vserver VSERVER_NAME 볼륨을 삭제합니다. volume delete -volume INTERNAL_NAME -vserver VSERVER_NAME
가상 머신	1.12.1 1.12.2	network-controller-manager 설치 실패로 인해 VMRuntime이 준비되지 않았을 수 있음 증상 타겟 클러스터 (관리자 또는 시스템 클러스터일 수 있음)의 VMRuntime 상태가 VMRuntime status.ready = false이고 kube-system 네임스페이스의 network-controller-manager가 대기 중입니다. kubectl --kubeconfig=${TARGET_CLUSTER_KUBECONFIG} get vmruntime vmruntime apiVersion: virtualmachine.private.gdc.goog/v1 kind: VMRuntime metadata: ... spec: ... status: ready: false kubectl --kubeconfig=${TARGET_CLUSTER_KUBECONFIG} describe deploy network-controller-manager -n kube-system ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedMount 3m36s (x122 over 3h55m) kubelet MountVolume.SetUp failed for volume "cert" : secret "network-webhook-server-cert" not found 해결 방법: 배포 network-controller-manager를 삭제하면 VMM 운영자가 필요한 인증서를 사용하여 배포가 자동으로 다시 생성됩니다. 배포가 Running 상태가 되고 VMRuntime 상태가 ready=true로 변경됩니다. kubectl --kubeconfig=${TARGET_CLUSTER_KUBECONFIG} delete deploy network-controller-manager -n kube-system
가상 머신	1.12.2	가상 머신 디스크의 프로비저닝 시간이 김 증상 VM 가져오기 프로그램 포드가 비정상 종료 루프를 실행하고 데이터 볼륨이 90분 이상 가져오기 상태로 멈춥니다. 포드 상태는 다음과 같을 수 있습니다. test-vm-project importer-disk-ops-test-vm-boot-disk-tbdtz 0/1 CrashLoopBackOff 14 (47s ago) 90m 172.16.20.94 zb-aa-bm08 <none> <none> test-vm-project importer-test-vm-1-boot-disk-plsxk 1/1 Running 1 (2m53s ago) 8m59s 172.16.22.244 zb-ab-bm09 <none> <none> test-vm-project importer-test-vm-2-boot-disk-npjc8 1/1 Running 6 (12m ago) 40m 172.16.22.180 zb-ab-bm09 <none> <none> 모든 디스크 가져오기는 3시간 이내에 완료됩니다.
업그레이드	1.12.2	1.11.1에서 1.12.2로 업그레이드할 때 unet-nodenetworkpolicy-infra 하위 구성요소가 조정되지 않음 증상 실패 메시지는 다음과 같이 표시될 수 있습니다. 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 해결 방법: 실패가 루트에 있는 경우 다음 단계에서 KUBECONFIG를 루트 관리자 kubeconfig로 바꿉니다. 조직에서 오류가 발생한 경우 다음 단계에서 KUBECONFIG를 조직 관리자 kubeconfig로 바꿉니다. 다음을 실행합니다. alias k="kubectl --kubeconfig=KUBECONFIG" k get networks mgmt-network -o json | jq '.spec.nodeInterfaceMatcher.interfaceName' 출력이 eth0이면 다음을 실행합니다. k patch network mgmt-network -p '{"metadata":{"finalizers":null}}' --type=merge mgmt-network를 삭제합니다. k delete network mgmt-network unet-nodenetworkpolicy-infra의 상태에 오류가 없는지 확인합니다. 예를 들면 다음과 같습니다. alias k="kubectl kubeconfig=KUBECONFIG" k get subcomponent unet-nodenetworkpolicy-infra -n org-1 출력 형식은 다음과 같습니다. NAME AGE STATUS unet-nodenetworkpolicy-infra 34d ReconciliationCompleted
업그레이드	1.12.2	1.11.x에서 1.12.2로 업그레이드하는 동안 시스템 클러스터가 실패함 증상 1.11.x에서 1.12.2로 업그레이드하는 동안 또는 업그레이드 후 bm-system-add-ons-* 이름이 있는 작업이 다음 오류와 함께 실패할 수 있습니다. E0326 17:04:22.997270 1 main.go:180] configdrift: Config drift health check failed F0326 17:04:22.997365 1 main.go:184] One or more checks failed. 해결 방법: 1.11에서 1.12.2로 업그레이드를 시작하기 전에 모든 Kubernetes 클러스터에 다음 주석을 적용합니다. # To bypass preflight check errors: baremetal.cluster.gke.io/bypass-check="vip_subnet" 예를 들어 루트 관리자 클러스터에서는 다음을 사용합니다. kubectl annotate -n root cluster root-admin baremetal.cluster.gke.io/bypass-check="vip_subnet" --kubeconfig=ROOT_ADMIN_KUBECONFIG
업그레이드	1.12.2	org-1-system-cluster에서 file-observability 하위 구성요소가 실패함 증상 이 문제는 1.11.1에서 1.12.2로 업그레이드할 때 발생합니다. file-observability 하위 구성요소의 .yaml 파일을 확인합니다. kubectl get subcomponent file-observability -n org-1-system-cluster -o yaml 파일의 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' 해결 방법: file-system 네임스페이스를 확인하여 org-admin cluster에서 종료되지 않는지 확인합니다. kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get namespace file-system 종료 중인 경우 file-system 네임스페이스에서 모니터링 타겟을 삭제합니다. kubectl --kubeconfig ORG_ADMIN_KUBECONFIG delete monitoringtarget -n file-system --all 다음 주석을 하위 구성요소에 추가하여 mon-admin 하위 구성요소가 실행될 때까지 file-observability 하위 구성요소를 일시중지합니다. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG annotate -n org-1 subcomponent file-observability lcm.private.gdc.goog/paused='true' kubectl --kubeconfig ORG_ADMIN_KUBECONFIG annotate -n org-1-system-cluster subcomponent file-observability lcm.private.gdc.goog/paused='true' 업그레이드가 완료된 후 하위 구성요소를 일시중지하려면 주석을 삭제하세요. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG annotate -n org-1 subcomponent file-observability lcm.private.gdc.goog/paused- kubectl --kubeconfig ORG_ADMIN_KUBECONFIG annotate -n org-1-system-cluster subcomponent file-observability lcm.private.gdc.goog/paused-
업그레이드	1.12.2	hsmcluster가 준비되지 않아 HSMupgrade가 실패함 증상 이 문제는 1.11.1에서 1.12.2로 업그레이드할 때 발생합니다. hsmupgraderequest 및 ctmclusterupgraderequest의 모든 업그레이드 단계가 완료되면 다음 오류가 표시됩니다. HSMCluster "hsmcluster" is not ready. 예를 들면 다음과 같습니다. - lastTransitionTime: "2024-04-08T15:18:45Z" message: HSMCluster "hsmcluster" is not ready observedGeneration: 2 reason: ziabhsm01PostUpgradeCheckFailed status: "False" type: AllComplete 해결 방법: HSM에서 업그레이드가 완료되었는지 확인하고 각 HSM의 IP 주소를 가져옵니다. kubectl get hsm -A --kubeconfig=ROOT_ADMIN_KUBECONFIG 출력 형식은 다음과 같습니다. NAMESPACE NAME AGE IP READY REASON gpc-system zi-aa-hsm01 11d 10.252.96.192 True ReconcileHSMSuccess gpc-system zi-ab-hsm01 11d 10.252.97.192 True ReconcileHSMSuccess gpc-system zi-ac-hsm01 11d 10.252.98.192 True ReconcileHSMSuccess ksctl을 다운로드하고 구성합니다. ksctl system info get --url=https://HSM_MANAGEMENT_IP을 실행하여 모든 HSM 버전이 ctmclusterupgraderequest의 .Spec.TargetVersion로 업그레이드되었는지 확인합니다. 출력 형식은 다음과 같습니다. ksctl system info get { "name": "zi-aa-hsm01", "version": "2.13.1+10196", "model": "CipherTrust Manager k570", "vendor": "Thales Group", "crypto_version": "1.7.0", "uptime": "0 days, 1 hours, 20 minutes", "system_time": "2024-04-08T19:51:27Z" } 각 HSM의 Status.FirmwareVersion 필드를 이전 단계에서 얻은 업그레이드된 버전으로 업데이트합니다. 예를 들면 다음과 같습니다. kubectl edit-status hsm HSM_NAME -n gpc-system ctmclusterupgraderequest.status.conditions 마지막 조건 상태를 False에서 True로 업데이트합니다. 그 후 hsmupgraderequest.status.conditions 마지막 조건 상태도 true가 됩니다. 예를 들면 다음과 같습니다. kubectl edit-status ctmclusterupgraderequest CTM_VERSION -n gpc-system kubectl get ctmclusterupgraderequest CTM_VERSION -n gpc-system -o yaml
업그레이드	1.12.2 1.12.4	연결할 수 없는 관리 IP 업그레이드 중에 서버의 관리 IP에 연결할 수 없습니다. 특히 스위치 OS 업그레이드 후 그렇습니다. Rocky Linux에서는 정적 경로를 추가할 때 정적 경로에 도달하는 데 사용되는 대상 IP에 정적 경로를 추가하기 전에 도달할 수 있어야 합니다. OS 업그레이드 후 스위치가 재부팅되는 경우 해당 관리 IP에 일시적으로 연결할 수 없습니다. 해결 방법: 데이터 IP 주소를 사용하여 서버에 SSH 연결을 설정하고 네트워킹 서비스를 다시 시작하여 누락된 고정 경로를 다시 만듭니다. systemctl restart NetworkManager.service
티켓팅 시스템	1.12.2	티켓팅 시스템 기술 자료 동기화 실패 증상 기술 자료 동기화 중에 다음과 같은 오류가 표시될 수 있습니다. Error: Article creation request failed status:400, body:map[error:map[detail:Rejected large REST payload with content-length = 10725676 bytes. Max allowed: 10485760 bytes. 해결 방법: 최대 길이를 늘리는 시스템 속성을 추가합니다. ServiceNow 플랫폼의 탐색 필터에 sys_properties.list를 입력합니다. New(새로 만들기)를 클릭합니다. 이름 필드에 glide.rest.max_content_length를 입력합니다. 유형 필드에서 string을 선택합니다. 값 필드에 15를 입력합니다. 제출을 클릭합니다. 기술 자료를 다시 동기화합니다.
티켓팅 시스템	1.12.2	티켓팅 시스템에 정상 업스트림이 없음 증상 gdchservices 조직을 수동으로 배포하면 티켓팅 시스템에 정상 업스트림이 없고, 생성된 VM이 없으며, midserver 포드가 support 네임스페이스의 gdchservices-system 클러스터에서 비정상입니다. 해결 방법: gdchservices-admin 클러스터에서 올바른 VM 이미지를 사용하여 새 TicketingSystem 커스텀 리소스를 만듭니다. apiVersion: ticketing.private.gdc.goog/v1 kind: TicketingSystem metadata: name: as-replacement namespace: support spec: replicas: 2 spec: image: ts-controller-app-server-2024-02-07-231907 imagenamespace: vm-system memory: 12G size: 100G vcpus: 8 version: name: glide-vancouver-07-06-2023__patch5-12-01-2023_12-11-2023_2006.zip
업그레이드	1.12.2	관리 IP가 있는 VM의 SSH 및 cilium 로그가 실패함 증상 관리 IP가 있는 VM에서는 로그인 액세스가 작동하지 않습니다. anetd 포드 로그에 다음과 같은 오류가 표시될 수 있습니다. Unable to create endpoint:[PUT /endpoint/{id}][400] putEndpointIdInvalid failed setting up layer2 interface 해결 방법: VM의 virt-launcher 포드를 삭제합니다.
업그레이드	1.12.2	mz-etcd 하위 구성요소가 spec.deployTarget 및 spec.Namespace를 업데이트하여 1.11.x에서 1.12.x로의 업그레이드가 실패함 증상 1.11x에서 1.12.x로 업그레이드하는 동안 다음과 같은 오류가 표시될 수 있습니다. kubectl --kubeconfig PATH_TO_ROOT_ADMIN_KUBECONFIG get subcomponent -n root mz-etcd -o yaml kubectl --kubeconfig PATH_TO_ROOT_ADMIN_KUBECONFIG get subcomponent -n org-1 mz-etcd -o yaml 업그레이드 전 mz-etcd 하위 구성요소의 사양은 다음과 같습니다. spec: crds: helmManifestSpec: chartURL: gcr.io/mz-etcd-crds:1.11.1-gdch.260 upgradeHookPolicy: OnVersionChange deployTarget: Local namespace: "" 해결 방법: 루트 관리자 클러스터에서 다음 하위 구성요소를 삭제합니다. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG delete subcomponent -n root mz-etcd kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG delete subcomponent -n org-1 mz-etcd 루트 및 조직 네임스페이스에서 하위 구성요소를 확인합니다. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get subcomponent -n root mz-etcd -o yaml kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get subcomponent -n org-1 mz-etcd -o yaml 새 하위 구성요소는 다음 사양을 충족해야 하며 chatURL은 클러스터가 이미 업그레이드된 버전을 표시해야 합니다. backend: helmManifestSpec: chartURL: gcr.io/mz-etcd-backend:1.12.2-gdch.785 ... dash: helmManifestSpec: chartURL: gcr.io/mz-etcd-dash:1.12.2-gdch.785 ... deployTarget: Remote namespace: mz-system mon: helmManifestSpec: chartURL: gcr.io/mz-etcd-mon:1.12.2-gdch.785 upgradeHookPolicy: OnVersionChange ... targetClusterName: root-admin targetClusterNamespace: root webhooks: helmManifestSpec: chartURL: gcr.io/mz-etcd-webhooks:1.12.2-gdch.785 upgradeHookPolicy: OnVersionChange
업그레이드	1.12.2	객체 스토리지 업그레이드에서 사후 검사 또는 사전 검사 중에 오류가 표시됨 증상 실행 전 검사 또는 실행 후 검사가 오류와 함께 실패합니다. 로그를 확인합니다. kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410 오류는 다음과 같이 표시될 수 있습니다. 03:42:05.701163 1 upgrade_check.go:276] 1 error occurred: * Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource {Role vm-system g-vm-image-bucket-reader } Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred: * Bucket "gpc-system/range-read-internal" not ready F0410 03:42:05.701901 1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred: * Bucket "gpc-system/range-read-internal" not ready 해결 방법: 비행 후 검사 중에 오류가 발생하고 다른 모든 검사가 오류 없이 완료된 경우 비행 후 검사를 건너뜁니다. 업그레이드가 다시 시작되면 루트 관리자 kubeconfig를 사용하여 프리플라이트 검사도 건너뛰어야 합니다. kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok 예를 들어 org-1에서 오류가 발생하면 명령어는 다음과 같습니다. kubectl delete organizationupgrade -n gpc-system org1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok 실행 전 검사 중에 오류가 발생하고 다른 모든 실행 전 검사가 오류 없이 완료된 경우 실행 전 검사를 건너뜁니다. kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok 예를 들어 org-1에서 오류가 발생하면 명령어는 다음과 같습니다. kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok 이 해결 방법을 적용하지 못하는 경우 두 번 이상 적용해야 할 수도 있습니다.
ATAT 포트폴리오	1.12.0 1.12.1 1.12.2 1.12.4	포트폴리오가 동기화되지 않음 증상 ConfigSync가 다음 메시지와 함께 오류를 발생시킵니다. KNV2009: failed to apply Portfolio.atat.config.google.com, atat-system/***: failed to create typed patch object (atat-system/***; atat.config. ││ google.com/v1alpha1, Kind=Portfolio): .spec.portfolioName: field not declared in schema. 해결 방법: GDC 버전 1.12에서 Portfolio 스키마가 변경되었습니다. portfolioName 필드가 portfolioID로 리팩터링되었습니다. 오류 메시지에 언급된 포트폴리오 커스텀 리소스가 포함된 YAML 파일을 찾습니다. portfolioName 필드를 portfolioID로 바꿉니다.
업그레이드	1.12.2	NTP OSPolicy 실패로 인해 다른 모든 OSPolicies가 실행되지 않음 증상 다음은 사전 비행 작업만 완료된 패치 작업에 대해 실행 중인 작업이 생성되지 않는 잠재적 이유입니다. NTP 오류로 인해 다른 모든 패치 작업이 실행되지 않습니다. 노드가 비정상 상태입니다. OS 구성 에이전트가 실행되고 있지 않습니다. OS 구성 에이전트가 OS 구성 서비스와 통신할 수 없습니다. OS 구성 서비스에 문제가 있습니다. 해결 방법: 노드의 `NodeTargetPolicy` CR을 확인합니다. `ref.name=admin-ntp-policy` 및 `type: Ready` 가 있고 상태가 false인 `NodeTargetPolicy` CR의 `.spec.osPolicies` 를 검색합니다. # Enter the node InventoryMachine name. NAME= kubectl get nodetargetpolicy -n gpc-system $NAME -ojsonpath="{.spec.osPolicies}" | jq 출력 형식은 다음과 같습니다. - conditions: - lastTransitionTime: "2024-04-19T19:12:01Z" message: "" observedGeneration: 7 reason: Complete status: "True" type: PolicyPreflightCompleted - lastTransitionTime: "2024-04-19T19:12:01Z" message: "" observedGeneration: 7 reason: None status: "True" type: PolicyConflictNone - lastTransitionTime: "2024-04-19T19:56:35Z" message: "" observedGeneration: 7 reason: Reconciled status: "True" type: Ready diff: os-policy-preflight-admin-ntp-policymf2w4-dpbxw playbookName: server-ntp-config ref: name: admin-ntp-policy namespace: gpc-system 이러한 `osPolicies` 의 조건을 모두 삭제하고 다음 부분만 유지합니다. - conditions: diff: os-policy-preflight-admin-ntp-policymf2w4-dpbxw playbookName: server-ntp-config ref: name: admin-ntp-policy namespace: gpc-system
업그레이드	1.12.3 1.12.4	NodeUpgrade에 Rocky Linux가 표시됨 증상 업그레이드되는 노드가 Ubuntu인데도 NodeUpgrade CR의 사양에 version: rocky-86-xyz 이 언급됩니다. 해결 방법: 이 정보는 무해하므로 해결 방법이 필요하지 않습니다. 노드가 최신 버전의 Ubuntu로 올바르게 업그레이드됩니다.
SIEM	1.12.0 1.12.1 1.12.2 1.12.3 1.12.4	SIEM 사전 설치 작업 실패 증상 루트 관리자 클러스터의 루트 및 org-1 네임스페이스에 있는 siem-*-preinstall 작업이 반복적으로 실패합니다. 해결 방법: SIEMComponent 기능 게이트가 사용 중지되면 작업이 실패할 것으로 예상됩니다. 실패가 구성요소가 손상되었음을 나타내지는 않습니다. 노이즈가 방해가 되는 경우 SIEM 구성요소의 조정을 일시중지할 수 있지만, 가능한 경우 구성요소를 사용 설정된 상태로 두는 것이 좋습니다. 구성요소 조정이 일시중지된 경우 향후 업그레이드에서 SIEM 구성요소 설치가 더 이상 제한되지 않을 때 수동으로 다시 사용 설정해야 합니다.
노드 업그레이드	1.12.0 1.12.1 1.12.2	오래된 lvm.conf 파일로 인해 노드 업그레이드가 실패함 증상 vgs, blkid, Ansible의 gather_facts이 응답하지 않는 문제가 있을 수 있습니다. 이 문제는 Rocky 및 Ubuntu OS 모두에 영향을 미칩니다. 노드가 이미 업그레이드된 경우 다음 단계를 실행하세요. lvm.conf 파일을 업데이트하는 프로세스는 다음 단계로 구성됩니다. 이 수정사항이 모든 노드에 적용될 수 있도록 모든 노드의 목록을 가져옵니다. Ansible 플레이북 및 OS 정책 파일을 만듭니다. 노드에 수정사항을 적용합니다. 수정사항이 적용되었는지 확인합니다. 기본 요건: IAM-R0004 런북의 단계에 따라 루트 관리자 클러스터의 ROOTCONFIG와 조직 관리자 클러스터의 ORGCONFIG를 생성합니다. IAM-R0005 런북의 단계에 따라 조직의 다음 역할을 획득합니다. 해결 방법: 클러스터에 해당하는 InventoryMachines를 식별합니다. kubectl --kubeconfig=$ROOTCONFIG get inventorymachines kubectl --kubeconfig=$ORGCONFIG get inventorymachines 출력을 분리합니다. 한 번에 하나의 클러스터를 수정합니다. 출력은 다음과 같이 표시될 수 있습니다. NAME bm-2bca8e3f bm-4caa4f4e 플레이북 및 정책 파일을 만듭니다. apiVersion: system.private.gdc.goog/v1alpha1 kind: AnsiblePlaybook metadata: name: lvm-conf-device-filter-node-update namespace: gpc-system spec: playbook: | - name: Add a device filter to /etc/lvm/lvm.conf hosts: all gather_facts: no tasks: # Change lvm.conf - name: Configure lvm for filtering out "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 below policy: installPlaybook: name: lvm-conf-device-filter-node-update 이전 인벤토리 섹션은 이 예와 같이 작성해야 합니다. 1단계에서 찾은 노드당 하나의 단락을 추가합니다. 한 번에 하나의 클러스터를 수행하므로 인벤토리 섹션을 하나의 클러스터의 노드로 채웁니다. inventory: # Node: bm-2bca8e3f - apiVersion: baremetal.cluster.gke.io/v1 kind: InventoryMachine name: bm-2bca8e3f # Node: bm-4caa4f4e - apiVersion: baremetal.cluster.gke.io/v1 kind: InventoryMachine name: bm-4caa4f4e 루트 관리자 클러스터에 수정사항을 적용합니다. kubectl --kubeconfig=$ROOTCONFIG apply -f PRECEDING_FILENAME_WITH_ROOT_NODES 조직 관리자 클러스터에 수정사항을 적용합니다. kubectl --kubeconfig=$ORGCONFIG apply -f PRECEDING_FILENAME_WITH_ORG_NODES 새 설정이 적용되도록 서버를 재부팅합니다. OS-P0005 런북의 단계에 따라 노드가 업데이트되었는지 확인합니다. 정책이 성공적으로 완료되었는지 확인한 후 k9s 도구를 사용하여 정책을 삭제합니다. :ospolicies와 같은 OS 정책으로 이동합니다. lvm-conf-device-filter-node-update 정책을 찾아 선택합니다. Ctrl + d를 누릅니다. 삭제를 확인합니다. 이 문제를 에스컬레이션하려면 SUPP-G0008 런북을 사용하여 티켓을 제출하세요. 티켓에는 다음을 비롯한 정보가 포함되어야 합니다. 실행된 명령어와 출력 메시지 InventoryMachineName 및 클러스터와 같은 세부정보 로그 메시지
운영체제(OS)	1.12.0 1.12.1 1.12.2 1.12.4	새 클러스터 또는 조직에 Rocky OS가 잘못 선택됨 증상 이 문제는 환경이 이전에 1.11로 배포된 후 1.12로 업그레이드된 경우 발생합니다. 1.12.x 버전에서 새 클러스터나 조직을 만들 때 ReleaseMetadata 및 Userclustermetadata CR에 지정된 Rocky OS 버전으로 인해 베어메탈 및 가상 머신 노드 프로비저닝에 Ubuntu OS가 아닌 Rocky OS가 선택됩니다. 해결 방법: 새 조직을 만들기 전에 다음 해결 방법을 적용하세요. Succeeded: true 상태가 아닌 OrganizationUpgrade CR이 있는지 확인합니다. for item in $(kubectl --kubeconfig=KUBECONFIG get OrganizationUpgrade -A -o custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace --no-headers); do NAME=$(echo $item | awk '{print $1}') NAMESPACE=$(echo $item | awk '{print $2}') STATUS=$(kubectl --kubeconfig=KUBECONFIG get organizationupgrade ${NAME} -n ${NAMESPACE} -o json | jq '.status.conditions[] | select(.type=="Succeeded") | .status') if [[ "$STATUS" != "True" ]]; then echo "Not in Succeeded: true state, stop following operations" fi done 이 경우 다음 단계로 진행하기 전에 엔지니어링팀에 에스컬레이션하세요. 실수로 노드 OS가 업그레이드되지 않도록 기존 OrganizationUpgrade CR을 모두 삭제합니다. for item in $(kubectl --kubeconfig=KUBECONFIG get OrganizationUpgrade -A -o custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace --no-headers); do NAME=$(echo $item | awk '{print $1}') NAMESPACE=$(echo $item | awk '{print $2}') echo "Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE" kubectl --kubeconfig=KUBECONFIG delete OrganizationUpgrade $NAME -n $NAMESPACE done 새 조직 생성의 타겟 GDC 버전을 정의합니다. 이 타겟 버전에 해당하는 ReleaseMetadata가 있어야 합니다. TARGET_RELEASE= 루트 관리자 클러스터에서 타겟 Ubuntu OS의 최신 OSImageMetadata CR을 식별하고 OS_VERSION 변수를 정의합니다. OS_VERSION=$(kubectl --kubeconfig=KUBECONFIG get osimagemetadata --sort-by=.metadata.creationTimestamp | grep -wv rocky | tail -1 | awk '{print $1}' | sed 's/gdch-node-os-//g') echo $OS_VERSION 출력은 다음과 같이 표시될 수 있습니다. 1.12.4-gdch.4 변수가 TARGET_RELEASE와 동일한 major.minor.patch 버전(예: 1.12.4)을 사용하는지 확인합니다. 그렇지 않은 경우 다음 단계를 진행하기 전에 엔지니어링팀에 에스컬레이션합니다. 루트 관리자 클러스터에서 Ubuntu OS_VERSION를 사용하도록 타겟 ReleaseMetadata를 업데이트합니다. kubectl --kubeconfig=KUBECONFIG patch releasemetadata "${TARGET_RELEASE}" --type='json' -p='[{"op": "replace", "path": "/spec/adminCluster/bmNodeImage", "value": '"${OS_VERSION}"'}, {"op": "replace", "path": "/spec/adminCluster/vmNodeImage", "value": '"${OS_VERSION}"'}, {"op": "replace", "path": "/spec/systemCluster/bmNodeImage", "value": '"${OS_VERSION}"'}, {"op": "replace", "path": "/spec/systemCluster/vmNodeImage", "value": '"${OS_VERSION}"'}]' 타겟 ReleaseMetadata의 매핑된 UserclusterMetadata 목록을 식별합니다. UCMS=$(kubectl --kubeconfig=KUBECONFIG get releasemetadata "${TARGET_RELEASE}" -o json | jq -r '.spec.userClusters[].name') 각 조직의 루트 관리자 클러스터와 조직 관리자 클러스터에서 Ubuntu OS_VERSION를 사용하도록 타겟 UserclusterMetadata를 업데이트합니다. 각 클러스터에 대해 다음 명령어를 실행합니다. for UCM in ${UCMS}; do echo "Updating UserclusterMetadata $UCM" kubectl --kubeconfig=KUBECONFIG patch userclustermetadata.upgrade.private.gdc.goog "${UCM}" --type='json' -p='[{"op": "replace", "path": "/spec/vmNodeImage", "value": '"${OS_VERSION}"'}]' done
가상 머신	1.12.1 1.12.2 1.12.4	qcow2 및 원시 이미지의 BYO 이미지 가져오기가 실패함 증상 gdcloud compute images import CLI를 사용하여 로컬 VM 이미지를 가져오면 가져오기 상태가 WaitingForTranslationVM 또는 ImportJobNotCreated에 멈춥니다. 이는 변환 또는 가져오기를 위해 생성된 임시 디스크가 qcow2 또는 원시 이미지와 정확히 동일한 크기를 사용하지만 LUKS가 디스크 프로비저닝 실패를 유발하는 몇 MiB의 오버헤드를 추가하기 때문입니다. 해결 방법: 동일한 이미지 이름이지만 더 큰 spec.minimumDiskSize를 사용하여 새 VirtualMachineImageImport를 수동으로 만듭니다. 예를 들어 이미지를 가져오는 데 사용된 명령어가 다음과 같은 경우: gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS CLI에 의해 자동으로 생성된 원래 VirtualMachineImageImport의 X Gi가 minimumDiskSize인 경우 X+1 Gi로 새로 만듭니다. 이 값은 가져오는 이미지의 크기를 기반으로 합니다. qcow2의 경우 가상 크기입니다. 예를 들어 20Gi는 21Gi로 대체해야 합니다. CLI가 호출된 방식에 따라 자리표시자 값을 바꿉니다. VirtualMachineImageImport를 찾습니다. kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml 객체가 없으면 gdcloud compute images import ... 명령어를 다시 트리거합니다. 콘솔 출력이 Uploading image to ...에서 Image import has started for ...로 전환되면 Ctrl+C를 눌러 로컬 이미지가 객체 스토리지에 업로드되고 VirtualMachineImageImport가 새 이미지를 만드는 데 참고할 수 있도록 보존되도록 합니다. 더 큰 minimumDiskSize를 사용하여 새 VirtualMachineImageImport를 만듭니다. apiVersion: virtualmachine.gdc.goog/v1 kind: VirtualMachineImageImport metadata: name: $IMPORT_NAME_NEW namespace: $NAMESPACE spec: imageMetadata: minimumDiskSize: $NEW_SIZE name: $IMAGE_NAME operatingSystem: $OS source: objectStorage: bucketRef: name: vm-images-bucket objectName: $LOCAL_FILENAME
가상 머신	1.12.0 1.12.1 1.12.2 1.12.3	이미지 가져오기가 TranslationInProgress에서 멈춤 증상 시스템 클러스터의 프로젝트 네임스페이스에 있는 importer-image-import-$VMII 포드가 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`) 오류와 함께 비정상 종료됩니다. VirtualMachineImageImport VMII 객체의 조건 유형은 Ready이고 상태는 False이며 가져오기를 시작한 후 2시간이 지나면 이유는 TranslationInProgress입니다. 해결 방법: 속도를 개선하려면 다음과 같이 이미지의 최소 디스크 크기를 200Gi로 수정하세요. kubectl get validatingwebhookconfiguration vmm-image-controller-v1-webhook -oyaml > /tmp/vmm-image-controller-v1-webhook.yaml kubectl delete validatingwebhookconfiguration vmm-image-controller-v1-webhook kubectl patch virtualmachineimageimport $VMII -n $PROJECT -p '{"spec": {"imageMetadata": {"minimumDiskSize": "200Gi"}}}' kubectl apply -f /tmp/vmm-image-controller-v1-webhook.yaml ValidatingWebhookConfiguration를 삭제하고 적용하려면 조직 관리자 클러스터의 클러스터 관리자 kubeconfig가 필요합니다. 다음 런북 IAM-R0004를 참고하세요. gdcloud를 사용하여 가져오기를 시작하는 경우 minimumDiskSize 매개변수를 제공할 방법이 없습니다. VMII 객체를 만들고 이전 명령어에 표시된 대로 VMII를 수정해야 합니다. VirtualMachineImageImport 프로세스가 계속되지만 후속 단계에서 다시 멈춥니다. 시스템 클러스터의 프로젝트 네임스페이스에서 image-import-$VMII 작업이 error: stream error: stream ID x; NO_ERROR; received from peer 오류와 함께 계속 실패하는 것을 확인할 수 있습니다. 이때 이미지 가져오기가 완료됩니다. 최종 이미지가 객체 스토리지에 업로드되지만 VirtualMachineImage가 누락됩니다. 다음과 같이 VirtualMachineImage를 수동으로 만들 수 있습니다. kubectl apply -f - <<EOF apiVersion: virtualmachine.gdc.goog/v1 kind: VirtualMachineImage metadata: name: $NAME namespace: $PROJECT spec: minimumDiskSize: 200Gi operatingSystem: name: $OS_NAME EOF `$NAME` 은 `VMII.ImageMetadata.Name`과 일치해야 하고 `$OS_NAME` 은 [`ubuntu-2004`, `ubuntu-2204`, `windows-2019`, `rhel-8`] 중 하나일 수 있으며 가져온 이미지의 유형과 일치해야 합니다.
Istio	1.12.4	istio-system 네임스페이스의 istio-eastwestgateway 배포가 멈춰 있음 증상 istio-system 네임스페이스의 istio-eastwestgateway 배포가 멈추고 포드 이벤트에 kubelet의 Back-off pulling image "auto" 오류가 표시됩니다. 문제를 진단하려면 istio-revision-tag-default라는 mutatingwebhookconfiguration가 멈춘 게이트웨이 배포와 동일한 클러스터에 있는지 확인합니다. kubectl --kubeconfig=KUBECONFIG get mutatingwebhookconfiguration istio-revision-tag-default 해결 방법: 구성 파일이 있으면 istio-system 네임스페이스에서 배포 istio-eastwestgateway를 다시 시작합니다. kubectl --kubeconfig=KUBECONFIG rollout restart deployment/istio-eastwestgateway -n istio-system 구성되지 않은 경우 웹훅이 존재할 때까지 기다립니다. 조정 루프에 있으므로 곧 발생합니다.
모니터링	1.12.2	슬라이스 범위가 범위를 벗어난 오류로 인해 cortex-store-gateway이 다시 시작됨 증상 cortex-store-gateway 포드가 로그에 다음 오류 메시지와 함께 다시 시작됩니다. panic: runtime error: slice bounds out of range 해결 방법: 시스템 클러스터에서 mon-cortex 하위 구성요소를 일시중지합니다. kubectl --kubeconfig $ORG_ADMIN_CONFIG annotate subcomponent mon-cortex -n $SYSTEM_CLUSTER_NAMESPACE lcm.private.gdc.goog/paused=true 시스템 클러스터에서 cortex-config configMap을 수정하고 index_cache 내 memcached의 제한 시간을 2초로 설정하여 index_cache 구성이 다음과 같이 표시되도록 합니다. index_cache: backend: memcached memcached: addresses: dnssrvnoa+_memcached._tcp.cortex-index-memcached.mon-system.svc.cluster.local timeout: 2s 업데이트된 구성을 사용하도록 시스템 클러스터에서 cortex-store-gateway 포드를 다시 시작합니다.
업그레이드	1.12.4	업그레이드 중에 루트 관리 노드를 재부팅하면 하위 구성요소 오류가 발생함 증상 베어메탈 노드가 NotReady로 표시되고 서버가 부팅 화면에서 멈추며 마지막 메시지는 Retrieving encryption keys입니다. 해결 방법: iLO를 다시 시작합니다. iLO가 다시 시작되면 서버를 다시 시작합니다.
업그레이드	1.12.4	업그레이드 중에 storagecluster의 버전 번호가 표시되지 않음 증상 업그레이드 후 StorageCluster CR에 StorageVersion 상태 필드의 값이 표시되지 않습니다. 버전을 확인합니다. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get StorageCluster -n gpc-system 버전 필드가 비어 있으면 해결 방법의 단계를 따릅니다. 해결 방법: file-storage-backend-controller 배포를 다시 시작합니다. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG rollout restart deployment -n file-system file-storage-backend-controller
운영 제품군 인프라 (OI)	1.12.4	Fluent Bit 설치 프로그램 경로가 잘못됨 증상 fluent-bit 설치 프로그램 위치가 operations_center\bin\fluent-bit-win64.msi로 변경되었습니다. Copy-ConfigHostFiles.ps1에서는 fluent-bit 클라이언트 설치 프로그램이 fluent-bit-*-win64.* 패턴과 일치해야 합니다. 이 패턴이 더 이상 일치하지 않으므로 설치 프로그램이 설치 프로그램을 찾지 못합니다. 해결 방법: Copy-ConfigHostFiles.ps1 파일을 엽니다. 다음 줄을 찾습니다. $(Get-Item -Path 'H:\operations_center\bin\fluent-bit-*-win64.*').FullName 이전 줄을 수정하여 올바른 설치 프로그램 위치를 추가합니다. $(Get-Item -Path 'H:\operations_center\bin\fluent-bit-win64.*').Name
운영 제품군 인프라 (OI)	1.12.4	Nessus 설치 프로그램 경로가 잘못됨 증상 Nessus 설치 프로그램 위치가 operations_center\bin\NessusAgent-x64.msi로 변경되었습니다. Copy-ConfigHostFiles.ps1은 클라이언트 설치 프로그램이 /NessusAgent-10.4.1-x64.msi 파일 이름과 일치해야 합니다. 이 패턴이 더 이상 일치하지 않으므로 설치 프로그램이 설치 프로그램을 찾지 못합니다. 해결 방법: Copy-ConfigHostFiles.ps1 파일을 엽니다. 다음 줄을 찾습니다. [pscustomobject]@{source = "H:\operations_center\bin\Nessus-10.4.1-x64.msi"; destination = "C:\config\nessus_mgr\Nessus-10.4.1-x64.msi" } [pscustomobject]@{source = "H:\operations_center\bin\Nessus-10.4.1-x64.msi"; destination = "C:\config\nessus_oob\Nessus-10.4.1-x64.msi" } 위의 줄을 수정하여 올바른 설치 프로그램 위치를 추가하고 Nessus-10.4.1-x64.msi를 NessusAgent-x64.msi로 변경합니다. [pscustomobject]@{source = "H:\operations_center\bin\NessusAgent-x64.msi"; destination = "C:\config\nessus_mgr\NessusAgent-x64.msi" } [pscustomobject]@{source = "H:\operations_center\bin\NessusAgent-x64.msi"; destination = "C:\config\nessus_oob\NessusAgent-x64.msi" }
객체 스토리지	1.12.4	새 조직 생성이 VMImageDistributing 상태에서 멈춤 증상 다음과 같은 메시지가 표시될 수 있습니다. Reason: NamespaceCreated Status: True Type: ObjectNamespaceReady Last Transition Time: 2024-07-12T00:49:29Z Message: awaiting images distribution to be finished Observed Generation: 1 Reason: VMImageDistributing Status: Unknown Type: Ready 이 문제는 새 조직의 S3 엔드포인트 구성이 누락되어 발생합니다. 해결 방법: 새 조직의 HA 그룹을 수동으로 만듭니다. 비상 모드 절차를 통해 다음 리소스에 대한 읽기 권한이 있는 루트 관리자 클러스터의 kubeconfig를 획득합니다. 조직 ObjectStorageAdminNode SubnetClaim ObjectStorageSite 보안 비밀 조직 이름을 확인합니다. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get Organization -A 루트 관리자 클러스터에서 ObjectStorageAdminNode CR의 클라이언트 IP 주소를 확인합니다. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get ObjectStorageAdminNode 각 AdminNode CR의 경우: kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get ObjectStorageAdminNode NODE_NAME -o jsonpath='{.spec.network.clientIP}' 사용 가능한 IP 주소 범위와 해당 범위 내의 예약된 IP를 확인합니다. kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get SubnetClaim -n root external-objectstorage-client-lif-subnet -o jsonpath='{.status.ipv4SubnetStatus}' 루트 관리자 클러스터의 gpc-system/objectstorage-breakglass-root-level1 보안 비밀에서 StorageGRID 관리 UI 로그인 사용자 인증 정보를 가져옵니다. 이전 단계의 사용자 인증 정보로 StorageGRID 관리 UI에 로그인합니다. URL이 ObjectStorageSite 상태입니다. kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get ObjectStorageSite -n gpc-system mb-obj-site-1 -o jsonpath='{.status.managementAPIEndpointURL}' 구성 탭으로 이동하여 고가용성 그룹을 클릭합니다. 각 HA 그룹의 세부정보 보기를 열고 가상 IP 주소 (VIP)를 기록합니다. 새 HA 그룹을 만듭니다. 그룹 이름: 이름 패턴은 ORGANIZATION_NAME-ha입니다. 이 경우 org-2-ha입니다. 그룹 설명: 설명 패턴에 기존 HA 그룹을 사용합니다. 인터페이스: 모든 eth2를 선택합니다. 우선순위 순서: 기본 인터페이스가 가장 높은 우선순위여야 합니다. SubnetCIDR: 이 필드는 StorageGRID에 의해 자동으로 채워집니다. 서브넷이 SubnetClaim external-objectstorage-client-lif-cidr의 status.ipv4SubnetStatus.cidrBlock과 일치하는지 확인합니다. 가상 IP: 사용 가능한 IP 범위의 다음 IP입니다. IP는 예약된 IP, 관리 노드의 클라이언트 IP, 기존 HA 그룹의 VIP와 충돌할 수 없습니다. StorageGRID 긴급 상황 시 사용자 인증 정보를 순환합니다.
업그레이드	1.12.4	하위 구성요소에서 지속적인 조정 증상 루트 조직을 1.12.2에서 1.12.4로 업그레이드하면 iac-gitlab 하위 구성요소의 조정 상태가 계속됩니다. 문제를 진단하려면 다음을 비롯한 Prometheus 로그를 확인하세요. kubectl logs gitlab-prometheus-server-5d6d9599f-l2l7s -n gitlab-system -c prometheus-server 로그에 다음과 같은 오류가 포함될 수 있습니다. unexpected fault address 0x7f217cf26000 fatal error: fault [signal SIGBUS: bus error code=0x2 addr=0x7f217cf26000 pc=0x46c302] goroutine 1 [running]: runtime.throw({0x3018bed?, 0x0?}) /usr/local/go/src/runtime/panic.go:992 +0x71 fp=0xc000a3b098 sp=0xc000a3b068 pc=0x438431 해결 방법: 예를 들어 실행 중인 컨테이너에서 셸을 가져오려면 sleep 3600을 실행합니다. kubectl exec --stdin --tty POD_NAME -n gitlab-system -c prometheus-server -- /bin/sh /prometheus $ df -h POD_NAME을 포드 이름으로 바꿉니다(예: gitlab-prometheus-server-d7969c968-hppsl). 출력을 확인하여 /data 폴더가 가득 찼는지 확인합니다. Filesystem Size Used Available Use% Mounted on overlay 866.4G 147.1G 719.3G 17% / tmpfs 64.0M 0 64.0M 0% /dev tmpfs 94.3G 0 94.3G 0% /sys/fs/cgroup/dev/mapper/luks-trident_pvc_6fb4dc48_72df_4bf1_825f_267818e3fefd 7.8G 7.3G 0 100% /data 업그레이드 중에 이 문제가 발생하면 3600초의 시간 제한이 있으므로 이전 작업을 삭제한 후 업그레이드를 진행합니다. kubectl delete job gitlab-migrations-1-fe7-2 -n gitlab-system
업그레이드	1.12.4	IAM 사전 확인 실패 증상 문제를 진단하려면 IAM 업그레이드 로그를 확인하세요(예:). kubectl logs -n gpc-system upgrade-managed-check-iamupgrade-qbdm5-tl264 출력은 다음과 같이 표시될 수 있습니다. I0724 21:57:20.456782 1 upgrade_check.go:39] IAM preflight check failed after 60000000000: Org iam-system deployments not ready: Deployment iam-authzpdp-backend-server is not ready; ready replicas 2,replicas 3 해결 방법: 이전 오류 메시지를 참조하여 배포의 네임스페이스와 이름을 확인합니다. 이 예시에서 NAME은 iam-authzpdp-backend-server이고 NAMESPACE은 iam-system입니다. 포드 목록을 가져옵니다. kubectl get pods -n NAMESPACE | grep NAME 결과는 다음 형식으로 표시됩니다. iam-authzpdp-backend-server-6875654c4b-64h4t 2/2 Running 0 29h iam-authzpdp-backend-server-6875654c4b-pvscg 1/2 Running 0 29h iam-authzpdp-backend-server-6875654c4b-v7jnl 2/2 Running 0 29h 모든 컨테이너가 준비되지 않은 포드를 확인합니다. 이 경우 POD_NAME은 iam-authzpdp-backend-server-6875654c4b-pvscg이며, 1/2 상태로 표시된 두 컨테이너 중 하나가 준비되지 않았습니다. 이와 같은 포드가 두 개 이상인 경우 영향을 받는 각 포드에 대해 다음 단계를 반복합니다. 완전히 정상 상태가 아닌 포드를 삭제합니다. kubectl delete pod -n NAMESPACE POD_NAME> 2단계의 명령어를 다시 실행합니다. 이제 모든 포드가 정상 상태여야 합니다. 이 단계는 몇 분 정도 걸릴 수 있습니다. 삭제된 포드가 정상 포드로 대체되지 않으면 지원 티켓을 여세요.
업그레이드	1.12.1 1.12.2 1.12.4	OrganizationUpgrade 상태가 Unknown입니다. 증상 업그레이드가 완료되면 OrganizationUpgrade 상태가 Unknown이 됩니다. 해결 방법: Organization의 버전 필드가 targetVersion 필드와 일치하면 '알 수 없음' 상태를 무시해도 됩니다.
업그레이드	1.12.4	opa gatekeeper의 하위 구성요소 업그레이드 실패 증상 테넌트 조직을 1.12.2에서 1.12.4로 업그레이드하는 동안 opa gatekeeper 하위 구성요소 업그레이드가 ReconciliationError로 실패합니다. 해결 방법: 영향을 받는 사용자 클러스터의 mutatingwebhookconfiguration 객체 edr-sidecar-injector-webhook-cfg을 수정합니다. 영향을 받는 사용자 클러스터가 두 개 이상인 경우 영향을 받는 각 사용자 클러스터에 대해 단계를 반복합니다. kubectl edit mutatingwebhookconfiguration edr-sidecar-injector-webhook-cfg webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values 섹션을 수정하여 다음 두 값을 추가합니다. opa-system cert-manager 업데이트된 객체는 다음과 같습니다. apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration ... webhooks: - admissionReviewVersions: name: edr-sidecar-injector.gpc-system.internal namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: - kube-system - opa-system - cert-manager ... 문제를 해결하는 데 최대 1시간이 걸릴 수 있습니다.
업그레이드	1.12.4	클러스터 업그레이드의 일부로 ansibleplaybook이 업그레이드되지 않음 증상 1.12.2에서 1.12.4로 업그레이드할 때 ansibleplaybook는 클러스터 업그레이드의 일부로 업그레이드되지 않습니다. ansibleplaybook에서 업데이트된 수정사항이 적용되지 않아 이전 버전의 ansibleplaybook를 실행하는 os-policy가 차단됩니다. 해결 방법: create-ansible-playbooks Kubernetes 작업을 삭제합니다. JOB_NAME=create-ansible-playbooks-xxx JOB_NAMESPACE=xxx kubectl delete job $JOB_NAME -n JOB_NAMESPACE --kubeconfig=/path/to/admin-cluster-config os-core-controller 배포를 다시 시작합니다. 이 작업은 작업을 다시 트리거하고 플레이북을 업데이트합니다.
DNS	1.12.4	루트 관리자 노드로의 DNS 트래픽이 만료되어 조직 생성이 실패함 증상 새 조직을 만들 때 로그에 core-dns 하위 구성요소의 시간이 초과될 수 있습니다. [INFO] 192.0.2.0:60741 - 40400 "A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232" - - 0 2.000828817s [ERROR] plugin/errors: 2 objectstorage-tenant-mgmt.gdch.example.com. A: read udp 10.244.4.184:59927->192.0.2.1:53: i/o timeout [INFO] 192.0.2.0:51401 - 5813 "AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232" - - 0 2.000585231s [ERROR] plugin/errors: 2 objectstorage-tenant-mgmt.gdch.example.com. AAAA: read udp 10.244.4.184:48542->192.0.2.1:53: i/o timeout 해결 방법: 루트 관리자 클러스터의 gpc-coredns-forwarder-udp 서비스와 gpc-coredns-forwarder-tcp 서비스를 업데이트하고 부하 분산기 소스 범위에 새 IP 범위를 추가합니다. CR 변경사항이 재정의되면 lcm.private.gdc.goog/paused="true" 주석으로 dns-core 하위 구성요소를 일시중지합니다.
파일 및 블록 스토리지	1.12.4	루트 클러스터에서 file-netapp-trident 하위 구성요소가 실패함 증상 1.12.2에서 1.12.4로 업그레이드할 때 file-netapp-trident 하위 구성요소가 StorageClasses 삭제에 멈춰 있습니다. 다음 상태가 표시됩니다. status: backendStatus: conditions: - lastTransitionTime: "2024-05-02T06:04:14Z" message: 'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found' observedGeneration: 2 reason: ReconciliationError status: "True" type: Reconciling - lastTransitionTime: "2024-04-08T00:12:53Z" message: Successfully pulled chart observedGeneration: 2 reason: ChartPullDone status: "True" type: ChartPull - lastTransitionTime: "2024-05-01T10:10:08Z" message: Fetched parameters from default, runtime observedGeneration: 2 reason: 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: 2 reason: DeployError status: "False" type: Deployed - lastTransitionTime: "2024-04-23T06:50:12Z" message: Readiness check job passed observedGeneration: 1 reason: ReadinessCheckDone status: "True" type: Ready deploymentFinished: false lastDeployTimestamp: "2024-05-02T06:03:16Z" readyAfterDeploy: true version: "" conditions: - lastTransitionTime: "2024-05-02T06:04:14Z" message: 'Reconciliation error: E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found' observedGeneration: 2 reason: ReconciliationError status: "True" type: Reconciling crdsStatus: conditions: - lastTransitionTime: "2024-04-07T08:02:33Z" message: Successfully pulled chart observedGeneration: 2 reason: ChartPullDone status: "True" type: ChartPull - lastTransitionTime: "2024-04-07T08:02:33Z" message: No parameters to fetch observedGeneration: 2 reason: ParametersDone status: "True" type: Parameters - lastTransitionTime: "2024-04-07T08:02:34Z" message: Readiness source is empty observedGeneration: 2 reason: ReadinessCheckSkipped status: "True" type: Ready - lastTransitionTime: "2024-05-01T18:37:52Z" message: Ready observedGeneration: 2 reason: ReconciliationCompleted status: "False" type: Reconciling deploymentFinished: true lastDeployTimestamp: "2024-05-02T06:04:03Z" readyAfterDeploy: true version: 1.12.3-gdch.312 해결 방법: file-netapp-trident 하위 구성요소를 일시중지합니다. ## Set KUBECONFIG to root-admin KUBECONFIG export KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent file-netapp-trident -n $cluster_namespace lcm.private.gdc.goog/paused=true 작업에서 생성하지 못한 StorageClasses(예: standard-rwo, standard-block, standard-rwo-non-luks, standard-block-non-luks)를 삭제합니다. kubectl delete storageclass $(kubectl get storageclasses -o jsonpath='{.items[?(@.provisioner=="csi.trident.netapp.io")].metadata.name} 클러스터의 oclcm-backend-controller를 다시 시작하여 StorageClasses 재생성을 트리거합니다(루트 및 조직 관리자 클러스터의 경우 root-admin 컨트롤러, 시스템 및 사용자 클러스터의 경우 org-admin 컨트롤러). kubectl rollout restart deployment oclcm-cm-backend-controller -n oclcm-system 클러스터에서 netapp-trident 배포와 netapp-trident DaemonSet을 다시 시작합니다. kubectl rollout restart deployment netapp-trident-controller -n netapp-trident kubectl rollout restart daemonset netapp-trident-node-linux -n netapp-trident PersistentVolumeClaim (PVC) 리소스에 LUKS 보안 비밀이 생성되었는지 확인합니다. 모든 PVC에는 g-luks-$pvc_name 형식의 비밀이 있어야 합니다. kubectl get secret -n $pvc_namespace g-luks-$pvc_name file-netapp-trident 하위 구성요소의 상태에 오류가 없는지 확인합니다. kubectl get subcomponent -n $cluster_namespace file-netapp-trident -o jsonpath='{.status}' | jq 참고: 메시지와 `backendStatus`에 오류가 없어야 합니다. `crdStatus` 에 `delpoymentFinished: true`가 표시되어야 합니다. 재정의가 적용되도록 하위 구성요소를 일시중지 해제합니다.
물리적 서버	1.12.4	서버 부트스트랩 실패 증상 서버를 부트스트랩할 때 베어 메탈 로그에 다음과 같은 메시지가 표시될 수 있습니다. Conditions: Last Transition Time: 2024-08-12T17:10:23Z Message: Introspection timeout Observed Generation: 2 Reason: FailedProvision Status: True Type: BaremetalFailure Last Transition Time: 2024-08-10T12:23:30Z Message: Observed Generation: 2 Reason: KeyManagerConfigurationSucceeded Status: True Type: KeyManagerConfigured Last Transition Time: 2024-08-10T12:11:17Z Message: The server is powered off or unknown Observed Generation: 2 Reason: NotPoweredOn Status: False Type: Ready 해결 방법: 각 멈춤 단계에 대해 다음 런북의 안내를 따르세요. SERV-R0006 SERV-R0007 SERV-R0008 문제가 아직 해결되지 않았다면 SERV-R0001 런북의 단계를 따르세요. 문제가 계속 해결되지 않으면 지원 티켓을 여세요.
업그레이드	1.12.0 1.12.1 1.12.2 1.12.4	업그레이드 중에 기본 Prometheus 포드가 정리되지 않음 증상 primary-prometheus-shardX-replicaX 포드는 obs-system 네임스페이스와 mon-system 네임스페이스에 표시됩니다. 1.12 업그레이드 후 primary-prometheus-shardX-replicaX가 obs-system 네임스페이스에만 있는 경우 다른 알 수 없는 문제이므로 해결 방법을 실행하면 안 됩니다. 의도된 동작은 1.12 업그레이드가 완료된 후 primary-prometheus-shardX-replicaX가 mon-system 네임스페이스에만 존재하는 것입니다. 해결 방법: obs-system 네임스페이스에서 primary-prometheus-shardX-replicaX StatefulSet을 수동으로 삭제합니다. mon-system 네임스페이스에서 primary-prometheus-shardX-replicaX StatefulSet을 삭제하지 마세요.
네트워킹	1.12.4	ClusterCIDRConfig가 생성되었지만 PodCIDR이(가) 노드에 할당되지 않음 증상 ClusterCIDRConfig는 PodCIDRs를 할당하는 데 필요한 객체입니다. ClusterCIDRConfig가 생성되었지만 PodCIDRs가 할당되지 않았습니다. 이 문제는 ipam-controller 포드가 부트스트랩될 때와 동시에 ClusterCIDRConfig가 생성되는 경우 발생합니다. 클러스터 생성이 조정 상태에서 멈춰 있습니다. ClusterCIDRConfig 객체가 클러스터에 생성되었는지 확인합니다. kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml 출력은 다음과 같이 표시될 수 있습니다. apiVersion: v1 items: - apiVersion: networking.gke.io/v1alpha1 kind: ClusterCIDRConfig metadata: annotations: baremetal.cluster.gke.io/managed: "true" kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"networking.gke.io/v1alpha1","kind":"ClusterCIDRConfig","metadata":{"annotations":{"baremetal.cluster.gke.io/managed":"true"},"creationTimestamp":null,"name":"root-admin-control-plane"},"spec":{"ipv4":{"cidr":"172.24.0.0/21","perNodeMaskSize":23},"ipv6":{"cidr":"fd00:1::2:0/112","perNodeMaskSize":119}},"status":{}} creationTimestamp: "2024-06-17T05:27:55Z" finalizers: - networking.kubernetes.io/cluster-cidr-config-finalizer generation: 1 name: root-admin-control-plane resourceVersion: "2172" uid: d1216fe3-04ed-4356-a105-170d72d56c90 spec: ipv4: cidr: 172.24.0.0/21 perNodeMaskSize: 23 ipv6: cidr: fd00:1::2:0/112 perNodeMaskSize: 119 kind: List metadata: resourceVersion: "" 조정 중에 멈춘 클러스터의 노드 객체 중 하나에 대해 describe를 실행하고 노드 객체에 CIDRNotAvailable 이벤트가 있는지 확인합니다. kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME 출력 이벤트는 다음과 같이 표시될 수 있습니다. Type Reason Age From Message ---- ------ ---- ---- ------- Normal CIDRNotAvailable 3m22s (x96 over 21h) cidrAllocator Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable Warning ReconcileError 3m22s (x96 over 21h) ipam-controller CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs 해결 방법: ipam-controller-manager 포드를 다시 시작합니다. kubectl --kubeconfig=CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager ipam-controller-manager 포드가 실행 중 상태가 되면 podCIDR이 노드에 할당되었는지 확인합니다. kubectl --kubeconfig=CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR 출력은 다음과 같이 표시될 수 있습니다. podCIDR: 172.24.4.0/23 podCIDRs: podCIDR: 172.24.2.0/23 podCIDRs: podCIDR: 172.24.0.0/23 podCIDRs:
Vertex AI	1.12.0 1.12.1 1.12.2 1.12.4	사전 학습된 API가 사용자 인터페이스에 Enabling 상태를 표시함 사용자 클러스터가 생성될 때 MonitoringTarget에 Not Ready 상태가 표시되어 사전 학습된 API가 사용자 인터페이스에 Enabling 상태를 계속 표시합니다. 해결 방법: Chrome 브라우저에서 메뉴 (점 3개 아이콘)를 엽니다. 도구 더보기 > 개발자 도구를 클릭하여 콘솔을 엽니다. 콘솔에서 네트워크 탭을 클릭합니다. ai-service-status 요청을 찾습니다. ai-service-status 요청에서 응답 탭을 클릭하여 해당 요청의 콘텐츠를 표시합니다. MonitoringTarget 및 LoggingTarget 구성요소를 제외한 모든 항목이 준비되었는지 확인합니다.
객체 스토리지	1.12.4	일부 객체 스토리지 업그레이드 경고는 무시할 수 있음 증상 객체 스토리지를 업그레이드할 때 다음과 같은 경고가 표시될 수 있습니다. Type Reason Age From Message ---- ------ ---- ---- ------- Warning ReconcileError 55m (x2 over 55m) ObjectStorageAdminNodeReconciler Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked 해결 방법: 각 노드에 해당하는 SSH 사용자 인증 정보가 비밀에 저장되어 있는지 확인합니다. 관리 노드를 확인합니다. kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done 스토리지 노드를 확인합니다. kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done 스토리지 노드의 경우 성공적인 출력은 다음 예와 같습니다. NAME TYPE DATA AGE gpcstgecn01-gce-gpcstgesite01-ssh-creds Opaque 2 3d23h NAME TYPE DATA AGE gpcstgecn02-gce-gpcstgesite01-ssh-creds Opaque 2 3d23h NAME TYPE DATA AGE gpcstgecn03-gce-gpcstgesite01-ssh-creds Opaque 2 3d23h 보안 비밀을 찾을 수 없는 경우 오류는 다음과 같습니다. Error from server (NotFound): secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found 명령어가 오류를 반환하지 않으면 조정기에서 보고한 오류를 무시해도 됩니다.
Vertex AI	1.11.x 1.12.x	번역 프런트엔드 포드 및 서비스가 초기화되지 않음 증상 업그레이드 중에 Translation DB 클러스터가 다시 생성되어 ODS 시스템 클러스터 secret-store 비밀번호가 오래되고 동기화되지 않습니다. 따라서 번역 프런트엔드 포드와 서비스가 초기화에 실패합니다. 해결 방법: 시스템 클러스터에서 보안 비밀을 삭제합니다. kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system SYSTEM_CLUSTER_KUBECONFIG를 시스템 클러스터의 kubeconfig 파일 경로로 바꿉니다. 컨트롤러가 보안 비밀을 자동으로 다시 만들고 DB 클러스터와 다시 동기화합니다.
물리적 서버	1.12.4	서버가 키 관리자에 연결할 수 없음 증상 서버가 키 관리자에 연결할 수 없어 서버 상태를 사용할 수 없게 됩니다. 이 문제로 인해 server-encrypt-and-create-logical-drive 작업이 실패하고 관리자 클러스터가 준비되지 않습니다. 작업 로그에 다음과 같은 오류가 표시될 수 있습니다. Error: Error during command execution: ansible-playbook error: one or more host failed Command executed: /usr/local/bin/ansible-playbook --extra-vars {"server_generation":"gen10","ssa_crypto_pwd":"vf{kXgbL?VFcV]%0","ssa_master_key":"ten-admin-org-2"} --inventory 192.0.2.0, --private-key /etc/ssh-key/id_rsa --become serve r/encrypt_and_create_logical_drive.yaml exit status 2 해결 방법: AuxCycle을 실행하고 iLO가 키 관리자에 연결할 수 있는지 확인합니다.
로깅	1.12.4	미리 쓰기 로그가 영구 볼륨을 채움 증상 Loki에는 WAL (Write-Ahead Log)과 색인 모두에 대해 하나의 영구 볼륨 (PV)만 있습니다. Loki 포드가 몇 시간 동안 스토리지 버킷에 연결할 수 없는 경우 WAL이 PV를 채울 수 있습니다. PV에 남은 공간이 없으면 PV를 삭제하고 StatefulSet를 다시 시작하지 않는 한 Loki가 복구할 수 없습니다. 해결 방법: 이 상태에서 Loki 포드를 복구하려면 해당 StatefulSet를 축소하고 공간이 남지 않은 PV를 삭제해야 합니다. 주의: 이 작업의 직접적인 결과로 스토리지 버킷으로 전송되지 않은 WAL에 현재 있는 로그가 영구적으로 손실됩니다. Loki 포드를 복구하려면 다음 단계를 따르세요. IO 도구 컨테이너가 워크스테이션에 설치되어 있는지 확인합니다. 자세한 내용은 OOPS-P0065 작업 설명서를 참고하세요. 리소스를 수정하는 데 필요한 권한을 얻으려면 보안 관리자에게 다음 역할을 부여해 달라고 요청하세요. observability-viewer observability-admin 루트 관리자 클러스터의 kubeconfig 파일 경로로 KUBECONFIG 환경 변수를 설정합니다. 자세한 내용은 IAM-R0004 런북을 참고하세요. 영향을 받는 조직의 이름으로 ORG_NAME 환경 변수를 설정합니다. 다음 콘텐츠를 log-admin-overrides.yaml이라는 YAML 파일에 저장합니다. apiVersion: lcm.private.gdc.goog/v1 kind: SubcomponentOverride metadata: name: log-admin-overrides spec: subComponentRef: log-admin backend: operableParameters: controller: disableReconcilers: "LoggingPipelineReconciler" LoggingPipelineReconciler를 사용 중지합니다. kubectl apply -f log-admin-overrides.yaml -n ${ORG_NAME} 영향을 받는 Loki 포드가 실행되는 클러스터의 kubeconfig 파일 경로로 KUBECONFIG 환경 변수를 설정합니다. 자세한 내용은 IAM-R0004 런북을 참고하세요. 영향을 받는 Loki 포드의 이름으로 LOKI_POD_NAME 환경 변수를 설정합니다. Loki StatefulSet 이름을 가져옵니다. export LOKI_STATEFULSET_NAME=$(kubectl get pod $LOKI_POD_NAME -n obs-system -o json | jq -r '.metadata.labels.app') Loki PVC 이름을 가져옵니다. export LOKI_PVC_NAME=$(kubectl get pod $LOKI_POD_NAME -n obs-system -o json | jq -r '.spec.volumes[] | select(.persistentVolumeClaim != null) | .persistentVolumeClaim.claimName') Loki StatefulSet 복제본을 가져옵니다. export LOKI_STATEFULSET_REPLICAS=$(kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system -o json | jq -r '.status.replicas') Loki StatefulSet를 축소합니다. kubectl scale statefulset $LOKI_STATEFULSET_NAME -n obs-system --replicas=0 실행 중인 StatefulSet 포드가 없는지 확인합니다. kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system 출력은 다음 예시와 같이 표시되어야 합니다. NAME READY AGE audit-logs-loki-io 0/0 4d3h 영향을 받는 PVC를 삭제합니다. kubectl delete pvc $LOKI_PVC_NAME -n obs-system Loki StatefulSet를 확장합니다. kubectl scale statefulset $LOKI_STATEFULSET_NAME -n obs-system --replicas=${LOKI_STATEFULSET_REPLICAS} 영향을 받는 조직의 관리 클러스터에 있는 kubeconfig 파일의 경로로 KUBECONFIG 환경 변수를 설정합니다. 자세한 내용은 IAM-R0004 런북을 참고하세요. log-admin-overrides.yaml YAML 파일의 콘텐츠를 다음과 같이 수정합니다. apiVersion: lcm.private.gdc.goog/v1 kind: SubcomponentOverride metadata: name: log-admin-overrides namespace: root spec: subComponentRef: log-admin backend: operableParameters: controller: disableReconcilers: "" LoggingPipelineReconciler를 사용 설정합니다. kubectl apply -f log-admin-overrides.yaml -n ${ORG_NAME} 모든 StatefulSet 포드가 실행 중이고 정상 상태인지 확인합니다. kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system 출력은 다음 예시와 같이 표시되어야 합니다. NAME READY AGE audit-logs-loki-io 5/5 2d5h 이 경우 StatefulSet에는 5개 중 5개 (5/5)의 복제본이 있습니다.
업그레이드	1.12.4	작업이 계속 예약됨 증상 작업이 계속해서 예약됩니다. 작업이 종료되는 즉시 새 작업이 예약됩니다. 계속 예약되는 작업은 다음과 같습니다. unet-networkpolicy-assets-parameter unet-nodenetworkpolicy-assets-parameter unet-nodenetworkpolicy-assets-readiness unet-userclusterpolicy-assets-parameter unet-clustermesh-backend-parameter unet-clustermesh-backend-readiness 해결 방법: 다음 하위 구성요소를 일시중지합니다. unet-networkpolicy unet-nodenetworkpolicy unet-nodenetworkpolicy unet-userclusterpolicy unet-clustermesh 루트 관리자 클러스터의 fleet-info 보안 비밀이 변경될 때마다 하위 구성요소를 일시중지 해제합니다. 이 문제는 kr get managementswitches -A와 같은 인스턴스의 관리 스위치가 변경되거나 조직 네임스페이스의 cidrclaim이 변경될 때 발생합니다. 조직 관리자 클러스터의 NodePool 리소스가 변경될 때마다 하위 구성요소를 일시중지 해제합니다. 시작하기 전에 하위 구성요소를 일시중지 해제하세요.
업그레이드	1.12.4	ServiceNow의 정상 업스트림을 사용할 수 없음 증상 1.12.2에서 1.12.4로 업그레이드할 때 ServiceNow의 정상적인 업스트림을 사용할 수 없습니다. failed to stage volume: LUKS passphrase cannot be empty 메시지가 표시될 수 있습니다. system-performance-rwo 스토리지 클래스가 LUKS에 사용 설정되어 있지 않습니다. 볼륨 연결은 PVC가 LUKS 사용 설정되었음을 나타냅니다. 조정자는 LUKS 비밀번호가 있는 비밀을 검색합니다. 볼륨 연결에서 LUKS가 사용 설정되었다고 표시되고 스토리지 클래스에서는 LUKS가 사용 설정되지 않았으므로 보안 비밀 암호가 생성되지 않습니다. 해결 방법: 문제가 표시되는 루트 또는 조직 관리자 클러스터의 Kubeconfig을 가져옵니다. export KUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG} system-performance-rwo 스토리지 클래스를 삭제하고 다시 만듭니다. kubectl delete storageclass system-performance-rwo kubectl apply -f system-performance-rwo.yaml system-performance-rwo 스토리지 클래스의 새 yaml을 만들고 LUKS를 사용 설정합니다. # kubectl get sc system-performance-rwo -o yaml allowVolumeExpansion: true apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: disk.gdc.goog/luks-encrypted: "true" helm.sh/resource-policy: keep lcm.private.gdc.goog/claim-by-force: "true" meta.helm.sh/release-name: file-netapp-trident-backend meta.helm.sh/release-namespace: netapp-trident storageclass.kubernetes.io/is-default-class: "false" labels: app.kubernetes.io/managed-by: Helm name: system-performance-rwo parameters: backendType: ontap-san csi.storage.k8s.io/node-expand-secret-name: g-luks-${pvc.name} csi.storage.k8s.io/node-expand-secret-namespace: ${pvc.namespace} csi.storage.k8s.io/node-publish-secret-name: g-luks-${pvc.name} csi.storage.k8s.io/node-publish-secret-namespace: ${pvc.namespace} csi.storage.k8s.io/node-stage-secret-name: g-luks-${pvc.name} csi.storage.k8s.io/node-stage-secret-namespace: ${pvc.namespace} fsType: ext4 selector: tier=performance provisioner: csi.trident.netapp.io reclaimPolicy: Delete volumeBindingMode: Immediate
업그레이드	1.12.4	file-netapp-trident 하위 구성요소 업그레이드의 상태가 Reconciliation ongoing입니다. 증상 file-netapp-trident 하위 구성요소의 상태가 Reconciling에서 ReconciliationCompleted로 앞뒤로 전환될 수 있습니다. 해결 방법: 다음 조건이 충족되면 진행 중인 조정은 무시해도 됩니다. TridentBackend은 online입니다. TridentBackend 구성은 bound입니다. netapp-trident-controller 배포가 정상입니다. netapp-trident-node-linux DaemonSet이 정상입니다.
업그레이드	1.12.4	시스템 클러스터 작업자 노드 업그레이드 시 manifest과 snapshot 간의 델타가 생성되지 않음 증상 1.12.2에서 1.12.4로 업그레이드할 때 조직 업그레이드가 NodeUpgrade 단계에서 중단되고 노드 업그레이드 작업에 다음 오류가 표시됩니다. Message: failed to generate delta between manifest and snapshot: failed to create or update delta configmap: failed to calculate delta between snapshot and manifest: failed to get valid OS distribution for delta comparison, distribution: 문제를 확인하려면 다음 단계를 실행하세요. 노드 업그레이드가 실패하는 루트 또는 조직 관리자 클러스터의 Kubeconfig를 가져와서 nodeupgradetask가 실패했는지 확인합니다. export KUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG} kubectl get nodeupgradetask -A -ojsonpath='{.items[*].status.conditions[?(@.status != "True")]}' | jq 메시지가 이전 오류 메시지와 일치하는지 확인합니다. Message: failed to generate delta between manifest and snapshot: failed to create or update delta configmap: failed to calculate delta between snapshot and manifest: failed to get valid OS distribution for delta comparison, distribution: osartifactsnapshot에 누락된 배포가 있는지 확인합니다. kubectl get osartifactsnapshots.system.private.gdc.goog -A -o json | jq '.items[] | select(.status.distribution == "") | .metadata.name' 배포가 설정되지 않은 스냅샷이 하나 이상 인쇄되었는지 확인합니다. 해결 방법: 노드가 속한 클러스터의 Kubeconfig를 가져옵니다. export KUBECONFIG=${CLUSTER_KUBECONFIG} kubectl rollout restart -n os-system os-core-controller 스냅샷에 이제 분포가 있는지 확인합니다. (이 명령어는 몇 분 정도 걸릴 수 있습니다.) kubectl get osartifactsnapshots.system.private.gdc.goog -A -o json | jq '.items[] | select(.status.distribution == "") | .metadata.name' 이 명령어는 결과를 반환하지 않아야 합니다. 누락된 배포가 계속 표시되면 지원 요청을 제출하세요.
업그레이드	1.12.4	kubelet이 스팸 로그가 있는 포드의 cgroup를 삭제하지 못함 증상 kubelet에서 다음 스팸 로그를 계속 출력합니다. May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="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" …… May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="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" runc init 프로세스가 고정되어 kubelet가 cgroup 포드를 삭제할 수 없습니다. 해결 방법: 다음 스크립트를 사용하여 cgroup 삭제를 차단하는 프로세스를 찾습니다. # Find matching cgroup directories MATCHING_CGROUPS=$(find /sys/fs/cgroup -type d -name "*74353c*") if [ -z "$MATCHING_CGROUPS" ]; then echo "No cgroups found containing 'd06aac'." exit 0 fi echo "Matching cgroups:" for cgroup in $MATCHING_CGROUPS; do echo "- $cgroup" # Print cgroup path # Check if cgroup.procs exists if [ -f "$cgroup/cgroup.procs" ]; then echo " Processes:" # List PIDs in cgroup.procs for pid in $(cat "$cgroup/cgroup.procs"); do # Get process details ps -o pid,comm,cmd --no-headers $pid 2>/dev/null # Suppress errors if process doesn't exist done else echo " No cgroup.procs file found." # Handle cases where cgroup.procs is missing fi echo # Add a newline for better readability done cat freezer.state를 사용하여 냉장고 상태를 확인합니다. 상태는 FROZEN이어야 합니다. 에코 "THAWED" > freezer.state cgroup이(가) 삭제되었습니다. Kubelet가 로그 스팸을 중지합니다.
성능	1.12.4	조정 오류가 있는 하위 구성요소 perf-ptaas 증상 perf-ptaas 하위 구성요소에 다음 오류 코드가 표시되어 PTaaS 배포가 차단됩니다. Reconciliation error: E0100 - deploy: failed to transfer ownership of conflicting resources for install: these resources need to be force claimed, but they are not annotated: [Resource: "resourcemanager.gdc.goog/v1, Resource=projects", GroupVersionKind: "resourcemanager.gdc.goog/v1, Kind=Project" 해결 방법: PTaaS는 gdchservices 조직에 배포됩니다. perftest 네임스페이스 gdch-perftest에서 PTaaS 프로젝트 gdch-perftest 및 버킷 perftest-bucket-reports의 주석과 라벨을 검사합니다. 버킷에 라벨 app.kubernetes.io/managed-by=Helm 및 주석 meta.helm.sh/release-name=perf-ptaas-assets, meta.helm.sh/release-namespace=gdch-perftest이 누락되었을 수 있습니다. 다음 라벨과 주석을 수동으로 추가합니다. kubectl --kubeconfig gdchservices-admin-kubeconfig label buckets -n gdch-perftest perftest-bucket-reports app.kubernetes.io/managed-by=Helm kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports meta.helm.sh/release-name=perf-ptaas-assets kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports meta.helm.sh/release-namespace=gdch-perftest OCLCM이 버킷을 강제로 클레임하는지 확인합니다. kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports lcm.private.gdc.goog/claim-by-force=true PTaaS 프로젝트 gdch-perftest의 주석을 검사합니다. 프로젝트가 meta.helm.sh/release-name=perf-ptaas-assets 주석으로 잘못 구성되었을 수 있습니다. 이 주석을 meta.helm.sh/release-name=perf-ptaas-backend로 변경합니다. kubectl --kubeconfig gdchservices-admin-kubeconfig annotate projects -n gpc-system gdch-perftest meta.helm.sh/release-name=perf-ptaas-backend --overwrite=true OCLCM이 프로젝트를 강제로 소유하는지 확인합니다. kubectl --kubeconfig gdchservices-admin-kubeconfig annotate projects -n gpc-system gdch-perftest lcm.private.gdc.goog/claim-by-force=true 하위 구성요소가 루트 관리자 클러스터에서 조정되는지 확인합니다. kubectl get subcomponent -n gdchservices perf-ptaas