이 페이지에서는 컨트롤러 싸움 관련 문제를 해결하는 방법을 보여줍니다. 이러한 싸움은 많은 양의 리소스를 소비하므로 성능이 저하될 수 있습니다. 컨트롤러 싸움을 리소스 경합이라고도 합니다.
구성 동기화는 클러스터에 적용된 객체를 감시하고 정보 소스에 선언된 값에 적용된 변경사항을 되돌립니다. 이러한 변경사항이 다른 컨트롤러에 의해 이루어지면 리소스가 경쟁 컨트롤러가 원하는 상태 사이에서 앞뒤로 전환될 수 있습니다. 이 동작의 한 가지 증상은 metadata.generation 및 metadata.resourceVersion 필드가 빠르게 증가하는 것입니다. 따라서 관리형 객체가 분당 5회 이상 업데이트되는 경우 구성 동기화는 싸움을 감지하고 드리프트를 로깅하고 RootSync 또는 RepoSync 객체 상태의 오류를 보고합니다.
구성 동기화에는 여러 RootSync 및 RepoSync 객체 간의 충돌을 감지하는 특수 로직이 있습니다. RepoSync 객체의 경우 해당 객체가 이미 다른 조정자에 의해 관리되고 있음을 조정자가 감지하면 추가 업데이트를 건너뜁니다.
RootSync 객체의 경우 조정자는 다른 RootSync 객체에 의해 관리되지 않는 한 관리하도록 구성된 객체를 채택하려고 시도합니다. 이렇게 하면 구성 동기화 조정자가 서로 싸우지 않고 관련된 모든 RootSync 및 RepoSync 객체의 상태에 오류가 보고됩니다.
컨트롤러 싸움 식별
nomos status 명령어를 사용하거나 RootSync 또는 RepoSync 객체의 상태 필드를 확인하여 싸움 오류를 검토할 수 있습니다.
nomos 명령줄 도구가 설치되어 있지 않은 경우 다음 명령어를 실행하여 RootSync 리컨실러의 로그를 검토할 수 있습니다.
kubectl logs -n config-management-system \
--selector "app=reconciler,configsync.gke.io/sync-name=root-sync" \
--container reconciler
특정 RepoSync 리컨실러를 필터링하려면 다음 명령어를 실행합니다.
kubectl logs -n config-management-system \
--selector "app=reconciler,configsync.gke.io/sync-namespace=NAMESPACE" \
--container reconciler
NAMESPACE를 네임스페이스 범위의 정보 소스를 만든 네임스페이스로 바꿉니다.
결과에 KNV2005가 표시되면 컨트롤러 싸움이 있는 것입니다.
다음 오류 메시지는 로그에 표시될 수 있는 오류 유형의 예입니다.
KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.
컨트롤러 싸움 조사
컨트롤러 싸움에 대한 자세한 내용을 보려면 다음 명령어를 실행하여 리소스의 YAML 파일 업데이트를 확인하세요.
kubectl get RESOURCE OBJECT_NAME \
--namespace NAMESPACE \
--watch -o yaml
다음을 바꿉니다.
RESOURCE: 싸움의 대상인 리소스의 종류입니다.OBJECT_NAME: 싸움의 대상인 객체의 이름입니다.NAMESPACE: 싸움의 대상인 리소스가 있는 네임스페이스입니다.
로그 결과는 추가해야 하는 리소스, 객체 이름, 네임스페이스를 지정합니다.
이 명령어는 업데이트가 API 서버에 적용된 후 리소스의 상태 스트림을 반환합니다. 파일 비교 도구를 사용하여 출력을 비교합니다.
컨트롤러 싸움 해결
컨트롤러 충돌을 해결하는 방법에는 여러 가지가 있습니다. 구성 동기화 설정에 가장 적합한 옵션을 선택합니다.
- 다른 컨트롤러가 원하는 값과 일치하도록 소스의 리소스 매니페스트를 업데이트합니다.
- 다른 컨트롤러가 관리할 수 있도록 소스에서 문제의 필드를 삭제합니다.
- 다른 컨트롤러를 사용 중지하거나 제거합니다.
- 소스에서 리소스를 삭제하고 수동으로 관리하거나 특정 변경사항이나 공동 관리를 허용하는 커스텀 컨트롤러를 사용하여 관리합니다.
- 리소스 경합을 유발하는 컨트롤러를 소유하고 있으며 변경되는 필드가 정보 소스에 있지 않은 경우 업데이트 대신 패치를 수행하도록 컨트롤러를 업데이트합니다. 이렇게 하면 구성 동기화에서 변경사항을 허용하고 되돌리지 않습니다.
또한 다른 컨트롤러에 속해야 하는 일부 리소스도 있습니다(예: 일부 연산자는 CRD를 설치하거나 유지보수합니다). 이러한 다른 컨트롤러는 구성 동기화 관련 메타데이터를 자동으로 삭제합니다. Kubernetes 클러스터의 다른 구성요소가 구성 동기화 메타데이터를 삭제하는 경우 구성 동기화로 리소스 관리를 중지하세요. 이 작업을 수행하는 방법에 대한 자세한 내용은 관리형 객체 관리 중지를 참조하세요.
또는 구성 동기화가 클러스터의 관리형 객체에 대한 변경사항을 되돌리지 않도록 하려면 구성 동기화로 변형을 무시하려는 객체에 client.lifecycle.config.k8s.io/mutation: ignore 주석을 추가할 수 있습니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 객체 변이 무시를 참고하세요.
암시적 네임스페이스의 컨트롤러 싸움 해결
기본적으로 구성 동기화는 RootSync가 네임스페이스 객체를 관리하지만 네임스페이스 자체가 아직 존재하지 않는 경우 암시적 네임스페이스를 만듭니다. 그런 다음 다른 컨트롤러가 네임스페이스의 소유권을 가져오려고 하면 구성 동기화와의 컨트롤러 충돌이 발생할 수 있습니다. 네임스페이스가 루트 저장소에서 선언된 적이 없고 라이브 네임스페이스에 삭제 방지 주석이 있는 경우 네임스페이스가 암시적으로 생성되었음을 확인할 수 있습니다.
암시적 네임스페이스에 대한 충돌을 해결하는 방법에는 여러 가지가 있습니다. 구성 동기화 설정에 가장 적합한 옵션을 선택하세요.
- RootSync 객체에서 명시적 네임스페이스 전략을 사용합니다. 이 전략은 컨트롤러 충돌을 해결하고 구성 동기화가 추가 암시적 네임스페이스를 생성하지 못하도록 합니다.
- 관리 사용 중지 주석을 사용하여 네임스페이스를 루트 저장소에 추가합니다. 이 주석은 구성 동기화에 네임스페이스 관리를 중지하도록 지시하지만 구성 동기화가 암시적 네임스페이스를 만들도록 허용합니다.
다음 단계
문제가 계속되면 이 문제가 알려진 문제인지 확인합니다.
문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.
- Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
- StackOverflow에서 질문하여 커뮤니티의 지원을 받습니다.
kpt 또는 Kustomize를 사용하는 경우
kpt또는kustomize태그를 사용하여 유사한 문제를 검색합니다. - GitHub의 공개 Issue Tracker를 사용하여 버그나 기능 요청을 엽니다.