버전 정보는 연결된 Distributed Cloud 출시 노트를 참고하세요.

Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

Distributed Cloud Connected 문제 해결

Google은 Google Distributed Cloud connected 하드웨어를 원격으로 모니터링하고 유지보수합니다. 이를 위해 Google 엔지니어는 Distributed Cloud(연결형) 하드웨어에 대한 보안 셸(SSH) 액세스 권한을 보유합니다. Google에서 문제를 감지하면 Google 엔지니어가 연락하여 문제를 해결합니다. 문제를 직접 확인한 경우 즉시 Google 지원팀에 문의하여 진단하고 해결하세요.

Distributed Cloud Connected 소프트웨어 업그레이드

이 섹션에서는 측정항목 탐색기를 사용하여 Distributed Cloud 연결 클러스터가 소프트웨어 업그레이드를 진행 중인지 확인하는 방법을 설명합니다.

이 절차에서는 다음 모니터링 측정항목을 사용합니다.

현재 클러스터 버전(/edge_cluster/current_cluster_version): 클러스터에서 실행 중인 Distributed Cloud(연결형) 소프트웨어의 현재 버전을 나타냅니다.
타겟 클러스터 버전 (/edge_cluster/target_cluster_version): 클러스터가 업그레이드되는 Distributed Cloud 연결의 타겟 버전을 나타냅니다.

이 섹션의 단계를 완료하려면 다음 기본 요건을 충족해야 합니다.

Google Cloud 콘솔 및 Distributed Cloud에 연결된 Google Cloud 프로젝트에 대한 액세스 권한
Monitoring 측정항목을 볼 수 있는 Monitoring 뷰어 IAM 역할
(선택사항) 반환된 결과를 필터링하기 위한 타겟 Distributed Cloud Connected 머신의 machine_id 값입니다.

측정항목 탐색기를 사용하여 클러스터의 현재 및 타겟 소프트웨어 버전 확인

측정항목 탐색기로 이동합니다.
1. Google Cloud 콘솔에서 Monitoring 섹션으로 이동합니다.
2. 왼쪽 탐색 트리에서 측정항목 탐색기를 클릭합니다.
대상 리소스 유형을 선택합니다.
1. 측정항목 탐색기 페이지에서 구성 페이지로 이동합니다.
2. 측정항목 선택을 클릭합니다.
3. 검색창을 사용하여 클러스터 리소스 유형을 검색합니다. 전체 리소스 식별자 edgecontainer.googleapis.com/Cluster를 사용할 수도 있습니다.
4. 반환된 결과에서 클러스터 리소스 유형을 클릭합니다.
클러스터의 현재 소프트웨어 버전을 가져옵니다.
1. 측정항목 섹션에서 current_cluster_version 값을 검색합니다.
2. 머신 가동시간 측정항목을 선택합니다. 전체 경로는 edgecontainer.googleapis.com/edge_cluster/current_cluster_version입니다.
3. (선택사항) 필터 섹션을 사용하여 타겟 machine_id 값으로 필터링합니다.
클러스터의 타겟 소프트웨어 버전을 가져옵니다.
1. 쿼리 추가를 클릭합니다.
2. 측정항목 섹션에서 target_cluster_version 값을 검색합니다.
3. 대상 클러스터 버전 측정항목을 선택합니다. 전체 경로는 edgecontainer.googleapis.com/edge_cluster/target_cluster_version입니다.
4. (선택사항) 필터 섹션을 사용하여 타겟 machine_id 값으로 필터링합니다.
표시되는 차트에서 클러스터의 소프트웨어 업그레이드 상태를 확인합니다.
- 현재 클러스터 버전과 타겟 클러스터 버전 줄에 각각 다른 값이 표시되면 클러스터에서 소프트웨어 업그레이드가 진행 중인 것입니다.
- 현재 클러스터 버전과 타겟 클러스터 버전 줄에 동일한 값이 표시되면 클러스터가 소프트웨어 업그레이드를 진행하지 않는 것입니다.
다음 명령어를 사용하여 이전 단계의 결과를 확인합니다.
```
gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION
```
다음을 바꿉니다.
- CLUSTER_ID: 대상 클러스터의 ID입니다.
- REGION: 클러스터가 생성된 Google Cloud 리전입니다.
명령어 출력에서 다음 필드의 값을 확인합니다.
- status 필드 값이 UPDATING이면 클러스터가 소프트웨어 업그레이드를 진행 중입니다.
- clusterVersion 및 targetVersion 필드의 값이 다른 경우 측정항목 탐색기에서 반환된 값과 비교하여 확인합니다.

결과 이해

다음 표에서는 측정항목 탐색기와 gcloud 명령어에서 반환되는 결과를 설명합니다.

클러스터 상태	진단	해결 방법
Healthy `currentVersion` 및 `targetVersion` 값이 일치합니다. `status` 값이 `RUNNING`입니다.	클러스터에서 Distributed Cloud Connected 소프트웨어의 타겟 버전을 실행하고 있습니다.	없음
업그레이드 `currentVersion` 값이 `targetVersion`보다 낮음 `status` 값이 `UPDATING`임	클러스터가 Distributed Cloud 연결 소프트웨어의 타겟 버전으로 업그레이드되고 있습니다.	현재 클러스터 버전 값과 타겟 클러스터 버전 값이 일치할 때까지 측정항목 탐색기에서 클러스터를 모니터링합니다.
고정됨 `currentVersion` 값이 `targetVersion`보다 무기한 낮음 `status` 값이 무기한 `UPDATING`임	클러스터의 하나 이상의 노드에서 Distributed Cloud 연결 소프트웨어의 타겟 버전으로 업그레이드하지 못했습니다.	머신 연결 및 시스템 로그를 확인하고 Google에 문의하여 지원을 받으세요.
롤백 `currentVersion` 값이 `targetVersion`보다 높음 `status` 값이 `UPDATING`임	luster가 이전 버전의 Distributed Cloud 연결 소프트웨어로 롤백됩니다.	Google에 문의하여 롤백 이유를 파악합니다.

클러스터의 소프트웨어 업그레이드가 실패했거나 클러스터가 이전 소프트웨어 버전으로 롤백된 경우 다음을 확인하세요.

노드 상태 각 물리적 Distributed Cloud 연결 머신에 네트워크 연결이 있고 다음 섹션에 설명된 대로 가동 시간을 보고하는지 확인합니다.
유지보수 기간. 유지보수 제외 기간으로 인해 소프트웨어 업그레이드가 일시중지되었는지 확인합니다.
시스템 로그 시스템 로그를 검사하여 포드 제거 시간 초과와 같은 소프트웨어 업그레이드 실패의 원인을 파악합니다.

표에 나열된 해결 단계로 문제가 해결되지 않으면 영향을 받는 머신의 machine_id 값과 서비스 중단 타임스탬프를 포함하여 Google 지원팀에 문의하세요.

Distributed Cloud Connected 머신 다시 시작

이 섹션에서는 측정항목 탐색기를 사용하여 Distributed Cloud에 연결된 실제 머신이 다시 시작되었는지 확인하고 다시 시작된 이유를 파악하는 방법을 설명합니다. 다시 시작을 모니터링하면 계획된 유지보수의 일부인지 아니면 하드웨어 오류나 전원 중단의 결과인지 파악할 수 있습니다.

이 절차에서는 다음 모니터링 측정항목을 사용합니다.

머신 업타임(/machine/uptime): 마지막으로 다시 시작한 후 경과된 시간(초)을 나타냅니다.
머신 재시작 (/machine/restart_count): 배포 이후 타겟 머신의 총 재시작 횟수를 나타냅니다.

이 섹션의 단계를 완료하려면 다음 기본 요건을 충족해야 합니다.

Google Cloud 콘솔 및 Distributed Cloud에 연결된 Google Cloud 프로젝트에 대한 액세스 권한
Monitoring 측정항목을 볼 수 있는 Monitoring 뷰어 IAM 역할
(선택사항) 반환된 결과를 필터링하기 위한 타겟 Distributed Cloud Connected 머신의 machine_id 값입니다.

측정항목 탐색기를 사용하여 머신 업타임 및 다시 시작 횟수 확인

측정항목 탐색기로 이동합니다.
1. Google Cloud 콘솔에서 Monitoring 섹션으로 이동합니다.
2. 왼쪽 탐색 트리에서 측정항목 탐색기를 클릭합니다.
대상 리소스 유형을 선택합니다.
1. 측정항목 탐색기 페이지에서 구성 페이지로 이동합니다.
2. 측정항목 선택을 클릭합니다.
3. 검색창을 사용하여 머신 리소스 유형을 검색합니다. 전체 리소스 식별자 edgecontainer.googleapis.com/Machine를 사용할 수도 있습니다.
4. 반환된 결과에서 머신 리소스 유형을 클릭합니다.
머신의 업타임을 확인합니다.
1. 측정항목 섹션에서 uptime 값을 검색합니다.
2. 머신 가동시간 측정항목을 선택합니다. 전체 경로는 edgecontainer.googleapis.com/machine/uptime입니다.
3. (선택사항) 필터 섹션을 사용하여 타겟 machine_id 값으로 필터링합니다.
4. 표시되는 시간 차트에서 업타임 그래프가 계속 상승하는지 확인합니다. 가동 시간 값이 0으로 떨어지고 다시 시작되면 머신이 다시 시작된 것입니다.
머신의 다시 시작 횟수를 확인합니다.
1. 측정항목 섹션에서 restart_count 값을 검색합니다.
2. 머신 다시 시작 측정항목을 선택합니다. 전체 경로는 edgecontainer.googleapis.com/machine/restart_count입니다.
3. (선택사항) 필터 섹션을 사용하여 타겟 machine_id 값으로 필터링합니다.
4. 표시되는 시간 차트에서 그래프 선이 0에 유지되어 재시작이 발생하지 않았음을 확인합니다. 이 선이 어느 시점에서든 1로 급증하면 머신이 다시 시작되었음을 나타냅니다. 추가 문제 해결을 위해 다시 시작의 정확한 타임스탬프를 기록해 두세요.
5. (선택사항) 그래프 대신 개별 이벤트를 보려면 페이지의 집계 섹션으로 이동하여 정렬 기간 필드를 1 minute로, 계열별 정렬기 필드를 델타로 설정합니다.

결과 이해

다음 표에서는 측정항목 탐색기에서 반환되는 결과를 설명합니다.

머신 상태	진단	해결 방법
안정 '머신 가동시간' 측정항목이 꾸준히 증가합니다. '머신 다시 시작' 측정항목 델타가 `0` 입니다.	머신이 다시 시작되지 않았습니다.	없음
클린 재시작 '머신 가동시간' 측정항목이 `0`으로 감소 '머신 재시작' 측정항목이 `1`으로 급증	머신이 다시 시작되고 Google Cloud에 다시 연결되었습니다.	시스템 로그를 확인하여 다시 시작된 이유를 파악합니다.
정전 '머신 가동 시간' 측정항목 그래프에 데이터가 없는 중단이 있음 머신 가동 시간 중단 중에 '머신 다시 시작' 측정항목이 변경되지 않음	머신이 다시 시작되기 전에 전원 또는 네트워크 연결이 끊어졌습니다.	전원 및 네트워크 케이블 배선, 로컬 네트워크 구성, LED 표시등 상태를 확인합니다.
간헐적 '머신 연결됨' 측정항목 값이 `0`와 `1` 사이에서 번갈아 표시됨 '네트워크 연결' 측정항목 값이 `0`와 `1` 사이에서 번갈아 표시됨	불안정한 네트워크 연결, 패킷 손실 또는 과도한 지연 시간	로컬 네트워크에 혼잡이 있는지, 하드웨어에 결함이 있는지 확인합니다.

표에 나열된 해결 단계로 문제가 해결되지 않으면 영향을 받는 머신의 machine_id 값과 서비스 중단 타임스탬프를 포함하여 Google 지원팀에 문의하세요.

Distributed Cloud Connected 머신 연결

이 섹션에서는 Cloud Monitoring의 측정항목 탐색기 기능을 사용하여 Distributed Cloud에 연결된 머신의 인터넷 및 Google Cloud 연결을 확인하는 방법을 설명합니다.

이 절차에서는 다음 모니터링 측정항목을 사용합니다.

기기 연결됨 (/machine/connected): 기기가 Google Cloud에 연결되어 있는지 나타냅니다.
네트워크 연결 (/machine/network/connectivity): 머신의 기본 네트워크 인터페이스에 인터넷 연결이 있는지 나타냅니다.

이 섹션의 단계를 완료하려면 다음 기본 요건을 충족해야 합니다.

Google Cloud 콘솔 및 Distributed Cloud에 연결된 Google Cloud 프로젝트에 대한 액세스 권한
Monitoring 측정항목을 볼 수 있는 Monitoring 뷰어 IAM 역할
(선택사항) 반환된 결과를 필터링하기 위한 타겟 Distributed Cloud Connected 머신의 machine_id 값입니다.

측정항목 탐색기를 사용하여 머신 연결 확인

측정항목 탐색기로 이동합니다.
1. Google Cloud 콘솔에서 Monitoring 섹션으로 이동합니다.
2. 왼쪽 탐색 트리에서 측정항목 탐색기를 클릭합니다.
대상 리소스 유형을 선택합니다.
1. 측정항목 탐색기 페이지에서 쿼리 페이지로 이동합니다.
2. 검색창을 사용하여 머신 리소스 유형을 검색합니다. 전체 리소스 식별자 edgecontainer.googleapis.com/Machine를 사용할 수도 있습니다.
3. 반환된 결과에서 머신 리소스 유형을 클릭합니다.
머신이 Google Cloud에 연결되어 있는지 확인합니다.
1. 측정항목 섹션에서 connected 값을 검색합니다.
2. Machine Connected 측정항목을 선택합니다. 전체 경로는 edgecontainer.googleapis.com/machine/connected입니다.
3. (선택사항) 필터 섹션을 사용하여 타겟 machine_id 값으로 필터링합니다.
4. 표시되는 시간 차트에서 정상 선이 100%로 연속적으로 유지되는지 확인합니다. 이 값이 0% 이거나 비정상인 시점에는 머신이 표시된 시간에 Google Cloud 와의 연결이 끊긴 것입니다.
머신의 인터넷 연결 상태를 확인합니다.
1. 측정항목 섹션에서 connectivity 값을 검색합니다.
2. 네트워크 연결 측정항목을 선택합니다. 전체 경로는 edgecontainer.googleapis.com/machine/network/connectivity입니다.
3. (선택사항) 필터 섹션을 사용하여 타겟 machine_id 값으로 필터링합니다.
4. 표시되는 시간 차트에서 정상 선이 100%로 연속적으로 유지되는지 확인합니다. 이 값이 어느 시점에서든 0% 비정상이면 머신이 표시된 시간에 인터넷 연결이 끊긴 것입니다.

결과 이해

다음 표에서는 측정항목 탐색기에서 반환되는 결과를 설명합니다.

머신 상태	진단	해결 방법
정상 '머신 연결됨' 측정항목 값이 `1`입니다. '네트워크 연결' 측정항목 값이 `1`입니다.	정상 작동	없음
연결 해제됨 '머신 연결됨' 측정항목 값은 `0` '네트워크 연결' 측정항목 값은 `1`	머신이 인터넷에 연결되어 있지만 Google Cloud에 연결할 수 없습니다.	Google 서비스 및 API 엔드포인트의 방화벽 규칙을 확인합니다. Distributed Cloud 연결 에이전트가 머신에서 실행 중인지 확인합니다.
격리됨 '머신 연결됨' 측정항목 값이 `0` 입니다. '네트워크 연결' 측정항목 값이 `0` 입니다.	머신이 인터넷에 연결되어 있지 않습니다.	전원 및 네트워크 케이블 배선, 로컬 네트워크 구성, LED 표시등 상태를 확인합니다. VLAN 및 라우팅 구성을 확인합니다.
간헐적 '머신 연결됨' 측정항목 값이 `0`와 `1` 사이에서 번갈아 표시됨 '네트워크 연결' 측정항목 값이 `0`와 `1` 사이에서 번갈아 표시됨	불안정한 네트워크 연결, 패킷 손실 또는 과도한 지연 시간	로컬 네트워크에 혼잡이 있는지, 하드웨어에 결함이 있는지 확인합니다.

두 측정항목 중 하나의 0 값이 지속적으로 표시되면 표에 설명된 문제 해결 단계에 따라 문제를 해결하세요. 문제가 계속되면 영향을 받는 컴퓨터의 machine_id 값과 서비스 중단 타임스탬프를 포함하여 Google 지원팀에 문의하세요.

가상 머신이 `Pending` 상태로 멈춤

다음 중 하나가 발생하면 가상 머신 워크로드가 Pending 상태에서 멈추고 노드에 예약되지 않을 수 있습니다.

Distributed Cloud Connected가 가상 머신에 CPU 시간, 메모리, 디스크 공간과 같은 요청된 리소스를 할당할 수 없습니다.
가상 머신의 구성에 오류가 있습니다.
가상 머신의 스토리지에 결함이 있습니다.
대상 노드가 오염되었습니다.

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

클러스터 사용자 인증 정보 가져오기에 설명된 대로 클러스터 사용자 인증 정보를 가져옵니다.

영향을 받는 가상 머신에 대한 정보를 확인합니다.

kubectl describe virtualmachine VM_NAME -n NAMESPACE

다음을 바꿉니다.

VM_NAME: 대상 가상 머신의 이름입니다.
NAMESPACE: 대상 가상 머신의 네임스페이스입니다.

이 명령어는 다음과 유사한 출력을 반환합니다.

Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

명령어의 출력에는 리소스 제약, 예약 실패, 스토리지 오류 및 기타 문제를 나타낼 수 있는 메시지가 포함됩니다.

다음 섹션에 설명된 대로 출력을 검사하여 예약 실패의 원인을 확인합니다.

리소스 부족

CPU, 메모리, 디스크 공간과 같은 리소스가 부족하다는 메시지가 표시될 수 있습니다. 예를 들면 다음과 같습니다.

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

이 문제를 해결하려면 영향을 받는 가상 머신과 노드에 예약된 다른 워크로드에 할당된 리소스를 확인한 후 비즈니스 요구사항에 따라 다음 단계를 따르세요.

노드에 예약된 다른 워크로드를 축소합니다.
영향을 받는 가상 머신에 할당된 리소스의 양을 줄입니다.
영향을 받는 클러스터에 머신을 더 추가합니다.

taint된 노드

타겟 노드가 오염되었다는 메시지가 표시될 수 있습니다. 예를 들면 다음과 같습니다.

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

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

다음 명령어를 사용하여 노드의 taint를 확인합니다.

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

이 명령어는 다음과 유사한 출력을 반환합니다.

NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

다음 중 하나를 수행합니다.
- 예기치 않은 taint는 taint 및 톨러레이션(toleration)에 설명된 대로 삭제합니다.
- 예상되는 taint의 경우 Taints and Tolerations에 설명된 대로 가상 머신의 구성에 해당 toleration을 추가합니다.

스토리지 오류

가상 머신의 스토리지에 오류가 있음을 나타내는 메시지가 표시될 수 있습니다. 예를 들면 다음과 같습니다.

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

이 메시지는 해당 영구 볼륨이 타겟 노드에 마운트되지 않았음을 나타낼 수 있습니다.

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

다음 명령어를 사용하여 영향을 받는 가상 머신의 네임스페이스에 있는 영구 볼륨 클레임 (PVC)의 상태를 가져옵니다.

kubectl get pvc -n NAMESPACE

NAMESPACE을 대상 네임스페이스의 이름으로 바꿉니다.

이 명령어는 다음과 유사한 출력을 반환합니다.

NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

해당 PVC의 상태가 Bound인지 확인합니다. 상태가 Pending이면 스토리지 하위 시스템에서 볼륨 프로비저닝에 실패한 것입니다. 이러한 경우 저장소 하위 시스템 구성을 문제 해결하고 적절한 StorageClass를 사용할 수 있는지 확인해야 합니다.

허용 웹훅 실패로 인한 예약 잠금

허용 웹훅을 사용하면 객체가 지속되기 전에 Kubernetes API 서버에 대한 요청을 가로챌 수 있습니다. 맞춤 보안 정책을 적용하는 데 유용하지만 잘못 구성된 웹훅은 특히 소프트웨어 업그레이드 및 인증서 새로고침과 같은 중요한 작업 중에 클러스터 전체 중단을 일으킬 수 있습니다. 특히 차단되거나 사용할 수 없는 허용 웹훅은 Kubernetes 컨트롤 플레인을 중단시켜 클러스터에서 추가 워크로드 스케줄링을 방해할 수 있습니다.

컨트롤 플레인 교착 상태

허용 웹훅이 웹훅 자체 복구에 필요한 리소스의 유효성 검사를 담당하는 경우 순환 종속성 교착 상태가 발생할 수 있습니다. 예를 들어 허용 웹훅이 포드를 검증하도록 구성되어 있고 노드 소프트웨어 업그레이드 중에 해당 웹훅 포드를 다시 예약해야 하는 경우 Kubernetes API 서버는 새 포드 생성을 승인하기 위해 웹훅에 연결하려고 시도할 수 있습니다. 웹훅에 연결할 수 없으면 요청이 실패하고 포드가 생성되지 않으며 클러스터가 새 워크로드를 예약할 수 없는 교착 상태에 들어갑니다.

failurePolicy: Fail로 웹훅이 구성된 경우 API 서버와 웹훅 간의 통신 오류 또는 시간 초과로 인해 API 요청이 거부됩니다. 이로 인해 다음과 같은 문제가 발생합니다.

소프트웨어 업그레이드 실패: 노드 소프트웨어 업그레이드 중 및 후에 시스템 구성요소와 VM을 예약할 수 없습니다.
시스템 서비스를 시작할 수 없음: GDC의 Symcloud Storage 및 VM 런타임과 같은 인프라 포드를 시작할 수 없습니다.
유지보수 모드에서 멈춘 노드: 컨트롤러가 승인 로직에 의해 차단되므로 유지보수 모드의 노드를 조정하거나 종료할 수 없습니다.

웹훅 구성 권장사항

이 섹션에 설명된 권장사항을 따라 앞에서 설명한 컨트롤 플레인 교착 상태를 방지하세요. 이러한 권장사항은 모든 ValidatingWebhookConfiguration 및 MutatingWebhookConfiguration 객체에 적용됩니다.

`failurePolicy: Ignore` 사용

비즈니스 요구사항에 따라 유효성을 검사할 수 없는 경우 API 요청이 실패해야 하는 것이 아니라면 항상 failurePolicy 필드를 Ignore로 설정하세요. 이렇게 하면 영향을 받는 웹훅 서비스가 다운되더라도 Kubernetes API 서버가 계속 작동하여 시스템에 중요한 포드를 예약하고 복구할 수 있습니다.

예약된 네임스페이스 제외

웹훅은 예약된 네임스페이스의 리소스 요청을 가로채서는 안 됩니다. namespaceSelector 필드를 사용하여 웹훅 구성에서 이러한 네임스페이스를 제외해야 합니다. 예약된 네임스페이스의 전체 목록은 관리 네임스페이스 제한사항을 참고하세요. 예를 들면 다음과 같습니다.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

실패한 웹훅으로 인해 교착 상태에 빠진 클러스터 복구

실패한 웹훅으로 인해 클러스터가 교착 상태에 있고 리소스 생성에 대한 kubectl 명령어가 시간 초과되거나 오류를 반환하는 경우 일반적으로 웹훅의 failurePolicy이 Fail로 설정되어 있기 때문입니다. 이 섹션의 단계에 따라 교착 상태에서 클러스터를 복구합니다. 실패한 웹훅이 변경 웹훅인 경우 validatingwebhookconfiguration 대신 mutatingwebhookconfiguration를 사용합니다.

실패한 웹훅을 식별합니다.
1. 클러스터에 배포된 검증 웹훅을 나열합니다.
```
kubectl get validatingwebhookconfigurations
```
2. 클러스터에 배포된 변형 웹훅을 나열합니다.
```
kubectl get mutatingwebhookconfigurations
```
해당 웹훅을 지원하는 포드가 실행 중인지 확인합니다.
```
kubectl get pods -A | grep WEBHOOK_SERVICE
```
WEBHOOK_SERVICE을 대상 웹훅의 서비스 이름으로 바꿉니다.

실패한 웹훅의 failurePolicy을 Ignore로 설정합니다.

kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

WEBHOOK_SERVICE을 대상 웹훅의 서비스 이름으로 바꿉니다.

(선택사항) 이전 단계가 실패한 경우 영향을 받는 웹훅의 구성을 강제 삭제합니다.
```
kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s
```
WEBHOOK_CONFIG을 대상 웹훅의 구성 이름으로 바꿉니다.

웹훅의 구성을 수정하거나 강제 삭제한 후 Kubernetes API 서버는 요청 처리를 재개하여 교착 상태를 해결하고 차단된 프로세스를 완료할 수 있도록 합니다.

Distributed Cloud Connected 문제 해결 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Distributed Cloud Connected 소프트웨어 업그레이드

측정항목 탐색기를 사용하여 클러스터의 현재 및 타겟 소프트웨어 버전 확인

결과 이해

Distributed Cloud Connected 머신 다시 시작

측정항목 탐색기를 사용하여 머신 업타임 및 다시 시작 횟수 확인

결과 이해

Distributed Cloud Connected 머신 연결

측정항목 탐색기를 사용하여 머신 연결 확인

결과 이해

가상 머신이 Pending 상태로 멈춤

리소스 부족

taint된 노드

스토리지 오류

허용 웹훅 실패로 인한 예약 잠금

컨트롤 플레인 교착 상태

웹훅 구성 권장사항

failurePolicy: Ignore 사용

예약된 네임스페이스 제외

실패한 웹훅으로 인해 교착 상태에 빠진 클러스터 복구

Distributed Cloud Connected 문제 해결

가상 머신이 `Pending` 상태로 멈춤

`failurePolicy: Ignore` 사용