구성 동기화 설치

구성 동기화에서는 클러스터 운영자가 Git 저장소에 저장된 구성(config)이라는 파일을 사용하여 Kubernetes 리소스를 관리할 수 있습니다.

이 페이지에서는 Anthos Config Management의 일부로 구성 동기화를 사용 설정하고 구성하는 방법을 보여줍니다. 관리하려는 각 클러스터에 Anthos Config Management를 설치하고 구성하려면 다음 단계를 따르세요.

시작하기 전에

구성 동기화를 설치하기 전에 환경, 클러스터, 역할을 준비하고 Anthos Config Management를 사용 설정했는지 확인하세요.

로컬 환경 준비

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

  1. 프로젝트에 Anthos API를 사용 설정합니다.

    Console

    Google Cloud Console에서 Anthos API 페이지로 이동합니다.

    Anthos API 페이지로 이동

    • 사용 설정을 클릭합니다.

    gcloud

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

    gcloud services enable anthos.googleapis.com
    
  2. 이 안내에서 사용되는 gcloud, gsutil, kubectl, nomos 명령어를 제공하는 Cloud SDK를 설치하고 초기화합니다. Cloud Shell을 사용하는 경우 Cloud SDK가 사전 설치됩니다.

  3. Cloud SDK는 kubectl을 기본으로 설치하지 않습니다. kubectl을 설치하려면 다음 명령어를 사용하세요.

    gcloud components install kubectl
    
  4. Anthos Config Management 구성요소를 다운로드할 수 있도록 gcloud auth login 명령어를 사용하여 Google Cloud에 인증합니다.

클러스터 준비

다음 작업을 완료하여 클러스터를 준비합니다.

  1. 클러스터가 Anthos 지원 플랫폼 및 버전에 있는지 확인합니다.

  2. Connect를 사용하여 Anthos 환경클러스터를 등록합니다. 프로젝트 환경은 Google Cloud 외부의 클러스터를 포함하여 Anthos의 일부로 클러스터와 워크로드를 보고 관리하는 통합 방법을 제공합니다. Anthos 요금은 등록된 클러스터에만 적용됩니다.

권한 준비

사용하는 설치 방법에 따라 Config Management를 설치하는 사용자에게 다른 권한을 부여해야 합니다. Identity and Access Management(IAM) 역할을 부여하는 방법을 알아보려면 리소스에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.

Console

구성 동기화를 설치하는 Google Cloud 사용자가 Hub API를 통해 클러스터를 관리하려면 GKE 허브 관리자(roles/gkehub.admin) 역할이 필요합니다.

gcloud

구성 동기화를 설치하는 Google Cloud 사용자가 Hub API를 통해 클러스터를 관리하려면 GKE 허브 관리자(roles/gkehub.admin) 역할이 필요합니다.

허브 관리자 역할은 environ 허브 및 관련 리소스에 대한 전체 액세스 권한을 제공합니다.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/gkehub.admin

다음을 바꿉니다.

  • MEMBER: 구성원의 식별자이며 일반적으로 member-type:id 형식을 사용합니다. 예를 들면 user:my-user@example.com입니다. member가 가질 수 있는 값의 전체 목록은 정책 binding 참조를 확인하세요.

  • PROJECT_ID: 프로젝트 ID입니다.

kubectl

GKE를 사용하는 경우, 구성 동기화를 설치하는 Google Cloud 사용자가 클러스터에서 새 역할을 만들려면 IAM 권한이 필요합니다.

예를 들면 다음과 같습니다.

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin --user USER_ACCOUNT

다음을 바꿉니다.

  • CLUSTER_NAME: 클러스터 이름입니다.
  • USER_ACCOUNT: Google Cloud 계정의 이메일 주소입니다.

로컬 시스템에서 gcloud 명령줄 도구를 구성한 방법에 따라 --project--zone 필드를 추가해야 할 수도 있습니다.

Anthos Config Management 사용 설정

Anthos Config Management를 처음 사용하는 경우 다음 단계를 완료하여 기능을 사용 설정하세요.

Console

  1. Google Cloud Console에서 Anthos 기능 페이지로 이동합니다.

    Anthos 기능 페이지로 이동

  2. Config Management 행에서 사용 설정을 클릭합니다.

  3. 확인 창에서 Config Management 사용 설정을 클릭합니다.

gcloud

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

 gcloud alpha container hub config-management enable

구성 동기화 설치

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

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

구성 동기화에는 저장소에 커밋된 구성을 읽고 이를 클러스터에 적용할 수 있도록 Git 저장소에 대한 읽기 전용 액세스 권한이 필요합니다. 사용자 인증 정보가 필요한 경우 등록된 각 클러스터의 git-creds 보안 비밀에 저장됩니다.

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

하지만 대부분의 사용자는 저장소에 대한 읽기 액세스가 제한되므로 사용자 인증 정보를 만들어야 합니다. 구성 동기화는 다음과 같은 인증 메커니즘을 지원합니다.

  • 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을 만들고 획득한 후에는 클러스터의 새 보안 비밀에 추가합니다.

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

    /path/to/COOKIEFILE을 적절한 경로와 파일 이름으로 바꿉니다.

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

토큰

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

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

  1. GitHub 또는 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에 있으면 secretType: gcenode를 사용하여 구성 동기화에 관리형 클러스터와 동일한 프로젝트의 저장소에 대한 액세스 권한을 부여할 수 있습니다.

기본 요건

시작하기 전에 다음 기본 요건을 충족하는지 확인하세요.

  • 클러스터의 노드 액세스 범위에는 cloud-source-repos-ro가 포함되어야 합니다. 기본적으로 Compute Engine 기본 서비스 계정 PROJECT_ID-compute@developer.gserviceaccount.com에는 동일한 프로젝트의 저장소에 대한 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: 조직의 프로젝트 번호입니다.
  • 클러스터의 노드 액세스 범위에는 cloud-source-repos-ro가 포함되어야 합니다. 클러스터 생성 시 지정된 --scopes 목록에 cloud-source-repos-ro를 포함하거나 클러스터 생성 시 cloud-platform 범위를 사용하여 이 범위를 추가할 수 있습니다.

    gcloud container clusters create example-cluster --scopes=cloud-platform
    

Cloud Source Repositories를 SyncRepo로 사용

이러한 기본 요건이 충족되면 구성 동기화를 구성할 때 Cloud Source Repositories에서 사용할 저장소의 URL에 spec.git.syncRepo를 설정합니다.

Cloud Source Repositories의 저장소를 SyncRepo로 사용하려면 다음 단계를 완료합니다.

  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
    
  3. URL을 syncRepo로 추가합니다. 예를 들면 다음과 같습니다.

    spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
    

워크로드 아이덴티티로 Cloud Source Repositories 사용

클러스터에서 워크로드 아이덴티티가 사용 설정된 경우 secretType: gcenode를 사용하려면 추가 단계가 필요합니다. 위 단계를 완료하고 구성 동기화 구성(다음 섹션에서 수행)을 완료한 다음 Kubernetes 서비스 계정과 Google 서비스 계정 간에 IAM 정책 binding을 생성합니다. 구성 동기화를 처음 구성할 때까지는 Kubernetes 서비스 계정이 생성되지 않습니다.

이 binding을 사용하면 구성 동기화 Kubernetes 서비스 계정을 Compute Engine 기본 서비스 계정으로 사용할 수 있습니다.

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

다음으로 바꿉니다. * PROJECT_ID: 조직의 프로젝트 ID * PROJECT_NUMBER: 조직의 프로젝트 번호

binding을 만든 후 Compute Engine 기본 서비스 계정의 이메일 주소를 사용하여 구성 동기화 Kubernetes 서비스 계정에 annotation을 추가합니다.

kubectl annotate serviceaccount -n config-management-system importer \
  iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

PROJECT_NUMBER를 조직의 프로젝트 번호로 바꿉니다.

구성 동기화 설정

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

GKE 클러스터를 사용하는 경우 Cloud Console을 사용하여 구성 동기화를 구성하는 것이 좋습니다. VMware용 Anthos 클러스터를 사용하는 경우 Cloud Console 또는 gcloud 도구에서 비공개 레지스트리가 지원되지 않으므로 kubectl 명령어를 사용하여 구성 동기화를 설치해야 합니다.

구성 동기화를 구성하려면 다음 단계를 완료하세요.

Console

  1. Cloud Console에서 Anthos Config Management 페이지로 이동합니다.

    Anthos Config Management로 이동

  2. 등록된 클러스터를 선택하고 구성을 클릭합니다.

  3. ACM의 Git 저장소 인증 섹션에서 다음 옵션 중 하나를 선택합니다.

    • 없음
    • SSH
    • cookiefile
    • 토큰
    • Google Cloud Repository

    아직 부여하지 않았다면 구성 동기화에 Git에 대한 읽기 전용 액세스 권한을 부여합니다.

  4. 계속을 클릭합니다.

  5. 클러스터의 ACM 설정 섹션에서 다음을 완료합니다.

    1. 버전 필드에서 Anthos Config Management 버전을 선택합니다.
    2. 구성 동기화 사용 체크박스를 선택합니다.
      1. URL 필드에 정보 소스로 사용할 Git 저장소의 URL을 추가합니다. 필수 필드입니다.
      2. 분기 필드에 동기화할 저장소의 분기를 추가합니다. 기본값은 기본(마스터) 분기입니다.
      3. 태그/커밋 필드에서 확인할 Git 버전(태그 또는 해시)을 추가합니다. 기본값은 HEAD입니다.
      4. 정책 디렉터리 필드에서 동기화할 정책 계층 구조의 맨 위에 저장소 내 경로를 추가합니다. 기본값은 저장소의 루트 디렉터리입니다.
      5. 동기화 대기 필드에서 연속 동기화 간격(초)을 추가합니다. 기본값은 15초입니다.
      6. Git 프록시 필드에 Git 저장소와 통신할 때 사용될 HTTPS 프록시의 URL을 입력합니다. 이 필드는 선택사항이며 비워 두면 프록시가 사용되지 않습니다.
      7. 소스 형식 필드에서계층 구조(기본값) 또는 구조화되지 않음(권장)을 선택합니다. 이 형식을 사용하면 가장 편리한 방식으로 구성을 조직화할 수 있기 때문에 구조화되지 않음을 선택하는 것이 좋습니다.
  6. 완료를 클릭합니다. Anthos Config Management 페이지로 돌아갑니다. 몇 분 후에 구성한 클러스터 옆에 있는 상태 열에 Synced가 표시되어야 합니다. Error가 표시되면 Error 단어를 클릭하여 자세한 내용을 확인합니다.

gcloud

  1. config-management.yaml 파일을 만들고 이 파일에 다음 YAML 파일을 복사합니다.

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      sourceFormat: FORMAT
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    

    다음을 바꿉니다.

    • FORMAT: unstructured를 추가하여 구조화되지 않은 저장소를 사용하거나 hierarchy를 추가하여 계층 구조의 저장소를 사용합니다. 이러한 값은 대소문자를 구분합니다. 이 필드는 선택사항이며 기본값은 hierarchy입니다. 이 형식을 사용하면 가장 편리한 방식으로 구성을 조직화할 수 있기 때문에 unstructured를 추가하는 것이 좋습니다.
    • REPO: 정보 소스로 사용할 Git 저장소의 URL입니다. 필수 필드입니다.
    • BRANCH: 동기화할 저장소의 분기입니다. 기본값은 기본(마스터) 분기입니다.
    • TYPE: 다음 SecretTypes 중 하나입니다.

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

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

  2. config-management.yaml 파일을 적용합니다.

     gcloud alpha container hub config-management apply \
         --membership=CLUSTER_NAME \
         --config=CONFIG_YAML_PATH \
         --project=PROJECT_ID
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 이 구성을 적용할 등록된 클러스터의 이름입니다.
    • CONFIG_YAML_PATH: config-management.yaml 파일에 대한 경로입니다.
    • PROJECT_ID: 프로젝트 ID입니다.

kubectl

kubectl로 구성 동기화를 설치하는 경우 Operator를 구성하기 전에 Operator를 먼저 배포해야 합니다. Operator는 Kubernetes 클러스터에서 구성 동기화를 관리하는 컨트롤러입니다.

연산자 배포

모든 기본 요건을 충족하는지 확인한 후 YAML 매니페스트를 다운로드하고 적용하여 연산자를 배포할 수 있습니다.

  1. 다음 명령어를 사용하여 최신 버전의 Operator CustomResourceDefinition(CRD)을 다운로드합니다. 특정 버전을 대신 다운로드하려면 다운로드를 참조하세요.

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
    
  2. CRD를 적용합니다.

    kubectl apply -f config-management-operator.yaml

이 명령어가 실패하면 문제 해결을 참조하세요.

Anthos Config Management 구성

Anthos Config Management의 동작을 구성하려면 ConfigManagement CustomResource의 구성 파일을 만든 후 kubectl apply 명령어를 사용하여 적용합니다.

  1. config-management.yaml 파일을 만들고 이 파일에 다음 YAML 파일을 복사합니다.

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      # clusterName is required and must be unique among all managed clusters
      clusterName: CLUSTER_NAME
      sourceFormat: FORMAT
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 이 구성을 적용할 등록된 클러스터의 이름입니다.
    • FORMAT: unstructured를 추가하여 구조화되지 않은 저장소를 사용하거나 hierarchy를 추가하여 계층 구조의 저장소를 사용합니다. 이러한 값은 대소문자를 구분합니다. 이 필드는 선택사항이며 기본값은 hierarchy입니다. 이 형식을 사용하면 가장 편리한 방식으로 구성을 조직화할 수 있기 때문에 unstructured를 추가하는 것이 좋습니다.
    • REPO: 정보 소스로 사용할 Git 저장소의 URL입니다. 필수 필드입니다.
    • BRANCH: 동기화할 저장소의 분기입니다. 기본값은 기본(마스터) 분기입니다.
    • TYPE: 다음 SecretTypes 중 하나입니다.

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

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

  2. kubectl apply 명령어로 구성을 적용합니다.

    kubectl apply -f config-management.yaml
    

    각 클러스터 또는 각 유형의 클러스터마다 별도의 구성 파일을 만들어야 할 수도 있습니다. --context 옵션을 사용하여 클러스터를 지정할 수 있습니다.

    kubectl apply -f config-management1.yaml --context=CLUSTER_NAME
    

    CLUSTER_NAME을 사용하려는 클러스터 이름으로 바꿉니다.

설치 확인

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

Console

  1. Cloud Console에서 Anthos Config Management 페이지로 이동합니다.

    Anthos Config Management로 이동

  2. 상태 열을 확인합니다. 설치에 성공한 경우 Synced 상태가 표시됩니다.

클러스터 상태를 자세히 확인하려면 다음 안내를 따르세요.

  • 탐색하려는 클러스터를 선택합니다. 클러스터 세부정보 페이지가 나타납니다. 이 페이지에서 클러스터 세부정보와 구성 동기화 설치에 대한 세부정보를 볼 수 있습니다.

gcloud

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

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

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

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

gcloud alpha container hub config-management apply

kubectl

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

구성 동기화가 성공적으로 배포되면 kube-system 네임스페이스에서 이름이 config-management-operator로 시작하는 Pod에서 실행됩니다. Pod를 초기화하는 데 시간이 다소 걸릴 수 있습니다.

Pod가 실행 중인지 확인합니다.

kubectl -n kube-system get pods | grep config-management

Pod가 실행 중이면 명령어 응답은 다음 예시와 비슷합니다.

config-management-operator-6f988f5fdd-4r7tr 1/1 Running 0 26s

config-management-system 네임스페이스가 존재하는지 확인할 수도 있습니다.

kubectl get ns | grep 'config-management-system'

명령어 결과는 다음 예시와 비슷합니다.

config-management-system Active 1m

명령어가 위 예시와 비슷한 출력을 반환하지 않으면 로그에서 잘못된 점을 확인합니다.

kubectl -n kube-system logs -l k8s-app=config-management-operator

또한 kubectl get events를 사용하여 구성 동기화에서 이벤트가 생성되었는지 확인할 수 있습니다.

kubectl get events -n kube-system

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

다음 단계