기존 클러스터 객체 관리

구성 동기화는 클러스터 객체를 관리할 때 객체와 객체에 영향을 미치는 저장소의 객체 구성 집합을 감시하고 이들이 동기화되도록 합니다. 이 주제에서는 기존 객체 관리를 시작하는 방법과 객체를 삭제하지 않고 현재 관리 중인 객체의 관리를 중지하는 방법을 설명합니다.

클러스터의 객체는 configmanagement.gke.io/managed: enabled 주석과 객체의 그룹, 종류, 네임스페이스, 이름 정보를 추적하는 configsync.gke.io/resource-id 주석이 올바르면 구성 동기화에서 관리됩니다.

configsync.gke.io/resource-id 주석 형식은 네임스페이스 범위 객체의 경우 GROUP_KIND_NAMESPACE_NAME이며 클러스터 범위 객체의 경우 GROUP_KIND_NAME입니다.

다음 순서도에서는 객체가 관리되거나 관리되지 않는 몇 가지 상황을 설명합니다.

이 차트에는 1) 객체 관리 시작, 2) 객체 관리 중지, 3) 관리 객체 삭제 등 세 가지 개별적인 흐름이 있습니다.

1. 객체 관리를 시작하려고 합니다. 객체에 매니페스트가 있나요? 즉, 객체 구성이 저장소에 있나요?
   • 아니요: 객체의 구성을 만듭니다. 구성 동기화는 configmanagement.gke.io/managed: enabled 주석을 설정하고 configsync.gke.io/resource-id 주석이 객체와 일치하도록 설정하고 객체 관리를 시작합니다.
   • 예: 구성에서 configmanagement.gke.io/managed: disabled 주석을 설정하나요?
     • 아니요: 기본적으로 객체가 관리됩니다.
     • 예: configmanagement.gke.io/managed: disabled 주석을 삭제하도록 구성을 수정합니다. 변경사항이 소스 저장소로 푸시되면 구성 동기화는 변경사항을 감지하고 configmanagement.gke.io/managed: enabled 주석과 configsync.gke.io/resource-id 주석을 적용한 후 구성을 적용합니다.
2. 객체 관리를 중지하지만 객체가 삭제되지 않기 원합니다.
   • 저장소에서 객체의 구성을 수정하고 configmanagement.gke.io/managed: disabled 주석을 설정합니다. 구성 변경이 감지되면 구성 동기화가 객체 관리를 중지합니다.
3. 객체 관리를 중지하고 객체를 삭제하고 싶습니다.
   • 저장소에서 객체의 구성을 삭제합니다. 이전에 관리된 객체의 구성을 삭제하면 구성 동기화는 구성이 적용되는 모든 클러스터 또는 네임스페이스에서 객체를 삭제합니다.

구성 동기화는 configmanagement.gke.io/managed: enabled 주석과 configsync.gke.io/resource-id 주석 외에도 app.kubernetes.io/managed-by: configmanagement.gke.io 라벨을 관리하는 모든 객체에 적용합니다. 이 라벨을 사용하면 구성 동기화로 모든 객체를 쉽게 나열할 수 있습니다.

주석을 수동으로 적용하지 않는 이유가 무엇인가요?

구성 동기화는 선언적 모델을 사용해 저장소에서 원하는 구성을 읽어 클러스터에 구성 변경사항을 적용합니다. kubectl 명령어 또는 Kubernetes API를 사용하여 주석을 수동으로 적용하려고 하면 구성 동기화가 저장소 콘텐츠로 매뉴얼을 자동으로 재정의합니다.

시작하기 전에

다음 예시는 구성 동기화 시작하기를 기반으로 합니다. 다음 단계를 시작하기 전에 빠른 시작에 따라 모든 단계를 완료한 후 구성 동기화 설치를 살펴보고 테스트합니다.

모든 관리 객체 나열

특정 클러스터 또는 네임스페이스에 있고 구성 동기화에서 관리되는 모든 객체를 나열하려면 다음과 같은 라벨 선택기를 사용합니다.

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

구성 동기화에서 관리되지 않는 모든 객체를 나열하려면 다음과 같은 라벨 선택기를 사용합니다.

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

예를 들어 다음 명령어는 구성 동기화에서 관리되는 gamestore 네임스페이스에 있는 RoleBinding을 나열합니다.

kubectl get rolebindings -n gamestore \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

출력은 다음과 비슷합니다.

NAME                              ROLE                                          AGE
configsync.gke.io:ns-reconciler   ClusterRole/configsync.gke.io:ns-reconciler   34h
gamestore-admin                   ClusterRole/admin                             34h
gamestore-webstore-admin          ClusterRole/webstore-admin                    34h

다음 명령어는 구성 동기화에서 관리되지 않는 kube-system 네임스페이스에 있는 RoleBinding을 나열합니다.

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

출력은 다음과 비슷합니다.

NAME                                             AGE
fluentd-gcp-scaler-binding                       2d21h
gce:cloud-provider                               2d21h
heapster-binding                                 2d21h
metrics-server-auth-reader                       2d21h
system::leader-locking-kube-controller-manager   2d21h
system::leader-locking-kube-scheduler            2d21h
system:controller:bootstrap-signer               2d21h
system:controller:cloud-provider                 2d21h
system:controller:token-cleaner                  2d21h

기존 객체 관리 시작

구성 동기화를 설치하기 전에 이미 클러스터에 있는 네임스페이스와 같은 기존의 Kubernetes 객체에 구성을 만들 수 있습니다. 그러나 객체에 configmanagement.gke.io/managed: enabled 주석이 없고 올바른 configsync.gke.io/resource-id 주석이 없으면 이 구성은 무시됩니다. 기존 객체의 경우 주석을 수동으로 적용해야 합니다.

특히 네임스페이스의 경우 구성 동기화는 주석 처리되지 않은 네임스페이스 내에서 새 객체를 만드는 구성을 적용하지 않고 configmanagement.gke.io/managed: enabled 및 configsync.gke.io/resource-id 주석을 이 객체에 적용합니다. 그러나 구성 동기화는 주석 처리되지 않은 객체를 수정하거나 클러스터에서 삭제하지 않습니다. 이 내용은 시간 경과에 따른 구성 작업의 다이어그램에 설명되어 있습니다.

다음 예시에서는 기존 역할 객체를 관리하는 방법을 보여줍니다. 먼저 역할을 수동으로 만든 후 구성 동기화로 관리를 시작합니다.

1. gamestore 네임스페이스에 myrole 역할을 만듭니다.

   kubectl create role -n gamestore myrole --verb=get --resource=pods

2. myrole 역할에서 부여되는 권한을 확인합니다.

   kubectl describe role -n gamestore myrole

   Name:         myrole
   Labels:       <none>
   Annotations:  <none>
   PolicyRule:
     Resources  Non-Resource URLs  Resource Names  Verbs
     ---------  -----------------  --------------  -----
     pods       []                 []              [get]
   

   이 역할에는 get 포드에 대한 권한만 있습니다.

3. 이 시점에서 이 역할은 클러스터에 있지만 구성 동기화는 이 역할을 알지 못합니다.

   1. 터미널에서 저장소의 로컬 클론으로 이동합니다.

   2. 다음 명령어를 사용하여 myrole의 YAML 매니페스트를 만들고 gamestore-myrole.yaml이라는 새 파일에 매니페스트를 저장합니다.

      kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
      

   3. gamestore-myrole.yaml 파일을 수정합니다.

      1. name과 namespace를 제외하고 metadata 키 아래에 있는 모든 필드를 삭제합니다.
      2. rules.verbs 목록 필드에서 get 다음에 list 동사를 추가합니다.

      변경사항을 저장합니다. 이제 파일 콘텐츠가 다음과 같습니다.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: myrole
        namespace: gamestore
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      

   4. 변경사항을 저장소에 커밋합니다.

   5. ConfigManagement Operator가 커밋을 감지할 때까지 잠시 기다립니다. myrole 역할이 현재 구성 동기화에서 관리되고 있는지 확인하려면 kubectl describe를 다시 실행합니다.

      kubectl describe role myrole -n gamestore
      

객체가 구성 동기화에서 관리됨을 나타내는 configmanagement.gke.io/managed: enabled 주석과 그룹, 종류, 네임스페이스, 이름 정보를 추적하는 configsync.gke.io/resource-id 주석을 확인합니다. 또한 객체에 대한 최근 구성 변경을 초래한 저장소 내 경로 및 파일 이름을 보여주는 주석과 커밋을 나타내는 Git 해시를 확인합니다.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

관리형 객체 관리 중지

다음 예시에서는 구성 동기화가 현재 관리하고 있는 객체의 관리를 중지하는 방법을 보여줍니다(예: 기존 객체 관리 시작의 myrole 역할).

참고: 관리에서 네임스페이스를 삭제하기 전에 여전히 관리되고 있는 네임스페이스 내 객체가 어떻게 되는지 확인해야 합니다.

1. 저장소의 로컬 클론에서 config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml 파일을 수정하고 아래 굵게 표시된 텍스트와 일치하는 annotations: 섹션을 추가합니다.

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      annotations:
        configmanagement.gke.io/managed: disabled
      name: gamestore-webstore-admin
      namespace: gamestore
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-gamestore
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: webstore-admin
      apiGroup: rbac.authorization.k8s.io
   

   파일을 저장합니다.

2. 변경사항으로 Git 커밋을 만들고 저장소에 커밋을 푸시합니다.

3. 구성 동기화가 새 커밋을 감지하고 적용할 때까지 잠시 기다립니다.

4. 다음 명령어를 사용하여 gamestore-webstore-admin RoleBinding의 주석과 라벨이 모두 비어 있는지 확인합니다. 구성 동기화는 객체의 configmanagement.gke.io/managed 주석을 disabled로 설정하지 않습니다.

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml
   

   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     annotations:
     name: gamestore-webstore-admin
     namespace: gamestore
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-gamestore
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: webstore-admin
     apiGroup: rbac.authorization.k8s.io
   

현재 객체가 중지되어 있음을 확인한 후에 저장소에서 구성을 삭제하고 현재 관리되지 않는 객체가 네임스페이스에서 삭제되지 않았음을 확인합니다. 객체를 다시 관리하려면 구성을 저장소에 다시 추가해야 합니다. 이로 인해 객체를 관리 중지하고 구성을 저장소에 남겨둘 수 있습니다.

이제 객체가 관리되지 않으므로 새 클러스터나 기존 클러스터에서 객체가 생성 또는 재생성되지 않으며 객체가 존재하더라도 삭제되지 않습니다. 이전에 관리를 중지한 객체의 관리를 다시 시작하려면 다음 예시인 이전에 관리를 중지한 객체 관리 재개를 참조하세요.

이전에 관리를 중지한 객체 관리 재개

다음 예시에서는 기존 객체 관리 중지와 같이 이전에 관리에서 삭제한 객체의 관리를 다시 시작하는 방법을 보여줍니다. 여기서는 gamestore-webstore-admin RoleBinding의 구성이 삭제되지 않았다고 가정합니다.

1. 마지막 커밋에서 저장소의 gamestore-webstore-admin RoleBinding을 삭제한 경우 다음 단계를 수행합니다.

   1. git revert를 사용하여 마지막 커밋을 되돌립니다.

      git revert HEAD~1
      

      되돌리기 작업을 확인하라는 메시지가 표시됩니다.

   2. 되돌리기 커밋을 저장소로 푸시합니다.

      git push
      

2. 저장소의 로컬 클론에서 config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml 파일을 수정하고 configmanagement.gke.io/managed: disabled 주석을 삭제합니다. 파일을 저장합니다.

3. 변경사항을 커밋하고 푸시합니다. 구성 동기화가 다음을 수행합니다.

   • 변경사항을 감지합니다.
   • configmanagement.gke.io/managed: enabled 주석과 configsync.gke.io/resource-id 주석을 적용합니다. 이제 객체가 관리됩니다.
   • 다른 모든 관리 객체와 마찬가지로 구성을 적용합니다.

4. 객체가 현재 관리되고 있는지 확인하려면 주석을 나열합니다.

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     annotations:
       configmanagement.gke.io/cluster-name: my-cluster
       configmanagement.gke.io/managed: enabled
       configsync.gke.io/resource-id: rbac.authorization.k8s.io_rolebinding_gamestore_gamestore-webstore-admin
   ...
   

네임스페이스 관리 중지

다른 모든 유형의 객체를 관리 중지할 때와 같은 방식으로 네임스페이스 관리를 중지할 수 있습니다. 네임스페이스 내에서 다른 리소스 관리를 중지하려면 다음 단계를 수행합니다.

1. 네임스페이스 구성 및 동일한 네임스페이스의 모든 구성에 configmanagement.gke.io/managed:disabled 주석을 추가합니다. 네임스페이스의 모든 객체에 이 주석이 있어야 합니다.

   주의: 계층적 정보 소스에서 네임스페이스가 추상 네임스페이스에서 상속된 경우 이를 관리할 수 없습니다.

2. 변경사항을 커밋하고 저장소로 푸시합니다. Operator가 저장소와 동기화될 때까지 기다립니다.

3. 저장소에서 관리되지 않는 리소스를 삭제합니다.

   경고: RootSync 및 RepoSync API를 사용하지 않는 경우 저장소에서 관리되지 않는 네임스페이스를 삭제하면 실시간 클러스터에서 네임스페이스가 삭제된다는 문제가 있습니다. 실수로 삭제된 비관리형 리소스의 경우 클러스터에 수동으로 다시 추가해야 합니다(예: kubectl apply 사용). RootSync 및 RepoSync API를 사용하려면 ConfigManagement 객체를 마이그레이션해야 합니다.

관리형 구성의 구성이 관리되지 않는 네임스페이스 디렉터리에 있는 경우 조정자는 오류를 로깅하지만 다른 구성은 계속 정상적으로 동기화됩니다.

관리형 리소스 삭제

정보 소스에서 개별 리소스를 삭제하면 구성 동기화가 다음에 정보 소스에서 동기화할 때 해당 객체가 클러스터에서 삭제됩니다. 또는 삭제 전파를 사용 설정하여 객체를 일괄 삭제할 수 있습니다.

개별 객체 삭제

구성 동기화의 기본 동작으로 정보 소스에서 객체를 삭제하면 구성 동기화가 정보 소스에서 동기화할 때 해당 객체가 클러스터에서 삭제됩니다.

구성 동기화 상태 또는 특정 객체의 상태를 확인하는 방법에는 여러 가지가 있습니다.

• nomos status 사용.
• kubectl을 사용하여 리소스 검사.
• gcloud alpha anthos config sync resources 명령어 사용하기
• 구성 동기화 대시보드 사용.

객체 일괄 삭제

미리보기

이 제품 또는 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 제품 및 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

기본적으로 RootSync 또는 RepoSync를 삭제하면 구성 동기화가 이전에 정보 소스에서 적용된 객체를 삭제합니다. 또는 삭제 전파를 사용 설정하여 이전에 적용된 모든 객체를 삭제할 수 있습니다.

RootSync 또는 RepoSync 객체에서 삭제 전파를 사용 설정한 다음 해당 객체를 삭제하면 구성 동기화는 해당 RootSync 또는 RepoSync에서 관리하는 모든 객체를 자동으로 삭제합니다.

삭제 전파를 사용하면 새 네임스페이스 또는 클러스터로 마이그레이션하거나 데모 또는 실험 후 정리하거나 애플리케이션을 제거하는 경우와 같이 리소스를 더 쉽게 삭제할 수 있습니다.

전파 옵션 삭제

삭제 전파는 기본적으로 사용 중지됩니다. 삭제 전파를 사용 설정하려면 다음 예시와 같이 configsync.gke.io/deletion-propagation-policy: Foreground 주석을 RootSync 또는 RepoSync 객체에 추가합니다.

# example-rootsync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: example-rootsync
  namespace: config-management-system
  annotations:
    configsync.gke.io/deletion-propagation-policy: Foreground
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: init
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

또는 다음 명령어를 실행하여 삭제 전파를 사용하도록 기존 RootSync 또는 RepoSync를 업데이트할 수 있습니다.

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

ROOTSYNC_NAME을 업데이트할 RootSync의 이름으로 바꿉니다.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

REPOSYNC_NAME을 업데이트할 RepoSync의 이름으로 바꿉니다.

삭제 전파를 중지하려면 주석을 삭제하거나 값을 configsync.gke.io/deletion-propagation-policy: Orphan으로 변경합니다.

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

ROOTSYNC_NAME을 업데이트할 RootSync의 이름으로 바꿉니다.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

객체 삭제 전파

이 예시에서는 RootSync 또는 RepoSync 객체에 삭제 전파를 적용한 다음 RootSync 또는 RepoSync를 삭제하여 RootSync 또는 RepoSync에서 관리되는 모든 객체를 삭제하는 방법을 보여줍니다.

주의: RepoSync 객체의 경우 RepoSync가 삭제를 완료하기 전에 RepoSync가 있는 네임스페이스를 삭제하지 마세요. 이렇게 하면 삭제 전파가 완료되기 전에 RoleBinding이 삭제되어 RepoSync와 네임스페이스의 삭제를 차단할 수 있는 교착 상태가 발생할 수 있습니다.

RootSync

1. RootSync 객체에 주석을 적용하여 삭제 전파를 사용 설정합니다.

   kubectl patch RootSync example-rootsync \
     --namespace config-management-system \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. RootSync 객체를 삭제하고 구성 동기화에서 삭제될 때까지 기다립니다.

   kubectl delete RootSync example-rootsync --namespace config-management-system --wait
   

   RootSync를 삭제하는 데 몇 분 정도 걸릴 수 있습니다.

RepoSync

1. RepoSync 객체에 주석을 적용하여 삭제 전파를 사용 설정합니다.

   kubectl patch RepoSync example-reposync \
     --namespace example-namespace \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. RepoSync 객체를 삭제하고 구성 동기화에서 삭제될 때까지 기다립니다.

   kubectl delete RepoSync example-reposync --namespace example-namespace --wait
   

   RepoSync를 삭제하는 데 몇 분 정도 걸릴 수 있습니다.

Kubernetes 객체 삭제 방지

구성 동기화에서 관리되는 Git 저장소에서 Kubernetes 객체를 삭제하면 이 객체는 새 커밋이 클러스터에 동기화될 때 클러스터에서 삭제됩니다.

해당 구성이 Git 저장소에서 삭제될 때 구성 동기화에서 객체를 삭제하지 못하도록 하려면 다음 단계를 수행하면 됩니다.

1. Git 저장소의 객체 구성에 client.lifecycle.config.k8s.io/deletion: detach 주석을 추가합니다.

2. Git 저장소에 변경사항을 커밋하고 푸시합니다.

3. 변경사항이 클러스터에 동기화될 때까지 기다립니다.

이 단계를 완료하면 구성 동기화는 Git 저장소에서 구성이 삭제될 때 클러스터에서 이 객체를 삭제하지 않지만 다른 클라이언트에서 여전히 삭제할 수 있습니다.

정보 소스의 객체 무시

구성 동기화가 정보 소스의 객체를 무시하도록 할 수 있습니다. 예를 들어 kpt 함수 구성은 클러스터에 적용되지 않아야 합니다.

구성 동기화에서 무시하려는 객체의 경우 config.kubernetes.io/local-config: "true" 주석을 객체에 추가하세요. 이 주석을 추가한 후에는 정보 소스에서 삭제된 것처럼 구성 동기화가 이 객체를 무시합니다. local-config 주석이 "false" 이외의 값으로 설정된 리소스는 "true"로 설정된 것처럼 취급되며 무시됩니다.