MongoDB Enterprise Kubernetes Operator의 알려진 문제

프로비저닝이 부족한 EBS 볼륨으로 인해 IOPS 대기 시간이 길어짐

kops 를 사용하여 Amazon Kubernetes Web Services Amazon Web Services 에서 Kubernetes 클러스터 를 프로비저닝했는데 성능이 저하되고 IOPS 대기 시간이 길어지는 경우, Elastic Block Store(EBS) 볼륨의 프로비저닝이 부족할 수 있습니다.

성능을 향상시키려면 EBS 볼륨의 스토리지 대 IOPS 비율을 높입니다. 예를 들어 데이터베이스가 500 GB인 경우 IOPS를 GB당 3:1 비율인 1500 로 늘립니다. IOPS를 높이는 방법에 대해 자세히 알아보려면 Amazon Web Services 설명서를 참조하세요.

ConfigMap 이름 mongodb-enterprise-operator-member-list 이(가) 하드 코딩되었습니다.

예를 들어 다중 Kubernetes 클러스터 빠른 시작 절차 중에 kubectl mongodb 플러그인을 실행 하면 플러그인이 mongodb-enterprise-operator-member-list 라는 기본값 ConfigMap을 생성합니다. 이 ConfigMap에는 멀티 Kubernetes 클러스터 MongoDB deployment 의 모든 멤버가 포함되어 있습니다. ConfigMap의 이름은 변경할 수 없습니다. 플러그인의 플래그 및 작업에 학습 보려면 MongoDB 플러그인 참조를 참조하세요.

mongos 인증 비활성화 후 인스턴스 준비 상태에 도달하지 못함

spec.security.auth.enabled 을(를) false(으)로 설정하여 인증을 비활성화하면 mongos 파드가 ready 상태에 도달하지 않습니다.

이 문제를 해결하려면 배포에서 각 mongos Pod를 삭제합니다.

다음 명령어를 실행하여 모든 Pod를 나열합니다.

kubectl get pods

이름에 mongos 가 포함된 각 Pod에 대해 다음 명령을 사용하여 삭제합니다.

kubectl delete pod <podname>

파드를 삭제하면 Kubernetes가 파드를 다시 생성합니다. Kubernetes가 다시 생성하는 각 Pod는 업데이트된 구성을 수신하며 READY 상태에 도달할 수 있습니다. 모든 mongos 파드가 READY 인지 확인하려면 다음 명령을 실행합니다.

kubectl get pods -n <metadata.namespace>

다음과 같은 응답은 모든 mongos 파드가 READY 임을 나타냅니다.

NAME                                           READY   STATUS    RESTARTS   AGE
mongodb-enterprise-operator-6495bdd947-ttwqf   1/1     Running   0          50m
my-sharded-cluster-0-0                         1/1     Running   0          12m
my-sharded-cluster-1-0                         1/1     Running   0          12m
my-sharded-cluster-config-0                    1/1     Running   0          12m
my-sharded-cluster-config-1                    1/1     Running   0          12m
my-sharded-cluster-mongos-0                    1/1     Running   0          11m
my-sharded-cluster-mongos-1                    1/1     Running   0          11m
om-0                                           1/1     Running   0          42m
om-db-0                                        2/2     Running   0          44m
om-db-1                                        2/2     Running   0          43m
om-db-2                                        2/2     Running   0          43m

Google 방화벽 규칙을 업데이트하여 WebHook 문제 해결

Kubernetes Operator를 GKE(Google Kubernetes Engine) 에 배포하는 MongoDB 경우 비공개 클러스터의 경우 리소스 또는 MongoDBOpsManager 리소스 생성 시간이 초과될 수 있습니다. 다음 메시지가 로그에 나타날 수 있습니다: Error setting state to reconciling: Timeout: request did not complete within requested timeout 30s.

Google은 Kubernetes Pod 에 대한 액세스를 제한하도록 방화벽을 구성합니다. . 웹훅 서비스를 사용하려면새 방화벽 규칙을 추가하세요.GKE(Google Kubernetes Engine) 를 부여합니다. 웹훅 서비스에 대한 플레인 액세스를 제어합니다.

Kubernetes Operator 웹훅 서비스는 포트 443에서 실행됩니다.

영구 저장소를 올바르게 구성합니다.

영구 볼륨 이 없는 경우 리소스를 생성할 때 사용 가능한 결과 Pod 가 일시적인 상태로 유지되고 연산자가 실패하고(20 재시도 후) 다음 오류가 발생합니다.

Failed to update Ops Manager automation config: Some agents failed to register

이 오류를 방지하려면 다음 중 하나를 수행하세요.

• 영구 볼륨 제공 또는

• 리소스에 대해 persistent : false 설정

테스트용으로만 persistent : false 설정할 수 있습니다. 다시 시작하는 사이에 데이터가 보존되지 않으므로 프로덕션 환경에서는 사용 하면 안 됩니다.

Kubernetes를 제거하기 전에 리소스 제거

경우에 따라 Ops Manager는 Kubernetes와 분리될 수 있습니다. 이 문제는 대부분 Kubernetes 리소스를 수동으로 제거할 때 발생합니다. Ops Manager는 종료된 자동화 에이전트를 계속 표시할 수 있습니다.

Kubernetes에서 MongoDB 배포를 제거하려면 리소스 사양을 사용하여 먼저 리소스를 삭제하여 작동하지 않는 자동화 에이전트가 남아 있지 않도록 합니다.

발생할 수 있는 문제를 해결하려면 다음을 참조하세요.

• MongoDB 리소스 제거

• Ops Manager 기능 제어 비활성화

• Kubernetes Operator 실패 시 리소스 제거

Kubernetes 연산자 및 MongoDB 리소스에 대해 별도의 네임스페이스 생성

가장 좋은 전략은 다음 작업이 올바르게 작동하도록 Kubernetes 연산자와 해당 리소스를 서로 다른 네임스페이스에 생성하는 것입니다.

kubectl delete pods --all

or

kubectl delete namespace mongodb

Kubernetes 연산자와 리소스가 동일한 mongodb 네임스페이스 에 있는 경우 , 연산자도 동일한 작업에서 제거됩니다. 이는 MongoDB Ops Manager 애플리케이션에서 수행해야 하는 구성을 정리할 수 없음을 의미합니다.

배포 후 HTTPS 활성화

Ops Manager 리소스를 배포 하기 전에 HTTPS 를 활성화하는 것이 좋습니다. 그러나 배포 후 HTTPS 를 활성화하면 managed 리소스는 더 이상 Ops Manager와 통신할 수 없으며 Kubernetes 연산자는 리소스의 상태를 Failed 로 보고합니다.

이 문제를 해결하려면 Pods 를 삭제해야 합니다. 각 Pod에 대해 다음 명령어를 실행합니다.

kubectl delete pod <replicaset-pod-name>

삭제 후 Kubernetes는 삭제된 파드를 자동으로 다시 시작합니다. 이 기간 동안에는 리소스에 연결할 수 없으며 다운타임이 발생합니다.

애플리케이션 데이터베이스 Pods에서 MongoDB Agent를 업데이트할 수 없음

MongoDB Ops Manager 를 사용하여 애플리케이션 데이터베이스 파드에서 실행 되는 MongoDB Agent 를 업그레이드 할 수 없습니다. 이러한 파드에서 실행되는 MongoDB Agent 버전은 애플리케이션 데이터베이스 Docker 이미지에 포함됩니다.

MongoDB가 새 이미지를 게시할 때 애플리케이션 데이터베이스 파드에서 MongoDB Agent 버전을 업그레이드하기 위해 Kubernetes Operator를 사용할 수 있습니다.

IBM Cloud Pak에서 Enterprise Kubernetes Operator 이미지를 가져올 수 없음

IBM Cloud Paks 에 호스팅된 컨테이너 레지스트리에서 Kubernetes Operator 이미지를 가져오는 경우 , IBM Cloud Paks는 공식 이미지 이름에 다이제스트 SHA를 추가하여 이미지 이름을 변경합니다. 이 작업을 수행하면 Kubernetes Operator에서 다음과 유사한 오류 메시지가 표시됩니다.

Failed to apply default image tag "cp.icr.io/cp/cpd/ibm-cpd-mongodb-agent@
sha256:10.14.24.6505-1": couldn't parse image reference "cp.icr.io/cp/cpd/
ibm-cpd-mongodb-agent@sha256:10.14.24.6505-1": invalid reference format

이 문제를 해결하려면 spec.applicationDatabase.podSpec.podTemplate 에서 Ops Manager 애플리케이션 데이터베이스 리소스 정의를 업데이트하여 다음 예와 유사하게 다이제스트 SHA를 포함하는 Kubernetes 연산자 이미지에 새 이름을 지정합니다.

applicationDatabase:
  # The version specified must match the one in the image provided in the `mongod` field
  version: 4.4.11-ubi8
  members: 3
  podSpec:
    podTemplate:
      spec:
        containers:
          - name: mongodb-agent
            image: 'cp.icr.io/cp/cpd/ibm-cpd-mongodb-agent@sha256:689df23cc35a435f5147d9cd8a697474f8451ad67a1e8a8c803d95f12fea0b59'

머신 메모리 대 컨테이너 메모리

Cloud Manager 및 Ops Manager의 자동화 에이전트는 Kubernetes 컨테이너 메모리 사용량 대신 호스트 메모리(RAM) 사용량을 보고합니다.