자주 묻는 질문
이 페이지의 내용
- 연산자란 무엇인가요?
- Kubernetes에서 MongoDB Enterprise Advanced를 실행하는 이유는 무엇인가요?
- Kubernetes 에서 MongoDB 는 얼마나 확장 가능한 할 수 있나요?
- Kubernetes 내에서 MongoDB 를 실행 때 단점이 있나요?
- MongoDB Server 배포를 위해 어떤 Kubernetes 플랫폼이 지원되나요?
- MongoDB Enterprise Kubernetes Operator는 몇 개의 배포서버를 지원할 수 있나요?
- MongoDB Server를 사용하는 애플리케이션과 동일한 cluster의 Kubernetes에서 MongoDB Server를 실행해야 하나요?
- 여러 Kubernetes cluster에 MongoDB Server를 배포할 수 있나요?
- 다중 Kubernetes 클러스터 MongoDB 배포를 관리하기 위해 Kubernetes Operator를 사용하는 것과 단일 Kubernetes 클러스터를 관리하는 것의 차이점은 무엇인가요?
- MongoDB는 둘 이상의 Kubernetes 연산자 인스턴스 실행을 지원하나요?
연산자란 무엇인가요?
연산자는 Kubernetes의 컨트롤 플레인을 사용자 지정 Kubernetes 리소스 관리로 확장하는 표준 메커니즘입니다. 각 연산자는 자체 사용자 지정 리소스(CR)를 위해 구축되었기 때문에 연산자가 구축된 서비스 유형을 해결하는 로직을 포함할 수 있습니다. Kubernetes 연산자의 경우, 연산자에는 MongoDB Server 및 Ops Manager 인스턴스 배포를 위한 로직이 포함됩니다.
Kubernetes 연산자가 사용하는 각 CR은 Kubernetes의 MongoDB Server 배포 요소를 나타내며, 배포의 해당 부분을 사용자 지정할 수 있는 옵션이 있습니다. Kubernetes 배포에서 이러한 객체를 구성하면 연산자는 MongoDB Server에 대한 지정된 요구 사항에 따라 파드를 생성하는 데 필요한 네이티브 Kubernetes 객체(예: Stateful 세트)를 빌드합니다. 또한 Kubernetes Operator는 MongoDB Cloud Manager 또는 Ops Manager와의 상호 작용을 통해 데이터베이스 백업과 같은 MongoDB Server 기능 구성을 용이하게 합니다.
Kubernetes에서 MongoDB Enterprise Advanced를 실행하는 이유는 무엇인가요?
Kubernetes 에서 MongoDB 를 실행하면 셀프 호스팅 MongoDB 의 설정 및 관리 가 간소화됩니다.
Kubernetes Operator는 MongoDB 및 MongoDB Ops Manager 와 함께 작동하여 설정 을 정의하기 위해 생성하는 사용자 지정 리소스 파일을 사용하여 구성을 자동화합니다. 이를 통해 Git 리포지토리 에서 구성을 managed 하는 GitOps 워크플로를 활성화 하는 도구를 포함하여 Kubernetes 에서 애플리케이션을 관리하기 위해 이미 가지고 있는 도구를 사용하여 구성을 관리 수 있습니다. 높은 수준의 자동화 와 복잡성으로부터의 추상화 덕분에 Kubernetes 와 Kubernetes Operator는 내부 사용자 또는 외부 고객을 위해 MongoDB 를 서비스로 실행 데 특히 적합합니다.
Kubernetes 를 통해 MongoDB 는 복제본 세트 또는 샤딩된 클러스터 를 구성하는 손실된 Pod의 자동 교체와 같이 Kubernetes 가 제공하는 확장성 성과 자동화된 회복 탄력성 을 활용할 수 있습니다. 이를 통해 MongoDB 는 Kubernetes 에서 실행 때 확장 가능한 성과 복원력이 뛰어납니다.
Kubernetes 에서 MongoDB 는 얼마나 확장 가능한 할 수 있나요?
Kubernetes 내의 MongoDB 는 베어메탈 또는 VM에서 MongoDB 만큼 확장 가능한 합니다. 대부분의 고객은 Kubernetes 내에서 확장성 을 더 쉽게 달성할 수 있습니다. Kubernetes Operator와 Kubernetes 는 원활하게 함께 작동하여 멀티 클러스터 및 멀티 사이트 회복 탄력성 을 위해 여러 Kubernetes 클러스터에 MongoDB 배포를 확장하는 기능 을 포함하여 쉬운 수평 확장 을 활성화 합니다.
수직 확장 은 배포를 정의하는 사용자 지정 리소스 에서 배포서버 에 대한 리소스를 변경하는 것만큼 쉽습니다.
이 모든 것이 MongoDB 를 확장하다 하여 모든 요구 사항을 충족할 수 있도록 합니다.
Kubernetes 내에서 MongoDB 를 실행 때 단점이 있나요?
기술적인 측면에서 단점은 없습니다. Kubernetes 내의 MongoDB 는 모든 hardware 또는 인프라에서 실행 되는 MongoDB 만큼 성능과 확장 가능한 이 뛰어납니다.
그러나 다른 인프라와 마찬가지로 고객이 이 기술(이 경우 Kubernetes )에 대한 친숙성과 전문성 을 보유해야 한다는 본질적인 요구 사항이 있습니다. Kubernetes Operator는 Kubernetes 내에서 MongoDB 설정 을 간소화하고 자동화하지만, Kubernetes 클러스터 의 일부인 기본 리소스 및 기능(예: 상태 저장, 네트워킹, 보안, 컴퓨팅 등)에 대한 종속성은 여전히 존재합니다. 이는 베어메탈 또는 가상 머신에서 실행 하는 경우 고객이 MongoDB 지원 을 위해 해당 서비스와 리소스를 사용할 수 있고 올바르게 구성할 수 있는지 확인해야 함을 의미합니다.
MongoDB Server 배포를 위해 어떤 Kubernetes 플랫폼이 지원되나요?
MongoDB Server 는 기본값 로직이나 동작을 변경하지 않고 네이티브 Kubernetes 를 기반으로 구축되는 모든 플랫폼을 지원합니다. 실제로 이는 MongoDB Server 가 Cloud Native Computing Foundation 에서 인증한 모든 Kubernetes 플랫폼을 지원한다는 의미입니다. . 학습 내용은 MongoDB Kubernetes 연산자 호환성을 참조하세요.
MongoDB Enterprise Kubernetes Operator는 몇 개의 배포서버를 지원할 수 있나요?
Kubernetes Operator는 수백 개의 배포를 지원 수 있습니다. 병렬 조정 작업을 용이하게 하고 조정 시간이 길어지는 것을 방지하려면 Kubernetes Operator 인스턴스 의 스레드 수를 늘리세요.
MongoDB Server를 사용하는 애플리케이션과 동일한 cluster의 Kubernetes에서 MongoDB Server를 실행해야 하나요?
지연 시간을 최소화하려면 배포 아키텍처에서 허용하는 경우 데이터베이스와 애플리케이션을 동일한 Kubernetes cluster에 배치하는 것이 좋습니다.
여러 Kubernetes cluster에 MongoDB Server를 배포할 수 있나요?
네. 자세한 내용 은 여러 Kubernetes 클러스터에 MongoDB 리소스 배포 를 참조하세요. 도움이 필요하면 MongoDB 지원팀 에 문의하세요.
다중 Kubernetes 클러스터 MongoDB 배포를 관리하기 위해 Kubernetes Operator를 사용하는 것과 단일 Kubernetes 클러스터를 관리하는 것의 차이점은 무엇인가요?
다중 Kubernetes 클러스터 MongoDB 배포를 관리하기 위해 Kubernetes Operator를 사용하려면 특정 Kubernetes 역할 세트인 ClusterRoles 를 설정해야합니다. , RoleBindings, ClusterRoleBindings및 ServiceAccounts.
다중 Kubernetes 클러스터 MongoDB 배포에 사용되는 Kubernetes Operator는 단일 Kubernetes 클러스터 리소스를 조정할 수도 있습니다. 자세한 내용은 MongoDB가 둘 이상의 Kubernetes 연산자 인스턴스 실행을 지원하나요?를 참조하세요.
MongoDB는 둘 이상의 Kubernetes 연산자 인스턴스 실행을 지원하나요?
가능하면 단일 Kubernetes Operator 인스턴스를 설정하여 Kubernetes 클러스터 내의 하나, 여러 개 또는 모든 네임스페이스를 감시하는 것이 좋습니다. 기본적으로 Kubernetes Operator는 모든 사용자 지정 리소스 를 감시합니다. 특정 리소스 유형을 감시하기 위해 구성할 필요가 없습니다.
그러나 단일 Kubernetes 연산자 인스턴스가 지원할 수 있는 배포 수의 성능 제한 에 도달하면 추가 Kubernetes 연산자 인스턴스를 설정할 수 있습니다. 이 점에서 Kubernetes cluster의 리소스 관리를 어떻게 분할할 것인지 고려하세요. 우선 순위에 따라 나열된 다음 권장 사항을 사용합니다.
각 Kubernetes 연산자 인스턴스가 Kubernetes cluster 내에서 겹치지 않는 서로 다른 네임스페이스를 감시하고 있는지 확인합니다.
또는, 다른 네임스페이스나 겹치는 네임스페이스에서 다양한 리소스 유형을 감시하도록 Kubernetes 연산자의 여러 인스턴스를 구성합니다.
겹치는 네임스페이스를 사용하기로 선택한 경우, 각 Kubernetes 연산자 인스턴스가 서로 다른 유형의 리소스를 감시하여 충돌로 인해 Kubernetes 연산자의 두 인스턴스가 동일한 리소스를 managed하려고 시도하는 것을 방지할 수 있습니다.
참고
다른 Kubernetes 연산자 인스턴스를 구성하기 전에 해당 네임스페이스가 기존 Kubernetes 연산자 인스턴스의 네임스페이스 하위 집합에 포함되어 있지 않은지 확인합니다.