고려 사항

여러 MongoDB 복제본 세트 배포

MongoDB 복제본 세트를 배포하고 관리하려면 Kubernetes Operator의 단일 인스턴스를 사용하는 것이 좋습니다.

10 개 이상의 MongoDB 복제본 세트를 병렬로 배포하려면 Kubernetes Operator 인스턴스의 스레드 수를 늘리면 됩니다.

CPU 및 메모리 리소스 요구 사항 지정

Kubernetes에서 각 Pod에는 CPU 리소스 를 지정할 수 있는 매개변수가 포함되어 있습니다. 및 메모리 리소스 Pod의 각 컨테이너에 대해

리소스 경계를 표시하기 위해 Kubernetes는 다음을 사용 합니다 . 매개변수, 여기서:

• 요청 은 리소스의 하한을 나타냅니다.

• limit 은 리소스의 상한을 나타냅니다.

다음 섹션에서는 그 방법을 설명합니다.

• 연산자 Pod의 CPU 및 메모리를 설정합니다.

• MongoDB Pods의 CPU 및 메모리를 설정합니다.

Ops Manager를 호스팅하는 파드의 경우 기본 리소스 제한 구성을 사용합니다.

권장 보관 방법 고려

다음 권장 사항은 Kubernetes Operator가 관리하는 MongoDB 배포 및 Ops Manager 애플리케이션 데이터베이스 배포에 적용됩니다.

• 제약 조건에 따라 최상의 성능을 제공하는 스토리지 클래스를 사용합니다. 자세한 내용은 배포 확장을 참조하세요.

• 영구 ReadWriteOnce 볼륨 프로비저닝 스토리지 클래스에 대해 를 지원합니다.

• 작업자 노드 수준 에서 Linux 기반 MongoDB의 권장사항을 적용합니다.

• 볼륨 확장 을 지원하는 스토리지 클래스를 사용해야 합니다. 데이터베이스 볼륨 크기 조정을 활성화합니다.

정적 컨테이너 사용(공개 미리 보기)

정적 컨테이너는 비정적 컨테이너보다 간단하고 안전합니다. 정적 컨테이너는 런타임에 변경되지 않으므로 컨테이너 생성에 사용된 이미지에서 변경되지 않습니다. 또한 다음을 수행합니다.

• 정적 컨테이너는 실행 중에 네트워크 연결을 통해 바이너리를 다운로드하거나 스크립트 또는 기타 유틸리티를 실행하지 않습니다. 정적 컨테이너는 런타임 구성 파일만 다운로드합니다.

• 정적 컨테이너는 실행되는 동안 스토리지 볼륨 마운트를 제외하고는 어떤 파일도 수정하지 않습니다.

• 컨테이너 이미지에 대한 보안 스캔을 실행하여 실제로 무엇이 라이브 컨테이너로 실행되는지 확인할 수 있으며, 실행되는 컨테이너는 이미지에 정의된 바이너리 이외의 바이너리를 실행하지 않습니다.

• 정적 컨테이너는 Ops Manager나 다른 HTTPS 서버에서 MongoDB 바이너리를 호스팅할 필요가 없으므로 에어 갭 환경이 있는 경우 특히 유용합니다.

• 정적 컨테이너에 대해 광범위한 CMD 스크립트를 실행할 수 없습니다.

• initContainer 을(를) 사용하여 정적 컨테이너 간에 파일을 복사할 수 없습니다.

자세한 내용은 정적 컨테이너(공개 미리 보기)를 참조하세요.

애플리케이션과 함께 파드 mongos 코로케이션

동일한 노드 에서 경량 인스턴스를 실행할 수 mongos 있습니다. MongoDB를 사용하여 앱으로 사용할 수 있습니다. Kubernetes Operator는 표준 Kubernetes 노드 선호도 및 반 선호도를 지원합니다. 기능. 이러한 기능을 사용하면 애플리케이션과 동일한 노드에 mongos 를 강제 설치할 수 있습니다.

다음의 축약된 예는 선호도 및 다중 가용영역 구성을 보여줍니다.

podAffinity 키는 다른 애플리케이션과 동일한 Pod, 노드 또는 데이터 센터에 애플리케이션을 설치할지 여부를 결정합니다.

Pod 선호도를 지정하려면 다음을 수행합니다.

1. YAML 컬렉션에 레이블과 값을 추가하여 spec.podSpec.podTemplate.metadata.labels 배포에 태그를 spec.podSpec.podTemplate.metadata 지정합니다. 및 Kubernetes PodSpec v1 핵심 API를 참조하세요.

2. 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 리소스를 분리합니다.

• 파드 배치 일부 특정 노드에서 SSD 지원과 같은 기능을 활용할 수 있습니다.

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 설치 지침 을 따르되 다음과 같이 조정합니다.

1. 설치할 CustomResourceDefinitions를 결정합니다. 다음을 원하는 만큼 설치할 수 있습니다.

   값	설명
   mongodb	데이터베이스 리소스에 대한 CustomResourceDefinitions를 설치하고 해당 리소스를 감시합니다.
   mongodbusers	MongoDB 사용자 리소스에 대한 CustomResourceDefinitions를 설치하고 해당 리소스를 확인합니다.
   opsmanagers	Ops Manager 리소스용 CustomResourceDefinitions를 설치하고 해당 리소스를 확인합니다.

2. 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 사용량이 크게 줄어듭니다.

프로덕션 배포의 경우 최대 50개의 MongoDB 복제본 세트 또는 샤드 cluster를 Kubernetes 연산자와 병렬로 배포하려면 다음과 같이 Kubernetes 연산자 Pod의 CPU 및 메모리 리소스와 제한을 설정합니다.

• spec.template.spec.containers.resources.requests.cpu ~ 500m

• spec.template.spec.containers.resources.limits.cpu ~ 1100m

• spec.template.spec.containers.resources.requests.memory ~ 200Mi

• spec.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.25

• spec.podSpec.podTemplate.spec.containers.resources.limits.cpu ~ 0.25

• spec.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 리소스 사용량을 모니터링하고 필요한 경우 각각의 리소스 할당을 조정하세요.