기존 클러스터 객체 관리
구성 동기화는 클러스터 객체를 관리할 때 객체와 객체에 영향을 미치는 저장소의 객체 구성 집합을 감시하고 이들이 동기화되도록 합니다. 이 주제에서는 기존 객체 관리를 시작하는 방법과 객체를 삭제하지 않고 현재 관리 중인 객체의 관리를 중지하는 방법을 설명합니다.
클러스터의 객체는 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) 관리 객체 삭제 등 세 가지 개별적인 흐름이 있습니다.
- 객체 관리를 시작하려고 합니다. 객체에 매니페스트가 있나요? 즉, 객체 구성이 저장소에 있나요?
- 아니요: 객체의 구성을 만듭니다. 구성 동기화는
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주석을 적용한 후 구성을 적용합니다.
- 아니요: 객체의 구성을 만듭니다. 구성 동기화는
- 객체 관리를 중지하지만 객체가 삭제되지 않기 원합니다.
- 저장소에서 객체의 구성을 수정하고
configmanagement.gke.io/managed: disabled주석을 설정합니다. 구성 변경이 감지되면 구성 동기화가 객체 관리를 중지합니다.
- 저장소에서 객체의 구성을 수정하고
- 객체 관리를 중지하고 객체를 삭제하고 싶습니다.
- 저장소에서 객체의 구성을 삭제합니다. 이전에 관리된 객체의 구성을 삭제하면 구성 동기화는 구성이 적용되는 모든 클러스터 또는 네임스페이스에서 객체를 삭제합니다.
구성 동기화는 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 주석을 이 객체에 적용합니다. 그러나 구성 동기화는 주석 처리되지 않은 객체를 수정하거나 클러스터에서 삭제하지 않습니다. 이 내용은 시간 경과에 따른 구성 작업의 다이어그램에 설명되어 있습니다.
다음 예시에서는 기존 역할 객체를 관리하는 방법을 보여줍니다. 먼저 역할을 수동으로 만든 후 구성 동기화로 관리를 시작합니다.
gamestore네임스페이스에myrole역할을 만듭니다.kubectl create role -n gamestore myrole --verb=get --resource=pods
myrole역할에서 부여되는 권한을 확인합니다.kubectl describe role -n gamestore myrole
Name: myrole Labels: <none> Annotations: <none> PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get]이 역할에는
get포드에 대한 권한만 있습니다.이 시점에서 이 역할은 클러스터에 있지만 구성 동기화는 이 역할을 알지 못합니다.
- 터미널에서 저장소의 로컬 클론으로 이동합니다.
다음 명령어를 사용하여
myrole의 YAML 매니페스트를 만들고gamestore-myrole.yaml이라는 새 파일에 매니페스트를 저장합니다.kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
gamestore-myrole.yaml파일을 수정합니다.name과namespace를 제외하고metadata키 아래에 있는 모든 필드를 삭제합니다.rules.verbs목록 필드에서get다음에list동사를 추가합니다.
변경사항을 저장합니다. 이제 파일 콘텐츠가 다음과 같습니다.
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: myrole namespace: gamestore rules: - apiGroups: - "" resources: - pods verbs: - get - list변경사항을 저장소에 커밋합니다.
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 역할).
저장소의 로컬 클론에서
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파일을 저장합니다.
변경사항으로 Git 커밋을 만들고 저장소에 커밋을 푸시합니다.
구성 동기화가 새 커밋을 감지하고 적용할 때까지 잠시 기다립니다.
다음 명령어를 사용하여
gamestore-webstore-adminRoleBinding의 주석과 라벨이 모두 비어 있는지 확인합니다. 구성 동기화는 객체의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의 구성이 삭제되지 않았다고 가정합니다.
마지막 커밋에서 저장소의
gamestore-webstore-adminRoleBinding을 삭제한 경우 다음 단계를 수행합니다.git revert를 사용하여 마지막 커밋을 되돌립니다.git revert HEAD~1되돌리기 작업을 확인하라는 메시지가 표시됩니다.
되돌리기 커밋을 저장소로 푸시합니다.
git push
저장소의 로컬 클론에서
config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml파일을 수정하고configmanagement.gke.io/managed: disabled주석을 삭제합니다. 파일을 저장합니다.변경사항을 커밋하고 푸시합니다. 구성 동기화가 다음을 수행합니다.
- 변경사항을 감지합니다.
configmanagement.gke.io/managed: enabled주석과configsync.gke.io/resource-id주석을 적용합니다. 이제 객체가 관리됩니다.- 다른 모든 관리 객체와 마찬가지로 구성을 적용합니다.
객체가 현재 관리되고 있는지 확인하려면 주석을 나열합니다.
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 ...
네임스페이스 관리 중지
다른 모든 유형의 객체를 관리 중지할 때와 같은 방식으로 네임스페이스 관리를 중지할 수 있습니다. 네임스페이스 내에서 다른 리소스 관리를 중지하려면 다음 단계를 수행합니다.
네임스페이스 구성 및 동일한 네임스페이스의 모든 구성에
configmanagement.gke.io/managed:disabled주석을 추가합니다. 네임스페이스의 모든 객체에 이 주석이 있어야 합니다.변경사항을 커밋하고 저장소로 푸시합니다. Operator가 저장소와 동기화될 때까지 기다립니다.
저장소에서 관리되지 않는 리소스를 삭제합니다.
관리형 구성의 구성이 관리되지 않는 네임스페이스 디렉터리에 있는 경우 조정자는 오류를 로깅하지만 다른 구성은 계속 정상적으로 동기화됩니다.
관리형 리소스 삭제
정보 소스에서 개별 리소스를 삭제하면 구성 동기화가 다음에 정보 소스에서 동기화될 때 해당 객체가 클러스터에서 삭제됩니다. 또는 구성 동기화 버전 1.16.0 이상에서 객체를 일괄 삭제할 수 있는 삭제 전파를 사용 설정할 수 있습니다.
개별 객체 삭제
구성 동기화의 기본 동작으로 정보 소스에서 객체를 삭제하면 구성 동기화가 정보 소스에서 동기화할 때 해당 객체가 클러스터에서 삭제됩니다.
구성 동기화 상태 또는 특정 객체의 상태를 확인하는 방법에는 여러 가지가 있습니다.
nomos status사용.kubectl을 사용하여 리소스 검사.gcloud alpha anthos config sync resources명령어 사용하기- 구성 동기화 대시보드 사용.
객체 일괄 삭제
기본적으로 RootSync 또는 RepoSync를 삭제하면 구성 동기화가 이전에 정보 소스에서 적용된 객체를 삭제합니다. 구성 동기화 버전 1.16.0 이상에서는 삭제 전파를 사용 설정하여 대신 이전에 적용된 모든 객체를 삭제할 수 있습니다.
RootSync 또는 RepoSync 객체에서 삭제 전파를 사용 설정한 다음 해당 객체를 삭제하면 구성 동기화는 해당 RootSync 또는 RepoSync에서 관리하는 모든 객체를 자동으로 삭제합니다.
삭제 전파를 사용하면 새 네임스페이스 또는 클러스터로 마이그레이션하거나 데모 또는 실험 후 정리하거나 애플리케이션을 제거하는 경우와 같이 리소스를 더 쉽게 삭제할 수 있습니다.
삭제 전파 옵션
삭제 전파는 기본적으로 사용 중지됩니다. 삭제 전파를 사용 설정하려면 다음 예시와 같이 RootSync 또는 RepoSync 객체에 configsync.gke.io/deletion-propagation-policy: Foreground 주석을 추가합니다.
# 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에서 관리되는 모든 객체를 삭제하는 방법을 보여줍니다.
RootSync
주석을 RootSync 객체에 적용하여 삭제 전파를 사용 설정합니다.
kubectl patch RootSync example-rootsync \ --namespace config-management-system \ --type merge \ --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'RootSync 객체를 삭제하고 구성 동기화에서 삭제될 때까지 기다립니다.
kubectl delete RootSync example-rootsync --namespace config-management-system --waitRootSync 삭제를 완료하는 데 몇 분 정도 걸릴 수 있습니다.
RepoSync
RepoSync 객체에 주석을 적용하여 삭제 전파를 사용 설정합니다.
kubectl patch RepoSync example-reposync \ --namespace example-namespace \ --type merge \ --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'RepoSync 객체를 삭제하고 구성 동기화가 삭제될 때까지 기다립니다.
kubectl delete RepoSync example-reposync --namespace example-namespace --waitRepoSync 삭제는 완료하는 데 몇 분 정도 걸릴 수 있습니다.
Kubernetes 객체 삭제 방지
구성 동기화에서 관리되는 Git 저장소에서 Kubernetes 객체를 삭제하면 이 객체는 새 커밋이 클러스터에 동기화될 때 클러스터에서 삭제됩니다.
해당 구성이 Git 저장소에서 삭제될 때 구성 동기화에서 객체를 삭제하지 못하도록 하려면 다음 단계를 수행하면 됩니다.
Git 저장소의 객체 구성에
client.lifecycle.config.k8s.io/deletion: detach주석을 추가합니다.Git 저장소에 변경사항을 커밋하고 푸시합니다.
변경사항이 클러스터에 동기화될 때까지 기다립니다.
이 단계를 완료하면 구성 동기화는 Git 저장소에서 구성이 삭제될 때 클러스터에서 이 객체를 삭제하지 않지만 다른 클라이언트에서 여전히 삭제할 수 있습니다.
정보 소스의 객체 무시
구성 동기화가 정보 소스의 객체를 무시하도록 하는 것이 좋습니다. 예를 들어 kpt 함수 구성은 클러스터에 적용되지 않아야 합니다.
구성 동기화에서 무시하려는 객체의 경우 config.kubernetes.io/local-config: "true" 주석을 객체에 추가하세요. 이 주석을 추가한 후에는 구성 동기화가 이 객체를 정보 소스에서 삭제된 것처럼 무시합니다. local-config 주석이 "false" 이외의 값으로 설정된 리소스는 "true"로 설정된 것처럼 취급되고 무시됩니다.