Migrar MongoDBSearch de la vista previa pública a la disponibilidad general

Antes de comenzar

GA aplica una versión mínima admitida de mongot, 1.70.1. Si su recurso MongoDBSearch fija un spec.version explícito anterior a 1.70.1, la conciliación falla después de la actualización con un error de versión no compatible. Si no establece spec.version, el operador de Kubernetes proporciona su propio valor por defecto (1.70.1 a partir de esta versión GA) y no necesita realizar ninguna acción.

Antes de actualizar, compruebe qué versión, si la hay, ha anclado:

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

Si el comando imprime una versión anterior a 1.70.1, actualice spec.version a 1.70.1 o posterior como parte de los cambios de manifiesto en la siguiente sección.

Actualizar la configuración de MongoDBSearch

Un recurso personalizado de MongoDBSearch de vista previa pública nunca tuvo un campo spec.clusters. En GA, se requiere spec.clusters, y varios campos que solían estar en el nivel superior de spec ahora solo están dentro de spec.clusters[0]. Cada manifiesto existente necesita la misma edición mecánica, una vez, independientemente de la topología.

Los ejemplos de esta sección utilizan un recurso de MongoDBSearch llamado my-search en el namespace mongodb. Sustituye el nombre y el namespace de tu propio 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

Qué sucede con sus recursos de Kubernetes

Esta sección cubre lo que sucede con los objetos de Kubernetes subyacentes que gestiona el operador de Kubernetes y lo que se debe verificar y limpiar después. Lo que cambia depende de si el recurso de MongoDB Search se sincroniza desde un set de réplicas o un clúster particionado.

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

verificación

Complete esta lista de comprobación después de actualizar el operador de Kubernetes y aplicar los cambios de manifiesto, y antes de borrar los recursos antiguos:

• Confirme que kubectl get mongodbsearch <name> -n <namespace> -o yaml muestra spec.clusters rellenado y que no quedan campos replicas, persistence, resourceRequirements, statefulSet, loadBalancer, jvmFlags o prometheus de nivel superior.

• Confirme que el nuevo mongot StatefulSet, <name>-search-0 para una implementación de clúster único, tiene todos los pods Running y Ready.

• Confirma que mongot ha terminado de reindexar en los nuevos pods antes de borrar nada del StatefulSet antiguo. Comprueba los registros o el estado del índice de mongot para confirmar su finalización, no solo la disponibilidad del pod.

• Si confía en el scraping de Prometheus, confirme que su configuración de scraping o sus tableros reflejan el nuevo comportamiento habilitado por defecto: o bien las métricas aparecen ahora, o su configuración explícita mode: disabled las mantiene deshabilitadas.

• Si utiliza spec.source.external con TLS, confirme que la CA ConfigMap a la que hace referencia spec.source.external.tls.ca.name existe y contiene una clave ca.crt válida, y que la conexión de mongot con la implementación externa de MongoDB es correcta.

• Para las fuentes del set de réplicas, confirme que ha localizado y borrado los objetos <name>-search, <name>-search-svc y <name>-search-config antiguos y sus PVC huérfanos. Para las fuentes particionadas, confirme que ha borrado los secretos TLS antiguos por partición.

Obtener soporte

Si alguna parte de tu actualización no coincide con lo que describe esta guía, o encuentras un problema que esta guía no cubre, ponte en contacto con Soporte de MongoDB. Incluye tu manifiesto de MongoDBSearch con los secretos omitidos, la versión del operador de Kubernetes desde la que estás actualizando y hacia la que vas a actualizar, y el resultado de:

kubectl describe mongodbsearch <name> -n <namespace>

Obtén más información

• Compatibilidad y requisitos de búsqueda y búsqueda vectorial
• Actualizar o degradar
• Especificación de recursos de MongoDBSearch
• mongot Preguntas frecuentes sobre la implementación