프로비저닝이 부족한 EBS 볼륨으로 인해 IOPS 대기 시간이 길어짐
kops 를 사용한 경우 Kubernetes Amazon Web Services 에서 클러스터를 프로비저닝할 때 성능이 저하되고 IOPS 대기 시간이 길어지는 경우, Elastic Block Store(EBS) 볼륨의 프로비저닝이 부족할 수 있습니다.
성능을 향상시키려면 EBS 볼륨의 스토리지 대 IOPS 비율을 높입니다. 예를 들어 데이터베이스가 500 GB인 경우 IOPS를 GB당 3:1 비율인 1500 로 늘립니다. IOPS를 높이는 방법에 대해 자세히 알아보려면 Amazon Web Services 설명서를 참조하세요.
ConfigMap 이름 mongodb-kubernetes-operator-member-list 이(가) 하드 코딩되었습니다.
예를 들어 다중 Kubernetes 클러스터 빠른 시작 절차 중에 kubectl mongodb 플러그인을 실행 하면 플러그인이 mongodb-kubernetes-operator-member-list 라는 기본값 ConfigMap을 생성합니다. 이 ConfigMap에는 멀티 Kubernetes 클러스터 MongoDB deployment 의 모든 멤버가 포함되어 있습니다. ConfigMap의 이름은 변경할 수 없습니다. 플러그인의 플래그 및 작업에 학습 보려면 MongoDB 플러그인 참조를 참조하세요.
mongos 인증 비활성화 후 인스턴스 준비 상태에 도달하지 못함
참고
이 문제는 다음 기준을 충족하는 샤드 클러스터 에만 적용됩니다.
Kubernetes 연산자 1.13.0을 사용하여 배포됨
X.509 인증 사용
Kubernetes.io/tls 사용 MongoDB Agent의 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-kubernetes-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
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) 사용량을 보고합니다.
MacOS에서 Docker Desktop OpsManager를 사용하는 호스트가 데이터베이스 이미지를 다운로드 하지 못함
OpsManager 로그에 다음과 같은 오류가 표시되는 경우:
['desiredState.FullVersion' is not a member of 'currentState.VersionsOnDisk' ('desiredState.FullVersion'={"trueName":"8.0.4","gitVersion":"bc35ab4305d9920d9d0491c1c9ef9b72383d31f9","modules":null,"major":8,"minor":0,"patch":4}, 'currentState.VersionsOnDisk'=[])] (err=<nil>). Outcome=Failure
다음과 같은 Docker Desktop 설정 조합으로 문제를 해결할 수 있습니다.