Migrar o MongoDBSearch do Public Preview para o GA

Antes de começar

O GA força uma versão mongot mínima suportada, 1.70.1. Se o seu recurso MongoDBSearch fixar um spec.version explícito anterior a 1.70.1, a reconciliação falhará após a atualização com um erro de versão não suportada. Se você não definir spec.version, o operador Kubernetes fornecerá seu próprio padrão (1.70.1 a partir desta versão GA) e você não precisará realizar nenhuma ação.

Antes de atualizar, verifique qual versão, se houver, você fixou:

kubectl get mongodbsearch <name> -n <namespace> -o jsonpath='{.spec.version}'

Se o comando imprimir uma versão anterior a 1.70.1, atualize spec.version para 1.70.1 ou posterior como parte das alterações de manifesto na próxima seção.

Atualize sua configuração do MongoDBSearch

Um recurso personalizado do MongoDBSearch de visualização pública nunca teve um campo spec.clusters. No GA, spec.clusters é necessário, e vários campos que costumavam viver no nível superior de spec agora vivem apenas dentro de spec.clusters[0]. Cada manifesto existente precisa da mesma edição mecânica, uma vez, independentemente da topologia.

Os exemplos nesta seção usam um recurso MongoDBSearch chamado my-search no namespace mongodb. Substitua o nome e o namespace do seu próprio recurso.

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"

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"

spec:
  prometheus:
    port: 9946

spec:
  observability:
    prometheus:
      port: 9946

spec:
  observability:
    prometheus:
      mode: disabled

apiVersion: v1
kind: Secret
metadata:
  name: my-search-external-ca
  namespace: mongodb
type: Opaque
stringData:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-search-external-ca
  namespace: mongodb
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

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

kubectl create configmap my-search-external-ca \
  --from-file=ca.crt=./ca.crt \
  --namespace mongodb

O que acontece com seus recursos do Kubernetes

Esta seção aborda o que acontece com os objetos Kubernetes subjacentes que o operador Kubernetes gerencia e o que verificar e limpar depois. O que muda depende se o recurso MongoDBSearch sincroniza de um conjunto de réplicas ou de um cluster sharded.

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

# 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

Verificação

Conclua esta lista de verificação depois de atualizar o operador do Kubernetes e aplicar as alterações do manifesto, e antes de excluir quaisquer recursos antigos:

• Confirme se kubectl get mongodbsearch <name> -n <namespace> -o yaml mostra spec.clusters preenchido e nenhum campo replicas, persistence, resourceRequirements, statefulSet, loadBalancer, jvmFlags ou prometheus de nível superior restante.

• Confirme se o novo StatefulSet mongot, <name>-search-0 para uma implantação de cluster único, tem todos os pods Running e Ready.

• Confirme se mongot concluiu a reindexação nos novos pods antes de excluir qualquer coisa do StatefulSet antigo. Verifique os logs ou o status do índice de mongot para conclusão, não apenas a prontidão do pod.

• Se você depende do scraping do Prometheus, confirme se sua configuração de scraping ou dashboards refletem o novo comportamento habilitado por padrão: as métricas agora aparecem, ou sua configuração explícita de mode: disabled as mantém desabilitadas.

• Se você usar spec.source.external com TLS, confirme se o CA ConfigMap referenciado por spec.source.external.tls.ca.name existe e contém uma chave ca.crt válida e se a conexão de mongot com a implantação externa do MongoDB está íntegra.

• Para fontes de conjunto de réplicas, confirme se você localizou e excluiu os objetos antigos <name>-search, <name>-search-svc e <name>-search-config e seus PVCs órfãos. Para fontes sharded, confirme se você excluiu os segredos TLS antigos por shard.

Obter suporte

Se alguma parte da sua atualização não corresponder ao que este guia descreve, ou se você encontrar um problema que este guia não aborda, entre em contato com o Suporte do MongoDB. Inclua seu manifesto do MongoDBSearch com segredos redigidos, a versão do Kubernetes operador da qual você está atualizando e para qual versão, e a saída de:

kubectl describe mongodbsearch <name> -n <namespace>

Saiba mais

• Compatibilidade e requisitos de pesquisa e pesquisa vetorial
• Atualizar ou Rebaixar
• Especificação do recurso MongoDBSearch
• mongot Perguntas frequentes sobre implantação