문서 메뉴
문서 홈
/
MongoDB Enterprise Kubernetes 연산자

자주 묻는 질문

이 페이지의 내용

  • 연산자란 무엇인가요?
  • 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를 실행하면 자체 호스팅 MongoDB의 설정 및 관리가 간소화됩니다.

Kubernetes Operator는 MongoDB 및 Ops Manager 와 함께 작동하여 설정을 정의하기 위해 생성하는 사용자 지정 리소스 파일을 사용하여 구성을 자동화합니다. 이를 통해 Git 리포지토리에서 구성을 관리하는 GitOps 워크플로를 활성화하는 도구를 포함하여 Kubernetes에서 애플리케이션을 관리하기 위해 이미 가지고 있는 도구를 사용하여 구성을 관리할 수 있습니다. 높은 수준의 자동화와 복잡성으로부터의 추상화 덕분에 Kubernetes와 Kubernetes Operator는 내부 사용자 또는 외부 고객을 위해 MongoDB를 서비스로 실행하는 데 특히 적합합니다.

Kubernetes를 통해 MongoDB는 복제본 세트 또는 샤드 클러스터를 구성하는 손실된 Pod의 자동 교체와 같이 Kubernetes가 제공하는 확장성과 자동화된 복원력을 활용할 수 있습니다. 이를 통해 MongoDB는 Kubernetes에서 실행할 때 확장성과 복원력이 매우 뛰어날 수 있습니다.

Kubernetes 내의 MongoDB는 베어메탈 또는 VM에서 MongoDB만큼 확장 가능합니다. 대부분의 고객은 Kubernetes 내에서 확장성을 더 쉽게 달성할 수 있습니다. Kubernetes Operator와 Kubernetes는 원활하게 함께 작동하므로 멀티 클러스터 및 멀티 사이트 복원력을 위해 여러 Kubernetes 클러스터에 MongoDB 배포를 확장하는 기능을 포함하여 수평으로 쉽게 확장할 수 있습니다.

수직 확장은 배포를 정의하는 사용자 지정 리소스에서 배포에 대한 리소스를 변경하는 것만큼 쉽습니다.

이 모든 것이 MongoDB를 확장하여 모든 요구 사항을 충족할 수 있도록 합니다.

기술적인 측면에서 단점은 없습니다. Kubernetes 내의 MongoDB는 모든 하드웨어 또는 인프라에서 실행되는 MongoDB만큼 성능과 확장성이 뛰어납니다.

그러나 다른 인프라와 마찬가지로 고객이 이 기술(이 경우 Kubernetes)에 대한 친숙성과 전문 지식을 보유해야 한다는 본질적인 요구 사항이 있습니다. Kubernetes Operator는 Kubernetes 내에서 MongoDB 설정을 간소화하고 자동화하지만, Kubernetes 클러스터의 일부인 기본 리소스 및 기능(예: 상태 저장 스토리지, 네트워킹, 보안, 컴퓨팅 등)에 대한 종속성은 여전히 존재합니다. 이는 베어메탈 또는 가상 머신에서 실행하는 경우 고객이 MongoDB를 지원하기 위해 해당 서비스와 리소스를 사용할 수 있고 올바르게 구성할 수 있는지 확인해야 함을 의미합니다.

MongoDB Server는 기본 로직이나 동작을 변경하지 않고 네이티브 Kubernetes를 기반으로 구축되는 모든 플랫폼을 지원합니다. 실제로 이는 MongoDB Server가 Cloud Native Computing Foundation에서 인증한 모든 Kubernetes 플랫폼을 지원한다는 의미입니다. . 자세한 내용은 MongoDB Kubernetes 연산자 호환성을 참조하세요.

Kubernetes Operator는 수백 개의 배포를 지원할 수 있습니다. 병렬 조정 작업을 용이하게 하고 조정 시간이 길어지는 것을 방지하려면 Kubernetes Operator 인스턴스의 스레드 수를 늘리세요.

지연 시간을 최소화하려면 배포 아키텍처에서 허용하는 경우 데이터베이스와 애플리케이션을 동일한 Kubernetes cluster에 배치하는 것이 좋습니다.

네. 자세한 내용 은 여러 Kubernetes 클러스터에 MongoDB 리소스 배포 를 참조하세요. 도움이 필요하면 MongoDB 지원팀 에 문의하세요.

다중 Kubernetes 클러스터 MongoDB 배포를 관리하기 위해 Kubernetes Operator를 사용하려면 특정 Kubernetes 역할 세트인 ClusterRoles 설정해야합니다. , RoleBindings, ClusterRoleBindings및 ServiceAccounts.

다중 Kubernetes 클러스터 MongoDB 배포에 사용되는 Kubernetes Operator는 단일 Kubernetes 클러스터 리소스를 조정할 수도 있습니다. 자세한 내용은 MongoDB가 둘 이상의 Kubernetes 연산자 인스턴스 실행을 지원하나요?를 참조하세요.

가능하면 단일 Kubernetes Operator 인스턴스를 설정하여 Kubernetes 클러스터 내의 하나, 여러 개 또는 모든 네임스페이스를 감시하는 것이 좋습니다. 기본적으로 Kubernetes Operator는 모든 사용자 지정 리소스 를 감시합니다. 특정 리소스 유형을 감시하기 위해 구성할 필요가 없습니다.

그러나 단일 Kubernetes 연산자 인스턴스가 지원할 수 있는 배포 수의 성능 제한 에 도달하면 추가 Kubernetes 연산자 인스턴스를 설정할 수 있습니다. 이 점에서 Kubernetes cluster의 리소스 관리를 어떻게 분할할 것인지 고려하세요. 우선 순위에 따라 나열된 다음 권장 사항을 사용합니다.

  • 각 Kubernetes 연산자 인스턴스가 Kubernetes cluster 내에서 겹치지 않는 서로 다른 네임스페이스를 감시하고 있는지 확인합니다.

  • 또는, 다른 네임스페이스나 겹치는 네임스페이스에서 다양한 리소스 유형을 감시하도록 Kubernetes 연산자의 여러 인스턴스를 구성합니다.

    겹치는 네임스페이스를 사용하기로 선택한 경우, 각 Kubernetes 연산자 인스턴스가 서로 다른 유형의 리소스를 감시하여 충돌로 인해 Kubernetes 연산자의 두 인스턴스가 동일한 리소스를 managed하려고 시도하는 것을 방지할 수 있습니다.

참고

다른 Kubernetes 연산자 인스턴스를 구성하기 전에 해당 네임스페이스가 기존 Kubernetes 연산자 인스턴스의 네임스페이스 하위 집합에 포함되어 있지 않은지 확인합니다.

돌아가기

타사 라이선스

다음

릴리스 노트