고려 사항

권장 수의 MongoDB 복제본 세트 배포

Kubernetes 연산자의 단일 인스턴스를 사용하여 최대 20개의 복제본 세트를 병렬로 배포하는 것이 좋습니다.

이 숫자를 50개로 늘리면 Kubernetes 연산자가 해당 리소스를 다운로드, 설치, 배포 및 조정하는 데 걸리는 시간이 합리적으로 증가할 수 있습니다.

복제본 세트 50개의 경우 배포 시간은 다양하며 최대 40분이 걸릴 수 있습니다. 이 시간은 Kubernetes cluster의 네트워크 대역폭과 각 MongoDB Agent가 인터넷에서 각 MongoDB cluster 멤버에 대해 MongoDB 설치 바이너리를 다운로드하는 데 걸리는 시간에 따라 달라집니다.

50개 이상의 MongoDB 복제본 세트를 병렬로 배포하려면 여러 Kubernetes 연산자 인스턴스를 사용합니다.

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

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

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

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

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

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

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

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

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

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

정적 컨테이너는 비정적 컨테이너보다 더 안전하고 간단합니다. 정적 컨테이너는 런타임에 변경되지 않습니다. 또한 다음을 수행합니다.

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

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

• 정적 컨테이너는 컨테이너 보안 스캔이 필요한 비정적 컨테이너와 달리 컨테이너에 보안 취약점을 스캔할 필요가 없습니다. 정적 컨테이너를 사용하는 경우 컨테이너 이미지 자체에 대해서만 보안 스캔을 실행할 수 있으며 해당 컨테이너에서는 실행할 수 없습니다.

• 에어 갭 환경의 경우 정적 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: "4.4.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 샘플 에서 디렉토리. 이 디렉토리 에는 샤딩된 클러스터 및 독립형 배포를 위한 샘플 영구 볼륨 구성도 포함되어 있습니다.

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

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

여러 가용영역 사용

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 배포에 대한 샘플 선호도와 다중 구역 구성도 포함되어 있습니다.