샤딩된 클러스터 배포
이 페이지의 내용
참고
이 페이지의 어느 곳에서나 Ops Manager라고 표시된 곳에서는 Cloud Manager로 대체할 수 있습니다.
중요
Kubernetes Operator를 사용하여 Cloud Manager 및 Ops Manager 버전 6.0.x 이상과 함께 MongoDB 리소스를 배포할 수 있습니다.
Atlas Operator 를 사용하여 MongoDB 리소스를 Atlas에 배포할 수 있습니다.
경고
Kubernetes Operator는 중재자 노드를 지원하지 않습니다.
샤딩된 클러스터 대규모 데이터 세트에 대한 수평적 확장을 제공하며, 여러 서버 그룹에 데이터 세트를 분산하여 높은 처리량의 작업을 가능하게 합니다.
샤딩에 대해 자세히 알아보려면 MongoDB 매뉴얼의 샤딩 소개를 참조하세요.
이 절차에 따라 Ops Manager가 관리하는 새 샤딩된 클러스터를 배포할 수 있습니다. 나중에 Ops Manager를 사용하여 샤드를 추가하고 클러스터에서 다른 유지 관리 작업을 수행할 수 있습니다.
고려 사항
Kubernetes 내부 및 외부에 모니터링 에이전트 배포하지 않기
Kubernetes 네트워크 변환으로 인해, Kubernetes 외부의 모니터링 에이전트 는 Kubernetes 내부의 MongoDB 인스턴스를 모니터 할 수 없습니다. 이러한 이유로 동일한 프로젝트 에서 k8및 k가 아닌8배포는 지원되지 않습니다. 별도의 프로젝트를 사용합니다.
연결 암호화 여부 선택
Kubernetes Operator를 통해 샤딩된 클러스터를 배포하는 경우 TLS 인증서를 사용하여 연결을 암호화할지 여부를 선택해야 합니다.
TLS-Encrypted 연결에 대한 절차는 다음과 같습니다.
클러스터 샤드 간에 TLS로 암호화된 연결을 설정합니다.
클라이언트 애플리케이션과 MongoDB deployment 간에 TLS로 암호화된연결을 설정합니다.
TLS 암호화를 위해 유효한 인증서가 필요합니다.
Non-Encrypted Connections에 대한 절차는 다음과 같습니다.
클러스터 샤드 간의 연결을 암호화하지 않습니다.
클라이언트 애플리케이션과 MongoDB deployment 간의 연결을 암호화하지 않습니다.
TLS-encrypted 연결을 사용하는 배포보다 설정 요구 사항이 적습니다.
참고
Kubernetes cluster에서 MongoDB의 독립형 인스턴스를 보호할 수 없습니다.
복제본 세트 에 대한 TLS 암호화 를 설정하다 하려면 복제본 세트 배포를 참조하세요.
복제본 세트 연결을 TLS로 암호화할지 여부에 따라 적절한 탭을 선택합니다.
전제 조건
객체 를 사용하여 샤딩된 클러스터 를 배포 하려면 다음을 수행해야 합니다.
MongoDB Enterprise Kubernetes Operator를 보유하거나 설치합니다.
Kubernetes Operator ConfigMap을 생성하거나 작성합니다.
Kubernetes Operator에 대한 자격 증명을 생성하거나 다른 시크릿 저장 도구를 구성합니다.
참고
단일 클러스터 Kubernetes 배포에 시크릿이 저장되지 않도록 하려면 모든 시크릿 을 마이그레이션할 수 있습니다. 비밀 저장 도구 에 저장합니다. 여러 Kubernetes 클러스터에 대한 배포는 HashiCorp Vault 와 같은 비밀 저장소 도구에 비밀을 저장하는 것을 지원하지 않습니다. .
다음 구성 요소 각각에 대해 하나의 TLS 인증서를 생성합니다.
샤드 샤딩된 클러스터 의 각 샤드 . 인증서에 샤드 멤버를 호스팅하는 각 Kubernetes pod에 대한 SAN을 추가해야 합니다.
TLS 인증서에서 각 샤드 의 SAN 은 다음 형식을 사용해야 합니다.
<pod-name>.<metadata.name>-sh.<namespace>.svc.cluster.local config 서버. config 서버를 호스팅하는 각 Kubernetes pod에 대한 SAN을 인증서에 추가해야 합니다.
TLS 인증서에서 각 config 서버 pod의 SAN 은 다음 형식을 사용해야 합니다.
<pod-name>.<metadata.name>-cs.<namespace>.svc.cluster.local mongos인스턴스. 인증서에 를 호스팅하는mongos각 Kubernetes pod에 대한 SAN 을 추가해야 합니다.TLS 인증서에서 각 파드의
mongosSAN은 이 형식을 사용해야 합니다.<pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local
프로젝트의 MongoDB Agent입니다. MongoDB Agent 인증서의 경우 다음 요구 사항을 충족하는지 확인하세요.
TLS 인증서의 일반 이름이 비어 있지 않습니다.
각 TLS 인증서의 결합된 조직 및 조직 구성 단위는 복제본 세트 멤버에 대한 TLS 인증서의 조직 및 조직 구성 단위와 다릅니다.
TLS 인증서에 서명할 때 사용한 CA 인증서와 키가 있어야 합니다.
중요
Kubernetes Operator는 다음을 사용합니다.kubernetes.io/tls 시크릿을 사용하여 MongoDB Ops Manager 및 리소스에 대한 TLS 인증서 및 비공개 키를 저장 MongoDB 합니다. Kubernetes Operator 버전 1 부터 시작됩니다.17.0, Kubernetes Operator는 Opaque 시크릿 으로 저장된 연결된 PEM 파일을 지원 하지 않습니다.
객체 를 사용하여 샤드 클러스터를 배포하려면 , 다음을 수행해야 합니다.
MongoDB Enterprise Kubernetes Operator를 보유하거나 설치합니다.
Kubernetes Operator ConfigMap을 생성하거나 작성합니다.
Kubernetes Operator에 대한 자격 증명을 생성하거나 다른 시크릿 저장 도구를 구성합니다.
참고
단일 클러스터 Kubernetes 배포에 시크릿이 저장되지 않도록 하려면 모든 시크릿 을 마이그레이션할 수 있습니다. 비밀 저장 도구 에 저장합니다. 여러 Kubernetes 클러스터에 대한 배포는 HashiCorp Vault 와 같은 비밀 저장소 도구에 비밀을 저장하는 것을 지원하지 않습니다. .
샤딩된 클러스터 배포
네임스페이스 kubectl 를 기본값 으로 구성합니다.
아직 실행하지 않았다면 다음 명령을 실행하여 생성한 네임스페이스에서 kubectl 명령을 모두 실행합니다.
참고
다중 Kubernetes 클러스터 MongoDB deployment에서 MongoDB Ops Manager 리소스를 배포하는 경우:
context을 중앙 클러스터의 이름(예:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME")으로 설정합니다.--namespace를 다중 Kubernetes 클러스터 MongoDB 배포에 사용한 것과 동일한 범위 (예:kubectl config --namespace "mongodb"로 설정합니다.
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
샤드의 TLS 인증서에 대한 시크릿을 생성합니다.
kubectl 명령을 실행하여 샤딩된 클러스터의 샤드 인증서를 저장하는 새 시크릿을 생성합니다.
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \ --cert=<shard-0-tls-cert> \ --key=<shard-0-tls-key> kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \ --cert=<shard-1-tls-cert> \ --key=<shard-1-tls-key>
HashiCorp Vault 를 사용하는 경우 대신 볼트 시크릿을 생성 할 수 있습니다.
config 서버의 TLS 인증서에 대한 시크릿을 생성합니다.
kubectl 명령을 실행하여 샤딩된 클러스터 config 서버의 인증서를 저장하는 새 시크릿을 생성합니다.
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \ --cert=<config-tls-cert> \ --key=<config-tls-key>
HashiCorp Vault 를 사용하는 경우 대신 볼트 시크릿을 생성 할 수 있습니다.
mongos 서버의 TLS 인증서에 대한 시크릿을 생성합니다.
이 kubectl 명령을 실행하여 샤딩된 클러스터 mongos 인증서를 저장하는 새 시크릿을 생성합니다.
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \ --cert=<mongos-tls-cert> \ --key=<mongos-tls-key>
HashiCorp Vault 를 사용하는 경우 대신 볼트 시크릿을 생성 할 수 있습니다.
에이전트의 TLS 인증서에 대한 시크릿을 생성합니다.
이 kubectl 명령을 실행하여 에이전트의 TLS 인증서를 저장하는 새 시크릿을 만듭니다.
kubectl create secret tls <prefix>-<metadata.name>-agent-certs \ --cert=<agent-tls-cert> \ --key=<agent-tls-key>
HashiCorp Vault 를 사용하는 경우 대신 볼트 시크릿을 생성 할 수 있습니다.
ConfigMap을 생성하여 CA를 배포서버 서버와 연결합니다.
이 kubectl 명령을 실행하여 CA 를 샤딩된 클러스터 에 연결하고 MongoDB 리소스 에 대해 항상 이름을 ca-pem 로 지정해야 하는 CA 인증서 파일 을 지정합니다.
kubectl create configmap custom-ca --from-file=ca-pem=<your-custom-ca-file>
샘플 샤딩된 클러스터 리소스 를 복사합니다.
원하는 샤드 클러스터구성과 일치하도록 이 YAML 파일의 설정을 변경합니다.
원하는 샤딩된 클러스터 구성에 맞게 설정을 변경합니다.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: <my-sharded-cluster> 6 spec: 7 shardCount: 2 8 mongodsPerShardCount: 3 9 mongosCount: 2 10 configServerCount: 3 11 version: "4.2.2-ent" 12 opsManager: 13 configMapRef: 14 name: <configMap.metadata.name> 15 # Must match metadata.name in ConfigMap file 16 credentials: <mycredentials> 17 type: ShardedCluster 18 persistent: true 19 ...
19 security: 20 tls: 21 ca: <custom-ca> 22 certsSecretPrefix: <prefix> 23 ...
이전 단계에서 강조 표시된 설정을 다음과 같이 구성합니다.
키 | 유형 | 설명 | 예시 |
|---|---|---|---|
문자열 | 이 Kubernetes 샤딩된 클러스터 객체에 대해 레이블을 지정합니다. 리소스 이름은 44자 이내여야 합니다. 학습 내용은 및 | myproject | |
integer | 배포할 샤드 수입니다. | 2 | |
integer | 샤드당 샤드 노드 수입니다. | 3 | |
integer | 배포할 샤드 라우터 수입니다. | 2 | |
integer | config 서버 복제본 세트의 노드 수입니다. | 3 | |
문자열 | 이 샤딩된 클러스터를 실행해야 하는 MongoDB 버전입니다. 형식은 커뮤니티 에디션의 경우 중요: 호환되는 MongoDB Server 버전 을 선택해야 합니다. 호환되는 버전은 MongoDB database 리소스 가 사용하는 기본 이미지에 따라 다릅니다. MongoDB 버전 관리에 대해 자세히 알아보려면 MongoDB 매뉴얼의 MongoDB 버전 관리를 참조하세요. | 최상의 결과를 얻으려면 사용 가능한 최신 MongoDB 엔터프라이즈 버전 을 사용하세요. MongoDB Ops Manager 버전과 호환 됩니다. | |
문자열 | ConfigMap 의 이름 MongoDB Ops Manager 연결 구성을 사용합니다. 이 값은 생성하려는 리소스와 동일한 네임스페이스에 존재해야 합니다. 중요: Kubernetes Operator는 ConfigMap에 대한 모든 변경 사항을 추적하고 | <myproject> | |
문자열 | Operator가 MongoDB Ops Manager와 통신할 수 있도록 MongoDB Ops Manager API 인증 자격 증명으로 생성 한 시크릿의 이름입니다.Kubernetes 자격 증명을 보유하고 있는 Ops Manager 쿠버네티스 시크릿 객체는 생성하려는 리소스와 동일한 네임스페이스에 존재해야 합니다. 중요: Kubernetes Operator는 시크릿에 대한 모든 변경 사항을 추적하고 | <mycredentials> | |
문자열 | 생성하고자 하는 MongoDB 리소스 유형입니다. | ShardedCluster | |
문자열 | 선택 사항. 이 이 값이 영구 볼륨 클레임 을 변경하려면 배포 요구 사항을 충족하도록 다음 컬렉션을 구성합니다.
경고: 컨테이너에 영구 볼륨 에 쓰기 (write) 수 있는 권한을 부여합니다. . Kubernetes Operator는 영구 볼륨 을 Disk Usage Disk IOPS 사용하지 않는 Processes 경우 , 및 Atlas Deployment 차트는 Metrics 이 배포에 대한 데이터를 검토 할 때 페이지의 탭 또는 페이지에 표시될 수 없습니다. | true |
사용자 지정 인증 기관(CA)을 사용하여 샤딩된 클러스터 리소스 에대한 TLS 설정을 구성합니다.
배포서버에서 TLS를 활성화하려면, Kubernetes 객체에서 다음 설정을 구성합니다.
키 | 유형 | 필요성 | 설명 | 예시 |
|---|---|---|---|---|
spec.security | 문자열 | 필수 사항 | <custom-ca> | |
spec.security | 문자열 | 필수 사항 | MongoDB deployment의 TLS 인증서가 포함된 시크릿 이름의 예를 예시 | devDb |
샤딩된 클러스터 배포서버 에 대해 허용되는 추가설정을 추가합니다.
다음과 같은 선택적 설정 중 하나를 객체 에 추가할 수도 있습니다. 샤드 클러스터 배포를 위한 사양 파일입니다.
경고
spec.clusterDomain Kubernetes 클러스터에 기본 도메인 이 있는 경우 cluster.local 를 설정해야 합니다. 기본값 이외. 기본값을 사용하지 않거나 spec.clusterDomain 옵션을 설정하지 않으면 Kubernetes Operator가 예상대로 작동하지 않을 수 있습니다.
For config server
샤드 라우터의 경우
샤드 노드의 경우
샤딩된 클러스터 배포서버 를 시작합니다.
다음 Kubernetes 명령을 호출하여 샤딩된 클러스터 를 생성합니다.
kubectl apply -f <sharded-cluster-conf>.yaml
이 명령을 실행한 후 로그를 확인합니다. 생성에 성공하면 다음과 유사한 메시지가 표시됩니다.
2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
샤딩된 클러스터 배포서버 의 상태를추적합니다.
MongoDB 리소스의 상태를 확인하려면 다음 명령어를 사용하세요.
kubectl get mdb <resource-name> -o yaml -w
-w(watch) 플래그 설정이 적용된 경우, 구성이 변경되면 상태 단계가 Running 상태를 달성할 때까지 출력이 즉시 새로 고침 됩니다. 리소스 배포 상태에 대해 자세히 알아보려면 Kubernetes Operator 문제 해결을 참조하세요.
TLS로 데이터베이스 리소스를 암호화한 후 다음을 보호할 수 있습니다.
샤딩된 클러스터에 대한 TLS 인증서 갱신
다음 절차를 사용하여 TLS 인증서를 정기적으로 갱신하십시오.
네임스페이스 kubectl 를 기본값 으로 구성합니다.
아직 실행하지 않았다면 다음 명령을 실행하여 생성한 네임스페이스에서 kubectl 명령을 모두 실행합니다.
참고
다중 Kubernetes 클러스터 MongoDB deployment에서 MongoDB Ops Manager 리소스를 배포하는 경우:
context을 중앙 클러스터의 이름(예:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME")으로 설정합니다.--namespace를 다중 Kubernetes 클러스터 MongoDB 배포에 사용한 것과 동일한 범위 (예:kubectl config --namespace "mongodb"로 설정합니다.
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
샤드의 TLS 인증서에 대한 시크릿을 갱신합니다.
kubectl 명령을 실행하여 샤딩된 클러스터의 샤드 인증서를 저장하는 기존 시크릿을 갱신합니다.
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \ --cert=<shard-0-tls-cert> \ --key=<shard-0-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f - kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \ --cert=<shard-1-tls-cert> \ --key=<shard-1-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
config 서버의 TLS 인증서에 대한 시크릿을 갱신합니다.
kubectl 명령을 실행하여 샤딩된 클러스터 config 서버의 인증서를 저장하는 기존 시크릿을 갱신합니다.
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \ --cert=<config-tls-cert> \ --key=<config-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
네임스페이스 kubectl 를 기본값 으로 구성합니다.
아직 실행하지 않았다면 다음 명령을 실행하여 생성한 네임스페이스에서 kubectl 명령을 모두 실행합니다.
참고
다중 Kubernetes 클러스터 MongoDB deployment에서 MongoDB Ops Manager 리소스를 배포하는 경우:
context을 중앙 클러스터의 이름(예:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME")으로 설정합니다.--namespace를 다중 Kubernetes 클러스터 MongoDB 배포에 사용한 것과 동일한 범위 (예:kubectl config --namespace "mongodb"로 설정합니다.
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
샘플 샤딩된 클러스터 리소스 를 복사합니다.
원하는 샤드 클러스터구성과 일치하도록 이 YAML 파일의 설정을 변경합니다.
원하는 구성에 맞게 수정할 수 있는 YAML 파일입니다. 원하는 샤딩된 클러스터 구성에 맞게 설정을 변경합니다.
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: <my-sharded-cluster> 6 spec: 7 shardCount: 2 8 mongodsPerShardCount: 3 9 mongosCount: 2 10 configServerCount: 3 11 version: "4.2.2-ent" 12 opsManager: 13 configMapRef: 14 name: <configMap.metadata.name> 15 # Must match metadata.name in ConfigMap file 16 credentials: <mycredentials> 17 type: ShardedCluster 18 persistent: true 19 ...
이전 단계에서 강조 표시된 설정을 다음과 같이 구성합니다.
키 | 유형 | 설명 | 예시 |
|---|---|---|---|
문자열 | 이 Kubernetes 샤딩된 클러스터 객체에 대해 레이블을 지정합니다. 리소스 이름은 44자 이내여야 합니다. 학습 내용은 및 | myproject | |
integer | 배포할 샤드 수입니다. | 2 | |
integer | 샤드당 샤드 노드 수입니다. | 3 | |
integer | 배포할 샤드 라우터 수입니다. | 2 | |
integer | config 서버 복제본 세트의 노드 수입니다. | 3 | |
문자열 | 이 샤딩된 클러스터를 실행해야 하는 MongoDB 버전입니다. 형식은 커뮤니티 에디션의 경우 중요: 호환되는 MongoDB Server 버전 을 선택해야 합니다. 호환되는 버전은 MongoDB database 리소스 가 사용하는 기본 이미지에 따라 다릅니다. MongoDB 버전 관리에 대해 자세히 알아보려면 MongoDB 매뉴얼의 MongoDB 버전 관리를 참조하세요. | 최상의 결과를 얻으려면 사용 가능한 최신 MongoDB 엔터프라이즈 버전 을 사용하세요. MongoDB Ops Manager 버전과 호환 됩니다. | |
문자열 | ConfigMap 의 이름 MongoDB Ops Manager 연결 구성을 사용합니다. 이 값은 생성하려는 리소스와 동일한 네임스페이스에 존재해야 합니다. 중요: Kubernetes Operator는 ConfigMap에 대한 모든 변경 사항을 추적하고 | <myproject> | |
문자열 | Operator가 MongoDB Ops Manager와 통신할 수 있도록 MongoDB Ops Manager API 인증 자격 증명으로 생성 한 시크릿의 이름입니다.Kubernetes 자격 증명을 보유하고 있는 Ops Manager 쿠버네티스 시크릿 객체는 생성하려는 리소스와 동일한 네임스페이스에 존재해야 합니다. 중요: Kubernetes Operator는 시크릿에 대한 모든 변경 사항을 추적하고 | <mycredentials> | |
문자열 | 생성하고자 하는 MongoDB 리소스 유형입니다. | ShardedCluster | |
문자열 | 선택 사항. 이 이 값이 영구 볼륨 클레임 을 변경하려면 배포 요구 사항을 충족하도록 다음 컬렉션을 구성합니다.
경고: 컨테이너에 영구 볼륨 에 쓰기 (write) 수 있는 권한을 부여합니다. . Kubernetes Operator는 영구 볼륨 을 Disk Usage Disk IOPS 사용하지 않는 Processes 경우 , 및 Atlas Deployment 차트는 Metrics 이 배포에 대한 데이터를 검토 할 때 페이지의 탭 또는 페이지에 표시될 수 없습니다. | true |
샤딩된 클러스터 배포서버 에 대해 허용되는 추가설정을 추가합니다.
다음과 같은 선택적 설정 중 하나를 객체 에 추가할 수도 있습니다. 샤드 클러스터 배포를 위한 사양 파일입니다.
경고
spec.clusterDomain Kubernetes 클러스터에 기본 도메인 이 있는 경우 cluster.local 를 설정해야 합니다. 기본값 이외. 기본값을 사용하지 않거나 spec.clusterDomain 옵션을 설정하지 않으면 Kubernetes Operator가 예상대로 작동하지 않을 수 있습니다.
For config server
샤드 라우터의 경우
샤드 노드의 경우
샤딩된 클러스터 배포서버 를 시작합니다.
다음 Kubernetes 명령을 호출하여 샤딩된 클러스터 를 생성합니다.
kubectl apply -f <sharded-cluster-conf>.yaml
이 명령을 실행한 후 로그를 확인합니다. 생성에 성공하면 다음과 유사한 메시지가 표시됩니다.
2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
샤딩된 클러스터 배포서버 의 상태를추적합니다.
MongoDB 리소스의 상태를 확인하려면 다음 명령어를 사용하세요.
kubectl get mdb <resource-name> -o yaml -w
-w(watch) 플래그 설정이 적용된 경우, 구성이 변경되면 상태 단계가 Running 상태를 달성할 때까지 출력이 즉시 새로 고침 됩니다. 리소스 배포 상태에 대해 자세히 알아보려면 Kubernetes Operator 문제 해결을 참조하세요.