MongoDB 사용자 지정 리소스 구성

배포 유형 선택

가장 먼저 결정해야 할 사항은 만들 MongoDB 배포서버의 유형입니다. spec.type 필드는 3개의 값을 허용하며, 각각 다른 워크로드 세트와 운영 요구사항을 대상으로 합니다. YAML 코드 한 줄을 쓰기 전에 이들 간의 상쇄 관계를 이해하는 것이 중요합니다.

독립형 인스턴스는 단일 mongod 프로세스를 실행합니다. 이들은 로컬 개발, 테스트 시나리오 또는 중복성이 문제가 되지 않는 기능 평가에 가장 적합합니다. 독립형 배포서버에는 복제가 없으므로 자동 페일오버를 지원하지 않으며 프로덕션 데이터에는 권장되지 않습니다.

복제본 세트 는 MongoDB의 기본 생산 토폴로지입니다. 복제본 세트는 동일한 데이터 복제본을 유지하는 여러 개의 mongod 노드(일반적으로 3개 이상)로 구성됩니다. 프라이머리가 실패하면 남은 노드가 수동 개입 없이 새 프라이머리를 선출합니다. 복제본 세트를 선택하면 고가용성, 세컨더리 읽기를 통한 읽기 확장성, 롤링 유지 보수 기능이 제공됩니다. 대부분의 팀은 여기서 시작합니다.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-replica-set
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

샤딩된 클러스터 는 데이터를 여러 샤드에 분산하며, 각 샤드는 그 자체가 복제본 세트입니다. 샤드 앞에는 클라이언트 트래픽을 지시하는 mongos 루터와 클러스터 메타데이터를 저장하는 전용 config 서버 복제본 세트가 있습니다. 데이터 세트가 단일 복제본 세트가 효율적으로 제공할 수 있는 범위를 초과하여 증가하거나 쓰기를 수평으로 확장해야 하는 경우 샤딩된 클러스터가 올바른 선택입니다. 샤드 수, 샤드당 mongod 인스턴스, mongos 라우터 및 config 서버의 수를 지정해야 하기 때문에 구성이 더 복잡합니다.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-sharded-cluster
spec:
  type: ShardedCluster
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

각 배포서 유형에 특유한 모든 필드에 대한 자세한 내용은 사양 참조의 독립형, 복제본 세트 및 샤딩된 클러스터 섹션을 참조하세요.

Ops Manager에 연결

모든 MongoDB 사용자 지정 리소스는 Ops Manager 프로젝트에 연결되어야 합니다. 이 연결은 Kubernetes 연산자가 모니터링, 자동화 및 백업을 위해 배포서버를 등록하는 방식입니다. 이 연결은 프로젝트를 식별하는 ConfigMap과 API 자격 증명을 저장하는 Secret이라는 두 가지 구성으로 작동합니다.

ConfigMap은 Kubernetes Operator에게 배포서버를 배치할 Ops Manager 프로젝트를 알려줍니다. 최소한 하나의 projectName 과 Ops Manager 인스턴스를 가리키는 baseUrl 이 포함되어야 합니다. 필요에 따라 orgId를 사용하여 배포서버를 특정 조직에 고정할 수 있습니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-project-configmap
data:
  projectName: "MyKubernetesProject"
  baseUrl: "https://ops-manager.example.com"
  orgId: "5e8f8b8b8b8b8b8b8b8b8b8b"

Secret에는 Kubernetes Operator가 사용자를 대신하여 Ops Manager API에 인증하는 프로그래밍 API 키 쌍이 포함되어 있습니다.

kubectl create secret generic my-credentials \
  --from-literal="publicKey=<public-api-key>" \
  --from-literal="privateKey=<private-api-key>"

그 다음 MongoDB CR에서 두 개 모두 참조합니다.

spec:
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials

이러한 사전 조건 만들기에 대한 자세한 내용은 Kubernetes 연산자의 자격 증명 만들기 및 ConfigMap을 사용하여 MongoDB 배포서버 단위로 프로젝트 하나 만들기를 참조하세요.

MongoDB 버전 및 기능 호환성

spec.version 필드는 Kubernetes 연산자가 배포하는 MongoDB 서버 버전을 설정합니다(예: "8.0.0"). 올바른 버전을 선택하는 것은 최신 기능을 확보하는 것이 상세한 정보가 아닙니다. 드라이버 라이브러리와의 버전 호환 매트릭스, 실행 중인 MongoDB Ops Manager 버전 및 팀의 업그레이드 주기도 고려해야 합니다.

주 버전 간에서 업그레이드할 때 featureCompatibilityVersion (기능 호환성 버전) 필드는 안전망을 제공합니다. 기능 호환성 버전은 어떤 스토리지 엔진 및 복제 기능이 활성화되는지 제어하며, 바이너리 버전 자체보다 낮게 설정할 수 있습니다. 이를 통해 바이너리를 먼저 업그레이드하고 안정성을 확인한 다음 별도의 신중한 단계로 기능 호환성 버전을 상향시켜 새 기능을 활성화할 수 있습니다. 롤백해야 하는 경우 FCV가 낮으면 이전 바이너리 버전과 데이터 파일이 호환되도록 할 수 있습니다.

spec:
  version: "8.0.0"
  featureCompatibilityVersion: "7.0"

참조하려면 사양에서 spec.version 및 spec.featureCompatibilityVersion 를 참조하세요.

배포의 보안 유지

Kubernetes에서의 MongoDB 배포에 대한 보안에는 TLS로 네트워크 트래픽 암호화와 클라이언트 및 클러스터 노드 인증의 두 가지 측면이 있습니다. 두 가지 모두 spec.security 블록 아래에서 구성되며, 이들이 상호 작용하는 방식을 이해하는 것이 보안이 있고 기능적인 배포를 구성하는 데 결정적입니다.

spec:
  security:
    certsSecretPrefix: "mdb"
    tls:
      enabled: true
      ca: "custom-ca-configmap"

spec:
  security:
    tls:
      enabled: true
    authentication:
      enabled: true
      modes: ["SCRAM", "X509"]
      internalCluster: "X509"

저장 및 영구 지속성

MongoDB는 상태 저장 워크로드이며, 스토리지를 구성하는 방식은 성능, 내구성 및 장애로부터 복구하는 기능에 직접적인 영향을 미칩니다. 데이터 손실이 허용되지 않는 환경(기본적으로 일회성 테스트를 제외한 모든 환경)의 경우 spec.persistent 필드를 true 로 설정해야 합니다. 영구성이 활성화되면 Kubernetes 연산자는 Pod 재시작 및 재예약을 견디실 수 있는 PersistentVolumeClaims(PVC)를 생성합니다.

spec:
  podSpec:
    persistence:
      multiple:
        data:
          storage: "200Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "50Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "20Gi"
          storageClass: "standard"

spec:
  podSpec:
    persistence:
      single:
        storage: "100Gi"
        storageClass: "standard"

리소스 할당 및 팟 템플릿

MongoDB Pod에 대한 CPU 및 메모리를 적절하게 조정하는 것은 배포 시점에 서 내릴 수 있는 가장 중요한 결정 중 하나이며, 워크로드가 변경됨에 따라 다시 검토할 가능성이 높습니다. Kubernetes Operator는 podSpec (복제본 세트 및 독립형) 및 shardPodSpec, configSrvPodSpec, mongosPodSpec (샤딩된 클러스터) 를 통해 리소스 제어를 노출합니다.

CPU 및 메모리에 대해 requests 및 limits 을 모두 설정하면 Kubernetes는 적절한 용량을 가진 노드에 Pod를 예정하고 동일 노드의 다른 워크로드에 영향을 미치는 제어 불가능한 프로세스를 방지합니다. 다음 예시는 시작 점으로 사용할 수 있는 구성을 보여줍니다. 이 구성에서는 최소 2 CPU 코어 및 4 GiB 메모리를 요청하여 생성 복제본 세트 노드를 만들고 제한은 이 값과 같거나 이보다 큰 값으로 설정합니다.

spec:
  podSpec:
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "4Gi"
              limits:
                cpu: "4"
                memory: "8Gi"

팟 템플릿을 사용하면 레이블, 주석, 톨러러스 및 아피니티 규칙도 설정할 수 있습니다. 아피니티 규칙은 복제본 세트 노드가 Kubernetes 노드 및 장애 도메인에 분산되는 방식을 제어하기 때문에 프로덕션에서 특히 중요합니다.

예를 들어, 다음 유사성 규칙은 노드를 가용영역에 걸쳐 구역 수준 장애에 대한 보호를 제공합니다.

spec:
  podSpec:
    podTemplate:
      spec:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: my-replica-set
                topologyKey: "topology.kubernetes.io/zone"

podTemplate 필드의 전체 목록은 사양 참조, 특히 spec.podSpec.podTemplate.spec.affinity에서 확인할 수 있습니다.

백업 구성

Kubernetes 연산자의 백업에서는 MongoDB Ops Manager에 내장된 연속 백업 기능을 사용합니다. 이 기능을 활성화하면 MongoDB Ops Manager는 oplog를 실시간으로 캡처하고 주기적으로 스냅샷을 생성하여 시점 복구를 제공합니다. 이는 마지막 스냅샷의 타임스탬프에서뿐 아니라 구성된 보유 창의 모든 초로 복원할 수 있다는 의미입니다.

MongoDB 리소스에서 백업을 활성화하려면 spec.backup.mode 을 enabled(로) 설정합니다. 다음 예시에 나와 있는 것에서와 같이 스냅샷이 촬영되는 빈도와 유지 기간을 제어하는 스냅샷 예정을 구성할 수도 있습니다.

spec:
  backup:
    mode: enabled
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 24

조직에서 미사용 백업 데이터의 암호화가 필요한 경우 다음 예시에 나와 있는 것에서처럼 KMIP준수 키 관리 서버와 통합할 수 있습니다.

spec:
  backup:
    mode: enabled
    encryption:
      kmip:
        client:
          clientCertificatePrefix: "backup-kmip"

autoTerminateOnDeletion 플래그는 MongoDB 리소스가 삭제될 때 백업 데이터가 정리되는지 여부를 제어합니다. 생성되지 않은 백업 상태를 피하기 위해 비생산 환경에서 true 로 설정합니다. 생산에서는 false 로 남겨두어 우연한 리소스 삭제 시 백업 데이터가 유지되도록 합니다.

spec:
  backup:
    mode: enabled
    autoTerminateOnDeletion: false

할당 레이블을 사용하면 특정 배포서버가 사용하는 백업 인프라스트럭처(oplog 저장소, 스냅샷 저장소)를 제어할 수 있습니다. 이는 여러 배포서버가 단일 MongoDB Ops Manager 인스턴스를 공유할 때 유용합니다.

백업 설정의 전체 세트는 사양 참조에서 복제본 세트 설정 을 참조하십시오. 백업 인프라스트를 배포하는 방법은 MongoDB 데이터베이스 백업 구성을 참조하세요.

배포서버를 외부에 노출

기본적으로 Kubernetes의 MongoDB 배포서버는 클러스터 내에서만 연결할 수 있습니다. 많은 팀에서 Kubernetes 외부에서 실행되는 애플리케이션, 개발 중 클라이언트 도구 또는 멀티 리전 아키텍처의 다른 Kubernetes 클러스터에서 데이터베이스에 액세스해야 합니다.

spec.externalAccess 블록은 Kubernetes 연산자에게 외부 트래픽을 MongoDB Pod로 보내는 Kubernetes 서비스를 만들도록 지시합니다. 다음 예시에 나와 있는 것처럼 클라우드 공급자 로드 밸러서를 프로비저닝하는 LoadBalancer 서비스와 모든 클러스터 노드에 정적 포트를 노출하는 NodePort 서비스 중에서 선택할 수 있습니다.

spec:
  externalAccess:
    externalService:
      spec:
        type: LoadBalancer
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

복제본 세트의 경우 externalDomain 를 추가로 구성하여 각 노드에 예측 가능한 DNS 호스트 이름을 할당할 수 있습니다. 이렇게 하면 클라이언트 사이드에서 연결 문자열 구성이 간단해집니다.

spec:
  externalAccess:
    externalDomain: "mongodb.example.com"
    externalService:
      spec:
        type: LoadBalancer

더 자세히 알아보려면 Kubernetes 외부에서 MongoDB 데이터베이스 리소스에 연결하기를 참조하세요.

MongoDB Server 매개변수 조정

모든 MongoDB 튜닝 설정에 사용자 지정 리소스에 최상위 필드가 있는 것은 아닙니다. Kubernetes 연산자의 명시적 스키마에 포함되지 않은 설정의 경우 spec.additionalMongodConfig 블록을 사용하여 임의의 mongod 구성 옵션을 전달할 수 있습니다. 이러한 옵션은 MongoDB Ops Manager가 적용하는 서버 구성으로 직접 변환됩니다.

additionalMongodConfig 의 일반적인 사용 예시는 다음 예시에 나와 있는 것처럼 WiredTiger 캐시 크기 조정, TLS 프로토콜 버전 제한 또는 수신 포트 변경 등이 있습니다.

spec:
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 4

샤딩된 클러스터에서는 각 구성 요소(샤드, config 서버, mongos)가 고유한 additionalMongodConfig 필드를 가지고 있으므로 독립적으로 조정할 수 있습니다. 지원되는 옵션의 전체 목록은 MongoDB 수동의 MongoDB Server Parameters 를 참조하십시오.

MongoDB Agent 구성

각 MongoDB Pod는 mongod 프로세스를 관리하고 자동화 작업을 처리하며 MongoDB Ops Manager에 헬스를 보고하는 MongoDB Agent를 실행합니다. 다음 예시에 표시된 것처럼 로그 로테이션 제한 및 연결 시간 초과 같은 스타트업 옵션을 포함하여 spec.agent을 통해 MongoDB Agent 동작을 조정할 수 있습니다.

spec:
  agent:
    startupOptions:
      maxLogFiles: "10"
      maxLogFileSize: "100"
      dialTimeout: "20"

spec.logLevel 필드는 MongoDB Agent의 로그 상세 수준을 설정합니다. 초기 설정 또는 문제 해결 중에는 DEBUG 이 매우 유용할 수 있습니다. 안정적인 상태의 프로덕션 환경에서는 INFO 또는 WARN 을 통해 과도한 로그 볼륨을 방지할 수 있습니다.

spec:
  logLevel: "DEBUG"

MongoDB 에이전트와 관련된 설정에 대한 자세한 내용은 사양 참조를 참조하세요.

멀티 클러스터 배포

지리적 이중화, 재해 복구 또는 데이터 주권을 위해 단일 MongoDB 배포를 여러 Kubernetes 클러스터에 걸쳐야 하는 팀을 위해 Kubernetes 연산자는 다중 클러스터 토폴로지를 지원합니다. spec.topology 을 MultiCluster (로) 설정하면 다음 예시에 표시된 것처럼 spec.clusterSpecList 에 정의된 복제본 세트 노드가 다른 Kubernetes 클러스터에 있음을 Kubernetes 연산자에게 지시합니다.

spec:
  topology: MultiCluster
  clusterSpecList:
    - clusterName: "cluster-us-east"
      members: 2
    - clusterName: "cluster-us-west"
      members: 2
    - clusterName: "cluster-eu-west"
      members: 1

다중 클러스터 배포서버는 클러스터 간 네트워킹 및 서비스 메시 또는 외부 DNS 구성을 포함하여 추가 사전 요건을 제공합니다. 계속하기 전에 다중 클러스터 사전 요건 및 다중 클러스터 아키텍처를 검토하십시오.

다중 클러스터 사양 필드에 대한 자세한 내용은 다중 Kubernetes 클러스터 사양을 참조하십시오.

시간이 지남에 따라 MongoDB 사용자 지정 리소스 구성 유지

MongoDB 사용자 지정 리소스는 일회성 아티팩트가 아닙니다. 팀의 요구 사항이 변경됨에 따라 노드를 확장하고, 샤드를 추가하고, 백업을 활성화하고, TLS 인증서를 로테이션하고, MongoDB 버전을 업그레이드하고, 또는 리소스 제한을 조정합니다. Kubernetes 연산자는 이를 위해 고안되었습니다. YAML 매니페스트를 업데이트하고 kubectl apply로 적용하면 Kubernetes 연산자가 변경 사항을 증분적으로 조정합니다.

안전한 반복을 위한 몇 가지 지침:

• 노드를 점차적으로 확장합니다. 복제본 세트 노드를 하나씩 추가하거나 제거하면 투표 중단 위험이 줄어듭니다.

• 버전을 두 단계로 업그레이드합니다. 먼저 featureCompatibilityVersion 를 이전 수준으로 유지하면서 바이너리 버전을 상승시키고 안정성을 확인한 후 기능 호환성 버전을 상승시키세요.

• 만료 전에 인증서를 교체하십시오. TLS 인증서는 유한한 수명을 가집니다. 교체 프로세스를 계획하고(이상적으로는 cert-manager을(를) 사용하여 자동화) 비운영 환경에서 먼저 테스트하십시오.

• 저장 변경 사항을 신중히 테스트하세요. 일부 저장 변경(저장 클래스 전환 등)에는 수동 볼륨 마이그레이션이 필요할 수 있습니다. 항상 스테이징 클러스터에서 유효성을 검사합니다.

• 리소스 상태를 모니터링합니다. 변경 후 kubectl get mdb 로 리소스 상태를 확인하고 인덱싱 오류에 대한 Kubernetes Operator 로그를 검토하여 Kubernetes Operator가 변경 사항을 성공적으로 조정했는지 확인합니다.

배포서버 수정을 위한 실습 절차에 대해서는 데이터베이스 리소스 편집을 참조하십시오.

모든 것을 하나로 모으기

다음 예시에서는 이 페이지에서 다루는 개념을 프로덕션 준비 복제본 세트 구성으로 결합합니다. 여기에는 TLS, SCRAM 인증, 백업, 안티 어피니티 예정, 분할 데이터/저널/로그 볼륨 및 WiredTiger 튜닝이 포함됩니다.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: prod-replica-set
  namespace: mongodb-production
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  featureCompatibilityVersion: "8.0"
  opsManager:
    configMapRef:
      name: prod-project-configmap
  credentials: prod-credentials
  persistent: true
  security:
    certsSecretPrefix: "prod-mdb"
    tls:
      enabled: true
      ca: "prod-ca-configmap"
    authentication:
      enabled: true
      modes: ["SCRAM"]
      internalCluster: "X509"
  backup:
    mode: enabled
    autoTerminateOnDeletion: false
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 48
  podSpec:
    persistence:
      multiple:
        data:
          storage: "500Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "100Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "50Gi"
          storageClass: "standard"
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "8Gi"
              limits:
                cpu: "4"
                memory: "16Gi"
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: prod-replica-set
                topologyKey: "topology.kubernetes.io/zone"
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 8