컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

구성 동기화 설치

구성 동기화를 사용하면 정보 소스에 저장된 구성(config)이라는 파일을 사용하여 Kubernetes 리소스를 관리할 수 있습니다. 구성 동기화는 Git 저장소, OCI 이미지, Helm 차트를 정보 소스로 지원합니다. 이 페이지에서는 루트 저장소에서 동기화되도록 구성 동기화를 사용 설정하고 구성하는 방법을 보여줍니다. 구성 동기화는 Anthos 또는 Google Kubernetes Engine(GKE)을 사용하는 경우 사용할 수 있습니다.

Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치할 때는 RootSync 및 RepoSync API가 기본적으로 사용 설정됩니다. 이렇게 하면 여러 저장소에서 동기화하고 Kustomize 및 Helm 구성을 동기화하는 등의 추가 기능을 제공합니다.

시작하기 전에

구성 동기화를 설치하기 전에 환경, 클러스터, 역할을 준비하고 Anthos Config Management를 사용 설정합니다.

로컬 환경 준비

다음 작업을 완료하여 로컬 환경을 준비합니다.

  1. 정보 소스를 만들거나 정보 소스를 이용할 수 있는지 확인합니다. 여기에서 구성 동기화가 동기화하는 구성을 추가합니다. 구성과 정보 소스를 설정하는 방법에 대한 자세한 내용은 다음 가이드 중 하나를 참조하세요.
  2. gcloud 및 nomos 명령어를 제공하는 Google Cloud CLI를 설치 및 초기화합니다. Cloud Shell을 사용하는 경우 Google Cloud CLI가 사전 설치됩니다.

클러스터 요구사항

다음 요구사항을 충족하는 클러스터를 만들거나 액세스할 수 있는지 확인합니다.

  • Anthos 지원 플랫폼 및 버전 또는 Google Kubernetes Engine(GKE) 클러스터입니다.
  • Anthos Config Management에서 Autopilot 클러스터를 사용하려면 Anthos Config Management 버전 1.12.0 이상을 사용합니다.

  • Anthos Config Management에서 Autopilot 클러스터를 사용하려면 Autopilot이 다음 규칙을 충족하도록 컨테이너 리소스 요구사항을 조정합니다.

    이러한 규칙으로 인해 Autopilot 클러스터의 경우 구성 동기화는 다음을 수행합니다.

    • 리소스 제한 재정의는 무시됩니다.
    • 주석에 선언된 조정 출력보다 높은 리소스 요청이 하나 이상 있거나 주석에 선언된 해당 입력보다 낮은 리소스 요청이 하나 이상 있는 경우에만 재정의를 적용합니다.

  • (선택사항) GKE 클러스터를 사용하는 경우 워크로드 아이덴티티가 사용 설정되어 있습니다. 워크로드 아이덴티티는 향상된 보안 속성 및 관리 편의성으로 인해 GKE 내에서 실행되는 애플리케이션에서 Google Cloud 서비스에 액세스하는 데 권장되는 방식입니다. 워크로드 아이덴티티를 사용 설정한 경우 구성 동기화에 Cloud Monitoring을 사용 설정하려면 올바른 측정항목 쓰기 권한을 부여해야 합니다.

  • 비공개 GKE 클러스터를 사용하려면 비공개 GKE 노드에서 이그레스를 허용하도록 Cloud NAT를 구성합니다. 자세한 내용은 GKE 설정 예시를 참조하세요. 또는 Google API 및 서비스에서 사용되는 외부 IP 주소 집합에 연결하도록 비공개 Google 액세스를 사용 설정할 수 있습니다.

  • Google 서비스 계정을 사용하려는 경우 구성 동기화에 Git 저장소에 대한 액세스 권한 부여를 사용할 때 읽기 전용 범위를 Cloud Source Repositories용 클러스터에 있는 노드의 액세스 범위에 포함해야 합니다.

    클러스터 생성 시 지정된 --scopes 목록에 cloud-source-repos-ro를 포함하거나 클러스터 생성 시 cloud-platform 범위를 사용하여 읽기 전용 범위를 추가할 수 있습니다. 예를 들면 다음과 같습니다.

    gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform

  • 불필요한 트래픽을 차단하는 엄격한 VPC 방화벽 요구사항이 있는 경우 공개 GKE 클러스터에서 다음 트래픽을 허용하도록 방화벽 규칙을 만들어야 합니다.

    • TCP: 포트 53과 443에서 인그레스 및 이그레스 허용

    • UDP: 포트 53에서 이그레스 허용

    이러한 규칙을 포함하지 않으면 구성 동기화가 올바르게 동기화되지 않으며 nomos status가 다음 오류를 보고합니다.

    Error: KNV2004: unable to sync repo Error in the git-sync container

    비공개 GKE 클러스터를 사용하는 경우 이 단계를 건너뛸 수 있습니다.

클러스터 준비

적합한 클러스터를 만든 후 다음 단계를 완료합니다.

  1. Anthos Config Management를 처음 사용하는 경우 Anthos Config Management를 사용 설정합니다.

  2. 클러스터를 등록하는 사용자에게 필요한 IAM 역할을 부여합니다.

  3. Google Cloud CLI를 사용하여 구성 동기화를 구성하려면 GKE 클러스터 또는 Google Cloud 외부 클러스터를 Fleet에 지금 등록합니다. Google Cloud 콘솔을 사용하려면 구성 동기화를 구성할 때 클러스터를 등록합니다.

구성 동기화 설치

다음 섹션에서는 구성 동기화에 다음 정보 소스 중 하나에 대한 액세스 권한을 부여합니다.

액세스 권한을 부여한 후에는 구성 동기화를 구성할 수 있습니다.

Git에 대한 액세스 권한 부여

구성 동기화에는 저장소에 커밋된 구성을 읽고 이를 클러스터에 적용할 수 있도록 Git 저장소에 대한 읽기 전용 액세스 권한이 필요합니다.

저장소에 읽기 전용 액세스에 대한 인증이 필요하지 않으면 계속 구성 동기화를 구성하고 none을 인증 유형으로 사용할 수 있습니다. 예를 들어 로그인하지 않고 웹 인터페이스를 사용하여 저장소를 탐색하거나 git clone을 사용하여 사용자 인증 정보를 제공하지 않거나 저장된 사용자 인증 정보를 사용하지 않고 저장소의 클론을 로컬로 만들 수 있는 경우에는 인증할 필요가 없습니다. 이 경우 보안 비밀을 만들 필요가 없습니다.

하지만 대부분의 사용자는 저장소에 대한 읽기 액세스가 제한되므로 사용자 인증 정보를 만들어야 합니다. 사용자 인증 정보가 필요한 경우 등록된 클러스터마다 git-creds 보안 비밀에 저장됩니다(Google 서비스 계정을 사용하지 않는 경우). 보안 비밀의 이름은 고정 값이므로 git-creds로 지정해야 합니다.

구성 동기화는 다음과 같은 인증 메커니즘을 지원합니다.

  • SSH 키 쌍
  • cookiefile
  • 토큰
  • Google 서비스 계정(Cloud Source Repositories 전용)

저장소에서 무엇을 지원하는지에 따라 선택할 수 있는 메커니즘이 다릅니다. 일반적으로 SSH 키 쌍을 사용하는 것이 좋습니다. GitHub와 Bitbucket 모두 SSH 키 쌍 사용을 지원합니다. 하지만 Cloud Source Repositories에서 저장소를 사용하는 경우에는 프로세스가 더 간단하므로 Google 서비스 계정을 대신 사용하는 것이 좋습니다. 조직에서 저장소를 호스팅하고 지원되는 인증 방법을 모르는 경우 관리자에게 문의하세요.

SSH 키 쌍

SSH 키 쌍은 공개 키 파일과 비공개 키 파일로 구성됩니다. 일반적으로 공개 키에는 .pub 확장자가 있습니다.

SSH 키 쌍을 사용하려면 다음 단계를 완료하세요.

  1. 구성 동기화가 Git 저장소에 인증할 수 있도록 SSH 키 쌍을 만듭니다. 이 단계는 저장소를 클론하거나 읽기 위해 저장소에 인증해야 할 때 필요합니다. 보안 관리자가 키 쌍을 제공하는 경우에는 이 단계를 건너뛰세요. 보안 및 규정 준수 요구사항에 따라 모든 클러스터에 단일 키 쌍을 사용하거나 클러스터별로 키 쌍을 사용할 수 있습니다.

    다음 명령어는 4096비트 RSA 키를 만듭니다. 이보다 낮은 값은 권장되지 않습니다.

    ssh-keygen -t rsa -b 4096 \
-C "GIT_REPOSITORY_USERNAME" \
-N '' \
-f /path/to/KEYPAIR_FILENAME

    다음을 바꿉니다.

    • GIT_REPOSITORY_USERNAME: 구성 동기화가 저장소에 인증하기 위해 사용할 사용자 이름입니다.
    • /path/to/KEYPAIR_FILENAME: 키 쌍의 경로입니다.

    GitHub와 같은 타사 Git 저장소 호스트를 사용하거나 Cloud Source Repositories에서 서비스 계정을 사용하려는 경우 별도의 계정을 사용하는 것이 좋습니다.

  2. 저장소가 새로 생성된 공개 키를 인식하도록 구성합니다. Git 호스팅 업체의 문서를 참조하세요. 편의를 위해 다음과 같이 자주 사용되는 Git 호스팅 업체용 안내가 포함되어 있습니다.

  3. 클러스터의 새 보안 비밀에 비공개 키를 추가합니다.

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME

    /path/to/KEYPAIR_PRIVATE_KEY_FILENAME을 비공개 키 이름(.pub 서픽스가 없는 이름)으로 바꿉니다.

  4. 로컬 디스크에서 비공개 키를 삭제하거나 키를 보호합니다.

  5. 구성 동기화를 구성하고 Git 저장소의 URL을 추가할 때 SSH 프로토콜을 사용합니다. Cloud Source Repositories에서 저장소를 사용하는 경우 URL을 입력할 때 다음 형식을 사용해야 합니다.

    ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME

    다음을 바꿉니다.

    • EMAIL: Google Cloud 사용자 이름입니다.
    • PROJECT_ID: 저장소가 있는 Google Cloud 프로젝트의 ID입니다.
    • REPO_NAME: 저장소의 이름입니다.

cookiefile

cookiefile을 획득하는 절차는 저장소 구성에 따라 다릅니다. 예시를 보려면 Cloud Source Repositories 문서의 정적 사용자 인증 정보 생성을 참조하세요. 사용자 인증 정보는 보통 홈 디렉터리의 .gitcookies 파일에 저장되거나 보안 관리자를 통해 제공받을 수 있습니다.

cookiefile을 사용하려면 다음 단계를 완료하세요.

  1. cookiefile을 만들고 획득한 후에는 클러스터의 새 보안 비밀에 추가합니다.

    HTTPS 프록시를 사용하지 않는 경우 다음 명령어를 사용하여 보안 비밀을 만듭니다.

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE

    HTTPS 프록시를 사용해야 할 경우 다음 명령어를 실행해서 cookiefile과 함께 보안 비밀에 추가합니다.

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE \
 --from-literal=https_proxy=HTTPS_PROXY_URL

    다음을 바꿉니다.

    • /path/to/COOKIEFILE: 적절한 경로 및 파일 이름입니다.
    • HTTPS_PROXY_URL: Git 저장소와 통신할 때 사용하는 HTTPS 프록시의 URL입니다.

  2. cookiefile 콘텐츠가 로컬에서 계속 필요하면 이 콘텐츠를 보호합니다. 그렇지 않으면 삭제합니다.

토큰

조직에서 SSH 키 사용을 허용하지 않으면 토큰을 대신 사용하는 것이 좋습니다. 구성 동기화를 사용하면 GitHub의 개인 액세스 토큰(PAT), GiLab의 PAT 또는 배포 키, Bitbucket의 앱 비밀번호를 토큰으로 사용할 수 있습니다.

토큰을 사용하여 보안 비밀을 만들려면 다음 단계를 완료합니다.

  1. GitHub, GitLab, Bitbucket을 사용하여 토큰을 만듭니다.

  2. 토큰을 만들고 얻은 후에는 클러스터의 새 보안 비밀에 추가합니다.

    HTTPS 프록시를 사용하지 않는 경우 다음 명령어를 사용하여 보안 비밀을 만듭니다.

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace="config-management-system" \
  --from-literal=username=USERNAME \
  --from-literal=token=TOKEN

    다음을 바꿉니다.

    • USERNAME: 사용할 사용자 이름입니다.
    • TOKEN: 이전 단계에서 만든 토큰입니다.

    HTTPS 프록시를 사용해야 할 경우 다음 명령어를 실행해서 username 및 token과 함께 보안 비밀에 추가합니다.

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-literal=username=USERNAME \
  --from-literal=token=TOKEN \
 --from-literal=https_proxy=HTTPS_PROXY_URL

    다음을 바꿉니다.

    • USERNAME: 사용할 사용자 이름입니다.
    • TOKEN: 이전 단계에서 만든 토큰입니다.
    • HTTPS_PROXY_URL: Git 저장소와 통신할 때 사용하는 HTTPS 프록시의 URL입니다.

  3. 토큰이 로컬에서 계속 필요하면 토큰을 보호합니다. 그렇지 않으면 삭제합니다.

Google 서비스 계정

저장소가 Cloud Source Repositories에 있으면 Google 서비스 계정을 사용하여 구성 동기화에 관리형 클러스터와 동일한 프로젝트의 저장소에 대한 액세스 권한을 부여할 수 있습니다.

Cloud Source Repositories의 저장소를 구성 동기화 저장소로 사용하려면 다음 단계별 안내를 완료하세요.

  1. Cloud Source Repositories URL을 가져옵니다.

    1. 모든 저장소를 나열합니다.

      gcloud source repos list

    2. 출력에서 사용하려는 저장소의 URL을 복사합니다. 예를 들면 다음과 같습니다.

      REPO_NAME  PROJECT_ID  URL
my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr

      다음 섹션에서 구성 동기화를 구성할 때 이 URL을 사용해야 합니다. Google Cloud 콘솔을 사용하여 구성 동기화를 구성하는 경우 URL 필드에 URL을 추가합니다. Google Cloud CLI를 사용하여 구성 동기화를 구성하는 경우 구성 파일의 syncRepo 필드에 URL을 추가합니다.

  2. 구성 동기화를 구성할 때 적절한 인증 유형을 선택하세요. 선택해야 하는 인증 유형은 보유한 클러스터 유형과 워크로드 아이덴티티를 사용 설정한 방법에 따라 다릅니다.

    • 워크로드 아이덴티티 사용 설정: GKE 워크로드 아이덴티티가 사용 설정되었거나 Fleet 워크로드 아이덴티티를 사용하는 경우 이 방법을 사용합니다. Fleet 워크로드 아이덴티티를 사용하는 경우 GKE 및 GKE 외의 클러스터 모두에 이 인증 방법을 사용할 수 있습니다.

      클러스터가 Fleet에 등록된 경우 구성 동기화는 기본적으로 Fleet 워크로드 아이덴티티를 사용합니다. 등록된 클러스터에서 Fleet 워크로드 아이덴티티가 사용 설정되어 있는지 확인합니다. 자세한 내용은 클러스터 등록을 참조하세요. 클러스터가 Fleet 호스트 프로젝트와 다른 프로젝트에 있는 경우 Google 서비스 계정을 Fleet 호스트 프로젝트의 Kubernetes 서비스 계정과 결합해야 합니다.

    • 워크로드 아이덴티티 사용 설정되지 않음: GKE 클러스터에만 이 방법을 사용할 수 있습니다.

    워크로드 아이덴티티 사용 설정

    1. 필요한 경우 서비스 계정을 만듭니다. 서비스 계정에 source.reader 역할을 부여하여 Cloud Source Repositories에 대한 읽기 액세스 권한을 부여합니다.

    2. Google Cloud 콘솔을 사용하여 구성 동기화를 구성하는 경우 워크로드 아이덴티티를 인증 유형으로 선택한 후 서비스 계정 이메일을 추가합니다.

      Google Cloud CLI를 사용하여 구성 동기화를 구성하는 경우 gcpserviceaccount를 secretType으로 추가한 후 서비스 계정 이메일을 gcpServiceAccountEmail에 추가합니다.

    3. 구성 동기화를 구성한 후, Kubernetes 서비스 계정과 Google 서비스 계정 간에 IAM 정책 바인딩을 만듭니다. 구성 동기화를 처음 구성할 때까지는 Kubernetes 서비스 계정이 생성되지 않습니다.

      Fleet에 등록된 클러스터를 사용하는 경우 Fleet당 한 번만 정책 바인딩을 만들면 됩니다. Fleet에 등록된 모든 클러스터는 동일한 워크로드 아이덴티티 풀을 공유합니다. Fleet의 동일성 개념에 따라 IAM 정책을 한 클러스터의 Kubernetes 서비스 계정에 추가하면 동일한 Fleet에 있는 다른 클러스터의 동일한 네임스페이스에 있는 Kubernetes 서비스 계정도 동일한 IAM 정책을 받습니다.

      이 바인딩을 사용하면 구성 동기화 Kubernetes 서비스 계정이 Google 서비스 계정 역할을 합니다.

      gcloud iam service-accounts add-iam-policy-binding \
   --role roles/iam.workloadIdentityUser \
   --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

      다음을 바꿉니다.

      • PROJECT_ID: GKE 워크로드 아이덴티티를 사용하는 경우 조직의 프로젝트 ID를 추가합니다.

        Fleet 워크로드 아이덴티티를 사용하는 경우 두 개의 서로 다른 프로젝트 ID를 사용할 수 있습니다. serviceAccount:PROJECT_ID에서 클러스터가 등록된 Fleet의 프로젝트 ID를 추가합니다. GSA_NAME@PROJECT_ID에서 Cloud Source Repositories의 저장소에 대한 읽기 액세스 권한이 있는 프로젝트의 프로젝트 ID를 추가합니다.

      • KSA_NAME: 조정자의 Kubernetes 서비스 계정입니다. 루트 저장소의 경우 RootSync 이름이 root-sync이면 KSA_NAME이 root-reconciler입니다. 그렇지 않은 경우 root-reconciler-ROOT_SYNC_NAME입니다.

        네임스페이스 저장소의 경우 RepoSync 이름이 repo-sync이면 KSA_NAME이 ns-reconciler-NAMESPACE입니다. 그렇지 않은 경우 ns-reconciler-NAMESPACE-REPO_SYNC_NAME입니다.

      • GSA_NAME: Cloud Source Repositories에 연결하기 위해 사용하려는 커스텀 Google 서비스 계정입니다. 선택한 Google 서비스 계정에 source.reader 역할이 있는지 확인합니다.

    워크로드 아이덴티티가 사용 설정되지 않음

    Google Cloud 콘솔을 사용하여 구성 동기화를 구성하는 경우 Google Cloud Repository를 인증 유형으로 선택합니다.

    Google Cloud CLI를 사용하여 구성 동기화를 구성하는 경우 gcenode를 secretType으로 추가하세요.

    Google Cloud Repository 또는 gcenode를 선택하면 Compute Engine 기본 서비스 계정을 사용할 수 있습니다. 기본적으로 Compute Engine 기본 서비스 계정인 PROJECT_ID-compute@developer.gserviceaccount.com에는 동일 프로젝트의 저장소에 대한 source.reader 액세스 권한이 있습니다. 하지만 Cloud Source Repositories가 클러스터 프로젝트와 다른 프로젝트에 있으면 클러스터 프로젝트의 기본 Compute Engine 서비스 계정에 Cloud Source Repositories 프로젝트의 source.reader를 부여해야 합니다.

    다음 명령어를 사용하여 source.reader 역할을 추가할 수 있습니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --role roles/source.reader

    다음을 바꿉니다.

    • PROJECT_ID: 조직의 프로젝트 ID입니다.
    • PROJECT_NUMBER: 조직의 프로젝트 번호입니다.

    노드 풀을 만든 후에는 액세스 범위를 수정할 수 없습니다. 그러나 동일한 클러스터를 사용하는 동안에 액세스 범위가 적절한 새 노드 풀을 만들 수 있습니다. 기본 gke-default 범위에는 cloud-source-repos-ro가 포함되지 않습니다.

구성 동기화에 OCI에 대한 읽기 전용 액세스 권한 부여

구성 동기화는 이미지에 포함된 구성을 읽고 이를 클러스터에 적용할 수 있도록 Artifact Registry 또는 Container Registry에 저장된 OCI 이미지에 대한 읽기 전용 액세스가 필요합니다.

이미지에 읽기 전용 액세스에 대한 인증이 필요하지 않으면 계속 구성 동기화를 구성하고 none을 인증 유형으로 사용할 수 있습니다. 예를 들어 이미지가 공개이고 인터넷에서 누구나 액세스할 수 있으면 인증이 필요하지 않습니다.

하지만 대부분의 사용자는 제한된 이미지에 액세스하기 위해 사용자 인증 정보를 만들어야 합니다. 제한된 읽기 액세스를 갖는 이미지의 경우 gcenode 또는 gcpserviceaccount를 인증 유형으로 사용해서 Google 서비스 계정을 인증에 사용할 수 있습니다.

gcenode

클러스터가 GKE 클러스터이고 워크로드 아이덴티티가 사용 설정되지 않았으면 gcenode를 인증 유형으로 사용할 수 있습니다. 구성 동기화는 Compute Engine 기본 서비스 계정을 사용합니다. Compute Engine 기본 서비스 계정에 Artifact Registry 또는 Container Registry에 대한 읽기 액세스를 부여해야 합니다.

  1. 다음 명령어를 실행하여 환경 변수에 프로젝트 번호를 저장합니다.

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID \
    --format=json | jq -r .projectNumber)

    여기서 PROJECT_ID를 프로젝트 ID로 바꿉니다.

  2. Compute Engine 서비스 계정에 Artifact Registry 또는 Container Registry에 대한 읽기 액세스를 부여합니다.

    Artifact Registry

    Artifact Registry에 대한 액세스를 부여하려면 다음 명령어를 실행합니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role=roles/artifactregistry.reader

    Container Registry

    Container Registry에 대한 액세스를 부여하려면 다음 명령어를 실행합니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role=roles/containerregistry.ServiceAgent

gcpserviceaccount

클러스터에 GKE 워크로드 아이덴티티 또는 Fleet 워크로드 아이덴티티가 사용되는 경우 gcpserviceaccount를 인증 유형으로 사용할 수 있습니다.

  1. 아직 서비스 계정이 없으면 서비스 계정을 만들고 Artifact Registry 또는 Container Registry에 대한 권한을 부여합니다.

    Artifact Registry

    서비스 계정에 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할을 부여합니다.

    Container Registry

    서비스 계정에 Container Registry 서비스 에이전트(roles/containerregistry.ServiceAgent) IAM 역할을 부여합니다.

  2. 다음 명령어를 실행하여 Kubernetes 서비스 계정과 Google 서비스 계정 사이에 IAM 정책 바인딩을 만듭니다.

    gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    다음을 바꿉니다.

    • PROJECT_ID: GKE 워크로드 아이덴티티를 사용하는 경우 조직의 프로젝트 ID입니다. Fleet 워크로드 아이덴티티를 사용하는 경우 두 개의 서로 다른 프로젝트 ID를 사용할 수 있습니다. serviceAccount:PROJECT_ID의 경우 클러스터가 등록된 Fleet의 프로젝트 ID를 추가합니다. GSA_NAME@PROJECT_ID의 경우 Cloud Source Repositories의 저장소에 대한 읽기 액세스 권한이 있는 프로젝트의 프로젝트 ID를 추가합니다.
    • KSA_NAME: 조정자의 Kubernetes 서비스 계정입니다.
      • 루트 저장소의 경우 RootSync 이름이 root-sync이면 root-reconciler를 추가합니다. 그렇지 않으면 root-reconciler-ROOT_SYNC_NAME을 추가합니다.
      • 네임스페이스 저장소의 경우 RepoSync 이름이 repo-sync이면 ns-reconciler-NAMESPACE를 추가합니다. 그렇지 않으면 ns-reconciler-NAMESPACE-REPO_SYNC_NAME을 추가합니다.
    • GSA_NAME: Artifact Registry 또는 Container Registry에 연결하는 데 사용하려는 커스텀 Google 서비스 계정입니다.
      • Artifact Registry의 경우 서비스 계정에 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할이 있어야 합니다.
      • Container Registry의 경우 서비스 계정에 Container Registry 서비스 에이전트(roles/containerregistry.ServiceAgent) IAM 역할이 있어야 합니다.

구성 동기화에 Helm에 대한 읽기 전용 액세스 권한 부여

구성 동기화에는 저장소에서 Helm 차트를 읽고 이를 클러스터에 설치할 수 있도록 Helm 저장소에 대한 읽기 전용 액세스 권한이 필요합니다.

저장소에 읽기 전용 액세스에 대한 인증이 필요하지 않으면 계속 구성 동기화를 구성하고 none을 인증 유형으로 사용할 수 있습니다. 예를 들어 Helm 저장소가 공개 상태이고 인터넷의 모든 사용자가 액세스할 수 있으면 인증할 필요가 없습니다.

하지만 대부분의 사용자는 비공개 Helm 저장소에 액세스하기 위해 사용자 인증 정보를 만들어야 합니다. 구성 동기화는 다음과 같은 인증 메커니즘을 지원합니다.

  • token
  • gcenode

  • gcpserviceaccount

token

Helm 저장소 사용자 이름과 비밀번호로 보안 비밀을 만듭니다.

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

다음을 바꿉니다.

  • SECRET_NAME: 보안 비밀에 지정할 이름입니다.
  • USERNAME: Helm 저장소 사용자 이름입니다.
  • PASSWORD: Helm 저장소 비밀번호입니다.

Config Management Operator를 구성할 때 spec.helm.secretRef.name에 선택한 보안 비밀 이름을 사용합니다.

gcenode

클러스터가 GKE 클러스터이고 워크로드 아이덴티티가 사용 설정되지 않았으면 gcenode를 인증 유형으로 사용할 수 있습니다. 구성 동기화는 Compute Engine 기본 서비스 계정을 사용합니다. Compute Engine 기본 서비스 계정에 Artifact Registry에 대한 읽기 액세스를 부여해야 합니다. 이미지를 가져올 수 있는 읽기 전용 권한을 부여하려면 storage-ro 액세스 범위를 부여해야 할 수 있습니다.

  1. 프로젝트 번호를 환경 변수에 저장합니다.

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')

    여기서 PROJECT_ID를 프로젝트 ID로 바꿉니다.

  2. Compute Engine 서비스 계정에 Artifact Registry에 대한 읽기 권한을 부여합니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role=roles/artifactregistry.reader

gcpserviceaccount

Artifact Registry에 Helm 차트를 저장하고 클러스터에서 GKE 워크로드 아이덴티티 또는 Fleet 워크로드 아이덴티티를 사용하는 경우 gcpserviceaccount를 인증 유형으로 사용할 수 있습니다.

  1. 서비스 계정이 아직 없으면 서비스 계정을 만들고 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할을 부여합니다. Artifact Registry 역할 및 권한에 대한 자세한 내용은 Artifact Registry의 역할 및 권한 구성을 참조하세요.

  2. 다음 명령어를 실행하여 Kubernetes 서비스 계정과 Google 서비스 계정 사이에 IAM 정책 바인딩을 만듭니다.

    gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    다음을 바꿉니다.

    • PROJECT_ID: GKE 워크로드 아이덴티티를 사용하는 경우 조직의 프로젝트 ID입니다. Fleet 워크로드 아이덴티티를 사용하는 경우 두 개의 서로 다른 프로젝트 ID를 사용할 수 있습니다. serviceAccount:PROJECT_ID의 경우 클러스터가 등록된 Fleet의 프로젝트 ID를 추가합니다. GSA_NAME@PROJECT_ID의 경우 Cloud Source Repositories의 저장소에 대한 읽기 액세스 권한이 있는 프로젝트의 프로젝트 ID를 추가합니다.
    • KSA_NAME: 조정자의 Kubernetes 서비스 계정입니다.
      • 루트 저장소의 경우 RootSync 이름이 root-sync이면 root-reconciler를 추가합니다. 그렇지 않으면 root-reconciler-ROOT_SYNC_NAME을 추가합니다.
      • 네임스페이스 저장소의 경우 RepoSync 이름이 repo-sync이면 ns-reconciler-NAMESPACE를 추가합니다. 그렇지 않으면 ns-reconciler-NAMESPACE-REPO_SYNC_NAME을 추가합니다.
    • GSA_NAME: Artifact Registry에 연결하는 데 사용할 커스텀 Google 서비스 계정입니다. 서비스 계정에는 Artifact Registry 리더(roles/artifactregistry.reader) IAM 역할이 있어야 합니다.

구성 동기화 구성

이 섹션에서는 루트 저장소의 설정을 구성합니다. Git 저장소에 동기화하는 경우 Google Cloud 콘솔을 사용하여 설치 과정을 안내하고 일부 단계를 자동화할 수 있습니다.

Google Cloud Console 또는 Google Cloud CLI를 사용하여 구성 동기화를 설치하면 구성 동기화는 root-sync라는 RootSync 객체를 자동으로 만듭니다. kubectl 명령어를 사용하여 root-sync를 수정하고 추가 구성 동기화 구성을 추가할 수 있습니다. 자세한 내용은 kubectl 명령어로 구성 동기화 구성을 참조하세요.

콘솔

클러스터 등록

Config Management를 사용하려면 먼저 클러스터를 등록해야 합니다. 클러스터를 등록하면 공통적인 구성 및 정책 집합을 공유할 수 있습니다.

클러스터를 등록하려면 다음 작업을 완료합니다.

  1. Google Cloud 콘솔에서 다음을 수행합니다.

    • Google Kubernetes Engine을 사용하는 경우 구성 및 정책 섹션의 GKE 구성 페이지로 이동합니다.

      Config Management로 이동

    • Anthos를 사용하는 경우 구성 및 정책 섹션에서 Anthos 구성 페이지로 이동합니다.

      Config Management로 이동

  2. 구성 동기화 설치를 클릭합니다.
  3. Config Management를 위해 등록된 클러스터 선택 페이지에서 이 페이지에서 등록 해제된 클러스터 테이블을 찾고 등록하려는 클러스터를 찾습니다.

  4. 등록하려는 클러스터 옆에서 등록을 클릭합니다.

    클러스터가 성공적으로 등록되면 Config Management를 위해 등록된 클러스터 선택 테이블에 표시됩니다.

구성 동기화 설치

클러스터를 등록한 후 구성 동기화를 계속 설치하고 구성할 수 있습니다.

구성 동기화를 설치하려면 다음 단계를 완료합니다.

  1. 구성 관리에 등록된 클러스터 선택 페이지에서 구성하려는 클러스터를 선택하고 다음을 선택합니다.

  2. 정책 컨트롤러를 설치하려면 정책 컨트롤러 사용 설정 체크박스를 선택한 상태로 두고 다음을 클릭합니다.

  3. 저장소 드롭다운 목록에서 Google 샘플 사용 또는 커스텀을 선택합니다.

    Google 샘플

    Google 샘플 저장소를 사용하려면 Google 샘플 사용을 선택합니다. 이 저장소에는 정책 컨트롤러 번들이 포함되어 있습니다.

    이 옵션을 선택하려면 정책 컨트롤러를 설치하고, 정책 컨트롤러의 제약조건 템플릿 라이브러리를 설치하고, 참조 제약조건을 사용 설정해야 합니다. 이러한 정책 컨트롤러 옵션은 기본적으로 사용 설정됩니다.

    커스텀

    자체 Git 저장소를 사용하려면 커스텀을 선택한 후 다음 필드를 구성합니다.

    1. URL 필드에 정보 소스로 사용할 Git 저장소의 URL을 추가합니다. HTTPS 또는 SSH 프로토콜을 사용하여 URL을 입력합니다. 예를 들면 https://github.com/GoogleCloudPlatform/anthos-config-management-samples입니다. SSH를 인증 유형으로 사용하려면 SSH 프로토콜에 URL을 입력합니다.

    2. 고급 옵션 표시를 클릭합니다.

    3. 인증 유형 드롭다운 목록에서 다음 옵션 중 하나를 선택합니다.

      • 없음: 인증을 사용하지 않습니다.
      • SSH: SSH 키 쌍을 사용합니다.
      • Cookiefile: cookiefile을 사용합니다.
      • 토큰: 토큰을 사용합니다.
      • Google Cloud Repository: Google 서비스 계정을 사용하여 Cloud Source Repositories 저장소에 액세스합니다. 워크로드 아이덴티티가 클러스터에 사용 설정되지 않은 경우에만 이 옵션을 선택합니다.
      • 워크로드 아이덴티티: Google 서비스 계정을 사용하여 Cloud Source Repositories 저장소에 액세스합니다. 워크로드 아이덴티티가 사용 설정된 GKE 클러스터를 사용할 때만 워크로드 아이덴티티를 선택할 수 있습니다. 다른 Anthos 클러스터에서 Fleet 워크로드 아이덴티티와의 통합은 지원되지 않습니다. 워크로드 아이덴티티를 선택할 때는 Google 서비스 계정 이메일 주소를 추가해야 합니다. 예를 들면 acm@PROJECT_ID.iam.gserviceaccount.com입니다. 이 인증 유형을 선택하는 경우 구성 동기화 구성을 완료한 후 IAM 정책 바인딩도 만들어야 합니다. 자세한 내용은 Git에 대한 읽기 전용 액세스 권한을 구성 동기화에 부여 섹션의 Google 서비스 계정 탭을 참조하세요.

    4. Google Cloud 콘솔의 안내에 따라 Git에 대한 읽기 전용 액세스 권한을 구성 동기화에 부여하고 계속을 클릭합니다.

    5. 선택사항: 분기 필드에 동기화할 저장소의 분기를 추가합니다. 기본값은 마스터 분기입니다.

    6. 선택사항: 태그/커밋 필드에서 확인할 Git 버전(태그 또는 해시)을 추가합니다. 기본값은 HEAD입니다.

    7. 선택사항: 구성 디렉터리 필드에서 Git 저장소의 루트를 기준으로 동기화할 디렉터리 경로를 추가합니다. 지정한 디렉터리의 모든 하위 디렉터리가 포함되어 클러스터에 동기화됩니다. 기본값은 저장소의 루트 디렉터리입니다.

    8. 선택사항: 동기화 대기 필드에서 연속 동기화 간격(초)을 추가합니다. 기본값은 15초입니다.

    9. 선택사항: Git 프록시 필드에 Git 저장소와 통신할 때 사용될 HTTPS 프록시의 URL을 입력합니다. 이 필드는 선택사항이며 비워 두면 프록시가 사용되지 않습니다. 프록시는 cookiefile, none 또는 token 승인 유형을 사용하는 경우에만 지원됩니다.

      HTTPS 프록시의 URL은 구성 동기화가 만드는 RootSync 리소스에 일반 텍스트로 표시됩니다. URL에 사용자 이름이나 비밀번호와 같은 민감한 정보가 포함되어 있고 민감한 정보를 숨겨야 하는 경우 Git 프록시를 비워 두고 HTTP 프록시의 URL을 Git 사용자 인증 정보에 사용되는 것과 동일한 보안 비밀에 추가할 수 있습니다. 승인 유형이 cookiefile 또는 token이면 보안 비밀에 프록시를 저장할 수 있습니다.

    10. 선택사항: 소스 형식 드롭다운 목록에서 구조화되지 않음 또는 계층 구조를 선택합니다. 기본값은 구조화되지 않음입니다. 가장 편리한 방식으로 구성을 조직화할 수 있도록 구조화되지 않음을 선택하는 것이 좋습니다.

    11. 선택사항: Config Management 버전 드롭다운 목록에서 사용할 Anthos Config Management 버전을 선택합니다. 기본값은 현재 버전입니다.

  4. 설치를 완료하려면 완료를 클릭합니다. Config Management 페이지로 돌아갑니다.

gcloud

계속하기 전에 Fleet에 클러스터를 등록했는지 확인하세요.

  1. 새 apply-spec.yaml 매니페스트를 만들거나 기존 매니페스트를 추가하여 구성을 준비합니다. 기존 매니페스트를 사용하면 다른 클러스터에 사용되는 것과 동일한 설정으로 클러스터를 구성할 수 있습니다.

새 매니페스트 만들기

클러스터에 대해 구성 동기화를 새 설정으로 구성하려면 apply-spec.yaml이라는 파일을 만들고 이 파일에 다음 YAML 파일을 복사합니다.

매니페스트를 만들 때 필요한 모든 선택적 spec.configSync 필드를 설정하고 나중에 구성을 위해 kubectl 명령어를 사용할 수 있습니다. spec.configSync.enabled 필드만 true로 설정하고 선택적 필드를 생략할 수도 있습니다. 그런 다음 나중에 kubectl 명령어를 사용하여 추가 RootSync 객체를 만들거나 이후 kubectl 명령어를 사용하여 완전히 관리할 수 있는 RepoSync를 만들 수 있습니다.

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a source of truth yet, omit the
    # following fields. You can configure them later.
    sourceType: SOURCE_TYPE
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

다음을 바꿉니다.

  • SOURCE_TYPE: Git 저장소에서 동기화하려면 git을, OCI 이미지에서 동기화하려면 oci를, Helm 차트에서 동기화하려면 helm을 추가합니다. 값을 지정하지 않으면 기본값은 git입니다.
  • FORMAT: unstructured를 추가하여 구조화되지 않은 저장소를 사용하거나 hierarchy를 추가하여 계층 구조의 저장소를 사용합니다. 이러한 값은 대소문자를 구분합니다. 이 필드는 선택사항이며 기본값은 hierarchy입니다. 이 형식을 사용하면 가장 편리한 방식으로 구성을 조직화할 수 있기 때문에 unstructured를 추가하는 것이 좋습니다.

  • REPO: 정보 소스의 URL을 추가합니다. Git 및 Helm 저장소 URL은 HTTPS 또는 SSH 프로토콜을 사용합니다. 예를 들면 https://github.com/GoogleCloudPlatform/anthos-config-management-samples입니다. SSH를 secretType으로 사용하려면 SSH 프로토콜로 URL을 입력합니다. 이 필드는 필수 항목이며 프로토콜을 입력하지 않으면 URL이 HTTPS URL로 취급됩니다.

    OCI URL에는 LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME 형식이 사용됩니다. 기본적으로 이미지는 latest 태그에서 가져오지만 대신 TAG 또는 DIGEST로 이미지를 가져올 수 있습니다. PACKAGE_NAME에서 TAG 또는 DIGEST를 지정합니다.

    • TAG로 가져오려면: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
    • DIGEST로 가져오려면: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

  • BRANCH: 동기화할 저장소의 분기입니다. 이 필드는 선택사항이며 기본값은 master입니다.

  • SECRET_TYPE: 다음 secretTypes 중 하나입니다.

    git

    • none: 인증을 사용하지 않습니다.
    • ssh: SSH 키 쌍을 사용합니다.
    • cookiefile: cookiefile을 사용합니다.
    • token: 토큰을 사용합니다.
    • gcpserviceaccount: Google 서비스 계정을 사용하여 Cloud Source Repositories에 액세스합니다. 이 인증 유형을 선택하는 경우 구성 동기화 구성을 완료한 후 IAM 정책 바인딩을 만들어야 합니다. 자세한 내용은 Git에 대한 읽기 전용 액세스 권한을 구성 동기화에 부여 섹션의 Google 서비스 계정 탭을 참조하세요.
    • gcenode: Google 서비스 계정을 사용하여 Cloud Source Repositories에 액세스합니다. 워크로드 아이덴티티가 클러스터에 사용 설정되지 않은 경우에만 이 옵션을 선택합니다.

    이러한 인증 유형에 대한 자세한 내용은 Git에 대한 읽기 전용 액세스 권한을 구성 동기화에 부여를 참조하세요.

    oci

    • none: 인증 사용 안함
    • gcenode: Compute Engine 기본 서비스 계정을 사용하여 Artifact Registry 또는 Container Registry의 이미지에 액세스합니다. 워크로드 아이덴티티가 클러스터에 사용 설정되지 않은 경우에만 이 옵션을 선택합니다.
    • gcpserviceaccount: Google 서비스 계정을 사용하여 이미지에 액세스합니다.

    helm

    • token: 토큰을 사용합니다.
    • gcenode: Compute Engine 기본 서비스 계정을 사용하여 Artifact Registry 또는 Container Registry의 이미지에 액세스합니다. 워크로드 아이덴티티가 클러스터에 사용 설정되지 않은 경우에만 이 옵션을 선택합니다.
    • gcpserviceaccount: Google 서비스 계정을 사용하여 이미지에 액세스합니다.

  • EMAIL: gcpserviceaccount를 secretType으로 추가한 경우 Google 서비스 계정 이메일 주소를 추가합니다. 예를 들면 acm@PROJECT_ID.iam.gserviceaccount.com입니다.

  • DIRECTORY: Git 저장소의 루트를 기준으로 동기화할 디렉터리의 경로입니다. 지정한 디렉터리의 모든 하위 디렉터리가 포함되어 클러스터에 동기화됩니다. 기본값은 저장소의 루트 디렉터리입니다.

  • PREVENT_DRIFT: true로 설정되었으면 충돌하는 변경사항이 라이브 클러스터로 푸시되지 않도록 거부하여 구성 동기화 허용 웹훅이 드리프트를 방지하도록 사용 설정합니다. 기본 설정은 false입니다. 구성 동기화는 이 필드 값에 관계없이 항상 드리프트를 조정합니다.

spec 필드에 추가할 수 있는 전체 필드 목록은 gcloud 필드를 참조하세요.

기존 매니페스트 사용

다른 클러스터에서 사용하는 것과 동일한 설정으로 클러스터를 구성하려면 등록된 클러스터에서 설정을 가져옵니다.

gcloud alpha container fleet config-management fetch-for-apply \
    --membership=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    > CONFIG_YAML_PATH

다음을 바꿉니다.

  • MEMBERSHIP_NAME: 사용할 구성 동기화 설정이 있는 등록된 클러스터의 멤버십 이름입니다.
  • PROJECT_ID: 프로젝트 ID입니다.
  • CONFIG_YAML_PATH: 클러스터에서 가져온 설정이 포함된 apply-spec.yaml 파일의 경로입니다.

2. apply-spec.yaml 파일을 적용합니다. 기존 매니페스트를 사용하는 경우 이전 명령어에서 가져온 설정으로 구성하려는 클러스터에 파일을 적용해야 합니다.

  gcloud beta container fleet config-management apply \
      --membership=MEMBERSHIP_NAME \
      --config=CONFIG_YAML_PATH \
      --project=PROJECT_ID

다음을 바꿉니다.

  • MEMBERSHIP_NAME: 클러스터를 등록할 때 선택한 멤버십 이름으로 gcloud container fleet memberships list를 사용하여 찾을 수 있습니다.
  • CONFIG_YAML_PATH: apply-spec.yaml 파일에 대한 경로입니다.
  • PROJECT_ID: 프로젝트 ID입니다.

루트 저장소 구성을 완료한 후 선택적으로 다른 루트 저장소 및 네임스페이스 저장소를 포함하여 여러 저장소로부터 동기화를 구성하도록 선택할 수 있습니다. 네임스페이스 저장소는 클러스터 간 특정 네임스페이스에 동기화된 네임스페이스 범위 구성이 포함된 저장소를 원하는 경우에 유용합니다.

설치 확인

Config Sync를 설치하고 구성한 후에는 설치가 성공적으로 완료되었는지 확인할 수 있습니다.

콘솔

다음 단계를 완료합니다.

  1. Google Cloud 콘솔에서 다음을 수행합니다.

    • Google Kubernetes Engine을 사용하는 경우 구성 및 정책 섹션의 GKE 구성 페이지로 이동합니다.

      Config Management로 이동

    • Anthos를 사용하는 경우 구성 및 정책 섹션에서 Anthos 구성 페이지로 이동합니다.

      Config Management로 이동

  2. 클러스터 테이블에서 구성 동기화 상태 열을 봅니다. 설치에 성공한 경우 동기화됨 상태가 표시됩니다.

gcloud

다음 명령어를 실행합니다.

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

PROJECT_ID를 프로젝트 ID로 바꿉니다.

설치에 성공한 경우 SYNCED 상태가 표시됩니다. 위 명령어를 실행한 후 오류가 발생하면 git-creds 보안 비밀을 만들었는지 확인합니다. 보안 비밀을 만든 경우 다음 명령어를 다시 실행해 봅니다.

gcloud beta container fleet config-management apply

또한 nomos status 명령어를 사용하여 구성 동기화가 성공적으로 설치되었는지 확인할 수 있습니다. 문제가 없는 유효한 설치 상태는 PENDING 또는 SYNCED입니다. 설치가 유효하지 않거나 완료되지 않은 경우 상태는 NOT INSTALLED 또는 NOT CONFIGURED입니다. 출력에는 보고된 오류도 포함됩니다.

누락되거나 잘못된 git-creds 보안 비밀 등 즉시 감지되지 않는 잘못된 구성이 있을 수 있습니다. 문제 해결 단계는 문제 해결 페이지에서 유효하지만 잘못된 ConfigManagement 객체를 참조하세요.

구성 동기화 업그레이드

구성 동기화는 Anthos Config Management를 업그레이드할 때마다 업그레이드됩니다. 자세한 내용은 Anthos Config Management 업그레이드를 참조하세요.

리소스 요청

총 리소스 요청 요약

다음 표에서는 사용 중인 기능에 따라 구성 동기화의 지원되는 각 버전에 대해 결합된 리소스 요청 양을 보여줍니다.

1.14

특성 CPU(m) 메모리(Mi)
구성 동기화 330 m + 80 m * (RootSync 및 RepoSync 객체 수)1 850Mi + 600Mi * (RootSync 및 RepoSync 객체 수)
허용 웹훅이 사용 설정된 구성 동기화 350 m + 80 m * (RootSync 및 RepoSync 객체 수)1 1050Mi + 600Mi * (RootSync 및 RepoSync 객체 수)
계층 구조 컨트롤러 200m 200Mi

1 RootSync 및 RepoSync 소스 유형이 helm으로 설정된 경우 CPU 요청은 120m * (RootSync 및 RepoSync 객체 수)입니다.

1.13

특성 CPU(m) 메모리(Mi)
구성 동기화 330m + 80m * (RootSync 및 RepoSync 객체 수) 850Mi + 600Mi * (RootSync 및 RepoSync 객체 수)
허용 웹훅이 사용 설정된 구성 동기화 350m + 80m * (RootSync 및 RepoSync 객체 수) 1050Mi + 600Mi * (RootSync 및 RepoSync 객체 수)
계층 구조 컨트롤러 200m 200Mi

1.12

특성 CPU(m) 메모리(Mi)
구성 동기화 330m + 80m * (RootSync 및 RepoSync 객체 수) 700Mi + 600Mi * (RootSync 및 RepoSync 객체 수)
허용 웹훅이 사용 설정된 구성 동기화 350m + 80m * (RootSync 및 RepoSync 객체 수) 900Mi + 600Mi * (RootSync 및 RepoSync 객체 수)
계층 구조 컨트롤러 200m 200Mi

세부 리소스 요청

다음 표에는 구성 동기화 구성요소의 Kubernetes 리소스 요구사항이 나와 있습니다. 자세한 내용은 Kubernetes 문서의 컨테이너 리소스 관리를 참조하세요.

1.14

배포 이름 복제본당 CPU 요청(m) 복제본당 메모리 요청(Mi) 단일 저장소 또는 다중 저장소
git-importer 450 400 단일
monitor 기본값1 기본값 단일
resource-group-controller-manager 110 300 다중
admission-webhook2 10 100 다중
otel-collector 200 400 다중
reconciler-manager 20 150 다중
reconciler(RootSync 및 RepoSync당 하나) 80 + 기본값3 600 + 기본값 다중
hnc-controller-manager 100 150 계층 구조 컨트롤러
gke-hc-controller-manager 100 50 계층 구조 컨트롤러

1 기본 리소스 요청에는 10milliCPU(mCPU)의 CPU 요청 및 메모리 요청 10Mi가 사용됩니다.

2 허용 웹훅에는 복제본이 두 개 있으므로 총 리소스 요청을 계산할 때 허용 웹훅을 사용하는 경우 값에 2를 곱해야 합니다 허용 웹훅은 기본적으로 사용 중지되어 있습니다.

3 RootSync 및 RepoSync 소스 유형이 helm으로 설정된 경우 CPU 요청은 120m * (RootSync 및 RepoSync 객체 수)입니다.

1.13

배포 이름 복제본당 CPU 요청(m) 복제본당 메모리 요청(Mi) 단일 저장소 또는 다중 저장소
git-importer 450 400 단일
monitor 기본값1 기본값 단일
resource-group-controller-manager 110 300 다중
admission-webhook2 10 100 다중
otel-collector 200 400 다중
reconciler-manager 20 150 다중
reconciler(RootSync 및 RepoSync당 하나) 80 + 기본값 600 + 기본값 다중
hnc-controller-manager 100 150 계층 구조 컨트롤러
gke-hc-controller-manager 100 50 계층 구조 컨트롤러

1 기본 리소스 요청에는 10milliCPU(mCPU)의 CPU 요청 및 메모리 요청 10Mi가 사용됩니다.

2 허용 웹훅에는 복제본이 두 개 있으므로 총 리소스 요청을 계산할 때 허용 웹훅을 사용하는 경우 값에 2를 곱해야 합니다 허용 웹훅은 기본적으로 사용 중지되어 있습니다.

1.12

배포 이름 복제본당 CPU 요청(m) 복제본당 메모리 요청(Mi) 단일 저장소 또는 다중 저장소
git-importer 450 400 단일
monitor 기본값1 기본값 단일
resource-group-controller-manager 110+기본값 150+기본값 다중
admission-webhook2 10 100 다중
otel-collector 200 400 다중
reconciler-manager 20 150 다중
reconciler(RootSync 및 RepoSync당 하나) 80+기본값 600+기본값 다중
hnc-controller-manager 100 150 계층 구조 컨트롤러
gke-hc-controller-manager 100 50 계층 구조 컨트롤러

1 기본 리소스 요청에는 10milliCPU(mCPU)의 CPU 요청 및 메모리 요청 10Mi가 사용됩니다.

2 허용 웹훅에는 복제본이 두 개 있으므로 총 리소스 요청을 계산할 때 허용 웹훅을 사용하는 경우 값에 2를 곱해야 합니다 허용 웹훅은 기본적으로 사용 중지되어 있습니다.

다음 단계