구성 동기화 문제 해결

이 페이지에서는 구성 동기화 관련 문제를 해결하는 방법을 보여줍니다.

구성 동기화 환경이 항상 작동할 수 있도록 노력하고 있지만 설정 문제 해결이 필요한 상황이 발생할 수 있습니다. 이 가이드에서는 발생한 문제를 해결하는 데 도움이 될 수 있는 몇 가지 일반적인 메커니즘을 설명합니다.

일반 권장사항

구성 동기화 상태 보기

nomos status 명령어는 구성 동기화 설치에서 발생하는 상황을 이해할 수 있도록 수집된 데이터 및 오류 정보를 제공합니다. 다음 정보는 nomos status로 제공됩니다.

클러스터당 설치 상태
동기화 오류(Git에서 읽기 및 변경사항 조정 모두)

nomos status를 사용하려면 nomos 명령어를 설치합니다.

gcloud alpha anthos config sync repo 명령어 또는 구성 동기화 대시보드를 사용하여 저장소별로 구성 동기화 상태를 확인할 수도 있습니다.

서비스 수준 지표(SLI) 사용

구성 동기화가 의도한 대로 작동하지 않을 때 알림을 받으려면 구성 동기화 SLI에 따라 Prometheus 알림 규칙을 설정합니다. 자세한 내용은 구성 동기화 SLI 사용을 참조하세요.

kubectl을 사용하여 리소스 검사

구성 동기화는 kubectl 명령어를 사용해서 쿼리할 수 있는 여러 커스텀 리소스로 구성됩니다. 이러한 명령어는 각 구성 동기화 객체의 상태를 이해하는 데 도움이 됩니다.

구성 동기화가 관리하는 Kubernetes 리소스에 대한 다음 정보를 확인합니다.

config-management-system은 구성 동기화의 모든 핵심 시스템 구성요소를 실행하는 데 사용하는 네임스페이스입니다.
configmanagement.gke.io/v1 및 configsync.gke.io는 모든 커스텀 리소스에 사용하는 버전 프리픽스입니다.

다음 명령어를 실행하여 커스텀 리소스의 전체 목록을 가져올 수 있습니다.

kubectl api-resources | grep -E "configmanagement.gke.io|configsync.gke.io"

kubectl get RESOURCE -o yaml을 실행하여 개별 커스텀 리소스를 사용할 수 있습니다.

예를 들어 다음 명령어의 출력에 따라 RootSync 객체 상태를 확인할 수 있습니다.

kubectl get rootsync -n config-management-system -o yaml

또한 gcloud alpha anthos config sync resources 명령어 또는 구성 동기화 대시보드를 사용하여 구성 동기화가 관리하는 리소스를 볼 수 있습니다.

RootSync 및 RepoSync 객체 살펴보기

kubectl을 사용하여 구성 동기화를 설치할 때는 루트 저장소 구성에 대한 세부정보가 포함된 RootSync 객체를 만듭니다. Google Cloud Console 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치하면 구성 동기화에서 RootSync 객체가 자동으로 생성됩니다. 다중 저장소에서 동기화 구성을 수행할 때는 네임스페이스 저장소에 대한 구성 정보가 포함된 RepoSync 객체가 생성됩니다.

이러한 객체를 탐색하면 구성 동기화 상태에 대한 중요한 정보를 확인할 수 있습니다. 자세한 내용은 RootSync 및 RepoSync 객체 모니터링을 참조하세요.

감사 로그 사용

감사 로그는 유용한 디버깅 도구입니다.

Google Cloud Console 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치한 경우 다음 단계에 따라 감사 로그를 사용하여 구성 동기화를 조사합니다.

Console

GKE Connect/Hub API 감사 로그를 사용 설정합니다.
1. Google Cloud Console에서 IAM 감사 로그 페이지로 이동합니다.
  
  감사 로그 페이지로 이동
2. 표에서 GKE Connect/Hub API 체크박스를 선택합니다.
3. 다음 체크박스를 선택합니다.
  - 관리자 읽기
  - 데이터 읽기
  - 데이터 쓰기
4. 저장을 클릭합니다.
로그 탐색기 페이지로 이동합니다.

로그 탐색기 페이지로 이동

쿼리 빌더 텍스트 상자에 다음 필터를 추가합니다.

resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"

쿼리 실행을 클릭합니다.
쿼리 결과 섹션에서 이벤트에 대해 자세히 알아볼 항목을 선택합니다.

일반적인 문제 해결

FailedScheduling 이벤트

kubectl get events의 출력에는 FailedScheduling 유형의 이벤트가 포함될 수 있습니다. 이 이벤트는 다음 예시와 비슷하게 표시됩니다.

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

이 이벤트는 노드에 CPU 또는 메모리가 부족할 때와 같이 노드에서 포드를 예약할 수 없기 때문에 발생할 수 있습니다. 이 오류를 해결하려면 다음 옵션 중 하나를 선택합니다.

기존 GKE 노드 풀에 노드 추가
더 큰 노드로 노드 풀 만들기

유효하지만 잘못된 ConfigManagement 객체

kubectl 명령어를 사용해서 구성 동기화를 설치하고 YAML 또는 JSON 구문 오류에 기인하지 않는 ConfigManagement 객체 관련 문제로 인해 설치가 실패하면 클러스터에서 객체가 인스턴스화되더라도 올바르게 작동하지 않을 수 있습니다. 이 경우 nomos status 명령어를 사용하여 객체의 오류를 확인할 수 있습니다.

문제가 없는 유효한 설치 상태는 PENDING 또는 SYNCED입니다.

유효하지 않은 설치 상태는 NOT CONFIGURED이며, 다음 오류 중 하나가 표시됩니다.

missing git-creds Secret
missing required syncRepo field
git-creds Secret is missing the key specified by secretType

문제를 해결하려면 구성 오류를 수정합니다. 오류 유형에 따라 ConfigManagement 매니페스트를 클러스터에 다시 적용해야 할 수도 있습니다.

git-creds 보안 비밀을 만드는 것을 잊어버린 경우에는 구성 동기화가 보안 비밀을 생성하는 즉시 이를 감지하므로 구성을 다시 적용할 필요가 없습니다.

ResourceGroup 필드가 계속 변경됨

클러스터에 동기화된 각 Git 저장소의 경우 모든 리소스의 조정 상태가 ResourceGroup이라는 리소스에 집계됩니다. 각 RootSync 또는 RepoSync 객체에 대해 클러스터에 적용된 리소스 집합을 캡처하고 해당 상태를 수집하기 위해 ResourceGroup이 생성됩니다.

경우에 따라 ResourceGroup이 ResourceGroup의 spec을 계속 업데이트하는 루프에 들어갈 수 있습니다. 이 경우 다음 문제를 발견할 수 있습니다.

ResourceGroup의 metadata.generation이 짧은 기간 내에 계속 증가합니다.
ResourceGroup spec이 계속 변경됩니다.
ResourceGroup spec에 클러스터에 동기화되는 리소스의 status.resourceStatuses가 포함되지 않습니다.

이 문제가 발견되면 Git 저장소의 일부 리소스가 클러스터에 적용되지 않았음을 의미합니다. 이 문제의 원인은 이러한 리소스를 적용하기 위해 필요한 권한이 없기 때문입니다.

RepoSync 리소스 상태를 가져와서 권한이 누락되었는지 확인할 수 있습니다.

kubectl get reposync repo-sync -n NAMESPACE -o yaml

NAMESPACE를 네임스페이스 저장소를 만든 네임스페이스로 바꿉니다.

nomos status을 사용할 수도 있습니다.

상태에 다음 메시지가 표시되면 NAMESPACE의 조정자가 리소스를 적용하는 데 필요한 권한이 없는 것입니다.

errors:
  - code: "2009"
    errorMessage: |-
      KNV2009: deployments.apps "nginx-deployment" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler-     default" cannot get resource "deployments" in API group "apps" in the namespace "default"

      For more information, see https://g.co/cloud/acm-errors#knv2009

이 문제를 해결하려면 해당 네임스페이스에서 실패한 리소스를 관리하기 위해 ns-reconciler-NAMESPACE 서비스 계정에 권한을 부여하는 RoleBinding 구성을 선언해야 합니다. RoleBinding 추가 방법에 대한 자세한 내용은 다중 저장소에서 동기화 구성에 포함되어 있습니다.

Git 저장소에 있는 대량의 리소스

RepoSync 또는 RootSync 객체로 클러스터에 동기화된 Git 저장소에 수천 개 이상의 리소스 구성이 포함된 경우 ResourceGroup의 etcd 객체 크기 제한이 초과될 수 있습니다. 이 경우 Git 저장소에서 리소스의 집계 상태를 확인할 수 없습니다. 집계 상태를 볼 수 없지만 저장소는 계속 동기화될 수 있습니다.

RootSync, RepoSync 객체, 조정자 로그에서 다음 오류가 표시되면 ResourceGroup 리소스가 etcd 객체 크기 한도를 초과하는 것입니다.

KNV2009: etcdserver: request is too large

이 문제를 해결하려면 Git 저장소를 여러 저장소로 분할하는 것이 좋습니다. 자세한 내용은 저장소를 여러 저장소로 분할을 참조하세요.

Git 저장소를 분할할 수 없으면 구성 동기화 v1.11.0 이상에서 상태 데이터 표시를 사용 중지하여 문제를 완화할 수 있습니다. RootSync 또는 RepoSync 객체의 .spec.override.statusMode 필드를 disabled로 설정하여 이를 수행할 수 있습니다. 이렇게 하면 구성 동기화가 ResourceGroup 객체에서 관리형 리소스 상태 업데이트를 중지합니다. ResourceGroup 객체 크기를 줄입니다. 하지만 더 이상 nomos status 또는 gcloud alpha anthos config sync에서 관리형 리소스 상태를 볼 수 없습니다.

Google Cloud console 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치한 경우 spec.override.statusMode를 설정할 수 있도록 수정 가능한 RootSync 객체를 만듭니다. 자세한 내용은 kubectl 명령어로 구성 동기화 구성을 참조하세요.

RootSync 또는 RepoSync 객체에서 오류가 표시되지 않으면 Git 저장소가 클러스터에 동기화된 것입니다. ResourceGroup 리소스가 etcd 객체 크기 제한을 초과하는지 확인하려면 ResourceGroup 리소스 상태와 ResourceGroup 컨트롤러의 로그를 모두 확인합니다.

ResourceGroup 상태를 확인합니다.
- RootSync 객체를 확인하려면 다음 명령어를 실행합니다.
```
 kubectl get resourcegroup.kpt.dev root-sync -n config-management-system
```
- RepoSync 객체를 확인하려면 다음 명령어를 실행합니다.
```
kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE
```
출력은 다음 예시와 비슷합니다.
```
NAME        RECONCILING   STALLED   AGE
root-sync   True          False     35m
```
RECONCILING 열의 값이 True이면 ResourceGroup 리소스가 계속 조정 중인 것입니다.
ResourceGroup 컨트롤러의 로그를 확인합니다.
```
kubectl logs deployment/resource-group-controller-manager -c manager -n resource-group-system
```
출력에 다음 오류가 표시되면 ResourceGroup 리소스가 너무 크고 etcd 객체 크기 제한을 초과하는 것입니다.
```
"error":"etcdserver: request is too large"
```

ResourceGroup이 너무 커지지 않도록 방지하려면 Git 저장소에서 리소스 수를 줄입니다. 안내에 따라 하나의 루트 저장소를 여러 루트 저장소로 분할할 수 있습니다.

Git 저장소에서 동기화 해제

새 커밋이 Git 저장소로 푸시되지만 클러스터의 구성 동기화 상태가 오랫동안 기존 커밋에 대해 Synced 상태이면(spec.git.period 이상) 다음을 수행해야 합니다. git-sync 컨테이너의 로그를 확인합니다.

# check git-sync logs for a root reconciler
kubectl logs -n config-management-system deployment/root-reconciler -c git-sync

# check git-sync logs for a namespace reconciler
kubectl logs -n config-management-system deployment/ns-reconciler-NAMESPACE -c git-sync

git-sync가 Git 저장소에서 동기화되지 않을 수 있지만 조정자가 이전에 동기화된 커밋에서 동기화를 계속합니다. 다음 예시 출력은 git-sync 문제가 있음을 보여줍니다.

"msg"="unexpected error syncing repo, will retry" "error"="Run(git fetch -f
--tags --depth 1 origin develop): exit status 128: { stdout: "", stderr: "fatal:
couldn't find remote ref develop\n" }"

삭제된 RootSync/RepoSync에서 관리되던 리소스 업데이트/삭제 요청이 웹훅에서 거부됨

RootSync 또는 RepoSync 객체를 삭제해도 구성 동기화 주석 및 라벨이 삭제되지 않습니다. 그리고 구성 동기화가 클러스터에 여전히 사용 설정된 상태이면 구성 동기화 허용 웹훅이 이러한 리소스의 수정 또는 삭제를 시도하는 요청을 거부합니다.

이러한 관리되는 리소스를 유지하려는 경우 Git 저장소에 선언된 모든 관리되는 리소스에서 configmanagement.gke.io/managed 주석을 disabled로 설정하여 먼저 이러한 리소스를 관리 해제할 수 있습니다. 그러면 Config Sync 주석 및 라벨이 관리되는 리소스에서 삭제되지만 해당 리소스가 삭제되지는 않습니다. 동기화가 완료되었으면 RootSync 또는 RepoSync 객체를 삭제할 수 있습니다.

이러한 관리되는 리소스를 삭제하려는 경우에는 비어 있는 Git 디렉터리에서 동기화되도록 RootSync 또는 RepoSync 객체를 수정하여 먼저 관리되는 리소스를 삭제할 수 있습니다. 동기화가 완료되었으면 RootSync 또는 RepoSync 객체를 삭제할 수 있습니다.

관리되는 리소스를 관리 해제하거나 삭제하기 전에 RootSync 또는 RepoSync 객체가 삭제된 경우 RootSync 또는 RepoSync 객체를 다시 추가하고, 관리되는 리소스를 관리 해제 또는 삭제한 후 RootSync 또는 RepoSync 객체를 다시 삭제할 수 있습니다.

수평형 포드 자동 확장이 작동하지 않음

구성 동기화는 사용자가 Git 저장소의 매니페스트에서 지정한 모든 필드를 관리합니다. 두 컨트롤러가 동일한 필드를 제어하려고 하는 리소스 경합이 발생할 수 있습니다. 이러한 리소스 경합은 구성 동기화에서 수평형 포드 자동 확장을 사용하려고 할 때 발생합니다.

수평형 포드 자동 확장을 사용하려면 Git 저장소의 모든 매니페스트에서 해당 필드를 삭제하여 수평형 포드 자동 확장 처리에서 spec.replicas 필드를 관리하도록 해야 합니다. 그렇지 않으면 구성 동기화가 변경사항을 저장소에 지정된 항목으로 되돌리려고 시도합니다.

PersistentVolumeClaim이 손실됨 상태임

Kubernetes 클러스터를 버전 1.22 이상으로 업그레이드할 때는 관리되는 PersistentVolumeClaims로 인해 Lost 상태가 발생할 수 있습니다. 이러한 경우는 PersistentVolumes 및 PersistentVolumeClaims 바인딩이 PersistentVolume 리소스 내에서 claimRef 필드를 사용하여 정의되었을 때 발생합니다. 업스트림 Kubernetes 변경사항으로 인해 claimRef 필드가 원자적으로 되어 서버 측 적용을 사용할 때 서로 다른 claimRef 하위 필드에 대한 서로 다른 필드 소유자를 방지하므로 이 버그가 발생합니다.

업스트림 Kubernetes(GitHub Issue Tracker, 버그 수정 PR)에서 이 문제가 해결될 때까지 대체 바인딩 방법을 사용하도록 PersistentVolume 및 PersistentVolumeClaim 리소스를 업데이트하는 것이 좋습니다. 대신 PersistentVolumeClaim 리소스의 spec.volumeName 내에 바인딩을 설정할 수 있습니다. 이 작업은 1.22로 업그레이드할 때 중단을 방지하기 위해 Kubernetes 버전 1.21 이하에서 수행할 수 있습니다.

다음은 staging-pv로 staging-pvc를 바인딩하는 최소 예시입니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: staging-pvc
  namespace: staging
spec:
  volumeName: staging-pv
  ...

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: staging-pv
spec:
  ...

바인딩에 claimRef 대신 volumeName을 사용하면 PersistentVolume에 대한 어떠한 바인딩 권한도 보증하지 않습니다.

오류 메시지 문제 해결하기

KNV1045: 상태가 지정된 구성은 허용되지 않음

소스 저장소에 status 필드를 지정하면 KNV1045: '상태'가 지정된 구성은 허용되지 않음이 표시됩니다. 구성 동기화를 사용하여 status 필드를 동기화할 수 없습니다. 다른 컨트롤러는 클러스터의 status 필드를 동적으로 관리하고 업데이트해야 합니다. 구성 동기화는 status 필드의 원하는 상태를 제어하려고 하면 status 필드 관리를 담당하는 컨트롤러와 싸우게 됩니다.

이 오류를 해결하려면 소스 저장소에서 status 필드를 삭제합니다. 소유하지 않은 타사 구성의 경우 kustomize 패치를 사용하여 매니페스트에 지정된 status 필드를 대량으로 삭제합니다.

KNV2004: git-sync 컨테이너의 저장소 오류 동기화 실패

구성 동기화는 Git 저장소의 부분 클론을 만듭니다. 일부 드문 경우에는 구성 동기화가 부분 클론에서 커밋을 찾지 못할 수 있습니다. 이 경우 구성 동기화는 인출할 Git 커밋 수를 늘립니다.

RootSync 또는 RepoSync 객체에서 spec.override.gitSyncDepth 필드를 설정하여 가져올 Git 커밋 수를 설정할 수 있습니다.

이 필드를 제공하지 않으면 구성 동기화가 이를 자동으로 구성합니다.
구성 동기화는 이 필드가 0일 때 전체 클론을 수행하고 이 필드가 0보다 크면 부분 클론을 수행합니다.
이 필드를 음수로 설정하는 것은 허용되지 않습니다.

Google Cloud console 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치한 경우 spec.override.gitSyncDepth를 설정할 수 있도록 수정 가능한 RootSync 객체를 만듭니다. 자세한 내용은 kubectl 명령어로 구성 동기화 구성을 참조하세요.

다음은 가져올 Git 커밋 수를 88로 설정하는 예시입니다.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  override:
    gitSyncDepth: 88
  git:
    ...

다음 명령어를 실행하여 변경사항이 적용되는지 확인합니다(root-reconciler-git-sync ConfigMap의 data 필드에서 GIT_SYNC_DEPTH를 88로 설정해야 함).

kubectl get cm root-reconciler-git-sync -n config-management-system -o yaml

마찬가지로 네임스페이스 조정자에서 가져올 Git 커밋의 수를 재정의할 수 있습니다.

오류: 권한 거부됨

구성 동기화를 구성하려고 시도할 때 다음 예시와 비슷한 오류가 수신되면 GKE Hub 관리자 역할이 없기 때문일 수 있습니다.

Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'

필요한 권한이 있는지 확인하려면 필요한 IAM 역할이 부여되었는지 확인합니다.

오류: 허용 웹훅이 요청을 거부함

구성 동기화에서 관리되는 필드에 변경사항을 적용하려고 시도할 때 다음 오류가 표시되면 변경사항 충돌이 발생했기 때문일 수 있습니다.

error: OBJECT could not be patched: admission webhook "v1.admission-webhook.configsync.gke.io"
denied the request: fields managed by Config Sync can not be modified

구성에서 필드를 선언하고 저장소가 클러스터에 동기화되면 구성 동기화가 해당 필드를 관리합니다. 이 필드에 시도하는 모든 변경사항이 충돌하는 변경사항입니다.

예를 들어 저장소에 environment:prod 라벨이 포함된 배포 구성이 있고 클러스터에서 라벨을 environment:dev로 변경하려고 시도하면 변경사항이 충돌하고 위의 오류 메시지가 표시됩니다. 하지만 배포에 tier:frontend와 같은 새 라벨을 추가하는 것은 충돌이 되지 않습니다.

구성 동기화가 객체에 대한 모든 변경사항을 무시하도록 하려면 객체 변형 무시에 설명된 주석을 추가할 수 있습니다.

오류: 허용 웹훅 요청 I/O 시간 초과

조정자가 클러스터에 구성 적용을 시도할 때 다음 오류가 수신되면 방화벽에 따라 제어 영역 네트워크에 대해 허용 웹훅 포트 8676이 차단되었기 때문일 수 있습니다.

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout

이 문제를 해결하려면 방화벽 규칙을 추가하여 구성 동기화 허용 웹훅이 드리프트 방지에 사용하는 포트 8676를 허용합니다.

오류: 허용 웹훅 연결이 거부됨

조정자가 클러스터에 구성을 적용하려고 할 때 다음 오류가 수신되면 허용 웹훅이 아직 준비되지 않은 것입니다.

KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused

구성 동기화를 부트스트랩할 때 발생할 수 있는 일시적인 오류입니다. 문제가 지속되면 허용 웹훅 배포를 살펴보고 pod가 예약될 수 있고 정상 상태인지 확인합니다.

kubectl describe deploy admission-webhook -n config-management-system

kubectl get pods -n config-management-system -l app=admission-webhook

오류: Git 보안 비밀을 마운트할 수 없음

git-sync가 보안 비밀을 사용해서 저장소를 동기화하려고 시도할 때 다음 오류가 수신되면 Git 보안 비밀이 git-sync 컨테이너에 성공적으로 마운트되지 않은 것입니다.

KNV2004: unable to sync repo Error in the git-sync container: ERROR: can't configure SSH: can't access SSH key: stat /etc/git-secret/ssh: no such file or directory: lstat /repo/root/rev: no such file or directory

이 오류는 Git 저장소 인증 유형을 none, gcenode, gcpserviceaccount에서 보안 비밀이 필요한 다른 유형으로 전환할 때 발생할 수 있습니다.

이 문제를 해결하려면 다음 명령어를 실행하여 조정자 관리자 및 조정자를 다시 시작합니다.

# Stop the reconciler-manager Pod. The reconciler-manager Deployment will spin
# up a new Pod which can pick up the latest `spec.git.auth`.
kubectl delete po -l app=reconciler-manager -n config-management-system

# Delete the reconciler Deployments. The reconciler-manager will recreate the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system

오류: 공개 저장소에서 원격 기반을 가져올 수 없음

렌더링 프로세스 중에 다음 오류가 발생하는 경우 공개 저장소에서 원격 기반을 가져오려고 하면 렌더링 프로세스가 성공적으로 완료되지 않은 것입니다.

KNV1068: failed to run kustomize build in /repo/source/0a7fd88d6c66362584131f9dfd024024352916af/remote-base, stdout:...
no 'git' program on path: exec: "git": executable file not found in $PATH

For more information, see https://g.co/cloud/acm-errors#knv1068

이 문제를 해결하려면 spec.override.enableShellInRendering를 true로 설정합니다.

reconciler 포드의 컨테이너가 OOMKilled됨

루트 또는 네임스페이스 저장소의 CPU 또는 메모리 요청 및 제한을 재정의할 수 있습니다. 이러한 값을 재정하려면 RootSync 또는 RepoSync 객체의 spec.override.resources 필드를 사용합니다. Google Cloud console 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치한 경우 spec.override.resources를 설정할 수 있도록 수정 가능한 RootSync 객체를 만듭니다. 자세한 내용은 kubectl 명령어로 구성 동기화 구성을 참조하세요.

다음 예시에서는 reconciler 컨테이너의 CPU 및 메모리 한도와 루트 조정자의 git-sync 컨테이너의 CPU 요청 및 메모리 한도를 재정의하는 방법을 보여줍니다. git-sync, oci-sync, helm-sync, hydration-controller, reconciler 컨테이너를 재정의하는 것은 허용됩니다. 부분 재정의가 허용되며, 리소스 요청 또는 한도에 대한 재정의 값이 제공되지 않았으면 요청 또는 한도의 기본 리소스 값이 사용됩니다.

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: "unstructured"
  override:
    resources:
    - containerName: "reconciler"
      cpuLimit: "800m"
      memoryLimit: "500Mi"
    - containerName: "git-sync"
      cpuRequest: "100m"
      memoryLimit: "400Mi"
  git:
     ...

다음 명령어를 실행하여 새 리소스 한도가 적용되는지 확인합니다.

kubectl get deployment.apps/root-reconciler -n config-management-system -o yaml

네임스페이스 조정자의 리소스 한도도 이와 비슷하게 재정의할 수 있습니다.

오류: 네임스페이스가 `Terminating` 단계에서 멈춤

Terminating 단계에서 멈추는 네임스페이스는 다음 조건을 갖습니다.

    message: 'Failed to delete all resource types, 1 remaining: admission webhook
      "v1.admission-webhook.configsync.gke.io" denied the request: system:serviceaccount:kube-system:namespace-controller
      is not authorized to delete managed resource "_configmap_bookstore_cm1"'
    reason: ContentDeletionFailed
    status: "True"
    type: NamespaceDeletionContentFailure

이 오류는 루트 저장소에서 네임스페이스를 삭제하려고 시도하지만 네임스페이스 아래의 일부 객체가 네임스페이스 조정자에서 여전히 관리되고 있는 경우에 발생합니다. 네임스페이스가 삭제되면 해당 서비스 계정이 system:serviceaccount:kube-system:namespace-controller인 네임스페이스 컨트롤러가 해당 네임스페이스에서 모든 객체를 삭제하려고 시도합니다. 하지만 구성 동기화 허용 웹훅은 루트 또는 네임스페이스 조정자만 이러한 객체를 삭제하도록 허용하고, 네임스페이스 컨트롤러가 이러한 객체를 삭제하는 것은 거부합니다.

해결 방법은 구성 동기화 허용 웹훅을 삭제하는 것입니다.

kubectl delete deployment.apps/admission-webhook -n config-management-system

Config Management Operator는 구성 동기화 허용 웹훅을 다시 만듭니다.

이 방법이 작동하지 않으면 구성 동기화를 다시 설치해야 합니다.

오류가 다시 발생하지 않도록 하려면 네임스페이스를 삭제하기 전에 네임스페이스 저장소를 삭제합니다.

오류: ValidatingWebhookConfiguration에서 `webhooks` 필드를 찾을 수 없음

kubectl logs -n config-management-system -l app=admission-webhook 실행 시 구성 동기화 허용 웹훅 로그에서 다음 오류가 발생하는 경우 다음을 참조하세요.

cert-rotation "msg"="Unable to inject cert to webhook." "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "gvk"={"Group":"admissionregistration.k8s.io","Version":"v1","Kind":"ValidatingWebhookConfiguration"} "name"="admission-webhook.configsync.gke.io"
controller-runtime/manager/controller/cert-rotator "msg"="Reconciler error" "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "name"="admission-webhook-cert" "namespace"="config-management-system"

이는 root-reconciler가 클러스터에 리소스를 동기화하지 않았음을 의미합니다. 이는 root-reconciler가 아직 준비되지 않았거나 Git 저장소에서 동기화할 항목이 없기 때문일 수 있습니다(예: 동기화 디렉터리가 비어 있음). 문제가 계속되면 root-reconciler의 상태를 확인해야 합니다.

kubectl get pods -n config-management-system -l configsync.gke.io/reconciler=root-reconciler

root-reconciler가 비정상 종료되거나 OOMKilled 오류가 발생하면 리소스 한도를 늘립니다.

오류: Stackdriver/GoogleCloud 내보내기를 만들 수 없음

Open Telemetry Collector의 구성요소가 동일한 네임스페이스에서 기본 서비스 계정에 액세스할 수 없는 경우 config-management-monitoring 아래의 otel-collector 포드가 CrashLoopBackoff 상태임을 알 수 있거나 다음 예시와 유사한 오류 메시지가 표시될 수 있습니다.

Error: cannot build exporters: error creating stackdriver exporter: cannot configure Google Cloud metric exporter: stackdriver: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

이 문제는 일반적으로 클러스터에서 워크로드 아이덴티티가 사용 설정되면 발생합니다.

이 문제를 해결하려면 구성 동기화 모니터링의 안내에 따라 기본 서비스 계정에 측정항목 쓰기 권한을 부여합니다.

IAM 설정 후 오류가 계속되면 변경사항을 적용하기 위해 otel-collector 포드를 다시 시작합니다.

오류: 서버 인증서 확인 실패

git-sync 컨테이너가 Git 저장소를 클론하지 못하고 다음 오류 메시지 server certificate verification failed. CAfile: /etc/ca-cert/cert CRLfile: none이 표시되면 Git 서버가 커스텀 인증 기관(CA)의 인증서로 구성되었음을 나타냅니다. 그러나 커스텀 CA가 올바르게 구성되지 않아 git-sync 컨테이너가 Git 저장소를 클론하지 못합니다.

먼저 RootSync 또는 RepoSync 객체에 spec.git.caCertSecretRef.name 필드가 지정되었는지 확인하고 보안 비밀 객체가 존재하는지도 확인할 수 있습니다.

필드가 구성되었고 보안 비밀 객체가 있는 경우 보안 비밀 객체에 전체 인증서가 포함되어 있는지 확인합니다.

커스텀 CA는 프로비저닝 방법에 따라 전체 인증서를 확인하는 방법이 달라질 수 있습니다.

다음은 서버 인증서를 나열하는 방법의 예시입니다.

echo -n | openssl s_client -showcerts -connect HOST:PORT -servername SERVER_NAME 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

네트워크 관리팀에 CA 인증서를 가져오도록 요청할 수 있습니다.