MongoDB Enterprise Kubernetes Operator의 알려진 문제

MongoDB 엔터프라이즈 Kubernetes Operator는 더 이상 사용되지 않습니다. The new Kubernetes Operator용 MongoDB 컨트롤러 가 MongoDB 엔터프라이즈 Kubernetes Operator를 대체합니다. Kubernetes Operator용 컨트롤러의 첫 번째 버전은 Enterprise Kubernetes Operator 의 v1.33 버전과 기능적으로 동일합니다. 이 변경 사항에 대한 자세한 내용과 새 연산자로 마이그레이션하는 방법에 대한 지침은 첫 번째 새 버전의 출시 노트 를 참조하세요. MongoDB 엔터프라이즈 Kubernetes Operator의 향후 릴리스는 없을 예정입니다. 각 버전은 기존 1년 지원 정책에 따라 수명이 종료됩니다. 지속적인 지원 받으려면 Kubernetes Operator용 컨트롤러로 마이그레이션 하세요.

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

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

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

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

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

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

참고

이 문제는 다음 기준을 충족하는 샤드 클러스터 에만 적용됩니다.

Kubernetes 연산자 1.13.0을 사용하여 배포됨
X.509 인증 사용
MongoDB Agent 의 TLS 인증서에 kubernetes.io/tls 시크릿 사용

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 배포를 제거하려면 리소스 사양을 사용하여 먼저 리소스를 삭제하여 작동하지 않는 자동화 에이전트가 남아 있지 않도록 합니다.

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

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

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

kubectl delete pods --all

kubectl delete namespace mongodb

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

배포 후 HTTPS 활성화

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

이 문제를 해결하려면 각 파드에 대해 다음 명령을 실행 하여 파드를 삭제 해야 합니다.

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) 사용량을 보고합니다.

돌아가기

문제 해결

클라우드 매니저