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

Artifact Registry

하위 구성요소 sar-failoverregistry 조정 오류

버전: 1.13.1, 1.13.3, 1.13.4

증상: gdcloud system admin-cluster install 명령어로 루트 관리자 클러스터를 만들 때 부트스트랩 시 서버 목록이 길면 작업이 실패할 수 있습니다. 오류 출력 메시지는 다음과 같습니다.

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

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

  1. 하위 구성요소와 동일한 Kubernetes 클러스터에서 서버를 나열하고 각 서버 커스텀 리소스에 키가 cluster.private.gdc.goog/inventory-machine인 라벨이 있는지 확인합니다.

    kubectl get servers -n gpc-system

  2. 다음과 같은 구성요소 맞춤 리소스를 찾습니다.

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

  3. 시스템 아티팩트 레지스트리 (SAR) 구성요소 맞춤 리소스에서 sar-failover-registry의 runtimeParameterSources 서버에 라벨 선택기를 추가합니다.

    1. 기존 server 리소스를 확인합니다.

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

    2. 구성요소 커스텀 리소스에서 서버 필드를 업데이트합니다.

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

  4. 이전 단계의 SAR 구성요소 변경사항이 하위 구성요소 sar-failverregistry에 전파되었는지 확인합니다.

    1. SAR 구성요소의 세부정보를 가져옵니다.

      kubectl get component | grep sar

    2. sar-failoverregistry 구성요소의 세부정보를 가져옵니다.

      kubectl get subcomponent sar-failoverregistry -n root

      -n 플래그를 사용하여 네임스페이스를 지정합니다.

백업 및 복원

볼륨 공간 부족으로 인해 스냅샷이 실패함

버전: 1.13.x의 모든 버전

증상: 영구 볼륨 백업에 간헐적인 문제가 있어 주기적인 백업 작업의 워크플로에 영향을 줄 수 있습니다. 변경률이 높은 일부 볼륨의 경우 진행 중인 백업을 위해 생성된 볼륨 스냅샷으로 인해 볼륨의 공간이 부족해져 볼륨이 읽기 전용 모드로 전환될 수 있습니다.

해결 방법: 프로덕션 워크로드에 미칠 수 있는 영향을 방지하려면 BACK-R0104 런북의 단계를 따르세요. 선택적으로 BACK-R0106 런북에 따라 누적된 스냅샷을 삭제할 수도 있습니다.

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

버전: 1.13.x의 모든 버전

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

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

PVC 스냅샷 백업 실패

버전: 1.13.x의 모든 버전

증상: PersistentVolumeClaim (PVC) 리소스당 ONTAP 스냅샷 한도인 1023개를 초과하여 백업 실패가 발생했습니다.

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

  1. 한도에 도달하지 않도록 백업 계획을 업데이트합니다. 매시간 백업을 실행하도록 백업 계획을 구성하거나 스냅샷 수가 1,023개를 초과하지 않도록 deleteLockDays를 3으로 줄입니다.

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

    다음을 바꿉니다.

    • LOCK_DAYS: 백업 생성 후 지정된 일수 동안 백업 삭제를 잠급니다. 다음 값을 사용합니다.

      • volumeStrategy 필드가 LocalSnapshotOnly 값으로 설정된 경우 2 값을 사용합니다.
      • volumeStrategy 필드가 ProvisionerSpecific 값으로 설정된 경우 7 값을 사용합니다.

    • RETENTION_DAYS: 백업 생성 후 지정된 일수가 지나면 백업을 삭제합니다. volumeStrategy 필드가 LocalSnapshotOnly 값으로 설정된 경우 3보다 작은 값을 사용합니다.

  2. 볼륨 스냅샷 삭제 명령어를 사용하여 환경에서 과도한 스냅샷을 수동으로 삭제하려면 다음 단계를 따르세요.

    1. 변수를 초기화합니다.

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

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME

      다음을 바꿉니다.

      • ORG_NAME: 조직 이름
      • PVC_NAME: 백업 계획과 관련된 PVC 리소스의 이름입니다.

    2. NetApp ONTAP은 GDC의 스토리지를 관리하는 데 사용되는 운영체제입니다. ONTAP 액세스 권한을 얻습니다.

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

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

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

echo $PASSWORD

    3. 선택한 PVC 리소스의 모든 스냅샷을 나열합니다.

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

      이전 단계의 비밀번호를 사용하여 MGMT_IP 변수로 정의된 IP 주소의 머신에 로그인합니다.

    4. 스냅샷 수가 가장 많은 PVC를 찾습니다.

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

    5. PVC 리소스 이름을 스냅샷 수가 많은 리소스로 설정합니다.

      export PV_NAME=

    6. 스냅샷 수가 많은 PVC 리소스의 스냅샷을 삭제합니다. PVC 리소스의 스냅샷 수 제한은 1023입니다.

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

    7. ONTAP에 로그인하고 다음 명령어를 실행하여 스냅샷을 삭제합니다.

      echo $PASSWORD

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

    8. 이전 단계에 나열된 명령어를 실행하여 스냅샷을 삭제합니다. 완료되면 SSH 세션을 종료합니다.

  3. 문제가 있는 모든 PVC 스냅샷이 정리될 때까지 삭제 단계를 반복합니다.

SVM 할당량과 호환되지 않는 백업에서 복원

버전: 1.13.1

증상: NetApp 기능 간의 비호환성 문제입니다. 이 비호환성으로 인해 테넌트 할당량이 제공되지 않고 복원이 성공적으로 구현되지 않습니다. 이 문제는 할당량 제한이 있는 사용자 클러스터로 백업을 복원할 때만 발생합니다.

해결 방법: 이 문제가 발생하면 DP volumes are not supported on storage-limit enabled Vserver 오류 메시지와 함께 복원이 실패하며 인프라 운영자 (IO)는 해당 사용자 클러스터의 할당량을 사용 중지하고 복원 프로세스를 다시 시작해야 합니다. 복원이 완료되면 IO는 테넌트 할당량을 다시 사용 설정해야 하며 시스템은 의도한 대로 계속 작동해야 합니다. 자세한 내용은 런북 FILE A0030을 참고하세요.

결제

결제 측정항목이 결제 대시보드에 올바르게 표시되지 않음

버전: 1.13.1

증상: MetricsProxySidecar가 누락되어 결제 측정항목이 cortex에 올바르게 전송되지 않습니다.

해결 방법: billing-monetizer MetricsProxySidecar 리소스를 만듭니다. 그런 다음 스크립트를 실행하여 metricExpression를 업데이트합니다.

  1. 다음 kubeconfig 변수를 내보냅니다.

    export KUBECONFIG=KUBECONFIG_PATH

    KUBECONFIG_PATH 변수를 조직 관리자 클러스터의 kubeconfig 파일 경로로 바꿉니다. 서비스 설명서 IAM-R0101의 단계에 따라 이 해결 방법에 필요한 kubeconfig 파일을 생성합니다.

  2. billing-system 및 partner-billing-system 네임스페이스용 billing-monetizer MetricsProxySidecar 리소스를 만듭니다.

    billing-system의 경우:

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

    partner-billing-system의 경우:

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

  3. 다음 스크립트를 실행하여 metricExpression를 업데이트합니다. 이렇게 하면 billing_total_cost{container_name="monetizer"를 포함한 skuconfig에서 container_name="monetizer"이(가) 삭제됩니다.

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

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

유효성 검사 웹훅의 버그로 인해 사용자가 BillingAccountBinding를 만들지 못함

버전: 1.13.0, 1.13.1, 1.13.3

증상: 이 버그는 BillingAccountBinding 유효성 검사 웹훅 로직에 있습니다. 사용자가 BillingAccountBinding 리소스를 만들려고 하면 웹훅에서 permission denied 오류를 반환합니다.

해결 방법: BillingAccountBinding 리소스를 만들려면 인프라 운영자에게 알리고 IAC를 통해 해당 리소스를 만드세요.

블록 스토리지

볼륨 마운트 오류로 인해 Grafana 포드가 Init 상태로 멈춤

버전: 1.13.3

증상:

anthos-identity-service-obs-system 및 platform-obs-obs-system 네임스페이스의 Grafana 포드가 볼륨 마운트 오류로 인해 Init 상태로 멈춰 있습니다. kubelet 로그의 오류 메시지는 다중 연결 문제를 나타냅니다. 이 문제는 Trident의 버그로 인해 발생합니다. 이 버그로 인해 LUKS 매핑의 기본 기기를 제대로 식별하고 확인할 수 없어 다중 연결 오류가 발생합니다.

해결 방법:

PVC에서 deletionTimestamp를 확인합니다. deletionTimestamp가 없는 경우 (포드 마이그레이션) 다음 단계를 따르세요.

  1. PVC의 VolumeAttachment를 확인하여 볼륨이 현재 연결된 위치를 파악합니다.
  2. 이 값과 일치하지 않는 클러스터의 Nodes을 차단합니다.
  3. 실패한 Pod를 삭제합니다. 그러면 원래 Node로 다시 이전됩니다.

확인 후 deletionTimestamp (볼륨 삭제)가 있는 경우 다음 단계를 따르세요.

  1. PVC의 VolumeAttachment를 확인하여 볼륨이 현재 연결된 위치를 파악합니다.

  2. Node에서 추적 파일의 콘텐츠를 출력합니다.

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

  3. 추적 파일 출력의 devicePath 필드에서 찾은 LUKS 기기가 실제로 닫혀 있는지 확인합니다. 이 시점에서 이 경로는 존재하지 않아야 합니다.

    stat DEVICE_PATH

  4. 일련번호가 현재 멀티 경로 기기에 매핑되어 있는지 확인합니다.

    1. 추적 파일의 iscsiLunSerial 필드 값을 복사합니다.

    2. 이 값을 예상되는 16진수 값으로 변환합니다.

      echo 'iISCSILUNSERIAL' | xxd -l 12 -ps

    3. 이 새 값으로 멀티 경로 항목이 아직 있는지 확인합니다.

      multipath -ll | grep SERIAL_HEX

    4. 추적 파일이 없으면 삭제합니다.

    5. 있는 경우 검색한 것보다 약간 긴 16진수 값이 표시되며 이를 multipathSerial라고 합니다. 다음을 실행하고 블록 기기를 찾습니다.

      multipath -ll MULTIPATH_SERIAL

    6. 그런 다음 다음 명령어를 실행합니다. 마지막 명령어는 각 블록 기기에 대해 고유하게 실행됩니다.

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

가상 머신 런처 포드가 볼륨을 매핑하지 못함

버전: 1.13.1

증상:

다음과 같은 경고가 표시될 수 있습니다.

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

문제를 진단하려면 다음 단계를 따르세요.

  1. 볼륨과 포드가 동일한 노드에 있는지 확인합니다.
  2. 포드가 있는 노드를 찾아 상태를 확인합니다.
  3. 노드 연결을 확인합니다.
  4. IPSEC을 확인합니다.
  5. 멀티 경로를 확인하여 좀비가 있는지 확인합니다.

  6. 트라이던트 로그를 확인하여 CSI 흐름의 어떤 단계에서 이 좀비가 도입되었는지 확인합니다.

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

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

  1. 노드 관련 문제는 FILE-R0010 런북을 참고하세요.
  2. IPSEC 관련 문제는 FILE-R0007 런북을 참고하세요.
  3. 좀비 LUN 관련 문제는 FILE-R0020 런북을 참고하세요.
  4. 슈퍼 좀비 LUN 관련 문제는 FILE-R0021 런북을 참고하세요.

스토리지 관련 오류

버전: 1.13.1

증상: 스토리지 관련 장애는 file_block_zombie_luns_present 알림이 발생하거나 조정 루프가 두 번 이상 지속되는 MountVolume 호출의 문제로 인해 포드가 실행되지 않는 것으로 식별할 수 있습니다. 제한 시간은 약 2분일 수 있습니다. 동일한 실패가 반복되면 NodeStage 또는 NodePublish CSI 경로에서 문제가 발생한 것이므로 해결 방법이 필요합니다. 시간 제한 실패를 나타내는 경우만 예외입니다. 다음과 같은 오류가 표시될 수 있습니다.

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

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

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

해결 방법:

  1. Pod이 있는 Node이 실패한 PVC에 대해 수정될 수 있는지 확인하려면 포드가 예약된 현재 노드를 차단하고 Pod을 삭제합니다.

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE

    Pod는 완전히 다른 Node에 예약되어야 하며, 이로 인해 Trident가 NodeStage, NodePublish, NodeUnpublish, NodeUnstage를 완전히 실행해야 합니다. 원래 Node에서 이 볼륨에 대해 아직 열려 있는 세션이 있을 수 있으므로 볼륨이 바로 수정되지 않을 수 있습니다.

  2. 이전 단계를 완료한 후 문제가 있는 노드의 코돈을 해제합니다.

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE

  3. 실패가 계속되면 Pod이 원래 예약된 위치를 제외한 다른 모든 Nodes을 차단하고 Pod을 삭제합니다. 이렇게 하면 기존 기기가 여전히 남아 있을 수 있는 원래 Node에서 Pod가 시작됩니다.

  4. 이전 단계를 완료한 후 문제가 있는 노드의 코돈을 해제합니다.

  5. PV와 데이터를 저장하는 마지막 방법으로 Node를 재부팅하여 Node의 멀티 경로, udev, devmapper 실패를 지울 수 있습니다. 이 단계는 다소 번거롭지만 성공할 가능성이 가장 높습니다.

  6. 이전 완화 조치로 볼륨 문제가 해결되지 않으면 데이터가 손상되어 사실상 사용할 수 없음을 나타냅니다. 의도한 컨테이너 동작을 계속할 수 있는 유일한 옵션은 실패한 PV, PVC, Pod를 삭제한 후 PV가 호스팅된 노드를 다시 시작하는 것입니다. 이 작업으로 인해 볼륨에 이미 기록된 모든 데이터가 완전히 손실됩니다.

크기가 잘못된 영구 볼륨이 생성됨

버전: 1.13.1

증상: 영구 볼륨이 있는 워크로드가 약 16MiB 너무 작게 생성됩니다. 워크로드가 영구 볼륨에서 광고하는 크기에 정확히 의존하는 경우 작은 불일치로 인해 확장하거나 프로비저닝할 때 워크로드가 실패합니다. 이 문제는 standard-rwo 스토리지 클래스로 프로비저닝된 영구 볼륨보다는 standard-block 스토리지 클래스로 프로비저닝된 영구 볼륨에서 더 많이 발생합니다. 이 문제는 volumemode:block 모드를 사용하는 standard-rwo 스토리지 클래스가 있는 영구 볼륨에서 발생할 수 있습니다.

해결 방법: 실제로 필요한 것보다 16MiB 이상 큰 영구 볼륨을 할당합니다.

스토리지 가상 머신을 삭제할 수 없음

버전: 1.13.1

증상: StorageVirtualMachine에 다음과 같은 오류가 표시될 수 있습니다.

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

해결 방법: org 네임스페이스의 StorageVirtualMachines에서 파이널라이저를 삭제합니다.

조직 비활성화는 리소스를 정리하지 않음

버전: 1.13.1

증상: 조직을 비활성화하면 다음과 같은 일부 StorageVirtualMachines 리소스가 남아 있습니다.

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

해결 방법: 이러한 리소스를 삭제합니다.

삭제 조정 실패

버전: 1.13.1

증상: StorageVirtualMachine에 종속된 클러스터를 정리하기 전에 StorageVirtualMachine를 삭제하면 일부 클러스터의 영구 볼륨 (PV)을 정리하는 데 문제가 발생할 수 있습니다. 특히 LUKS로 암호화된 PV가 정리되지 않으면 비밀번호로 인해 PV가 있는 네임스페이스가 삭제되지 않습니다. 로그에 다음과 같은 경고가 표시될 수 있습니다.

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

해결 방법: 서비스 클러스터 네임스페이스의 g-luks-gdc-vm-disk-* 보안 비밀에서 파이널라이저를 삭제합니다.

베어메탈 업그레이드가 멈춤

버전: 1.13.1, 1.13.5, 1.13.6

증상: 좀비 LUN이 있으면 Ansible 작업이 사실 수집에서 멈춥니다. multipath -ll 명령어를 실행하면 다음과 같은 문제가 표시될 수 있습니다.

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

다음 오류 메시지가 표시될 수도 있습니다.

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

해결 방법: 타겟 노드와의 SSH 연결을 확인한 후 FILE-R0020 런북을 사용합니다.

Trident 다중 연결 오류

버전: 1.13.3

증상: 포드와 PVC가 서로 다른 노드에 고립될 수 있으며 포드는 PVC를 기다리며 초기화에 멈춰 있습니다.

해결 방법:

  1. PVC에서 deletionTimestamp을 확인합니다.

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

  2. deletionTimestamp (포드 이전)이 없는 경우:

    1. PVC의 VolumeAttachment를 확인하여 볼륨이 연결된 위치를 식별합니다.
    2. 이 값과 일치하지 않는 클러스터의 노드를 차단합니다.
    3. 실패한 포드를 삭제합니다. 이 작업은 POD를 원래 노드로 다시 마이그레이션합니다.

  3. deletionTimestamp (볼륨 삭제)가 있는 경우:

    1. PVC의 VolumeAttachment를 확인하여 볼륨이 연결된 위치를 식별합니다.
    2. 노드에서 추적 파일 /var/lib/trident/tracking/PVC_NAME.json의 콘텐츠를 출력합니다.
    3. 추적 파일 출력의 devicePath 필드에 있는 LUKS 기기가 실제로 닫혀 있는지 확인합니다. 이 시점에는 이 경로가 존재하지 않아야 합니다(stat DEVICE_PATH). 경로가 여전히 존재한다면 다른 문제가 발생한 것입니다.
    4. 일련번호가 멀티 경로 기기에 매핑되었는지 확인합니다.
    5. 추적 파일의 iscsiLunSerial 필드 값을 복사합니다.
    6. 이 값을 예상되는 16진수 값으로 변환하세요. echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
    7. 이 새 값으로 멀티 경로 항목이 아직 있는지 확인합니다(multipath -ll | grep SERIAL_HEX).
    8. 추적 파일이 없으면 삭제합니다.

    9. 있는 경우 검색한 값보다 약간 긴 serial-hex 값이 표시됩니다. 이 값을 MULTIPATH_SERIAL로 기록합니다. multipath -ll MULTIPATH_SERIAL를 실행하면 다음과 같은 메시지가 표시됩니다.

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

    10. 다음 명령어를 실행합니다.

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

    11. 각 블록 기기에 대해 마지막 명령어를 고유하게 실행합니다.

IPsec 구성 오류

버전: 1.13.4

증상: 0X가 포함된 잘못된 사전 공유 키 (PSK)로 인해 ONTAP IPsec 구성에 오류가 발생합니다. 0X는 16진수 문자열로 해석됩니다.

다음과 같은 경고가 표시될 수 있습니다.

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

해결 방법:

  1. 스토리지 암호화 연결을 가져옵니다.

    kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

    Ready=False가 있는 항목을 찾아 PRESHAREKEY의 이름을 기록합니다. 출력은 다음 예시와 같이 표시됩니다.

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

  2. 이 머신은 gpu org를 실행하므로 gpu-org-admin에서 secrets gpc-system/vm-5a77b2a2-pre-shared-key를 삭제합니다.

  3. 시스템에서 secret/vm-5a77b2a2-pre-shared-key를 다시 만들 때까지 기다립니다.

  4. gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2과 같은 패턴의 작업을 찾습니다. 마지막 8개 문자는 무작위로 생성됩니다. 키를 다시 사용할 수 있게 되면 gpu-org-admin에서 jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl와 같은 작업을 삭제합니다.

스토리지 가상 머신이 생성되지 않음

버전: 1.13.5

증상: 볼륨 프로비저닝 문제로 인해 gpu-org의 Harbor 서비스가 시작되지 않습니다. 이 문제는 존재하지 않는 인벤토리 머신을 참조하는 file-storage-backend-controller 포드로 인해 발생합니다.

다음과 같은 스토리지 컨트롤러 오류가 표시될 수 있으며, 이는 InventoryMachine를 찾을 수 없음을 나타냅니다.

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

해결 방법:

  1. file-storage-backend-controller 포드를 삭제합니다.
  2. 스토리지 컨트롤러가 현재 인벤토리 머신을 다시 가져오도록 합니다.

스토리지 클러스터 간 네트워크가 조정되지 않음

버전: 1.13.5, 1.13.6

증상: 업그레이드 후 루트 관리자 클러스터의 StorageCluster 커스텀 리소스가 사양의 클러스터 간 서브넷의 잘못된 구성으로 인해 준비되지 않습니다. 스토리지 클러스터는 Not Ready를 보고 이 오류가 포함된 이벤트를 포함합니다.

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

이 오류가 발생하면 스토리지 클러스터에서 사용하는 클러스터 간 서브넷 클레임에 참조의 kind 필드가 포함되지 않습니다. StorageCluster 커스텀 리소스를 검사하면 다음과 같이 이름과 네임스페이스만 있는 클러스터 간 서브넷 클레임 참조가 표시됩니다.

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

해결 방법: 서브넷 클레임 참조에 kind: SubnetClaim 필드를 포함하도록 StorageCluster 사양을 업데이트합니다.

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

StorageCluster 사양을 업데이트한 후 file-storage-backend-controller 배포를 다시 시작하고 스토리지 클러스터가 준비되었는지 확인합니다.

클러스터 관리

클러스터 프로비저닝 중에 machine-init 작업이 실패함

버전: 1.13.1

증상

  1. 클러스터 프로비저닝 중에 두 번째 제어 영역 노드의 machine-init 작업이 다음 메시지와 함께 실패합니다.

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

  2. 로그를 조회합니다.

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

    출력에 비어 있지 않은 결과가 표시됩니다.

해결 방법:

  1. /etc/kubernetes/pki/etcd/ca.crt 권한을 전환합니다. 이 작업은 시간에 매우 민감합니다. 권한 전환은 이전 machine-init 작업 실행 후 다음 machine-init 작업 실행 전에 이루어져야 합니다. machine-init가 권한을 루트로 덮어쓰기 때문입니다.

  2. 두 번째 노드에서 etcd를 다시 시작하여 첫 번째 노드의 etcd가 비정상 종료 루프에서 복구되도록 합니다.

이 두 단계를 완료하면 첫 번째 노드의 kube-apiserver가 실행되고 다음 machine-init 작업이 성공합니다.

서비스 클러스터에서 객체 스토리지 버킷으로 연결할 수 없음

버전: 1.13.1

증상: 서비스 클러스터에서 실행되는 데이터베이스 포드의 조직 관리자 클러스터에 있는 객체 스토리지 버킷 연결이 실패합니다.

해결 방법: KUB-R0305 런북의 안내를 따르세요.

실행 전 검사 실패

버전: 1.13.1

증상: 클러스터 객체 상태에 다음 메시지가 표시될 수 있습니다.

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

또한 PreflightCheck 객체에 표시된 오류 또는 실패가 더 이상 문제가 아닌 것으로 알려진 동안 몇 시간 동안 있었던 클러스터 객체와 동일한 이름 및 네임스페이스에 해당하는 PreflightCheck 객체가 표시됩니다.

해결 방법: PreflightCheck 객체를 삭제합니다.

사용자 클러스터 작업자 노드 풀 생성 실패

버전: 1.13.5

증상: 다음 머신 유형 중 하나에 대해 사용자 클러스터 작업자 노드 풀 생성이 응답하지 않을 수 있습니다.

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

해결 방법: 해당 노드 풀을 삭제하고 사용자 클러스터 생성 UI 드롭다운에서 사용 가능한 다른 머신 유형을 선택하여 다시 만듭니다.

사용자 클러스터가 다시 생성될 때 부적절한 정리로 인해 조정이 중단될 수 있음

버전: 1.13.x

증상: 이전에 삭제된 클러스터와 동일한 이름으로 사용자 클러스터를 만들면 애드온 설치 단계 ONE이 언급된 상태로 Reconciling에 무한정 멈출 수 있습니다.

해결 방법: helm 부가기능 CLUSTER_NAME-abm-overrides를 제거하고 managed-adm-controller 배포를 다시 시작합니다. 자세한 단계는 MKS-R0004를 따르세요.

데이터베이스 서비스

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

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

버전: 1.13.x의 모든 버전

증상: 사용자가 특정 시점에서 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 기준입니다.

IOPS 적용이 스토리지 성능에 영향을 미침

버전: 1.13.1

해결 방법: 이 문제를 해결하려면 다음 옵션 중 하나를 따르세요.

  • 스토리지 크기를 늘립니다.
  • IOPS 할당량을 재정의합니다.

dbs-fleet 하위 구성요소를 업그레이드할 때 조정 오류 발생

버전: 1.13.3

증상: 루트 조직을 1.13.1에서 1.13.3으로 업그레이드할 때 조정 오류가 표시될 수 있습니다. 조정 오류가 있는지 확인합니다.

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

오류는 다음과 같이 표시될 수 있습니다.

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

해결 방법: OCLCM-R0122 런북의 단계를 따릅니다.

DBCluster 생성 실패

버전: 1.13.3

증상: 1.13.3로 업그레이드한 후 새 DBcluster가 조정되지 않고 상태에 다음 오류가 표시됩니다.

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

해결 방법

조직 관리자 클러스터에 cpa-v0.12.46 및 cpa-v0.12.51로 끝나는 localrollout CR이 있는지 확인합니다. 예를 들면 다음과 같습니다.

kubectl get localrollouts -A

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

cpa-v0.12.46로 끝나는 localrollout CR을 찾아 삭제하여 다른 localrollout CR에 영향을 주지 않도록 합니다.

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

그러면 다음과 같은 목록이 반환됩니다.

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

각각 삭제합니다.

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

cpa-v0.12.51로 끝나는 localrollout CR이 여전히 있는지 확인합니다.

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

DNS

DNSSEC는 resolved.conf에서 명시적으로 사용 중지해야 합니다.

버전: 1.13.1, 1.13.3, 1.13.4

증상: 베어 메탈 또는 VM 노드에서 DNS 변환이 실패합니다. DNS 확인이 실패하는지 확인하려면 영향을 받는 노드에 SSH 연결을 설정하고 systemctl status systemd-resolved를 실행합니다. 출력에 DNSSEC validation failed for question . IN SOA: no-signature과 같은 줄이 포함됩니다.

해결 방법:

  1. 영향을 받는 노드의 /etc/systemd/resolved.conf에 다음 줄을 추가합니다.

    DNSSEC=false

  2. systemd-resolved 서비스를 다시 시작합니다.

    systemctl restart systemd-resolved.service

항만 서비스

Harbor 서비스 생성 실패

버전: 1.13.6

증상: ServiceIsolationEnvironment 이름의 길이 제한으로 인해 네임스페이스 불일치가 발생하여 Harbor 인스턴스를 만들 수 없습니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

해결 방법: 현재 문제를 해결하려면 Harbor 인스턴스 이름을 짧게 만드세요. PROJECT_NAME과 HARBOR_INSTANCE_NAME의 결합된 길이는 27자(영문 기준) 미만이어야 합니다.

Harbor 인스턴스를 삭제해도 연결된 레지스트리 미러는 삭제되지 않습니다.

버전: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8

증상: Harbor 인스턴스를 삭제해도 연결된 레지스트리 미러가 삭제되지 않습니다. 노드 풀이 Provisioning 상태로 멈춰 있을 수 있습니다. 이는 Harbor 인스턴스가 삭제될 때 MHS 컨트롤러에 의해 생성된 레지스트리 미러가 삭제되지 않기 때문에 발생합니다.

해결 방법: 레지스트리 미러를 수동으로 삭제해야 합니다. 이 문제를 완화하려면 다음 단계를 따르세요.

  1. 조직 관리자 클러스터에 연결합니다. 자세한 내용은 GDC 클러스터 아키텍처를 참고하세요.

  2. 이 스크립트를 실행하여 lcm.private.gdc.goog/cluster-type=user 라벨이 있는 모든 Kubernetes 클러스터에서 HARBOR_INSTANCE_URL 환경 변수의 값과 일치하는 레지스트리 미러를 삭제합니다.

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

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

    HARBOR_INSTANCE_URL을 Harbor 인스턴스의 URL로 바꿉니다.

하드웨어 보안 모듈

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

버전: 1.13.1, 1.13.3~1.13.11

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

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

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

버전: 1.13.x

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

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

sudo systemctl restart host-daemon

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

HSM 인증서가 만료됨

버전: 1.13.11

증상: 조직을 업그레이드할 때 다음과 같은 경고가 표시될 수 있습니다.

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

org-1-system-cluster이 만료된 HSM (하드웨어 보안 모듈) 인증서로 인해 ABM 버전 업그레이드에 멈춰 있습니다.

HPE 서버 iLO, StorageGRID 또는 ONTAP에 다음 예와 같은 오류가 표시될 수도 있습니다.

Not able to connect SSL to Key Manager server at IP_ADDRESS

해결 방법:

ksctl를 사용하여 루트 CA와 웹 인터페이스 인증서를 수동으로 순환합니다.

  1. 모든 HSM, HSMCluster, HSMTenant CR을 일시중지합니다.

  2. 이전 루트 CA에서 복사한 속성을 사용하여 새 루트 CA를 만듭니다. ksctl ca locals list를 사용하여 이전 CA ID를 찾습니다. 예시는 다음과 같습니다.

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

  3. 기간이 1년인 새 CA에 자체 서명합니다. 예를 들면 다음과 같습니다.

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

  4. 인증서 자동 생성에 이 새 CA를 사용하도록 웹 인터페이스를 업데이트합니다. 예시는 다음과 같습니다.

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

  5. 새 CA에서 서명한 새 웹 인터페이스 인증서를 생성합니다. --url 플래그는 HSM의 관리 IP (kubectl get hsm -n gpc-system에서 가져옴)입니다. 예시는 다음과 같습니다.

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

  6. 이때 openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text에는 여전히 이전 인증서가 표시됩니다. 새 인증서를 선택하려면 HSM을 재부팅해야 합니다.

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

sudo reboot

    이제 openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text에 새 인증서가 표시됩니다.

  7. HSM CR에서 이전 CA를 삭제합니다.

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

  8. HSM의 일시중지를 해제합니다. 

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

    HSM이 정상 상태가 되는지 확인합니다.

  9. 다른 두 HSM에 대해 이 단계를 반복합니다. CA가 클러스터의 HSM 간에 공유되므로 새 자체 서명 루트 CA가 이미 있습니다. 2단계와 3단계를 건너뛰고 4~8단계를 반복합니다.

  10. HSM T0008 CA 순환 작업에 따라 모든 인증서의 순환을 자동화하되 ca-rotation-finalizing annotation이 추가되는 hsmcluster에 새 순환 주석을 추가하여 순환 완료 단계를 건너뜁니다.

새 CA 이름을 iLO에 업로드합니다.

  1. iLO 인터페이스에서 관리 - 키 관리자 페이지를 열고 키 관리자 탭을 클릭합니다.
  2. 인증서 이름을 순환합니다.
  3. 콜드 재부팅을 실행합니다.
  4. SSL 핸드셰이크가 다시 작동하는지 확인합니다.

ID 및 액세스 관리

opa-system 네임스페이스의 gatekeeper-audit 포드가 자주 다시 시작됨

버전: 1.13.3

증상: opa-system 네임스페이스에서 gatekeeper-audit-*** 포드의 상태를 확인합니다.

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

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

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

이 문제는 리소스 한도가 낮기 때문에 발생합니다.

코드형 인프라(IAC)

Gitlab 토큰을 과도하게 생성하면 Gitlab 데이터베이스가 채워질 위험이 있음

버전: 1.13.1

증상: iac-manager 하위 구성요소가 필요하지 않은 경우에도 configsync-ro 사용자의 새 토큰을 반복적으로 만듭니다. 이로 인해 GitLab 데이터베이스가 가득 차서 IAC에 액세스할 수 없게 될 수 있습니다. gitlab-system 네임스페이스의 pg-gitlab-database-0 포드가 시작되지 않고 다음과 같은 이벤트를 표시하지 못할 수 있습니다.

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

해결 방법:

Google 담당자와 협력하여 1.13.1 출시용 hotfix_3를 획득하고 적용합니다.

키 관리 시스템 (KMS)

루트 키 유형을 변경하면 기존 키가 모두 무효화됩니다.

버전: 1.13.x

증상: 조직이 생성되면 KMS가 소프트웨어 루트 키로 자동 프로비저닝됩니다. 소프트웨어 루트 키에서 CTM 키로 마이그레이션하려면 사용자가 하위 구성요소 재정의를 실행합니다. 이렇게 하면 루트 키 유형이 변경되어 KMS의 모든 기존 소프트웨어 키가 무효화됩니다.

해결 방법: 가능한 경우 루트 키 유형을 업데이트하지 마세요. 루트 키 유형을 업데이트하면 기존 키가 모두 무효화됩니다.

OOMKILL로 인해 kms-rootkey-controller CrashLoopBackOff

버전: 1.13.1

증상: kms-rootkey-controller 메모리 사용량이 600Mi 한도를 초과하면 컨트롤러가 OOMKilled 상태로 인해 CrashLoopBackOff에 진입합니다.

해결 방법: 메모리 한도를 1500Mi로 업데이트하는 SubcomponentOverride를 만듭니다. 자세한 내용은 KMS 런북 0007을 참고하세요. 런북의 필수 단계가 완료되면 다음 명령어를 실행합니다.

  1. SubcomponentOverride 커스텀 리소스를 만듭니다.

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

    다음 예시에서는 전체 SubcomponentOverride 커스텀 리소스를 확인할 수 있습니다.

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

  2. SubcomponentOverride 리소스를 적용합니다.

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

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

로깅

객체 스토리지 감사 로거가 DNS 호스트를 확인할 수 없음

버전: 1.13.x

증상:

루트 관리자 클러스터에서 obs-system/log-remote-logger 배포에 다음과 같은 여러 오류가 포함됩니다.

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

해결 방법: 다음 명령어를 사용하여 obs-system/log-remote-logger 배포에 패치를 적용합니다.

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

HaaS 로거가 루트 관리자 클러스터에 오류를 표시함

버전: 1.13.x

증상:

루트 관리자 클러스터에서 obs-system/log-remote-logger 배포에 다음과 같은 여러 오류가 포함됩니다.

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

해결 방법: 1.13.8로 업그레이드하여 오류를 수정합니다. 또는 다음과 같이 obs-system/log-remote-logger 배포를 수정합니다.

remote-logger 컨테이너 인수에서 santricity와 HaaS를 포함하도록 --disabled-loggers 플래그를 업데이트합니다.

YAML

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

Santricity Logger가 실패함

버전: 1.13.x

증상:

루트 관리자 클러스터에서 obs-system/log-remote-logger 배포에 다음과 같은 여러 오류가 포함됩니다.

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

해결 방법: 1.13.8로 업그레이드하여 오류를 수정합니다.

로깅 타겟 로그가 잘못된 프로젝트로 전송됨

버전: 1.13.x

증상: obs-system/oplogs-forwarder DaemonSet 로그에 다음과 비슷한 경고가 표시됩니다.

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

이러한 경고로 인해 로그가 잘못된 프로젝트 (테넌트 ID)로 라우팅됩니다. 이 문제는 Fluent Bit의 알려진 버그에서 비롯됩니다. 자세한 내용은 Fluent Bit GitHub 문제를 참고하세요.

해결 방법: 1.13.8로 업그레이드하여 오류를 수정합니다.

플랫폼 네임스페이스의 감사 로그가 PA에 표시되지 않음

버전: 1.13.x

증상: 플랫폼 네임스페이스의 감사 로그가 플랫폼 관리자 (PA)가 아닌 인프라 운영자 (IO)에게 표시됩니다.

해결 방법: 모든 조직 클러스터의 platform 네임스페이스에 observability.gdc.goog/auditlog-destination=pa 라벨을 수동으로 추가합니다. 이 수동 해결 방법을 구현하려면 다음 단계를 따르세요.

  1. KUBECONFIG을 대상 클러스터로 설정합니다.

  2. 네임스페이스에 필수 라벨을 추가합니다.

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

  3. 라벨이 성공적으로 추가되었는지 확인합니다.

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

포드가 컨테이너를 초기화하지 못함

버전: 1.13.x

증상: 포드가 다음과 비슷한 오류로 인해 생성되지 않습니다.

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

이러한 오류로 인해 특정 노드에서 포드가 시작되지 않습니다. 관찰된 동작은 logrotate-daemon 상태 파일이 잠겨 데몬이 예상되는 파일 순환을 실행하지 못하는 알려진 특이 사례에서 발생합니다. 이 오류를 확인하려면 다음 단계를 따르세요.

  1. KUBECONFIG을 대상 클러스터로 설정합니다.

  2. 노드에 예약된 anthos-audit-logs-forwarder-xxxx 인스턴스를 식별합니다.

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

  3. 노드에 예약된 anthos-audit-logs-forwarder-xxxx 인스턴스에서 로그를 가져와 확인합니다.

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

해결 방법:

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

  1. 노드의 /var/log 디렉터리에서 수동 디스크 공간 회수를 실행합니다.

  2. KUBECONFIG을 대상 클러스터로 설정합니다.

  3. 클러스터에서 타겟 노드를 식별합니다.

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

  4. SSH를 사용하여 노드에 연결하고 노드의 /var/log 디렉터리에서 공간을 수동으로 확보합니다. logrotate는 이러한 디렉터리의 파일을 관리합니다.

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

  5. 비정상적으로 큰 로그 파일 (크기가 100MB 이상) 또는 며칠이 지난 파일을 확인합니다. 타겟 파일이 있으면 다음과 같이 로그를 자를 수 있습니다.

    truncate -s 1G <target_file>

  6. 노드에 예약된 anthos-audit-logs-forwarder-xxxx 인스턴스를 식별합니다.

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

  7. 노드에서 예약된 anthos-audit-logs-forwarder-xxxx 인스턴스를 다시 시작합니다.

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

Marketplace

Prisma Cloud 이미지 가져오기 실패

버전: 1.13.7

증상: Marketplace에서 Prisma Cloud 서비스 인스턴스를 만들 수 없습니다. 이 문제는 잘못된 이미지 태그로 인해 발생합니다.

해결 방법:

  1. twistlock-console 배포를 수정하여 이미지 태그를 수정합니다.

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

  2. 다음 줄을 찾습니다.

    image: HARBOR_IP/library/twistlock/console:console_33_01_137

  3. console_33_01_137를 console_33.01.137로 바꿉니다.

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

  4. 포드가 올바르게 실행되는지 확인합니다.

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

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

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

모니터링

ServiceNow에 생성된 알림 수가 매우 많음

버전: 1.13.x

증상:

MON-T0016 및 MON-T1016 수고 작업으로 ServiceNow에 알림을 보내도록 모니터링을 구성하면 ServiceNow에서 많은 수의 인시던트가 자동으로 생성됩니다.

이 문제에는 다음과 같은 특징이 있습니다.

  • 모든 인시던트가 비어 있습니다.
  • 루트 관리자 클러스터와 gdchservices 조직만 ServiceNow로 알림을 보낼 수 있습니다.

해결 방법: MON-T0016 및 MON-T1016 반복 작업을 실행한 직후 MON-T0018 반복 작업을 따릅니다.

ServiceNow에 중복 알림이 여러 개 생성됨

버전: 1.13.x

증상:

MON-T0016, MON-T1016, MON-T0018 작업 도구를 사용하여 ServiceNow에 알림을 전송하도록 모니터링을 구성한 후 ServiceNow에 중복 알림이 여러 개 생성됩니다.

이 문제에는 다음과 같은 특징이 있습니다.

  • MON-T0018 고통 작업 적용 후에도 일부 알림에 대해 중복된 인시던트가 여러 개 생성됩니다.

해결 방법: MON-T0016, MON-T1016, MON-T0018 toil 작업을 실행한 직후 MON-T0019 toil 작업을 따릅니다.

Vertex AI 측정항목을 볼 수 없음

버전: 1.13.1

증상: dvs-frontend-server 포드에서 측정항목이 발생하지 않습니다.

해결 방법: 버전 1.13.1은 Vertex AI 서비스의 암호화된 측정항목을 지원하지 않습니다. Vertex AI 서비스가 1시간 이상 사용 설정되지 않으면 mon-admin 컨트롤러 포드를 다시 시작합니다.

mon-cortex의 조정 오류

버전: 1.13.1, 1.13.9

증상: mon-cortex 포드에 조정 오류가 있습니다. mon-cortex 포드의 상태를 가져옵니다.

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

출력은 다음과 같이 표시될 수 있습니다.

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

다음과 같은 메시지가 로깅될 수 있습니다.

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

해결 방법:

  1. 다음과 같은 메시지를 표시하는 Cortex 포드를 확인합니다.

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

  2. 해당 포드와 연결된 PVC를 삭제하고 다시 시작합니다.

metrics-server-exporter 시스템 클러스터의 포드가 비정상 종료 루프를 실행 중임

버전: 1.13.1

증상: 시스템 클러스터의 metrics-server-exporter 포드가 OOMKilled로 비정상 종료 루프를 실행하지만 한도에 도달하지는 않는 것으로 보입니다. 오류 진단:

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

출력은 다음과 같이 표시될 수 있습니다.

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

해결 방법: 포드를 삭제하고 다시 시작하도록 하여 측정항목 엔드포인트에서 제공되는 데이터 양을 줄입니다. 이렇게 하면 메모리에 보관된 이전 time-series가 삭제되어 필요한 메모리가 줄어듭니다.

ObservabilityPipeline 조정 오류 메시지 무시

버전: 1.13

증상:

ObservabilityPipeline 객체는 root-admin-controller 포드에 다음과 같은 Reconciler error 로그를 표시합니다.

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

해결 방법:

다음 조건을 모두 충족하는 로그는 무시합니다.

  • "controller":"observabilitypipeline"
  • "namespace":"infra-obs"
  • "name":"default"
  • "err"이(가) failed to get system cluster client to install per project overrides: root admin cluster has no system cluster을(를) 포함합니다.

높은 조정 오류로 인해 알림을 디버깅하는 경우 이러한 로그는 거짓 음성이므로 무시하세요.

mon-prober-backend-prometheus-config ConfigMap이 재설정됩니다.

버전: 1.13.0 및 1.13.1

증상:

  • MON-A0001 알림이 트리거됩니다.

  • mon-prober-backend-prometheus-config ConfigMap이 프로브 작업을 포함하지 않도록 재설정됩니다. 예를 들면 다음과 같습니다.

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

해결 방법:

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

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

    • KUBECONFIG: 클러스터의 kubeconfig 파일 경로입니다.
    • TARGET_CLUSTER: 문제를 해결하는 클러스터의 이름입니다.

  2. 모든 클러스터에서 mon-prober 하위 구성요소를 일시중지합니다.

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

    예를 들면 다음과 같습니다.

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

  3. 각 관리자 클러스터에서 MON 관리자 컨트롤러를 다시 시작합니다.

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

    프로브가 등록될 때마다 프로버 ConfigMap이 채워집니다.

  4. 이 알림은 계속 발생하므로 런북 MON-R2009에 따라 MON-A0001 알림 Blackbox monitoring metrics pipeline down을 음소거합니다.

Cortex 스토어 게이트웨이 구성요소 OOMKilled crashloop

버전: 1.13.3

증상: 측정항목을 로드할 때 Grafana에 오류가 표시되거나 측정항목이 전혀 로드되지 않으면 cortex-store-gateway 포드가 비정상 종료 루프에 있을 수 있습니다.

cortex-store-gateway 포드를 진단하고 비정상 종료 루프가 발생하는지 확인하려면 상태를 검토하세요.

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

SYSTEM_CLUSTER_KUBECONFIG를 시스템 클러스터의 kubeconfig 파일 경로로 바꿉니다.

포드가 비정상 종료를 반복하는 경우 출력은 다음 예시와 같이 표시됩니다.

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

해결 방법: SubcomponentOverride를 사용하여 cortex-store-gateway 메모리 한도를 일시적으로 늘립니다. SubComponentOverride 구현에 관한 자세한 내용은 MON-R2008 런북을 참고하세요.

다음은 메모리 제한이 지정된 SubcomponentOverride의 예입니다.

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

모든 cortex-store-gateway 포드가 Ready 상태가 될 때까지 재정의를 그대로 두고 mon-cortex 하위 구성요소가 일시중지되지 않았는지 확인합니다.

  • cortex-store-gateway 포드의 상태가 Ready인지 확인합니다.

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

    모든 포드의 상태가 Ready인 경우 출력은 다음 예시와 같이 표시됩니다.

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

    모든 포드가 준비되려면 READY 열에 N/N 값이 표시되어야 합니다. 그렇지 않으면 1/3 또는 2/3과 같은 값이 표시됩니다.

  • 특정 조직에서 mon-cortex 하위 구성요소가 일시중지되지 않았는지 확인합니다.

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

    다음을 바꿉니다.

    • ORG_ADMIN_KUBECONFIG: 조직 관리자 클러스터의 kubeconfig 파일 경로입니다.
    • SYSTEM_CLUSTER: 시스템 클러스터의 이름입니다.

    하위 구성요소가 일시중지되면 출력에 다음 줄이 표시됩니다.

    lcm.private.gdc.goog/paused: true

    그렇지 않으면 출력은 비어 있습니다.

사용자 클러스터에서 kube 컨트롤 플레인 측정항목 프록시 이미지 가져오기 백오프

버전: 1.13.3

증상: kube-scheduler 또는 kube-controller-manager (예: scheduler_pending_pods 및 workqueue_depth 측정항목)와 관련된 측정항목이 Grafana에 표시되지 않으면 kube-control-plane-metrics-proxy 포드에 이미지 풀 백오프 문제가 있을 수 있습니다.

kube-control-plane-metrics-proxy 포드를 진단하고 이미지 가져오기 지연 문제가 있는지 확인하려면 상태를 검토하세요.

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

USER_CLUSTER_KUBECONFIG를 사용자 클러스터의 kubeconfig 파일 경로로 바꿉니다.

포드에 이미지 가져오기 백오프 문제가 있는 경우 출력은 다음 예시와 같습니다.

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

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

  1. gpc-system-container-images Harbor 프로젝트에서 gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 이미지를 가져옵니다. 이미지를 가져오는 데 필요한 안내와 권한은 Docker로 이미지 가져오기를 참고하세요.

  2. gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 이미지를 library Harbor 프로젝트로 푸시합니다. 이미지를 푸시하는 데 필요한 안내 및 권한은 이미지 푸시를 참고하세요.

    library 프로젝트는 사용자 클러스터에 배포할 아티팩트에 사용됩니다.

WAL이 증가하면 Prometheus가 많은 메모리를 사용함

버전: 1.13.3

증상: 시스템 컨트롤 플레인 VM 노드에서 NodeHasInsufficientMemory 및 EvictionThresholdMet 이벤트를 보고합니다.

kubectl describe node NODE_NAME | grep Events -A100

출력은 다음 예시와 같이 표시될 수 있습니다.

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

Prometheus는 WAL (미리 쓰기 로그)의 증가로 인해 메모리를 많이 사용하므로 노드의 메모리에 영향을 미칩니다. Cortex가 배포되지 않아 WAL이 증가할 수 있으므로 이 문제는 Cortex가 다운된 결과일 수 있습니다. Prometheus 인스턴스가 Cortex와의 연결이 장시간 끊어지면 메모리와 영구 볼륨 (PV)에 데이터를 버퍼링합니다. Prometheus가 종료되면 시작 시 WAL의 모든 데이터를 메모리에 로드합니다.

또 다른 근본 원인은 네트워크 연결 문제 (서비스 메시, 물리적 네트워크, 상위 네트워크)일 수 있습니다.

해결 방법: 이 상태에서 복구하려면 근본 원인을 해결하고 Cortex를 정상 상태로 만들거나 네트워크 연결 문제를 해결하는 것이 좋습니다. 그런 다음 Prometheus의 WAL이 드레이닝될 때까지 기다립니다. 데이터는 손실되지 않지만 Cortex가 다운된 경우 Cortex가 복구되는 기간 동안 노드를 사용할 수 없습니다.

또는 Prometheus STS를 0으로 축소하고 PV를 삭제할 수 있습니다. 이 조치를 취하면 노드를 사용할 수 없는 총 시간이 줄어들지만 데이터 손실이 발생합니다. 또한 Cortex가 다운되거나 네트워크 연결 문제가 발생하는 동안에는 이 작업을 주기적으로 반복해야 합니다. Prometheus와 Cortex 간에 연결 문제가 있는 한 PV가 다시 채워집니다.

다음 단계에 따라 Prometheus STS를 0으로 축소하고 PV를 삭제합니다.

  1. logmon-operator 구성요소를 축소합니다.

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

    ORG_SYSTEM_KUBECONFIG를 조직 시스템 클러스터의 kubeconfig 파일 경로로 바꿉니다.

  2. anthos-prometheus-k8s 구성요소를 축소합니다.

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

  3. 영구 볼륨 신청을 삭제합니다.

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

  4. logmon-operator를 다시 확장합니다.

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

  5. anthos-prometheus-k8s이 준비될 때까지 기다립니다.

다중 영역 부트스트랩

클러스터 역할 누락

버전: 1.13.1

증상: 필수 역할 추가에 사용할 다중 영역 부트스트랩을 위한 특정 역할이 없습니다.

해결 방법: 연결된 안내에 지정된 대로 cluster-admin 클러스터 역할을 사용합니다. 이렇게 하면 사용자가 나중에 작업을 수행하는 데 필요한 최소 액세스 권한보다 많은 액세스 권한을 갖게 됩니다.

호환되지 않는 Bootstrap 리소스

버전: 1.13.1

증상: 부트스트랩 파일 만들기의 3단계에서 만든 Bootstrap 리소스가 이를 처리하는 로직과 호환되지 않습니다.

해결 방법: 4단계에 지정된 대로 생성된 YAML 파일을 수정합니다.

GlobalAPIZone 리소스가 전역 API에 생성되지 않음

버전: 1.13.1

증상: 컨트롤 플레인이 전역 API에서 영역의 GlobalAPIZone 리소스를 생성하지 않아 이 리소스에 의존하는 구성요소가 제대로 작동하지 않습니다.

해결 방법: GlobalAPIZone 리소스 만들기에 표시된 대로 리소스를 만듭니다.

네트워킹

객체 스토리지 노드 그리드 네트워크 다운

버전: 1.13.1, 1.13.3, 1.13.4

증상:

  1. 객체 스토리지 부트스트랩 단계에서 OBJ 관리 노드 설치 프로그램 UI에 그리드 네트워크가 다운된 것으로 표시됩니다.
  2. cables.csv 및 Cell CR에 따르면 객체 스토리지 objsadmin 노드와 TOR 스위치 간 연결의 cables.csv에 있는 MPN 값은 QSFP-100G-CU2.5M입니다.

설명 1.13에서는 cables.csv의 MPN 필드를 사용하여 Tor 스위치에 설정된 속도를 결정합니다. 이러한 포트에서 속도가 설정되지 않으면 objsadmin 노드 연결로 전환하는 tor가 실패합니다. MPN을 속도에 매핑하는 데 사용된 목록이 시스템 통합업체에서 제공한 값을 고려하지 않아 객체 스토리지 부트스트랩이 실패했습니다. 대부분의 1.13 설정에서 공급업체는 QSFP-100G-CU2.5M를 사용했습니다.

해결 방법:

  1. 루트 관리자 클러스터에서 kubectl get -A cell -oyaml를 사용하여 객체 스토리지 어플라이언스 및 TOR 스위치와 관련된 연결을 찾습니다.
  2. objsadm -> torsw 연결의 경우 mpn을 'QSFP-100G-CU3M'으로 변경

예를 들면 다음과 같습니다.

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

노드에 연결할 수 없음

버전: 1.13.1, 1.13.3, 1.13.4

증상:

  1. 네트워크 부트스트랩 단계에서는 일부 스위치에 연결할 수 없습니다.
  2. DHCP 설치 단계에서 일부 서버에 iLO IP 주소를 통해 연결할 수 없습니다.

해결 방법:

  1. 영향을 받는 관리 스위치를 새로고침합니다. 자세한 내용은 PNET-R0018 런북을 참고하세요.

ClusterCIDRConfig이 생성되었지만 노드에 PodCIDR이 할당되지 않음

버전: 1.13.1

증상: ClusterCIDRConfig은 PodCIDRs을 할당하는 데 필요한 객체입니다. ClusterCIDRConfig가 생성되었지만 PodCIDRs가 할당되지 않았습니다. 이 문제는 ipam-controller 포드가 부트스트랩되는 것과 동시에 ClusterCIDRConfig가 생성되는 경우 발생합니다. 클러스터 생성이 조정 상태에서 멈춰 있습니다.

  1. ClusterCIDRConfig 객체가 클러스터에 생성되었는지 확인합니다.

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

    출력은 다음과 같이 표시될 수 있습니다.

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

  2. 조정 중에 멈춘 클러스터의 노드 객체 중 하나에 대해 describe를 실행하고 노드 객체에 CIDRNotAvailable 이벤트가 있는지 확인합니다.

    kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

    출력 이벤트는 다음과 같이 표시될 수 있습니다.

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

해결 방법:

  1. ipam-controller-manager 포드를 다시 시작합니다.

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

  2. ipam-controller-manager 포드가 실행 중 상태가 되면 podCIDR이 노드에 할당되었는지 확인합니다.

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

    출력은 다음과 같이 표시될 수 있습니다.

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

NTP 드리프트

버전: 1.13.1

증상: VM 노드가 절전 모드에 들어가거나 일정 시간 실행된 후 시간이 동기화되지 않거나 정확하지 않습니다.

해결 방법:

  1. VM 노드에 SSH 연결을 설정하고 /etc/chrony.conf 파일을 수정합니다.
  2. makestep 1.0 3 줄을 makestep 1.0 -1로 바꿉니다.

  3. chronyd 서비스를 다시 시작합니다.

    systemctl restart chronyd

각 VM에 대해 이 변경사항을 한 번만 적용하면 됩니다. 변경사항이 덮어쓰여지지 않습니다.

시간을 건너뛰는 더 빠른 즉각적인 빠른 수정을 위해 VM 노드에 대한 SSH 연결을 설정하고 chronyc -a makestep를 실행합니다.

SyncServer 감사 로그가 파싱되지 않음

버전: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

증상: SyncServer의 감사 로그가 log-remote-logger에 의해 올바르게 파싱되지 않습니다. 일부 감사 로그는 Grafana에서 사용할 수 없으며 루트 관리자 log-remote-logger 포드에 다음과 같은 오류 메시지가 표시될 수 있습니다.

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

해결 방법: 감사 로그는 SyncServer에서 계속 사용할 수 있습니다. NTP-P0002에 따라 SyncServer UI에 액세스하고 Logs > Events에서 로그를 확인합니다.

스위치 이미지가 이미지를 추출하지 못함

버전: 1.13.3

증상: 스위치 RMA를 수행하거나 루트 관리자 클러스터를 부트스트랩할 때 SwitchImageHostRequest 객체에 다음과 같은 메시지가 표시될 수 있습니다.

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

kubectl 액세스 권한이 있는 경우 이를 사용하여 이 문제가 발생하는지 확인하세요.

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

출력은 다음 예시와 같이 표시될 수 있습니다.

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

해결 방법:

올바른 이미지 태그를 사용하여 SwitchImageHostRequest를 수동으로 만듭니다.

  1. 부트스트래퍼 서버에 로그인합니다.

  2. gdcloud을 사용하여 올바른 스위치 이미지 버전을 식별합니다.

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

    출력은 다음 예시와 같이 표시될 수 있습니다.

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

    이 출력에서 올바른 스위치 이미지 버전은 1.13.3-gdch.5385입니다.

  3. 오류를 보고하는 SwitchImageHostRequest 객체를 수정합니다.

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

  4. name, fromVersion, toVersion 필드를 예상 스위치 이미지 버전과 일치하도록 수정하거나 바꿉니다. 이 경우 1.13.3-gdch.5385입니다. SwitchImageHostRequest 객체에 적용할 변경사항을 보여주는 다음 diff 출력을 참고하세요.

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

StatefulSet 포드 통신 실패

버전: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9, 1.13.10

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

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

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

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

DBS 인스턴스 연결 문제

버전: 1.13.0, 1.13.1

증상: 데이터베이스 클라이언트에서 연결 시간 초과가 표시되어 데이터베이스 서비스 (DBS) 인스턴스에 액세스할 수 없습니다.

이 문제는 DBS를 사용하는 다른 시스템 구성요소를 통해 표시될 수 있습니다. 예를 들어 결제에서 다음과 같은 오류 메시지를 보고할 수 있습니다.

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

해결 방법: 이 오류는 조직의 서비스 클러스터에서 예약할 수 없는 네트워킹 시스템 구성요소로 인해 발생합니다.

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

    export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME

    다음을 바꿉니다.

    • KUBECONFIG_PATH: 조직 관리자 클러스터 kubeconfig 파일의 경로입니다.
    • ORG_NAME: 조직 이름입니다(예: org-1).

  2. 네트워킹 구성요소 구성을 업데이트하여 예약할 수 있도록 합니다.

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

몇 분 후에 네트워킹 연결이 복원됩니다.

클러스터 메시가 영역 정보로 구성되지 않음

버전: 1.13.5

증상: VM이 동일한 프로젝트의 데이터베이스 클러스터에 연결할 수 없습니다. 내부 부하 분산기에 대한 연결이 영향을 받습니다. 이 문제는 클러스터 이름 구성에 영역 정보가 누락되어 Clustermesh가 클러스터 간에 서비스 객체를 교환하지 못해 발생합니다.

해결 방법: 멀티 영역으로 부트스트랩된 환경에서 다음 수동 해결 방법 단계를 실행하여 내부 부하 분산기가 작동하도록 합니다.

  1. 조직 관리자 클러스터에서 영역 이름을 가져옵니다.

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

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

    zone1

  2. 조직 관리자 클러스터에서 영역 사이트 ID를 가져옵니다.

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

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

    1

  3. 모든 클러스터를 나열합니다.

    ​​kubectl get clusters -A

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

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

  4. 각 클러스터에 대해 CILIUM_CLUSTERNAME를 구성합니다.

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

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

    org-1-system-zone1

  5. 각 클러스터에 대해 다른 매개변수를 다음과 같이 설정합니다. org-1-system의 다음 예시를 참고하세요.

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

  6. 각 클러스터에 대해 AddOnConfiguration 객체를 만들고 addonconfig.yaml 파일에 저장합니다. 기존 클러스터와 향후 만들 새 클러스터에 대해 이 파일을 만듭니다.

    이 페이지에서 다음 변수를 설정하여 다음 코드 샘플을 업데이트합니다.

    CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

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

  7. 조직 관리자 클러스터에 addonconfig.yaml을 적용합니다.

    kubectl apply -f addonconfig.yaml

  8. 시스템, 서비스, 사용자 클러스터에서 cluster-name가 클러스터의 cilium-config에 업데이트되었는지 확인합니다. 업데이트하는 데 시간이 걸릴 수 있지만 clustermesh-apiserver 배포를 다시 시작하기 전에 이 단계를 완료해야 합니다.

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

  9. 시스템, 서비스, 사용자 클러스터에서 clustermesh-apiserver 배포를 다시 시작합니다.

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

잘못된 EVPN IP 주소가 생성됨

버전: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

증상: 하드웨어 자산 관리 시스템 (HAMS)에서 생성된 다중 영역 (MZ) EVPN 인터커넥트 세션 피어링 IP 주소가 .65 또는 .66로 끝나지 않습니다. 이는 잘못된 것이며 MZ EVPN BGP 세션이 설정되지 않습니다.

해결 방법:

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

  1. 모든 InterconnectSession 리소스를 나열합니다.

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

  2. interconnectType 값이 ZonePeering이고 addressFamily 값이 EVPN인 생성된 EVPN 다중 영역 InterconnectSession 리소스를 검토합니다.

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

  3. 이러한 매개변수와 일치하는 각 InterconnectSession 리소스에 다음 수정사항을 적용합니다.

    1. 인터커넥트 세션 커스텀 리소스 이름을 확인합니다.
    2. 이름이 홀수로 끝나면 다음 단계의 명령어를 사용하여 피어 IP 주소의 마지막 부분을 65로 업데이트합니다.
    3. 이름이 짝수로 끝나면 다음 단계의 명령어를 사용하여 피어 IP 주소의 마지막 부분을 66로 업데이트합니다.

  4. 잘못된 피어 IP 주소로 InterconnectSession 리소스를 수정합니다.

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

  5. 오류를 일으키는 모든 InterconnectSession 리소스에 이 수정사항을 적용합니다.

상위 네트워킹 컨트롤 플레인 대시보드에 데이터가 표시되지 않음

버전: 1.13.7

증상: org-1-system 클러스터에 측정항목이 누락되어 TestUpperNetworkingMetrics의 Prometheus 쿼리가 실패합니다. IO 조직 관리자의 상위 네트워킹 컨트롤 플레인 대시보드의 클러스터 메시 패널에 데이터가 표시되지 않습니다. 이 문제는 Cilium과 모니터링 시스템 간의 source_cluster 라벨 불일치로 인해 발생합니다.

해결 방법: UNET 컨트롤 플레인 대시보드에서 source_cluster 필터를 삭제하여 데이터를 표시합니다.

네트워크 설치에 표시되는 혼동을 야기하는 오류

버전: 1.13.1

증상: 네트워크 설치 중에 일부 케이블 연결 경고 메시지가 표시됩니다. 예를 들면 다음과 같습니다.

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

이러한 오류 메시지는 무시해도 됩니다.

모든 이그레스 허용 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*]

객체 스토리지

스토리지 조직을 삭제할 수 없음

버전: 1.13.1

증상: SVM 삭제가 완료되지 않는 문제로 인해 조직 삭제가 완료되지 않을 수 있습니다. 다음과 같은 경고가 표시될 수 있습니다.

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

일부 객체 스토리지 업그레이드 경고는 무시해도 됨

버전: 1.13.3

증상: 객체 스토리지를 업그레이드할 때 다음과 같은 경고가 표시될 수 있습니다.

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

해결 방법:

  1. 각 노드에 해당하는 SSH 사용자 인증 정보가 비밀에 저장되어 있는지 확인합니다.

    1. 관리 노드를 확인합니다.

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

    2. 스토리지 노드를 확인합니다.

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

      스토리지 노드의 경우 성공적인 출력은 다음 예와 같습니다.

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

      보안 비밀을 찾을 수 없는 경우 오류는 다음과 같습니다.

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

  2. 명령어가 오류를 반환하지 않으면 조정자에서 보고한 오류를 무시해도 됩니다.

ObjectStorageStorageNodeReconciler 보고서 maintenance.gdu.gdu_server_locked

버전: 1.13.3

증상: objectstoragestoragenode의 세부정보를 표시합니다.

kubectl describe objectstoragestoragenode zv-aa-objs02

출력은 다음 예시와 같이 표시될 수 있습니다.

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

해결 방법: 이 문제는 무시해도 됩니다. GDU 서비스는 요청이 너무 많으면 일시적으로 잠길 수 있지만 몇 분 후에 잠금 해제됩니다.

사후 1.12.x -> 1.13.x 업그레이드 객체 스토리지 확인 실패

버전: 1.13.x

증상: ObjectStorageUpgrade CR이 다음 오류와 함께 실패합니다.

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

오류로 인해 포드 gpc-system/upgrade-managed-check-objectstorageupgrade 실패

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

근본 원인: 부트스트랩 KIND 클러스터가 비활성화되거나 삭제되지 않은 경우 객체 스토리지 운영 구성요소를 1.12.x에서 1.13.x로 업그레이드하는 데 실패합니다. 업그레이드가 성공하더라도 Kubernetes RBAC를 통해 새 버킷이나 S3 사용자 인증 정보를 만드는 것과 같은 일반적인 객체 스토리지 서비스가 TLS 인증서 유효성 검사 오류로 인해 실패할 수 있습니다. 이는 KIND 클러스터 내의 특정 객체 스토리지 포드가 StorageGRID 관리 엔드포인트의 TLS 서버 인증서를 지속적으로 설치하려고 하기 때문입니다. 이 인증서는 1.12.x에서는 유효했지만 1.13.x에서는 인식되지 않을 수 있습니다. 업그레이드 중에 StorageGRID는 확인 가능한 새 TLS 서버 인증서를 설치하지만 KIND 클러스터 포드는 이를 이전의 유효하지 않은 인증서로 대체하여 TLS 인증서 오류가 발생합니다.

해결 방법: 다음 요구사항이 충족되어야 합니다.

  • 객체 스토리지 1.12.x에서 1.13.x로 업그레이드
  • 부트스트랩 클러스터 (KIND 클러스터)가 여전히 존재합니다.

다음 단계를 따르세요.

  1. 부트스트랩 클러스터 (KIND 클러스터)에서 ObjectStorageSite 리소스에 대한 보기 및 수정 권한이 있는 kubeconfig를 획득합니다.

  2. 부트스트랩 클러스터 (KIND 클러스터)에 연결하는 kubectl에 별칭을 설정합니다.

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

  3. 부트스트래퍼 클러스터에서 ObjectStorageSite 커스텀 리소스 인스턴스를 가져옵니다. ObjectStorageSite 리소스 인스턴스가 하나 있어야 합니다.

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

  4. ObjectStorageSite 리소스 인스턴스에 객체 스토리지 일시중지 주석을 추가합니다.

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

  5. 객체 스토리지 일시중지 주석이 ObjectStorageSite 인스턴스에 추가되었는지 확인합니다.

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

  6. 보기 액세스 권한과 상태 패치 권한이 있는 kubeconfig를 루트 관리자 클러스터의 ObjectStorageCluster 리소스에 획득합니다.

  7. 루트 관리자 클러스터에 연결하는 kubectl에 별칭을 설정합니다.

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

  8. 루트 관리 클러스터에 ObjectStorageCluster 리소스 인스턴스가 있는지 확인합니다.

    kubectlrootadmin get ObjectStorageCluster

    ObjectStorageCluster 리소스 인스턴스가 없으면 해결 방법이 완료된 것입니다. 객체 스토리지 업그레이드 절차를 다시 실행해야 할 수도 있습니다.

  9. 부트스트랩 클러스터의 ObjectStorageSite 리소스 상태에서 관리 엔드포인트 URL을 가져옵니다.

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

  10. 환경 변수 $MGMT_ENDPOINT가 설정되었는지 확인합니다. 엔드포인트는 https://로 시작해야 합니다.

    echo ${MGMT_ENDPOINT:?}

  11. 루트 관리자 클러스터에 ObjectStorageCluster 리소스 인스턴스가 정확히 하나 있는 경우에만 나머지 단계를 실행합니다. 그렇지 않으면 객체 스토리지 업그레이드 절차를 다시 실행합니다.

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

  12. gpc-system/obj-infra-cluster-cm 포드를 다시 시작합니다.

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

  13. 관리 엔드포인트가 ObjectStorageCluster 리소스의 상태에 추가되었는지 확인합니다.

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

  14. postflight check Kubernetes 작업 gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>를 삭제하여 postlight check를 다시 시작합니다. 작업이 곧 다시 생성됩니다.

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

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

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

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

버전:

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

증상:

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

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

해결 방법:

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

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

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

  2. 영향을 받는 노드에 대한 SSH 액세스 권한을 획득합니다.

  3. 노드의 관리 IP 주소를 사용하여 SSH를 통해 노드에 연결합니다.

  4. 노드에서 다음 명령어를 실행한 후 SSH 연결을 종료합니다.

    tc filter del dev bond0 egress

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

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

    StorageGRID 부하 분산기 엔드포인트 인증서가 만료됨

버전: 1.13.10, 1.13.11, 1.13.12

증상: 객체 스토리지 프록시에서 502 Bad Gateway를 보고합니다.

해결 방법: OBJ T0003을 따릅니다.

운영체제

포드가 init 상태로 멈춤

버전: 1.13.1

증상: 노드가 준비됨으로 보고되지만 노드에 대한 SSH 액세스가 느리고 top -n 1에 100개가 넘는 좀비 프로세스가 표시됩니다.

해결 방법:

  1. OS-P0001에 따라 서버를 드레인합니다. 배터리 소모에는 20분 이상 걸릴 수 있습니다. 1시간 후에도 배출이 되지 않으면 다음 단계로 진행합니다.

  2. 서버에 SSH 연결을 설정하고 다음 명령어를 실행하여 서버를 재부팅합니다.

    systemctl reboot

  3. 서버를 완전히 복구하려면 두 번째 재부팅이 필요할 수 있습니다.

  4. SSH 액세스가 더 이상 느리지 않고 좀비 프로세스 수가 훨씬 적은지(30개 미만 권장) 확인합니다.

  5. 서버에서 maintenance을 false로 설정하여 서버의 드레인을 해제합니다.

bm-system-machine-preflight-check 베어메탈 또는 VM 노드의 Ansible 작업이 실패함

버전: 1.13.1

증상: 재부팅 후 커널 모듈 nf_tables이 로드되지 않아 클러스터 Ansible 작업이 Either ip_tables or nf_tables kernel module must be loaded 오류와 함께 실패합니다. 이 문제는 베어메탈 또는 VM 노드가 완전히 프로비저닝되기 전에 재부팅될 때 발생합니다. Ansible 작업에서 다음과 같은 오류가 발생할 수 있습니다.

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

해결 방법:

노드에 SSH 연결을 설정하고 다음 명령어를 실행합니다.

modprobe nf_tables

기기에 남은 공간이 없는 VM

버전: 1.13.1, 1.13.3, 1.13.4, 1.13.5

증상: 로그 디렉터리 /var/log가 가득 차면 Node가 NotReady 상태로 멈출 수 있고 no space left on device 오류로 인해 포드가 시작되지 않을 수 있습니다. 이를 확인하려면 노드에서 다음 명령어를 실행하고 사용량이 100%에 가까운지 확인합니다.

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

해결 방법:

  1. 문제가 발생한 노드에 로그인하고 /var/log/messages의 오래된 로그 보관 파일을 정리합니다.

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

    이 문제가 발생하지 않도록 다음 해결 방법을 계속 적용하는 것이 좋습니다. 해결 방법은 AnsiblePlaybook를 만들고 타겟 OS (BM+VM 머신)를 안전하게 구성하는 맞춤 OSPolicy CR을 통해 변경사항을 적용하는 것입니다. 자세한 내용은 OS-P0005 프로세스를 참고하세요.

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

    export KUBECONFIG=<the path to the kubeconfig file>

  3. 해결 방법을 위한 Ansible 플레이북을 만듭니다.

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

  4. 변경사항을 적용해야 하는 타겟 인벤토리를 식별합니다. 타겟은 개별 InventoryMachine 또는 NodePool일 수 있습니다. OS-P0005 (2. 런타임 구성의 대상 인벤토리 식별)을 참고하세요.

    다음 OSPolicy 예시에는 spec.inventory 아래에 두 개의 타겟 인벤토리가 포함되어 있습니다. 필요에 따라 인벤토리를 추가할 수 있습니다.

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

  5. 검증

    정책 실행 상태를 추적하려면 프로세스 OS-P0005 (유효성 검사)를 참고하세요.

포드가 ContainerCreating 상태로 멈춰 있음

버전: 1.13.3, 1.13.5, 1.13.6

증상: 노드가 정상으로 표시되지만 ContainerCreating 상태로 멈춘 포드가 많고 서버에 SSH 연결을 설정할 수 없습니다.

해결 방법: 서버의 전원을 껐다 켠 후 서버가 다시 시작될 때 노드에 SSH 연결을 설정할 수 있는지 확인합니다.

프로비저닝된 노드에 SSH를 설정할 수 없음

버전: 1.13.5

증상: 노드가 프로비저닝되지만 관리 및 데이터 IP 모두에서 SSH가 시간 초과됩니다.

해결 방법: iLO를 통해 노드를 다시 시작합니다. 부팅 후 ssh로 연결하고 systemctl stop clamonacc; systemctl disable clamonacc를 사용하여 clamonacc를 사용 중지합니다.

보안 부팅에서 OS 서명을 인식하지 못해 최신 OS 이미지에서 베어메탈 노드가 부팅되지 않음

버전: 1.13.12

증상: 1.13.12 버전으로 업그레이드한 후 노드를 재부팅하면 OS가 새 커널로 부팅되지 않습니다. iLO 콘솔 화면에 보안 부팅과 관련된 문제가 표시됩니다.

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

해결 방법:

  1. 이 문제로 인해 부팅에 실패한 노드의 경우 iLO 콘솔을 통해 GRUB 화면으로 들어가 Rocky Linux 4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64를 부팅 타겟으로 선택합니다. 이 절차를 통해 노드가 이전에 알려진 양호한 커널로 부팅됩니다.

  2. GDC 1.13.12 버전으로 업그레이드된 모든 베어메탈 서버의 경우 다음 단계에 따라 부팅 실패를 방지하세요.

    1. 서버에 SSH 연결을 설정합니다.
    2. 서버에서 다음 명령어를 실행하여 문제가 있는 커널을 삭제합니다.
    dnf remove kernel-core-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64
    1. 기본 커널이 알려진 양호한 버전으로 다시 설정되었는지 확인합니다.
    grubby --default-kernel

결과는 /boot/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64입니다.

운영 제품군 인프라 (OI)

하드웨어 3.0에는 SSA가 필요하지 않음

하드웨어 3.0의 RAID 어댑터 구성은 다릅니다. 하드웨어 3.0 OIC 서버는 자체 암호화 드라이브를 사용하므로 스마트 스토리지 관리 (SSA)를 실행하지 않아도 됩니다. 서버별로 디스크 식별자를 확인하려면 추가 단계가 필요합니다. OI 서버 부트스트랩을 참고하세요.

경계 보안

조직 부트스트랩 중에 조직 시스템 클러스터가 멈춤

버전: 1.13.1

증상: 조직 부트스트랩 중에 조직 시스템 클러스터가 멈출 수 있습니다. edr-sidecar-injector 포드가 대기 중 상태입니다. 이러한 포드를 삭제하려고 하면 다음과 같은 오류 메시지가 표시될 수 있습니다.

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

동시에 다른 대기 중인 포드에 다음과 같은 오류 메시지가 표시될 수 있습니다.

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

시스템이 잠금 해제되려면 수동 개입이 필요합니다.

해결 방법:

  1. 시스템 클러스터에서 MutatingWebhookConfiguration CR edr-sidecar-injector-webhook-cfg을 복제합니다.
  2. 시스템 클러스터에서 ValidatingWebhookConfiguration CR gatekeeper-validating-webhook-configuration을 복제합니다.
  3. 시스템 클러스터에서 edr-sidecar-injector-webhook-cfg CR과 gatekeeper-validating-webhook-configuration CR을 모두 삭제합니다.
  4. edr-sidecar-injector 포드가 다시 시작되고 gatekeeper-controller-manager이 다시 시작될 때까지 기다립니다.
  5. kubectl apply 명령어를 사용하여 웹훅 CR을 복원합니다.

CIDR 클레임 변경사항에 따라 PANW 방화벽 주소 그룹이 업데이트되지 않음

버전: 1.13.1

증상: 부트스트랩 중에 OCIT cidr-claim는 올바른 값으로 업데이트되지만 방화벽 AddressGroups는 업데이트되지 않습니다. AddressGroups 쌍, 특히 vsys1-root-ocit-network-cidr-group 및 ocvsys1-root-ocit-network-cidr-group는 OIR에서 실제로 사용되는 것과 중복되지 않는 네트워크 블록을 사용합니다. OIR이 GDC 영역 레코드를 확인할 수 없으며 응답 없이 쿼리가 타임아웃됩니다.

해결 방법: cidr-claim 변경 후 루트 관리자 클러스터의 fw-system 네임스페이스에서 fw-core-backend-controller 배포를 다시 시작하여 AddressGroup가 최신 cidr-claim로 업데이트되도록 합니다.

물리적 서버

HPE 서버의 POST 문제로 인해 서버 부트스트랩이 실패함

버전: 1.13.1

증상: 서버가 POST 부팅 프로세스를 통과하지 못하면 서버 부트스트랩이 실패합니다. ILO에 로그인하고 서버의 콘솔을 확인하면 다음 오류가 표시됩니다.

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

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

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

ACTION : Reboot the server.

해결 방법:

iLO에서 전원 버튼을 클릭하고 Cold Boot을 선택합니다.

서버가 프로비저닝 상태로 멈춰 있음

버전: 1.13.1, 1.13.3, 1.13.5

증상: 서버 부트스트랩 중에 서버가 프로비저닝 상태에서 멈춰 있습니다. 서버 상태를 확인합니다.

k get servers -A | grep -v availabl

출력은 다음과 같이 표시될 수 있습니다.

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

해결 방법:

  1. KIND 클러스터에서 다운로드한 구성으로 dhcp를 수동으로 시작합니다. 이 예시에서 /tmp/dhcp.conf은 KIND 클러스터의 dhcp 구성입니다.

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

    루트 및 조직 관리자 클러스터의 수동 파일 구성요소 업그레이드의 업그레이드 안내에 설명된 대로 VERSION를 출시 버전으로 바꿉니다(예: 1.13.1-gdch.525).

  2. 서버의 BIOS 구성을 확인하고 데이터 플레인 NIC (Slot{i}Nic{i} 패턴으로 이름 지정됨)에 NetworkBoot가 사용 설정되어 있지 않은지 확인합니다.

  3. API 호출로 BIOS를 확인합니다.

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

    여기서 $bmcUser과 $bmcPassword은 ILO의 비밀번호이며, bmc-credentials-<server-name>라는 비밀에 있는 cellcfg 파일 또는 디렉터리에서 찾을 수 있습니다(예: bmc-credentials-ai-aa-bm01). 이 명령어의 출력에 Slot1Nic1: Disabled가 표시되는지 확인합니다.

  4. 이러한 Slot{i}Nic{i}에 NetworkBoot이 있으면 BIOS 설정 API로 사용 중지합니다.

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

    Slot{i}Nic{i}을 페이로드에 문제가 있는 슬롯 이름으로 바꿉니다.

  5. 서버를 다시 시작합니다.

DL380a 서버 프로비저닝 실패

버전: 1.13.3, 1.13.4, 1.13.5

증상: HPE DL380a 모델의 암호화 작업에서 서버 프로비저닝이 실패합니다. 서버 부트스트랩 중에 서버 CR 상태가 available에서 멈춥니다.

# server name
export SERVER_NAME=

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

해결 방법:

  1. IAM-R0004에 따라 root-admin-cluster의 KUBECONFIG를 생성합니다.

  2. PLATAUTH-G0001에 따라 CLUSTER_NS=root의 SSH 키 root-id_rsa를 생성합니다.

  3. 서버 커스텀 리소스에 server.system.private.gdc.goog/paused 주석을 추가하여 서버를 일시중지합니다.

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

  4. 관리 IP에서 서버에 로그인합니다.

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

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

  5. 수동으로 암호화를 사용 설정하려면 다음 단계를 따르세요.

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

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

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

    명령어의 출력은 다음과 비슷하게 표시됩니다.

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

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

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

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

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

    마지막 명령어가 성공하지 못했거나 '잘못된 BIOS EKM 상태'와 같은 오류가 표시되면 서버와 iLO를 재부팅한 후 이 단계를 다시 실행하세요.

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

    마지막 명령어가 성공하면 안내에 따라 서버를 재부팅합니다.

  6. 논리 드라이브를 수동으로 만듭니다.

    서버가 재부팅을 완료한 후 관리 IP에서 서버에 다시 로그인하고 사용 가능한 모든 드라이브를 나열합니다.

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

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

    마지막 명령어의 출력은 다음 예시와 같이 표시됩니다.

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

    이 경우 Size이 1.60 TB인 EID:Slt ID 2개를 저장해야 합니다.

    252:1,252:2

    그런 다음 EID:Slt ID를 사용하여 논리 드라이브를 만듭니다.

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

    마지막 명령어의 출력은 다음 예시와 같습니다.

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

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

  7. 서버 CR에서 디스크 암호화 상태를 모의합니다.

    서버 CR의 상태를 수정합니다.

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

    DiskEncryptionEnabled 상태를 true로 추가하거나 수정합니다.

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

  8. 서버 암호화 작업이 있는 경우 삭제합니다.

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

  9. 프로비저닝이 다시 시작되도록 서버를 일시중지 해제합니다.

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

라이선스가 없으면 완전 삭제가 실패함

버전: 1.13.5

증상: 서버 설치 중에 서버가 멈추면 서버 CR에 다음과 같은 상태가 표시될 수 있습니다.

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

해결 방법: SERV-R0014 런북의 안내를 따르세요.

플랫폼 보안

인증서에 일치하는 공개 키가 있는지 확인하지 않는 BYO SubCA 리컨실러

버전: 1.13.1

증상: 이전에 서명된 인증서가 하위 CA에 업로드된 상태에서 PKI BYO 하위 CA 모드가 새 인증서 서명 요청(CSR)을 생성하면 리컨실러가 새 CSR이 이전 서명된 인증서와 일치하는지 확인하지 않고 cert-manager CertificateRequest 커스텀 리소스 (CR)를 Ready로 표시합니다. 이는 SubCA 인증서 갱신 또는 수동 순환 중에 발생합니다. cert-manager 컨트롤러가 Certificate CR 상태를 업데이트하려고 하면 다음 오류 메시지가 트리거됩니다.

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

해결 방법:

안내에 따라 새 CSR의 서명된 새 BYO 하위 CA 인증서를 업로드합니다.

cert-manager 문제로 인해 ACME를 사용한 PKI BYO 발급이 실패함

버전: 1.13.1

증상: 자동 인증서 관리 환경 (ACME)을 사용하여 BYO 인증서를 처음 발급하거나 갱신할 때 오류가 발생합니다. 인증서 상태를 확인하는 명령어를 실행하면 인증서가 not ready로 표시됩니다.

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

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

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

해결 방법:

조직 관리자 클러스터에서 cert-manager 배포를 다시 시작합니다.

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

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

Resource Manager

GDC 콘솔에서 프로젝트 상태를 확인할 수 없음

버전: 1.13.1 이상

증상: GDC 콘솔에 프로젝트 상태가 표시되지 않습니다. Ready 상태가 아닌 프로젝트는 새 리소스를 지원하거나 기존 리소스에 대한 새 수정사항을 처리할 수 없습니다. 프로젝트 상태를 확인할 수 없기 때문에 프로젝트의 리소스를 언제 관리할 수 있는지 알 수 없어 새 프로젝트 작업을 시도할 때 오류가 발생합니다.

해결 방법: kubectl CLI를 사용하여 프로젝트 상태를 출력하려면 RM-R0100 런북을 참고하세요.

업그레이드

bm-system 및 기타 작업이 멈춤

버전: 1.13.1

증상: bm-system 및 ansible 플레이북을 실행하는 기타 작업이 gathering facts에서 멈춥니다.

해결 방법: 멈춘 노드의 이름을 입력하고 multipath -ll | grep failed 및 multipath -ll | grep #을 실행합니다. 비어 있지 않은 결과가 있으면 런북 FILE R0020 및 FILE R0021을 따릅니다.

연결할 수 없는 관리 IP

버전: 1.13.1, 1.13.3, 1.13.4, 1.13.5

증상: 업그레이드 중에 서버의 관리 IP에 연결할 수 없습니다(특히 스위치 후).

Rocky Linux에서는 정적 경로를 추가할 때 정적 경로에 도달하는 데 사용되는 대상 IP에 정적 경로를 추가하기 전에 도달할 수 있어야 합니다. OS 업그레이드 후 스위치가 재부팅되는 경우 해당 관리 IP에 일시적으로 연결할 수 없습니다.

해결 방법: 데이터 IP 주소를 사용하여 서버에 SSH 연결을 설정하고 네트워킹 서비스를 다시 시작하여 누락된 고정 경로를 다시 만듭니다.

systemctl restart NetworkManager.service

storagecluster의 버전 번호가 표시되지 않음

버전: 1.13.3

증상: 업그레이드 후 StorageCluster CR에 StorageVersion 상태 필드의 값이 표시되지 않습니다.

버전을 확인합니다.

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

버전 필드가 비어 있는 경우 해결 방법의 단계를 따릅니다.

해결 방법: file-storage-backend-controller 배포를 다시 시작합니다.

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

베어메탈 서버가 프로비저닝 상태에서 멈춤

버전: 1.13.1

증상:

조직을 생성할 때 베어메탈 서버가 '프로비저닝' 상태에서 오랫동안 멈춰 있습니다.

해결 방법:

서버의 BIOS 구성이 변경되어 서버가 Pxebooting에 잘못된 네트워크 카드를 사용하게 되었을 수 있습니다.

데이터 플레인 NIC 네트워크 부팅을 사용 중지하려면 다음 단계를 따르세요.

  • 액세스 필요:
    • 멈춘 서버의 bmc 관리자 사용자 인증 정보에 액세스할 수 있어야 합니다.
    • IAM-R0005에 따라 루트 관리자 클러스터에서 ClusterRole hardware-admin 역할을 1시간 동안 획득합니다.
    • IAM-R0004에 따라 루트 관리자 클러스터의 KUBECONFIG를 생성합니다.

  1. 멈춘 서버의 이름을 설정합니다.

    export SERVER_NAME=

  2. 서버 BMC의 IP 및 사용자 인증 정보를 설정합니다.

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

  3. 서버에서 데이터 플레인 네트워크 카드의 PCIe 슬롯을 식별합니다.

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

    예를 들어 다음 출력은 네트워크 카드가 슬롯 3에 설치되어 있음을 나타냅니다.

    ["s3p1","s3p2"]

    PCIEslot 변수를 설정합니다.

    export DATA_NIC_SLOT=3

  4. 네트워크 부팅이 사용 중지되어 있지 않은지 확인합니다.

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

    결과가 'NetworkBoot'인 경우 명시적으로 사용 중지해야 합니다.

  5. BMC를 사용하여 데이터 플레인 네트워크 카드의 네트워크 부팅 기능을 사용 중지합니다.

    다음 명령어에서 'Slot3'을 실제 슬롯 번호로 바꿉니다.

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

    그런 다음 머신을 재부팅합니다.

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

    서버가 다시 작동하는 데 10~15분이 걸리며 프로비저닝 프로세스가 자동으로 재개됩니다.

실행 후 또는 실행 전 검사 중에 객체 스토리지 업그레이드에 오류가 표시됨

버전: 1.13.1

증상: 실행 전 검사 또는 실행 후 검사가 오류와 함께 실패합니다. 로그 확인하기:

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

오류는 다음과 같이 표시될 수 있습니다.

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

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

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

해결 방법:

  1. 비행 후 검사 중에 오류가 발생하고 다른 모든 검사가 오류 없이 완료된 경우 비행 후 검사를 건너뜁니다. 업그레이드가 다시 시작되면 루트 관리자 kubeconfig를 사용하여 실행 전 검사도 건너뛰어야 합니다.

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

    예를 들어 org-1에서 오류가 발생하면 명령어는 다음과 같습니다.

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

  2. 실행 전 검사 중에 오류가 발생하고 다른 모든 실행 전 검사가 오류 없이 완료된 경우 실행 전 검사를 건너뛰세요.

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

    예를 들어 org-1에서 오류가 발생하면 명령어는 다음과 같습니다.

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

이 해결 방법을 적용하지 못하는 경우 두 번 이상 적용해야 할 수도 있습니다.

Helm 업그레이드 롤백

버전: 1.13.3

증상: Helm 업그레이드 문제로 인해 일련의 롤백이 발생하고 Certificate 및 ServiceEntry를 찾을 수 없습니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

해결 방법: OCLCM-R0122 런북의 단계를 따릅니다.

dhcp-tftp-core-server 포드가 드레인되지 않아 노드 업그레이드 또는 ABM이 멈춤

버전: 1.13.3, 1.14.4, 1.14.5

증상: 노드 업그레이드가 멈출 수 있습니다. 베어메탈 머신 상태에서 dhcp-tftp-core-server 포드가 드레인되지 않습니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

해결 방법: dhcp-tftp-core-server-* 포드를 강제 삭제하여 계속합니다. 명령어는 다음과 같습니다.

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

OrganizationUpgrade이 노드 업그레이드 단계에서 멈춤

버전: 1.13.3

증상: OrganizationUpgrade이 노드 업그레이드 단계에서 멈춥니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

해결 방법:

  1. 루트 클러스터 ka get upgradetaskrequest -n gpc-system에서 upgradetaskrequest CR을 확인합니다. 노드가 아직 실행 중 상태인지 확인합니다. 서비스 작업에서 멈춰 있는지 확인합니다.

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

  2. 노드 풀 클레임마다 nodeupgrade CR을 수동으로 만듭니다.

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

  3. 각 노드 풀 클레임의 nodeupgrade CR을 만듭니다. upgrade.private.gdc.goog/target-release-version 주석의 세부정보는 타겟의 OS CRMD 이름에서 가져와야 합니다.

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

  4. 주석 upgrade.private.gdc.goog/target-release-version에서 여기의 버전을 사용합니다.

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

  5. 각 nodepoolclaim에 다음 yaml을 적용합니다.

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

  6. 서비스 클러스터 노드의 노드 업그레이드가 완료되면 조직 업그레이드가 다음 단계로 진행되도록 UpgradeTaskRequest CR 상태를 True로 업데이트합니다.

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

  7. 이제 조직 업그레이드가 다음 단계로 진행되고 서비스 또는 노드의 상태가 완료됩니다.

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

커널에서 컨테이너를 만들지 못함

버전: 1.13.3

증상: 커널이 메모리 cgroup를 할당하지 못하여 새 컨테이너를 만들지 못합니다.

다음과 같은 메시지가 표시될 수 있습니다.

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

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

노드에서 매우 많은 수의 cgroup을 사용하고 있습니다.

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

해결 방법:

다음 중 하나를 따르세요.

  1. 노드에서 echo 3 > /proc/sys/vm/drop_caches를 실행하고 kubelet을 다시 시작합니다.
  2. 이전 방법이 작동하지 않으면 노드를 다시 시작해 보세요.

외부 클러스터 VIP에 대한 간헐적인 연결 실패

버전: 1.13.3

증상: 컨트롤 플레인 VIP, istio-gateway VIP, Harbor VIP와 같은 외부 클러스터 가상 IP (VIP)에 간헐적으로 연결이 실패하여 dial tcp :: connect: no route to host 오류가 발생합니다.

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

  1. 루트 관리자 클러스터에 연결합니다. 이 해결 방법은 루트 관리자 클러스터의 IP 주소를 디버깅한다고 가정합니다. 조직 관리자 또는 조직 시스템 클러스터와 같은 다른 Kubernetes 클러스터와의 연결 문제를 디버깅하는 경우 KUBECONFIG 값을 올바른 클러스터 kubeconfig 경로로 변경합니다.

  2. 영향을 받을 수 있는 IP에는 두 가지 알려진 카테고리가 있습니다. 경계 게이트웨이 프로토콜 (BGP)이 IP 주소를 ToR (Top-of-Rack) 스위치에 공지하는지 확인합니다.

    • IP가 192.0.2.100와 같은 Kubernetes 컨트롤 플레인 IP 주소인 경우 다음 명령어를 사용하여 구성 정보를 가져옵니다.

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

      KUBECONFIG를 루트 관리자 클러스터의 kubeconfig 파일 경로로 바꿉니다.

    • 일부 구성의 경우 BGPAdvertisedRoute 커스텀 리소스는 BGP를 사용하여 다른 네트워크나 시스템에 공지되는 IP 주소의 경로를 정의합니다. IP 주소가 BGPAdvertisedRoute 커스텀 리소스에 의해 공지되는 경우 이 명령어를 사용하여 구성 정보를 가져옵니다.

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

      TARGET_IP_ADDRESS를 간헐적인 연결 문제가 발생하는 IP 주소로 바꿉니다.

  3. BGPSession 커스텀 리소스의 상태를 확인합니다. BGPSession는 Kubernetes 클러스터와 외부 BGP 피어 간에 설정된 개별 BGP 피어링 세션을 나타냅니다. BGPAdvertiser 포드의 로그를 검사하고 모든 BGPSession 리소스가 Established 상태인지 확인합니다.

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

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

    정상 BGPAdvertiser 포드의 출력에는 다음 스니펫이 포함됩니다.

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

  4. 연결 안정성을 확인합니다. 연결이 간헐적인지 아니면 불안정한지 확인하는 스크립트를 만들고 실행합니다.

    1. 스크립트를 만듭니다.

      #!/bin/bash

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

    2. 스크립트를 실행합니다.

      ./script.sh TARGET_IP_ADDRESS:PORT

      PORT를 문제가 발생한 포트 번호로 바꿉니다.

      연결에 문제가 있으면 다음과 같은 출력이 표시됩니다.

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

  5. 이전 출력에서 문제를 확인할 수 있습니다. TOR 스위치의 경로를 확인하여 TOR 스위치 구성이 문제의 원인인지 확인합니다.

    192.0.2.201 IP 주소의 트래픽이 삭제되고 BGPAdvertisedRoute 리소스에 의해 공지된다고 가정하고 BGPAdvertisedRoute 리소스의 홉을 검사하여 잠재적인 장애 지점을 식별합니다.

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

  6. nextHops 필드의 IP 주소를 확인합니다. 각 IP 주소의 서버 이름을 찾습니다. 예를 들면 다음과 같습니다.

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

  7. 이 출력은 다음 홉이 랙 aa 및 랙 ab의 서버를 향하고 있음을 보여줍니다. 랙 aa 및 ab의 TOR 스위치에 로그인하고 두 랙의 경로를 비교합니다.

    show ip route 192.0.2.201 vrf root-external-vrf

  8. 두 랙의 TOR 스위치 간에 경로가 다른 경우 이 해결 방법으로 완화할 수 있는 문제가 발생한 것입니다. 이 문제의 출력은 다음과 같이 표시됩니다.

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

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

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

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

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

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

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

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

    이 출력에서 랙 aa의 라우트는 예상 상태에 있으며, 접두사에 대해 나열된 세 개의 다음 홉을 보여줍니다. 하지만 랙 ab에서는 프리픽스에 다음 홉이 두 개만 있습니다. 접두사로 향하는 트래픽이 랙 ab로 해싱되면 누락된 다음 홉에 해당하는 노드가 트래픽을 수신하지 않으며 네트워크에 연결 문제가 발생합니다.

해결 방법을 따라 이 문제를 완화하세요.

해결 방법:

이 해결 방법은 Kubernetes 클러스터 내 특정 IP 주소에 대한 간헐적인 연결 문제를 해결하는 데 도움이 됩니다.

이 문제를 완화하려면 집계 스위치 간의 BGP 세션에 여러 구성 변경사항을 적용해야 합니다. 집계 (AGG) 스위치는 여러 TOR 스위치의 트래픽을 집계합니다. 필요한 모든 구성을 업데이트하려면 다음 단계를 따르세요.

  1. switchstaticconfig이라는 구성 파일은 단일 스위치의 정적 구성을 나타냅니다. 두 AGG 스위치의 switchstaticconfig 파일을 다운로드합니다.

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

  2. 환경의 자율 시스템 번호 (ASN)를 가져옵니다.

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

    이 출력에는 ASN 값 65030이 표시됩니다. 다음 단계에서는 여기에 반환된 ASN 값을 사용해야 합니다.

  3. AGG 스위치의 루프백 IP 주소는 다른 네트워크 연결이 다운된 경우에도 관리, 라우팅, 문제 해결을 위한 안정적이고 항상 사용 설정된 주소 역할을 합니다. 각 AGG 스위치의 루프백 IP 주소를 가져옵니다.

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

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

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

  4. za-ab-aggsw01 AGG 스위치의 staticswitchconfig 업데이트 config 섹션에 다음 스니펫을 추가합니다.

    spec:
  config: |

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

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1

    다음을 바꿉니다.

    • ASN: 이전 단계의 ASN 값입니다. 이 예시에서 이 값은 65030입니다.
    • LOOPBACK_ADDRESS: AGG 스위치 za-ac-aggsw01의 루프백 IP 주소입니다. 이 예시에서 값은 192.0.2.2입니다.

  5. 다른 AGG 스위치(za-ac-aggsw01)에도 동일한 업데이트를 적용합니다. 올바른 루프백 주소를 제공해야 합니다. 루프백 IP 주소는 스위치마다 다릅니다.

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

  6. 이 단계에서 문제를 진단하는 데 사용한 것과 동일한 스크립트를 만들어 실행하여 수정이 성공했는지 확인합니다. 출력에 오류 메시지가 표시되지 않습니다.

업그레이드 중에 Incorrect version of Trident 오류가 표시됨

버전: 1.13.3, 1.13.4, 1.13.5

증상: 1.13.3 미만 버전에서 업그레이드하면 ontap에 Incorrect version of Trident 오류가 표시됩니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

해결 방법:

  1. 업그레이드할 버전의 releasemetadata를 업데이트합니다.

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

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

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

  2. 다음 예와 같이 업그레이드할 버전을 선택합니다.

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

  3. .yaml의 fileBlockStorage 섹션 아래에 있는 tridentVersion을 오류에 언급된 버전으로 업데이트합니다. 오류 메시지가 다음과 같은 경우:

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

    releasemetadata.yaml에서 tridentVersion을 v23.10.0-gke.5로 변경합니다.

    예를 들어 원래 값이 infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6인 경우

    다음 값으로 변경합니다.

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

  4. 변경사항을 적용합니다.

    kubectl apply -f releasemetadata.yaml

  5. ontap 스토리지 업그레이드를 다시 적용합니다.

pod 예약 실패

버전: 1.13.3. 1.13.4, 1.13.5

증상: 사용자 클러스터 프로비저닝 중에 일부 포드가 예약되지 않습니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

해결 방법:

사용자 클러스터 컨트롤 플레인 노드 풀을 스케일 업합니다.

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

iac-zoneselection-global 하위 구성요소에서 업그레이드 실패

버전: 1.13.1

증상: 1.13.3으로 업그레이드하는 동안 하위 구성요소 iac-zoneselection-global에서 오류가 발생합니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

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

해결 방법:

1.13.3으로 업그레이드하면 오류가 해결됩니다.

업그레이드 확인 작업의 기한이 지남

버전: 1.12.x, 1.13.x

증상: 조직 업그레이드 중에 업그레이드 확인에 상태 False와 이유 DeadlineExceeded이 표시됩니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

해결 방법:

  1. 실패한 업그레이드 확인에 해당하는 실패한 업그레이드 확인 작업을 삭제합니다.
  2. 업그레이드 확인 작업이 다시 생성될 때까지 기다립니다.
  3. 다시 만든 작업의 로그를 살펴보고 문제를 분류합니다.

strongswan 위치가 다른 런타임 디렉터리에 있어 meta-monitoring 부가기능이 실패함

버전: 1.12.x, 1.13.x

증상: 1.13.4 또는 1.13.5로 업그레이드하는 동안 meta-monitoring 부가기능이 실패합니다.

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

애드온을 확인합니다.

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

조건 메시지는 다음과 같이 표시될 수 있습니다.

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

해결 방법:

  1. 조직 시스템 클러스터의 BGP 세션이 실패하는지 확인합니다. 예를 들면 다음과 같습니다.

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

  2. ang-node 포드가 ContainerCreating에 고정되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

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

    다음 오류가 표시됩니다.

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

  3. 조직 관리자 클러스터의 ang-overrides AddonConfiguration에 다음 변경사항을 적용합니다.

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

    다음을 변경합니다.

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

    다음과 같습니다.

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

  4. 1분 정도 후에 ang-node 포드가 이제 Running 상태인지 확인합니다.

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

  5. 조직 시스템 클러스터의 BGP 세션이 이제 실행 중인지 확인합니다.

  6. meta-monitoring 부가기능이 다음 단계로 진행됩니다.

서명 작업 실패로 인해 루트 조직 업그레이드가 중단됨

버전: 1.13.3, 1.13.4

증상: 1.13.3에서 1.13.4로 업그레이드할 때 다음과 같은 메시지가 표시될 수 있습니다.

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

해결 방법:

  1. 실행 전 검사를 사용 중지합니다.

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

  2. 실패한 artifact-signature-verification-*** 작업을 삭제합니다.

  3. 루트 업그레이드가 완료될 때까지 기다립니다.

  4. 선택사항: 환경이 1.13.4 이상으로 업그레이드된 경우 프리플라이트 검사를 사용 설정합니다.

컨트롤러가 1.13.4가 되면 업그레이드에 이 문제가 발생하지 않습니다.

ErrImagePull으로 인해 실행 전 검사 단계에서 테넌트 조직 업그레이드가 실패함

버전: 1.13.3

증상: 패키지 검증 포드의 경우 ErrImagePull를 사용하여 실행 전 검사 단계에서 테넌트 조직 업그레이드가 실패합니다. 다음과 같은 메시지가 표시될 수 있습니다.

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

포드에 ImagePullBackOff 오류가 표시됩니다.

kubectl describe po -n package-validation-system POD_NAME

다음 예와 같은 이미지 가져오기 오류가 표시됩니다.

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

해결 방법:

프리플라이트 검사를 건너뛰려면 다음을 실행하세요.

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

루트 조직 업그레이드 중에 serviceaccount를 찾을 수 없음

버전: 1.13.8, 1.13.9

증상: 1.13.8로 업그레이드하는 동안 이전 업그레이드가 완료되고 부가기능이 이미 있는 경우 RBAC용 addon 배포가 실패합니다. 증상은 다음 단계 중 하나일 수 있습니다.

  1. 프리플라이트 또는 포스트플라이트 검사
  2. 업그레이드 작업이 포함된 단계에서 작업이 멈춰 있는데도 작업이 실행 중이라는 메시지가 표시됩니다. status.conditions 메시지는 작업이 오랫동안 실행되고 있음을 나타내며, 이는 문제가 있음을 나타냅니다.

업그레이드 프리플라이트 검사 실패가 있는지 확인하려면 업그레이드하는 조직의 해당 OrganizationUpgrade 객체 상태를 확인하세요.

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

  1. 실행 전 검사에서 작업이 실패하면 다음과 같은 실패 또는 UpgradeCheckRBACDeploymentInProgress 메시지가 표시될 수 있습니다.

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

  2. 작업이 실행되는 AnthosBareMetal (ABM) 단계에서 작업이 실패하면 다음 출력이 표시됩니다.

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

  3. 실패가 검사에 있는 경우 upgradecheckrequest CR이 실패합니다.

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

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

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

  4. 작업에 실패가 있는 경우 upgradetaskrequests CR이 실패합니다.

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

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

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

  5. 실패가 서비스 계정 조회 시 RBAC 오류를 나타내는 경우 이전 부가기능이 배포되었는지 확인합니다.

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

해결 방법:

  1. 이전 부가기능이 배포되었는지 확인합니다.

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

  2. 동일한 구성요소(upgrade-task-mz)에 대해 이전에 존재했던 부가기능을 가져옵니다.

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

  3. 이 부가기능을 삭제합니다.

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

  4. 부가기능을 삭제한 후에는 해당 upgradetaskrequest 또는 upgradecheckrequest도 삭제합니다. 다시 생성됩니다.

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

  5. 새로 생성된 upgradetaskrequest, upgradecheckrequest 또는 해당 작업을 직접 계속 모니터링합니다.

shared-service-cluster upgrade에서 업그레이드 실패

버전: 1.13.3

증상: 하나 이상의 베어메탈 머신에서 Anthos 베어메탈 업그레이드가 멈춥니다. 다른 모든 베어 메탈 머신은 업그레이드가 완료되었거나 아직 업그레이드를 시작하지 않았습니다. 베어메탈 머신 하나가 유지보수 모드에 있지만 현재 ABM 버전과 원하는 ABM 버전 필드 모두에 이전 버전이 계속 표시됩니다.

Anthos 베어메탈에 따라 클러스터의 baremetalmachine 상태와 세부정보를 가져옵니다.

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

예상 출력:

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

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

예상 출력:

true

해결 방법:

  1. 인벤토리 머신을 유지보수 모드에서 이동합니다.

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

  2. 인벤토리 머신이 유지보수 모드를 종료할 때까지 기다립니다. 이 과정에는 최대 10분이 소요될 수 있습니다.

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

  3. 베어메탈 머신을 모니터링하여 머신에 선택한 ABM 버전 업데이트가 표시되는지 확인합니다.

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

system-dashboards 부가기능 설치 실패

버전: 1.13.5

증상: 1.12.4에서 1.13.5로 업그레이드할 때 system-dashboards 부가기능의 부가기능 업그레이드가 실패합니다.

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

해결 방법: OCLCM-R0122 런북의 단계를 따르세요.

NodeUpgradeTask CR이 NodeOSInPlaceUpgradePostProcessingCompleted 조건에서 멈춤

버전: 1.13.5

증상: 1.13.5로 업그레이드하는 동안 NodeUpgradeTask CR이 NodeOSInPlaceUpgradePostProcessingCompleted 조건에서 멈춥니다.

해당 os-artifact-collector 작업이 완료되었는지 확인합니다. 작업이 몇 시간 동안 멈춰 있으면 다음 메시지가 표시됩니다.

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

해결 방법:

  1. 작업 또는 포드를 삭제하여 강제로 다시 시도합니다.

업그레이드 중에 이미지 배포가 실패함

버전: 1.13.5

증상: 1.12.4에서 1.13.x로 업그레이드하는 동안 이미지 배포가 실패합니다.

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

조직의 gpc-system에서 obj-proxy 포드를 확인하여 인증서 확인에 실패하는지 확인합니다.

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

해결 방법:

  1. 실패하는 조직의 KUBECONFIG를 사용하여 obj-proxy 포드를 다시 시작합니다.

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

  2. obj-proxy의 로그를 확인합니다. 

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

    예상 출력은 다음과 같습니다.

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

  3. 사용 가능한 포드의 로그를 확인합니다. 예를 들면 다음과 같습니다. 

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

  4. 해결 방법을 적용하면 이미지 배포 작업이 완료됩니다.

사용자 클러스터 업그레이드 중에 노드가 실패함

버전: 1.13.3

증상: 사용자 클러스터 업그레이드 중에 노드에서 실행되는 작업이 실패하고 다음과 같은 오류 메시지가 표시됩니다.

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

  1. 노드에 로그인하여 파티션이 가득 찼는지 확인합니다.

    df -h /

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

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

  2. /etc/kubernetes/tmp에서 많은 공간을 사용하고 있는지 확인합니다(du -s /etc/kubernetes/tmp). 이 문제는 Kubernetes에서 평소보다 많은 백업을 만들 때 발생합니다.

해결 방법:

  1. rm -f /etc/kubernetes/tmp/*의 모든 백업을 삭제합니다.

    df -h /

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

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

루트 관리자 업그레이드가 다시 생성되고 실행 전 검사에서 실패함

버전: 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9

증상: 프리플라이트 검사로 인해 루트 조직 업그레이드가 실패합니다. 예를 들면 다음과 같습니다.

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

루트 관리자 클러스터와 루트 관리자의 kubeapiserver가 선택한 abm 버전으로 업그레이드되었습니다.

예:

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

kubectl describe kubeapiserver root-admin -n root의 출력 예:

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

kubectl get cluster root-admin -n root의 출력 예:

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

해결 방법

업그레이드를 계속하려면 프리플라이트 검사 건너뛰기를 적용하세요.

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

네임스페이스 platform-obs-obs-system 또는 platform-obs이 종료 중 상태로 멈춤

버전: 1.13.5

증상: 업그레이드 또는 부트스트랩 중에 애드온이 배포되지 않고 다음과 같은 오류 메시지가 표시됩니다. 

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

다음 출력이 표시됩니다.

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

배포됨 또는 준비 상태에 false이 표시되거나 비어 있는 경우 오류가 있는지 해당 부가기능을 확인합니다. 예를 들면 다음과 같습니다.

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

다음 출력이 표시됩니다.

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

삭제 중인 네임스페이스에 콘텐츠를 만들려고 시도했기 때문에 부가기능이 차단되었습니다. 네임스페이스 삭제도 차단되므로 이 차단은 지속됩니다.

해결 방법:

  1. 업그레이드를 시작하기 전에 삭제를 방지하도록 프로젝트에 주석을 추가합니다.

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

    다음 출력이 표시됩니다.

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

    환경에 이미 앞에서 설명한 증상이 나타나고 있다면 다음 해결 방법을 따르세요.

  2. 파이널라이저가 있는 리소스로 인해 네임스페이스 삭제가 차단되었습니다. 삭제를 진행하려면 제공된 스크립트를 사용하여 파이널라이저를 삭제하세요. 

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

  3. 리소스 삭제를 기다립니다. 스크립트를 실행한 후 리소스와 종료 네임스페이스를 삭제합니다. 네임스페이스가 여전히 종료 중 상태로 멈춰 있는 경우 스크립트를 다시 실행해야 할 수 있습니다. 종료되면 네임스페이스가 자동으로 다시 생성됩니다. 네임스페이스가 다시 생성되고 ACTIVE 상태인지 확인합니다.

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

    다음 출력이 표시됩니다.

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

    활성 네임스페이스를 사용하면 멈춘 부가기능이 몇 분 이내에 배포됩니다. DEPLOYED 및 READY 상태가 이제 true인지 확인합니다.

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

    다음 출력이 표시됩니다.

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

부트스트랩 중에 KIND 클러스터에서 UPORC 비정상 종료가 반복됨

버전: 1.13.x

증상: 네임스페이스 uporc-system 아래의 배포 uporc-root-backend-controller가 KIND 클러스터에서 비정상 종료 루프를 실행합니다.

해결 방법:

  1. ComponentGroupReleaseMetadata 객체와 ReleaseMetadata 객체가 일치하는지 확인합니다.

    export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata

    객체가 일치하면 해결 방법이 필요하지 않습니다.

  2. 객체가 일치하지 않으면 UPORC팀에 문의하여 지원을 받으세요. 다른 기본 문제가 있을 수 있습니다.

노드를 업그레이드할 수 없습니다.

버전: 1.13.6

증상: NodeOSInPlaceUpgradeCompleted에서 노드 업그레이드에 실패했습니다.

  1. os-upgrade ospolicy 작업의 로그를 확인합니다.
  2. 로그에 구성 파일이 손상되었음을 나타내는 오류가 포함된 경우 노드 머신에 들어가 파일을 수동으로 확인하여 손상되었는지 확인합니다. 로그 오류에 configparser.DuplicateOptionError 오류 코드와 /etc/yum.repos.d/gdch.repo 파일이 언급될 수 있습니다.

해결 방법: 파일이 손상되었는지 확인한 경우에만 손상된 /etc/yum.repos.d/gdch.repo 파일을 손상된 노드에서 수동으로 삭제합니다.

업그레이드용 ansible 작업은 ansible 플레이북의 일부로 파일을 자동으로 재생성합니다.

### NodeUpgradeTask CR이 NodeOSInPlaceUpgradePostProcessingCompleted 조건에서 멈춤

버전: 1.13.5

증상: 1.13.5로 업그레이드하는 동안 NodeUpgradeTask CR이 NodeOSInPlaceUpgradePostProcessingCompleted 조건에서 멈춥니다.

해당 os-artifact-collector 작업이 완료되었는지 확인합니다. 작업이 몇 시간 동안 멈춰 있으면 다음 메시지가 표시됩니다.

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

해결 방법:

  1. 작업 또는 포드를 삭제하여 강제로 다시 시도합니다.

NodeUpgradeTask CR이 NodeBIOSFirmwareUpgradeCompleted 조건에서 멈춤

버전: 1.13.5

증상: 1.13.5로 업그레이드하는 동안 NodeUpgradeTask CR이 NodeBIOSFirmwareUpgradeCompleted 조건에서 멈춥니다.

다음 조건이 표시되어 해당 NodeBIOSFirmwareUpgradeCompleted 조건이 멈췄는지 확인합니다.

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

해결 방법:

  1. NodeUpgrade CR에서 "U30 v3.20 (05/29/2024)"을 "U30 v3.20 (05/27/2024)"로 수동으로 수정합니다.

노드가 유지보수 모드로 전환되지 않아 클러스터 업그레이드가 차단됨

버전: 1.13.5, 1.13.6, 1.13.7

증상: 노드가 유지보수 모드로 전환되지 않아 클러스터 (조직 관리자, 시스템 또는 사용자 클러스터) 업그레이드가 차단됩니다.

클러스터에 MaintenanceMode이 true로 설정되어 표시되지만 다음을 실행하면 Status이 false에 멈춰 있습니다.

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

다음 출력이 표시됩니다.

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

해결 방법:

KUBECONFIG를 드레인되지 않은 노드가 포함된 클러스터의 kubeconfig 파일로 설정합니다. 클러스터는 사용자 클러스터 또는 공유 서비스 클러스터일 수 있습니다.

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

초기 루트 organizationupgrade 중에 지속적인 시간 초과 발생

버전: 1.13.3

증상: 조직 업그레이드 중에 유지보수 기간 무시 주석이 있으면 organizationupgrade CR에 패치가 반복적으로 적용되어 진행 상황이 재설정됩니다.

해결 방법:

하위 구성요소 rm-org를 일시중지하고 rm-org-backend-controller 복제본을 축소합니다.

  1. 별칭이 선언되지 않은 경우 다음을 실행합니다.

    alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"

  2. 하위 구성요소를 일시중지하고 rm-org의 배포를 축소합니다.

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG annotate subcomponent -n root rm-org lcm.private.gdc.goog/paused=true
kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=0

  3. 클러스터 업그레이드가 완료되면 배포를 축소합니다.

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

하위 구성요소 obj-syslog-server가 루트 조직에서 조정에 실패함

버전: 1.13.3, 1.13.4, 1.13.5, 1.13.6

증상: 버전 1.13.x로 업그레이드하는 동안 하위 구성요소 obj-syslog-server이 ReconciliationError 상태인 것으로 확인됩니다.

root        obj-syslog-server     ReconciliationError

다음과 유사한 조건으로

Sub-Component: obj-syslog-server - Reconciliation error: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded

Last Transition Time: 2024-09-17T21:49:25Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     ReconciliationError
     Status:True
     Type: Reconciling
     Last Transition Time: 2024-09-17T21:49:23Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     Reason: DeployError
     Status: False
     Type: Deployed

포드 syslog-server-abcdefg-wxyz가 CrashLoopBackOff 상태이고 다음과 같은 오류가 표시될 수 있습니다.

       containerID: containerd://65d460176a1dcae412af698fa02fa5ffb0c5f0ef9bf0d0e2111ef88845630827
       exitCode: 128
       finishedAt: "2024-09-18T19:14:45Z"
       message: 'failed to create containerd task: failed to create shim task: OCI
         runtime create failed: runc create failed: unable to start container process:
         error during container init: error mounting "/var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2"
         to rootfs at "/etc/ssl/certs/obs-ca-cert.pem": mount /var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2:/etc/ssl/certs/obs-ca-cert.pem
         (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown'
       reason: StartError
       startedAt: "1970-01-01T00:00:00Z"

해결 방법:

하위 구성요소를 정상 상태로 되돌리려면 불필요한 volumeMounts를 삭제합니다.

  1. 현재 배포를 수정합니다.

    export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

    kubectl edit deployments syslog-server -n istio-system

  2. spec.containers.volumeMounts에서 필요하지 않은 volumeMounts를 삭제합니다. 다음 마운트 경로를 삭제합니다.

        - mountPath: /etc/ssl/certs/obs-ca-cert.pem
      name: observability-ca
      readOnly: true1.
      subPath: ca.crt
    - mountPath: /etc/ssl/certs/obj-ca-cert.pem
      name: obj-ca
      readOnly: true
      subPath: ca.crt

  3. 변경사항을 적용하면 변경사항이 적용된 후 하위 구성요소가 ReconciliationCompleted로 돌아옵니다.

ABM 또는 노드 업그레이드가 maintenanceMode false에서 중단됨

버전: 1.13.4

증상: 노드가 AnthosBaremetal 클러스터 업그레이드에서 멈추고 노드가 유지보수 모드로 전환되지 않습니다.

서비스 클러스터 노드에서 baremetalmachine을 확인합니다. 예를 들면 다음과 같습니다.

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

해결 방법:

BMM.MaintenanceMode을 전파하기 위해 anthos-cluster-operator을 다시 시작합니다.

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

테넌트 조직의 atat-webhooks 부가기능 업그레이드 시 업그레이드가 실패함

버전: 1.13.5

증상: atat-webhooks 부가기능 업그레이드가 복구되지 않습니다.

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

다음과 같은 메시지가 표시될 수 있습니다.

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

atat-webhooks-parameters-*****의 포드를 확인합니다. 

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

다음과 같은 오류가 표시될 수 있습니다.

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

해결 방법:

  1. 현재 포트폴리오의 사본을 만듭니다.

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

    kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

  2. portfolio-org-1 Pop End Date을 미래 날짜로 업데이트합니다.

    kubectl delete portfolios -n atat-system portfolio-org-1

    이 명령어가 응답을 중지하면 포트폴리오를 삭제하기 전에 활성 포트폴리오에서 .Metadata.Finalizers 조건을 삭제하세요. 조건은 다음과 같을 수 있습니다.

    │     portfolio.finalizers.atat.config.google.com

  3. 복사된 YAML 파일을 다시 적용합니다.

    kubectl apply -f portfolio-org-1

  4. 날짜를 다시 확인하여 포트폴리오와 구성 맵이 모두 업데이트되었는지 확인합니다.

  5. 작업이 복구되지 않으면 실패한 atat-webhooks-parameters 작업을 삭제하면 복구됩니다. 완료될 때까지 기다립니다.

    kubectl delete jobs -n org-1 atat-webhooks-parameters

DeadlineExceeded 또는 BackoffLimitExceeded 오류로 인해 사후 비행 또는 업그레이드 확인이 실패합니다.

버전: 1.13.8

증상:

1.13.7에서 1.13.8로 업그레이드하는 동안 비행 후 확인이 아직 대기 상태이며 DeadlineExceeded 또는 BackoffLimitExceeded 오류가 표시됩니다.

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

해결 방법:

작업이 실패하는 위치를 확인합니다.

  1. 실행 전 또는 실행 후 검사 중에 작업이 실패하는지 확인합니다.

    kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  2. 업그레이드 중에 작업이 실패하는지 확인합니다.

    kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  3. 작업을 삭제합니다.

    kubectl delete jobs -n gpc-system CHECK_NAME

업그레이드 검사에 검사 수준과 관련 없는 결과가 포함됨

버전: 1.13.x

증상:

다른 수준의 결과가 잘못 포함되어 조직 업그레이드 확인이 실패할 수 있습니다. 예를 들어 루트 조직 확인에서 테넌트 조직 결과가 표시되거나 테넌트 조직 확인에서 사용자 클러스터 결과가 표시될 수 있습니다.

루트 조직 확인의 실패 로그 예시:

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

해결 방법:

다음과 같이 프리플라이트 또는 포스트플라이트 검사를 완전히 건너뜁니다.

프리플라이트:

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

포스트플라이트:

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

Vertex AI

사전 학습된 API는 사용자 인터페이스에 Enabling 상태로 표시됩니다.

버전: 1.13.1

증상: 사용자 클러스터가 생성될 때 MonitoringTarget에 Not Ready 상태가 표시되어 사전 학습된 API가 사용자 인터페이스에 Enabling 상태를 계속 표시합니다.

해결 방법:

  1. Chrome 브라우저에서 메뉴 (점 3개 아이콘)를 엽니다.
  2. 도구 더보기 > 개발자 도구를 클릭하여 콘솔을 엽니다.
  3. 콘솔에서 네트워크 탭을 클릭합니다.
  4. ai-service-status 요청을 찾습니다.
  5. ai-service-status 요청에서 응답 탭을 클릭하여 해당 요청의 콘텐츠를 표시합니다.
  6. MonitoringTarget 및 LoggingTarget 구성요소를 제외한 모든 항목이 준비되었는지 확인합니다.

Speech-to-Text의 streaming_recognize 사전 학습된 API 기능이 실패함

버전: 1.13.3

증상: Speech-to-Text의 streaming_recognize 사전 학습된 API 함수를 호출할 때 클라이언트 라이브러리의 문제로 인해 다음과 유사한 400 오류 메시지가 표시됩니다.

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

해결 방법: 다음 Python 스크립트를 사용하여 streaming_recognize 함수가 작동하도록 합니다.

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

다음을 바꿉니다.

Python 스크립트에서는 streaming_recognize의 해결 방법을 작동시키기 위해 streaming_recognize 함수와 recognize 함수 간에 다음과 같은 차이점을 도입합니다.

  • 4번째 줄: recognize 스크립트 (from google.cloud.speech_v1p1beta1.services.speech import client)와 비교하여 추가된 import 문입니다.
  • 18번째 줄: 클라이언트가 speech_v1p1beta1.SpeechClient() 대신 client.SpeechClient()에 의해 반환됩니다.

번역 프런트엔드 포드 및 서비스가 초기화되지 않음

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

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

해결 방법:

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

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

SYSTEM_CLUSTER_KUBECONFIG를 시스템 클러스터의 kubeconfig 파일 경로로 바꿉니다.

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

batchTranslateDocument API에서는 작업 상태 폴링이 지원되지 않습니다.

버전: 1.13.3

증상: Vertex AI는 Translation 서비스 API에서 GET 및 LIST 작업을 지원하지 않습니다. Translation BatchTranslateDocument API를 호출하면 다음 예와 비슷한 장기 실행 작업이 반환됩니다.

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

이 문제는 엔드포인트를 직접 호출할 수 없도록 하는 APIP (승인) 제한으로 인해 발생합니다. 엔드포인트는 작업 상태 폴링을 지원하지 않으며 APIP 제한으로 인해 장기 실행 작업에 GET 작업을 실행할 수 없습니다.

해결 방법: 애플리케이션 운영자 (AO)는 s3_destination 폴더를 정기적으로 확인하여 작업 상태를 검토하고 새로 생성된 작업 출력 파일을 찾습니다. 폴더에 출력 파일이 포함되어 있으면 작업이 성공적으로 완료된 것입니다.

batchTranslateDocument 요청으로 인해 성능 문제가 발생할 수 있음

버전: 1.13.3

증상: 일괄 문서 번역 서비스가 하나 이상의 사용자 입력 파일을 읽고 StorageGRID에 임시 처리 및 번역된 출력 파일을 씁니다. 클라이언트 재사용이 실패하므로 각 읽기-쓰기 작업에 대해 새 curl 클라이언트가 생성됩니다.

바이너리의 S3 curl 클라이언트는 일회성 사용입니다. 즉, 각 클라이언트는 StorageGRID 버킷에서 단일 읽기-쓰기 작업만 실행할 수 있습니다. 따라서 버킷에서 파일을 읽고 쓰기 위해 batchTranslateDocument 서버에서 StorageGRID 클라이언트와의 통신이 설정될 때마다 새 curl 클라이언트가 생성됩니다.

하지만 curl 클라이언트에는 적합하지 않습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다.

  • 성능 저하: 지연 시간 증가 및 처리량 감소
  • 리소스 소진: 메모리 및 CPU 오버헤드, 소켓 소진
  • 서버 과부하: 비율 제한 또는 제한

사전 학습된 API를 사용 설정한 후 GDC 콘솔에 일관되지 않은 상태가 표시됨

버전: 1.13.3

증상: 사전 학습된 API를 처음 사용 설정하면 몇 분 후에 사용 설정된 서비스의 상태가 GDC 콘솔에 일관되지 않게 표시될 수 있습니다. 서비스가 실제로 사용 설정되어 있어도 GDC 콘솔은 Enabling 상태를 Disabled로 다시 전환하고 사용자 인터페이스에 사용 설정 버튼을 다시 표시합니다.

해결 방법: 몇 분 후에 상태가 일관되게 표시되고 서비스에 올바른 상태가 반영됩니다.

서비스 상태를 확인하려면 브라우저 콘솔에서 네트워크 탭을 열고 ai-service-status 요청 상태를 확인합니다. 페이로드에 L2 연산자가 사용 설정되어 있다고 표시되어야 합니다.

250자를 초과하는 번역 요청으로 인해 translation-prediction-server 포드가 비정상 종료됨

버전: 1.13.3

증상: 문서 번역 요청을 포함하여 약 250자 이상의 번역 요청을 보내면 translation-prediction-0 또는 translation-prediction-1 포드가 비정상 종료되어 모델을 다시 로드해야 할 수 있습니다. 모델 다시 로드는 자동으로 진행되며 이 과정은 해결하는 데 약 30분이 걸릴 수 있습니다.

이 문제는 번역 컨테이너의 제한사항으로 인해 발생합니다.

해결 방법: 번역 요청을 250자(영문 기준) 미만으로 분할합니다. 200~250자 사이의 범위는 모든 언어에서 안전합니다. 긴 요청으로 인해 포드가 비정상 종료되는 경우 이 문제를 완화하기 위해 다른 조치를 취할 필요는 없습니다.

공유 서비스 클러스터의 GPUAllocation가 올바르게 구성되지 않음

버전: 1.13.3

증상: GPU 리소스가 부족하여 Vertex AI 워크로드를 예약할 수 없습니다. 예를 들어 Vertex AI 서비스 엔드포인트를 보거나 사용 설정할 수 없는 경우 GPU 리소스가 부족하기 때문일 수 있습니다.

이 리소스 할당 문제는 공유 서비스 클러스터 내에 있는 일부 GPUAllocation 리소스에 다음 주석이 누락되어 발생할 수 있습니다.

processed: "true"

해결 방법:

  1. IAM-R0004에 따라 g-ORG_NAME-shared-service-cluster의 kubeconfig 파일을 생성합니다.

  2. 서비스 클러스터에서 processed: "true" 주석이 없는 모든 GPU 할당을 나열합니다.

    kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

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

    zi-ad-bm08

  3. 할당되지 않은 GPUAllocation 리소스를 편집기에서 엽니다.

    kubectl edit gpuallocation -n vm-system NODE_NAME

  4. 서비스 클러스터에 있는 총 GPU 할당을 기반으로 GPU 할당을 수정합니다.

    • GPU 할당 커스텀 리소스가 하나만 있는 경우 processed: "true" 주석을 추가하고 사양을 다음과 같이 수정합니다.

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • GPU 할당 커스텀 리소스가 두 개 있는 경우 processed: "true" 주석이 없는 리소스를 찾아 processed: "true" 주석을 추가하고 사양을 다음과 같이 수정합니다.

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • GPU 할당 커스텀 리소스가 4개인 경우 processed: "true" 주석이 없는 리소스를 찾아 processed: "true" 주석을 추가하고 사양을 다음과 같이 수정합니다.

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0

  5. GPUAllocation 커스텀 리소스의 변경사항을 저장하고 할당 상태가 true로 업데이트되었는지 확인합니다.

    kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

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

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

버전 1.9.x에서 1.13.3으로 업그레이드하면 OCLCM 컨트롤러에 오류가 표시됨

버전: 1.13.3

증상: 버전 1.9.x에서 1.13.3으로 업그레이드할 때 Vertex AI 하위 구성요소의 작동 가능한 구성요소 수명 주기 관리 (OCLCM) 컨트롤러에 오류가 표시될 수 있습니다. 이 문제는 ai_platform 부가기능 작업의 오류로 인해 발생합니다. 업그레이드 중에 표시되는 오류는 OCLCM이 이러한 Vertex AI 구성요소의 소유권을 이전할 수 없음을 나타냅니다.

영향을 받는 조직 관리자 클러스터의 Vertex AI 구성요소는 다음과 같습니다.

이름 네임스페이스
aip-l1operator-deployment ai-system
aip-l2operator-deployment ai-system
aip-web-plugin-frontend ai-system
aip-web-plugin-backend ai-system
aip-l1operator-sa ai-system
aip-l2operator-sa ai-system
aip-web-plugin-sa ai-system
aip-l1operator-role 해당 사항 없음
aip-l2operator-role 해당 사항 없음
aip-web-plugin-role 해당 사항 없음
aip-l1operator-rolebinding 해당 사항 없음
aip-l2operator-rolebinding 해당 사항 없음
aip-web-plugin-rolebinding 해당 사항 없음
aip-l1operator-log ai-system
aip-l2operator-log ai-system
aip-web-plugin-frontend-log ai-system
aip-web-plugin-backend-log ai-system
log-rule-aipl-a004 platform-obs
mon-rule-aipl-a0001 platform-obs
mon-rule-aipl-a0003 platform-obs
aip-l1operator-mon ai-system
aip-l1operator-mon-cm ai-system
aip-l2operator-mon ai-system
aip-l2operator-mon-cm ai-system
aip-l1operator-webhook-svc ai-system
aip-web-plugin-frontend-svc ai-system
aip-web-plugin-backend-svc ai-system
aip-web-plugin-frontend-virtualsvc ai-system
aip-web-plugin-backend-virtualsvc ai-system
aip-l1operator-selfsigned-issuer ai-system
aip-l1operator-serving-cert ai-system
aip-l1operator-validating-webhook ai-system
aip-l1operator-mutating-webhook ai-system

해결 방법: 이 문제를 해결하려면 조직 관리자 클러스터에서 영향을 받는 Vertex AI 구성요소를 수동으로 삭제해야 합니다. 그런 다음 Vertex AI의 새로운 OCLCM 기반 버전이 이를 다시 설치합니다.

조직 관리자 클러스터에서 영향을 받는 Vertex AI 구성요소를 수동으로 삭제합니다.

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

다음을 바꿉니다.

  • ORG_ADMIN_CLUSTER_KUBECONFIG: 조직 관리자 클러스터의 kubeconfig 파일 경로입니다.
  • NAMESPACE: 삭제하려는 Vertex AI 구성요소의 네임스페이스입니다. 구성요소에 네임스페이스가 없으면 명령어에서 -n NAMESPACE를 삭제합니다.
  • COMPONENT_NAME: 삭제하려는 Vertex AI 구성요소의 이름입니다.

다음 예시에서는 조직 관리 클러스터의 ai-system 네임스페이스에 있는 aip-l1operator-deployment 구성요소를 삭제하는 방법을 보여줍니다.

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

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

버전: 1.13.3

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

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

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

버전: 1.13.3

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

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

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

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

    ORG_ADMIN_NAMESPACE를 조직 관리자 클러스터의 네임스페이스로 바꿉니다.

  2. SubcomponentOverride 커스텀 리소스를 조직 관리자 클러스터에 적용합니다.

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f vai-translation.yaml

    ORG_ADMIN_KUBECONFIG를 조직 관리자 클러스터의 kubeconfig 파일 경로로 바꿉니다.

Vertex AI 사전 학습된 서비스를 사용할 수 없음

버전: 1.13.7, 1.13.9

증상: Kubernetes 일정 문제로 인해 Vertex AI OCR 및 번역 서비스가 시작되지 않습니다. 로그에 다음과 같은 경고가 표시될 수 있습니다.

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

해결 방법: 기본 풀에 워커 노드를 더 추가하고 GPU 노드의 포드를 삭제하여 AI 워크로드를 예약할 수 있도록 합니다.

가상 머신

qcow2 및 원시 이미지의 BYO 이미지 가져오기가 실패함

버전: 1.13.1, 1.13.3

증상: gdcloud compute images import CLI를 사용하여 로컬 VM 이미지를 가져오면 가져오기 상태가 WaitingForTranslationVM 또는 ImportJobNotCreated에 멈춥니다. 이는 변환 또는 가져오기를 위해 생성된 임시 디스크가 qcow2/원시 이미지와 정확히 동일한 크기를 사용하지만 LUKS가 디스크 프로비저닝 실패를 유발하는 몇 MiB의 오버헤드를 추가하기 때문입니다.

해결 방법:

동일한 이미지 이름이지만 더 큰 spec.minimumDiskSize을 사용하여 새 VirtualMachineImageImport를 수동으로 만듭니다.

예를 들어 이미지를 가져오는 데 사용된 명령어가 다음과 같은 경우

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

CLI에 의해 자동으로 생성된 원래 VirtualMachineImageImport에 X Gi가 minimumDiskSize로 있는 경우 X+1 Gi로 새 VirtualMachineImageImport를 만듭니다. 값은 가져오는 이미지의 크기를 기반으로 합니다. qcow2의 경우 가상 크기입니다. 예를 들어 20Gi를 21Gi로 바꿔야 합니다.

CLI가 호출된 방식에 따라 자리표시자 값을 바꿉니다.

  1. VirtualMachineImageImport를 찾습니다.

    kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml

    객체가 없으면 gdcloud compute images import ... 명령어를 다시 트리거합니다. 콘솔 출력이 Uploading image to ..에서 Image import has started for ...로 전환되면 Ctrl+C를 눌러 로컬 이미지가 객체 스토리지에 업로드되고 VirtualMachineImageImport가 새 이미지를 만드는 데 참고할 수 있도록 보존됩니다.

  2. 더 큰 minimumDiskSize로 새 VirtualMachineImageImport를 만듭니다.

    apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

이미지에서 디스크 프로비저닝 실패

버전: 1.13.1, 1.13.3

증상: 커스텀 이미지에서 디스크를 프로비저닝할 때 minimumDiskSize가 가상 크기에 너무 가까워 디스크 프로비저닝이 실패할 수 있습니다. VM 디스크가 대기 상태이지만 프로비저닝되지 않습니다.

해결 방법: 더 큰 spec.minimumDiskSize로 새 디스크를 수동으로 만듭니다.

클러스터에 GPU가 있는 경우 NVIDIA 기기 플러그인 DaemonSet이 실패함

버전: 1.13.3

증상: GPU가 있는 클러스터 노드에서 NVIDIA 기기 플러그인 DaemonSet이 driver rpc error 메시지와 함께 실패합니다.

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

KUBECONFIG를 클러스터의 kubeconfig 파일 경로로 바꿉니다.

다음 예와 비슷한 출력이 표시됩니다.

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

이 문제로 인해 가상 머신 (VM)과 포드에서 GPU를 사용할 수 없습니다. 영향은 다음 클러스터 유형을 기반으로 합니다.

  • 시스템 클러스터: 해당 베어메탈 노드에 GPUAllocation 커스텀 리소스가 생성되지 않으며 해당 노드의 GPU가 서비스 및 사용자 클러스터에서 사용할 수 있도록 VM 모드로 구성되지 않습니다. 이 문제를 해결하려면 시스템 클러스터 해결 방법을 참고하세요.
  • 서비스 또는 사용자 클러스터: 해당 VM 노드에 GPUAllocation 커스텀 리소스가 생성되지 않으며 해당 노드의 GPU는 클러스터의 포드에서 사용할 수 없습니다. 이 문제를 해결하려면 서비스 또는 사용자 클러스터의 해결 방법을 참고하세요.

시스템 클러스터 해결 방법:

다음 단계에 따라 시스템 클러스터의 문제를 해결하세요.

  1. 시스템 클러스터의 kubeconfig 파일 경로로 KUBECONFIG 환경 변수를 설정합니다. 자세한 내용은 IAM-R0004 런북을 참고하세요.

  2. 문제가 있는 노드를 식별합니다.

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    출력에는 노드 이름과 Kubernetes 노드의 IP 주소가 출력되어야 합니다.

    노드가 여러 개인 경우 모든 노드에서 단계를 실행합니다. 이 경우 출력은 다음 예시와 같이 표시됩니다.

    Node:                 yy-ab-bm04/172.20.128.26

  3. 노드 이름으로 NODE_NAME 환경 변수를 설정합니다. 예를 들면 다음과 같습니다.

    export NODE_NAME=yy-ab-bm04

  4. 노드와 SSH 연결을 설정합니다. 자세한 내용은 PLATAUTH-G0001 런북을 참고하세요.

  5. 노드에 GPU가 있는지 확인합니다.

    nvidia-smi -L

    출력은 다음 예와 같이 노드의 GPU를 출력해야 합니다.

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

  6. GPU에서 영구 모드를 사용 설정합니다.

    nvidia-smi -pm 1

    이 작업을 통해 NVIDIA 드라이버가 항상 로드되므로 기기 플러그인이 시간 초과되지 않습니다.

    출력은 다음 예시와 같이 표시되어야 합니다.

    Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.

  7. SSH 세션을 종료합니다.

    exit

  8. DaemonSet를 쿼리하여 기기 플러그인이 실행 중인지 확인합니다.

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. GPUAllocation 커스텀 리소스가 VM 모드에서 생성되고 구성되었는지 확인합니다.

    kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    출력은 다음 예시와 같이 표시되어야 합니다.

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

서비스 또는 사용자 클러스터의 해결 방법:

다음 단계에 따라 서비스 또는 클러스터의 문제를 해결하세요.

  1. 서비스 또는 사용자 클러스터의 kubeconfig 파일 경로로 KUBECONFIG 환경 변수를 설정합니다. 자세한 내용은 IAM-R0004 런북을 참고하세요.

  2. 문제가 있는 노드를 식별합니다.

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    출력에는 노드 이름과 Kubernetes 노드의 IP 주소가 출력되어야 합니다.

    노드가 여러 개인 경우 모든 노드에서 단계를 실행합니다. 이 경우 출력은 다음 예시와 같이 표시됩니다.

    Node:                 vm-948fa7f4/172.20.128.21

  3. 노드 이름으로 NODE_NAME 환경 변수를 설정합니다. 예를 들면 다음과 같습니다.

    export NODE_NAME=vm-948fa7f4

  4. 노드와 SSH 연결을 설정합니다. 자세한 내용은 PLATAUTH-G0001 런북을 참고하세요.

  5. 노드에 GPU가 있는지 확인합니다.

    nvidia-smi -L

    출력은 다음 예와 같이 노드의 GPU를 출력해야 합니다.

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

  6. GPU에서 영구 모드를 사용 설정합니다.

    nvidia-smi -pm 1

    이 작업을 통해 NVIDIA 드라이버가 항상 로드되므로 기기 플러그인이 시간 초과되지 않습니다.

    출력은 다음 예시와 같이 표시되어야 합니다.

    Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.

  7. SSH 세션을 종료합니다.

    exit

  8. DaemonSet를 쿼리하여 기기 플러그인이 실행 중인지 확인합니다.

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. GPUAllocation 커스텀 리소스가 VM 모드에서 생성되고 구성되었는지 확인합니다.

    kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    출력은 다음 예시와 같이 표시되어야 합니다.

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

시스템 클러스터 VM이 준비되지 않음

버전: 1.13.3

증상: 시스템 클러스터 VM이 준비되지 않았습니다. 다음과 같은 메시지가 표시될 수 있습니다.

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

해결 방법:

  1. VirtualMachineInstance을 찾아 삭제합니다.
  2. 새 VM을 다시 시작합니다.

데이터 볼륨에서 스크래치 공간을 찾을 수 없다고 보고함

버전: 1.13.3, 1.13.4

증상: VM 디스크를 만들 때 데이터 볼륨이 성공으로 보고됩니다.

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

하지만 importer-gdc-vm-disk-vm-ce34b8ea-disk와 같은 가져오기 프로그램 포드가 다음과 같은 메시지와 함께 비정상 종료 루프를 실행합니다.

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

해결 방법: 데이터 볼륨 상태가 Succeeded인지 확인한 후 가져오기 포드를 삭제합니다.

이름이 45자를 초과하는 프로젝트의 VM은 중지된 상태로 유지됩니다.

버전: 1.13.5

증상: VM을 만들 때 프로젝트 이름이 45자를 초과하면 VM이 Stopped 상태로 유지됩니다.

해결 방법: 이름이 45자(영문 기준) 이하인 프로젝트를 만듭니다.

서비스 클러스터에 GPU 할당이 누락됨

버전: 1.13.5

증상: gpu-org의 공유 서비스 클러스터에 GPUAllocation이 누락되어 있습니다. GPU 할당을 가져올 때 다음과 같은 메시지가 표시될 수 있습니다.

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

출력 형식은 다음과 같습니다.

No resources found

해결 방법:

  1. GPU 노드에 taint를 추가합니다.

    taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

  2. VM virt-launcher 포드의 예약이 허용되도록 taint를 삭제합니다.

공유 서비스 클러스터 작업자 VM을 예약할 수 없음

버전: 1.13.6

증상: 사용 가능한 GPU가 있음에도 지정된 노드의 CPU 리소스가 부족하여 Kubernetes 작업자 VM이 예약되지 않았습니다. 다음과 같은 이벤트가 표시될 수 있습니다.

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

해결 방법:

  1. CPU 리소스를 확보하려면 GPU가 아닌 VM을 수동으로 중지합니다.
  2. 대기 중인 VM이 예약되면 GPU가 아닌 VM을 시작합니다.