구성 동기화 아키텍처

이 페이지에서는 구성 동기화의 아키텍처를 소개합니다. 구성 동기화로 생성된 구성요소에 대해 학습하면 구성 동기화를 자세히 파악할 수 있으며 발생한 문제를 디버깅하고 수정하는 데 도움이 될 수 있습니다.

다음은 구성 동기화 및 Google Kubernetes Engine(GKE) Enterprise 버전 클러스터 관련 리소스의 아키텍처를 보여주는 다이어그램입니다.

구성 동기화 객체 및 리소스 간의 관계를 보여주는 다이어그램

이 다이어그램에서 사용자는 정보 소스를 만들고 기능 관리자를 사용하여 구성 동기화를 설치합니다.

구성 동기화를 설치하는 단계는 여러 단계이며 각 단계에서는 클러스터에 추가 구성요소를 배포합니다.

  1. 클러스터에서 구성 동기화를 사용 설정하면 다음 구성요소가 추가됩니다.

    • 이름이 config-management-operator인 배포의 ConfigManagement Operator
    • ConfigManagement 커스텀 리소스 정의(CRD) 및 이름이 config-management인 객체
    • 이름이 reconciler-manager인 배포의 조정 관리자
    • 이름이 resource-group-controller-manager인 배포의 ResourceGroup 컨트롤러
    • 이름이 otel-collector인 배포의 OpenTelemetry Collector
    • 선택사항: 이름이 admission-webhook인 배포의 구성 동기화 허용 웹훅

    이러한 리소스와 객체는 대부분 구성 동기화를 설치할 때 자동으로 생성되며 사용자가 수정할 필요가 없습니다.

  2. RootSync 및 RepoSync 객체를 만들면 다음 구성요소가 추가됩니다.

    • 각 RootSync에 대해 root-reconciler-ROOTSYNC_NAME이라는 조정자 배포
    • 각 RepoSync에 대해 ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH라는 조정자 배포

구성 동기화 배포, 포드, 컨테이너

다음 표에서는 구성 동기화 배포, 포드, 컨테이너에 대한 자세한 정보를 제공합니다.

배포 이름 배포 네임스페이스 배포 관련 설명 복제본 수 포드 이름 정규 표현식 컨테이너 수 컨테이너 이름
config-management-operator config-management-system ConfigManagement Operator는 구성 동기화가 설치된 모든 클러스터에서 실행됩니다. ConfigManagement 객체를 감시하고 조정 관리자 및 OpenTelemetry Collector와 같은 구성 동기화 구성요소를 관리합니다. 1 config-management-operator-.* 1
  • manager
    		•
    reconciler-manager config-management-system 조정 관리자는 ConfigManagement 객체에서 구성 동기화가 사용 설정된 모든 클러스터에서 실행됩니다. RootSync 및 RepoSync 객체를 감시하고 각 객체에 대해 조정자 배포를 관리합니다. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system 루트 조정자 배포는 모든 RootSync 객체에 생성됩니다. 1 root-reconciler-.* 3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    ns-reconciler config-management-system 네임스페이스 조정자 배포는 모든 RepoSync 객체에 생성됩니다. 1 ns-reconciler-.* 3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    otel-collector config-management-monitoring OpenTelemetry Collector는 ConfigManagement 객체에서 구성 동기화가 사용 설정된 모든 클러스터에서 실행됩니다. config-management-system 및 resource-group-system 네임스페이스에서 실행되는 구성 동기화 구성요소에서 측정항목을 수집하고 이러한 측정항목을 Prometheus 및 Cloud Monitoring으로 내보냅니다. 1 otel-collector-.* 1
  • otel-collector
    		•
    resource-group-controller-manager resource-group-system ResourceGroup 컨트롤러는 ConfigManagement 객체에서 구성 동기화가 사용 설정된 모든 클러스터에서 실행됩니다. ResourceGroup 객체를 감시하고 인벤토리에 있는 각 객체의 현재 조정 상태로 업데이트합니다. ResourceGroup 객체는 모든 RootSync 및 RepoSync 객체에 대해 생성되며 정보 소스에서 조정자가 적용한 객체 목록을 목록화합니다. 1 resource-group-controller-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    admission-webhook config-management-system 구성 동기화 허용 웹훅은 ConfigManagement 객체에서 드리프트 방지가 사용 설정된 각 클러스터에서 실행됩니다. Kubernetes API 요청을 모니터링하고 구성 동기화에서 관리하는 리소스의 수정 또는 삭제를 방지합니다. 구성 동기화 허용 웹훅은 기본적으로 사용 중지됩니다. 2 admission-webhook-.* 1
  • admission-webhook
    		•

    1 이러한 컨테이너가 생성되는 경우에 대한 자세한 내용은 조정자 컨테이너를 참조하세요.

    주요 구성요소

    다음 섹션에서는 중요한 구성 동기화 구성요소에 대해 자세히 살펴봅니다.

    ConfigManagement Operator 및 객체

    ConfigManagement Operator는 ConfigManagement 객체를 감시하고 구성 동기화가 작동하는 데 필요한 다른 구성요소를 만들고 관리합니다.

    연산자 작동

    ConfigManagement Operator는 cluster-admin 권한이 필요한 일부 구성요소를 설치하므로 ConfigManagement Operator에도 cluster-admin 권한이 필요합니다.

    조정 관리자 및 조정자

    조정 관리자는 클러스터 구성을 동기화 상태로 유지하는 개별 조정자를 만들고 관리합니다.

    조정 관리자는 모든 RootSync 객체에 대해 루트 조정자를 만들고 모든 RepoSync 객체에 대해 네임스페이스 조정자를 만듭니다. 구성 동기화는 단일 모놀리식 조정자를 공유하는 대신 이 설계를 사용합니다. 단일 장애점을 줄여 안정성을 개선하고 개별 조정자를 독립적으로 확장할 수 있기 때문입니다.

    루트 및 네임스페이스 조정자는 정보 소스에서 구성을 자동으로 가져와서 이를 적용하여 클러스터 내에서 원하는 상태를 적용합니다.

    다음 다이어그램은 조정 관리자가 각 루트 조정자와 네임스페이스 조정자의 수명 주기 제어를 처리하는 방법을 보여줍니다.

    조정 관리자가 루트 조정자를 제어하는 방법을 보여주는 다이어그램 조정 관리자가 네임스페이스 조정자를 제어하는 방법을 보여주는 다이어그램

    조정자 컨테이너

    조정자 포드에 배포된 특정 컨테이너는 선택한 구성에 따라 달라집니다. 다음 표에서는 이러한 각 조정 컨테이너가 수행하는 작업과 구성 동기화에서 컨테이너를 만드는 조건에 대해 자세히 설명합니다.

    컨테이너 이름 설명 조건
    reconciler 동기화 및 드리프트 해결을 처리합니다. 항상 사용 설정됨
    otel-agent 다른 조정자 컨테이너에서 측정항목을 수신하여 OpenTelemetry Collector로 전송합니다. 항상 사용 설정됨
    git-sync Git 저장소의 구성을 조정자 컨테이너에서 읽을 수 있는 로컬 디렉터리로 가져옵니다. spec.sourceType이 git이면 사용 설정됨
    helm-sync 차트 저장소의 Helm 차트를 조정자 컨테이너에서 읽을 수 있는 로컬 디렉터리로 가져와 렌더링합니다. spec.sourceType이 helm이면 사용 설정됨
    oci-sync 구성이 포함된 OCI 이미지를 Container Registry에서 조정자 컨테이너에서 읽을 수 있는 로컬 디렉터리로 가져옵니다. spec.sourceType이 oci면 사용 설정됨
    gcenode-askpass-sidecar git-sync 컨테이너에서 사용할 GKE 메타데이터 서비스에서 Git 사용자 인증 정보를 캐시합니다. spec.sourceType이 git고 spec.git.auth가 gcenode 또는 gcpserviceaccount면 사용 설정됨
    hydration-controller 조정자 컨테이너에서 읽을 수 있는 로컬 디렉터리에 Kustomize 구성을 빌드하는 방법을 처리합니다. 소스에 kustomize.yaml 파일이 포함되면 사용 설정됨

    위 표에 표시된 것처럼 일반적으로 각 조정자 포드 내에서 3~5개의 컨테이너 수를 예상할 수 있습니다. reconciler 및 otel-agent 컨테이너는 항상 존재합니다. 정보 소스의 유형을 지정하면 추가되는 동기화 컨테이너가 결정됩니다. 또한 표에 언급된 구성을 변경하면 hydration-controller 및 gcenode-askpass-sidecar 컨테이너가 생성됩니다.

    ResourceGroup 컨트롤러 및 ResourceGroup 객체

    루트 및 네임스페이스 조정자는 설정한 각 RootSync 및 RepoSync 객체에 대해 ResourceGroup 인벤토리 객체를 만듭니다. 각 ResourceGroup 객체에는 해당 RootSync 또는 RepoSync 객체의 조정자가 정보 소스에서 클러스터에 동기화한 객체 목록이 포함됩니다. 그러면 ResourceGroup 컨트롤러가 ResourceGroup 객체의 모든 객체를 감시하고 동기화된 객체의 현재 조정 상태로 ResourceGroup 객체의 상태를 업데이트합니다. 이렇게 하면 모든 개별 객체의 상태를 직접 쿼리할 필요 없이 ResourceGroup 객체의 상태를 확인하여 동기화 상태를 개략적으로 볼 수 있습니다.

    ResourceGroup 객체에는 해당 RootSync 또는 RepoSync 객체와 동일한 이름 및 네임스페이스가 있습니다. 예를 들어 네임스페이스 config-management-system의 이름이 root-sync인 RootSync 객체의 경우 해당 ResourceGroup 객체도 config-management-system 네임스페이스에서 root-sync라는 이름으로 지정됩니다.

    ResourceGroup 객체를 만들거나 수정하지 마세요. 구성 동기화 작업을 방해할 수 있습니다.

    허용 웹훅

    구성 동기화 허용 웹훅은 드리프트 방지를 사용 설정할 때 생성됩니다. 드리프트 방지는 수정 요청을 사전에 가로채서 변경을 허용하기 전 정보 소스와 일치하는지 확인합니다.

    드리프트 방지를 사용 설정하지 않아도 구성 동기화는 여전히 자가 복구 메커니즘을 사용하여 구성 드리프트를 되돌립니다. 구성 동기화는 자가 복구를 사용하여 관리형 객체를 지속적으로 모니터링하고 의도한 상태에서 벗어나는 모든 변경사항을 자동으로 되돌립니다.

    RootSync 및 RepoSync 객체

    RootSync 객체는 지정된 정보 소스를 감시하고 해당 소스의 객체를 클러스터에 적용하는 루트 조정자를 만들도록 구성 동기화를 구성합니다. 기본적으로 각 RootSync 객체의 루트 조정자에는 cluster-admin 권한이 있습니다. 이 기본 권한으로 루트 조정자는 클러스터 범위 리소스와 네임스페이스 범위 리소스를 모두 동기화할 수 있습니다. 필요한 경우 spec.override.roleRefs 필드를 구성하여 이러한 권한을 변경할 수 있습니다. RootSync 객체는 클러스터 관리자가 사용하도록 설계되었습니다.

    RepoSync 객체는 지정된 소스를 감시하고 해당 소스의 객체를 클러스터의 특정 네임스페이스에 적용하는 네임스페이스 조정자를 만들도록 구성 동기화를 구성합니다. 네임스페이스 조정자는 해당 네임스페이스의 모든 네임스페이스 범위 리소스를 사용자가 지정한 커스텀 권한과 동기화할 수 있습니다. RepoSync 객체는 네임스페이스 테넌트에서 사용하도록 설계되었습니다.

    Fleet 서비스가 RootSync 객체를 관리하는 방법

    Google Cloud 콘솔, Google Cloud CLI, 구성 커넥터, Terraform을 사용하여 구성 동기화를 설치하면 Google Cloud API에 대한 입력을 기반으로 Fleet 서비스에서 구성 동기화를 관리합니다.

    구성 동기화 설치가 Fleet 서비스에서 관리되는 경우 선택적으로 root-sync라는 초기 RootSync 객체를 관리하도록 할 수도 있습니다. 따라서 클러스터에 직접 아무것도 적용할 필요 없이 클러스터에서 GitOps를 부트스트랩할 수 있습니다. Fleet 서비스에서 초기 RootSync 객체를 관리하지 않기로 결정한 경우에도 원하는 RootSync 및 RepoSync 객체를 클러스터에 직접 적용할 수 있습니다.

    이름이 root-sync인 RootSync 객체는 Google Cloud API에 대한 입력, 특히 구성 관리 적용 API의 spec.configSync 섹션을 기반으로 생성됩니다. 이 API는 RootSync 필드의 하위 집합만 노출하기 때문에 이러한 필드는 root-sync에서 관리되는 것으로 간주되지만 다른 필드는 관리되지 않는 것으로 간주됩니다. 관리형 필드는 Google Cloud API를 통해서만 수정할 수 있습니다. 비관리형 필드는 kubectl 또는 다른 Kubernetes 클라이언트를 사용하여 수정할 수 있습니다. root-sync YAML을 내보내고 로컬에서 수정한 후 다시 적용하는 방법을 보여주는 예시는 RootSync 구성 파일 만들기 및 수정을 참조하세요.

    수동 설치의 경우 kubectl 명령줄 도구 또는 다른 Kubernetes 클라이언트를 사용하여 구성 동기화를 관리합니다.

    추가 RootSync 및 RepoSync 객체

    추가 RootSync 또는 RepoSync 객체를 만들려면 kubectl 명령줄 도구 또는 다른 Kubernetes 클라이언트를 사용하면 됩니다. 또한 초기 root-sync 객체를 사용하면 YAML 매니페스트를 root-sync가 동기화하도록 구성된 정보 소스에 추가하여 GitOps로 추가 RootSync 및 RepoSync 객체를 관리할 수 있습니다. 일부 필드는 Fleet 서비스에서 관리되므로 이 방법은 초기 root-sync의 구성을 관리하는 데 사용할 수 없습니다. GitOps로 root-sync 객체를 관리하려면 구성 커넥터 또는 Terraform을 사용합니다. 추가 RootSync 및 RepoSync 객체 만들기에 대한 자세한 내용은 정보 소스 2개 이상에서 동기화 구성을 참조하세요.

    다음 단계

    • 구성 동기화 구성요소를 모니터링하거나 해당 로그를 확인해야 할 수 있습니다. 소개는 모니터링 및 로그 사용을 참조하세요.
    • 구성 동기화 구성요소의 리소스 요청에 대해 알아보세요.