이 절차는 하나의 Kubernetes 연산자 설치가 managed MongoDB 배포서버를 동일한 Ops Manager 또는 Cloud Manager 프로젝트의 두 번째 Kubernetes 연산자 설치로 마이그레이션합니다. 이 절차는 가상 머신에서 Kubernetes로 처음 마이그레이션하는 경우가 아니라, 네임스페이스 간 또는 Kubernetes 클러스터 간에 배포서버를 이동할 때 사용하세요.
이 마이그레이션에서, 소스 배포서버는 이미 Kubernetes 연산자 managed입니다. 자동화 구성에는 Kubernetes 연산자 스타일 프로세스 이름과 호스트 이름이 포함되어 있습니다. 대상은 다른 네임스페이스 또는 클러스터에 두 번째 Kubernetes 연산자를 설치하는 것입니다.
시작하기 전에
두 개의 Kubernetes 연산자 설치 사이에서 배포서버를 마이그레이션하기 전에 다음 사항을 확인하세요.
Ops Manager 또는 Cloud Manager 연결
ConfigMap이baseUrl,orgId및projectName키를 사용합니다.키
publicKey및privateKey를 가진 API 키Secret입니다.Kubernetes 연산자
ServiceAccount는 가상 실행 연결 작업을 위해batch/jobs권한(create,get,list,watch및delete)을 가집니다.프로젝트는 정확히 하나의 배포서버를 포함합니다.
다음도 필요합니다:
실행 중인 Kubernetes 연산자 설치가 managed하는 소스 배포서버입니다.
소스와 다른 네임스페이스 또는 Kubernetes 클러스터에 있는 대상이 되도록 하려는 두 번째 Kubernetes 연산자 설치.
동일한 MongoDB Ops Manager 또는 Cloud Manager 프로젝트 ConfigMap 및 자격 증명에 대해 구성된 두 설치 모두.
항상 최소 3 명의 투표 회원을 유지하세요. Kubernetes 연산자는 7 개 이상의 투표권을 가진 노드를 거부합니다. 7를 초과하는 경우, 투표권이 없는 Kubernetes 노드를 추가하거나 투표권이 있는 외부 노드를 제거합니다.
한 번에 한 가지 유형의 변경만 수행하십시오. Kubernetes 노드 추가, 외부 노드 정리, 또는 한 번에 하나의 노드에 대한 투표 및 우선 순위 변경만 수행하십시오. 마이그레이션이 시작되면 승인 유효성 검사가 혼합된 변경 사항을 거부하며, 마이그레이션 중간에 Kubernetes 노드를 제거하거나 외부 노드를 추가하는 것도 거부합니다.
배포가 목표 상태에 도달했을 때에만 작업하세요.
프라이머리 마지막에 마이그레이션하세요. 노드에 투표 및 우선 순위를 할당하면 투표가 trigger될 수 있으며, 복제본 세트가 새 프라이머리를 투표하는 동안 쓰기 (write)가 일시적으로 실패할 수 있습니다. 프라이머리를 마지막으로 마이그레이션하면 최종 단계까지 해당 투표를 트리거하는 것과 이로 인해 발생하는 쓰기 (write) 다운타임을 방지할 수 있습니다.
참고
Kubernetes에서 노드의 우선 순위를 높여 재투표를 trigger할 수도 있습니다.
spec.externalMembers이 비어 있지 않은 동안 Kubernetes 연산자는 노드 하나씩 확장을 강제합니다. 그러므로 각 변경은 각각 목표 상태를 기다리는 과정이 필요합니다.
가상 머신에서 마이그레이션하는 것과 이것의 차이점
MCK-MCK 마이그레이션은 가상 머신 배포서버 마이그레이션과 동일한 확장, 승격 및 제거 루프를 사용합니다. 소스 노드는 대상 리소스에서 spec.externalMembers으로 표시됩니다. 이는 가상 마신에서 마이그레이션할 때와 동일한 방식입니다. 해당 루프의 자세한 단계별 메카닉스는 복제본 세트를 Kubernetes로 마이그레이션을 참조하세요.
이 마이그레이션에는 가상 머신 마이그레이션에는 적용되지 않는 추가 요구 사항이 있습니다.
먼저 소스 연산자를 중지하거나 범위를 축소하세요. 시작하기 전에 소스 Kubernetes 연산자 설치를 중지하거나 배포서버 조정이 중지되었는지 확인하세요. 두 개의 연산자가 동시에 동일한 MongoDB Ops Manager 또는 Cloud Manager 프로젝트를 조정해서는 안 됩니다.
두 연산자 모두 동일한 프로젝트 ConfigMap 및 자격 증명을 공유해야 합니다. 소스 및 대상 Kubernetes 연산자 설치는 동일한 Ops Manager 또는 Cloud Manager 프로젝트에 연결됩니다.
클러스터 범위의 Helm 리소스 이름은 충돌해서는 안 됩니다. 두 개의 연산자 Helm 설치는 클러스터 범위 리소스에 대해 서로 다른 이름을 사용해야 합니다.
네임스페이스는 달라야 합니다. 소스 및 대상 설치가 네임스페이스를 공유하는 경우 프로세스 이름이 충돌합니다.
배포서버 마이그레이션
중요
계속하기 전에 소스 연산자를 중지하거나 범위를 축소하세요. 이전 섹션을 참조하십시오.
Kubernetes로 복제본 세트 마이그레이션에 설명된 동일한 확장, 승격 및 정리 시퀀스를 따르세요. 대상 Kubernetes 연산자 설치의 네임스페이스 및 클러스터에 대해 대상 MongoDB 사용자 지정 리소스를 생성합니다. 소스 노드는 대상 리소스의 spec.externalMembers에서 제거할 때까지 표시됩니다.
이유 | 상태 | 의미 |
|---|---|---|
|
| dry-run 어노테이션이 설정되었습니다. |
|
| 원하는 Kubernetes 노드 수가 마지막으로 조정된 수보다 많습니다. |
|
|
|
|
| 외부 노드가 있지만 아무것도 변경되지 않습니다. 이것이 첫 번째 일치 시의 그러한 이유이기도 됩니다. |
|
| 모든 외부 노드가 제거되었습니다. |
우선순위는 Validating > Extending > Pruning > InProgress입니다. Kubernetes 측을 확장하는 프루는 Extending을 보고합니다. 이는 단일 변경을 수행해야 하는 또 다른 이유가 됩니다.
가지치기와 확장은 동시에 수행할 수 없습니다.
마이그레이션 완료를 스크립트로 작성하려면 status.phase을 폴링하는 대신 kubectl wait --for=condition=Migrating=False을 사용하세요.
소스 정리
마이그레이션이 완료되면 소스 MongoDB 사용자 지정 리소스를 삭제합니다. Ops Manager 또는 Cloud Manager 프로젝트를 삭제하지 말고 기본 데이터를 삭제하지 마십시오. 소스 사용자 지정 리소스를 삭제하면 해당 리소스에 대한 소스 Kubernetes 연산자 설치의 관리만 제거됩니다.