구성 동기화 설치

구성 동기화를 사용하면 Git 저장소에 저장된 구성(config)이라는 파일을 사용하여 Kubernetes 리소스를 관리할 수 있습니다. 이 페이지에서는 구성 동기화를 사용 설정하고 구성하는 방법을 보여줍니다.

구성 동기화는 Anthos 또는 Google Kubernetes Engine(GKE)을 사용하는 경우 사용할 수 있습니다.

시작하기 전에

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

로컬 환경 준비

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

  1. 구성 동기화가 동기화하는 구성을 포함할 수 있는 Git 저장소를 만들거나 액세스 권한이 있는지 확인합니다.
  2. gcloudnomos 명령어를 제공하는 Cloud SDK를 설치하고 초기화합니다. Cloud Shell을 사용하는 경우 Cloud SDK가 사전 설치됩니다.

클러스터 요구사항

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

  • Anthos 지원 플랫폼 및 버전입니다.
  • Kubernetes 버전 1.14.x 이상을 사용합니다.
  • Autopilot 클러스터가 아닙니다.
  • 워크로드 아이덴티티가 사용 설정되었습니다. 워크로드 아이덴티티는 향상된 보안 속성과 관리 편의성으로 인해 Google Kubernetes Engine(GKE) 내에서 실행되는 애플리케이션에서 Google Cloud 서비스에 액세스하는 데 권장되는 방식입니다.
  • 비공개 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
    

클러스터 준비

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

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

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

  3. gcloud 명령줄 도구를 사용하여 구성 동기화를 구성하려면 지금 Fleet클러스터를 등록하세요. Google Cloud Console을 사용하려는 경우 클러스터를 등록하세요.

구성 동기화 설치

다음 섹션에서는 구성 동기화에 저장소 액세스 권한을 부여합니다. 액세스 권한을 부여한 후에는 설치를 구성합니다.

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

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

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

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

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

  • SSH 키 쌍
  • cookiefile
  • 토큰
  • Google 서비스 계정(Google 소스 저장소만)

저장소에서 무엇을 지원하는지에 따라 선택할 수 있는 메커니즘이 다릅니다. 모든 메커니즘을 사용할 수 있는 경우에는 SSH 키 쌍을 사용하는 것이 좋습니다. GitHub, Cloud Source Repositories, Bitbucket 모두 SSH 키 쌍 사용을 지원합니다. 조직에서 저장소를 호스팅하고 지원되는 인증 방법을 모르는 경우 관리자에게 문의하세요.

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. 로컬 디스크에서 비공개 키를 삭제하거나 키를 보호합니다.

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 프록시 또는 HTTP 프록시를 사용해야 하는 경우 다음 명령어를 실행하여 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 \
     --from-literal=http_proxy=HTTP_PROXY_URL
    

    다음을 바꿉니다.

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

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

토큰

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

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

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

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

    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: 이전 단계에서 만든 토큰입니다.
  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 Console을 사용하여 구성 동기화를 구성하는 경우 URL 필드에 URL을 추가합니다. gcloud 명령줄 도구를 사용하여 구성 동기화를 구성하는 경우 구성 파일의 syncRepo 필드에 URL을 추가합니다.

  2. 구성 동기화를 구성할 때 적절한 인증 유형을 선택하세요. 클러스터에 워크로드 아이덴티티가 사용 설정되어 있는지에 따라 다른 인증 유형을 선택해야 합니다.

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

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

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

      gcloud 명령줄 도구를 사용하여 구성 동기화를 구성하는 경우 gcpserviceaccountsecretType으로 추가한 후 gcpServiceAccountEmail에 서비스 계정 이메일을 추가합니다.

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

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

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

      다음을 바꿉니다.

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

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

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

    gcloud 명령줄 도구를 사용하여 구성 동기화를 구성하는 경우 gcenodesecretType으로 추가합니다.

    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가 포함되지 않습니다.

구성 동기화 구성

Google Cloud Console은 설치 과정을 안내하고 많은 단계를 자동화합니다. gcloud 명령줄 도구를 사용하여 설치를 완료할 수도 있습니다.

콘솔

클러스터 등록

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

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

  1. Cloud Console에서 다음 안내를 따르세요.

    이 페이지에서는 현재 등록 및 구성된 클러스터를 확인하고 새 클러스터 등록을 시작할 수 있습니다.

  2. 새 설정을 클릭합니다.

  3. Config Management를 위해 등록된 클러스터 선택 페이지에서 이 페이지에서 등록 해제된 클러스터 테이블을 찾고 등록하려는 클러스터를 찾습니다.

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

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

구성 동기화 설치

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

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

  1. 구성 관리에 등록된 클러스터 선택 페이지에서 구성하려는 클러스터를 선택하고 다음을 선택합니다.
  2. 표시되는 구성 동기화 페이지의 버전 드롭다운 목록에서 사용할 Anthos Config Management 버전을 선택합니다. 기본값은 현재 버전입니다.
  3. 구성 섹션에서 구성 동기화 사용 설정 체크박스를 선택한 상태로 둡니다.
  4. URL 필드에 정보 소스로 사용할 Git 저장소의 URL을 추가합니다. HTTPS 또는 SSH 프로토콜을 사용하여 URL을 입력할 수 있습니다. 예를 들어 https://github.com/GoogleCloudPlatform/anthos-config-management-samples는 HTTPS 프로토콜을 사용합니다. 프로토콜을 입력하지 않으면 URL이 HTTPS URL로 취급됩니다.
  5. 인증 유형 드롭다운 목록에서 다음 옵션 중 하나를 선택합니다.

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

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

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

  9. 선택사항: 정책 디렉터리 필드에서 동기화할 정책 계층 구조의 맨 위에 저장소 내 경로를 추가합니다. 기본값은 저장소의 루트 디렉터리입니다.

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

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

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

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

  13. 정책 컨트롤러를 설치하지 않으려면 다음을 클릭하고 정책 컨트롤러 사용 설정 체크박스를 선택 해제합니다.

  14. 완료를 클릭하여 구성 동기화 설치를 완료합니다.

gcloud

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

Anthos 또는 GKE를 사용하는 경우 다음 단계를 완료하여 gcloud 명령줄 도구로 구성 동기화를 구성합니다.

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

새 매니페스트 만들기

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

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY

다음을 바꿉니다.

  • FORMAT: unstructured를 추가하여 구조화되지 않은 저장소를 사용하거나 hierarchy를 추가하여 계층 구조의 저장소를 사용합니다. 이러한 값은 대소문자를 구분합니다. 이 필드는 선택사항이며 기본값은 hierarchy입니다. 이 형식을 사용하면 가장 편리한 방식으로 구성을 조직화할 수 있기 때문에 unstructured를 추가하는 것이 좋습니다.
  • REPO: 정보 소스로 사용할 Git 저장소의 URL을 추가합니다. HTTPS 또는 SSH 프로토콜을 사용하여 URL을 입력할 수 있습니다. 예를 들어 https://github.com/GoogleCloudPlatform/anthos-config-management-samples는 HTTPS 프로토콜을 사용합니다. 프로토콜을 입력하지 않으면 URL이 HTTPS URL로 취급됩니다. 필수 필드입니다.
  • BRANCH: 동기화할 저장소의 분기입니다. 기본값은 기본(마스터) 분기입니다.
  • TYPE: 다음 secretTypes 중 하나입니다.

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

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

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

  • DIRECTORY: 동기화하려는 구성이 포함된 Git 저장소의 루트 디렉터리 경로입니다. 기본값은 저장소의 루트 디렉터리입니다.

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

설치 확인

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

콘솔

다음 단계를 완료합니다.

  1. Cloud Console에서 다음 안내를 따르세요.

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

gcloud

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

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

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

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

gcloud beta container hub config-management apply

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

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

구성 동기화 업그레이드

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

리소스 요청

총 리소스 요청 요약

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

기능 CPU 메모리
(v1.9+) 기본(다중 저장소) 모드 240m + 80m * (RootSync 및 RepoSync 객체 수) 620Mi + 210Mi * (RootSync 및 RepoSync 객체 수)
(v1.7 - v1.8) 기본(다중 저장소) 모드 710m + 260m * (RootSync 및 RepoSync 객체 수) 620Mi + 210Mi * (RootSync 및 RepoSync 객체 수)
계층 구조 컨트롤러 220m 220Mi
단일 저장소 모드 460m 310Mi

세부 리소스 요청

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

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

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

2허용 웹훅에 2개 복제본이 포함되므로 총 리소스 요청을 계산할 때 값에 2를 곱해야 합니다.

다음 단계