고려 사항

여러 MongoDB 복제본 세트 배포

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

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

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

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

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

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

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

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

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

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

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

권장 보관 방법 고려

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

• 제약 조건에 따라 최상의 성능을 제공하는 저장 클래스를 사용합니다. 학습 내용은 배포서버 확장하다 을 참조하세요.

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

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

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

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

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

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

• 을(를) 실행 하는 동안 정적 컨테이너는 저장 볼륨 마운트를 제외하고는 어떤 파일 도 수정하지 않습니다.

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

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

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

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

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

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

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

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

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

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

1. spec.podSpec.podTemplate.metadata.labels YAML 컬렉션 에 레이블과 값을 추가하여 배포서버 에 태그를 지정하다 를 지정합니다. spec.podSpec.podTemplate.metadata및 Kubernetes PodSpec v1 Core 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 환경 변수를 설정하거나 연산자 .maxConcurrentReconciles 를 통해 여러 조정 프로세스를 병렬로 실행 하도록 Kubernetes Operator를 구성할 수 있습니다. 필드 를 추가하여 더 많은 values.yaml 수를 구성 파일 .

Kubernetes Operator의 스레드 수를 늘리면 Kubernetes Operator 배포서버 를 Kubernetes 클러스터 내에서 실행 되는 수백 개의 MongoDB 리소스로 수직 확장하다 하고 CPU 사용률을 최적화할 수 Kubernetes .

Kubernetes API 서버 및 Kubernetes Operator 리소스 사용량을 모니터 하고 필요한 경우 각각의 리소스 할당을 조정하세요.