이 가이드는 Kubernetes 연산자를 MongoDBSearch의 GA(General Availability) 릴리스로 업그레이드한 후 기존 MongoDBSearch 배포서버를 다시 만들기 위해 수행해야 하는 변경 사항에 대해 설명합니다.
중요
이 마이그레이션은 인플레이스 업그레이드가 아니며, 마이그레이션하는 동안 검색이 계속 실행되지 않습니다. Kubernetes 연산자는 검색 배포서버를 처음부터 다시 빌드합니다. 새 배포서버가 준비되고 데이터 재인덱싱이 완료될 때까지 MongoDB Search 및 벡터 검색 쿼리($search 및 $vectorSearch 집계 단계)를 사용할 수 없습니다. 이 가이드를 사용하여 GA Kubernetes 연산자에서 Public Preview 배포서버의 동등한 구성을 다시 만듭니다. 중단 없이 실행 중인 배포서버를 업그레이드하는 것이 아닙니다.
이 가이드에서 "공개 미리 보기"는 GA 전의 MongoDBSearch 모든 릴리스를 의미합니다. MongoDBSearch 사용자 지정 리소스에는 항상 하나의 API 버전( v1)만 있었으므로 Kubernetes 또는 Kubernetes 연산자는 이전 필드 값을 자동으로 변환하지 않습니다. 이 가이드의 모든 변경 사항을 기존 매니페스트에 수동으로 한 번 적용해야 합니다.
이 가이드에서는 새로운 GA 역량 또는 선택 사항 필드는 다루지 않습니다. 특정 섹션이 기존 매니페스트에 적용되지 않는 경우 건너띍니다.
시작하기 전에
GA는 최소 지원 mongot 버전인 1.70.1을 시행합니다. MongoDBSearch 리소스가 1.70.1보다 이전의 명시적 spec.version 를 고정하는 경우 업그레이드 후 지원되지 않는 버전 오류로 인해 조정이 실패합니다. spec.version를 설정하지 않은 경우 Kubernetes Operator가 자체 기본값(1.70.1 이 GA 릴리즈 기준) 을 제공하므로 별도의 조치를 취할 필요가 없습니다.
업그레이드하기 전에 고정한 버전이 있는지 확인하십시오.
kubectl get mongodbsearch <name> -n <namespace> -o jsonpath='{.spec.version}'
명령이 1.70.1 이전 버전을 인쇄하면 다음 섹션의 매니페스트 변경 내용의 일부로 spec.version 을 1.70.1 또는 이후 버전으로 업데이트합니다.
MongoDBSearch 구성 업데이트
공개 미리 보기 MongoDBSearch 사용자 지정 리소스에는 spec.clusters 필드가 없습니다. GA에서는 spec.clusters 이(가) 필요하며, 이전에 spec 의 최상위 수준에 있던 여러 필드가 이제는 spec.clusters[0] 내부에만 있습니다. 모든 기존 매니페스트에는 토폴로지에 관계없이 동일한 기계적 편집이 한 번 필요합니다.
이 섹션의 예시에서는 mongodb 네임스페이스에 있는 my-search 이라는 MongoDBSearch 리소스를 사용합니다. 리소스의 이름과 네임스페이스를 대체합니다.
필수 spec.clusters 필드를 추가하고 클러스터 별 설정을 이동합니다.
여섯 개의 최상위 spec 필드가 spec.clusters[0] 내부로 이동합니다.
공개 미리보기 경로 | GA 경로 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
spec.clusters 에 정확히 하나의 엔트리가 있는 경우(모든 Public Preview 워크로드에 해당)에는 spec.clusters[0].name 또는 spec.clusters[0].index를 설정할 필요가 없습니다.
logLevel, security, source, version 및 autoEmbedding 은 spec의 최상위 레벨에 그대로 유지됩니다.
예시
다음 공개 미리 보기 구성:
apiVersion: mongodb.com/v1 kind: MongoDBSearch metadata: name: my-search namespace: mongodb spec: source: mongodbResourceRef: name: my-replica-set replicas: 3 persistence: single: storage: 20Gi resourceRequirements: requests: cpu: "1" memory: 2Gi limits: cpu: "2" memory: 4Gi statefulSet: spec: template: spec: nodeSelector: disktype: ssd loadBalancer: managed: replicas: 2 jvmFlags: - "-Xmx2g"
GA에서 다음 구성이 됩니다.
apiVersion: mongodb.com/v1 kind: MongoDBSearch metadata: name: my-search namespace: mongodb spec: source: mongodbResourceRef: name: my-replica-set clusters: - replicas: 3 persistence: single: storage: 20Gi resourceRequirements: requests: cpu: "1" memory: 2Gi limits: cpu: "2" memory: 4Gi statefulSet: spec: template: spec: nodeSelector: disktype: ssd loadBalancer: managed: replicas: 2 jvmFlags: - "-Xmx2g"
중요
이 단계를 거너뛰면 Kubernetes API 서버가 공개 미리 보기 매니페스트를 완전히 거부합니다. spec.clusters 은 기본값이 없는 필수 필드이므로 지연되거나 조용한 승인 실패가 아니라 즉시 승인 실패가 발생합니다.
spec.prometheus 을 spec.observability.prometheus(으)로 이동합니다.
이 변경은 이름 변경 이상입니다. GA에서는 Prometheus 지표 엔드포인트가 기본적으로 활성화되지만 공개 미리 보기에서는 spec.prometheus를 명시적으로 설정하지 않으면 비활성화되었습니다.
spec.prometheus을 이미 설정했은 경우 그대로 이동합니다.
예시
공개 미리보기:
spec: prometheus: port: 9946
GA:
spec: observability: prometheus: port: 9946
spec.prometheus을 설정하지 않은 경우 이동할 것이 없지만 업그레이드 후에는 이전에 없었던 포트 9946 에 Prometheus 스크래프 대상이 표시됩니다.
중요
업그레이드 후에도 지표를 비활성화된 상태로 유지하려면 다음을 명시적으로 추가합니다.
spec: observability: prometheus: mode: disabled
외부 MongoDB TLS CA 참조를 Secret에서 ConfigMap으로 업데이트합니다.
경고
이 변경으로 인해 기존 TLS가 자동 폴백 없이 중단됩니다. MongoDBSearch 리소스가 spec.source.external.tls.ca 에서 TLS CA를 구성하고 있는 경우 이 단계를 건너뛰면 GA Kubernetes 연산자가 조정을 시작하는 순간 외부 TLS가 중단됩니다. 연산자는 ConfigMap만 읽으며 Secret로 폴백하지 않습니다. 리소스가 spec.source.external.tls.ca 을 사용하지 않는 경우 이 단계는 적용되지 않습니다.
필드 경로 spec.source.external.tls.ca.name은(는) 변경되지 않습니다. 변경되는 것은 Kubernetes 연산자가 해당 이름에서 예상하는 Kubernetes 객체 유형입니다. 이는 사전 미리 보기에서의 Secret 이고 GA에서의 ConfigMap 입니다. 두 개 모두 동일한 키 ca.crt에서 CA 인증서를 예상합니다.
예시
공개 미리 보기에서 spec.source.external.tls.ca.name 는 Secret을(를) 의미합니다.
apiVersion: v1 kind: Secret metadata: name: my-search-external-ca namespace: mongodb type: Opaque stringData: ca.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----
GA에서는 동일한 이름이 동일한 ca.crt 키를 가진 ConfigMap 을(를) 참조해야 합니다.
apiVersion: v1 kind: ConfigMap metadata: name: my-search-external-ca namespace: mongodb data: ca.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----
참조되는 MongoDBSearch 리소스는 변경되지 않습니다. spec.source.external.tls.ca.name 은 여전히 동일한 이름을 가리킵니다.
apiVersion: mongodb.com/v1 kind: MongoDBSearch metadata: name: my-search namespace: mongodb spec: source: external: hostAndPorts: - mongodb-0.example.com:27017 tls: ca: name: my-search-external-ca
가능하면 Kubernetes 연산자를 업그레이드하기 전에 또는 동시에 ConfigMap 을(를) 만들세요.
kubectl create configmap my-search-external-ca \ --from-file=ca.crt=./ca.crt \ --namespace mongodb
이전 예시에서 볼 수 있듯이 이전 Secret의 이름을 다시 사용하거나 새 이름을 선택할 수 있습니다. Kubernetes 연산자는 이전 Secret을 더 이상 읽지 않습니다. 외부 TLS가 다시 작동하는 것을 확인한 후에 삭제할 수 있습니다.
Kubernetes 리소스에 어떤 일이 발생하나요
이 섹션에서는 Kubernetes 연산자가 관리하는 기본 Kubernetes 객체에 대해 설명하고 이후 확인하고 정리해야 할 사항을 설명합니다. 변경 사항은 MongoDBSearch 리소스가 복제본 세트에서 동기화되는지 샤딩된 클러스터에서 동기화되는지에 따라 다릅니다.
이름을 유지핕는 리소스
대부분의 연산자 managed 리소스는 GA에서 동일한 이름을 유지합니다. Kubernetes Operator는 다음 조정에서 이러한 리소스를 제자리에서 업데이트하므로 별도의 조치를 취할 필요가 없습니다.
프록시 서비스(
<name>-search-0-proxy-svc)Envoy 로드 밸런서 배포서버, ConfigMap 및 인증서(
<name>-search-lb-0...)TLS, X.509 및 비밀 시크릿은 샤딩된 클러스터 소스: 이름은 변경되지 않음, 한 가지 예외에 설명된 연산자-managed 샤드별 TLS 시크릿을 제외하고 모두 사용할 수 있습니다.
복제본 세트 소스: 새 이름으로 다시 만들어진 리소스
MongoDBSearch 리소스가 복제본 세트(샤딩되지 않은) 소스에서 동기화되는 경우 GA Kubernetes 연산자는 MongoDBSearch 리소스를 처음으로 조정할 때 새 이름의 리소스 3개를 다시 만듭니다. Kubernetes 연산자는 이전 객체를 채택하거나, 이름을 변경하거나, 삭제하지 않습니다. 이 동작은 설계된 것입니다.
다음 표에서는 이전 섹션의 my-search 예시 리소스를 사용합니다.
Resource | 공개 미리보기 이름 | GA 이름 |
|---|---|---|
|
|
|
|
|
|
|
|
|
이 변경은 다음과 같은 실용적인 효과가 있습니다.
새 StatefulSet은 비어 있는 상태로 시작됩니다. 포드에 새
PersistentVolumeClaims이 할당됩니다. 따라서mongot은 처음부터 다시 인덱싱을 수행합니다. 이는 데이터 세트 크기에 따라 시간이 걸릴 수 있습니다.이전 StatefulSet의 팝은 계속 실행됩니다. Kubernetes 연산자는 이를 축소하지 않습니다. 이전 StatefulSet을 삭제하기 전까지
mongot팝에 대해 동일한 컴퓨트를 double 실행합니다.이전 StatefulSet의 PVC 및 이전 ConfigMap이 단절됩니다. 더 이상 읽지 않습니다. 하지만 삭제되지도 않습니다.
헤드리스 서비스의 DNS 이름 변경에 대해 조치를 취할 필요가 없습니다. 로드 밸런서가 없으면 Kubernetes Operator가 동기화 소스 연결 문자열을 매 조정마다 다시 작성합니다. managed 또는 unmanaged 로드 밸런서를 사용하는 경우 이 서비스는 연결 경로의 일부가 아닙니다.
중요
Kubernetes Operator는 오래된 객체를 절대 삭제하지 않습니다. 새 StatefulSet가 정상적인 지 확인한 후(확인 참조), 오래된 리소스 삭제하여 두 배로 계산되는 비용을 무기한적으로 지불하는 것을 피합니다. 이 정리는 선택 사항이 아니라 필수 단계입니다.
이전 StatefulSet, Service 및 ConfigMap을 삭제합니다.
먼저 새 StatefulSet가 정상인지 확인한 후(확인 참조), 다음을 실행합니다.
kubectl delete statefulset my-search-search -n mongodb kubectl delete service my-search-search-svc -n mongodb kubectl delete configmap my-search-search-config -n mongodb
오판된 PersistentVolumeClaims를 삭제합니다.
StatefulSet을 삭제하면 PVC는 삭제되지 않으므로 별도 제거해야 합니다.
Preview the PVCs to delete: PVCS=$(kubectl get pvc -n mongodb -o name \ | grep -E 'data-my-search-search-[0-9]+$') echo "$PVCS" After confirming, delete exactly what you previewed: echo "$PVCS" | xargs kubectl delete -n mongodb
오래된 PVC는 data-my-search-search-<ordinal>와 일치합니다(예시: data-my-search-search-0). data-my-search-search-0-<ordinal>와 일치하는 것은 삭제하지 마십시오(예: data-my-search-search-0-0). 이들은 새 StatefulSet에 속합니다.
샤딩된 클러스터 소스: 이름은 변경되지 않음(한 가지 제외)
MongoDBSearch 리소스가 샤딩된 클러스터 소스에서 동기화되는 경우 샤드 별 리소스 이름은 공개 미리 보기와 GA에서 동일합니다. Kubernetes Operator는 새 이름으로 다시 만들지 않습니다. 대신 제자리에서 업데이트합니다.
Resource | 개발자 및 GA에서의 이름(변경 없음) |
|---|---|
샤드별 |
|
샤드별 |
|
Per-shard |
|
샤드별 프록시 서비스 |
|
샤드별 TLS 인증서를 사용하는 경우에만 해당합니다. Kubernetes 연산자는 제공하는 TLS 시크릿의 인증서와 키를 샤드별 연산자 managed Secret으로 결합하고 새 이름으로 해당 Secret을 다시 만듭니다.
Resource | 공개 미리보기 이름 | GA 이름 |
|---|---|---|
샤드별 TLS 연산자 조합 Secret |
|
|
제공하는 TLS 시크릿의 이름은 그대로 유지됩니다. 이 연산자가 managed 시크릿만 이름이 변경됩니다. Kubernetes 연산자는 오래된 시크릿를 삭제하지 않으며, 이 시크릿는 오퍰되어 있습니다. 새 시크릿가 존재하고 해당 샤드에 대한 TLS가 작동하는지 확인한 후 오래된 시크릿를 수동으로 삭제합니다.
검증
Kubernetes 연산자를 업그레이드하고 매니페스트 변경 사항을 적용한 후 이 체크리스트를 완료하고 오래된 리소스를 삭제하기 전에 다음 사항을 수행합니다.
kubectl get mongodbsearch <name> -n <namespace> -o yaml에spec.clusters이 채워지고 남아 있는 최상위replicas,persistence,resourceRequirements,statefulSet,loadBalancer,jvmFlags또는prometheus필드가 없는지 확인합니다.단일 클러스터 배포서버의 새
mongotStatefulSet인<name>-search-0에 모든 팝이Running및Ready인지 확인합니다.이전 StatefulSet에서 문서를 삭제하기 전에
mongot이 새 팟에서 인덱싱을 다시 시작했는지 확인합니다. 팟 준비 완료 여부만 확인하지 말고mongot의 로그 또는 인덱스 상태를 확인하여 완료 여부를 확인합니다.Prometheus 스크래핑에 의지하는 경우 스크래핑 구성 또는 대시보드에 새로운 기본값 사용 가능 동작이 반영되어 있는지 확인합니다. 지표가 표시되거나 명시적인
mode: disabled설정이 지표를 비활성화되어 있는지 확인합니다.TLS와 함께
spec.source.external를 사용하는 경우spec.source.external.tls.ca.name에서 참조하는 CAConfigMap이 존재하고 유효한ca.crt키가 포함되어 있는지,mongot의 외부 MongoDB 배포서버에 대한 연결이 정상적인지 확인합니다.복제본 세트 소스의 경우 이전
<name>-search,<name>-search-svc및<name>-search-config객체와 이들의 오퍰 PVC를 찾아 삭제했는지 확인합니다. 샤딩된 소스의 경우 이전 샤드별 TLS 시크릿을 삭제했는지 확인합니다.
지원 받기
업그레이드의 어떤 부분이 이 가이드에 설명된 내용과 일치하지 않거나 이 가이드에서 다루지 않는 문제가 발생하면 MongoDB 지원에 문의하세요. 시크릿이 삭제된 MongoDBSearch 매니페스트, 업그레이드하는 Kubernetes 연산자 버전 및 다음의 출력을 포함하세요.
kubectl describe mongodbsearch <name> -n <namespace>