전제 조건
이 페이지의 내용
빠른 시작 또는 배포서버 절차를 사용하여 다중 Kubernetes 클러스터 MongoDB deployment 를 만들기 전에 다음 작업을 완료하세요.
빠른 시작과 관련된 전제 조건에 학습 보려면 빠른 시작 전제 조건을 참조하세요.
지원되는 hardware 아키텍처 검토
MongoDB Enterprise Kubernetes Operator 리포지토리 복제
MongoDB Enterprise Kubernetes Operator MongoDB 엔터프라이즈 KubernetesOperator 리포지토리 를 복제합니다:
git clone https://github.com/mongodb/mongodb-enterprise-kubernetes.git
환경 변수 설정
이 예시 와 같이 클러스터를 배포 하는 클러스터 이름으로 환경 변수를 설정합니다.
export MDB_CENTRAL_CLUSTER_FULL_NAME="mdb-central" export MDB_CLUSTER_1_FULL_NAME="mdb-1" export MDB_CLUSTER_2_FULL_NAME="mdb-2" export MDB_CLUSTER_3_FULL_NAME="mdb-3"
Go 및 Helm 설치
다음 도구를 설치합니다.
Kubernetes 역할 및 역할 바인딩 이해
다중 Kubernetes 클러스터 MongoDB deployment 를 사용하려면 특정 Kubernetes 역할 설정하다 인 ClusterRoles 가 있어야합니다. , RoleBindings, ClusterRoleBindings 및 ServiceAccounts 다음 중 한 가지 방법으로 구성할 수 있습니다.
MongoDB Plugin 을 사용하여 필요한 객체를 자동으로 생성하고 이를 멀티 Kubernetes 클러스터 MongoDB deployment 내의 적절한 클러스터에 적용 하는 방법을 설명하는 Multi-Kubernetes-Cluster Quick Start 를 따르세요.
Helm 사용 각 멤버 클러스터 에 필요한 Kubernetes 역할 및 서비스 계정을 구성합니다.
helm template --show-only \ templates/database-roles.yaml \ mongodb/enterprise-operator \ --set namespace=mongodb | \ kubectl apply -f - \ --context=$MDB_CLUSTER_1_FULL_NAME \ --namespace mongodb helm template --show-only \ templates/database-roles.yaml \ mongodb/enterprise-operator \ --set namespace=mongodb | \ kubectl apply -f - \ --context=$MDB_CLUSTER_2_FULL_NAME \ --namespace mongodb helm template --show-only \ templates/database-roles.yaml \ mongodb/enterprise-operator \ --set namespace=mongodb | \ kubectl apply -f - \ --context=$MDB_CLUSTER_3_FULL_NAME \ --namespace mongodb Kubernetes 객체
.yaml
파일을 수동으로 생성하고kubectl apply
명령을 사용하여 다중 Kubernetes 클러스터 MongoDB deployment 에 필요한 Kubernetes 역할 및 서비스 계정을 추가합니다. 이는 고도로 자동화된 특정 워크플로에 필요할 수 있습니다. MongoDB 는 샘플 구성 파일을 제공합니다.네임스페이스의 하위 집합으로 범위가 지정된 사용자 지정 리소스의 경우:
cluster 전체 네임스페이스로 범위가 지정된 사용자 지정 리소스의 경우:
중앙 클러스터를 위한 ClusterRoles, ClusterRoleBindings 및 ServiceAccounts
멤버 cluster에 대한 clusterRoles, clusterRoleBindings 및 ServiceAccounts
각 파일은 여러 리소스를 정의합니다. 배포를 지원하려면 다음 필드에서 자리 표시자 값을 바꿔야 합니다.
subjects.namespace
각RoleBinding
또는ClusterRoleBinding
리소스에서metadata.namespace
각ServiceAccount
리소스에서
정의를 수정한 후 각 파일에 대해 다음 명령을 실행하여 적용합니다.
kubectl apply -f <fileName>
배포서버 범위 설정
기본값 멀티 클러스터 Kubernetes Operator의 범위는 네임스페이스 로 지정됩니다. 에 설치합니다. Kubernetes Operator는 Kubernetes Operator와 동일한 네임스페이스 에 배포된 MongoDBMultiCluster
리소스 를 조정합니다.
멀티 cluster 빠른 시작 의 일부로 MongoDB kubectl 플러그인 kubectl mongodb
을 실행하고 플러그인 설정을 수정하지 않는 경우 플러그인은 다음을 수행합니다.
멀티-Kubernetes 클러스터 MongoDB deployment 의 모든 멤버 클러스터를 포함하는
mongodb-enterprise-operator-member-list
이라는 기본값 ConfigMap을 생성합니다. 이 이름은 하드 코딩되어 있으며 변경할 수 없습니다. 알려진 문제를 참조하세요.서비스 계정 생성 , Roles, ClusterRoles, RoleBindings 및 ClusterRoleBindings 중앙 클러스터와 각 멤버 클러스터에 있습니다.
서비스 계정에 대한 올바른 권한을 적용합니다.
앞의 설정을 사용하여 다중 Kubernetes 클러스터 MongoDB deployment를 생성합니다.
Kubernetes Operator가 다중 Kubernetes 클러스터 MongoDB deployment 를 생성하면 Kubernetes Operator는 MongoDB
mongodb
네임스페이스 에서 리소스를 감시하기 시작합니다. .
하위 집합 또는 모든 네임스페이스에 배포할 수 있는 올바른 권한으로 Kubernetes 연산자를 구성하려면 다음 명령을 실행하고 Kubernetes 연산자가 감시할 네임스페이스를 지정합니다.
kubectl mongodb multicluster setup \ --central-cluster="${MDB_CENTRAL_CLUSTER_FULL_NAME}" \ --member-clusters="${MDB_CLUSTER_1_FULL_NAME},${MDB_CLUSTER_2_FULL_NAME},${MDB_CLUSTER_3_FULL_NAME}" \ --member-cluster-namespace="mongodb2" \ --central-cluster-namespace="mongodb2" \ --create-service-account-secrets \ --cluster-scoped="true"
여러 또는 모든 네임스페이스 에 다중 Kubernetes cluster MongoDB deployment를 설치하는 경우 를 사용하여 Kubernetes Operator를 다음과 같이 구성할 수 있습니다.
참고
단일 Kubernetes 연산자 인스턴스를 설치 및 설정하고 겹치지 않는 서로 다른 네임스페이스 하위 집합에서 하나, 다중 또는 모든 사용자 지정 리소스를 감시하도록 구성합니다. MongoDB는 둘 이상의 Kubernetes 연산자 인스턴스 실행을 지원하나요?도 참조하세요.
여러 네임스페이스의 리소스 보기
다중 Kubernetes 클러스터 MongoDB 배포의 범위를 여러 네임스페이스 로 설정한 경우 멀티 MongoDB
Kubernetes 클러스터 MongoDB 배포에서 이러한 네임스페이스의 리소스를 감시하도록 Kubernetes Operator를 구성할 수 있습니다.
spec.template.spec.containers.name.env.name:WATCH_NAMESPACE
mongodb-enterprise.yaml 파일에서 MongoDB Enterprise Kubernetes Operator Github 을(를)Kubernetes 설정합니다. 파일을 리포지토리에서 연산자가 감시하려는 쉼표로 구분된 네임스페이스 목록으로 복사합니다.
WATCH_NAMESPACE: "$namespace1,$namespace2,$namespace3"
다음 명령을 실행하고 마지막 줄의 값을 Kubernetes 연산자가 감시할 네임스페이스로 바꿉니다.
helm upgrade \ --install \ mongodb-enterprise-operator-multi-cluster \ mongodb/enterprise-operator \ --namespace mongodb \ --set namespace=mongodb \ --version <mongodb-kubernetes-operator-version>\ --set operator.name=mongodb-enterprise-operator-multi-cluster \ --set operator.createOperatorServiceAccount=false \ --set operator.createResourcesServiceAccountsAndRoles=false \ --set "multiCluster.clusters={$MDB_CLUSTER_1_FULL_NAME,$MDB_CLUSTER_2_FULL_NAME,$MDB_CLUSTER_3_FULL_NAME}" \ --set operator.watchNamespace="$namespace1,$namespace2,$namespace3"
모든 네임스페이스의 리소스 보기
다중 Kubernetes 클러스터 MongoDB deployment 의 범위를 모든 네임스페이스 로 mongodb
설정하다 하는 경우 기본값 네임스페이스 대신 MongoDB
멀티 Kubernetes 클러스터 MongoDB deployment 의 모든 네임스페이스에서 리소스를 감시하도록 Kubernetes Operator를 구성할 수 있습니다.
spec.template.spec.containers.name.env.name:WATCH_NAMESPACE
mongodb-enterprise.yaml 에서 을(를)"*"
설정합니다. . YAML 파일에서 별표(*
) 주위에 큰따옴표("
)를 포함해야 합니다.
WATCH_NAMESPACE: "*"
다음 명령을 실행합니다:
helm upgrade \ --install \ mongodb-enterprise-operator-multi-cluster \ mongodb/enterprise-operator \ --namespace mongodb \ --set namespace=mongodb \ --version <mongodb-kubernetes-operator-version>\ --set operator.name=mongodb-enterprise-operator-multi-cluster \ --set operator.createOperatorServiceAccount=false \ --set operator.createResourcesServiceAccountsAndRoles=false \ --set "multiCluster.clusters={$MDB_CLUSTER_1_FULL_NAME,$MDB_CLUSTER_2_FULL_NAME,$MDB_CLUSTER_3_FULL_NAME}" \ --set operator.watchNamespace="*"
외부 연결 계획: 서비스 메시를 사용해야 하나요?
서비스 메시를 사용하면 서로 다른 Kubernetes 클러스터에 배포된 복제본 세트 멤버 간의 클러스터 간 통신이 가능합니다. 서비스 메시를 사용하면 다중 Kubernetes 클러스터 MongoDB 배포 생성이 크게 간소화되며, 여러 Kubernetes 클러스터에 MongoDB 를 배포하는 데 권장되는 방법입니다. 그러나 IT 조직 에서 서비스 메시를 사용하지 않는 경우, 서비스 메시 없이도 다중 Kubernetes 클러스터 MongoDB deployment 에 복제본 세트 를 배포 할 수 있습니다.
환경에 따라 다음을 수행합니다.
서비스 메시를 사용할 수 있는 경우 Istio를 설치합니다.
서비스 메시를 사용할 수 없는 경우:
Kubernetes 연산자는 연결을 어떻게 설정하나요?
배포 유형에 관계없이 Kubernetes의 MongoDB 배포는 다음 연결을 설정해야 합니다.
파드의 Ops Manager MongoDB Agent에서
mongod
프로세스까지, MongoDB deployment의 라이프사이클 관리 및 모니터링을 활성화합니다.파드의 Ops Manager MongoDB Agent에서 Ops Manager 인스턴스로 이동하여 자동화를 활성화합니다.
모든
mongod
프로세스 사이에서 복제를 허용합니다.
Kubernetes 연산자가 MongoDB 리소스를 배포할 때 배포 유형에 따라 다음과 같은 방식으로 이러한 연결 요구 사항을 처리합니다.
단일 Kubernetes 클러스터 배포서버 에서 Kubernetes Operator는 복제본 세트 의 호스트 이름을 헤드리스 서비스 의FQDN 으로 구성합니다. . 이는 다음과 같이 MongoDB 인스턴스 를 호스팅하는 각 파드의 직접 IP 주소 의 DNS 를 파드의 FQDN 으로 확인하는
<pod-name>.<replica-set-name>-svc.<namespace>.svc.cluster.local
단일 서비스입니다.서비스 메시를 사용하는 다중 Kubernetes 클러스터 MongoDB deployment 에서 Kubernetes Operator는 Kubernetes 클러스터 의 각 MongoDB 복제본 세트 멤버에 대해 별도의 StatefulSet를 생성합니다. 서비스 메시를 사용하면 고유한 Kubernetes 클러스터의
mongod
프로세스 간 통신이 가능합니다.서비스 메시를 사용하면 다중 Kubernetes 클러스터 MongoDB deployment 를 통해 다음을 수행할 수 있습니다.
Kubernetes cluster 전반에서 글로벌 DNS 호스트 이름 확인을 달성하고 cluster 간에 연결을 설정합니다. 각 Kubernetes cluster의 각 MongoDB deployment Pod에 대해 Kubernetes 연산자는
MongoDBMultiCluster
리소스의spec.duplicateServiceObjects: true
구성을 통해 ClusterIP 서비스를 생성합니다. 각 프로세스에는 이 서비스의 FQDN<pod-name>-svc.<namespace>.svc.cluster.local
에 정의된 호스트 이름이 있습니다. 이러한 호스트 이름은 DNS에서 각 구성원 cluster에 있는 서비스의 ClusterIP로 확인됩니다.서로 다른 Kubernetes cluster의 파드 간에 통신을 설정합니다. 결과적으로 서로 다른 cluster에서 호스팅되는 복제본 세트 멤버는 이러한 cluster에서 단일 복제본 세트를 형성합니다.
서비스 메시가 없는 다중 Kubernetes 클러스터 MongoDB deployment 에서 Kubernetes Operator는 다음
MongoDBMultiCluster
리소스 설정을 사용하여 모든mongod
프로세스를 외부에 노출합니다. 이를 통해 고유한 Kubernetes 클러스터 간에 호스트 이름의 DNS 확인이 가능하고 이러한 클러스터를 연결하는 네트워크를 통해 라우팅된 파드 간에 연결이 설정됩니다.
선택 사항: Istio 설치
Istio 설치 서로 다른 네트워크의 멀티 프라이머리 모드에서 , Istio 문서를 사용합니다. Istio는 DNS 확인을 간소화하고 멀티 Kubernetes 클러스터 MongoDB 배포에서 멤버 Kubernetes 클러스터 간에 클러스터 간 통신을 설정하는 데 도움이 되는 서비스 메시입니다. 서비스 메시를 사용하기로 선택한 경우 이를 설치해야 합니다. 서비스 메시를 사용할 수 없는 경우 이 섹션을 건너뛰고 외부 도메인을 사용하고 외부 연결을 활성화하도록 DNS를 구성하세요.
또한 install_istio_separate_network 예제 스크립트 를 제공합니다. . 이 스크립트는 Istio 설명서를 기반으로 하며 다양한 네트워크에서 다중 프라이머리 모드 를 사용하는 설치 예시를 제공합니다. . 향후 Istio 릴리스에서는 스크립트의 유지 관리가 보장되지 않습니다. 스크립트를 사용하기로 선택한 경우 멀티클러스터 설치에 대한 최신 Istio 설명서를 검토하세요. , 필요한 경우 설명서 및 배포에 맞게 스크립트를 조정합니다. 다른 서비스 메시 솔루션을 사용하는 경우 DNS 확인이 용이하도록 별도의 네트워크를 구성하기 위한 자체 스크립트를 생성합니다.
외부 도메인 및 DNS 구역을 통한 외부 연결 활성화
서비스 메시를 사용하지 않는 경우 다음을 수행하여 mongod
프로세스와 Ops Manager MongoDB Agent 간에 외부 연결을 허용합니다.
다중 Kubernetes 클러스터 MongoDB deployment 를 만들 때 spec.clusterSpecList.externalAccess.externalDomain 을 사용합니다. 설정을 사용하여 외부 도메인을 지정하고 Kubernetes Operator에
mongod
프로세스의 호스트 이름을 다음 패턴 으로 구성하도록 지시합니다.<pod-name>.<externalDomain> 참고
새 배포에 대해서만 외부 도메인을 지정할 수 있습니다. 다중 Kubernetes 클러스터 MongoDB deployment 를 구성한 후에는 외부 도메인을 변경할 수 없습니다.
이러한 방식으로 외부 도메인을 구성하면 Ops Manager MongoDB 에이전트와
mongod
프로세스가 이 도메인을 사용하여 서로 연결합니다.Kubernetes 연산자가 Kubernetes cluster의 각 파드에 대해 생성하는 외부 서비스를 사용자 지정합니다. spec.externalAccess 에서 글로벌 구성을 사용하세요. spec.clusterSpecList.externalAccess.externalService 의 설정 및 Kubernetes cluster별 재정의 설정.
DNS 구역 에서 Pod 호스트 이름을 구성하여
mongod
프로세스 를 호스팅하는 각 Kubernetes Pod가 다중 Kubernetes 클러스터 MongoDB deployment 에서 다른mongod
프로세스에 대한 외부 연결을 설정할 수 있도록 합니다. 포트<pod-name>.<externalDomain>
프로세스mongod
27017 기본값 데이터베이스 포트) 및 27018 ( 데이터베이스 포트 + 1). 포트 27017 및 27018 에서 TCP 트래픽을 허용하도록 방화벽 규칙을 구성해야 할 수도 있습니다.
이러한 사전 조건을 완료한 후에 는 서비스 메시 없이 다중 Kubernetes cluster를 배포할 수 있습니다.
cluster 간 연결 확인
이 절차의 단계에 따라 Kubernetes cluster 전체에서 서비스 FQDN에 연결할 수 있는지 확인합니다.
이 예시 에서는 sample-service.yaml 파일 에 정의된 샘플 애플리케이션 을 배포 합니다. 두 개의 Kubernetes 클러스터에 걸쳐 있습니다.
에 샘플 애플리케이션 CLUSTER_1
을 배포합니다.
kubectl apply --context="${CTX_CLUSTER_1}" \ -f sample-service.yaml \ -l version=v1 \ -n sample
이(가) 실행 CLUSTER_1
확인합니다.
CLUSTER_1
호스팅 Pod가 Running
상태인지 확인합니다.
kubectl get pod --context="${CTX_CLUSTER_1}" \ -n sample \ -l app=helloworld
에 샘플 애플리케이션 CLUSTER_2
을 배포합니다.
kubectl apply --context="${CTX_CLUSTER_2}" \ -f sample-service.yaml \ -l version=v2 \ -n sample
이(가) 실행 CLUSTER_2
확인합니다.
CLUSTER_2
호스팅 Pod가 Running
상태인지 확인합니다.
kubectl get pod --context="${CTX_CLUSTER_2}" \ -n sample \ -l app=helloworld
CLUSTER_1
가 에 연결할 수 있는지 CLUSTER_2
확인합니다.
CLUSTER_1
에 Pod를 배포하고 CLUSTER_2
에서 샘플 애플리케이션에 연결할 수 있는지 확인합니다.
kubectl run --context="${CTX_CLUSTER_1}" \ -n sample \ curl --image=radial/busyboxplus:curl \ -i --tty \ curl -sS helloworld2.sample:5000/hello
다음 예시와 유사한 출력이 표시됩니다.
Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
CLUSTER_2
가 에 연결할 수 있는지 CLUSTER_1
확인합니다.
CLUSTER_2
에 Pod를 배포하고 CLUSTER_1
에서 샘플 애플리케이션에 연결할 수 있는지 확인합니다.
kubectl run --context="${CTX_CLUSTER_2}" \ -n sample \ curl --image=radial/busyboxplus:curl \ -i --tty \ curl -sS helloworld1.sample:5000/hello
다음 예시와 유사한 출력이 표시됩니다.
Hello version: v1, instance: helloworld-v1-758dd55874-6x4t8
Ops Manager 배포를 위한 요구 사항 검토
빠른 시작의 일환으로 MongoDB Ops Manager 리소스 를 중앙 클러스터 에 배포 합니다.
TLS 암호화 연결을 위한 준비
TLS 암호화를 사용하여 다중 Kubernetes 클러스터 MongoDB 배포를 보호하려는 경우, 다음 작업을 완료하여 내부 클러스터 인증을 활성화하고 멤버 클러스터 및 MongoDB Agent에 대한 TLS 인증서를 생성합니다.
참고
TLS 인증서에 서명할 때 사용한 CA 인증서와 키가 있어야 합니다.
Kubernetes 서비스에 대한 TLS 인증서를 생성합니다.
다음 옵션 중 하나를 사용합니다.
Kubernetes Operator가 배포서버 서버의 각 파드에 대해 생성하는 서비스의 호스트 이름을 포함하는 와일드카드 TLS 인증서를 생성합니다.
와일드카드 인증서를 생성하는 경우, 예를 들어 재해 복구를 위해 Kubernetes 구성원 cluster에서 노드를 확장하거나 리밸런싱할 때 동일한 인증서를 계속 사용할 수 있습니다.
예를 예시, 다음 형식과 유사한 호스트 이름을 SAN 에 추가합니다.
*.<namespace>.svc.cluster.local Kubernetes Operator가 각 멤버 클러스터 의 각 파드에 해당하여 생성하는 각 Kubernetes 서비스에 대해 인증서에 SAN을 추가합니다. TLS 인증서에서 각 Kubernetes 서비스의 SAN 은 다음 형식을 사용해야 합니다.
<metadata.name>-<member_cluster_index>-<n>-svc.<namespace>.svc.cluster.local 여기서
n
범위는0
~clusterSpecList[member_cluster_index].members - 1
입니다.
멤버 Kubernetes 클러스터에 대한 TLS 인증서 생성 속도를 높이기 위해 setup_tls 스크립트 를 제공합니다. . 스크립트의 유지 관리를 보장하지 않습니다. 스크립트 를 사용하기로 선택한 경우 테스트하고 필요에 맞게 조정합니다. 스크립트 는 다음을 수행합니다.
연결된 클러스터 에
cert-manager
네임스페이스 를 생성하고 cert-manager 를cert-manager
설치합니다. Helm 사용 네임스페이스 에 있습니다.mkcert 를 사용하여 로컬 CA 를 설치합니다.
downloads.mongodb.com
에서 TLS 인증서를 다운로드 하여 CA 파일 이름 및ca-chain
와 연결합니다.ca-chain
파일을 포함하는 ConfigMap을 만듭니다.cert-manager가 인증서를 생성하는 데 사용하는
Issuer
리소스 를 만듭니다.cert-manager가 인증서의 키 객체 를 만드는 데 사용하는
Certificate
리소스 를 만듭니다.
스크립트 를 사용하려면 다음을 수행합니다.
SAN 호스트 이름에 대한 TLS 인증서를 생성합니다.
다음 옵션 중 하나를 사용합니다.
SAN 에서 생성한 모든 externalDomain 을 포함하는 와일드카드 TLS 인증서를 생성합니다. 예를 예시, 다음 형식과 유사한 호스트 이름을 SAN 에 추가합니다.
*.cluster-0.example.com, *.cluster-1.example.com 와일드카드 인증서를 생성하는 경우, 재해 복구와 예시 Kubernetes 멤버 클러스터에서 노드를 확장하다 하거나 리밸런싱할 때 와일드카드 인증서를 계속 사용할 수 있습니다.
SAN 의 각 MongoDB 복제본 세트 멤버 호스트 이름에 대한 TLS 인증서를 생성합니다. 예를 예시, 다음과 유사한 호스트 이름을 SAN 에 추가합니다.
my-replica-set-0-0.cluster-0.example.com, my-replica-set-0-1.cluster-0.example.com, my-replica-set-1-0.cluster-1.example.com, my-replica-set-1-1.cluster-1.example.com 특정 호스트 이름이 모두 포함된 개별 TLS 인증서를 생성하는 경우, 재해 복구와 예시 Kubernetes 멤버 클러스터에서 노드를 확장하다 하거나 리밸런싱할 때마다 새 인증서를 생성해야 합니다.
중요
Kubernetes Operator는 다음을 사용합니다.kubernetes.io/tls 시크릿을 사용하여 MongoDB Ops Manager 및 리소스에 대한 TLS 인증서 및 비공개 키를 저장 MongoDB 합니다. Kubernetes Operator 버전 1 부터 시작됩니다.17.0, Kubernetes Operator는 Opaque 시크릿 으로 저장된 연결된 PEM 파일을 지원 하지 않습니다.
GitOps 또는 kubectl MongoDB 플러그인 선택
GitOps 환경에서 MongoDBMultiCluster
리소스 배포에 필요한 리소스 파일을 만들고 유지 관리하도록 선택할 수 있습니다.
GitOps 워크플로를 사용하는 경우 역할 기반 액세스 제어(RBAC) 를 자동으로 구성하는 kubectl MongoDB 플러그인 은 사용할 수 없습니다. 그리고 중앙 클러스터 가 해당 멤버 클러스터와 통신할 수 있도록 하는 kubeconfig 파일 을 생성합니다. 대신 GitOps에 대한 리소스 구성의 절차 및 예제를 기반으로 RBAC 및 kubeconfig
파일을 구성하기 위한 자체 자동화 를 수동으로 구성하거나 빌드 해야 합니다.
다음 필수 구성 요소 섹션에서는 GitOps를 사용하지 않는 경우 kubectl MongoDB 플러그인을 설치 하거나 사용하는 경우 GitOps 에 대한 리소스를 구성 하는 방법을 설명합니다.
kubectl MongoDB 플러그인 설치
kubectl mongodb
플러그인을 사용하여 다음을 수행합니다.
참고
GitOps를 사용하는 경우 kubectl mongodb
플러그인을 사용할 수 없습니다. 대신 GitOps에 대한 리소스 구성의 절차를 따르세요.
kubectl mongodb
플러그인을 설치하려면 다음을 수행합니다.
원하는 Kubernetes 연산자 패키지 버전을 다운로드합니다.
MongoDB Enterprise Kubernetes Operator Repository의릴리스 페이지 에서 Kubernetes 원하는 Operator 패키지 버전을 다운로드합니다.
패키지 이름에 kubectl-mongodb_{{ .Version }}_{{ .Os }}_{{ .Arch }}.tar.gz
패턴을 사용합니다.
다음 패키지 중 하나를 사용합니다.
kubectl-mongodb_{{ .Version }}_darwin_amd64.tar.gz
kubectl-mongodb_{{ .Version }}_darwin_arm64.tar.gz
kubectl-mongodb_{{ .Version }}_linux_amd64.tar.gz
kubectl-mongodb_{{ .Version }}_linux_arm64.tar.gz
플러그인 바이너리를 찾아 원하는 kubectl mongodb
대상에 복사합니다.
다음 예와 같이 압축을 푼 디렉토리에서 kubectl-mongodb
바이너리를 찾아 Kubernetes 연산자 사용자의 PATH 내 원하는 대상으로 이동합니다.
mv kubectl-mongodb /usr/local/bin/kubectl-mongodb
이제 다음 명령을 사용하여 kubectl mongodb
플러그인을 실행할 수 있습니다.
kubectl mongodb multicluster setup kubectl mongodb multicluster recover
지원되는 플래그에 대해 자세히 알아보려면 MongoDB kubectl 플러그인 참고를 참조하세요.
GitOps를 위한 리소스 구성
GitOps 워크플로를 사용하는 경우,kubectl MongoDB 플러그인 을 사용하여 역할 기반 액세스 제어(RBAC) 를 자동으로 구성할 수 없습니다. 또는 중앙 클러스터 가 해당 멤버 클러스터와 통신할 수 있도록 하는 kubeconfig 파일 을 사용할 수 있습니다. 대신 다음 리소스 파일을 수동으로 구성하고 적용 하거나 아래 정보를 기반으로 자체 자동화 를 빌드 해야 합니다.
참고
플러그인이 다음 단계를 자동화하는 방법을 학습 kubectl mongodb
보려면 코드 를 Github 확인하세요. 에서 .
GitOps에 대해 RBAC 및 kubeconfig
를 구성하려면 다음을 수행합니다.
RBAC 리소스를 생성하고 각 cluster에 적용합니다.
다음 RBAC 리소스 예시 사용 직접 만들 수 있습니다. 이러한 RBAC 리소스에 학습 보려면 Kubernetes 역할 및 역할 바인딩 이해를 참조하세요.
GitOps를 사용하여 중앙 및 멤버 클러스터에 적용 하려면 Argo CD와 같은 도구를 사용할 수 있습니다.
ConfigMap 파일을 만들어 적용합니다.
Kubernetes Operator는 ConfigMap 을 사용하여 멤버 클러스터를 추적 합니다. 파일. 다음 예시 ConfigMap을 복사, 수정 및 적용 합니다.
apiVersion: v1 kind: ConfigMap data: cluster1: "" cluster2: "" metadata: namespace: <namespace> name: mongodb-enterprise-operator-member-list labels: multi-cluster: "true"
Kubernetes Operator에 대한 시크릿을 구성합니다.kubeconfig
중앙 클러스터 에서 실행되는 Kubernetes Operator는 Kubernetes API 를 통해 멤버 클러스터의 파드와 통신합니다. 이 작업을 수행하려면 Kubernetes Operator에 kubeconfig 가 필요합니다. 멤버 클러스터의 서비스 계정 토큰이 포함된 파일 입니다. 다음 단계에 따라 이 kubeconfig
파일 을 만듭니다.
서비스 계정 목록 가져오기 Kubernetes Operator의 네임스페이스 에 구성됩니다. 예를 예시 기본값
mongodb
네임스페이스 를 사용하기로 선택한 경우 다음 명령을 사용하여 서비스 계정을 가져올 수 있습니다.kubectl get serviceaccounts -n mongodb 구성원 cluster에 속한 각 서비스 계정의 비밀을 가져옵니다.
kubectl get secret <service-account-name> -n mongodb -o yaml 각 서비스 계정 시크릿에서 CA 인증서와 토큰을 복사합니다. 예를 들어, 다음 예와 같이 시크릿에서
<ca_certificate>
및<token>
를 복사합니다.apiVersion: v1 kind: Secret metadata: name: my-service-account namespace: mongodb data: ca.crt: <ca_certificate> token: <token> 중앙 클러스터 에 대한 다음
kubeconfig
예시 를 복사하고 아래 나열된 명령을 실행 하여 서비스 계정 시크릿에서 복사한<ca_certificate>
및<token>
로 자리 표시자를 바꿉니다.apiVersion: v1 clusters: - cluster: certificate-authority: server: https:// name: kind-e2e-cluster-1 - cluster: certificate-authority: server: https:// name: kind-e2e-cluster-2 contexts: - context: cluster: kind-e2e-cluster-1 namespace: mongodb user: kind-e2e-cluster-1 name: kind-e2e-cluster-1 - context: cluster: kind-e2e-cluster-2 namespace: mongodb user: kind-e2e-cluster-2 name: kind-e2e-cluster-2 kind: Config users: - name: kind-e2e-cluster-1 user: token: - name: kind-e2e-cluster-2 user: token: 다음
kubectl
명령을 올바른 값으로 실행 하여 예시kubeconfig
파일 을 업데이트 합니다.kubectl config --kubeconfig=kubeconfig set-cluster kind-e2e-cluster-1 --certificate-authority=<cluster-1-ca.crt> kubectl config --kubeconfig=kubeconfig set-cluster kind-e2e-cluster-2 --certificate-authority=<cluster-2-ca.crt> kubectl config --kubeconfig=kubeconfig set-credentials kind-e2e-cluster-1 --token=<cluster-1-token> kubectl config --kubeconfig=kubeconfig set-credentials kind-e2e-cluster-2 --token=<cluster-2-token> 참조 Helm 차트 에 표시된 대로 Kubernetes 연산자에 마운트하는 중앙 클러스터 에 시크릿을 생성합니다. . 예를 예시 다음과 같습니다.
kubectl --context="${CTX_CENTRAL_CLUSTER}" -n <operator-namespace> create secret --from-file=kubeconfig=<path-to-kubeconfig-file> <kubeconfig-secret-name>