Anthos Config Management는 클러스터 객체를 관리할 때 객체와 객체에 영향을 미치는 저장소의 객체 구성 집합을 감시하고 이들이 동기화되도록 합니다. 이 주제에서는 기존 객체 관리를 시작하는 방법과 객체를 삭제하지 않고 현재 관리 중인 객체의 관리를 중지하는 방법을 설명합니다.
개요
클러스터의 객체는 configmanagement.gke.io/managed: enabled 주석이 있으면 Anthos Config Management에서 관리됩니다.
객체에 configmanagement.gke.io/managed 라벨이 없거나 enabled 이외의 값으로 설정된 경우에는 객체가 관리되지 않습니다.
다음 순서도에서는 객체가 관리되거나 관리되지 않는 몇 가지 상황을 설명합니다.
이 차트에는 객체 관리 시작, 객체 관리 중지, 관리 객체 삭제 등 세 가지 개별적인 흐름이 있습니다.
- 객체를 관리하고 싶습니다.
a. 객체 구성이 저장소에 있나요?
- 아니요: 객체의 구성을 만듭니다. Anthos Config Management가
configmanagement.gke.io/managed: enabled주석을 설정하고 객체 관리를 시작합니다. - 예: 구성에서
configmanagement.gke.io/managed: disabled주석을 설정하나요?- 아니요: 기본적으로 객체가 관리됩니다.
- 예:
configmanagement.gke.io/managed: disabled주석을 삭제하도록 구성을 수정합니다. 변경사항이 소스 저장소로 푸시되면 Anthos Config Management는 변경사항을 감지하고configmanagement.gke.io/managed: enabled주석을 적용한 후 구성을 적용합니다.
- 아니요: 객체의 구성을 만듭니다. Anthos Config Management가
- 객체 관리를 중지하지만 객체가 삭제되지 않기 원합니다.
- 저장소에서 객체의 구성을 수정하고
configmanagement.gke.io/managed: disabled주석을 설정합니다. 구성 변경이 감지되면 Anthos Config Management가 객체 관리를 중지합니다.
- 저장소에서 객체의 구성을 수정하고
- 객체 관리를 중지하고 객체를 삭제하고 싶습니다.
- 저장소에서 객체의 구성을 삭제합니다. 이전에 관리된 객체의 구성을 삭제하면 Anthos Config Management는 구성이 적용되는 모든 클러스터 또는 네임스페이스에서 객체를 삭제합니다.
Anthos Config Management는 configmanagement.gke.io/managed: enabled 주석 외에도 app.kubernetes.io/managed-by: configmanagement.gke.io 라벨을 관리하는 모든 객체에 적용합니다. 이 라벨을 사용하면 Anthos Config Management별 모든 객체를 쉽게 나열할 수 있습니다.
주석을 수동으로 적용하지 않는 이유가 무엇인가요?
Anthos Config Management는 선언적 모델을 사용하여 저장소에서 원하는 구성을 읽어 클러스터에 구성 변경 사항을 적용합니다.
kubectl 명령어 또는 Kubernetes API를 사용하여 주석을 수동으로 적용하려고 하면 Anthos Config Management가 저장소의 내용으로 매뉴얼을 자동으로 대체합니다.
시작하기 전에
다음 예시는 빠른 시작을 바탕으로 합니다. 다음 단계를 시작하기 전에 빠른 시작에 따라 모든 단계를 완료한 후 클러스터와 저장소를 검토합니다.
모든 관리 객체 나열
지정된 클러스터 또는 네임스페이스에서 Anthos Config Management가 관리하는 모든 객체를 나열하려면 다음과 같은 라벨 선택기를 사용합니다.
kubectl get object-type -l "app.kubernetes.io/managed-by=configmanagement.gke.io"
Anthos Config Management가 관리하지 않는 모든 객체를 나열하려면 다음과 같은 라벨 선택기를 사용합니다.
kubectl get object-type -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"
예를 들어 이 명령어는 Anthos Config Management가 관리하는 shipping-dev 네임스페이스에 RoleBinding을 나열합니다.
kubectl get rolebindings -n shipping-dev \
-l "app.kubernetes.io/managed-by=configmanagement.gke.io"
NAME AGE
job-creators 12m
pod-creators 12m
sre-admin 12m
viewers 12m
이 명령어는 Anthos Config Management가 관리하지 않는 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
기존 객체 관리 시작
이 예시에서는 역할을 수동으로 작성한 다음 Anthos Config Management로 역할을 관리하기 시작합니다.
audit네임스페이스에myrole역할을 만듭니다.kubectl create role -n audit myrole --verb=get --resource=pods
myrole역할에서 부여되는 권한을 확인합니다.kubectl describe role -n audit myrole
Name: myrole Labels: <none> Annotations: <none> PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get]이 역할에는
getPod에 대한 권한만 있습니다.이 시점에서 역할은 클러스터에 존재하지만 Anthos Config Management는 이를 알지 못합니다.
- 터미널에서 저장소의 로컬 클론으로 이동합니다.
다음 명령어를 사용하여
myrole의 YAML 매니페스트를 만들고namespaces/audit/myrole.yaml이라는 새 파일에 매니페스트를 저장합니다.kubectl get role myrole -n audit -o yaml > namespaces/audit/myrole.yaml
myrole.yaml파일을 수정합니다.name과namespace를 제외하고metadata키 아래에 있는 모든 필드를 삭제합니다.rules.verbs목록 필드에서get다음에list동사를 추가합니다.
변경사항을 저장합니다. 이제 파일 콘텐츠가 다음과 같습니다.
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: myrole namespace: audit rules: - apiGroups: - "" resources: - pods verbs: - get - list변경사항을 저장소에 커밋합니다.
Config Management Operator가 커밋을 감지할 때까지 잠시 기다립니다. Anthos Config Management에서
myrole역할을 관리하는지 확인하려면kubectl describe를 다시 실행합니다.kubectl describe role myrole -n audit
객체가 Anthos Config Management에 의해 관리됨을 나타내는 configmanagement.gke.io/managed: enabled 주석을 확인합니다. 또한 객체에 대한 최근 구성 변경을 초래한 저장소 내 경로 및 파일 이름을 보여주는 주석과 커밋을 나타내는 Git 해시를 확인합니다.
Name: myrole
Labels: app.kubernetes.io/managed-by=configmanagement.gke.io
Annotations: configmanagement.gke.io/cluster-name: example-cluster-name
configmanagement.gke.io/managed: enabled
configmanagement.gke.io/source-path: namespaces/audit/myrole.yaml
configmanagement.gke.io/token: 0836805a09f160f12aa934b9042527e7283c7030
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
pods [] [] [get list]
관리형 객체 관리 중지
이 예시는 기존 객체 관리 시작의 myrole 역할과 같이 Anthos Config Management가 현재 관리 중인 객체 관리를 중지하는 방법을 보여줍니다.
저장소의 로컬 클론에서
namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml파일을 수정하고 아래 굵게 표시된 텍스트와 일치하는annotations:섹션을 추가합니다.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: job-creators subjects: - kind: User name: sam@foo-corp.com apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: job-creator apiGroup: rbac.authorization.k8s.io annotations: configmanagement.gke.io/managed: disabled파일을 저장합니다.
변경사항으로 Git 커밋을 만들고 저장소에 커밋을 푸시합니다.
Anthos Config Management가 새 커밋을 감지하고 적용할 때까지 잠시 기다립니다.
다음 명령어를 사용하여
job-creatorsRoleBinding의 모든 주석을 나열합니다. 가독성을 위해 잘린 상태로 출력이 표시됩니다.kubectl get rolebinding job-creators -n audit -o yaml
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: annotations: configmanagement.gke.io/cluster-name: my-cluster configmanagement.gke.io/managed: disabled configmanagement.gke.io/source-path: namespaces/viewers-rolebinding.yaml configmanagement.gke.io/sync-token: fabdb51587d51a81c7e419eeb983aafcf293dc83 ...
현재 객체가 중지되어 있음을 확인한 후에 구성을 삭제하고 현재 관리되지 않는 객체가 네임스페이스에서 삭제되지 않았음을 확인합니다. 객체를 다시 관리하려면 구성을 다시 만들어야 합니다. 이로 인해 객체를 관리 중지하고 구성을 저장소에 남겨둘 수 있습니다.
이제 객체가 관리되지 않으므로 새 클러스터나 기존 클러스터에서 객체가 생성 또는 재생성되지 않으며 객체가 존재하더라도 삭제되지 않습니다. 이전에 관리를 중지한 객체의 관리를 다시 시작하려면 다음 예시인 이전에 관리를 중지한 객체 관리 재개를 참조하세요.
이전에 관리를 중지한 객체 관리 재개
다음 예시에서는 기존 객체 관리 중지와 같이 이전에 관리에서 삭제한 객체의 관리를 다시 시작하는 방법을 보여줍니다. 여기서는 job-creators RoleBinding의 구성이 삭제되지 않았다고 가정합니다.
마지막 커밋에서 저장소의
job-creatorsRoleBinding을 삭제한 경우 다음 단계를 수행합니다.git revert를 사용하여 마지막 커밋을 되돌립니다.git revert HEAD~1되돌리기 작업을 확인하라는 메시지가 표시됩니다.
되돌리기 커밋을 저장소로 푸시합니다.
git push
저장소의 로컬 클론에서
namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml파일을 수정하고configmanagement.gke.io/managed: disabled주석을 삭제합니다. 파일을 저장합니다.변경사항을 커밋하고 푸시합니다. Anthos Config Management는 다음을 수행합니다.
- 변경사항을 감지합니다.
configmanagement.gke.io/managed: enabled주석을 적용합니다. 이제 객체가 관리됩니다.- 다른 모든 관리 객체와 마찬가지로 구성을 적용합니다.
객체가 현재 관리되고 있는지 확인하려면 주석을 나열합니다.
kubectl get rolebinding job-creators -n audit -o yaml
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: annotations: configmanagement.gke.io/cluster-name: my-cluster configmanagement.gke.io/managed: enabled ...
네임스페이스 관리 중지
다른 모든 유형의 객체를 관리 중지할 때와 같은 방식으로 네임스페이스 관리를 중지할 수 있습니다. 네임스페이스 내에서 다른 리소스 관리를 중지하려면 다음 단계를 수행합니다.
네임스페이스 구성 및 동일한 네임스페이스의 모든 구성에
configmanagement.gke.io/managed:disabled주석을 추가합니다.변경사항을 커밋하고 저장소로 푸시합니다. Operator가 저장소와 동기화될 때까지 기다립니다.
저장소에서 관리되지 않는 리소스를 삭제합니다.
관리형 구성의 구성이 관리되지 않는 네임스페이스 디렉터리에 있는 경우 syncer는 오류를 로깅하지만 다른 구성은 계속 정상적으로 동기화됩니다.
다음 단계
- 구성 만들기에 대해 알아보기