구성 동기화의 알려진 문제

이 페이지에는 지원되는 구성 동기화 버전의 알려진 문제가 나와 있습니다.

여기에 나열된 문제 중 상당수가 해결되었습니다. 수정된 버전 열은 수정사항이 도입된 버전을 나타냅니다. 이 수정사항을 적용하려면 나열된 버전 이상으로 업그레이드합니다.

Google Developer Program에 참여하는 경우 이 페이지를 저장하여 이 페이지와 관련된 출시 노트가 게시될 때 알림을 받으세요. 자세한 내용은 저장된 페이지를 참고하세요.

제품 버전이나 문제 카테고리별로 알려진 문제를 필터링하려면 다음 드롭다운 메뉴에서 필터를 선택하세요.

구성 동기화 버전을 선택합니다.

문제 카테고리를 선택하세요.

또는 알려진 문제를 필터링합니다.

카테고리 식별된 버전 수정된 버전 문제 및 해결 방법
측정항목 1.5.0 1.21.0

해결됨: 삭제된 패키지에 대해 보고된 측정항목

RootSync 또는 RepoSync 객체를 삭제했지만 이름이 같은 ResourceGroup 객체를 삭제하지 않으면 구성 동기화는 다음과 같은 해당 ResourceGroup 객체의 측정항목을 계속 보고합니다.

  • rg_reconcile_duration_seconds
  • resource_group_total
  • resource_count
  • ready_resource_count
  • resource_ns_count
  • cluster_scoped_resource_count
  • crd_count
  • kcc_resource_count
  • pipeline_error_observed
ResourceGroup 객체는 RootSync 또는 RepoSync 객체가 삭제되기 전에 삭제 전파를 사용 설정한 경우에만 자동으로 삭제됩니다.

해결 방법:

ResourceGroup 객체를 삭제합니다.

kubectl delete resourcegroup RESOURCE_GROUP_NAME -n config-management-system

RESOURCE_GROUP_NAME을 삭제해야 하는 ResourceGroup 객체의 이름으로 바꿉니다. ResourceGroup 이름 지정에 대한 자세한 내용은 ResourceGroup 컨트롤러 및 ResourceGroup 객체를 참조하세요.

구성요소 상태 1.15.0

조정자 예약할 수 없음

구성 동기화 조정자는 RootSync 또는 RepoSync의 구성에 따라 다양한 양의 리소스가 필요합니다. 특정 구성에는 다른 구성보다 더 많은 리소스가 필요합니다.

조정자를 예약할 수 없는 경우 이는 노드에서 사용할 수 있는 리소스보다 더 많은 리소스를 요청했기 때문일 수 있습니다.

Standard 모드 GKE 클러스터를 사용하는 경우 조정자 리소스 요청이 매우 낮게 설정됩니다. 이 설정은 제한과 성능 저하가 발생하더라도 구성 동기화가 소규모 클러스터 및 소규모 노드에서 작동하도록 예약을 허용하기 위해 선택되었습니다. 하지만 GKE Autopilot 클러스터에서는 동기화 중 사용량을 보다 현실적으로 나타내기 위해 조정자 요청이 더 높게 설정됩니다.

해결 방법:

노드 자동 프로비저닝이 사용 설정된 GKE Autopilot 또는 GKE Standard는 요청된 리소스 수를 확인하고 예약을 허용하도록 적절한 크기의 노드를 만들 수 있어야 합니다. 하지만 노드나 노드 인스턴스 크기를 수동으로 구성하는 경우 조정자 포드 리소스 요구사항이 충족되도록 이러한 설정을 조정해야 할 수 있습니다.

측정항목 1.15.0

내보낼 수 없습니다. 권한 거부됨

기본적으로 reconciler-manager에서 애플리케이션 기본 사용자 인증 정보를 감지하면 otel-collector는 Prometheus, Cloud Monitoring, Monarch에 측정항목을 내보내도록 구성됩니다.

해결 방법:

otel-collectorCloud Monitoring을 구성하거나 측정항목 필터를 맞춤설정하고 Cloud Monarch를 사용하지 않은 경우 오류를 로깅합니다.

측정항목 1.15.0

커스텀 구성과 함께 otel-collector가 비정상 종료됨

기본 ConfigMap인 otel-collector 또는 otel-collector-google-cloud 중 하나를 수정하거나 삭제하려고 하면 필요한 ConfigMap을 로드할 수 없어 otel-collector에서 오류가 발생하거나 otel-collector가 비정상 종료될 수 있습니다.

해결 방법:

측정항목 내보내기 구성을 맞춤설정하려면 config-management-monitoring 네임스페이스에 otel-collector-custom이라는 ConfigMap을 만듭니다.

해결

자체적으로 싸우는 구성 동기화

구성 동기화가 자체적인 컨트롤러 경합을 하는 것으로 보일 수 있습니다. 이 문제는 Git 저장소에서 리소스의 선택적 필드에 대한 기본값을 설정하는 경우에 발생합니다. 예를 들어 RoleBinding의 주제에 대한 apiGroup: ""을 설정하면 apiGroup 필드는 선택사항이고 빈 문자열이 기본값이기 때문에 이 문제가 트리거됩니다. 문자열, 부울, 정수 필드의 기본값은 각각 "", false, 0입니다.

해결 방법:

리소스 선언에서 필드를 삭제합니다.

해결

구성 커넥터 리소스와 싸우는 구성 동기화

구성 동기화는 StorageBucket과 같은 리소스를 두고 구성 커넥터와 경합하는 것으로 보일 수 있습니다. 이 문제는 정보 소스에서 리소스 spec.lifecycleRule.condition.withState의 선택적 필드 값을 설정하지 않는 경우에 발생합니다.

해결 방법:

리소스 선언에 withState=ANY 필드를 추가하면 이 문제를 방지할 수 있습니다. 또는 cnrm.cloud.google.com/state-into-spec: absent 주석이 있는 리소스를 폐기한 후 다시 획득하면 됩니다.

정보 소스 1.13.0 1.20.1

해결됨: OCI 소스에 대한 액세스 토큰을 생성할 수 없음

구성 동기화가 OCI를 정보 소스로 사용하고 GKE용 워크로드 아이덴티티 제휴로 인증하도록 구성된 경우 컨테이너 레지스트리로 인증하려고 하면 임시 KNV2004 오류가 발생할 수도 있습니다.

이 문제는 oauth2 라이브러리에서 토큰이 이미 만료된 후에만 인증 토큰을 새로고침하기 때문에 발생합니다.

오류 메시지에 "oauth2/google: unable to generate access token" 또는 "ID Token issued at (xxx) is stale to sign-in." 텍스트가 포함될 수 있습니다.

해결 방법:

구성 동기화가 다음에 정보 소스에서 가져오려고 할 때 오류가 자동으로 해결됩니다.

구성 동기화에 오류가 여러 번 발생하면 재시도 횟수가 점점 줄어듭니다. 구성 동기화가 더 빨리 재시도하게 하려면 조정자 포드를 삭제합니다. 이 작업을 실행하면 구성 동기화가 조정자 포드를 다시 만들고 정보 소스에서 즉시 가져옵니다.

    kubectl delete pod -n config-management-system RECONCILER_NAME
    
RECONCILER_NAME을 RootSync 또는 RepoSync 객체의 조정자 이름으로 바꿉니다.
정보 소스 1.20.0 1.21.3

Git 잠금 파일이 분리된 후 git-sync 컨테이너가 반복적으로 비정상 종료

git-sync 컨테이너 로그에 다음과 유사한 오류가 표시되면서 git-sync 컨테이너가 반복적으로 비정상 종료되는 경우 이전 git 호출이 실패하여 컨테이너에 분리된 잠금 파일이 남아 있을 수 있습니다.

    {"logger":""..."msg":"repo contains lock file","error":null,"path":"/repo/source/.git/shallow.lock"}
    ...runtime error: invalid memory address or nil pointer dereference
    

해결 방법:

이 문제를 해결하려면 영향을 받는 조정자 포드를 다시 시작하여 새 임시 볼륨을 제공합니다.

    kubectl delete pod -n config-management-system RECONCILER_NAME
    
RECONCILER_NAME을 RootSync 또는 RepoSync 객체의 조정자 이름으로 바꿉니다.
정보 소스 1.19.0 1.20.0

해결됨: 남아 있는 Git 잠금 파일

git-sync 컨테이너에서 다음과 유사한 오류가 발생하면 이전 git 호출이 실패하고 컨테이너에 잠금 파일이 남아 있을 수 있습니다.

    KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...
    

해결 방법:

이 문제를 해결하려면 영향을 받는 조정자 포드를 다시 시작하여 새 임시 볼륨을 제공합니다.

    kubectl delete pod -n config-management-system RECONCILER_NAME
    
RECONCILER_NAME을 RootSync 또는 RepoSync 객체의 조정자 이름으로 바꿉니다.
동기화 중 1.7.0 1.21.0

해결됨: 무시 변형 주석이 적용되지 않음

구성 동기화 조정기의 버그로 인해 client.lifecycle.config.k8s.io/mutation 주석이 있는 경우에도 선언된 구성의 변경사항이 적용됩니다. 이로 인해 클러스터의 객체 상태를 덮어쓸 수 있습니다.

해결 방법:

configmanagement.gke.io/managed: disabled 주석을 추가하여 관리형 객체 관리를 중지하면 됩니다. 그러나 관리를 사용 중지하면 객체가 클러스터에서 삭제될 경우 구성 동기화에서 객체를 다시 만들지 않습니다. 또한 정보 소스의 추가 업데이트가 적용되지 않습니다.

동기화 중 1.5.0 1.20.1

해결됨: API 검색 오류로 인해 관리 객체가 Not Found로 잘못 표시될 수 있음

API 서비스 백엔드가 비정상적인 경우 API 검색에서 오류가 발생할 수 있습니다. ResourceGroup 컨트롤러가 시작되는 동안 업데이트 또는 일정 변경 후에 이 문제가 발생하면 리소스 캐시가 초기화되지 않아 모든 관리형 객체가 ResourceGroup 상태에서 Not Found로 보고됩니다.

이 문제는 metrics-server가 비정상일 때 자주 발생합니다.

해결 방법:

metrics-server가 다시 정상 상태가 되면 resource-group-controller 포드를 다시 시작합니다.

    kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME
    
RESOURCE_GROUP_CONTROLLER_NAME을 해당 패키지의 RootSync 또는 RepoSync 이름과 동일한 ResourceGroup 컨트롤러 이름으로 바꿉니다.
동기화 중 1.15.0

감사 로그에 비효율적인 PATCH 요청 수가 많음

구성 동기화 수정자는 시험 이전을 사용하여 드리프트를 감지합니다. 이로 인해 PATCH가 지속되지 않은 경우에도 PATCH 요청이 감사 로그에 표시될 수 있습니다. 감사 로그는 테스트 실행과 일반 요청을 구분하지 않기 때문입니다.

해결 방법:

감사 로그는 테스트 실행 요청과 테스트 실행 이외의 요청을 구분할 수 없으므로 PATCH 요청을 무시해도 됩니다.
비공개 레지스트리 1.19.0

구성 동기화가 조정자 배포에 비공개 레지스트리를 사용하지 않음

구성 동기화는 비공개 레지스트리가 구성된 경우 모든 배포의 이미지를 바꿉니다. 하지만 구성 동기화가 조정자 배포의 이미지에 대한 이미지 레지스트리를 대체하지 않습니다.

해결 방법:

이 문제를 해결하려면 containerd에서 이미지 레지스트리 미러를 구성하세요.

동기화 중 1.7.0 1.21.0

해결됨: 클러스터에 업데이트된 인벤토리를 쓸 수 없음

구성 동기화에서 ResourceGroup 객체 상태를 업데이트하지 못하면 조정자 로그에 다음과 유사한 간헐적 오류가 발생할 수 있습니다.

    KNV2009: task failed (action: "Inventory", name: "inventory-set-0"): failed to write updated inventory to cluster: Operation cannot be fulfilled on resourcegroups.kpt.dev "root-sync": the object has been modified; please apply your changes to the latest version and try again
    

이 오류는 조정자와 ResourceGroup 컨트롤러 간의 경합 상태로 인해 발생합니다. 조정자가 ResourceGroup 사양을 업데이트하기 전에 ResourceGroup 컨트롤러에서 ResourceGroup 상태를 업데이트하면 KNV2009 오류가 발생할 수 있습니다.

해결 방법:

이 문제를 해결할 방법은 없습니다. 오류가 자동으로 해결됩니다.

Terraform Terraform 버전 5.41.0

Terraform을 사용하여 구성 동기화를 설치하거나 업그레이드할 수 없음

Terraform 버전 5.41.0에서는 google_gke_hub_feature_membership 리소스에 새로운 필드 config_sync.enabled를 도입했습니다. 이 필드의 기본값은 false이므로 이 필드를 명시적으로 true로 설정하지 않으면 Terraform 버전 5.41.0 이상을 사용할 때 구성 동기화 설치나 업그레이드가 실패합니다. 이 문제가 발생하면 git spec not included in configmanagement spec 오류 메시지가 표시될 수도 있습니다.

해결 방법:

  • google_gke_hub_feature_membership 리소스를 사용하는 경우 config_sync.enabledtrue로 수동으로 설정합니다.
  • acm 하위 모듈을 사용하는 경우 구성 동기화를 설치하는 다른 방법으로 전환하는 것이 좋습니다. 전환할 수 없는 경우 v33.0.0으로 업그레이드하세요.

Google Cloud 콘솔

Google Cloud 콘솔의 구성 동기화 대시보드에 데이터 누락 오류 발생

Google Cloud 콘솔의 대시보드에 구성 동기화 클러스터에 대한 '데이터 누락' 또는 '잘못된 클러스터 사용자 인증 정보'와 같은 오류가 표시될 수 있습니다. 이 문제는 GDC(VMware) 또는 GDC(베어메탈) 클러스터에 로그인하지 않은 경우에 발생할 수 있습니다.

해결 방법:

GDC(VMware) 또는 GDC(베어메탈) 클러스터의 Google Cloud 콘솔에 이러한 유형의 오류가 표시되면 GKE Identity Service 또는 Connect Gateway를 사용하여 클러스터에 로그인했는지 확인합니다.

동기화 중 1.21.0

해결됨: 구성 동기화로 인해 폐기된 리소스가 업데이트되지 못함

1.21.0 이전 버전에는 삭제된 RootSync 또는 RepoSync 객체로 인해 구성 동기화에서 이러한 리소스 객체를 추적하는 데 사용하는 여러 라벨과 주석이 남을 수 있습니다.

이러한 라벨과 주석으로 인해 RootSync 또는 RepoSync 객체가 삭제된 후에 다음과 같은 부작용이 발생할 수 있습니다.

  • 다른 RepoSync 객체는 이전에 관리된 객체의 소유권을 가질 수 없습니다.
  • 드리프트 방지가 사용 설정되면 구성 동기화에서 폐기된 리소스에 대한 변경사항을 거부할 수 있습니다.

nomos 명령줄 도구 1.17.0

nomos CLI에서 oidc 인증 플러그인을 지원하지 않음

nomos 명령줄 도구를 사용할 때 no Auth Provider found for name "oidc"와 같은 오류가 표시될 수 있습니다. 이 문제는 oidc 인증 플러그인을 사용할 때 발생할 수 있습니다.

해결 방법:

해결 방법은 없습니다. oidc 인증 플러그인은 후속 출시 버전에서 다시 추가됩니다.

맨 위로

다음 단계

  • 문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.

    • Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
    • StackOverflow에서 질문하여 커뮤니티의 지원을 받습니다. kpt 또는 Kustomize를 사용하는 경우 kpt 또는 kustomize 태그를 사용하여 유사한 문제를 검색합니다.
    • GitHub의 공개 Issue Tracker를 사용하여 버그나 기능 요청을 엽니다.