MongoDB 사용자 지정 리소스는 Kubernetes Operator가 managed하는 데이터베이스 배포를 정의합니다. 사용자 지정 리소스 사양은 이러한 리소스를 정의하고 Kubernetes Operator는 이를 모니터합니다. 리소스의 사양을 업데이트하면 Kubernetes Operator는 변경 사항을 MongoDB 배포의 구성을 수정하는 MongoDB Ops Manager에 푸시합니다.
MongoDB CRD는 세 가지 배포서버 유형을 지원합니다. 다음 다이어그램은 각각의 구성을 보여줍니다.
경고
Kubernetes Operator는 중재자 노드를 지원하지 않습니다.
독립형 리소스
Standalone 리소스를 배포할 수 있지만, 복제본 세트를 사용하면 나중에 노드를 추가할 수 있으므로 노드가 하나인 ReplicaSet 리소스를 배포하는 것이 좋습니다. Kubernetes에서 Standalone 리소스는 노드가 하나인 ReplicaSet 리소스와 동일합니다.
Standalone 리소스의 경우 Kubernetes Operator는 단일 노드를 가진 복제본 세트를 StatefulSet로 배포합니다. Kubernetes Operator는 파드 사양이 포함된 StatefulSet를 생성하고 Kubernetes StatefulSet 컨트롤러를 사용하여 이 단일 mongod 인스턴스에 대한 파드를 생성합니다.
복제본 세트 리소스
ReplicaSet 리소스의 경우, Kubernetes Operator는 spec.members의 값과 동일한 수의 노드를 갖는 복제본 세트를 StatefulSet으로 배포합니다. Kubernetes Operator는 Kubernetes StatefulSet 컨트롤러를 사용하여 노드당 하나의 Pod를 생성합니다. 각 Pod는 해당 Pod에서 mongod 프로세스를 관리하는 MongoDB Agent 인스턴스를 실행합니다.
샤딩된 클러스터 리소스
ShardedCluster 리소스는 config 서버, mongos 인스턴스 및 샤드 노드로 구성됩니다. Kubernetes 연산자는 다음을 배포합니다.
모든 Config 서버에 대해 하나의 StatefulSet
모든
mongos인스턴스에 대한 하나의 StatefulSet각 샤드당 하나의 StatefulSet
Kubernetes Operator는 Kubernetes StatefulSet 컨트롤러를 사용하여 각 StatefulSet에 하나의 파드를 생성합니다. 2 샤드를 가진 샤딩된 클러스터의 경우 총 4 개의 StatefulSet이 있습니다(config 서버용 1 개 + mongos 용 1 개 + 샤드용 2 개).
배포 유형 | StatefulSets | StatefulSet 의 크기 |
|---|---|---|
독립형 | 1 | 1 Pod |
복제본 세트 | 1 | 1 멤버당 Pod |
샤딩된 클러스터 | <numberOfShards> + 2 |
|
MongoDB 리소스 조정
MongoDB 사용자 지정 리소스 사양을 적용하면 Kubernetes Operator는 각 리소스를 StatefulSet로 배포합니다. 그 다음 Kubernetes Operator는 연속 조정 루프에 진입합니다.
spec.opsManager.configMapRef.name에 지정된 ConfigMap에서 프로젝트 구성을 읽습니다.에 지정된 시크릿에서 또는 시크릿 저장 도구에서API 자격 증명을 읽습니다.
spec.credentialsMongoDB Ops Manager에 연결하여 다음을 수행합니다.
ConfigMap의
orgId에서 조직을 읽습니다.projectName에 지정된 프로젝트를 읽거나 생성합니다.<project-id>-group-secret이 존재하는지 확인하거나 Ops Manager API 키로 만듭합니다.Kubernetes Operator를 ConfigMap 및 자격 증명 Secrets의 감시자로 등록합니다.
사용하는경우 TLS 및 X.509 인증서를 확인합니다.
복제본 세트의 경우:
<prefix>-<resource-name>-cert에서 인증서를 찾습니다.샤딩된 클러스터의 경우:
<prefix>-<resource-name>-x-cert(샤드 단위),<prefix>-<resource-name>-config-cert(config 서버) 및<prefix>-<resource-name>-mongos-cert(mongos인스턴스)에서 인증서를 찾습니다.
StatefulSet을 생성하거나 업데이트합니다. 숫자는 배포 유형에 따라 다릅니다. 이 시점에서 각 파드는 MongoDB Agent를 실행하지만 아직
mongod인스턴스를 포함하지 않습니다.각 MongoDB Agent는 자동화 구성을 위해 MongoDB Ops Manager를 폴링합니다.
비정적 컨테이너에서 MongoDB Agent는
spec.version에 지정된 버전의 MongoDB 바이너리를 다운로드합니다.구성을 수신한 후 MongoDB Agent가
mongod를 시작합니다.Kubernetes 연산자는
spec.persistent이false인 경우를 제외하고 각 포드(mongos포드 제외) 마다 PersistentVolumeClaims를 생성합니다.
자동화 구성 업데이트를 MongoDB Ops Manager로 푸시합니다. 각 MongoDB Agent는 업데이트된 구성을 폴링하고 적용합니다. 필드를 변경하면 Kubernetes Operator가 StatefulSet의 롤링 업데이트를 수행합니다.
Kubernetes 서비스 생성 또는 업데이트:
ReplicaSet또는Standalone의 경우:<resource-name>-svc이라는 이름의 헤드리스ClusterIP서비스.ShardedCluster의 경우:mongosspec.service또는<resource-name>-svc의 이름을 사용합니다.Config servers:
<resource-name>-cs.각 샤드:
<resource-name>-sh.
다음 다이어그램은 복제본 세트의 재정리 플로우를 나타냅니다.
다음 다이어그램은 샤딩된 클러스터의 조정 흐름을 나타냅니다.
MongoDBUser 리소스 재정리
사용자 인증 메서드가 SCRAM인 경우 MongoDBUser 리소스는 사용자 자격 증명을 저장하는 시크릿 에 종속됩니다. Kubernetes 연산자는 시크릿의 변경 사항을 지켜보고 다음과 같이 조정합니다.
spec.MongoDBResourceRef.name에서 MongoDB 사용자의 리소스를 결정합니다.Ops Manager에 연결하고 조직과 프로젝트를 읽은 다음 에이전트 시크릿을 확인합니다.
Ops Manager에서 사용자의 자격 증명을 업데이트하거나 사용자가 존재하지 않는 경우 새 사용자를 생성합니다. 사용자 이름이 변경된 경우 Kubernetes Operator는 이전 이름을 제거하고 새 이름을 추가합니다.
다음 다이어그램은 MongoDBUser 조정 흐름을 보여줍니다.
