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

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

Distributed Cloud Connected 문제 해결

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

Distributed Cloud(연결형) 소프트웨어 업그레이드

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

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

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

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

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 명령어에서 반환되는 결과를 설명합니다.

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

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

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

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

Distributed Cloud(연결형) 머신 다시 시작

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

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

머신 업타임(/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(연결형) 머신 연결

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

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

머신 연결됨 (/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 시간, 메모리, 디스크 공간과 같은 요청된 리소스를 가상 머신에 할당할 수 없습니다.
가상 머신 구성에 오류가 있습니다.
가상 머신의 스토리지에 오류가 있습니다.
대상 노드가 taint되었습니다.

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

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

영향을 받는 가상 머신에 대한 정보를 가져옵니다.

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된 노드

대상 노드가 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의 경우 taint 및 톨러레이션(toleration)에 설명된 대로 가상 머신 구성에 해당 톨러레이션(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을 예약할 수 없습니다.
시스템 서비스를 시작할 수 없음: Symcloud Storage 및 GDC용 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(연결형) 소프트웨어 업그레이드

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

결과 이해

Distributed Cloud(연결형) 머신 다시 시작

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

결과 이해

Distributed Cloud(연결형) 머신 연결

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

결과 이해

가상 머신이 Pending 상태로 멈춰 있음

리소스 부족

taint된 노드

스토리지 오류

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

컨트롤 플레인 교착 상태

웹훅 구성 권장사항

failurePolicy: Ignore 사용

예약된 네임스페이스 제외

실패한 웹훅으로 인해 교착 상태가 된 클러스터 복구

Distributed Cloud Connected 문제 해결

가상 머신이 `Pending` 상태로 멈춰 있음

`failurePolicy: Ignore` 사용