| 설치 |
1.9.0
1.9.1
1.9.2 |
iLO가 HSM에서 키를 가져올 수 없는 경우가 있음
증상
`server.status.conditions` 에 유형이 `KeyManagerConfigured` 이고 상태가 `True` 인 항목이 있지만 유형이 `DiskEncryptionEnabled`인 항목은 없습니다. `server-encrypt-and-create-logical-drive-$SERVER-xxxxx` 라는 포드가 오류 `"ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0`과 함께 실패합니다. 잘못된 키로 인해 포드에서 SSH를 실행할 수 없습니다.
해결 방법:
이 문제를 해결하려면 다음 단계를 따르세요.
iLO UI > 정보 > 진단 > 재설정으로 이동하여 iLO를 재설정합니다. 재설정 중에 iLO에 서버가 전원 켜기 자체 테스트 (POST) 중이라고 표시되면 프로비저닝 흐름을 다시 시작합니다.
관리자 클러스터 설치가 통과된 경우:
export KUBECONFIG=<root-admin-kubeconfig path>
SSH 키를 업데이트합니다.
현재 공개 SSH 키를 가져옵니다. 이 키는 로테이션되었을 수 있으므로 /root/.ssh/id_rsa.pub와 다를 수 있습니다.
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
공개 키를 ironic-vars configmap에 넣습니다.
kubectl -n gpc-system edit cm/ironic-vars
IRONIC_RAMDISK_SSH_KEY 추가: \ ironic을 다시 시작합니다.
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
IPA를 재설치하도록 머신을 다시 프로비저닝합니다.
bmh를 삭제하면 보안 비밀도 삭제되므로 bmc-credential-$SERVER를 백업합니다.
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
파일에서 last-applied, creationtimestamp, finalizer, ownerreference, resourceversion, uid와 같은 적용할 수 없는 속성을 삭제합니다.
BareMetalHost를 삭제합니다.
kubectl -n gpc-system delete bmh/$SERVER
cellcfg에서 비밀 bmc-credentials-$SERVER 또는 이전 백업을 가져와 적용합니다.
서버에 다른 작업을 수행하도록 지시합니다.
캐시된 BMH 상태를 삭제하려면 다음 단계를 따르세요.
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
서버가 프로비저닝될 때까지 기다립니다. BMH 객체가 생성되는 방법을 확인하세요. 다시 트리거하려면 암호화 작업을 삭제해야 할 수도 있습니다.
|
| 작업 |
1.9.0
1.9.1
1.9.2 |
증상
storageClassName이 standard-block인 경우 VM 상태는 Provisioning 또는 Starting의 STATUS로 유지됩니다.
해결 방법:
이 문제를 해결하려면 다음 단계를 따르세요.
VM STATUS에 Provisioning 또는 Starting가 표시되는지 확인합니다.
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG은 시스템 클러스터 kubeconfig 파일 경로입니다.
PROJECT은 VM이 상주하는 GDC 프로젝트입니다.
선택사항: 추가 상태 세부정보를 가져옵니다.
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME은 응답하지 않는 VM의 이름입니다.
VM을 삭제합니다.
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME은 네임스페이스 이름입니다.
삭제가 완료되었는지 확인합니다.
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
다음과 유사한 결과가 표시되면 성공한 것입니다.
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
해당 VM의 디스크를 모두 삭제합니다.
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME DISK_NAME_1 및 DISK_NAME_2~DISK_NAME_N을 각 디스크의 이름으로 대체하고 모든 디스크가 나열되어 있는지 확인합니다.
삭제가 완료되었는지 확인합니다.
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
다음과 유사한 결과가 표시되면 성공한 것입니다.
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_1" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_2" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_N" not found
VM과 디스크를 다시 만듭니다.
VM을 다시 시작합니다.
|
| 작업 |
1.9.2 |
증상
오류로 인해 gdcloud system container-registry load-oci개가 실패했습니다. 명령어를 다시 실행하면 서로 다른 기간 동안 실행되고 푸시 또는 리태그와 같은 프로세스의 서로 다른 지점에서 실패하지만 오류는 유사합니다.
해결 방법:
이 문제를 해결하려면 다음 단계를 따르세요.
KUBECONFIG를 루트 관리자 kubeconfig로 내보냅니다.
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- 다음 명령어를 실행하여
deployment/root-admin-tftp-manager-controller을 복제본 0개로 축소합니다.
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- 실패한 작업을 실행합니다.
deployment/root-admin-tftp-manager-controller를 1개 복제본으로 확장합니다.
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| 작업 |
1.9.1
1.9.2
1.9.3 |
증상
오류로 인해 gdcloud system container-registry load-oci개가 실패했습니다. 명령어를 다시 실행하면 서로 다른 기간 동안 실행되고 푸시 또는 리태그와 같은 프로세스의 서로 다른 지점에서 실패하지만 오류는 유사합니다.
해결 방법:
메시지를 무시해도 됩니다. 잠시 후 사라집니다.
|
| 작업 |
1.9.2 |
해결 방법:
이 문제를 해결하려면 문제가 있는 포드를 다시 시작하세요.
|
| 작업 |
1.9.0
1.9.1
1.9.2 |
증상
서버 준비 상태의 상태가 'False'이고 메시지에 'job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...'가 포함됩니다. 실패한 작업의 로그에는 'Failed to connect to the host via ssh ... Permission denied (publickey).'가 포함됩니다.
해결 방법:
이 문제를 해결하려면 다음 단계를 따르세요.
루트 관리자 클러스터에서 현재 공개 SSH 키를 가져옵니다.
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d키를 ironic-vars configmap에 배치합니다.
kubectl -n gpc-system edit cm/ironic-vars 기존 IRONIC_RAMDISK_SSH_KEY를 추가하거나 바꿉니다.
<SSH public key>
ironic 배포를 다시 시작합니다.
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic 영향을 받는 각 서버의 경우 다음을 수행합니다.
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| 작업 |
1.9.2 |
해결 방법:
IP 주소 부족 문제가 발생하지 않도록 하려면 고가용성 사용자 클러스터를 만들 때 포드 CIDR 크기를 /21 이상으로 설정하세요.
|
| 설치 |
1.9.2 |
해결 방법:
이 문제를 해결하려면 포드를 다시 시작하세요.
자세한 내용은 MON-R0001 런북을 참고하세요.
|
| 플랫폼 인증 |
1.9.13 |
증상
모든 cplb-init 및 storage-ipsec-config-bm-XXXXX 작업에 Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out 메시지가 표시됩니다.
해결 방법:
1. aggswitch에서 bgp vrf가 다운되었는지 확인합니다.
2. 방화벽에 커밋되지 않은 새 스테이징 구성이 있는지 확인합니다.
3. 이름에 삭제된 조직이 있는 모든 securitypolicyrules를 정리하고 루트 관리자 컨트롤러를 다시 시작합니다.
|
| 업그레이드 |
1.9.1
1.9.2
1.9.11 |
증상
Server의 .status.bareMetalHostStatus.provisionState이 20분 넘게 deprovisioning에 멈춰 있습니다.
업그레이드되는 서버의 관리 IP 주소는 다음 명령어의 출력에 포함됩니다.
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,option:tftp-server
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,tag:ipxe,option:bootfile-name
해결 방법:
이 문제를 해결하려면 다음을 실행하세요.
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| 업그레이드 |
1.9.1
1.9.2
1.9.10
1.9.11
1.9.12
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18 |
증상
NodeUpgrade의 업그레이드 작업 하나가 2시간 넘게 완료되지 않았습니다.
해당 NodeUpgradeTask가 NodeResumeCompleted 조건에서 멈추고 1시간 넘게 완료되지 않습니다.
bm-system-x.x.x.x-machine-init 작업이 오랫동안 완료되지 않은 상태로 유지됩니다. x.x.x.x은 노드의 주소입니다.
해결 방법:
비정상 노드 주소를 찾으려면 중단된 bm-system-x.x.x.x-machine-init 작업의 x.x.x.x를 확인하세요.
비정상 노드의 정상 제어 영역 노드를 찾으려면 다음 단계를 따르세요.
- 비정상 노드의 노드 풀을 찾습니다.
비정상 노드의 동일한 클러스터에서 컨트롤 플레인 노드 풀을 확인하고 해당 컨트롤 플레인 노드 풀의 .spec.address에서 주소를 선택합니다.
부트스트래퍼 또는 OC IT에서 다음을 실행합니다.
HEALTHY_CP_NODE_IP=Y.Y.Y.Y # Needs to be entered.
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
HARBOR=$(ka get harborcluster harbor -n harbor-system -o=jsonpath="{.spec.externalURL}")
REGISTRY=${HARBOR#https://}
# Download `etcdctl`.
docker run --rm -v $(pwd):/workspace --workdir /workspace ${REGISTRY}/library/anthos-baremetal-release/etcd:v3.4.21-0-gke.1 /bin/sh -c "cp /usr/local/bin/etcdctl /workspace/etcdctl"
scp etcdctl "root@$HEALTHY_CP_NODE_IP:/root/etcdctl"
# SSH into the healthy control plane node.
ssh $HEALTHY_CP_NODE_IP
정상적인 컨트롤 플레인 노드 내에서 다음을 실행합니다.
UNHEALTHY_NODE_IP=X.X.X.X # Needs to be entered.
UNHEALTHY_MEMBER=$(ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member list | grep $UNHEALTHY_NODE_IP | cut -d',' -f1)
ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member remove $UNHEALTHY_MEMBER
|
| 업그레이드 |
1.9.1
1.9.2 |
증상
ODS Fleet Operator 포드가 비정상 종료를 반복합니다.
포드 상태를 확인하려면 다음을 실행합니다.
ko get pods -n ods-fleet-operator
ODS Fleet Operator 로그에 다음과 유사한 리더 선택 오류가 표시됩니다.
E0413 18:06:48.614127 1 leaderelection.go:330] error retrieving resource lock ods-fleet-system/af0cf209.dbadmin.gdc.goog: Get "https://172.20.0.1:443/apis/coordination.k8s.io/v1/namespaces/ods-fleet-system/leases/af0cf209.dbadmin.gdc.goog": context deadline exceeded
I0413 18:06:48.614214 1 leaderelection.go:283] failed to renew lease ods-fleet-system/af0cf209.dbadmin.gdc.goog: timed out waiting for the condition
E0413 18:06:48.614460 1 main.go:473] "setup: problem running manager" err="leader election lost" log_name="l1_controller"
ODS Fleet Operator 로그를 확인하려면 다음을 실행합니다.
ko logs deployment/fleet-controller-manager -n ods-fleet-system
다음 메시지가 표시됩니다.
Message: Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgrade error: post-upgrade hooks failed: timed out waiting for the condition: timed out waiting for the condition개
해결 방법:
배포를 수정하려면 다음을 실행합니다.
ko edit deployment -n ods-fleet-system fleet-controller-manager
ku edit deployment oracle-controller-manager -n ods-oracle-system
ku edit deployment pg-controller-manager -n ods-postgres-system
manager 컨테이너의 resources 필드를 다음과 같이 수정해야 합니다.
최적화 전
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
최적화 후
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| 업그레이드 |
1.9.2
1.9.3 |
증상
다음 오류 메시지가 표시됩니다.
nvidia-driver-init run the action: init, with options: skip_driver
nvidia-driver-init Find the nvidia card, label this node
nvidia-driver-init node/MACHINE_NAME not labeled
nvidia-driver-init enable nvidia container runtime for ubuntu/debian system
nvidia-driver-init install nvidia container runtime package
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container1_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container1:amd64 (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container1:amd64 (1.12.0-1) ...
nvidia-driver-init Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container-tools_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container-tools (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container-tools (1.12.0-1) ...
nvidia-driver-init dpkg: regarding .../nvidia-container-toolkit-base_1.12.0-1_amd64.deb containing nvidia-container-toolkit-base:
nvidia-driver-init nvidia-container-toolkit-base breaks nvidia-container-toolkit (<= 1.10.0-1)
nvidia-driver-init nvidia-container-toolkit (version 1.8.1-1) is present and installed.
nvidia-driver-init dpkg: error processing archive var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb (--install):
nvidia-driver-init installing nvidia-container-toolkit-base would break nvidia-container-toolkit, and
nvidia-driver-init deconfiguration is not permitted (--auto-deconfigure might help)
nvidia-driver-init Errors were encountered while processing:
nvidia-driver-init var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb
해결 방법:
이 문제를 해결하려면 다음 단계를 따르세요.
프로비저닝된 모든 GPU 노드에 로그인합니다.
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
오래된 패키지를 삭제합니다.
root@MACHINE_NAME:~# dpkg -r nvidia-container-runtime nvidia-container-toolkit
(Reading database ... 92154 files and directories currently installed.)
Removing nvidia-container-runtime (3.8.1-1) ...
Removing nvidia-container-toolkit (1.8.1-1) ...
고정된 kubevm-gpu-driver-daemonset 포드를 삭제합니다. 이렇게 하면 설치가 다시 시작됩니다.
# kug get pods -A | grep gpu | grep Init
(선택사항) 부가기능 설치 시간이 초과된 경우 부가기능 설치를 다시 시작합니다.
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| 업그레이드 |
1.9.10
1.9.11 |
증상
gpcbackup-agent-0에 failed to stage volume: iSCSI login failed이 표시되고 볼륨을 스테이징하지 못합니다.
포드가 볼륨을 연결하지 못하는지 확인합니다. 다음 예에서는 시스템 클러스터 kubeconfig를 사용합니다.
-
포드를 설명합니다.
kos describe pod -n gpc-backup-system gpcbackup-agent-0
포드가 실패하면 다음 예와 비슷한 출력이 표시됩니다.
Warning FailedMount 24m (x1064 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[kube-api-access-cr45d gpcbackup-agent-vol]: timed out waiting for the condition
Warning FailedMount 9m18s (x4109 over 7d17h) kubelet MountVolume.MountDevice failed for volume "pvc-5df41864-63c5-4589-9569-036fa011f64c" : rpc error: code = Internal desc = failed to stage volume: iSCSI login failed
Warning FailedMount 4m32s (x3840 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[gpcbackup-agent-vol kube-api-access-cr45d]: timed out waiting for the condition
-
포드가 실패한 노드를 확인합니다.
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
다음 예와 비슷한 출력이 표시됩니다.
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none]
-
gpcbackup-agent-0 포드가 실패한 동일한 노드에서 netapp-trident 포드를 가져옵니다.
kos get pod -o wide -n netapp-trident
다음 예와 비슷한 출력이 표시됩니다.
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
gpcbackup-agent-0 포드가 실패한 동일한 노드에서 netapp-trident 포드의 로그를 확인합니다.
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
다음 예와 비슷한 출력이 표시됩니다.
time="2024-01-25T17:35:29Z" level=error msg="Failed to discover targets" error="process killed after timeout" output= portal="172.20.131.41:3260" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
time="2024-01-25T17:35:29Z" level=error msg="unable to ensure iSCSI target exists: failed to discover targets: process killed after timeout" err="failed to discover targets: process killed after timeout" iface=default requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI targetIqn="iqn.1992-08.com.netapp:sn.944e1654ac1c11ee86b0d039ea524d51:vs.26" tp="172.20.131.41:3260"
time="2024-01-25T17:35:29Z" level=error msg="GRPC error: rpc error: code = Internal desc = failed to stage volume: iSCSI login failed" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
해결 방법:
이 문제를 해결하려면 다음 단계를 수행하세요.
-
InventoryMachine 이름을 가져옵니다.
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
이전 작업이 있는지 확인합니다.
export ORG_ADMIN_KUBECONFIG=[path to the org admin kubeconfig]
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-"${INV_MACH}"
다음과 비슷한 출력이 표시됩니다.
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
작업 삭제:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
다음과 비슷한 출력이 표시됩니다.
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
StorageEncryptionConnection가 있는지 확인합니다.
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
다음과 비슷한 출력이 표시됩니다.
NAME INVENTORYMACHINE STORAGEVIRTUALMACHINE STORAGECIDR PRESHAREDKEY READY AGE
vm-e2b9792a vm-e2b9792a org-1-user 172.20.131.32/27 vm-e2b9792a-pre-shared-key True 19d
-
StorageEncryptionConnection을 삭제합니다.
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
다음과 비슷한 출력이 표시됩니다.
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
root-admin-controller 포드를 다시 시작합니다.
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout restart deploy -n gpc-system root-admin-controller && kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout status deploy -n gpc-system root-admin-controller
-
새 작업이 다시 생성되고 성공적으로 실행되었는지 확인합니다.
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
다음과 비슷한 출력이 표시됩니다.
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| 업그레이드 |
1.9.10
1.9.11 |
증상
Harbor 레지스트리 포드에 다음과 유사한 오류 메시지가 표시됩니다.
Warning FailedMount 6m52s (x718 over 2d14h) kubelet Unable to attach or mount volumes: unmounted volumes=[storage], unattached volumes=[registry-config authentication-htpasswd internal-certificates sto │
│ age[]: timed out waiting for the condition
해결 방법:
이 문제를 해결하려면 다음 단계를 따르세요.
-
Harbor 레지스트리의 영구 볼륨 클레임 (PVC)을 확인하고 PVC 볼륨 이름을 기록합니다.
kubectl get pvc harbor-registry -n harbor-system
-
볼륨 연결이 Harbor 레지스트리 포드와 동일한 노드에 있는지 확인하려면 volumeattachment을 나열하고 볼륨 이름과 연결된 항목을 찾습니다.
kubectl get volumeattachment | grep [volume-name]
-
볼륨 연결이 Harbor 레지스트리 포드와 다른 노드에 있는 경우 volumeattachment를 삭제합니다.
kubectl delete volumeattachment [volumeattachment-name]
-
Harbor 레지스트리 포드를 다시 시작합니다.
이제 루트 관리자 클러스터의 Harbor 레지스트리가 정상이어야 하며 노드 업그레이드가 성공적으로 완료됩니다.
|
| 설치 |
1.9.2
1.9.3
1.9.4
1.9.5
|
증상
다음 오류 메시지가 표시됩니다.
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
포드 로그에는 다음이 포함됩니다.
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
CoreDNS 버전은 1.8.6입니다.
해결 방법:
이 문제를 해결하려면 coredns 배포를 다시 시작하세요.
올바른 클러스터에 KUBECONFIG가 설정되면 다음을 실행합니다.
kubectl rollout restart deployment coredns -n kube-system
사용자 클러스터 이름은 오류 메시지에 포함됩니다.
/root/release/user/에서 kubeconfig 파일을 찾으려면 kubeconfigs를 찾습니다. org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
kubeconfig 파일이 누락된 경우 다음과 같이 생성합니다.
export KUBECONFIG=/root/release/org-admin/org-1-admin-kubeconfig
kubectl get secrets -n user-vm-1-cluster user-vm-1-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/user-vm-1-user-kubeconfig
|
| 업그레이드 |
1.9.2
1.9.3 |
증상
다음 오류 메시지가 표시됩니다.
Warning ReconcileBackoff 43m (x9 over 61m) OrganizationUpgrade [UPG1402: unable to set AddOn selector labels for root-admin cluster: Operation cannot be fulfilled on clusters.baremetal.cluster.gke.io "root-admin": the object has been modified; please apply your changes to the latest version and try again, UPG9900: unable to update status: OrganizationUpgrade.upgrade.private.gdc.goog "root" is invalid: [status.errorStatus.errors[0]. errorResource.name: Required value, status.errorStatus.errors[0].errorResource.namespace: Required value]]
이 문제는 일반적으로 일시적이며 해결됩니다.
|
| 설치 |
1.9.3 |
다음 오류와 함께 부가기능 설치가 실패합니다.
Error occurred during addon installation: failed to install chart: release netapp-trident failed, and has been uninstalled due to atomic being set: failed post-install: timed out waiting for the condition개
해결 방법:
노드가 NotReady 상태에 있어 부가기능 설치가 실패할 수 있습니다. 다음을 사용하여 노드가 NotReady 상태인지 확인합니다.
kubectl get nodes
NotReady 상태인 노드의 세부정보를 가져옵니다.
$ kubectl describe node | grep PodCIDRs
이 문제가 있는 클러스터에서는 노드에 PodCIDR이 할당되지 않습니다. 예를 들면 다음과 같습니다.
PodCIDRs:
For a healthy cluster, all the nodes should have PodCIDRs assigned to it(CIDR shown here is for example purposes only and might vary on the actual cluster based in the Configured ClusterCIDR): eg.
PodCIDRs: 192.168.6.0/24
이 문제를 해결하려면 영향을 받는 클러스터에서 ipam-controller 배포를 다시 시작하세요.
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| 업그레이드 |
1.9.3 |
다음 오류와 함께 업그레이드가 실패합니다.
Rollback "netapp-trident" failed: cannot patch "netapp-trident-csi-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp 172.20.5.144:443: i/o timeout && cannot patch "netapp-trident-server-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-client-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-selfsigned-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded개
해결 방법:
클러스터가 업그레이드되는 것과 동일한 네임스페이스에서 원하는 버전의 AddOnSetTemplate 이름으로 AddOnSet abm-overrides 필드 <code.spec.addonsettemplateref< code="" dir="ltr" translate="no">를 수동으로 업데이트합니다.</code.spec.addonsettemplateref<>
|
| 설치 |
1.9.3 |
증상
TestCreateFleetAdminCluster 또는 TestSimOverlayCreateFleetAdminCluster 테스트에 실패하여 함대 관리자 컨트롤러가 준비되지 않습니다. 자동차 관리자 컨트롤러가 비정상 종료 루프에 갇혀 있습니다. 다음 오류가 플릿 관리자 컨트롤러의 로그에 있습니다. Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced
해결 방법:
Logmon CRD를 조직 관리자 클러스터에 배포합니다.
Fleet 관리자 컨트롤러를 다시 시작합니다.
|
| 설치 |
1.9.3 |
증상
다음 오류 메시지가 표시됩니다.
k8s_mt_system_cluster_healthcheck_test.go:147: system cluster did not become ready in time: cluster "org-1-system-cluster/org-1-system" did not become healthy in time: [waitingForClusterHealth] WaitForSuccess gave up [...] unable to retrieve logs for pod "anthos-prometheus-k8s-0" [...] pod "anthos-prometheus-k8s-0" in namespace "obs-system" is not ready yet. [...] Message:containers with unready status: [config-reload prometheus-server] [...]
해결 방법:
이 문제를 해결하려면 클러스터에서 배포와 데몬 세트를 모두 다시 시작하세요.
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
참고: 배포 및 DaemonSet를 다시 시작하기 전에 다음 명령어를 실행하여 올바른 클러스터를 가리킵니다.
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| 업그레이드 |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
증상
CPU가 부족하여 포드를 예약할 수 없습니다.
해결 방법:
n2-standard-4 워커 노드로 생성된 기존 사용자 클러스터의 경우 업그레이드하기 전에 노드가 3개인 새 n2-standard-8 NodePool을 이 클러스터에 추가합니다.
새 사용자 클러스터의 경우 노드가 최소 3개인 n2-standard-8 NodePool 하나로 만듭니다. 자세한 내용은 컨테이너 워크로드용 사용자 클러스터 만들기를 참고하세요.
|
| 작업 |
1.9.0
1.9.2
1.9.3
1.9.4 |
증상
VM 인스턴스 PHASE가 Scheduling로 표시되고 READY는 False 상태로 유지되어 True 상태에 도달하지 않습니다. 이 문제는 해결 방법으로 나열된 두 가지 머신 유형에 영향을 미칩니다. 다른 머신 유형은 영향을 받지 않으며 해결 방법을 적용할 필요가 없습니다.
해결 방법:
- A100 40G GPU를 사용하는 사용자 클러스터를 만들 때는 항상 UI에서 a2-highgpu-1g-gdc 머신 유형을 선택하세요.
- A100 80G GPU를 사용하는 사용자 클러스터를 만들 때는 항상 UI에서 a2-ultragpu-1g-gdc 머신 유형을 선택하세요.
|
| 작업 |
1.9.0
1.9.2
1.9.3
1.9.4 |
증상
메모리 크기가 32GB보다 큰 VM 인스턴스가 있는 노드 풀의 경우 VM 인스턴스가 실행된 후 중지되고 다시 실행되는 것처럼 보일 수 있으며 이 시퀀스가 반복될 수 있습니다. 결국 메모리 부족 OOMKilled 오류가 발생하고 인스턴스가 실패합니다.
영향을 받는 세 가지 VM 유형은 다음과 같습니다.
- n2-highmem-8-gdc: 64GB 메모리
- a2-highgpu-1g-gdc: 85GB 메모리
- a2-ultragpu-1g-gdc: 메모리 170GB
해결 방법:
- 머신 유형을 확인합니다.
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- 다음에서 VM 유형을 찾습니다. 출력에
spec.compute.virtualMachineTypeName 이 포함되어 있습니다.
- VM 유형이 나열된 세 가지 유형 중 하나인 경우
configmap를 수정하여 메모리 재정의를 포함합니다.
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- 다음 예와 같이
memory.guest 및 resources.overcommitGuestOverhead 섹션을 추가합니다.
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
memory에서 guest이 다음 값을 갖도록 변경합니다.
- n2-highmem-8-gdc의 경우 MEMORY_SIZE
63.6G을 만듭니다.
- a2-highgpu-1g-gdc의 경우 MEMORY_SIZE
84G를 만듭니다.
- a2-ultragpu-1g-gdc의 경우 MEMORY_SIZE
168G를 만듭니다.
- 영향을 받는 모든 VM에 대해 이 단계를 반복합니다.
|
| 업그레이드 |
1.9.4 |
증상
bm-system-* 작업이 Gathering Facts 단계에서 멈춥니다. 서버에 수동으로 SSH를 시도하면 PTY allocation request failed on channel 0가 표시됩니다.
해결 방법:
다음 중 하나를 사용하여 서버를 재부팅합니다.
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
iLO UI kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| 업그레이드 |
1.9.4
1.9.10 |
증상
backup-ipsec-* 작업이 실패하여 업그레이드가 실패합니다.
해결 방법:
다음 단계를 따르세요.
조직 관리자 클러스터의 gpc-system 네임스페이스에서 사전 공유 키를 찾습니다. 키 이름은 <node-name>-pre-shared-key입니다.
작동 노드의 사전 공유 키 yaml에서 키 해시를 가져오려면 kubectl get --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig -n gpc-system secret <not-failed-node-name>-pre-shared-key -o=jsonpath='{.data.pre-shared-key}' | awk '{ print $1 }'를 사용합니다.
ipsec 업그레이드가 실패한 노드가 아닌 다른 노드에서 키 해시를 가져와야 합니다. 이 사전 공유 키의 해시를 조직 관리자 클러스터의 gpc-system에 있는 실패한 노드의 사전 공유 키 보안 비밀에 적용합니다. 루트 관리자 클러스터에서 실패한 노드와 이름이 같은 storageencryptionconnection 객체를 삭제합니다. 조직 관리자 클러스터에서 연결된 storage-ipsec-config-<node-name> 작업을 삭제합니다. 연결된 backup-ipsec-for-upgrade-<node-name> 업그레이드 작업을 삭제합니다.
|
| 업그레이드 |
1.9.4 |
증상
조직 클러스터 업그레이드에 시간이 오래 걸립니다.
해결 방법:
clamav가 자연스럽게 종료될 때까지 기다립니다.
|
| 업그레이드 |
1.9.5 |
증상
다른 인증서가 표시됩니다.
echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBqjCCAS+gAwIBAgIQSve6hYhac9nZr/u/l/hPzjAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTcwMzQ3MjhaFw0yODA3MTUwMzQ3
MjhaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MHYwEAYHKoZIzj0CAQYFK4EEACID
YgAEsGCynvjnSNNIdz3PxpEqvogHAITWyB3jJbA6jxQhics5MYuq2biaqLg38Ly1
3mF6CRh9Tzroxg2Wtu339McKTAC/7v61ZsbGXbj3eQiTECJut/a55BekG7FcwVG/
btbAo0IwQDAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQUUh1ZUS9CUIHgQmJZTj8m3MIINS8wCgYIKoZIzj0EAwMDaQAwZgIxALDea5fh
IeafRNzR3pjYRgW++TCYZU3XVSJ04K8eIBy1wz1XRDR5SWFgJ/ejWZGUagIxAIQP
9A42lzd7gyqaAAlRB+TQ0sMJMOOyNl0gFg5ZVyhGdJfsZpv1XrcLcqX3tejydw==
-----END CERTIFICATE-----
echo $(kubectl get secret ca-cert-10.2.2.101.10443 -n anthos-creds -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBazCCARKgAwIBAgIQKkDVSpMZf9CQEHxx7UFPmDAKBggqhkjOPQQDAjAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTYwOTQzMTlaFw0yNDA3MTUwOTQz
MTlaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEI4hXIh65Zc8sWaPQL9gqz3lrq22A1XJsRrMwl/pk3vZiNLGS3+Tt9tXc
WDP74IbinOxZ1Auw08e3s4sxCahfyqNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1Ud
EwEB/wQFMAMBAf8wHQYDVR0OBBYEFN8ob6e8WeFELnVKPSdtMfyvRP95MAoGCCqG
SM49BAMCA0cAMEQCIF8P5THYBHcOdcn1u7zi+Y4jwDTdLAeaDZbVxUDEK2EaAiBW
zilvR3YvW7h5OdSUsgFkSQ42FcSIoNHWYNSZx16CeQ==
-----END CERTIFICATE-----
해결 방법:
참고: 다음 단계를 수행하기 전에 harbor-harbor-https 인증서를 순환하세요.
다음 단계를 따르세요.
클러스터 내 보안 비밀에 저장된 인증서 데이터의 사본이 있습니다. harbor-harbor-https 인증서를 순환한 후에는 보안 비밀 사본도 업데이트해야 합니다.
- Artifact Registry URL을 가져옵니다.
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- 각 네임스페이스에서 Artifact Registry 인증서 보안 비밀 사본을 업데이트합니다.
Artifact Registry 인증서 보안 비밀 사본을 저장하는 모든 네임스페이스를 가져옵니다.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
각 네임스페이스에서 Artifact Registry 인증서 보안 비밀 사본을 업데이트합니다.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done
- 루트 관리자 클러스터의 경우
anthos-creds 네임스페이스에서 ca-cert-in-cluster-registry라는 인증서 보안 비밀 복사본이라는 수정사항도 업데이트해야 합니다.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n anthos-creds patch secret/ca-cert-in-cluster-registry -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"
kube-system 네임스페이스에 저장된 registry-cert를 업데이트합니다.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n kube-system patch secret/registry-cert -p "{\"data\":{\"registry-cert\":\"${cert_data}\"}}"
- 조직 관리자 클러스터의 인증서를 순환하는 경우 루트 관리자 클러스터에 있는 인증서 보안 비밀 사본도 업데이트해야 합니다.
Artifact Registry 인증서 보안 비밀 사본을 저장하는 모든 네임스페이스를 가져옵니다.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
각 네임스페이스에서 Artifact Registry 인증서 보안 비밀 사본을 업데이트합니다.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done .
|
| 업그레이드 |
1.10.0
1.10.1 |
증상
OrganizationUpgrade를 시작한 후 하나 이상의 노드에서 kube-apiserver 포드가 실행되지 않습니다.
- 업그레이드가 차단된 노드를 식별합니다.
kubectl get po -n kube-system -l component=kube-apiserver
출력 형식은 다음과 같습니다.
NAME READY STATUS RESTARTS AGE
kube-apiserver-ah-aa-bm01 1/1 Running 0 12h
kube-apiserver-ah-ab-bm01 1/1 Running 0 11h
kube-apiserver-ah-ac-bm01 1/1 Error 0 12h
- 방금 업데이트된 노드에 SSH 연결을 설정합니다.
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
컨테이너 상태가 Exited로 표시됩니다.
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
Exited 포드의 로그를 확인합니다.
crictl logs f1771b8aad929
출력 형식은 다음과 같습니다.
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
플래그는 /etc/kubernetes/manifests/kube-apiserver.yaml 파일에서 구성됩니다.
root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
해결 방법:
/etc/kubernetes/manifests/kube-apiserver.yaml 파일에서 플래그를 삭제합니다.
- 파일을 백업합니다.
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- 다음 줄을 삭제합니다.
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- 라인이 삭제되었는지 확인합니다.
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
kube-apiserver 컨테이너를 나열합니다.
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet가 변경사항을 자동으로 선택하고 kube-apiserver 포드를 시작합니다.
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- 영향을 받는 모든 노드에 대해 이 단계를 반복합니다.
|
| 업그레이드 |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
증상
인증서 순환 후 조직에서 kube-state-metrics 배포가 비정상 종료 루프를 실행합니다. 이 문제로 인해 모니터링 데이터가 손실될 수 있습니다.
|
| 업그레이드 |
1.9.6 |
증상
업그레이드 후 워커 노드가 불균형합니다.
해결 방법:
워커 노드를 수동으로 균형 조정합니다.
- 포드 워크로드의 경우 배포에서 포드를 삭제합니다.
- VM 워크로드의 경우 제어 영역 GVM 객체를 수정하지 않고 virt-launcher를 삭제합니다.
|
| 업그레이드 |
1.9.6 |
1.9.5에서 1.9.6으로 업그레이드할 때 GPU 기기 플러그인이 시작되지 않을 수 있습니다.
증상
VM 런타임 준비 및 업그레이드 프로세스를 차단하는 다음 오류가 표시될 수 있습니다.
Failed to initialize NVML: could not load NVML library
해결 방법:
- 노드에서
nvidia-container-runtime이 올바르게 구성되었는지 확인합니다.
- 문제가 있는 것으로 의심되는 노드에 SSH 연결을 설정합니다.
- 포드 목록을 가져옵니다.
crictl pods
- 포드를 검사합니다.
crictl inspectp $pod_hash | grep runtimeOption -A1
출력이 다음과 같이 표시되면 노드가 올바르게 구성된 것입니다. 출력이 다음과 같지 않으면 nvidia-container-runtime가 노드에 구성되지 않은 것입니다.
binary_name": "/usr/bin/nvidia-container-runtime"
nvidia-container-runtime가 올바르게 구성되지 않은 경우 containerd를 다시 시작하여 문제를 해결합니다.
systemctl restart containerd
|
| 업그레이드 |
1.9.7 |
1.9.7로 업그레이드할 때 루트 관리자 클러스터 노드 풀 펌웨어가 in process 상태로 유지됩니다.
증상
NodeUpgrade 측면에서는 아티팩트 서버 시간 초과 해결 방법을 참고하세요.
NodeUpgrade가 in process 상태로 멈추고 Nodeupgradetask 상태의 NodeROMFirmwareUpgradeCompleted 조건이 항상 완료되지 않습니다.NodeUpgrade 객체의 spec.firmware.firmwarePackages.url에 있는 URL은 다음과 같은 항목에 연결될 때 중단될 수 있습니다.
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
Harbor 측면의 경우 아티팩트 서버 승인되지 않음 해결 방법을 참고하세요.
- 아티팩트 서버 로그에 저장소에 대한 무단 액세스와 관련된 오류가 표시될 수 있습니다(예:
gdch-hpe-firmware/ilo).
root@bootstrapper:~# kubectl --kubeconfig ${KUBECONFIG} logs -n gpc-system -l name=artifact-registry-services-artifact-server -f
artifact-server I1108 05:20:28.084320 1 artifact_server.go:171] Pulling artifact at path /artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU=
artifact-server E1108 05:20:28.159685 1 artifact_server.go:194] Error fetching image 10.249.23.11:10443/gdch-hpe-firmware/ilo:ilo5: GET https://10.249.23.11:10443/v2/gdch-hpe-firmware/ilo/manifests/ilo5: UNAUTHORIZED: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull
- Harbor 프로젝트에서
gdch-hpe-firmware은 private로 Spec.harborProjectConfig.accessLevel을 가져야 합니다.
kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
해결 방법:
|
| 하위 네트워킹 |
1.9.0~1.9.6 |
증상
조직의 내부 네트워크에서 BGP 세션이 다운되었습니다. 조직의 내부 BGP 피어링 엔드포인트 중 하나만 TORSwitchInternal 객체에 추가됩니다.
해결 방법:
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim에서 사용되는 서브넷이 다른 조직의 유사한 AddressPoolClaim 리소스와 겹치지 않도록 명시적으로 변경합니다.
- 증상 조사:
- 각 조직 시스템 클러스터에 대해 다음을 실행합니다.
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- 각
BGPSession 객체의 State 필드에서 NotEstablished의 State을 확인합니다. 나중에 사용할 수 있도록 연결된 각 NotEstablished BGPSession의 LocalIP를 기록해 둡니다.
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs"이 근본 원인인지 확인합니다.
- 활성 조직마다 다음을 실행합니다.
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- 출력의
ClusterIP 필드 (세 번째 열)에서 1.b단계에서 확인한 LocalIPs을 검색합니다. 나중에 사용할 수 있도록 출력의 세 번째 열에 있는 항목과 일치하는 LocalIP를 기록해 둡니다. 2.a의 출력에 1.b단계에 설명된 LocalIP가 포함된 여러 개의 개별 조직 관리자 클러스터가 있는 경우 3단계로 진행합니다.
- 조직 시스템 클러스터에 사용되는 중복 IP 해결
- 실행:
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- 3.a의 쿼리에서 반환된
SubnetClaim 객체 수를 기록합니다. 활성 조직 수와 같아야 합니다.
- 각 행에 대해 네임스페이스 (열 1)와 CIDR 블록 (열 3)을 기록합니다. 각 행의 CIDR 블록은 다른 모든 행의 CIDR 블록과 동일해야 합니다.
- 각 조직에 대해 다음 단계를 실행합니다.
- 해당 조직의 조직 관리자 클러스터에서
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim 객체로 이동합니다.
- 해당 조직의 워커 노드 주소 풀 클레임의
Start IP을 계산합니다. 이렇게 하려면 3.c의 CIDR 블록과 3.d.i의 AddressPoolClaim에 있는 Size 필드를 사용합니다. CIDR 블록의 마지막에서 두 번째 IP부터 Size IP를 카운트다운합니다. 첫 번째 조직의 새 Start IP입니다 (3.d.iii 단계에서 사용됨). 추가 조직마다 이전 조직의 새 Start IP부터 시작하여 Size IP를 카운트다운합니다.
예를 들면 다음과 같습니다.
CIDR block: 10.0.0.0/24
org-1, org-2, & org-3 AddressPoolClaim Size: 2
- New org-1 startIPAddress: 10.0.0.252
- New org-2 startIPAddress: 10.0.0.250
- New org-3 startIPAddress: 10.0.0.248
- 3.c.i 단계의
AddressPoolClaim에서 Spec 필드에 다음 필드를 추가합니다.
staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
다음 명령어를 사용합니다.
`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
예를 들어 3.d.ii에서 org-1를 사용하는 경우 결과는 다음과 같이 표시되어야 합니다.
apiVersion: system.private.gdc.goog/v1alpha1
kind: AddressPoolClaim
metadata:
name: org-1-system-bgp-flat-ip-ipv4-apc
namespace: org-1-system-cluster
...
spec:
category: InternalOverlayNetwork
...
parentReference:
name: worker-node-network-subnet
type: SubnetClaim
size: 2
staticIPRanges:
- startIPAddress: 10.0.0.252
size: 2
status:
allocatedIPRanges: ...
...
- TORSwitch 하드웨어에서 불필요한 BGP 세션을 방지하기 위해 정리합니다.
- 업데이트해야 하는 모든
TORSwitchInternal 리소스를 나열하려면 다음을 실행합니다.
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- 이전 명령어의 출력에 나열된 각
TORSwitchInternals에 대해 다음 명령어를 실행합니다.
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- 모든
TORSwitchInternal 객체에 대해 2.b단계의 LocalIP 중 하나와 동일한 NeighborIP이 있는 .spec.ebgpNeighbors 목록에서 모든 항목을 삭제합니다. 예를 들어 2.b단계에서 2.2.2.2의 LocalIP가 확인되었습니다. 다음은 정리 단계 전후의 TORSwitchInternal 예시입니다.
정리 전:
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
- md5SecretReference: {}
neighborIP: 2.2.2.2
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
정리 후 삭제된 ebgpNeighbor 항목을 확인합니다.
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- 1단계를 실행하고 모든
BGPSession 객체 States이 Established로 돌아갔는지 확인하여 검증합니다. 모든 수정사항이 실제 GDC TORSwitch 구성에 전파되는 데 약 10분 정도 걸릴 수 있습니다.
|
| 업그레이드 |
1.9.7~1.9.21 |
업그레이드 중에 노드 및 운영체제 업그레이드가 진행되지 않을 수 있습니다.
증상
Ready, SchedulingDisabled 상태의 노드가 몇 시간 동안 표시될 수 있습니다.
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG get no
NAME STATUS ROLES AGE VERSION
aa-bm01 Ready, SchedulingDisabled control-plane 52d v1.27.4-gke.500
ab-bm01 Ready control-plane 52d v1.27.4-gke.500
ac-bm01 Ready control-plane 52d v1.27.4-gke.500
해결 방법:
- 런북 PLATAUTH-SSH 0001에 따라 문제가 되는 노드의 SSH 키를 가져옵니다. SSH를 사용하여 노드에 연결한 후 다음 명령어를 실행합니다.
multipath -ll | grep fail
- 출력이 다음과 유사한 경우에만 다음 단계로 진행하세요.
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 7:0:0:7 sdad 65:208 failed faulty running
| `- 8:0:0:7 sdae 65:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:0:7 sdac 65:192 failed faulty running
`- 5:0:0:7 sdab 65:176 failed faulty running
- 다음 명령어를 실행하여 문제를 해결합니다.
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| 업그레이드 |
1.9.8-1.9.21 |
증상
ABM 클러스터 업그레이드가 2시간 이상 멈춰 있으면 노드 드레이닝이 차단되었을 수 있습니다.
해결 방법:
다음 작업에서는 루트 관리자 클러스터를 예로 사용합니다. ${TARGET_KUBECONFIG}는 노드 드레이닝이 차단된 타겟 ABM 클러스터의 `kubeconfig` 를 나타내고, ${KUBECONFIG}는 타겟 ABM 클러스터를 관리하는 클러스터의 kubeconfig를 나타냅니다. 루트 관리자 클러스터의 경우 둘 다 루트 관리자 kubeconfig를 참조합니다.
ABM 클러스터 업그레이드가 멈췄는지 확인하려면 다음 단계를 완료하세요.
- 드레이닝에서 멈춘 노드를 확인합니다.
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
결과는 다음과 같습니다.
{"10.200.0.2": 2}
즉, 노드 '10.200.0.2'의 경우 두 개의 포드가 드레이닝되고 있습니다.
- 포드가 노드에서 여전히 드레이닝되고 있는지 확인합니다 (
${NODE_BEING_DRAINED}로 표시).
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
출력 포드 수는 이전 단계에서 보고된 드레인되는 포드 수와 동일해야 합니다.
1단계에 나열된 각 포드 yetToDrain에 대해 포드 상태를 확인합니다.
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
포드가 Running 상태이거나 포드가 obs-system 네임스페이스에서 audit-logs-loki-0 또는 loki-0이고 포드에 unable to unmount volume에 대한 불만이 있는 이벤트가 없는 경우 grace-period를 사용하여 포드를 명시적으로 삭제합니다.
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- 포드가 드레인되는 중에 멈춘 다른 모든 경우에는 당직 서비스로 에스컬레이션합니다.
- 노드의 드레이닝이 완료되었는지 모니터링합니다.
- 다른 노드가 드레이닝에서 멈춘 경우 1단계를 반복합니다.
|
| 업그레이드 |
1.9.6
1.9.7
1.9.8
|
서명된 아티팩트가 있는 1.9 버전은 DistributionPolicy의 Override 플래그가 false로 설정되어 대상 레지스트리에 이름이 동일한 아티팩트가 있는 경우 배포되지 않으므로 배포할 수 없습니다.
증상
다음 문제가 발생할 수 있습니다.
- 서명이 있는 아티팩트가 푸시됩니다. 로그는 다음과 같이 표시될 수 있습니다.
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 아티팩트를 푸시하지 못했습니다. 로그는 다음과 같이 표시될 수 있습니다.
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 404 아티팩트를 찾을 수 없습니다. 로그는 다음과 같이 표시될 수 있습니다.
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- 아티팩트 배포가 실패합니다.
해결 방법:
이 문제를 해결하려면 다음 단계를 따르세요.
DistributionPolicy 커스텀 리소스 (CR)를 업데이트하여 Spec.Override을 true로 설정합니다. - SAR-1005 런북에 따라 복제를 다시 트리거합니다.
- 새 복제 실행이 성공하면
Annotation에서 성공한 실행 ID로 ManualDistribution CR execution-ids을 업데이트합니다.
|
| 하드웨어 보안 모듈(HSM) |
1.9.9 |
HSM이 간헐적으로 ServicesNotStarted를 보고할 수 있으며, 이로 인해 베어메탈 서버가 정상 상태가 되지 않고 다음 메시지를 보고할 수 있습니다.
"message": "failed to get master key name"
증상
다음 문제가 발생할 수 있습니다.
해결 방법:
이 문제를 해결하려면 다음 단계에 따라 멈춘 HSM을 재부팅하세요.
- 다음 명령어를 실행하여 첫 번째 HSM에서
kstl 도구를 설치합니다.
export HSM_NAME=`kubectl get hsm \
-n gpc-system -o jsonpath={.items[0].metadata.name} | tr -d '"'`
export HSM_MGMT_IP=$(kubectl get hsm $HSM_NAME \
--namespace gpc-system \
--output jsonpath="{.spec.managementNetwork.ip}")
curl --insecure \
https://$HSM_MGMT_IP/downloads/ksctl_images.zip \
--output ksctl_images.zip
mkdir -p ~/bin
unzip ksctl_images.zip -d ~/bin
cp ~/bin/ksctl-linux-amd64 ~/bin/ksctl
export PATH=$PATH:~/bin
mkdir -p $HOME/.ksctl
export ADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "admin" | grep -v "luna-admin" | grep -v "ksadmin"`
export ADMIN_PW=$(kubectl get secrets $ADMIN_SECRET_NAME -n hsm-system -o jsonpath="{.data.password}" | base64 -d)
export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $HOME/.ksctl/ssh-privatekey
chmod 0600 $HOME/.ksctl/ssh-privatekey
cat << EOF > $HOME/.ksctl/config.yaml
KSCTL_URL: https://$HSM_MGMT_IP:443
KSCTL_USERNAME: admin
KSCTL_PASSWORD: '$ADMIN_PW'
KSCTL_NOSSLVERIFY: true
EOF
- HSM이 다시 시작하는 데 문제가 있는지 확인합니다.
ServicesNotStarted에서 멈춘 각 HSM에 대해 $HSM_MGMT_IP를 가져오고 서비스가 다운되었는지 확인합니다.
ksctl services status --url=https://$HSM_MGMT_IP
- 모든 HSM, HSM 클러스터, HSM 테넌트를 일시중지합니다.
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
- 서비스가 중단된 상태로 HSM에 SSH 연결을 설정합니다.
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- 올바른 HSM에 있는지 확인합니다. 올바른
$HSM_MGMT_IP로 SSH 연결을 설정했는지 확인합니다.
- HSM 내부에서 첫 번째 HSM을 재부팅합니다.
ksadmin@ciphertrust:~ sudo reboot
- 첫 번째 HSM이 HSM 외부에서 정상 상태가 될 때까지 기다립니다.
watch -c ksctl services status --url=https://$HSM_MGMT_IP
HSM이 다시 시작되는 데 약 5분이 걸릴 수 있습니다.
- 서비스가 다운된 다른 HSM에 대해 이 단계를 반복합니다.
- HSM, HSM 클러스터, HSM 테넌트의 일시중지를 해제합니다.
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
- 모든 항목이 조정되었는지 확인합니다. HSM이 조정되는 데 5~10분 정도 걸릴 수 있습니다.
|
| 모니터링 |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9 |
증상
1.11.3 이전 GDC 버전의 조직 시스템 클러스터에서 alertmanager-servicenow-webhook 알림이 ServiceNow에 도달하지 않습니다. 로그에 read: connection reset by peer 오류 메시지가 포함되어 있습니다. 이 문제는 출구 트래픽을 사용 설정하는 라벨이 누락되어 발생합니다. 웹훅이 조직 간에 통신해야 하는 경우 이그레스 NAT를 사용해야 합니다.
해결 방법:
조직 시스템 클러스터에서 alertmanager-servicenow-webhook의 이그레스 트래픽을 사용 설정해야 합니다. 이 문제를 해결하려면 다음 단계를 따르세요.
- 필수 기본 요소를 설정합니다.
- gdcloud 명령줄 인터페이스 (CLI)를 설치합니다.
- 루트 관리자 및 조직 관리자 클러스터의 kubeconfig 파일 경로를 가져옵니다. 경로를 각각
ROOT_KUBECONFIG 및 ORG_SYSTEM_KUBECONFIG 환경 변수에 저장합니다.
- 보안 관리자에게 루트 관리자 및 조직 관리자 클러스터 모두에 대해
obs-system 네임스페이스의 관측 가능성 관리자 (observability-admin) 역할을 부여해 달라고 요청하세요.
- 환경에 문제가 있는지 확인합니다.
alertmanager-servicenow-webhook 배포를 가져옵니다.
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
alertmanager-servicenow-webhook 배포의 로그를 확인합니다.
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
로그에 오류 메시지 read: connection reset by peer가 포함되어 있으면 문제가 있는 것이므로 이 해결 방법의 단계를 계속 진행해야 합니다.
- 이그레스 라벨을 추가합니다.
- 현재
alertmanager-servicenow-webhook 배포 YAML 파일을 가져옵니다.
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml && \
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
alertmanager-servicenow-webhook 배포 YAML 파일에 이그레스 라벨을 추가합니다.
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
alertmanager-servicenow-webhook 배포 YAML 파일을 업데이트된 파일로 바꿉니다.
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
배포가 자동으로 다시 시작되어야 합니다.
- 환경에 문제가 있는지 확인 단계를 다시 실행하여 문제가 해결되었는지 확인합니다. 로그의 오류 메시지가 표시되면 안 됩니다. 그렇지 않으면 엔지니어링팀에 에스컬레이션합니다.
롤백 전략:
해결 방법 단계가 실패하거나 측정항목이 손실되면 alertmanager-servicenow-webhook 배포 YAML 파일을 원래 상태로 되돌립니다.
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| 업그레이드 |
1.9.10 |
증상
업그레이드가 NodeMaintain 단계에서 멈춥니다.
gpc-system org-1-admin-control-plane-node-poolphdzg 1 in-progress 3h58m
Status: Tasks:
Name: zp-aa-bm06 Task Status: finished
Name: zp-aa-bm04
Task Status: finished
Name: zp-aa-bm05
Task Status: in-progress
Upgrade Status: in-progress
Events: none
진행 중인 노드 풀의 nodeupgradetask에는 다음이 표시됩니다.
Status: Conditions: Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: Succeeded
Status: True
Type: PreUpgradeValidationCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: InProgress
Status: False
Type: NodeMaintainCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message: Observed Generation:1
Reason: Reconciling
Status: Unknown
Type: Succeeded
│ Data IP:10.249.20.4 bm-5f3d1782
│ Start Time: 2023-11-09T18:26:31Z
│ Events: none
해결 방법:
다음 단계를 따르세요.
- cap-controller-manager 배포의 이름을 가져옵니다.
kubectl --kubeconfig ${KUBECONFIG} get deployment -n kube-system | grep cap-controller-manager
cap-controller-manager-1.28.0-gke.435 1/1 1 1 30h
- cap-controller-manager의 이름을 지정합니다 (예: cap-controller-manager-1.28.0-gke.435).
export CAP_DEPLOYMENT_NAME=
- cap-controller-manager를 다시 시작합니다.
kubectl --kubeconfig ${KUBECONFIG} rollout restart deployment ${CAP_DEPLOYMENT_NAME} -n kube-system
deployment.apps/cap-controller-manager-1.28.0-gke.435 restarted
|
| 업그레이드 |
1.9.10 |
증상
업그레이드가 AdminClusterHealth 사후 검사 단계에서 멈춥니다.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
조직 객체에는 다음이 표시됩니다.
NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
해결 방법:
다음 단계를 따르세요.
다음 명령어를 사용하여 사전 검사를 건너뜁니다.
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| 업그레이드 |
1.9.9 |
증상
NodeUpgradeTask에 작업 완료를 차단하는 failed to monitor failover registry recreation: failed to monitor job: job not complete 조건이 있을 수 있습니다.
해결 방법:
이 문제를 해결하려면 작업을 다시 시작하세요.
- 완료가 '0/1'인
create-failover-registry-***이라는 작업을 삭제합니다.
- 업그레이드 중인 서버 객체에서
failover-registry-creation-job-name 주석을 삭제합니다.
컨트롤러가 작업을 자동으로 다시 만듭니다.
|
| 업그레이드 |
1.9.20 |
증상
노드가 backup-ipsec-for-upgrade-bm 작업에서 실패합니다.
I0512 01:05:55.949814 7 main.go:24] BuildDate: 2023-04-01T15:48:57Z
I0512 01:05:55.949920 7 main.go:25] Version: 1.9.2-gdch.135.dirty
"
해결 방법:
`backup-ipsec-for-upgrade-bm` 작업을 삭제하고 다시 생성될 때까지 기다립니다.
|
| Google Distributed Cloud |
1.9.9 |
증상
etcd 클러스터가 시작되지 않아 컨트롤 플레인 노드 풀이 준비되지 않습니다. 다음 문제가 발생할 수 있습니다.
--- FAIL: TestPlan (27563.26s)
--- FAIL: TestPlan/TestMTSystemClusterHealth (3445.24s)
k8s_mt_system_cluster_healthcheck_test.go:149: FATAL FLAKE: TestMTSystemClusterHealth: system cluster did not become ready in time: NodePool org-1-system-cluster/control-plane-node-pool didn't get ready: NodePool "control-plane-node-pool" is not ready
Error Routing:
{
"Name": "NODEPOOL_NOT_READY_ERR",
"Description": "NodePool is not ready",
"OwnerTeam": "Cluster Management",
"OwnerLDAP": "",
"TrackingBug""
}
FAIL
해결 방법:
이 문제를 해결하려면 다음 단계를 따르세요.
- 클러스터 생성이 머신 초기화 작업에서 멈췄는지 확인합니다.
kubeadm join 작업이 다음 이유로 실패했습니다.
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
다음과 같은 이유로 kubeadm reset 작업이 실패했습니다.
panic: runtime error: invalid memory address or nil pointer dereference
- SSH를 사용하여 작동하는 제어판 노드에 연결합니다.
etcdctl 명령어를 실행하여 오래된 데이터를 정리합니다.etcd 멤버십을 확인합니다.
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member list
5feb7ac839625038, started, vm-72fed95a, https://10.252.164.11:2380, https://10.252.164.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://10.252.164.12:2380, https://10.252.164.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://10.252.164.10:2380, , false
- 사용하지 않는 멤버십을 삭제합니다.
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member remove bd1949bcb70e2cb5
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
|
| VM 백업 및 복원 |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
증상
VM 관리자의 부적절한 역할 기반 액세스 제어 (RBAC) 및 스키마 설정으로 인해 사용자가 VM 백업 및 복원 프로세스를 시작할 수 없습니다.
VM 백업 계획 이름은 63자를 초과할 수 없습니다.
예를 들어 다음과 같은 오류 메시지가 표시될 수 있습니다.
Internal error occurred: failed calling webhook
"vvirtualmachinebackupplantemplates.virtualmachine.gdc.goog":
failed to call webhook: Post "https://vmm-vm-controller-webhooks.vm-system.svc:443/validate-virtualmachine-gdc-goog-v1-virtualmachinebackupplantemplate?timeout=10s":
context deadline exceeded
해결 방법:
VM 백업 계획 이름은 VirtualMachineBackupPlanTemplate 이름, 리소스 유형 (vm 또는 vm-disk) 및 해당 리소스의 이름을 연결한 것입니다. 연결된 문자열은 63자(영문 기준) 미만이어야 합니다.
이를 위해 이러한 리소스를 만들 때 이름을 짧게 유지하세요. 이러한 리소스 생성에 대한 자세한 내용은 VM 인스턴스 만들기 및 시작 및 VM 백업 계획 만들기를 참고하세요.
|
| 업그레이드 |
1.9.9 |
증상
다음 템플릿 오류로 인해 업그레이드에서 백업 ipsec 작업이 실패합니다.
"msg": "An unhandled exception occurred while templating '{'changed': True, 'stdout': 'connections {\\n # A connection id defined for this specific connection\\n pol_client {\\n children {\\n pol_cli
해결 방법:
다음 단계를 따르세요.
업그레이드 작업이 실패한 노드에 로그인합니다. swanctl.conf를 백업으로 저장합니다.
/etc/swanctl/swanctl.conf 파일에서 중괄호가 있는 줄을 삭제합니다.
실패한 backup-ipsec-for-upgrade 작업을 삭제하고 다시 만들어질 때까지 기다리면 후속 작업이 성공적으로 완료됩니다. 3단계에서 삭제한 줄을 /etc/swanctl/swanctl.conf에 다시 추가합니다.
|
| 노드 플랫폼 |
1.9.6
1.9.7
1.9.8
1.9.9 |
루트 관리자 클러스터에서 펌웨어 업그레이드가 시작되면 노드 중 하나가 노드 업그레이드를 완료한 후 멈춘 것처럼 보입니다.
증상
nodeupgradetask이 NodeResumeCompleted 단계에서 멈춥니다.machine-init 작업이 실패하고 로그에 kubeadm join이 실패한 것으로 표시됩니다.- 데이터 플레인 IP 주소를 사용하여 노드에 SSH 연결을 설정할 수 없습니다.
이 문제는 업그레이드된 노드가 더 이상 인바운드 네트워크 트래픽을 수락하지 않아 발생합니다.
해결 방법:
- 실패한
job/nodeupgradetask 로그를 검사하여 IP 주소를 기록하고 문제가 있는 노드를 확인합니다.
- 영향을 받는 노드의
anetd-client 포드를 다시 시작합니다.
- 데이터 플레인 IP에서 영향을 받는 노드로의 SSH 연결을 확인합니다.
추가 조사를 위한 선택적 단계:
- 작동하는 anetd 포드 중 하나의 cilium 에이전트 컨테이너로 셸을 실행합니다.
- cilium-bugtool을 실행하고 약 10초 동안 기다립니다. 이 도구는
/var/log/network/policy_action.log 디렉터리에 로그를 저장합니다.
deny를 찾아 트래픽이 거부되는지 확인합니다.
grep -r "deny" /var/log/network/ to
거부된 서버(루트 관리자 베어메탈 노드일 수 있음)를 확인합니다. |
| 업그레이드 |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
증상
|
| 업그레이드 |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
증상
- 1.9.12에서 1.9.13으로 업그레이드하는 동안 테넌트 조직 베어메탈의 노드 OS 업그레이드가 실패합니다. 다음 메시지가 표시됩니다.
Reason: Succeeded
Status: True
Type: NodeMaintainCompleted
Last Transition Time: 2024-05-06T18:25:20Z
Message: the ssh cert rotation job is still in progress
Observed Generation: 1
Reason: ReconcileBackoff
Status: Unknown
Type: Succeeded
Last Transition Time: 2024-05-06T18:27:42Z
-
SSH generation fails. The following message appears:
"tasks": [
{
"hosts": {
"10.248.4.72": {
"action": "gather_facts",
"changed": false,
"msg": "Failed to connect to the host via ssh: Certificate invalid: name is not a listed principal\r\nHost key verification failed
.",
"unreachable": true
}
},
"task": {
"duration": {
"end": "2024-05-06T19:47:11.284055Z",
"start": "2024-05-06T19:47:11.146536Z"
},
"id": "98f2b32d-e15c-fe27-2225-00000000001c",
"name": "Gathering Facts"
}
} ]
해결 방법:
- 루트 관리자 및 조직 관리자 서버 CR에서
cluster.private.gdc.goog/ssh-trusted-ca-versions 주석을 삭제합니다.
- 실패한 Ansible 작업을 삭제합니다.
cluster.private.gdc.goog/host-key-rotation-in-progress 주석이 서버 CR에서 true로 표시되어 새 작업이 자동으로 생성됩니다.
- 로테이션 후
cluster.private.gdc.goog/ssh-trusted-ca-versions 주석이 서버 CR에 다시 추가됩니다.
|
| 노드, 업그레이드 |
1.9.* |
증상
업그레이드 후 일부 베어메탈 노드의 포드가 CrashLoopBackOff 상태로 멈추고 노드의 iptables -L -v -n | grep CILIUM이 빈 결과를 반환합니다.
해결 방법:
문제를 해결하려면 다음 단계를 수행합니다.
- 다음 명령어를 실행합니다.
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force
iptables -L -v -n | grep CILIUM을 다시 실행하고 출력이 있는지 확인합니다.
|
| 로깅 |
1.9.14
1.9.15 |
증상
audit-logs-loki-0 포드가 CrashLoopBackOff 상태입니다.
포드 상태를 확인합니다.
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
여기서 SYSTEM_KUBECONFIG는 kubeconfig 파일의 경로입니다.
Loki 오류는 다음 출력과 같이 표시됩니다. 여기서 CrashLoopBackOff은 상태입니다.
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
해결 방법:
문제를 해결하려면 다음 단계를 수행합니다.
- kubeconfig 파일의 경로를
SYSTEM_KUBECONFIG라는 환경 변수로 내보냅니다.
- Logmon 연산자를 축소합니다.
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Loki 리소스를 축소합니다.
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
audit-logs-loki-storage-audit-logs-loki-0 및 loki-storage-loki-0 영구 볼륨 클레임 (PVC)을 삭제합니다.obs-system/loki-storage-loki-0 및 obs-system/audit-logs-loki-storage-audit-logs-loki-0 영구 볼륨 (PV)을 삭제합니다.- Logmon 연산자를 확장합니다.
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- 버전 1.9에서 로깅 구성을 업데이트하는 단계를 따릅니다.
audit-logs-loki-0 포드가 실행 중인지 확인합니다.
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
Running 상태는 다음 예와 같이 출력에 표시되어야 합니다.
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| 코드형 인프라 |
1.9.16 |
증상
1.9.16으로 업그레이드하면 Gitlab 부가기능 설치가 실패합니다. 다음과 같은 오류가 표시될 수 있습니다.
Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgr │
│ ade error: timed out waiting for the condition: deployments/gitlab-sidekiq-all-in-1-v2: release gitlab failed: client rate limiter Wait returned an error: ra │
│ te: Wait(n=1) would exceed context deadline
gpc-system/gitlab-postgresql-0와 같은 postgres 포드가 종료 상태입니다.
해결 방법:
- 종료 중 상태로 멈춰 있는 postgres 포드를 강제로 삭제합니다.
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- 삭제 후 postgres 포드가 다시 생성되는지 확인합니다.
|
| ID 및 액세스 관리 |
1.9.19
1.9.20 |
증상
1.9.18에서 업그레이드하고 GDC 콘솔에 액세스하려고 하면 다음 메시지가 표시될 수 있습니다.
Authentication failed, please contact your system administrator
해결 방법:
- 필요한 CA를 가져옵니다.
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- 수정할 클라이언트 구성 파일을 엽니다.
kubectl edit clientconfig -n kube-public default
- 클라이언트 구성에서
certificateAuthorityData를 찾아 다음 경로를 사용하여 필수 CA를 업데이트합니다. spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
