고려 사항
이 페이지의 내용
- 여러 MongoDB 복제본 세트 배포
- CPU 및 메모리 리소스 요구 사항 지정
- 권장 보관 방법 고려
- 정적 컨테이너 사용(공개 미리 보기)
- 애플리케이션과 함께
mongos
파드 코로케이션 - 목적에 따라 MongoDB 서비스 이름 지정하기
- 레이블을 사용하여 배포 간 차별화
- Kubernetes 연산자가 감시하는 CustomResourceDefinitions 사용자 지정하기
- 적절한 지속성 구성 확인
- Kubernetes 연산자 Pod에 대한 CPU 및 메모리 사용률 바운드 설정
- MongoDB 파드에 대한 CPU 및 메모리 사용률 한도 설정
- 여러 가용영역 사용
- 스레드 수를 늘려 여러 조정 프로세스를 병렬로 실행
이 페이지에서는 프로덕션 환경에서 실행할 때 MongoDB Enterprise Kubernetes Operator에 대한 권장사항 및 시스템 구성 권장사항에 대해 자세히 설명합니다.
여러 MongoDB 복제본 세트 배포
MongoDB 복제본 세트를 배포하고 관리하려면 Kubernetes Operator의 단일 인스턴스를 사용하는 것이 좋습니다.
10 개 이상의 MongoDB 복제본 세트를 병렬로 배포하려면 Kubernetes Operator 인스턴스의 스레드 수를 늘리면 됩니다.
CPU 및 메모리 리소스 요구 사항 지정
참고
다음 고려 사항이 적용됩니다.
이 섹션의 Kubernetes 연산자를 통한 일반적인 MongoDB 배포에 대한 모든 크기 조정 및 성능 권장 사항은 변경될 수 있습니다. 이러한 권장 사항을 어떤 종류의 보장이나 제한으로 간주하지 마십시오.
이러한 권장 사항은 성능 테스트 결과를 반영하며 프로덕션 배포에 대한 제안 사항을 나타냅니다. 테스트는
t2.2xlarge
유형의 Amazon Web Services EC2 인스턴스 7개와t2.medium
유형의 마스터 노드로 구성된 cluster에서 실행되었습니다.이 섹션의 권장 사항에서는 특정 배포의 특성에 대해 설명하지 않습니다. 배포의 특성은 이러한 권장 사항을 생성하기 위한 가정과 다를 수 있습니다. 크기 조정에 대한 추가 도움이 필요하면 MongoDB 지원팀 에 문의하세요.
Kubernetes에서 각 Pod에는 CPU 리소스 를 지정할 수 있는 매개변수가 포함되어 있습니다. 및 메모리 리소스 Pod의 각 컨테이너에 대해
리소스 경계를 표시하기 위해 Kubernetes는 다음을 사용 합니다 . 매개변수, 여기서:
요청 은 리소스의 하한을 나타냅니다.
limit 은 리소스의 상한을 나타냅니다.
다음 섹션에서는 그 방법을 설명합니다.
Ops Manager를 호스팅하는 파드의 경우 기본 리소스 제한 구성을 사용합니다.
권장 보관 방법 고려
다음 권장 사항은 Kubernetes Operator가 관리하는 MongoDB 배포 및 Ops Manager 애플리케이션 데이터베이스 배포에 적용됩니다.
참고
MongoDB는 복제본 세트 또는 샤드의 멤버 간에 데이터를 자동으로 복제하므로 스토리지 클래스의 중복성은 필요하지 않습니다.
복제본 세트 또는 샤드의 멤버 간에 스토리지를 공유할 수 없습니다.
제약 조건에 따라 최상의 성능을 제공하는 스토리지 클래스를 사용합니다. 자세한 내용은 배포 확장을 참조하세요.
영구
ReadWriteOnce
볼륨 프로비저닝 스토리지 클래스에 대해 를 지원합니다.작업자 노드 수준 에서 Linux 기반 MongoDB의 권장사항을 적용합니다.
볼륨 확장 을 지원하는 스토리지 클래스를 사용해야 합니다. 데이터베이스 볼륨 크기 조정을 활성화합니다.
정적 컨테이너 사용(공개 미리 보기)
정적 컨테이너는 비정적 컨테이너보다 간단하고 안전합니다. 정적 컨테이너는 런타임에 변경되지 않으므로 컨테이너 생성에 사용된 이미지에서 변경되지 않습니다. 또한 다음을 수행합니다.
정적 컨테이너는 실행 중에 네트워크 연결을 통해 바이너리를 다운로드하거나 스크립트 또는 기타 유틸리티를 실행하지 않습니다. 정적 컨테이너는 런타임 구성 파일만 다운로드합니다.
정적 컨테이너는 실행되는 동안 스토리지 볼륨 마운트를 제외하고는 어떤 파일도 수정하지 않습니다.
컨테이너 이미지에 대한 보안 스캔을 실행하여 실제로 무엇이 라이브 컨테이너로 실행되는지 확인할 수 있으며, 실행되는 컨테이너는 이미지에 정의된 바이너리 이외의 바이너리를 실행하지 않습니다.
정적 컨테이너는 Ops Manager나 다른 HTTPS 서버에서 MongoDB 바이너리를 호스팅할 필요가 없으므로 에어 갭 환경이 있는 경우 특히 유용합니다.
정적 컨테이너에 대해 광범위한
CMD
스크립트를 실행할 수 없습니다.initContainer
을(를) 사용하여 정적 컨테이너 간에 파일을 복사할 수 없습니다.
자세한 내용은 정적 컨테이너(공개 미리 보기)를 참조하세요.
애플리케이션과 함께 파드 mongos
코로케이션
동일한 노드 에서 경량 인스턴스를 실행할 수 mongos
있습니다. MongoDB를 사용하여 앱으로 사용할 수 있습니다. Kubernetes Operator는 표준 Kubernetes 노드 선호도 및 반 선호도를 지원합니다. 기능. 이러한 기능을 사용하면 애플리케이션과 동일한 노드에 mongos
를 강제 설치할 수 있습니다.
다음의 축약된 예는 선호도 및 다중 가용영역 구성을 보여줍니다.
podAffinity
키는 다른 애플리케이션과 동일한 Pod, 노드 또는 데이터 센터에 애플리케이션을 설치할지 여부를 결정합니다.
Pod 선호도를 지정하려면 다음을 수행합니다.
YAML 컬렉션에 레이블과 값을 추가하여
spec.podSpec.podTemplate.metadata.labels
배포에 태그를spec.podSpec.podTemplate.metadata
지정합니다. 및 Kubernetes PodSpec v1 핵심 API를 참조하세요.spec.mongosPodSpec.podAffinity
.requiredDuringSchedulingIgnoredDuringExecution.labelSelector
YAML collection에서mongos
가 사용하는 레이블을 지정합니다.matchExpressions
collection은 Kubernetes 연산자가mongos
호스팅을 위한 파드를 식별하는 데 사용하는label
를 정의합니다.
예제
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-set 5 spec: 6 members: 3 7 version: 4.2.1-ent 8 service: my-service 9 10 ... 11 podTemplate: 12 spec: 13 affinity: 14 podAffinity: 15 requiredDuringSchedulingIgnoredDuringExecution: 16 - labelSelector: 17 matchExpressions: 18 - key: security 19 operator: In 20 values: 21 - S1 22 topologyKey: failure-domain.beta.kubernetes.io/zone 23 nodeAffinity: 24 requiredDuringSchedulingIgnoredDuringExecution: 25 nodeSelectorTerms: 26 - matchExpressions: 27 - key: kubernetes.io/e2e-az-name 28 operator: In 29 values: 30 - e2e-az1 31 - e2e-az2 32 podAntiAffinity: 33 requiredDuringSchedulingIgnoredDuringExecution: 34 - podAffinityTerm: 35 topologyKey: nodeId
replica-set-affinity.yaml 에서 다중 가용영역 및 노드 어피니티 구성의 전체 예시를 참조하세요. 선호도 샘플 에서 디렉토리.
이 디렉토리에는 샤드 cluster 및 독립형 MongoDB 배포에 대한 샘플 선호도와 다중 구역 구성도 포함되어 있습니다.
목적에 따라 MongoDB 서비스 이름 지정하기
다음 예제와 같이 spec.service
매개 변수를 이 배포의 목적을 식별하는 값으로 설정합니다.
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-set 5 spec: 6 members: 3 7 version: "6.0.0-ent" 8 service: drilling-pumps-geosensors 9 featureCompatibilityVersion: "4.0"
레이블을 사용하여 배포 간 차별화
Pod 선호도 사용 Kubernetes 기능:
test
,staging
및production
환경과 같은 서로 다른 MongoDB 리소스를 분리합니다.
1 mongosPodSpec: 2 podAffinity: 3 requiredDuringSchedulingIgnoredDuringExecution: 4 - labelSelector: 5 matchExpressions: 6 - key: security 7 operator: In 8 values: 9 - S1 10 topologyKey: failure-domain.beta.kubernetes.io/zone
Kubernetes 연산자가 감시하는 CustomResourceDefinitions 사용자 지정하기
Kubernetes 연산자가 감시하도록 할 사용자 지정 리소스를 지정할 수 있습니다. 이를 통해 Kubernetes Operator에서 managed 리소스에 대해서만 CustomResourceDefinition을 설치할 수 있습니다.
helm
를 사용하여 지정한 사용자 지정 리소스만 감시하도록 Kubernetes 연산자를 구성해야 합니다. 관련 helm
설치 지침 을 따르되 다음과 같이 조정합니다.
설치할 CustomResourceDefinitions를 결정합니다. 다음을 원하는 만큼 설치할 수 있습니다.
값설명mongodb
데이터베이스 리소스에 대한 CustomResourceDefinitions를 설치하고 해당 리소스를 감시합니다.mongodbusers
MongoDB 사용자 리소스에 대한 CustomResourceDefinitions를 설치하고 해당 리소스를 확인합니다.opsmanagers
Ops Manager 리소스용 CustomResourceDefinitions를 설치하고 해당 리소스를 확인합니다.Helm 차트를 설치하고 Kubernetes 연산자가 관찰할 CustomResourceDefinitions를 지정합니다.
각 사용자 지정 리소스를 쉼표로 구분합니다.
helm install <deployment-name> mongodb/enterprise-operator \ --set operator.watchedResources="{mongodb,mongodbusers}" \ --skip-crds
적절한 지속성 구성 확인
Kubernetes Operator가 조정하는 Kubernetes 배포는 상태를 저장합니다. Kubernetes 컨테이너는 영구 볼륨 을 사용합니다. 재시작 사이에 클러스터 상태를 유지합니다.
상태 저장 요구 사항을 충족하기 위해 Kubernetes 연산자는 다음 조치를 수행합니다.
영구 볼륨 생성 MongoDB deployment의 경우.
마운트 점이라는 하나 이상의 디렉토리에 저장 장치를 마운트합니다.
각 MongoDB 마운트 점에 대해 하나의 영구 볼륨을 생성합니다.
각 Kubernetes container의 기본 경로를
/data
으로 설정합니다.
MongoDB cluster의 저장 요구 사항을 충족하려면 Kubernetes 연산자와 함께 배포된 각 복제본 세트에 대해 구성을 다음과 같이 변경합니다.
spec.persistent
에서 영구 볼륨이 활성화되어 있는지 확인합니다. 이 설정의 기본값은true
입니다.Kubernetes 연산자가 각 볼륨에 할당할 수 있는 충분한 양의 스토리지를 지정합니다. 볼륨에는 데이터와 로그가 저장됩니다.
각각 데이터, 로그 및
oplog
에 대해 여러 볼륨을 설정하려면spec.podSpec.persistence.multiple.data
을 사용합니다.데이터, 로그 및
oplog
를 저장할 단일 볼륨을 설정하려면spec.podSpec.persistence.single
을 사용합니다.
다음 축약된 예는 권장되는 영구 스토리지 크기를 보여줍니다.
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-cluster 5 spec: 6 7 ... 8 persistent: true 9 10 11 shardPodSpec: 12 ... 13 persistence: 14 multiple: 15 data: 16 storage: "20Gi" 17 logs: 18 storage: "4Gi" 19 storageClass: standard
영구 볼륨 구성의 전체 예는 replica-set-persistent-volumes.yaml을 참조하세요.Persistent Volumes 샘플 에서 디렉토리. 이 디렉토리에는 샤드 클러스터 및 독립형 배포를 위한 샘플 영구 볼륨 구성도 포함되어 있습니다.
Kubernetes 연산자 Pod에 대한 CPU 및 메모리 사용률 바운드 설정
Kubernetes Operator를 사용하여 MongoDB 복제본 세트를 배포하는 경우 초기 조정 프로세스로 인해 Kubernetes Operator를 실행하는 Pod의 CPU 사용량이 증가합니다. 그러나 복제본 세트 배포 프로세스가 완료되면 Kubernetes Operator의 CPU 사용량이 크게 줄어듭니다.
참고
Kubernetes 연산자의 CPU 사용량 스파이크의 심각도는 스레드 수(MDB_MAX_CONCURRENT_RECONCILES 값으로 정의됨)가 특정 시점에서 병렬로 실행될 수 있는 조정 프로세스 수와 같기 때문에 Kubernetes 연산자 의 스레드 수 에 직접적으로 영향을 받습니다. 시간.
프로덕션 배포의 경우 최대 50개의 MongoDB 복제본 세트 또는 샤드 cluster를 Kubernetes 연산자와 병렬로 배포하려면 다음과 같이 Kubernetes 연산자 Pod의 CPU 및 메모리 리소스와 제한을 설정합니다.
spec.template.spec.containers.resources.requests.cpu
~ 500mspec.template.spec.containers.resources.limits.cpu
~ 1100mspec.template.spec.containers.resources.requests.memory
~ 200Mispec.template.spec.containers.resources.limits.memory
~ 1Gi
Helm을 사용하여 리소스를 배포하는 경우 values.yaml 파일에서 이러한 값을 정의합니다.
다음의 축약된 예시는 복제본 세트 또는 샤드 cluster 50개 배포에서 Kubernetes 연산자 Pod에 권장되는 CPU 및 메모리 제한이 있는 구성을 보여줍니다. 50개 미만의 MongoDB cluster를 배포하는 경우, Kubernetes 연산자 Pod의 구성 파일에 더 낮은 숫자를 사용할 수 있습니다.
예제
1 apiVersion: apps/v1 2 kind: Deployment 3 metadata: 4 name: mongodb-enterprise-operator 5 namespace: mongodb 6 spec: 7 replicas: 1 8 selector: 9 matchLabels: 10 app.kubernetes.io/component: controller 11 app.kubernetes.io/name: mongodb-enterprise-operator 12 app.kubernetes.io/instance: mongodb-enterprise-operator 13 template: 14 metadata: 15 labels: 16 app.kubernetes.io/component: controller 17 app.kubernetes.io/name: mongodb-enterprise-operator 18 app.kubernetes.io/instance: mongodb-enterprise-operator 19 spec: 20 serviceAccountName: mongodb-enterprise-operator 21 securityContext: 22 runAsNonRoot: true 23 runAsUser: 2000 24 containers: 25 - name: mongodb-enterprise-operator 26 image: quay.io/mongodb/mongodb-enterprise-operator:1.9.2 27 imagePullPolicy: Always 28 args: 29 - "-watch-resource=mongodb" 30 - "-watch-resource=opsmanagers" 31 - "-watch-resource=mongodbusers" 32 command: 33 - "/usr/local/bin/mongodb-enterprise-operator" 34 resources: 35 limits: 36 cpu: 1100m 37 memory: 1Gi 38 requests: 39 cpu: 500m 40 memory: 200Mi
최대 개의 50 MongoDB 복제본 세트의 병렬 배포를 충족하는 Kubernetes 연산자 파드의 CPU 및 메모리 사용률 리소스 및 제한에 대한 전체 예시는 mongodb-enterprise.yaml 을 참조하세요. 파일입니다.
MongoDB 파드에 대한 CPU 및 메모리 사용률 한도 설정
복제본 세트 또는 샤드 클러스터를 호스팅하는 파드의 값은 requests 필드 에 매핑됩니다. 생성된 Pod의 CPU 및 메모리에 해당합니다. 이러한 값은 MongoDB 호스트에 대해 명시된 고려 사항 과 일치합니다.
Kubernetes 연산자는 할당된 메모리를 처리, WiredTiger 캐시 및 배포 중 패키지 저장에 사용합니다.
프로덕션 배포의 경우 다음과 같이 MongoDB Pod에 대한 CPU 및 메모리 리소스와 제한을 설정합니다.
spec.podSpec.podTemplate.spec.containers.resources.requests.cpu
~ 0.25spec.podSpec.podTemplate.spec.containers.resources.limits.cpu
~ 0.25spec.podSpec.podTemplate.spec.containers.resources.requests.memory
~ 5억 1200만spec.podSpec.podTemplate.spec.containers.resources.limits.memory
~ 5억 1200만
Helm을 사용하여 리소스를 배포하는 경우 values.yaml 파일에서 이러한 값을 정의합니다.
다음의 축약된 예시는 배포에서 MongoDB 복제본 세트 멤버를 호스팅하는 각 Pod에 권장되는 CPU 및 메모리 바운드가 포함된 구성을 보여줍니다.
예제
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-set 5 spec: 6 members: 3 7 version: 4.0.0-ent 8 service: my-service 9 ... 10 11 persistent: true 12 podSpec: 13 podTemplate: 14 spec: 15 containers: 16 - name: mongodb-enterprise-database 17 resources: 18 limits: 19 cpu: "0.25" 20 memory: 512M
MongoDB 복제본 세트 멤버를 호스팅하는 파드에 대한 CPU 및 메모리 사용 리소스 및 한도에 대한 전체 예시는 replica-set-podspec.yaml을 참조하세요. MongoDB Podspec 샘플 의 파일 디렉토리.
이 디렉토리에는 다음과 같은 용도로 사용되는 파드에 대한 샘플 CPU 및 메모리 제한 구성도 포함되어 있습니다.
sharded-cluster-podspec.yaml에있는 샤드 클러스터.
독립형 MongoDB 배포는 standalone-podspec.yaml에 있습니다.
여러 가용영역 사용
Kubernetes Operator 및 StatefulSets 설정 하나의 복제본 세트의 모든 멤버를 다른 노드 에 배포합니다. 고가용성을 보장합니다.
다음의 축약된 예는 선호도 및 다중 가용영역 구성을 보여줍니다.
예제
1 apiVersion: mongodb.com/v1 2 kind: MongoDB 3 metadata: 4 name: my-replica-set 5 spec: 6 members: 3 7 version: 4.2.1-ent 8 service: my-service 9 ... 10 podAntiAffinityTopologyKey: nodeId 11 podAffinity: 12 requiredDuringSchedulingIgnoredDuringExecution: 13 - labelSelector: 14 matchExpressions: 15 - key: security 16 operator: In 17 values: 18 - S1 19 topologyKey: failure-domain.beta.kubernetes.io/zone 20 21 nodeAffinity: 22 requiredDuringSchedulingIgnoredDuringExecution: 23 nodeSelectorTerms: 24 - matchExpressions: 25 - key: kubernetes.io/e2e-az-name 26 operator: In 27 values: 28 - e2e-az1 29 - e2e-az2
이 예시에서 Kubernetes Operator는 e2e-az1
또는 e2e-az2
가용영역에 kubernetes.io/e2e-az-name
레이블이 있는 노드에 파드 배포를 예약합니다. nodeAffinity
를 변경하여 원하는 가용영역에 Pod 배포를 예약합니다.
replica-set-affinity.yaml 에서 다중 가용영역 구성의 전체 예시를 참조하세요. 선호도 샘플 에서 디렉토리.
이 디렉토리에는 샤드 cluster 및 독립형 MongoDB 배포에 대한 샘플 선호도와 다중 구역 구성도 포함되어 있습니다.
스레드 수를 늘려 여러 조정 프로세스를 병렬로 실행
10 개보다 많은 MongoDB 복제본 세트를 병렬로 배포하려는 경우, Kubernetes Operator 배포에서 MDB_MAX_CONCURRENT_RECONCILES 환경 변수를 설정하거나 Helm의 operator.maxConcurrentReconciles 필드를 통해 여러 조정 프로세스를 병렬로 실행하도록 Kubernetes Operator를 구성할 수 있습니다. values.yaml
파일을 사용하여 더 많은 스레드 수를 구성합니다.
Kubernetes Operator의 스레드 수를 늘리면 Kubernetes Operator 배포를 Kubernetes 클러스터 내에서 실행되는 수백 개의 MongoDB
리소스로 수직 확장하고 CPU 사용률을 최적화할 수 있습니다.
Kubernetes API 서버 및 Kubernetes Operator 리소스 사용량을 모니터링하고 필요한 경우 각각의 리소스 할당을 조정하세요.
참고
MDB_MAX_CONCURRENT_RECONCILES 를 10 이상으로 늘릴 때는 주의해서 진행하세요. 특히 Kubernetes Operator 및 Kubernetes API를 주의 깊게 모니터링하여 해당 구성 요소의 부하 증가로 인한 다운타임을 방지해야 합니다.
배포서버의 요구 사항에 적합한 스레드 수를 결정하려면 다음 지침을 사용하세요.
많은 리소스를 조정할 때 Kubernetes Operator의 응답 속도에 대한 요구 사항
Kubernetes 환경 내에서 사용 가능한 컴퓨팅 리소스와 MongoDB와 관련이 없을 수 있는 리소스를 포함하여 Kubernetes 컴퓨팅 리소스가 받는 총 처리 부하
단일 Kubernetes Operator 인스턴스의 스레드 수를 늘리면서 Kubernetes 클러스터에서 지원할 수 있는
MongoDB
리소스 수를 계속 늘리는 대신, Kubernetes 클러스터 내에 여러 Kubernetes Operator 인스턴스를 배포할 수 있습니다. 그러나 여러 Kubernetes Operator 인스턴스를 배포하려면 두 개의 Kubernetes Operator 인스턴스가 동일한MongoDB
리소스를 모니터링하지 않도록 해야 합니다.둘 이상의 Kubernetes Operator 인스턴스를 실행하면 특히 병렬 조정이 활성화된 Kubernetes Operator 인스턴스가 많을수록 API 서버가 과부하될 위험이 커지므로 주의해야 합니다.
Kubernetes API 서버의 확장은 둘 이상의 Kubernetes Operator 인스턴스를 실행해야 하는 유효한 이유가 아닙니다. API 서버의 성능이 영향을 받는 경우, Kubernetes 연산자의 인스턴스를 더 추가하면 문제가 악화될 수 있습니다.