이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Google Distributed Cloud(에어 갭 적용형) 1.14.x 알려진 문제

백업 및 복원

클러스터 백업 복원 계획 수정이 작동하지 않음

버전: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

증상

RestorePlan 커스텀 리소스는 GDC 콘솔을 사용하여 수정할 수 없습니다.

해결 방법:

새 복원 계획을 만들고 이전 복원 계획을 삭제하거나 kubectl CLI를 사용하여 복원 계획을 수정합니다.

잘못된 소스 디스크 크기

버전: 1.14.4, 1.14.5

증상: v2 조직 아키텍처로 마이그레이션한 후 백엔드 데이터 모델이 변경되어 UI에 디스크 크기가 0MB로 표시되고 생성 시간이 '알 수 없음'으로 표시됩니다.

해결 방법: UI를 통해 이 정보를 볼 수 있는 대체 방법은 없습니다.

메모리 부족으로 인해 에이전트 및 컨트롤 플레인 포드가 다시 시작됨

버전: 1.14.3, 1.14.4

증상: 메모리가 부족하면 에이전트 및 컨트롤 플레인 포드가 다시 시작될 수 있습니다.

해결 방법: BACK-R0005 런북의 안내에 따라 컨트롤 플레인 및 에이전트 포드의 메모리를 늘립니다. 포드의 메모리를 2GiB로 늘립니다.

백업 및 복원 SLO가 적용되지 않음

버전: 1.14.3, 1.14.4

증상: 필요한 커스텀 리소스 정의가 설치되어 있지 않으므로 GDC 서비스 수준 목표(SLO) 측정항목과 알림이 기본적으로 구성되지 않습니다. 이러한 알림은 Grafana에서 사용됩니다.

해결 방법: GDC에서 백업 및 복원에 대해 SLO를 사용 설정하려면 BACK-T0001 런북을 따르세요.

가져온 백업에는 보관 정책이 적용되지 않음

버전: 에어 갭이 적용된 모든 버전의 Google Distributed Cloud(GDC)가 영향을 받을 수 있습니다.

증상: 클러스터에 백업 저장소를 연결하면 모든 백업 및 복원 메타데이터가 동기화되고 저장소가 가져온 백업으로 처리됩니다. 이러한 가져온 백업은 조정 중에 잘못 건너뛰어지므로 보관 정책이 무시되고 백업이 무기한 보관됩니다.

해결 방법: 가져온 백업에는 backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME 라벨이 지정됩니다. 정상적인 조정과 보관 정책 적용을 허용하려면 다음 kubectl 명령어를 사용하여 백업에서 라벨을 삭제합니다.

필수 환경 변수를 설정합니다.
```
export KUBECONFIG=KUBECONFIG
export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
export NAMESPACE=BACKUP_PLAN_NAMESPACE
```
다음을 바꿉니다.
- KUBECONFIG: kubeconfig 파일의 경로
- BACKUP_REPOSITORY_NAME: 백업 저장소의 이름
- NAMESPACE: 백업 계획이 포함된 네임스페이스

가져온 모든 백업을 나열합니다.

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

필요에 따라 라벨을 삭제합니다.

모든 백업에서 라벨을 삭제합니다.

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

단일 백업의 라벨을 삭제합니다.

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

부분 VM 백업 실패

버전: 1.14.3, 1.14.4

증상: 여러 VM 중 하나의 VM이 백업되지 않으면 전체 VM 백업이 실패로 표시됩니다.

해결 방법: 백업 계획당 VM 수를 제한합니다.

사용자 또는 서비스 클러스터 삭제 후 고아 백업 리소스 정리

버전: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

증상: 사용자 또는 서비스 클러스터를 삭제하면 조직 인프라 및 관리 클러스터에서 생성된 연결된 백업 에이전트 리소스 (예: StatefulSet, 포드, 비밀 등)가 자동으로 정리되지 않습니다. 이 경우 고아 리소스가 남을 수 있으며 동일한 이름으로 클러스터를 다시 만들면 백업 에이전트 포드가 작동하지 않습니다.

해결 방법: 고아 리소스는 조직 인프라 클러스터의 전용 네임스페이스에 있습니다. 이를 정리하려면 이 네임스페이스를 삭제해야 합니다.

조직 인프라 및 관리 클러스터의 kubeconfig 파일을 설정합니다.

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

고아 리소스의 네임스페이스를 식별합니다. 네임스페이스는 gpc-backup-<cluster-name>-system 패턴을 따릅니다. 예를 들면 다음과 같습니다.
- gpc-backup-user-vm-1-cluster-system
- gpc-backup-user-vm-2-cluster-system
- gpc-backup-g-org-1-shared-service-cluster-system

네임스페이스를 삭제합니다. 이렇게 하면 인프라의 백업 에이전트 StatefulSet 및 포드와 관리 클러스터의 보안 비밀을 비롯한 모든 리소스가 삭제됩니다.

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

정리가 완료되었는지 확인하려면 get all 명령어를 다시 실행합니다.
```
# Replace <namespace-name> with the actual namespace
kubectl get all -n <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl get all -n <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
```
이제 네임스페이스가 더 이상 존재하지 않으므로 명령어가 실패해야 합니다. Error from server (NotFound): namespaces "<namespace-name>" not found과 같은 오류가 표시됩니다.

CLI 또는 UI를 통한 VirtualMachineRestore 삭제가 지원되지 않음

버전: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

증상: VirtualMachineRestore 리소스 삭제 시 VirtualMachineRestore 컨트롤러가 기본 리소스 (VolumeRestore, Restore)를 자동으로 정리하지 않습니다. 이 경우 수동으로 정리해야 합니다. 이는 kubectl delete를 사용하여 삭제하든 UI를 사용하여 삭제하든 상관없이 적용됩니다.

해결 방법: 해결 방법은 종속 리소스를 올바른 순서로 수동으로 삭제한 다음 VirtualMachineRestore 리소스에서 종료자를 삭제하는 것입니다.

kubeconfig 파일이 관리 클러스터를 가리키도록 설정합니다.
```
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
```

삭제할 VirtualMachineRestore와 네임스페이스를 식별합니다.

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

연결된 VolumeRestore 리소스를 찾아 삭제합니다. 이러한 항목은 VirtualMachineRestore에 연결하는 라벨과 함께 생성됩니다.

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

연결된 Restore 리소스를 찾아 삭제합니다. 이러한 항목은 VirtualMachineRestore에 연결하는 라벨과 함께 생성됩니다.

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

아직 실행하지 않았다면 kubectl delete를 실행하고 VirtualMachineRestore 리소스에서 종료자를 삭제합니다. 이는 Kubernetes 가비지 수집기가 리소스를 삭제할 수 있도록 하는 마지막 단계입니다.
```
kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"
```

삭제를 확인합니다.

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

이 명령어는 리소스가 삭제되었음을 확인하는 NotFound 오류를 반환해야 합니다.

메모리 부족으로 인해 백업 제어 영역 포드가 비정상 종료됨

버전: 1.14.4 이상

증상: 조직의 인프라 클러스터의 gpc-backup 시스템 네임스페이스에 있는 gpcbackup-controlplane-controller 포드의 상태가 CrashLoopBackOff로 표시됩니다. 이 오류가 발생하면 백업 및 복원 작업이 실패하거나 응답이 중지되거나 예상대로 작동하지 않습니다.

해결 방법: BACK-R0005에 따라 gpcbackup-controlplane-controller 배포의 메모리 한도를 늘립니다. 이 메서드는 SubcomponentOverride를 적용하여 CPU, 메모리 요청, 한도를 조정합니다.

사용자 클러스터 삭제가 중단됨

버전: 1.14.7 이상

증상: 파이널라이저 문제로 인해 클러스터가 삭제 상태에서 멈춥니다.

해결 방법: 클러스터를 삭제하기 전에 스토리지 볼륨에 SnapMirror 관계가 있는지 확인합니다. 자세한 내용은 BACK-R0109를 참고하세요.

대기 중인 영구 볼륨 클레인으로 인해 복원이 중단됨

버전: 1.14.3 이상

증상: 영구 볼륨 클레임 (PVC) 컨트롤러가 조직 인프라 클러스터의 백업 에이전트와 통신하지 못하는 경우가 있습니다. 이 문제는 백업 기능에는 영향을 미치지 않지만 볼륨 복원 작업이 Pending 상태에서 멈추고 결국 시간이 초과될 수 있습니다. 이 문제는 클로닝을 위한 데이터베이스 서비스 복원 기능 및 사용자 워크로드 복원과 같이 볼륨 복원이 포함된 복원 작업에 영향을 미칩니다.

이 문제가 발생하면 해당 백업 에이전트를 수동으로 다시 시작할 때까지 영향을 받는 클러스터 내의 후속 복원 작업이 실패합니다.

복원 문제가 이 특정 문제와 관련이 있는지 확인하려면 백업 에이전트 로그를 조사해야 합니다.

IAM-R0005에 따라 ExpirationClusterRoleBinding 리소스를 적용하여 필요한 BACK 디버거 역할 (back-cluster-debugger)을 획득합니다.
IAM-R0004에 따라 조직 인프라 클러스터의 kubeconfig 파일을 생성합니다. 모든 백업 에이전트는 조직 인프라 클러스터에서 실행됩니다.

복원을 지원하는 백업 에이전트를 식별합니다.

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

ORG_INFRA_KUBECONFIG를 조직 인프라 클러스터의 kubeconfig 파일 경로로 바꿉니다.

출력은 다음과 비슷합니다.

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

출력을 읽고 복원에 해당하는 백업 에이전트를 확인합니다. 예를 들어 출력에서 영향을 받는 스테이트풀 세트 네임스페이스가 gpc-backup-user-vm-1-cluster-system이면 백업 에이전트는 gpcbackup-agent-user-vm-1입니다.

스테이트풀 세트 로그에서 오류 메시지를 검색하여 문제를 확인합니다.
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
    -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
```
다음을 바꿉니다.
- ORG_INFRA_KUBECONFIG: 조직 인프라 클러스터의 kubeconfig 파일 경로입니다.
- BACKUP_AGENT: 이전 단계에서 식별한 백업 에이전트입니다.
- NAMESPACE: 이전 단계에서 식별한 네임스페이스입니다.
일치하는 로그가 있으면 이 알려진 문제가 발생한 것입니다.

해결 방법: 이 문제를 해결하려면 다음 단계를 완료하세요.

백업 에이전트를 다시 시작합니다.
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
   statefulsets/BACKUP_AGENT -n NAMESPACE
```
다음을 바꿉니다.
- ORG_INFRA_KUBECONFIG: 조직 인프라 클러스터의 kubeconfig 파일 경로입니다.
- BACKUP_AGENT: 문제를 확인할 때 식별한 백업 에이전트입니다.
- NAMESPACE: 문제를 확인할 때 식별한 네임스페이스입니다.
출력은 다음과 비슷합니다.
```
statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
```
대기 중인 작업이 자동으로 다시 시작될 때까지 최대 20분 동안 기다립니다.

백업 에이전트 다시 시작이 완료된 후 동일한 대상 클러스터에 대해 다른 복원을 실행할 수 있습니다. 이 해결 방법을 완료하면 부작용이 없습니다. 이 해결 방법은 영향을 받는 클러스터당 한 번만 완료하면 됩니다.

클러스터 관리

하위 구성요소 `kub-gpu-controller`이(가) 조정되지 않음

버전: 1.14.3

증상: gdchservices 조직의 하위 구성요소 g-gdchservices-shared-service-cluster/kub-gpu-controller가 조정되지 않습니다. 다음 출력이 반환됩니다.

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

이 오류로 인해 GPU 머신이 gdchservices 조직에서 시작되지 않습니다.

해결 방법: 버전 1.14.4 이상으로 업그레이드하여 문제를 완화하세요.

Standard 클러스터는 노드 풀을 삭제할 수 없습니다.

버전: 1.14.3, 1.14.4, 1.14.5

Fixed(해결됨): 1.14.6

증상: 표준 클러스터에서 오래된 노드 풀을 삭제하지 못하고 예상 기간 내에 노드 풀이 삭제되지 않습니다. 표준 클러스터는 비공개 미리보기로 제공되며 일부 고객에게는 제공되지 않을 수 있습니다.

해결 방법: 사용하지 않는 노드 풀을 수동으로 삭제합니다.

클러스터가 삭제 상태로 멈춰 있음

버전: 1.14.6 이상

증상: Kubernetes 클러스터를 삭제할 때 Deleting 상태에서 멈출 수 있습니다. 다음 명령어를 실행하여 클러스터의 상태를 확인합니다.

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

출력은 다음과 비슷합니다.

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

클러스터 네임스페이스의 상태를 확인하여 문제를 확인할 수도 있습니다.

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

출력은 다음과 비슷합니다.

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

클러스터 네임스페이스가 Terminating 상태로 멈추고 NamespaceContentRemaining 및 NamespaceFinalizersRemaining 조건이 True로 설정됩니다.

해결 방법: 이 문제를 해결하려면 다음 단계를 완료하세요.

전달 규칙 API를 패치합니다.

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

백엔드 서비스 API를 패치합니다.

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

데이터베이스 서비스

이 섹션에는 데이터베이스 서비스의 알려진 문제가 포함되어 있습니다.

AlloyDB Omni 데이터베이스 클론이 멈춤

버전: 1.14.6 이하

Fixed(해결됨): 1.14.7

증상: 사용자가 특정 시점에서 AlloyDB Omni 클러스터를 클론하면 클론된 데이터베이스 클러스터가 DBSE0005 오류로 멈춰 준비 상태가 될 수 없습니다. 해당 restore.alloydb 리소스가 'ProvisionInProgress' 단계에서 멈춰 있습니다.

해결 방법: 이 문제를 해결하려면 성공한 백업의 COMPLETETIME에서 시점을 신중하게 선택하세요.

관리 API 서버에서 복제할 수 있는 AlloyDB Omni 백업을 나열합니다.

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

출력 예시:

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

클론의 시점으로 COMPLETETIME 값을 선택합니다. 시간은 UTC 기준입니다.

DNS

GlobalCustomerRootDNSServerNotReachable에서 잘못된 알림이 발생함

버전: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7, 1.14.8

증상: DNS 경고 DNS-A0021이 발생하여 GlobalCustomerRootDNSServerNotReachable을 제안합니다. org-mp의 global-customer-root-dns 프로브 CR에 사양에 egress: true이 없습니다.

해결 방법:

org-mgmt의 KUBECONFIG 경로를 설정합니다.
```
export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG
```

프로브 CR을 관리하는 core-mz 하위 구성요소를 일시중지합니다.

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

org-mp에서 현재 프로브 CR을 수정합니다.

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

egress: True를 포함하도록 사양을 업데이트하고 변경사항을 적용합니다. CLUSTER_NAME 및 GLOBAL_CUSTOMER_ROOT_IP은 변경되지 않습니다.

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

이 해결 방법은 프로버를 수정하며 잘못된 알림은 15분 이내에 사라집니다.

파일/블록 스토리지

VM에서 파일 공유 볼륨을 마운트할 수 없음

버전: 1.14.6, 1.14.7

증상: 클러스터에 새 노드가 추가될 때 네트워크 스토리지 권한이 업데이트되지 않아 NFS 마운트 요청이 거부될 수 있습니다. NFS 파일 공유를 마운트할 때 access denied by server 오류가 표시될 수 있습니다.

해결 방법: file-share 또는 proxy-group 리컨실러를 다시 시작하거나 FileShare 리소스를 수정하여 업데이트를 트리거합니다.

방화벽

서브넷 CR의 주소에 대한 보안 정책 규칙이 누락됨

버전: 1.14.3

증상: 조직의 전역 API 서버에서 고객이 만든 전역 서브넷 커스텀 리소스에 방화벽 주소 그룹이 누락되어 조직에 연결할 수 없습니다.

해결 방법: 서비스 매뉴얼 FW-G0002의 단계에 따라 트래픽을 허용하는 보안 정책 규칙을 수동으로 추가합니다.

GDC 방화벽이 관리 및 데이터 영역 모두에 대해 OIR로 향하는 트래픽을 거부함

버전: 1.14.3, 1.14.4

증상: OCITTopology 커스텀 리소스가 배포된 후 OIR과 GDC 관리 영역 및 데이터 영역 간의 연결이 끊어집니다.

해결 방법: 서비스 매뉴얼 FW-G0002의 단계에 따라 트래픽을 허용하도록 루트 관리 클러스터에 보안 정책 규칙을 수동으로 추가합니다.

다음 보안 정책 규칙이 필요합니다.

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

다음을 바꿉니다.

OCIT_CIDR: 고객 입력 설문지 (CIQ)의 ocitCIDR 필드에 있는 IP 주소 범위입니다.
MGMT_CIDR: 고객 입력 설문지 (CIQ)의 oobManagementCIDRs 필드에 있는 IP 주소 범위입니다.
ZONE_INFRA_CIDR: 고객 입력 설문지 (CIQ)의 zoneInfraCIDRs 필드에 있는 IP 주소 범위입니다.

GDC 방화벽에서 교차 영역 교차 조직 트래픽 거부

버전: 1.14.3, 1.14.4, 1.14.5

증상: 교차 영역 교차 조직 트래픽이 방화벽에 의해 기본적으로 차단됩니다.

해결 방법: 런북의 단계에 따라 트래픽을 허용하는 보안 정책 규칙을 수동으로 추가합니다.

방화벽은 식별자가 조직 이름과 동일한 AttachmentGroup을 지원하지 않음

버전: 1.14.3 이상

증상: AttachmentGroup가 배포된 후 해당 AttachmentGroup 객체의 identifier 필드가 orgName와 동일하면 방화벽에서 이 객체를 파싱하지 못하고 방화벽 구성 업데이트가 중단됩니다. 문제가 있는 AttachmentGroup의 예는 다음과 같습니다.

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

해결 방법: 조직 이름을 식별자로 사용하지 마세요. 잘못된 AttachmentGroup를 수정하는 방법은 몇 가지가 있습니다.

문제가 있는 AttachmentGroup를 수정하려면 다음 옵션 중 하나를 선택하세요.

대시 기호를 사용하여 원래 식별자 끝에 문자열을 추가합니다.

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

대시 기호를 사용하여 원래 식별자의 시작 부분에 문자열을 추가합니다.

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

원래 식별자를 다른 문자열로 바꿉니다.

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

항구

백업 및 복원 후 Harbor CLI 보안 비밀이 무효화됨

버전: 1.14.3

증상: Harbor 백업 및 복원 후 CLI 보안 비밀이 무효화되어 다시 만들어야 합니다.

해결 방법: 이 문제를 완화하려면 다음 단계를 따르세요.

IAP 사용자 계정으로 Harbor에 로그인합니다.
사용자 이름을 클릭하고 사용자 프로필을 선택합니다.
더보기를 클릭합니다.
자동 또는 수동으로 다른 CLI 보안 비밀을 만듭니다.

GDC의 Harbor에 관한 자세한 내용은 Harbor 개요를 참고하세요.

Harbor 백업 및 복원 작업이 권한을 놓고 경쟁함

버전: 1.14.3, 1.14.4

증상: 여러 Harbor 인스턴스가 서로 다른 사용자 프로젝트에 있는 경우 백업 및 복원 작업이 역할 기반 액세스 제어를 위해 경쟁하여 실패율이 높습니다.

해결 방법: 이 문제를 완화하려면 다음 단계에 따라 Harbor 인스턴스가 생성된 각 네임스페이스에 대한 역할 바인딩을 수동으로 만드세요.

필수 환경 변수를 설정합니다.
```
INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
```
다음을 바꿉니다.
- INFRA_CLUSTER_KUBECONFIG: 인프라 클러스터 kubeconfig 파일의 경로입니다.
- INSTANCE_NAMESPACE: 관리형 Harbor 서비스 (MHS) Harbor 인스턴스가 생성되는 네임스페이스입니다.

해결 방법을 위한 역할 바인딩을 만듭니다.

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

Harbor 백업 크기가 0으로 표시됨

버전: 1.14.3, 1.14.4

증상: Harbor 백업의 백업 크기 측정은 현재 구현되지 않았습니다. GDC 콘솔에서 SizeBytes 필드에 0 값이 표시되고 Size 열에 0MB 값이 표시됩니다. 현재는 이 구성이 예상되는 동작입니다.

Harbor Registry 콘솔 페이지의 백업 리소스에 대한 권한 오류

버전: 1.14.3, 1.14.4

증상: Harbor 인스턴스 관리자 역할이 없는 경우 GDC 콘솔에서 Harbor Container Registry 페이지를 볼 때 백업 리소스에 권한 오류가 표시됩니다. 이 오류는 Harbor Container Registry 페이지에 백업 정보가 새로 추가되었지만 백업 리소스에 대한 읽기 권한이 Harbor 인스턴스 관리자 이외의 IAM 역할에 부여되지 않았기 때문에 표시됩니다.

Harbor Container Registry 페이지의 다른 GDC 콘솔 요소는 여전히 예상대로 작동합니다. GDC의 역할에 대한 자세한 내용은 역할 정의를 참고하세요.

데이터베이스 비밀번호 순환이 멈춘 페이지

버전: 1.14.3, 1.14.4, 1.14.5, 1.14.6

증상: failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01))와 같은 DB 요청 인증에 관한 오류가 발생하고 회전 가능한 단일 보안 비밀에 대해 자동으로 생성된 회전 요청이 많이 있습니다.

해결 방법: 순환 가능한 보안 비밀에 대해 준비되지 않은 추가 순환 요청을 삭제합니다.

KUBECONFIG를 mp api 서버로 설정합니다.
네임스페이스를 내보냅니다.
```
NAMESPACE=haas-system
```

haas-system에서 순환 가능한 보안 비밀이 준비되지 않았는지 확인합니다.

kubectl get rotatablesecrets -n ${NAMESPACE?}

출력은 다음 예시와 같이 표시됩니다.

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

순환 가능한 보안 비밀의 이름을 내보냅니다. 예를 들면 다음과 같습니다.
```
ROTATABLE_SECRET=haasdb-pw-haas-alice
```

준비되지 않은 추가 회전 요청을 삭제합니다.

CUR_ROTATABLE_SECRET=$(kubectl get rotatablesecret ${ROTATABLE_SECRET?} -n ${NAMESPACE?} -ojsonpath='{.status.currentRotationRequestRef.name}')

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

하드웨어 보안 모듈

HSM 비활성화된 무료 체험 라이선스가 계속 감지됨

버전: 1.14.3, 1.14.4, 1.14.5

증상: CipherTrust Manager의 기존 알려진 문제로 인해 비활성화된 무료 체험 라이선스가 계속 감지되어 잘못된 만료 경고가 트리거될 수 있습니다.

해결 방법: HSM-R0003을 참고하여 활성 일반 라이선스를 확인하고 비활성화된 평가판 라이선스를 삭제하세요.

HSM 호스트 데몬 파일 설명자 누수

버전: 1.14.x

증상: HSM이 30일 이상 실행되면 파일 설명자 누수로 인해 호스트 데몬 서비스가 응답을 중지하여 ServicesNotStarted 오류가 발생할 수 있습니다.

해결 방법: 호스트 데몬 서비스를 다시 시작합니다. 이렇게 하려면 인프라 운영자(IO)에게 SSH를 통해 ksadmin 사용자로 HSM에 연결하고 다음 명령어를 실행하도록 요청하세요.

sudo systemctl restart host-daemon

그래도 문제가 해결되지 않으면 IO가 비정상 HSM을 재부팅할 수 있습니다.

부팅 후 `ValidateNetworkConfig` 오류로 인해 HSM이 실패함

버전: 1.14.x

증상: HSM 커스텀 리소스가 Ready 상태로 전환되지 않고 ValidateNetworkConfig 오류로 인해 실패합니다. 이 오류에는 data0 interface MAC address {} is not active 메시지가 표시됩니다. 이 오류는 시스템이 재부팅되고 다른 기본 데이터 인터페이스가 설정된 경우 발생합니다.

해결 방법: 런북 HSM-R0059에 따라 데이터 네트워크의 HSM 네트워크 구성을 다시 적용합니다. 이 런북은 HSM이 두 개 이상에서 이 오류가 발생하더라도 안전하게 따를 수 있습니다.

건강

잘못된 알림 SLO 알림

버전: 1.14.3

증상: successRange SLO가 잘못 실행됩니다.

해결 방법: 인프라 운영자 (IO)에게 알림이 실제 문제인지 아니면 잘못된 알림인지 확인해 달라고 요청하세요.

이렇게 하려면 알림이 트리거될 때 해당 런북에 따라 서비스 수준 목표 (SLO) 알림의 근본 원인을 해결하세요.

첫 번째 사례: 런북으로 문제가 해결되고 알림이 중지되면 IO가 연결된 인시던트를 종료할 수 있습니다.

두 번째 사례: 런북이 완료되었지만 알림이 계속 발생하면 잘못된 알림일 수 있습니다. SLO가 중단되었는지 확인합니다.

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

출력을 기반으로 알림이 오보임을 확인하는 경우 IO는 GDC 에어갭 인스턴스 내에서 알림을 무음으로 설정해야 합니다. 그렇지 않으면 Cloud 지원팀에 에스컬레이션합니다.
어떤 경우든 IO가 작동 가능한 구성요소가 정상인지 확인하기 위해 Cloud 지원팀에 에스컬레이션하는 것이 적절합니다.

잘못된 게이지 기반 SLO 구성

버전: 1.14.3, 1.14.4

증상: 잘못된 구성으로 인해 서비스 수준 목표 (SLO)의 하위 집합에 양호, 불량 또는 총 이벤트가 채워지지 않습니다. 문제가 되는 SLO는 Prometheus 게이지를 기반으로 하며 그에 따라 구성해야 합니다.

해결 방법:

버전 1.14.3: 해결 방법이 없습니다. 따라서 영향을 받는 SLO에 대해 SLO 알림이 실행되지 않습니다.

버전 1.14.4: SLO를 수정하는 해결 방법이 있습니다. 이 문제를 해결하려면 SLO 사양에 isGauge: true 설정을 적용해야 합니다.

SLO의 게이지 구성 예:

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

이 설정으로 수정되는 SLO의 알려진 목록은 다음과 같습니다.

방화벽 SLO:
- fw-packet-discard-errors-slo
- fw-packet-discard-no-error-slo
- fw-packet-discard-unknown-protocol-slo
- fw-uptime-slo
파일 SLO:
- file-ontap-appliance-availability-slo
- file-ipsec-networking-availability-slo
- file-ontap-networking-availability-slo
- file-iscsi-client-availability-slo
- file-multipath-client-availability-slo
- file-trident-client-availability-slo

ID 및 액세스 관리

IAM 역할 바인딩 생성 실패

버전: 1.14.3

증상: IAM 역할 바인딩 이름이 시스템에 의해 생성됩니다. 이러한 이름의 최대 길이는 63자(영문 기준)이며 형식은 user-idp-prefix-rolename입니다. 생성된 이름이 63자(영문 기준) 제한을 초과하는 경우 역할 바인딩이 생성되지 않습니다. 따라서 사전 정의된 역할 또는 커스텀 역할을 사용하여 정의된 권한은 사용자에게 할당되지 않습니다.

해결 방법: 사전 정의된 역할 이름이나 커스텀 역할 이름이 매우 짧은 경우(예: 영문 기준 4~5자) 역할 바인딩이 생성될 수 있습니다.

프로젝트 서비스 계정의 IAM 역할 바인딩을 만들지 못함

버전: 1.14.3, 1.14.4, 1.14.5, 1.14.6

증상: organization-iam-admin 역할이 있는 프로젝트 서비스 계정 (PSA)이 gdcloud projects add-iam-policy-binding 명령어를 사용하여 project-iam-admin 역할과 같은 다른 역할을 자신에게 할당할 수 없습니다. 이 결함으로 인해 PSA가 자체 권한을 관리할 수 없습니다.

해결 방법: organization-iam-admin 역할이 있는지 확인합니다. 그런 다음 타겟 PSA의 프로젝트 네임스페이스에서 project-iam-admin 역할을 자신에게 할당하고 PSA에 project-iam-admin 역할을 할당합니다. 이 권한 설정을 사용하면 PSA가 자신 또는 다른 PSA에 추가 권한을 할당할 수 있습니다.

새 프로젝트에서 사전 정의된 역할 생성 지연

버전: 1.14.3

증상: 새 프로젝트를 만들 때 project-bucket-object-admin과 같은 기본 역할이 누락됩니다.

해결 방법: 15~60분 정도 기다리거나 조직 인프라 클러스터의 iam-system 네임스페이스에서 iam-org-admin-cm-backend-controller 컨트롤러를 수동으로 다시 시작합니다.

GDC 콘솔에서 첫 번째 역할 바인딩을 만들 수 없음

버전: 1.14.4

증상: GDC 콘솔을 사용하여 새 서비스 ID의 첫 번째 역할 바인딩을 만들 때 역할 바인딩 생성이 성공한 것으로 보고되지만 실제로 작동하지 않습니다. 역할 바인딩 추가 또는 역할 바인딩 삭제 등 서비스 ID에 대한 추가 작업은 실패하며 효과가 없습니다.

해결 방법: gdcloud CLI를 사용하여 서비스 ID의 첫 번째 역할 바인딩을 만듭니다. 첫 번째 역할 바인딩이 연결된 후 GDC 콘솔을 사용하여 서비스 ID로 수행하는 모든 향후 작업이 올바르게 작동합니다. 자세한 내용은 서비스 ID에 역할 바인딩 할당을 참고하세요.

AO는 인프라 클러스터의 역할에 대한 액세스 권한을 부여할 수 없음

버전: 1.14.3. 1.14.4

Fixed(해결됨): 1.14.3 핫픽스 21

증상: AO가 인프라 클러스터의 역할에 대한 액세스 권한을 자신이나 다른 사용자에게 부여할 방법이 없습니다.

해결 방법: AO 사용자는 IO에 문의하여 필요한 액세스 권한을 얻어야 합니다. IO는 IAC를 사용하여 AO 사용자에게 필요한 액세스 권한을 제공할 수 있습니다.

기존 서비스 계정 토큰이 무효화됨

버전: 1.14.3

Fixed(해결됨): 1.14.3 핫픽스 21

증상: 부트스트랩 후 클러스터가 실행 상태에 있을 때 service-account-issuer apiserver arg가 변경되어 사용자 클러스터에서 발급한 기존 서비스 계정 토큰이 무효화됩니다. 이 문제로 인해 사용자 클러스터의 포드(예: istio-proxy 사이드카 컨테이너가 있는 포드)가 서비스 계정 토큰을 사용하여 인증에 실패하고 서비스 계정 토큰이 새 구성으로 새로고침되는 데 몇 시간이 걸립니다.

해결 방법: 사용자 클러스터에서 포드를 수동으로 다시 시작하여 서비스 계정 토큰이 새 구성으로 갱신되도록 합니다.

코드형 인프라(IAC)

네임스페이스 누락으로 인한 하위 구성요소 조정 실패

버전: 1.14.3

증상: 하위 구성요소가 조정되지 않습니다. 이는 필수 config-management-monitoring 네임스페이스가 gdchservices-mp 클러스터에서 자동으로 생성되지 않기 때문에 발생합니다.

해결 방법: 다음 매니페스트를 사용하여 gdchservices-mp 클러스터에 config-management-monitoring 네임스페이스를 만듭니다.

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

IAC ConfigSync 측정항목 수집 실패

버전: 1.14.3, 1.14.4

증상: IAC의 ConfigSync 모니터링 하위 시스템에 문제가 있어 otel-collector 배포가 시작되지 않습니다. ConfigSync 측정항목은 모니터링 및 알림을 위해 수집되지 않습니다.

해결 방법: root-admin 클러스터에서 다음 단계를 완료합니다.

iac-configsync-mon 하위 구성요소를 일시중지합니다.
config-management-monitoring 네임스페이스에서 MetricsProxySidecar/iac-configsync-metrics 객체를 수정합니다.

MetricsProxySidecar/iac-configsync-metrics YAML에서 다음을 찾습니다.

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

이 섹션을 다음과 같이 변경합니다.

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

config-management-monitoring 네임스페이스에서 otel-collector 배포를 다시 시작합니다.

IAC RootSync가 실패함

버전: 1.14.3

증상: iac-creds 보안 비밀이 누락되어 Gitlab에서 클러스터로 리소스를 동기화하는 ConfigSync에 문제가 있습니다 . iacmanager 문제로 인해 iac-creds가 회전되지 않습니다.

해결 방법: 클러스터에서 다음 단계를 완료합니다.

IAC-R0015 런북에 따라 누락된 보안 비밀 iac-creds 문제를 해결합니다. IaC 관리자 및 Configsync의 사용자 인증 정보를 순환합니다.

인벤토리

인벤토리 감사에서 조정 실패

버전: 1.14.3

증상: HarborRobotAccount는 관리 영역에서만 사용할 수 있으므로 inv-audit 하위 구성요소가 조정되지 않습니다.

해결 방법: AlertManager에서 음소거를 만들어 component: inv의 component_reconciliation_errors 알림을 음소거합니다.

키 관리 시스템

CTM 루트 키를 사용하도록 구성된 KMS는 HSM을 사용할 수 없는 경우 장애 조치를 수행하지 않음

버전: 1.14.x

증상: HSM을 사용할 수 없고 사용할 수 있는 다른 HSM이 있는 경우 KMS에 대한 일부 요청이 실패합니다. 이 문제는 KMS가 CTM 루트 키를 사용하도록 구성된 경우에만 적용됩니다.

해결 방법: HSM-P0006 런북에 따라 HSMCluster에서 사용할 수 없는 HSM을 삭제합니다. 그런 다음 kms-backend 배포를 다시 시작합니다.

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

이 명령어는 kms-backend 포드를 다시 시작하고 HSMCluster의 HSM에 대한 연결을 다시 설정합니다.

부하 분산기

서브넷 CIDR 소진으로 인해 전역 부하 분산기 생성이 실패함

버전: 1.14.3

증상: 전역 서브넷의 IP 주소가 부족하여 전역 외부 또는 내부 부하 분산기 생성이 실패합니다. 잘못된 코드 경로를 사용하는 컨트롤러로 인해 시스템에서 전역 부하 분산기의 IP 주소를 동적으로 할당할 수 없습니다. 부하 분산기는 하나의 서브넷만 참조하며 해당 서브넷에 사용 가능한 IP 주소가 더 이상 없으면 다른 서브넷으로 전환할 방법이 없습니다. 이 제한으로 인해 오류가 표시됩니다.

해결 방법: 자체 서브넷을 만들고 ForwardingRule 리소스의 고정 IP 주소를 만들어야 합니다. 서브넷 만들기에 대한 자세한 내용은 워크로드 네트워킹을 위한 서브넷 구성을 참고하세요. ForwardingRule 리소스를 만들 때 cidrRef 필드에서 서브넷을 지정할 수 있습니다.

버전: 1.14.3

증상: 부하 분산기 객체가 Ready 상태로 전환되지 않습니다.

해결 방법: spec 필드에 값이 있는 Backend 리소스를 만들어야 합니다. Backend 리소스는 부하 분산기의 엔드포인트를 식별합니다. spec 필드에 값을 제공하지 않으면 오류 상태가 발생할 수 있습니다.

부하 분산기 리소스를 수정해도 서비스가 조정되지 않음

버전: 1.14.3

증상: 부하 분산기 커스텀 리소스를 수정해도 부하 분산기 서비스가 조정되지 않습니다.

해결 방법: 이 문제를 완화하려면 해당 부하 분산기의 BackendService 및 ForwardingRule 리소스를 삭제하여 부하 분산기를 삭제하고 다시 만듭니다.

잘못된 영역 이름이 거부되지 않음

버전: 1.14.3

증상: 전역 BackendService 리소스가 잘못된 영역 이름을 거부하지 않습니다. 영역 이름이 잘못된 경우 부하 분산기가 구성을 검증하고 거부하는 대신 실패합니다.

해결 방법: 사용 중인 영역의 올바른 이름을 제공해야 합니다. 부하 분산기가 잘못 구성된 경우 부하 분산기 커스텀 리소스를 삭제하고 다시 만들어야 합니다.

전역 및 영역 부하 분산기 웹훅 오류

버전: 1.14.3

증상: 다음 오류가 반환됩니다.

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

해결 방법: 이 문제를 완화하려면 unet-global-cm 포드를 다시 시작하고 삭제합니다.

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

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

로깅

WAL 재생 중에 Loki 포드가 비정상 종료되거나 OOMKilled됨

버전: 1.14.3, 1.14.4, 1.14.5

증상:

obs-system 네임스페이스의 audit-logs-loki-io 포드가 CrashLoopBackOff 상태로 전환됩니다. 이는 포드의 메모리 한도를 초과하는 wal_replay_ceiling 값으로 인해 WAL (Write-Ahead Log) 재생 중에 조기 활성 상태 프로브 실패 또는 메모리 부족 (OOM) 종료가 발생하기 때문입니다.

해결 방법:

다음 단계에 따라 WAL 재생이 성공하도록 Loki의 구성을 조정하세요. 변경사항이 적용될 클러스터 (예: root-admin 또는 org-infra)

KUBECONFIG=/path/to/affected-cluster.kubeconfig을 환경 변수로 설정합니다.

컨트롤러가 수동 변경사항을 되돌리지 않도록 LoggingPipelineReconciler를 일시중지합니다. 이 매니페스트를 적용합니다.

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

재정의가 활성 상태인지 확인합니다. 출력에는 "disable-reconcilers=LoggingPipelineReconciler"이 포함되어야 합니다.

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

audit-logs-loki-io-cm ConfigMap의 replay_memory_ceiling을 8GB로 낮춥니다.

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

wal 섹션을 수정합니다.

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

선택사항: 객체 프록시를 확장합니다. obj-proxy 포드가 리소스 한도에 가까운 경우 복구 중에 증가한 부하를 처리하도록 배포를 확장합니다.

a. 리소스 사용량을 확인합니다.
```
kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
```
b. 사용량이 많으면 배포를 확장합니다.
```
kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
```
c. 필요한 경우 포드의 메모리 한도를 늘릴 수도 있습니다 (예: 12000Mi에서 16000Mi로).
영향을 받는 포드의 PVC 크기를 늘립니다 (예: loki-storage-audit-logs-loki-io-0에서 70Gi로 변경)하여 디스크 압력을 방지합니다.75Gi 내부 절차 SUPP-R001에 따라 PVC 크기를 조정합니다. 다음 단계에서 다시 시작하면 새 크기가 적용됩니다.
활성 상태 확인이 시작되기 전에 WAL 재생 시간을 허용하도록 audit-logs-loki-io StatefulSet에 startupProbe 추가 변경사항을 저장하면 포드의 순차적 다시 시작이 트리거됩니다 (5~10분).
```
kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}
```
이 startupProbe을 audit-logs-loki-io 컨테이너 사양에 추가합니다.
```
startupProbe:
  failureThreshold: 1000
  httpGet:
    path: /ready
    port: loki
    scheme: HTTP
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 10
```

해결 방법 확인

포드 및 StatefulSet 상태 확인: 모든 audit-logs-loki-io 포드가 Running이고 StatefulSet에 모든 복제본이 준비됨으로 표시되는지 확인합니다.

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

PVC의 크기가 조정되었는지 확인합니다. 예상 출력은 75Gi입니다.

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

errors=false 메시지에 대한 포드 로그를 확인하여 WAL 복구가 성공했는지 확인합니다.
```
kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"
```

포드 내 /wal 디렉터리의 사용량이 적은지 확인합니다.

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

Loki Ring 상태 확인:

a. Loki 서비스를 포트 전달합니다.

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

b. http://<DATA_IP>:43100/ring에서 모든 인스턴스가 정상인지 확인합니다.

재정의 및 객체 프록시 정리

인증이 완료되면 다음 정리 단계를 실행합니다.

하위 구성요소 재정의를 삭제합니다.

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

obj-proxy 배포를 확장한 경우 원래 크기로 다시 축소합니다.

모니터링

AlertManager 웹훅이 일부 클러스터에 대한 알림을 전송하지 못함

버전: 1.14.3

증상: AlertManager 웹훅이 루트 관리자 클러스터 또는 ServiceNow 인스턴스가 있는 클러스터가 아닌 클러스터에서 ServiceNow로 요청 및 알림을 전송하지 못합니다. 따라서 조직에 대한 알림이 ServiceNow에 생성되지 않습니다.

오류 로그 메시지가 반복적으로 수신되면 웹훅이 알림을 전송하지 못하는 것입니다. 다음 단계에 따라 반복되는 오류를 확인하세요.

환경 변수 내보내기
```
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
```
MGMT_API_KUBECONFIG를 관리 API 서버의 kubeconfig 파일 경로로 바꿉니다.

포드를 찾습니다.

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

로그를 가져옵니다.

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

POD_NAME을 포드의 이름으로 바꿉니다.

다음과 같은 반복되는 오류를 찾습니다.

Errorsendingtherequest ... read: connection reset by peer

해결 방법: 이 문제의 권장 해결 방법은 메타 모니터링 알림용 하위 구성요소 하나와 일반 알림용 하위 구성요소 하나를 일시중지하는 것입니다. 그런 다음 영향을 받는 클러스터의 mon-alertmanager-servicenow-webhook-backend 배포에서 egress.networking.gke.io/enabled: "true" 라벨을 networking.private.gdc.goog/infra-access: enabled로 바꿉니다. 이 라벨을 사용하면 이그레스 게이트웨이를 사용하지 않고도 포드가 다른 인프라 클러스터와 통신할 수 있습니다.

권장 해결 방법을 적용하려면 다음 단계를 따르세요.

환경 변수 내보내기
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
export ORG=ORG
```
다음을 바꿉니다.
- ROOT_KUBECONFIG: 루트 관리자 클러스터의 kubeconfig 파일 경로
- MGMT_API_KUBECONFIG: 관리 API 서버의 kubeconfig 파일 경로
- ORG: 조직의 네임스페이스

하위 구성요소를 일시중지합니다.

mon-alertmanager-servicenow-webhook 하위 구성요소를 일시중지합니다.

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

mon-meta-monitoring 하위 구성요소를 일시중지합니다.

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

대부분의 알림을 처리하는 mon-alertmanager-servicenow-webhook-backend 배포를 업데이트합니다.

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

spec.template.metadata.labels의 라벨을 egress.networking.gke.io/enabled: "true"에서 networking.private.gdc.goog/infra-access: "enabled"로 바꿉니다.

모니터링 스택과 관련된 알림을 처리하는 meta-alertmanager-servicenow-webhook 배포를 업데이트합니다.

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

spec.template.metadata.labels의 라벨을 egress.networking.gke.io/enabled: "true"에서 networking.private.gdc.goog/infra-access: "enabled"로 바꿉니다.

또는 Grafana를 사용하여 동일한 알림을 볼 수 있습니다.

ServiceNow 인시던트가 가끔 중복됨

버전: 1.14.3

증상: 동일한 포드에 대해 중복된 ServiceNow 인시던트가 표시될 수 있습니다.

해결 방법: 인시던트 설명의 디지털 지문을 일치시켜 중복 티켓을 식별할 수 있습니다.

인프라 측정항목이 지나치게 민감할 수 있음

버전: 1.14.3

증상: oclcm-reconciler-success-rate 알림에 대한 알람이 표시될 수 있습니다.

해결 방법: 알림을 음소거해도 됩니다. 이 알림은 과도하게 자주 표시되고 있어, 신호 개선을 위해 노력하고 있습니다.

조정 측정항목이 지나치게 민감할 수 있음

버전: 1.14.3, 1.14.4, 1.14.5

증상: component_reconciliation_errors 알림에 대한 알람이 표시될 수 있습니다.

해결 방법: 런북 MON-R2009에 따라 알림을 음소거해도 됩니다. 이 알림은 과도하게 자주 표시됩니다.

루트 관리자 클러스터에 잘못된 알림 2개가 열려 있음

버전: 1.14.3

증상: 루트 관리자 클러스터에서 MON-A0001_slow 및 MON-A0001_fast 알림이 트리거 상태입니다.

ServiceNow의 인시던트는 다음 예시와 같이 표시됩니다.

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

사고의 설명은 다음과 같습니다.

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

해결 방법: 루트 관리자 클러스터에서만 이 문제를 해결하려면 다음 단계를 따르세요.

mon-a0001-blackbox-monitoring-obs-system MonitoringRule에서 monitoring.gdc.goog/metamonitoring-project=mon-system 라벨을 삭제합니다.

mon-a0001-blackbox-monitoring-obs-system MonitoringRule에서 이름이 mon_metrics_pipeline_absent이고 클러스터 라벨 값이 ORG_NAME-admin인 모든 녹화 규칙을 삭제합니다.

다음 예는 삭제할 mon_metrics_pipeline_absent 녹화 규칙을 보여줍니다.

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

MON_A0001_slow 및 MON_A0001_fast 알림은 몇 분 (약 40분) 후에 Normal 상태로 돌아갑니다.

루트 관리자 컨트롤러 관리자의 오류율이 높게 표시됨

버전: 1.14.3

증상: ControllerReconciliationErrorRateHigh 알림에 대한 알람이 표시될 수 있습니다. 컨트롤러 관리자에 ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found라는 로그가 표시됩니다.

해결 방법: 오류가 발생한 컨트롤러를 사용 중지해도 됩니다.

환경 변수 내보내기
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
```
루트 관리자 컨트롤러 관리자 배포를 수정합니다.
```
kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
  -n gpc-system root-admin-controller
```
manager 컨테이너에 --disable-reconcilers 인수가 아직 없으면 --disable-reconcilers=ApplianceStorageTunnelReconciler 값을 사용하여 인수를 추가합니다. 있는 경우 ApplianceStorageTunnelReconciler 리컨실러를 쉼표와 함께 추가합니다. 예를 들면 --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler입니다.

오류 로그가 지워집니다.

KUB 대시보드의 모든 PA 패널에 데이터가 표시되지 않음

버전: 1.14.3

증상: 플랫폼 관리자의 경우 Grafana의 모든 패널에 KUB 대시보드에 데이터가 표시되지 않습니다.

해결 방법: KSM 하위 구성요소를 일시중지하고 monitoringtarget 및 metricsproxysidecar를 업데이트합니다.

하위 구성요소를 일시중지합니다.

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

다음을 바꿉니다.

ORG_NAME: 조직 이름
ROOT_ADMIN_KUBECONFIG: root-admin kubeconfig의 경로

.spec.destinations 섹션의 mon-kube-state-metrics-metrics-proxy metricsproxysidecar에 다음을 추가합니다.

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

업데이트된 metricsproxysidecar는 다음과 같이 표시될 수 있습니다.

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

mon-pa-kube-state-metrics monitoringtarget spec에서 matchClusters: 섹션을 삭제합니다. 업데이트된 mon-pa-kube-state-metrics monitoringtarget spec은 다음과 같습니다.

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

관측 가능성-admin-debugger 역할의 권한이 잘못 구성됨

버전: 1.14.3, 1.14.4

증상: IO가 mon-system 네임스페이스에서 cortex 또는 prometheus 포드를 다시 시작할 수 없습니다.

해결 방법:

조직의 경우:

iam-common 하위 구성요소를 일시중지합니다.

observability-admin-debugger/iam-system roleTemplate을 다음과 같이 업데이트합니다.

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

루트 관리자의 경우:

iam-common 하위 구성요소를 일시중지합니다.

observability-admin-debugger-root/iam-system roleTemplate을 다음과 같이 업데이트합니다.

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

Grafana 디버거 역할 누락

버전: 1.14.3, 1.14.4

증상: grafana-debugger-cp 역할이 관측 가능성 섀도우 프로젝트 네임스페이스 (*-obs-system)에 없습니다. 사용자에게 Grafana 관련 문제를 디버깅하는 데 필요한 올바른 권한 집합이 부여되지 않습니다.

해결 방법: infra-cp에서 다음 ClusterRoleTemplate 커스텀 리소스를 만들고 생성된 해당 ClusterRole를 사용하여 grafana-debugger 권한을 가져옵니다.

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

새 영역을 추가한 후 교차 영역 측정항목 및 로그가 표시되지 않음

버전: 1.14.*

증상: Grafana 대시보드에 새로 추가된 영역의 로그와 측정항목이 표시되지 않습니다.

해결 방법 1: 데이터 소스 프록시 배포를 다시 시작합니다.

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

이렇게 하면 datasource-proxy 포드가 다시 시작되고 새로 추가된 영역의 교차 영역 엔드포인트 구성이 업데이트됩니다.

`MonitoringTarget` 파이널라이저가 네임스페이스 삭제를 차단함

버전: 1.14.3, 1.14.4

증상: 네임스페이스가 삭제되지 않고 해당 조직에 비정상 클러스터가 있습니다.

해결 방법: 네임스페이스 삭제를 차단한 MonitoringTarget 커스텀 리소스에서 파이널라이저를 수동으로 삭제합니다.

대시보드 및 데이터 소스의 파이널라이저가 보류되어 프로젝트 삭제가 중단됨

버전: 1.14.3, 1.14.4

Fixed(해결됨): 1.14.3 핫픽스 22

증상: 프로젝트가 삭제되지 않고 네임스페이스 종료에 다음 예와 같은 오류가 있습니다.

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

해결 방법: 대시보드 및 데이터 소스 종료자를 수동으로 삭제합니다.

KSM의 측정항목이 표시되지 않음

버전: 1.14.3

Fixed(해결됨): 1.14.3 핫픽스 22

증상: KUB 대시보드에 모든 패널에 No Data이 표시됩니다.

해결 방법: KSM 하위 구성요소를 일시중지하고 monitoringtarget 및 metricsproxysidecar를 업데이트합니다.

하위 구성요소 일시중지:

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

다음을 바꿉니다.

ORG_NAME: 조직 이름입니다.
ROOT_ADMIN_KUBECONFIG: 루트 관리자 kubeconfig의 경로입니다.

.spec.destinations의 mon-kube-state-metrics-metrics-proxy metricsproxysidecar에 다음을 추가합니다.

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

업데이트된 mon-kube-state-metrics-metrics-proxy metricsproxysidecar는 다음 예와 같습니다.

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

mon-pa-kube-state-metrics monitoringtarget 사양에서 matchClusters: 섹션을 삭제합니다. 업데이트된 mon-pa-kube-state-metrics monitoringtarget 사양은 다음과 같습니다.

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

시스템 측정항목 파이프라인이 다운됨

버전: 1.14.3

증상: MON-R0001 런북을 따른 후에도 MON-A0001 알림이 활성 상태입니다.

해결 방법:

관리자 클러스터에서 문제가 확인되면 IAC-R0004 런북을 사용하여 root-admin에서 다음 SubcomponentOverride를 만듭니다. 사용자, 경계 또는 공유와 같은 다른 클러스터의 경우 ${ORG}-mp에 SubcomponentOverride를 만듭니다.

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

올바른 NAMESPACE를 찾습니다.

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

출력은 다음과 같습니다.

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

네임스페이스는 파이프라인이 root-admin로 다운된 경우 루트이고, 파이프라인이 org-1 admin로 다운된 경우 org-1입니다.

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

출력은 다음과 같습니다.

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

여기서 올바른 네임스페이스는 시스템 측정항목 파이프라인이 다운된 클러스터에 따라 g-org-1-perimeter-cluster, g-org-1-shared-service-cluster, user-vm-1-cluster 또는 user-vm-2-cluster일 수 있습니다.

SubcomponentOverride를 적용한 후 각 클러스터에서 cortex-tenant 배포를 다시 시작합니다. 값이 해당 클러스터에서 업데이트되었는지 확인합니다.
```
kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
```
동시 실행 필드를 업데이트합니다.

cortex-tenant 배포를 다시 시작합니다.

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

멀티테넌시

콘솔에 노드 풀 생성 실패가 표시되지 않음

버전: 1.14.4, 1.14.5, 1.14.6

Fixed(해결됨): 1.14.7

증상: GDC 콘솔에서 노드 풀 생성이 실패하면 UI에 노드 풀이 생성되었음을 나타내는 creation in progress 메시지가 잘못 표시됩니다.

해결 방법: gdcloud CLI를 사용하여 노드 풀 생성을 검증합니다.

멀티 영역

액세스할 수 없는 영역이 인증 페이지로 리디렉션됨

버전: 1.14.x

증상: 영역에 액세스할 수 없으면 GDC 콘솔이 인증 오류를 표시하는 페이지로 리디렉션됩니다. 하지만 영역에 액세스할 수 없는 이유는 인증 문제 때문이 아니라 영역 중단 때문일 수 있습니다.

해결 방법: 영역 URL을 사용하여 이 문제를 해결합니다. 영역 URL도 작동하지 않으면 인증 문제가 발생하는 영역이 다운되었는지 인프라 운영자 (IO)에게 진단해 달라고 요청하세요.

gdcloud CLI를 사용하여 영역을 보는 역할이 적용되지 않음

버전: 1.14.x

증상: gdcloud zones list 명령어를 사용하는 데 필요한 IAM 역할이 기본적으로 GDC 유니버스에 적용되지 않습니다. 사전 정의된 역할로 사용할 수 없는 누락된 역할로 인해 gdcloud CLI를 사용하여 영역을 나열할 수 없습니다.

해결 방법: IAM 역할 global-zone-viewer 및 역할 바인딩 리소스를 전역 API 서버에 적용합니다.

다음 콘텐츠로 역할 YAML 파일(예: global-zone-viewer.yaml)을 만듭니다.

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

YAML 파일을 조직의 전역 API 서버에 적용합니다.

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

이 역할 바인딩은 gdcloud zones list를 사용하여 영역을 볼 수 있도록 시스템의 모든 사용자를 인증합니다.

간헐적인 전역 콘솔 URL 로그인 오류

버전: 1.14.x

증상: 전역 URL로 GDC 콘솔에 로그인하면 세션이 더 이상 유효하지 않다는 오류가 표시될 수 있습니다. 이 오류는 기본 네트워킹 버그로 인해 발생할 수 있으며 세션 상태를 정확하게 나타내지 않습니다.

해결 방법: 영역 URL로 GDC 콘솔에 로그인하여 각 영역 내에서 전역 리소스를 관리합니다. GDC 콘솔에서 영역 컨텍스트를 전환하는 방법에 대한 자세한 내용은 영역 간 리소스 관리를 참고하세요.

네트워킹

`MultiZoneNetworkConfig` 영역 순서를 조정하면 구성 바꾸기가 실패함

버전: 1.14.x의 모든 버전이 영향을 받을 수 있습니다.

증상:

Top of Rack(ToR) 스위치의 READY 상태가 False입니다. 다음 명령어를 실행하여 확인할 수 있습니다.
```
kubectl get torswitches -A
```
항목이 이미 존재한다는 오류와 함께 스위치 구성 바꾸기가 실패합니다. 이는 스위치 구성 바꾸기 로그에서 확인할 수 있습니다. 오류 메시지는 다음과 비슷합니다.
```
% Insertion failed - entry already exists
```

이 문제는 MultiZoneNetworkConfig 내 영역의 순서 조정으로 인해 발생합니다. 시스템은 구성 목록에서 각 영역의 위치를 기반으로 BGP 액세스 목록 규칙의 시퀀스 넘버를 생성합니다. 영역 순서가 변경되면 시스템에서 스위치에 이미 있는 규칙과 충돌하는, 시퀀스 넘버가 다른 새 규칙을 생성합니다.

해결 방법:

이 문제를 해결하려면 영향을 받는 각 ToR 스위치에서 충돌하는 BGP AS 경로 액세스 목록 구성을 수동으로 삭제하세요. 이렇게 하면 시스템에서 올바른 구성을 조정하고 적용할 수 있습니다.

Ready 상태가 아닌 각 ToR 스위치에 SSH 연결을 설정합니다.
전역 구성 모드로 진입합니다.
```
config t
```
충돌하는 액세스 목록 구성을 삭제합니다.
```
no ip as-path access-list other-zones
```
구성 모드를 종료합니다.

이 명령어가 영향을 받는 모든 스위치에서 실행되면 조정자가 올바른 구성을 적용하고 스위치가 READY 상태로 전환됩니다.

구성 바꾸기 커밋 만료

버전: 1.14.x의 모든 버전이 영향을 받을 수 있습니다.

증상:

액세스 제어 목록 (ACL)이 많으면 네트워크 스위치를 구성할 때 타임아웃이 발생합니다. BorderLeafSwitch 커스텀 리소스가 Ready 상태가 아니며 준비되지 않은 스위치로 SSH 연결을 설정하면 Commit expiry 상태가 표시됩니다.

예를 들어 다음 명령어는 상태를 보여줍니다.

sh config-replace log verify

출력은 다음과 비슷합니다.

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

해결 방법:

1.14.3 또는 1.14.7 이상 버전에서는 root 네임스페이스에서 pnet-core-override이라는 SubcomponentOverride 커스텀 리소스를 수정하고 .spec.operableParameters.netDevGW에 httpTimeout 필드를 추가합니다.

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

자동화 인프라가 스위치에 새 구성을 푸시할 수 있도록 15분 동안 기다립니다. Commit expiry 메시지가 사라질 때까지 필요에 따라 httpTimeout를 구성합니다.

1.14.4, 1.14.5, 1.14.6 버전에서는 config-replace를 수동으로 실행하고 변경사항을 커밋합니다.

스위치를 일시중지합니다.

export SWITCH_NAME=SWITCH_NAME # example: aa-aa-blsw01
export SWITCH_TYPE=SWITCH_TYPE # example: borderleafswitch

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

PNET-P0001 런북에 따라 스위치 액세스 권한을 얻습니다.
바꿀 구성을 찾습니다.
```
switch-cli# dir | grep new_config
```
구성 바꾸기를 완료합니다.
```
switch-cli# configure replace <new_config_file>
```
5분 이상 걸릴 수 있습니다.
config-replace가 성공하면 변경사항을 커밋합니다.
```
switch-cli# configure replace commit
```

스위치의 일시중지를 해제합니다.

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

4바이트 BGP ASN을 사용한 배포가 실패함

버전: 1.14.3, 1.14.4

증상: 네트워크 스위치에서 4바이트 자율 시스템 번호 (ASN)로 경계 게이트웨이 프로토콜 (BGP)을 구성하면 구성이 실패합니다. BGP 구성이 올바르게 적용되지 않으면 해당 GDC 영역 내 네트워크에서 적절한 라우팅을 설정하지 못하여 연결 문제, 경로 공지 불가 또는 일반적인 네트워크 불안정성이 발생할 수 있습니다. 현재로서는 해결 방법이 없습니다.

전역 애니캐스트 트래픽이 차단됨

버전: 1.14.3

증상: 전역 애니캐스트 엔드포인트로 향하는 트래픽이 액세스 제어 목록(ACL)에 의해 차단됩니다.

해결 방법:

액세스 제어 목록(ACL)에 의해 전역 애니캐스트 트래픽이 차단되는 문제를 해결하려면 루트 관리자 클러스터에서 SubcomponentOverride 커스텀 리소스를 만들어 전역 DNS 서버의 애니캐스트 CIDR 블록으로의 트래픽을 명시적으로 허용해야 합니다. 다음 단계를 따르세요.

모든 전역 애니캐스트 CIDR 블록을 찾습니다. 업데이트할 전역 애니캐스트 CIDR 블록을 찾으려면 다음 단계를 따르세요.
1. 루트 전역 API 서버에 연결합니다.
2. 다음 명령어를 사용하여 모든 네임스페이스에서 모든 서브넷 커스텀 리소스를 나열합니다.
```
kubectl get subnet -A
```
3. metadata.name 필터에 anycast 키워드가 포함된 서브넷 리소스를 찾도록 출력을 필터링합니다.
4. 이름에 anycast가 있는 각 서브넷 리소스에 대해 spec.subnet 값을 기록합니다. 이 값은 전역 애니캐스트 CIDR 블록을 나타냅니다.

루트 관리자 클러스터의 루트 네임스페이스에서 pnet-trafficpolicy-dc-override라는 SubcomponentOverride 커스텀 리소스를 만듭니다. 이전 단계에서 식별한 각 애니캐스트 서브넷에 대해 YAML 파일에 표시된 대로 규칙을 추가합니다.

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

다음을 바꿉니다.

INTERCONNECT_RULE_DESCRIPTION: 상호 연결 네트워크 규칙의 설명 텍스트
GLOBAL_ANYCAST_CIDR: 전역 애니캐스트 CIDR 블록(예: 136.125.38.128/28). 이전 단계에서 찾은 각 애니캐스트에 대해 이 YAML 파일을 사용하여 규칙을 만듭니다.
HAIRPIN_RULE_DESCRIPTION: 헤어핀 네트워크 규칙의 설명 텍스트

부분 DCI 실패로 인해 트래픽 손실이 발생함

버전: 1.14.3

증상: 한 영역의 보더 리프 스위치를 이동통신사 스위치에 연결하는 데이터 센터 상호 연결(DCI)의 두 링크 모두 또는 한 영역의 보더 리프 스위치에 하드웨어 장애가 발생하면 영역 간 네트워크 트래픽의 약 50%가 손실됩니다.

VRF 이름이 너무 김

버전: 1.14.2

증상: 이 명령어를 실행할 때 스위치가 정상 상태가 아님을 나타내는 다음 예시와 같은 메시지가 표시될 수 있습니다.

sh config-replace log verify

출력은 다음 예시와 같이 표시됩니다.

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

해결 방법: 조직 CR의 이름은 최대 19자(영문 기준)까지 가능합니다.

StatefulSet 포드 통신 실패

버전: 1.14.3, 1.14.4

해결됨: 1.14.3 핫픽스 23, 1.14.5

증상: StatefulSet 포드 재시작 후 Cilium 엔드포인트 (CEP) 객체 삭제가 올바르게 처리되지 않아 연결 문제 또는 중단이 발생합니다. 이로 인해 관리되지 않는 엔드포인트 ID로 인해 네트워크 정책이 적법한 트래픽을 잘못 삭제할 수 있습니다. 영향을 받는 포드는 해당 CEP 객체가 없는지 확인하여 확인할 수 있습니다.

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

해결 방법: 영향을 받는 StatefulSet 포드를 다시 시작하여 UID를 업데이트하고 연결된 메타데이터를 새로고침합니다.

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

데이터 네트워크에서 노드에 연결할 수 없음

이는 anetd 포드가 비정상 종료 루프에 걸린 경우 발생할 수 있는 드문 문제입니다.

노드 연결에 필수적인 커널 리소스가 손상된 상태로 멈출 수 있습니다.

이 가이드에서는 이 문제의 증상과 문제를 해결하기 위해 취할 수 있는 단계를 간략하게 설명합니다.

버전:

에어 갭이 적용된 Google Distributed Cloud(GDC)의 모든 버전이 영향을 받을 수 있습니다.

증상:

이 문제가 발생하면 다음과 같은 증상이 나타날 수 있습니다.

노드가 NotReady 상태로 멈춰 있음
노드를 설명하면 kubelet:kubelet was found unhealthy; repair flag : true 메시지가 표시됨
데이터 네트워크에서 노드에 대한 SSH 액세스를 할 수 없음

해결 방법:

다음 안내에 따라 비정상 노드를 복구하세요.

영향을 받는 노드의 관리 IP 주소를 가져옵니다.

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

영향을 받는 노드에 대한 SSH 액세스 권한을 획득합니다.
노드의 관리 IP 주소를 사용하여 SSH를 통해 노드에 연결합니다.
노드에서 다음 명령어를 실행한 후 SSH 연결을 종료합니다.
```
tc filter del dev bond0 egress
```

영향을 받는 노드가 있는 클러스터의 anetd DaemonSet를 다시 시작합니다.

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

모든 이그레스 허용 PNP를 만들면 예기치 않은 트래픽이 거부됨

버전:

에어 갭이 적용된 Google Distributed Cloud(GDC)의 모든 버전이 영향을 받을 수 있습니다.

증상: allow-all-egress 프로젝트 네트워크 정책(PNP)은 프로젝트 내 엔드포인트와 클러스터 외부의 외부 엔드포인트로의 트래픽을 허용하지만 시스템 엔드포인트로의 트래픽은 허용하지 않습니다. 이 문제로 인해 DNS 변환 및 객체 스토리지와 같은 시스템 및 퍼스트 파티 서비스 액세스가 차단될 수 있습니다.

allow-all-egress PNP는 다음과 같습니다.

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

해결 방법: allow-all-egress PNP를 삭제합니다. 기본적으로 데이터 무단 반출 방지가 사용 중지되면 클러스터 및 시스템 엔드포인트 외부의 프로젝트와 외부 엔드포인트로 트래픽이 허용됩니다.

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

멀티 영역 교차 영역 가용성 SLO Grafana 대시보드 문제

버전: 1.14.3

증상: Grafana에서 pnet-cross-zone-availability SLO 대시보드에 측정항목이 표시되지 않습니다.

해결 방법: PNET-P0001 런북에 따라 스위치 액세스 권한을 얻고 다중 영역 BGP 세션과 연결 상태를 수동으로 확인합니다.

데이터 영역 및 관리 인그레스 게이트웨이가 조정되지 않음

버전: 1.14.3

증상: 하위 구성요소 asm-dataplane-ingress 또는 asm-management-ingress가 다음 오류와 함께 조정되지 않습니다.

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

오류 문자열에서 BackendService 대신 사용할 수 있는 다른 값은 ForwardingRuleInternal 및 ForwardingRuleExternal입니다. 마찬가지로 리소스 이름이 management-ingress-gateway 대신 dataplane-ingress-gateway, dataplane-ingress-gateway-global 또는 management-ingress-gateway-global일 수 있습니다.

해결 방법: 리소스가 관리 API 서버에 있는지 아니면 전역 API 서버에 있는지 확인합니다. 이는 오류 문자열의 리소스 유형 API 버전에서 추론할 수 있습니다. 예를 들어 networking.gdc.goog 접미사가 있는 리소스는 관리 API 서버에 있는 반면 networking.global.gdc.goog 접미사가 있는 리소스는 글로벌 API 서버에 있습니다.

API 서버를 식별한 후 해당 kubeconfig 파일을 사용하여 리소스를 삭제합니다. 예를 들면 다음과 같습니다.

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

프로젝트 네트워크 정책 페이지는 ProjectNetworkPolicy API의 프로젝트 선택기 필드를 지원하지 않습니다.

버전: 1.14.3, 1.14.4

증상: projectSelector 필드가 포함된 프로젝트 네트워크 정책을 만들고 GDC 콘솔에서 이를 보면 UI에 projectSelector 필드의 프로젝트 대신 정책에 대해 선택된 모든 프로젝트가 표시됩니다.

해결 방법: API를 사용하여 projectSelector 필드가 포함된 프로젝트 네트워크 정책을 만들고 읽습니다.

운영체제

서버 프로비저닝 실패

버전: 1.14.3

증상: 서버 프로비저닝 중에 Harbor 레지스트리에서 OS 이미지를 다운로드할 때 해당 BaremetalHost 커스텀 리소스에 다음 401 오류가 표시될 수 있으며 서버가 프로비저닝 해제 및 재프로비저닝 루프에 멈춰 있습니다.

이러한 오류를 확인하려면 BaremetalHost 커스텀 리소스의 상세한 상태를 확인하세요.

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

출력은 다음 예시와 같이 표시됩니다.

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

해결 방법:

서버가 속한 nodePoolClaim의 이름과 네임스페이스를 가져옵니다.

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

출력은 다음 예시와 같이 표시됩니다.

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

NodePoolClaim에서 OS 이미지 이름을 가져옵니다.

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

OSImageMetadata에서 OS 이미지 URL을 가져옵니다.

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

최신 OS 이미지 URL로 Server 커스텀 리소스를 업데이트합니다.

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

OS NodeUpgrade가 NodeOSInPlaceUpgradePostProcessingCompleted 단계에서 멈출 수 있음

버전: 1.14.3, 1.14.4

증상:

노드 업그레이드 중에 NodeUpgradeTask가 NodeOSInPlaceUpgradePostProcessingCompleted 단계에서 failed verifying delta after upgrade 메시지가 포함된 조정자 오류로 멈춰 완료할 수 없습니다. 이 오류는 업그레이드 확인 프로세스에서 노드에 예기치 않은 패키지 불일치가 발견되었음을 나타냅니다. 특히 '업그레이드 필요' 상태에 있거나 업그레이드 시도 후 '새 버전에만 있음' 패키지로 표시되는 패키지를 식별합니다.

오류 메시지에는 확인에 실패한 특정 패키지가 표시됩니다. 스니펫 예:

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

이 증상은 두 가지 문제로 인해 발생할 수 있습니다. 먼저 원인이 되는 문제를 감지합니다.

Cause-A: 머신에 연결할 수 없어 OSArtifactSnapShot이 오래되었습니다.

업그레이드 중인 노드가 여전히 정상인지, 해당 OSArtifactSnapShot 작업이 실패하는지 확인합니다.

OSArtifactSnapShot가 오래되었고 20분 넘게 머신에 연결할 수 없는 경우 Mitigation-A로 진행합니다. 그렇지 않으면 Cause-B를 계속 확인합니다.
Cause-B: 자동 RPM 업그레이드 실패

드물지만 부분 업그레이드 후 머신의 RPM 업그레이드가 자동으로 실패할 수 있습니다. 업그레이드 전후의 패키지 차이가 포함된 ConfigMap가 두 개 있어야 합니다.
```
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
```
'after-upgrade'에 'before-upgrade' configmap보다 적은 수의 패키지가 포함되어 있으면 업그레이드가 자동으로 중단되었으며 일부 패키지가 업그레이드되지 않았음을 의미합니다. Mitigation-B로 이동합니다.

해결 방법:

Mitigation-A: 연결할 수 없는 머신 복구

머신을 재부팅하여 복구를 시도합니다. 재부팅을 시도한 후에도 머신에 연결할 수 없는 경우 SERV팀에 문의하여 추가 지원을 받으세요. 머신에 다시 연결할 수 있게 되면 OSArtifactSnapShot를 삭제하여 강제로 조정합니다. OSArtifactSnapShot가 조정되면 NodeUpgradeTask은 다음 단계로 진행해야 합니다.

Mitigation-B: NodeUpgradeTask 다시 시도

업그레이드 중인 머신에 SSH로 연결하고 향후 문제 해결을 위해 다음 로그를 수집합니다. 다음 파일을 수집해야 합니다.
- /var/log/dnf.log
- /var/log/dnf.rpm.log
- dnf history > dnf_history.log
- rpm -qa --last > rpm_last.log
실패한 NodeUpgradeTask을 삭제합니다. 이렇게 하면 특정 노드에서 NodeUpgradeTask 재시도가 트리거됩니다. 새 NodeUpgradeTask는 RPM 업그레이드를 완료하고 다음 단계로 진행해야 합니다.

OS NodeUpgrade가 패키지 서버 생성 단계에서 멈출 수 있음

버전: 1.14.3, 1.14.4

증상:

NodeUpgrade CR이 생성되고 일시중지 해제된 후 30분 이상 in-progress 상태로 유지되면 패키지 서버 생성 단계에서 자동으로 실패할 수 있습니다. 증상은 NodeUpgrade가 .status.upgradeStatus=in-progress와 함께 유지되지만 .status.tasks가 로드되지 않는 것입니다.

status:
  duration: 0s
  upgradeStatus: in-progress

패키지 서버 생성 시 실패하는지 추가로 확인하려면 OS 업그레이드 컨트롤러 로그를 읽으세요.

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

컨트롤러 로그에 failed to create package server 및 failed to create package repo server DNS registration이 자세한 이유 (다음 중 하나)와 함께 표시되는 경우

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

그런 다음 다른 NodeUpgrade에서 사용하는 다른 패키지 서버 리소스가 아직 활성 상태이며 현재 중단된 NodeUpgrade에 대해 생성될 리소스와 충돌한다고 제안합니다.

해결 방법:

추가로 확인하려면 실제 패키지 서버 리소스 (NodeUpgrade CR을 관리하는 클러스터의 관리 API 서버에 있는 dnsregistration.network.private.gdc.goog와 같은 특정 API)를 확인하고 해당 리소스를 소유하는 NodeUpgrade를 찾으면 됩니다. DNSRegistration를 소유한 NodeUpgrade가 이미 완료되었지만 DNSRegistration 리소스가 아직 삭제되지 않은 경우 참조된 모든 NodeUpgrade 객체가 완료되면 DNSRegistration 객체를 삭제할 수 있습니다.

NodeUpgrade 패키지 서버의 모든 DNSRegistration CR을 나열합니다.

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

특정 DNSRegistration의 소유자 NodeUpgrade CR을 쿼리합니다.

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

노드 OS 업그레이드 시 문제가 발생하여 프로세스의 어느 단계에서든 중단될 수 있습니다.

버전: 1.14.4, 1.14.5, 1.14.6

증상:

NodeUpgradeTask CR이 2시간 이상 in-progress 상태로 유지되지만 시간이 충분하면 자동 완성될 수 있습니다.

NodeUpgradeTask CR이 2시간 이상 진행 중입니다. 결국 자동 완성될 수도 있지만 근본적인 문제는 os-policy-reconciler가 많은 양의 OSPolicy CR을 효율적으로 관리할 수 없다는 것입니다. 이 문제는 NodeOSInPlaceUpgradeCompleted 단계에서 발생합니다.

패키지 서버 생성 중에 이 실패를 추가로 확인하려면 OS 업그레이드 컨트롤러 로그를 참고하세요.

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

컨트롤러 로그에 NodeUpgradeTask의 OSPolicy 항목이 없으면 컨트롤러가 과부하 상태임을 나타냅니다.

해결 방법:

업그레이드 프로세스 중에 필수적이지 않은 모든 OSPolicy CR을 일시중지합니다.

큰 파일의 'storage cp'로 인해 org-mgmt kube-api가 다운됨

버전: 1.14.3 이상

증상: OIC 워크스테이션에서 gdcloud storage cp 작업 또는 gdcloud system container-registry load-oci 작업을 실행하는 동안 조직 인프라에 대한 액세스가 손실되고 org-mgmt의 kube-api이 다운될 가능성이 약간 있습니다. 드문 문제이므로 엔지니어링을 위해 데이터를 수집하는 것이 좋습니다.

해결 방법: 이 문제가 발생하면 다음 단계를 시도해 보세요.

각 컨트롤 플레인 (CP) 노드에서 uptime를 실행하여 지난 24시간 이내에 노드가 재부팅되었는지 확인합니다.
재부팅 시간을 기록합니다.
dmesg | grep -i 'kernel panic'를 실행하여 재부팅 직전에 발생한 각 CP 노드의 커널 패닉을 확인합니다.
각 CP 노드에서 lspci | grep -i eth | grep -i mellanox를 실행하여 Mellanox NIC 카드가 설치되어 있는지 확인합니다. Mellanox NIC가 없으면 이 알려진 문제 읽기를 중단하세요.

각 CP 노드에서 data0의 다음 네트워크 설정을 확인합니다.

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

모든 노드에서 rx-gro-hw (위 참고)가 'off'으로 설정된 경우 이 알려진 문제 읽기를 중지하세요.

Google에서 문제를 진단할 수 있도록 다음 정보를 수집하세요.

k8s.org get po -n anthos-identity-service -l k8s-app=ais

k8s.org get po -n management-kube-system

k8s.org get po -n kube-system -l component=kube-apiserver

k8s.org get nodes -l node-role.kubernetes.io/control-plane

각 CP 노드에서 다음 명령어를 실행합니다.

dmesg | grep -i 'kernel panic'

journalctl -u disable-rx-gro-hw.service

systemctl status disable-rx-gro-hw

modinfo mlx5_core | grep ^version:

네트워크 설정 문제를 완화하려면 모든 CP 노드에서 다음 명령어를 실행하여 rx-gro-hw을 off로 전환해야 합니다.

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

설정을 다시 확인합니다.

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

gdcloud storage cp 또는 gdcloud system container-registry load-oci과 같은 원래 작업을 재시도합니다. 그래도 실패가 계속되면 엔지니어링팀에 문의하세요.

운영 제품군 인프라 핵심 서비스(OIC)

jumphost 성능이 저조함

버전: 에어 갭이 적용된 모든 버전의 Google Distributed Cloud(GDC)가 영향을 받을 수 있습니다.

증상: 브라우저 또는 시스템 작업이 작업을 완료하는 데 과도한 시간이 걸립니다.

해결 방법:

BM03 및 BM04의 Hyper-V 관리자를 통해 jumphost의 vCPU 수를 늘립니다.

jumphost VM을 선택한 다음 작업 창에서 설정을 클릭합니다.
프로세서를 선택한 다음 워크로드에 따라 가상 프로세서 수를 4 이상으로 늘립니다.
나머지 jumphost에 대해서도 반복합니다.

Resource Manager

GDC 콘솔에서 프로젝트를 삭제할 수 없음

버전: 1.14.3, 1.14.4

증상: GDC 콘솔의 프로젝트 세부정보 페이지에 기존 프로젝트를 위한 삭제 삭제 버튼이 제공되지만 버튼이 작동하지 않습니다.

해결 방법: 기존 프로젝트를 삭제하려면 gdcloud CLI를 사용해야 합니다. 자세한 내용은 프로젝트 삭제를 참고하세요.

조직 Ansible 플레이북 누락

버전: 1.14.3

증상: 조직을 만들 때 필수 Ansible 플레이북을 만드는 작업 create-ansible-playbooks이 자동으로 실패합니다. Ansible 플레이북이 누락되면 경계 가상 머신이 누락되고 전역 조직을 만드는 데 문제가 발생하는 등의 문제가 발생합니다.

해결 방법: OS-R0009 런북에 따라 누락된 조직 Ansible 플레이북을 수동으로 만듭니다.

비대칭 전역 조직에 존재하지 않는 영역 구성이 표시됨

버전: 1.14.4

증상: 일부 지역 조직 구성만 사용하여 v1 전역 조직을 만들면 모든 지역에 조직 복제본 상태가 계속 표시됩니다. 예를 들어 영역이 3개인 GDC 유니버스가 있지만 영역 2개에 대해서만 영역별 조직 구성을 만드는 경우 세 번째 영역에는 존재하지 않는 세 번째 영역별 조직에 대한 잘못된 복제본 상태가 계속 표시됩니다.

잘못된 상태를 확인하려면 전역 조직의 상태를 출력하세요.

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

YAML 출력은 다음과 유사합니다.

...

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

...

비대칭 영역 구성은 v2 조직에서 지원되지 않으므로 이 문제는 v1 조직에서만 발생합니다.

해결 방법: 특별히 생성하지 않는 한 영역별 조직이 존재하지 않으므로 잘못된 복제본 상태를 무시해도 됩니다.

클러스터

인프라 클러스터 작업자 노드 풀이 삭제되지 않음

버전: 1.14.3, 1.14.4

증상: Organization CR 사양에서 작업자 노드 풀을 삭제할 때 노드 풀이 자동으로 삭제되지 않습니다. 즉, kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} 명령어는 여전히 삭제할 노드 풀을 출력합니다.

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

해결 방법: Organization CR 사양에서 작업자 노드 풀을 삭제한 후 다음 명령어를 실행하여 루트 관리자 클러스터에서 이 노드 풀의 NodePoolClaim CR을 수동으로 삭제합니다. sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

NodePoolClaim 및 연결된 NodePool CR이 완전히 삭제될 때까지 기다립니다. 즉, kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} 명령어에서 더 이상 작업자 노드 풀이 출력되지 않습니다.

스토리지

`gdcloud config set zone` 명령어로 만든 버킷이 삭제되지 않음

버전: 1.14.7 이상

증상: gdcloud config set zone 명령어로 생성된 버킷이 삭제되지 않습니다. 이 명령어는 잘못된 영역에서 작동하려고 하기 때문에 권한 문제가 발생합니다.

해결 방법: 콘솔을 사용하여 버킷의 특정 영역을 설정하거나 gdcloud 명령어에서 --zone 플래그를 --location로 바꿉니다.

OBJ SLO 알림 실행

버전: 1.14.3, 1.14.4

증상: OBJ 프록시의 ErrFailedStreamingDecryptRequest 오류로 인해 OBJ의 SLO 알림이 실행됩니다(obj-list-object-ops-availability-slo, obj-rw-object-ops-error-rate-slo).

해결 방법: 알림을 음소거합니다. 사용자가 연결을 종료하여 발생한 오류는 SLO에 포함되지 않지만 시스템 오류로 잘못 식별됩니다.

S3 UploadPart ETag가 비어 있음

버전: 1.14.3

증상: UploadPart 요청을 보낸 후 응답 메시지에 200 Success 상태 코드가 표시되지만 ETag 필드가 비어 있습니다. 이 오류는 네트워크 중단으로 인해 InternalServerError가 발생하고 상태 코드가 500 InternalServerError로 업데이트되지 않기 때문에 발생합니다.

해결 방법: 이전에 실패한 것처럼 요청을 다시 시도합니다.

Trident `mkfs.ext4` 오류로 인해 포드를 마운트할 수 없음

버전: 1.14.3

증상: 포드를 마운트하려고 하면 특정 노드로 전환되거나 특정 노드에서 전환되는 모든 포드가 실패합니다. 노드가 멈췄음을 나타내는 rpc 오류 메시지 DeadlineExceeded desc = context deadline exceeded가 표시됩니다. 이 메시지가 표시되면 해당 노드에서 추가 Trident 작업을 실행할 수 없습니다. 데이터를 제공하는 볼륨은 영향을 받지 않지만 노드로 이동하거나 노드에서 이동하는 볼륨은 서비스 중단이 발생할 수 있습니다.

해결 방법:

포드가 마운트하려고 하는 노드에서 Trident 로그를 검사하고 대기열이 증가하는지 확인합니다. 로그는 다음과 비슷하게 표시됩니다.

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

노드에 로그인하고 dmesg 출력을 확인합니다. 로그는 다음과 비슷하게 표시됩니다.

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

Trident mkfs.ext4 오류가 발생했는지 확인한 후 노드를 재부팅합니다.

이미 존재하는 오류로 인해 Trident가 볼륨을 만들지 못함

버전: 1.14.3

증상:

PVC가 프로비저닝되지 않고 다음과 같은 이벤트가 표시됩니다.

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

이 이벤트가 발생하면 해결 방법을 수행할 때까지 PVC가 프로비저닝되지 않습니다.

해결 방법:

이 문제를 해결하려면 다음 단계를 따르세요.

이벤트에서 내부 볼륨 이름을 기록합니다. 예를 들어 증상 섹션에 표시된 샘플 이벤트에는 내부 볼륨 이름 trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a이 표시됩니다.
FILE-R0105 런북에 따라 ONTAP에 액세스합니다.

볼륨을 삭제합니다.

volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a

`file_block_iscsi_sessions_unhealthy alert`에서 거짓양성 보고

버전: 1.14.3

증상: 일부 환경에서 하나 이상의 노드에 iSCSI 장애가 발생했음을 나타내는 file_block_iscsi_sessions_unhealthy 알림이 발생합니다. file-observability 컨트롤러는 맞춤 측정항목 수집기를 사용하여 각 Kubernetes 노드에서 iSCSI 세션의 상태를 추적하지만, 경우에 따라 측정항목 수집기가 iscsiadm 명령의 출력을 파싱할 수 없어 iSCSI에 정상 세션이 있더라도 실행 중인 iSCSI 세션을 0으로 보고합니다.

해결 방법:

다음 단계에 따라 iSCSI에 문제가 없는지 확인하고 알림이 실제로 오탐지인 경우 알림을 무음으로 설정하세요.

Grafana의 탐색 페이지에서 fb_sessions_running_count{job="file-observability-backend-target.file-system"} 쿼리를 실행합니다. 이 쿼리는 클러스터의 모든 노드에 대한 측정항목을 반환합니다. 노드에서 fb_sessions_running_count 측정항목이 0으로 보고되는 경우 노드 이름을 적어 둡니다.
fb_sessions_running_count 측정항목이 0를 반환하는 각 노드에 대해 다음 명령어를 실행합니다.
1. 영향을 받는 노드와 SSH 연결을 설정합니다.
2. iscsiadm -m session 명령어를 실행합니다. 여러 줄이 반환되어야 합니다. 각 줄은 실행 중인 iSCSI 세션입니다. 명령어에서 반환되는 항목이 없거나 출력에 오류가 있는 경우 파일 차단 엔지니어링팀에 문제를 에스컬레이션합니다.
3. 이전 명령어에서 iSCSI 세션을 성공적으로 반환했다면 이 노드의 알림이 거짓양성임을 확인한 것입니다.
영향을 받는 모든 노드에 정상적인 iSCSI 세션이 있고 잘못된 알림이 트리거되는 것을 확인한 경우 AlertManager에서 무음을 만들어 file_block_iscsi_sessions_unhealthy 알림을 무음으로 설정합니다.

예비 디스크에 대한 `file_block_storage_disk_failure` 알림이 발생함

버전: 1.14.3

증상: 일부 환경에서 ONTAP의 디스크가 하나 이상 비정상임을 나타내는 file_block_storage_disk_failure 알림이 발생합니다. file-observability 컨트롤러는 맞춤 측정항목 수집기를 사용하여 ONTAP의 각 디스크 상태를 추적하지만 이전 버전의 GDC에서는 수집기가 예비 디스크를 정상으로 간주하지 않아 예비 디스크에 대한 알림이 트리거됩니다.

해결 방법:

다음 단계에 따라 디스크가 예비 디스크인지 확인하고 디스크에 대한 알림을 무음으로 설정하세요.

Grafana의 탐색 페이지에서 disks_labels_healthy{job="file-observability-backend-target.file-system"} 쿼리를 실행합니다. 이 쿼리는 ONTAP의 모든 디스크에 대한 측정항목을 반환합니다. 디스크에서 0 (비정상) 측정항목을 보고하는 경우 디스크 이름을 적어 둡니다.
disks_labels_healthy 측정항목이 0를 반환하는 각 디스크에 대해 다음 명령어를 실행합니다.
1. ONTAP 클러스터에 SSH로 연결하고 측정항목 쿼리에서 수집한 디스크 이름을 사용하여 disk show -disk <disk-name> -fields state 명령어를 실행합니다.
2. 명령어 출력에 디스크 상태가 present 또는 spare으로 표시되는지 확인합니다. 디스크가 present 또는 spare 이외의 상태인 경우 파일 블록 엔지니어링팀에 문제를 에스컬레이션합니다.
3. 문제가 있는 디스크가 present 또는 spare를 보고하는 경우 이 디스크에 대한 알림이 트리거되지 않음을 확인할 수 있습니다. AlertManager에서 무음을 만들어 disk_name 라벨이 디스크 이름으로 설정된 file_block_storage_disk_failure 알림을 무음 처리합니다.
모든 예비 디스크에 대해 무음이 생성되면 Grafana로 이동하여 알림이 중지되었는지 확인합니다.

연결이 복원된 후 file_block_storage_node_peer_connection_unhealthy 알림이 발생함

버전: 1.14.3

증상: 일부 환경에서 ONTAP 노드 간의 연결이 하나 이상 실패했음을 나타내는 file_block_storage_node_peer_connection_unhealthy 알림이 발생합니다. file-observability 컨트롤러는 맞춤 측정항목 수집기를 사용하여 이러한 연결의 상태를 추적합니다. 연결 실패가 복원된 후에도 이 알림이 계속 발생하는 알려진 문제가 있습니다.

해결 방법:

다음 단계에 따라 노드 간 연결이 정상인지 확인하고 노드에 대한 알림을 무음으로 설정하세요.

Grafana의 탐색 페이지에서 storage_node_peer_connections{job="file-observability-backend-target.file-system"} 쿼리를 실행합니다. 이 쿼리는 클러스터의 스토리지 노드 간 모든 연결에 대한 측정항목을 반환합니다. 연결 중 하나에서 0의 storage_node_peer_connections 측정항목을 보고하는 경우 측정항목의 source_node, destination_ip, storage_cluster_name 라벨을 적어 둡니다.
0을 반환하는 각 storage_node_peer_connections 측정항목에 대해 다음 명령어를 실행합니다.
1. storage_cluster_name 라벨에서 ONTAP 스토리지 클러스터와 SSH 연결을 설정합니다.
2. source_node 및 destination_ip 라벨의 값을 사용하여 ONTAP 클러스터에서 다음 명령어를 실행합니다.
```
ping -node <node-name> -destination <destination-ip> -verbose -show-detail
```
ping 명령어가 실패하면 파일 차단 엔지니어링팀에 문제를 에스컬레이션합니다. ping 명령어가 성공하면 노드 연결이 정상이고 알림이 잘못 트리거된 것입니다.
1. AlertManager에서 무음을 만들어 측정항목의 소스 노드와 대상 IP로 설정된 source_node 및 destination_ip 라벨이 있는 file_block_storage_node_peer_connection_unhealthy 알림을 무음으로 설정합니다.
정상 노드에 대해 모두 무음이 생성되면 Grafana로 이동하여 알림이 중지되었는지 확인합니다.

연결이 복원된 후 file_block_nodes_not_reachable 알림이 발생함

버전: 1.14.3

증상: 일부 환경에서 Kubernetes 노드의 IPsec 서비스에서 ONTAP로의 하나 이상의 연결이 실패했음을 나타내는 file_block_nodes_not_reachable 알림이 발생합니다. file-observability 컨트롤러는 맞춤 측정항목 수집기를 사용하여 이러한 연결의 상태를 추적합니다. 연결 실패가 복원된 후에도 이 알림이 계속 발생하는 알려진 문제가 있습니다.

해결 방법:

다음 단계에 따라 노드의 연결이 정상인지 확인하고 노드의 알림을 무음으로 설정하세요.

Grafana의 탐색 페이지에서 fb_all_nodes_reachable{job="file-observability-backend-target.file-system"} 쿼리를 실행합니다. 이 쿼리는 클러스터의 모든 노드에 대한 측정항목을 반환합니다. 노드에서 fb_all_nodes_reachable 측정항목이 0으로 보고되는 경우 노드 이름을 적어 둡니다.
fb_all_nodes_reachable 측정항목이 0를 반환하는 각 노드에 대해 다음 명령어를 실행합니다.
1. 영향을 받는 노드와 SSH 연결을 설정합니다.
2. 다음 명령어를 실행합니다.
```
journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh
```
  이 명령어는 모든 IPsec 연결을 사용하여 ontap에 핑을 시도합니다. 명령어의 핑이 실패하면 파일 차단 엔지니어링팀에 문제를 에스컬레이션합니다. 핑 명령어가 성공하면 노드 연결이 정상이고 알림이 잘못 트리거된 것입니다.
3. 명령어의 모든 핑이 성공하면 노드의 연결이 정상이며 알림이 잘못 트리거된 것입니다. AlertManager에서 무음을 만들어 node_name 라벨이 노드 이름으로 설정된 file_block_nodes_not_reachable 알림을 무음 처리합니다.
정상 노드에 대해 모두 무음이 생성되면 Grafana로 이동하여 알림이 중지되었는지 확인합니다.

`file_block_storage_high_node_total_latency` 경고가 과도한 워크로드 중에 발생함

버전: 1.14.3

증상: 스토리지 노드의 워크로드가 많아 특정 환경에서 file_block_storage_high_node_total_latency 알림이 트리거될 수 있습니다. 이 알림은 이러한 워크로드가 완전히 처리될 때까지 계속 표시됩니다. 볼륨의 읽기 및 쓰기 성능이 빠른 경우에도 스토리지 노드에서 특정 블록 작업의 지연 시간이 높다고 보고할 수 있습니다.

해결 방법:

정상적인 볼륨 지연 시간을 확인하고 스토리지 노드 지연 시간 알림을 무음으로 설정하려면 다음 단계를 따르세요.

볼륨 지연 시간 알림 확인:
1. Grafana에서 file_block_storage_high_volume_write_latency 및 file_block_storage_high_volume_read_latency 알림이 트리거되지 않고 볼륨에 대한 최적의 지연 시간을 보고하는지 확인합니다.
볼륨 지연 시간이 높은 경우 에스컬레이션합니다.
1. 볼륨 쓰기 또는 볼륨 읽기 알림이 발생하면 전체 스토리지 시스템에 지연 시간이 높다는 것을 나타냅니다. 이 문제를 파일 차단 엔지니어링팀에 에스컬레이션합니다.
볼륨이 정상인 경우 노드 지연 시간 알림을 음소거합니다.
1. 볼륨 쓰기 및 볼륨 읽기 알림이 모두 정상인 경우 노드 지연 시간 알림이 거짓양성일 가능성이 높습니다.
2. AlertManager에서 file_block_storage_high_node_total_latency 알림에 대한 무음을 만듭니다.
3. 무음 처리를 만든 후 Grafana로 이동하여 알림이 트리거되지 않는지 확인합니다.

차단된 노드 업그레이드

버전: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

증상: 이 차단은 스냅샷 문제로 인해 LUN (논리 단위 번호)이 읽기 전용이 될 때 발생합니다. 이 경우 영향을 받는 포드를 다른 노드로 이동하기 위해 노드가 차단됩니다. 노드 업그레이드 프로세스에는 노드가 차단되지 않도록 하는 사전 검사가 있으므로 이 상태에서는 업그레이드가 진행되지 않습니다.

해결 방법: 업그레이드 프로세스를 시작하기 전에 file-read-only-lun-cleanup 하위 구성요소를 수동으로 사용 중지합니다.

영향을 받는 각 조직을 식별합니다.

환경의 각 조직에 SubcomponentOverride를 적용합니다.

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

영향을 받는 조직의 노드 중 차단된 노드가 없는지 확인합니다.

조직의 노드를 나열합니다.

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

출력은 다음과 비슷합니다.

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

상태가 SchedulingDisabled인 노드의 이름을 기록합니다. 이 샘플 출력에서 차단된 노드는 admin-node0-zone1입니다.

이전 단계에서 SchedulingDisabled 상태를 반환한 노드의 코돈을 해제합니다.
```
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
```

모든 노드가 준비되었는지 확인합니다.

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

출력은 다음과 비슷합니다.

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

멀티 경로 오류가 해결된 후 `file_block_zombie_luns_present` 알림이 발생함

버전: 1.14.3 이상

증상: file-observability 컨트롤러가 multipath -ll 명령어의 출력을 파싱하지 못하여 특정 환경에서 file_block_zombie_luns_present 알림이 트리거될 수 있습니다. 이로 인해 모든 노드에서 멀티 경로 서비스가 정상인 경우에도 좀비 LUN 알림이 계속 발생합니다.

해결 방법:

문제가 있는 노드에서 정상적인 멀티 경로 서비스를 확인하려면 다음 단계를 따르세요.

Grafana의 탐색 페이지에서 zombie_lun_exists{job="file-observability-backend-target.file-system"} 쿼리를 실행합니다. 이 쿼리는 클러스터의 모든 노드에 대한 측정항목을 반환합니다. 노드에서 zombie_lun_exists 측정항목이 1으로 보고되면 노드 이름을 적어 둡니다.
zombie_lun_exists 측정항목이 1를 반환하는 각 노드에 대해 다음 명령어를 실행합니다.
1. 영향을 받는 노드와 SSH 연결을 설정합니다.
2. 다음 명령어를 실행합니다.
```
multipath -ll
```
  이 명령어는 멀티패스 서비스에서 관리하는 모든 블록 기기에 관한 정보를 반환합니다. 블록 기기 상태에 failed undef unknown 문자열이나 failed faulty running 문자열이 포함되어 있지 않은지 확인합니다.
3. 기기에 failed faulty running 상태가 포함된 경우 FILE-R0020 런북에 따라 고스트 LUN을 해결합니다.
4. 기기에 failed undef unknown 상태가 포함된 경우 FILE-R0021 런북에 따라 슈퍼 좀비 LUN을 해결합니다.
노드가 정상인 경우 좀비 LUN 알림을 음소거합니다.
1. 노드에서 유효하지 않은 블록 기기가 발견되지 않으면 좀비 LUN 알림은 거짓양성입니다.
2. AlertManager에서 file_block_zombie_luns_present 알림에 대한 무음을 만듭니다.
3. 무음 모드를 만든 후 ServiceNow로 이동하여 알림이 중지되었는지 확인합니다.

콘솔에서 빈 버킷을 삭제할 수 없음

버전: 1.14.4 이상

증상: GDC 콘솔에서 빈 버킷을 삭제할 수 없습니다. 보관 정책과 함께 객체 버전 관리가 사용 설정된 경우 버킷에 삭제 마커와 객체의 다른 버전이 있을 수 있습니다. 다음과 같은 오류가 표시될 수 있습니다.

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

해결 방법: gdcloud storage rm -a 명령어를 사용하여 삭제 마커를 비롯한 객체를 삭제하여 버킷을 삭제할 수 있도록 합니다.

시스템 아티팩트 레지스트리

Harbor 복제 작업이 멈춤

버전: 1.14.3

증상: Harbor 아티팩트 복제 작업이 멈춥니다. 이 문제로 인해 조직에 아티팩트가 배포되지 않고 조직 생성이 중지됩니다.

해결 방법: 이 문제를 완화하려면 SAR-R1010 런북의 단계를 따르세요.

Harbor 로봇 계정 커스텀 리소스를 조정할 때 일시적인 오류 상태가 지워지지 않음

버전: 1.14.3

증상: kind=HarborRobotAccount 및 code=SAR2002로 라벨이 지정된 CustomResourceErrorStatusAlert 알림이 잘못 실행됩니다. 예를 들어 잘못된 알림의 message 필드가 'Error getting robot: failed to list robots: 503 Service Unavailable'로 설정되어 있습니다.

해결 방법: 인프라 운영자 (IO)에게 알림이 실제 문제인지 아니면 잘못된 알림인지 확인해 달라고 요청하고, 잘못된 알림인 경우 다음 안내에 따라 알림을 무음으로 설정하세요.

알림이 트리거되면 런북 SAR-E2002에 따라 알림의 근본 원인을 파악하고 해결합니다.

이 알려진 문제로 인해 런북에서 근본 원인을 성공적으로 해결하더라도 알림이 잘못 계속 발생할 수 있습니다. 알림이 전송되는 대상 HarborRobotAccount (HRD) 커스텀 리소스 (CR) 객체의 오류 상태를 계속 확인합니다.

필수 환경 변수를 설정합니다.
```
export KUBECONFIG=KUBECONFIG
export HRD_NAME=HRD_NAME
export HRD_NAMESPACE=HRD_NAMESPACE
```
다음을 바꿉니다.
- KUBECONFIG: kubeconfig 파일의 경로
- HRD_NAME: 대상 HarborRobotAccount CR의 이름입니다.
- HRD_NAMESPACE: 타겟 HarborRobotAccount CR을 포함하는 네임스페이스입니다.

타겟 HarborRobotAccount CR의 오류 상태를 확인합니다.

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

lastUpdateTime 값이 errorStatus 필드가 30분 전에 마지막으로 업데이트되었음을 나타내는 경우 알림은 잘못된 알림입니다. 잘못된 알림을 완화하려면 MON-R2009 런북에 따라 GDC 에어 갭 인스턴스 내에서 알림을 음소거하세요.

SAR-R0003 알림의 잘못된 알림

버전: 1.14.3 이상

증상: 코드 SAR-R0003, OC SAR, 심각도 critical의 알림이 잘못 트리거됩니다.

해결 방법: MON-R2009 런북에 따라 알림을 음소거합니다.

티켓팅 시스템

ServiceNow MID 서버가 제대로 시작되지 않음

버전: 1.14.3

Fixed(해결됨): 1.14.4

증상: Splunk와 통합되는 ServiceNow MID 서버가 버전 불일치로 인해 시작 시 ServiceNow에 등록되지 않습니다.

해결 방법:

ts-mid-server 하위 구성요소를 일시중지합니다.

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

MID 서버 버전 문자열을 재정의합니다.

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

업그레이드

클러스터 업그레이드가 완료된 후 공유 서비스 클러스터 주석이 업데이트되지 않음

버전: 1.14.4

증상: 업그레이드 후 clusters.baremetal.cluster.gke.io의 경계 및 공유 서비스 클러스터 CR이 올바른 GKE 버전을 반영합니다. clusters.cluster.gdc.goog CR에는 이전 GKE 버전이 계속 표시됩니다.

해결 방법: clusters.baremetal.cluster.gke.io의 upgrade.gdc.goog/version 주석을 업그레이드된 GKE 버전에 해당하는 새 UserClusterMetadata 이름으로 업데이트합니다.

조직 관리자 노드 업그레이드가 중단됨

버전: 1.14.6

Fixed(해결됨): 1.14.7

증상: gdchservices 조직의 관리 컨트롤 플레인 노드 업그레이드 프로세스가 멈춥니다. 노드에 대한 SSH 연결을 설정할 수 없어 노드 업그레이드가 실패하고 Connection timed out 오류가 발생합니다.

부가기능 업그레이드가 중단됨

버전: 1.14.6

Fixed(해결됨): 1.14.7

증상: 이전 1.14.x 버전에서 1.14.6으로 업그레이드하는 동안 루트 관리자 클러스터의 부가기능 업그레이드가 중단됩니다. 상태 메시지에 업그레이드가 예상 시간 제한을 초과했다고 표시될 수 있습니다.

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

해결 방법: 새 버전의 올바른 템플릿을 가리키도록 루트 관리자 addonset 리소스의 spec.addOnSetTemplateRef를 수동으로 업데이트합니다.

지원 보고서가 실패함

버전: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Fixed(해결됨): 1.14.7

증상: 권한 문제로 인해 사용자 클러스터에서 실행될 때 gdcloud resource-support get-report 명령어가 실패합니다.

OS 노드 업그레이드가 완료된 후 VM 부팅이 멈출 수 있음

버전: 1.14.6

증상: 1.14.3~1.14.6 업그레이드 중에 경계 또는 공유 서비스 클러스터의 가상 머신이 부팅되지 않고 OS 업그레이드 후 연결할 수 없게 됩니다.

예를 들어 다음 명령어를 통해 문제를 확인할 수 있습니다.

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

VM 콘솔 로그 출력에 다음과 유사한 커널 패닉 메시지가 표시됩니다.

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

해결 방법: 이 문제를 해결하려면 다음 단계를 완료하세요.

다음 환경 변수를 설정합니다.

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

실패한 VM을 중지합니다.

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

편집기를 열어 실패한 VM에서 부팅 디스크를 분리합니다.

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

VM 사양에서 부팅 디스크를 자리표시자 이름으로 바꿉니다.

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

시작 스크립트 보안 비밀을 만듭니다.

cat <<'EOF' > script
#!/bin/bash
username="newuser"
password="Lime+blaze8legend"
sudo useradd -m -s /bin/bash "$username"
echo "$username:$password" | sudo chpasswd
sudo usermod -aG sudo "$username"
EOF

kubectl --kubeconfig=$MP_KUBECONFIG create secret generic configure-password -n $VM_NAMESPACE --from-file=script

도우미 VM을 만듭니다.

VM 부팅 디스크의 VM 이미지를 가져옵니다. 이미지의 OS 계열이 문제 VM 노드 부팅 디스크와 동일하면 안 되므로 grep를 사용하여 Ubuntu 이미지를 찾습니다.

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

VM 부팅 디스크와 VM을 만듭니다. 연결된 보조 디스크와 콘솔 액세스용 시작 스크립트를 사용하여 새 부팅 디스크와 새 VM을 만듭니다.

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

헬퍼 VM이 실행 중인지 확인합니다.

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

콘솔을 헬퍼 VM에 연결하고 initramfs를 재생성합니다.

콘솔에서 헬퍼 VM으로 연결:

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

다음 사용자 인증 정보를 사용합니다.

username="newuser"

password="Lime+blaze8legend"

연결된 디스크의 파티션을 마운트합니다.

sudo mkdir /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/sdb2 /mnt/kernelpanic/boot/
sudo mount /dev/sdb1 /mnt/kernelpanic/boot/efi/
sudo mount /dev/rocky/rl-home /mnt/kernelpanic/home/
sudo mount /dev/rocky/rl-var /mnt/kernelpanic/var/
sudo mount /dev/rocky/rl-var_tmp /mnt/kernelpanic/var/tmp/
sudo mount /dev/rocky/rl-var_log /mnt/kernelpanic/var/log/
sudo mount /dev/rocky/rl-var_log_audit /mnt/kernelpanic/var/log/audit/
sudo mount /dev/rocky/rl-tmp /mnt/kernelpanic/tmp/

sudo mount -t sysfs sysfs /mnt/kernelpanic/sys/
sudo mount -t proc procfs /mnt/kernelpanic/proc/
sudo mount -t devtmpfs devtmpfs /mnt/kernelpanic/dev/
sudo mount -t devpts devpts /mnt/kernelpanic/dev/pts/
sudo mount -o bind /dev/pts/ /mnt/kernelpanic/dev/pts/

마운트 지점에 chroot 연결을 설정하고 initramfs를 재생성합니다.
```
sudo chroot /mnt/kernelpanic/
dracut --regenerate-all --force
```

새 커널 버전 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64의 새 initramfs가 생성되었는지 확인합니다.

ls /boot/initramfs-* -l

결과는 다음과 유사합니다.

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

도우미 VM을 중지합니다.

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

헬퍼 VM에서 디스크를 분리합니다.

편집기에서 헬퍼 VM 사양을 엽니다.

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

YAML 파일에서 다음 코드를 삭제합니다.

- virtualMachineDiskRef:
    name: PROBLEM_VM_BOOT_DISK
  autoDelete: false

실패한 VM에 부팅 디스크를 다시 연결합니다.

실패한 VM의 사양을 편집기에서 엽니다.

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

다음과 같이 사양을 업데이트합니다.

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

실패한 VM을 시작합니다.

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

업그레이드가 수정되었는지 확인합니다.

이 VM의 Node 커스텀 리소스에 Ready이 표시되고 최신 커널 버전 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64이 사용되는지 확인합니다.

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

출력은 다음과 비슷합니다.

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

VM에 SSH 연결을 설정한 후 커널 버전을 확인합니다.
```
uname -a
```
출력에 새 커널 버전 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64이 표시되어야 합니다.

인제스터가 비정상 상태로 유지되고 업그레이드 후 자동으로 삭제되지 않음

버전: 1.14.x

증상: 업그레이드 후 log-infra 하위 구성요소가 정상 상태가 아닙니다. 확인하려면 다음을 실행하세요. none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra 하위 구성요소의 상태를 확인하려면 KUBECONFIG에는 상위 클러스터의 kubeconfig를 사용하고 CLUSTER_NAMESPACE에는 현재 클러스터의 네임스페이스를 사용해야 합니다. 이 명령어는 하위 구성요소의 상태를 반환합니다. 상태가 ReconciliationCompleted이 아니면 해당 클러스터에서 하위 구성요소가 비정상임을 나타냅니다.

클러스터의 일부 Loki 포드가 비정상입니다. 모든 Loki 포드를 나열하려면 다음을 실행합니다. none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' 이 명령어는 STATUS 및 READY 열을 포함한 모든 Loki 포드를 표시합니다. 포드의 상태가 Running가 아니거나 일부 컨테이너가 준비되지 않은 경우 포드가 비정상으로 간주됩니다. a/b 형식으로 지정된 READY 열은 총 b 중 준비된 컨테이너 a의 수를 나타냅니다. a와 b이 같으면 포드가 정상입니다.

비정상 Loki 포드의 로그를 확인합니다. none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

비정상 포드의 샘플 출력 로그는 다음과 같습니다.

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

해결 방법: Loki 링에서 비정상 인제스터를 삭제하려면 런북 AL-R0031을 참고하세요.

Vertex AI

번역 요청에서 `RESOURCE_EXHAUSTED` 오류 코드가 생성될 수 있음

버전: 1.14.3

증상: 번역 요청을 보낸 후 응답 메시지에 RESOURCE_EXHAUSTED 오류 코드가 표시됩니다. 이 오류는 시스템 빈도 제한을 초과할 때 발생합니다. 사용자당 할당량, 초당 최대 쿼리 수 또는 전체 파일 시스템의 용량 부족 등 리소스가 소진되었습니다.

해결 방법: 인프라 운영자(IO)에게 번역 서비스 백엔드 샤드를 다시 시작하도록 요청합니다. 그런 다음 요청 간 지연 시간을 늘리거나 더 짧은 요청을 전송하여 번역 요청을 다시 보냅니다.

`batchTranslateDocument` 요청에서 `503` 오류가 반환됨

버전: 1.14.3

증상: batchTranslateDocument 요청을 보낸 후 응답 메시지에 503 "Batch Document translation is not implemented" 오류 코드가 표시됩니다. 이 오류는 BatchTranslateDocument 메서드에 Aspose 서비스가 필요하기 때문에 발생합니다. Aspose 서비스는 클러스터에서 enableRAG 작동 가능 파라미터가 true로 설정된 경우에만 배포됩니다.

해결 방법: 인프라 운영자(IO)에게 다음 단계에 따라 조직 관리자 클러스터에서 enableRAG 작동 가능 파라미터를 true로 설정하도록 요청하세요.

enableRAG 작동 가능 파라미터가 true로 설정된 vai-translation.yaml이라는 YAML 파일에 SubcomponentOverride 커스텀 리소스를 만듭니다.

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

SHARED_SERVICE_CLUSTER_NAMESPACE을 공유 서비스 클러스터의 네임스페이스로 바꿉니다.

SubcomponentOverride 커스텀 리소스를 조직 관리자 클러스터에 적용합니다.
```
kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
```
ORG_MGMT_KUBECONFIG를 조직 관리자 클러스터의 관리 kubeconfig 파일 경로로 바꿉니다.

번역 또는 OCR 프런트엔드 포드와 서비스가 초기화되지 않습니다.

버전: 1.11.x, 1.12.x, 1.13.x, 1.14.x

증상: 업그레이드 중에 DB 클러스터가 다시 생성되어 공유 서비스 클러스터의 ODS secret-store 비밀번호가 오래되고 동기화되지 않습니다. 이러한 이유로 번역 또는 OCR 프런트엔드 포드와 서비스가 초기화에 실패합니다.

해결 방법:

공유 서비스 클러스터에서 보안 비밀을 삭제합니다.

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

SHARED_SERVICE_CLUSTER_KUBECONFIG를 공유 서비스 클러스터의 kubeconfig 파일 경로로 바꿉니다.

문제가 있는 서비스가 Translation인 경우 VAI_API_NAMESPACE을 'g-vai-translation-sie'로 바꾸고, 문제가 있는 서비스가 OCR인 경우 VAI_API_NAMESPACE을 'g-vai-ocr-sie'로 바꿉니다.

컨트롤러가 보안 비밀을 자동으로 다시 만들고 DB 클러스터와 다시 동기화합니다.

Vertex AI Search

조정 상태로 멈춰 있는 검색 구성요소

버전: 1.14.6

증상: 조직에 SearchConfig 커스텀 리소스가 생성되지 않으면 vaisearch-conversation 및 vaisearch-frontend 하위 구성요소가 Reconciling 상태로 멈춥니다.

해결 방법: 이 문제는 무시해도 됩니다. SearchConfig 커스텀 리소스가 생성되면 하위 구성요소가 조정을 완료해야 합니다.

서버

BIOS 사용자 인증 정보 순환이 reset-requested 단계에서 멈춤

버전: 1.14.4

증상: BIOS 사용자 인증 정보 순환이 reset-requested 상태에서 멈춥니다. 서버의 bios-credentials 보안 비밀에 대한 gdch.cluster.gke.io/rotation-status 주석을 확인하여 이를 확인할 수 있습니다.

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

SERVER_NAME을 서버 이름으로 바꿉니다. 회전이 멈추면 명령어의 출력은 reset-requested입니다.

해결 방법: BIOS 사용자 인증 정보 순환을 완료하려면 SERV-R0018 런북을 따르세요.

이전에 설치된 서버를 프로비저닝할 수 없음

버전: 1.14.6

증상: 서버가 프로비저닝 해제 후 다시 프로비저닝되지 않습니다. 특히 iLO (Integrated Lights-Out) 및 HSM (하드웨어 보안 모듈) 키 관리와 관련된 문제입니다. 이전에 비활성화된 조직에 속했던 서버에서 이미지 프로비저닝 중에 오류가 발생합니다. 이는 적합한 기기를 찾을 수 없음을 나타내며, 오래되었거나 삭제된 키로 인해 디스크가 잠겨 있는 경우가 많습니다. 다음과 같은 오류가 표시될 수 있습니다.

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

해결 방법: 영향을 받는 서버를 삭제하고 다시 설치하여 서버가 프로비저닝된 상태가 되도록 합니다. 자세한 내용은 SERV-R0020 및 SERV-R0021 런북을 참고하세요.

가상 머신

이미지 가져오기 실패

버전: 1.14.4. 1.14.5

Fixed(해결됨): 1.14.6

증상: 세션 시간 초과로 인해 gdcloud compute images import 명령어를 사용한 이미지 가져오기가 Unauthorized 오류와 함께 실패합니다.

해결 방법: gdcloud CLI 대신 KRM API를 사용하여 자체 이미지 가져오기를 가져옵니다.

KRM 이미지 가져오기에 시간이 오래 걸림

버전: 1.14.6 이상

증상: KRM API를 사용한 이미지 가져오기가 완료되는 데 오랜 시간이 걸립니다. VirtualMachineImageImport 리소스가 장기간 TranslationJobInProgress 상태로 유지되어 변환 단계가 예상대로 완료되지 않음을 나타냅니다. image-translation 포드가 CrashLoopBackOff 상태로 전환됩니다.

해결 방법:

다른 이름으로 새 VirtualMachineImageImport 리소스를 만들어 가져오기를 다시 시도하세요.
상태가 WaitingForTranslationJob으로 변경될 때까지 리소스를 주기적으로 확인하여 VirtualMachineImageImport 상태를 모니터링합니다. 자세한 내용은 VMM R0007 런북을 참고하세요.

Google Distributed Cloud(에어 갭 적용형) 1.14.x 알려진 문제 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

백업 및 복원

클러스터 백업 복원 계획 수정이 작동하지 않음

잘못된 소스 디스크 크기

메모리 부족으로 인해 에이전트 및 컨트롤 플레인 포드가 다시 시작됨

백업 및 복원 SLO가 적용되지 않음

가져온 백업에는 보관 정책이 적용되지 않음

부분 VM 백업 실패

사용자 또는 서비스 클러스터 삭제 후 고아 백업 리소스 정리

CLI 또는 UI를 통한 VirtualMachineRestore 삭제가 지원되지 않음

메모리 부족으로 인해 백업 제어 영역 포드가 비정상 종료됨

사용자 클러스터 삭제가 중단됨

대기 중인 영구 볼륨 클레인으로 인해 복원이 중단됨

클러스터 관리

하위 구성요소 kub-gpu-controller이(가) 조정되지 않음

Standard 클러스터는 노드 풀을 삭제할 수 없습니다.

클러스터가 삭제 상태로 멈춰 있음

데이터베이스 서비스

AlloyDB Omni 데이터베이스 클론이 멈춤

DNS

GlobalCustomerRootDNSServerNotReachable에서 잘못된 알림이 발생함

파일/블록 스토리지

VM에서 파일 공유 볼륨을 마운트할 수 없음

방화벽

서브넷 CR의 주소에 대한 보안 정책 규칙이 누락됨

GDC 방화벽이 관리 및 데이터 영역 모두에 대해 OIR로 향하는 트래픽을 거부함

GDC 방화벽에서 교차 영역 교차 조직 트래픽 거부

방화벽은 식별자가 조직 이름과 동일한 AttachmentGroup을 지원하지 않음

항구

백업 및 복원 후 Harbor CLI 보안 비밀이 무효화됨

Harbor 백업 및 복원 작업이 권한을 놓고 경쟁함

Harbor 백업 크기가 0으로 표시됨

Harbor Registry 콘솔 페이지의 백업 리소스에 대한 권한 오류

데이터베이스 비밀번호 순환이 멈춘 페이지

하드웨어 보안 모듈

HSM 비활성화된 무료 체험 라이선스가 계속 감지됨

HSM 호스트 데몬 파일 설명자 누수

부팅 후 ValidateNetworkConfig 오류로 인해 HSM이 실패함

건강

잘못된 알림 SLO 알림

잘못된 게이지 기반 SLO 구성

ID 및 액세스 관리

IAM 역할 바인딩 생성 실패

프로젝트 서비스 계정의 IAM 역할 바인딩을 만들지 못함

새 프로젝트에서 사전 정의된 역할 생성 지연

GDC 콘솔에서 첫 번째 역할 바인딩을 만들 수 없음

AO는 인프라 클러스터의 역할에 대한 액세스 권한을 부여할 수 없음

기존 서비스 계정 토큰이 무효화됨

코드형 인프라(IAC)

네임스페이스 누락으로 인한 하위 구성요소 조정 실패

IAC ConfigSync 측정항목 수집 실패

IAC RootSync가 실패함

인벤토리

인벤토리 감사에서 조정 실패

키 관리 시스템

CTM 루트 키를 사용하도록 구성된 KMS는 HSM을 사용할 수 없는 경우 장애 조치를 수행하지 않음

부하 분산기

서브넷 CIDR 소진으로 인해 전역 부하 분산기 생성이 실패함

부하 분산기 리소스를 수정해도 서비스가 조정되지 않음

잘못된 영역 이름이 거부되지 않음

전역 및 영역 부하 분산기 웹훅 오류

로깅

WAL 재생 중에 Loki 포드가 비정상 종료되거나 OOMKilled됨

해결 방법 확인

재정의 및 객체 프록시 정리

모니터링

AlertManager 웹훅이 일부 클러스터에 대한 알림을 전송하지 못함

ServiceNow 인시던트가 가끔 중복됨

인프라 측정항목이 지나치게 민감할 수 있음

조정 측정항목이 지나치게 민감할 수 있음

루트 관리자 클러스터에 잘못된 알림 2개가 열려 있음

루트 관리자 컨트롤러 관리자의 오류율이 높게 표시됨

KUB 대시보드의 모든 PA 패널에 데이터가 표시되지 않음

관측 가능성-admin-debugger 역할의 권한이 잘못 구성됨

Grafana 디버거 역할 누락

새 영역을 추가한 후 교차 영역 측정항목 및 로그가 표시되지 않음

MonitoringTarget 파이널라이저가 네임스페이스 삭제를 차단함

대시보드 및 데이터 소스의 파이널라이저가 보류되어 프로젝트 삭제가 중단됨

KSM의 측정항목이 표시되지 않음

시스템 측정항목 파이프라인이 다운됨

Google Distributed Cloud(에어 갭 적용형) 1.14.x 알려진 문제

하위 구성요소 `kub-gpu-controller`이(가) 조정되지 않음

부팅 후 `ValidateNetworkConfig` 오류로 인해 HSM이 실패함

`MonitoringTarget` 파이널라이저가 네임스페이스 삭제를 차단함

`MultiZoneNetworkConfig` 영역 순서를 조정하면 구성 바꾸기가 실패함

`gdcloud config set zone` 명령어로 만든 버킷이 삭제되지 않음

Trident `mkfs.ext4` 오류로 인해 포드를 마운트할 수 없음

`file_block_iscsi_sessions_unhealthy alert`에서 거짓양성 보고

예비 디스크에 대한 `file_block_storage_disk_failure` 알림이 발생함

`file_block_storage_high_node_total_latency` 경고가 과도한 워크로드 중에 발생함

멀티 경로 오류가 해결된 후 `file_block_zombie_luns_present` 알림이 발생함

번역 요청에서 `RESOURCE_EXHAUSTED` 오류 코드가 생성될 수 있음

`batchTranslateDocument` 요청에서 `503` 오류가 반환됨