Config Management Operator는 Kubernetes 클러스터에서 Anthos Config Management를 관리하는 컨트롤러입니다. 다음 단계에 따라 Anthos Config Management를 사용하여 관리하려는 각 클러스터에 Operator를 설치하고 구성하세요.
시작하기 전에
이 섹션에서는 Anthos Config Management에서 지원되는 클러스터를 등록하기 전에 충족해야 하는 기본 요건을 설명합니다.
로컬 환경
- Anthos Config Management에는 활성 Anthos 권한이 필요합니다. 자세한 정보는 Anthos에 대한 가격 책정을 참조하세요.
이 안내에서 사용되는
gcloud,gsutil,kubectl명령어를 제공하는 Cloud SDK를 설치해야 합니다.Cloud SDK는
kubectl을 기본으로 설치하지 않습니다.kubectl을 설치하려면 다음 명령어를 사용하세요.gcloud components install kubectl
nomos status하위 명령어를 사용하여 설치 및 설정 중에 문제를 감지할 수 있도록nomos명령어를 설치합니다.Anthos Config Management의 구성요소를 다운로드하려면
gcloud auth login명령어를 사용하여 Google Cloud에 인증해야 합니다.
클러스터에 연결하려면
kubectl명령어를 구성해야 합니다. GKE 및 Anthos clusters on VMware 클러스터는 다른 방식으로 단계를 수행해야 합니다.프로젝트에 Anthos API가 사용 가능해야 합니다.
gcloud
Anthos API를 사용 설정하려면 다음 명령어를 실행합니다.
gcloud services enable anthos.googleapis.com
콘솔
클러스터
클러스터는 GKE v1.14.x 또는 Anthos clusters on VMware v1.0.0.x 이상을 실행해야 합니다.
Connect를 사용하여 클러스터를 Anthos 환경에 등록해야 합니다. 프로젝트 환경은 Google Cloud 외부의 클러스터를 포함하여 Anthos의 일부로 클러스터와 워크로드를 보고 관리하는 통합 방법을 제공합니다. Anthos 요금은 등록된 클러스터에만 적용됩니다. 클러스터 등록에서 클러스터를 등록하는 방법을 확인할 수 있습니다.
권한
Anthos Config Management를 설치하는 Google Cloud 사용자에게는 클러스터에서 새 역할을 만들 수 있는 ID 및 액세스 관리(IAM) 권한이 필요합니다.
클러스터 등록
Anthos Config Management에서 클러스터를 등록하려면 다음 안내를 따르세요.
연산자 배포
Google Cloud Console을 사용하여 Config Management Operator를 설치하면 Operator가 자동으로 배포됩니다. git-creds 보안 비밀 만들기를 진행합니다.
모든 기본 요건을 충족하는지 확인한 후 YAML 매니페스트를 다운로드하고 적용하여 연산자를 배포할 수 있습니다.
다음 명령어를 사용하여 최신 버전의 연산자 CRD를 다운로드합니다. 특정 버전을 대신 다운로드하려면 다운로드를 참조하세요.
gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
CRD를 적용합니다.
kubectl apply -f config-management-operator.yaml
이 방법이 실패하면 문제해결을 참조하세요.
연산자에게 Git에 대한 읽기 전용 액세스 권한 부여
연산자가 저장소에 커밋된 구성을 읽고 해당 구성을 클러스터에 적용하기 위해서는 Git 저장소에 대한 읽기 전용 액세스 권한이 필요합니다. 사용자 인증 정보가 필요한 경우 등록된 각 클러스터의 git-creds 보안 비밀에 저장됩니다.
저장소에 읽기 전용 액세스를 위한 인증이나 승인이 필요하지 않은 경우 git-creds 보안 비밀을 만들 필요가 없습니다. Anthos Config Management 구성으로 건너뛰고 SecretType을 none으로 설정할 수 있습니다.
대부분의 사용자는 저장소에 대한 읽기 액세스가 제한되므로 사용자 인증 정보를 만들어야 합니다. Anthos Config Management 는 다음 인증 메커니즘을 지원합니다.
- SSH 키 쌍
- cookiefile
- 개인 액세스 토큰
- Google 서비스 계정(Google 소스 저장소만)
- 인증이 필요하지 않음
저장소에서 지원하는지 여부에 따라 선택할 수 있는 메커니즘이 다릅니다. 모든 메커니즘을 사용할 수 있는 경우에는 SSH 키 쌍을 사용하는 것이 좋습니다. 이 문서 작성 시점에서 GitHub, Cloud Source Repositories, Bitbucket 모두 SSH 키 쌍 사용을 지원합니다. 조직에서 저장소를 호스팅하고 지원되는 인증 방법을 모르는 경우 관리자에게 문의하세요.
사용자 인증 정보를 만든 후에는 생성된 사용자 인증 정보를 클러스터에 보안 비밀로 추가합니다. 보안 비밀을 만드는 방법은 인증 방법에 따라 다릅니다. 자세한 내용은 아래의 인증 방법 섹션을 참조하세요.
아래 옵션 중에서 가장 적절한 저장소 승인 방법을 선택합니다. 선택하는 방법에 따라 연산자 구성 시 사용하는 secretType이 결정됩니다.
SSH 키 쌍 사용
저장소에서 SSH 키 쌍을 사용하여 승인할 수 있는 경우, 이 섹션의 단계를 수행하여 보안 비밀을 만들 수 있습니다. 그렇지 않으면 대신 cookiefile 사용 안내를 수행합니다.
SSH 키 쌍은 공개 키 파일과 비공개 키 파일로 구성됩니다. 일반적으로 공개 키에는 .pub 확장자가 있습니다.
연산자가 Git 저장소를 인증할 수 있도록 SSH 키 쌍을 만듭니다. 이 키 쌍은 저장소를 클론하거나 읽기 위해 저장소를 인증해야 할 때 필요합니다. 보안 관리자가 키 쌍을 제공하는 경우에는 이 단계를 건너뛸 수 있습니다. 보안 및 규정 준수 요구사항에 따라 모든 클러스터에 단일 키 쌍을 사용하거나 클러스터별로 키 쌍을 사용할 수 있습니다.
다음 명령어를 실행하면 4,096비트 RSA 키가 생성됩니다. 낮은 값은 권장되지 않습니다.
[GIT REPOSITORY USERNAME]과/path/to/[KEYPAIR-FILENAME]을 연산자가 저장소에 인증하는 데 사용할 값으로 바꿉니다. GitHub와 같은 타사 Git 저장소 호스트를 사용하는 경우에는 별도의 계정을 사용하고, Cloud Source Repositories를 사용하는 경우에는 서비스 계정을 사용하는 것이 좋습니다.ssh-keygen -t rsa -b 4096 \ -C "[GIT REPOSITORY USERNAME]" \ -N '' \ -f [/path/to/KEYPAIR-FILENAME]
저장소가 새로 생성된 공개 키를 인식하도록 구성합니다. Git 호스팅 업체의 문서를 참조하세요. 편의를 위해 다음과 같은 많이 사용되는 Git 호스팅 업체용 안내가 포함되어 있습니다.
- Cloud Source Repositories
- Bitbucket
- GitHub 단일 GitHub 저장소에 대한 읽기 전용 액세스 권한을 제공하려면 별도의 배포 키를 만드는 것이 좋습니다.
- Gitlab
클러스터의 새 보안 비밀에 비공개 키를 추가합니다. /path/to/[KEYPAIR-PRIVATE-KEY-FILENAME]이 표시되는 비공개 키(
.pub서픽스가 없는 키)의 이름으로 바꿉니다.kubectl create secret generic git-creds \ --namespace=config-management-system \ --from-file=ssh=/path/to/[KEYPAIR-PRIVATE-KEY-FILENAME]
로컬 디스크에서 비공개 키를 삭제하거나 키를 보호합니다.
cookiefile 사용
저장소가 승인하는 데 SSH 키 쌍 사용을 지원하지 않는 경우 cookiefile 또는 개인 액세스 토큰을 사용할 수 있습니다.
이 섹션의 단계에 따라 cookiefile 보안 비밀 자료를 만드세요.
cookiefile을 획득하는 절차는 저장소 구성에 따라 다릅니다. 예는 Cloud Source Repositories에서 정적 사용자 인증 정보 생성에 대한 문서를 참조하세요.
사용자 인증 정보는 보통 사용자 홈 디렉터리의 .gitcookies 파일에 저장되거나 보안 관리자를 통해 제공받을 수 있습니다.
cookiefile을 만들고 얻은 후에는 클러스터의 새 보안 비밀에 추가합니다. /path/to/[COOKIEFILE]을 적절한 경로와 파일 이름으로 바꿉니다.
kubectl create secret generic git-creds \ --namespace=config-management-system \ --from-file=cookie_file=/path/to/[COOKIEFILE]
cookiefile 콘텐츠가 로컬에서 계속 필요하면 이 콘텐츠를 보호해야 합니다. 그렇지 않으면 삭제합니다.
토큰 사용
조직에서 SSH 키 사용을 허용하지 않으면 토큰을 대신 사용하는 것이 좋습니다. Anthos Config Management에서는 GitHub의 개인 액세스 토큰(PAT) 또는 Bitbucket의 앱 비밀번호를 토큰으로 사용할 수 있습니다.
토큰을 사용하여 보안 비밀을 만들려면 다음 단계를 완료합니다.
GitHub 또는 Bitbucket을 사용하여 토큰을 만듭니다.
토큰을 만들고 얻은 후에는 클러스터의 새 보안 비밀에 추가합니다. [USERNAME]을 원하는 사용자 이름으로 바꾸고 [TOKEN]을 이전 단계에서 만든 토큰으로 바꿉니다.
kubectl create secret generic git-creds \ --namespace="config-management-system" \ --from-literal=username=[USERNAME] \ --from-literal=token=[TOKEN]토큰이 로컬에서 계속 필요하면 토큰을 보호합니다. 그렇지 않으면 삭제합니다.
Google 소스 저장소로 Google 서비스 계정 사용
저장소가 Google 소스 저장소에 있는 경우 secretType: gcenode를 사용하여 Anthos Config Management에 관리형 클러스터와 동일한 프로젝트에 있는 저장소에 대한 액세스 권한을 부여할 수 있습니다.
시작하기 전에 다음 기본 요건을 충족하는지 확인하세요.
클러스터의 Compute Engine 기본 서비스 계정
PROJECT_NUMBER-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
클러스터의 노드 액세스 범위에는
cloud-source-repos-ro가 포함되어야 합니다. 클러스터를 만들 때 지정된--scopes목록에cloud-source-repos-ro를 포함하거나 클러스터를 만들 때cloud-platform범위를 사용하면 됩니다.gcloud container clusters create example-cluster --scopes=cloud-platform
이러한 기본 요건이 충족되면 연산자를 구성할 때 spec.git.syncRepo를 원하는 Google 소스 저장소의 URL로 설정합니다. 예를 들면 다음과 같습니다.
gcloud source repos list
REPO_NAME PROJECT_ID URL
my-repo my-project https://source.developers.google.com/p/my-project/r/my-repo-csr
다음이 필요합니다.
spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
워크로드 아이덴티티로 Google 소스 저장소 사용
클러스터에서 워크로드 아이덴티티가 사용 설정된 경우 secretType:
gcenode를 사용하려면 추가 단계가 필요합니다. 위 단계를 완료한 후 Kubernetes 서비스 계정과 Google 서비스 계정 간에 IAM 정책 binding을 만듭니다. 이 binding을 사용하면 Anthos Config Management 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
마지막으로 Compute Engine 기본 서비스 계정의 이메일 주소를 사용하여 Anthos Config Management Kubernetes 서비스 계정에 annotation을 추가합니다.
kubectl annotate serviceaccount -n config-management-system importer \ iam.gke.io/gcp-service-account=[PROJECT_NUMBER]-compute@developer.gserviceaccount.com
인증 사용 안함
저장소에 읽기 전용 액세스에 대한 인증이 필요하지 않으면 계속 진행하여 연산자를 구성하고 spec.git.secretType을 none으로 설정할 수 있습니다.
연산자 구성
kubectl 또는 Google Cloud Console을 사용하여 클러스터의 Operator를 구성할 수 있습니다.
kubectl
연산자의 동작을 구성하려면 ConfigManagement CustomResource의 구성 파일을 만든 다음 kubectl apply 명령어를 사용하여 적용합니다.
예를 들어 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: my-cluster
git:
syncRepo: git@github.com:my-github-username/csp-config-management.git
syncBranch: 1.0.0
secretType: ssh
policyDir: "foo-corp"
spec 필드에 추가할 수 있는 필드의 전체 목록은 다음 Git 저장소 구성 섹션을 참조하세요. spec 필드 이외의 구성 값을 변경하지 마세요.
구성을 적용하려면 kubectl apply 명령어를 사용합니다.
kubectl apply -f config-management.yaml
각 클러스터 또는 각 유형의 클러스터마다 별도의 구성 파일을 만들어야 할 수도 있습니다. --context 옵션을 사용하여 클러스터를 지정할 수 있습니다.
kubectl apply -f config-management1.yaml --context=cluster-1
Git 저장소 구성
| 키 | 설명 |
|---|---|
spec.git.syncRepo |
정보 소스로 사용할 Git 저장소의 URL입니다. 필수 항목입니다. |
spec.git.syncBranch |
동기화할 저장소의 분기입니다. 기본값: master |
spec.git.policyDir |
동기화할 저장소의 최상위 수준을 나타내는 Git 저장소 내의 경로입니다. 기본값: 저장소의 루트 디렉터리 |
spec.git.syncWait |
연속 동기화 간격(초)입니다. 기본값: 15 |
spec.git.syncRev |
체크아웃할 Git 버전(태그 또는 해시)입니다. 기본값: HEAD |
spec.git.secretType |
Git 저장소에 액세스할 수 있도록 구성된 보안 비밀 유형입니다. ssh, cookiefile, token, gcenode 또는 none 중 하나입니다. 필수 항목입니다. |
spec.sourceFormat |
unstructured로 설정하면 비계층적 저장소를 구성합니다. 기본값: hierarchy |
Git 저장소의 프록시 구성
조직 보안 정책에 따라 HTTP(S) 프록시를 통해 트래픽을 라우팅해야 하는 경우 프록시 URI를 사용하여 Git 호스트와 통신하도록 Anthos Config Management를 구성할 수 있습니다.
| 키 | 설명 |
|---|---|
spec.git.proxy.httpProxy |
httpProxy는 Git 저장소에 액세스하는 데 사용되는 HTTP_PROXY env 변수를 정의합니다. |
spec.git.proxy.httpsProxy |
httpsProxy는 Git 저장소에 액세스하는 데 사용되는 HTTPS_PROXY env 변수를 정의합니다. |
httpProxy 및 httpsProxy 필드가 모두 지정되면 httpProxy가 무시됩니다.
ConfigManagement 객체 동작 구성
| 키 | 설명 |
|---|---|
spec.clusterName |
ClusterSelector에서 클러스터를 함께 그룹화하는 데 사용되는 클러스터의 사용자 정의 이름입니다. Anthos Config Management 설치 내에서 고유합니다. |
통합을 위한 구성
이 필드는 Config Connector 및 Policy Controller와 통합할 수 있습니다.
| 키 | 설명 |
|---|---|
spec.configConnector.enabled |
true이면 Config Connector를 설치합니다. 기본값은 false입니다. |
spec.policyController.enabled |
true이면 Policy Controller를 활성화합니다. 기본값은 false입니다. |
spec.policyController.templateLibraryInstalled |
true이면 제약조건 템플릿 라이브러리를 설치합니다. 기본값은 true입니다. |
Console
제한사항
Google Cloud Console에서 Anthos Config Management 구성에는 다음과 같은 제한사항이 있습니다.
- 다음 항목을 설치하거나 구성할 수 없습니다.
- Policy Controller
- 구성 커넥터
- 계층 구조 컨트롤러
- 구성 동기화 구성 옵션의 하위 집합만 지원됩니다. 지원되지 않는 구성 동기화 구성에는 다음이 포함됩니다.
spec.git.proxyspec.git.secretType: gcenodespec.git.secretType: tokenspec.sourceFormat
이러한 옵션을 사용하려면 Cloud Console을 사용하면 안 됩니다.
Operator 구성
Cloud Console에서 Operator를 구성하려면 다음 단계를 완료합니다.
Google Cloud Console에서 Anthos Config Management 메뉴로 이동합니다.
등록된 클러스터를 선택하고 구성을 클릭합니다.
ACM용 Git 저장소 인증 섹션에서 다음을 완료합니다.
보안 비밀 유형에 다음 중 하나를 선택합니다.
- 없음 저장소에서 읽기 전용 액세스에 인증이 필요하지 않으면 선택합니다.
- SSH
- cookiefile
token또는gcenode를 선택하려면kubectl을 사용하여 Operator를 구성합니다.계속을 클릭합니다.
클러스터의 ACM 설정 섹션에서 다음을 완료합니다.
- URL 필드에 정보 소스로 사용할 Git 저장소의 URL을 추가합니다. 필수 입력란입니다.
- 분기 필드에 동기화할 저장소의 분기를 추가합니다. 기본값은 마스터입니다. 필수 입력란입니다.
- 태그/커밋 필드에서 체크아웃할 Git 버전(태그 또는 해시)을 추가합니다. 기본값은
HEAD입니다. - 고급 옵션 표시를 클릭합니다.
- 정책 디렉터리 필드에서 동기화할 정책 계층 구조의 맨 위에 저장소 내 경로를 추가합니다. 기본값은 저장소의 루트 디렉터리입니다.
- 동기화 대기 필드에서 연속 동기화 간격(초)을 추가합니다. 기본값은 15초입니다.
완료를 클릭합니다. Anthos Config Management 메뉴로 돌아갑니다. 몇 분 후에 페이지를 새로 고치면 구성한 클러스터 옆에 있는 상태 열에
Synced가 표시되어야 합니다.
설치 확인
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를 사용하여 Anthos Config Management가 이벤트를 작성했는지 확인할 수도 있습니다.
kubectl get events -n kube-system
누락되거나 잘못된 git-creds 보안 비밀 등 즉시 감지되지 않는 잘못된 구성이 있을 수 있습니다. 문제 해결 단계는 이 주제의 문제 해결 섹션에서 유효하지만 잘못된 ConfigManagement 객체를 참조하세요.
문제해결
불충분한 CPU
kubectl get events의 출력에는 FailedScheduling 유형의 이벤트가 포함될 수 있습니다. 이벤트는 다음과 같습니다.
LAST SEEN TYPE REASON OBJECT MESSAGE
9s Warning FailedScheduling pod/config-management-operator-74594dc8f6 0/1 nodes are available: 1 Insufficient cpu.
이 오류를 해결하려면 다음 중 하나를 수행해야 합니다.
- 기존 GKE 노드 풀에 노드 추가
- 더 큰 노드로 노드 풀 만들기
오류: 추가 권한 부여 시도
kubectl apply -f config-management-operator.yaml
Error from server (Forbidden): error when creating "config-management-operator.yaml": clusterroles.rbac.authorization.k8s.io "config-management-operator" is forbidden: attempt to grant extra privileges: [...] ruleResolutionErrors=[]
이 오류는 현재 사용자가 설치에 필요한 권한을 가지고 있지 않음을 나타냅니다. GKE의 역할 기반 액세스 제어 기본 요건 섹션을 참조하세요.
유효하지만 잘못된 ConfigManagement 객체
YAML 또는 JSON 구문 오류가 아닌 ConfigManagement 객체의 문제로 인해 설치에 실패하면 ConfigManagement 객체가 클러스터에서 인스턴스화될 수 있지만 올바르게 작동하지 않을 수도 있습니다. 이 경우 nomos status 명령어를 사용하여 ConfigManagement 객체의 오류를 확인할 수 있습니다.
문제가 없는 유효한 설치 상태는 PENDING 또는 SYNCED입니다.
유효하지 않은 설치 상태는 NOT CONFIGURED이며, 다음 오류 중 하나가 표시됩니다.
missing git-creds Secretmissing required syncRepo fieldgit-creds Secret is missing the key specified by secretType
향후에 다른 오류가 추가될 수 있습니다.
문제를 해결하려면 구성 오류를 수정합니다. 오류 유형에 따라 ConfigManagement 매니페스트를 클러스터에 다시 적용해야 할 수도 있습니다.
git-creds 보안 비밀을 만드는 것을 잊어버린 경우에는 보안 비밀을 생성하는 즉시 Operator에서 이를 감지하므로 구성을 다시 적용할 필요가 없습니다.
업그레이드
이 섹션에서는 현재 버전으로 업그레이드하기 위한 일반적인 안내를 제공합니다. 업그레이드하기 전에 출시 노트에서 구체적인 안내를 확인하세요.
등록된 각 클러스터에 다음 명령어를 실행합니다.
새 버전에 대한 연산자 매니페스트 및
nomos명령어를 다운로드합니다.연산자 매니페스트를 적용합니다.
kubectl apply -f config-management-operator.yaml
이 명령어는 연산자 이미지를 업데이트합니다. Kubernetes는 새 버전을 검색하고 새 버전을 사용하여 연산자 Pod를 다시 시작합니다. 연산자가 시작되면 새 이미지에 번들된 매니페스트 집합을 적용하는 조정 루프를 실행합니다. 이렇게 하면 각 구성요소 Pod가 업데이트되고 다시 시작됩니다.
모든 클라이언트의
nomos또는nomos.exe명령어를 새 버전으로 바꿉니다. 이렇게 하면nomos명령어가 항상 등록된 모든 클러스터의 상태를 가져오고 클러스터 구성을 확인할 수 있습니다.
클러스터에서 연산자 삭제
클러스터에서 연산자를 삭제하려면 다음 안내를 따르세요. Anthos Config Management를 사용하여 더 이상 관리하지 않으려는 각 클러스터에 다음 단계를 수행해야 합니다.
클러스터에서 ConfigManagement 객체를 삭제합니다.
kubectl delete configmanagement --all
다음 작업이 수행됩니다.
- Anthos Config Management가 클러스터에 만든 ClusterRole과 ClusterRoleBinding 모두 클러스터에서 삭제됩니다.
- Anthos Config Management가 설치한 허용 컨트롤러 구성이 모두 삭제됩니다.
config-management-system네임스페이스의 콘텐츠는 삭제되지만git-creds보안 비밀은 삭제되지 않습니다. Anthos Config Management는config-management-system네임스페이스가 없으면 작동하지 않습니다. 생성되거나 수정된 클러스터에서 Anthos Config Management가 만들거나 수정한 모든 CustomResourceDefinition이 삭제됩니다. 연산자를 실행하는 데 필요한 CRD(CustomResourceDefinition)는 Kubernetes의 관점에서 연산자를 설치한 사용자가 추가했으므로 아직 있습니다. 다음 단계에서 삭제에 대한 정보를 제공합니다.
이 시점에서 연산자는 클러스터에 여전히 존재하지만 아무것도 수행하지 않습니다. Anthos clusters on VMware를 사용하는 경우 Operator를 수동으로 삭제할 수 없습니다.
GKE를 사용 중이고 더 이상 Anthos Config Management를 사용하지 않기로 결정한 경우 다음 단계에 따라 Operator를 제거할 수 있습니다.
이전 단계에서 ConfigManagement 객체를 삭제한 후
config-management-system네임스페이스가 비어 있는지 확인합니다.kubectl -n config-management-system get all명령어가No resources found.를 반환할 때까지 기다립니다.config-management-system네임스페이스를 삭제합니다.kubectl delete ns config-management-system
ConfigManagement CustomResourceDefinition을 삭제합니다.
kubectl delete crd configmanagements.configmanagement.gke.io
kube-system네임스페이스에서 모든 Anthos Config Management 객체를 삭제합니다.kubectl -n kube-system delete all -l k8s-app=config-management-operator
다음 단계
- Anthos Config Management 구성에 사용되는
gcloud명령어 알아보기