Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu
Docs Home
/
Gestión
/
Controladores para el Operador de Kubernetes
Docs Home
/
Gestión
/
Controladores para el Operador de Kubernetes
Docs Home
/
Gestión
/
Controladores para el Operador de Kubernetes

Problemas conocidos en los controladores de MongoDB para operador de Kubernetes

Volumen de EBS insuficientemente aprovisionado causa tiempos de espera prolongados para IOPS

Si utilizaste kops para aprovisionar un clúster de Kubernetes en AWS y estás experimentando bajo rendimiento y altos tiempos de espera IOPS, tu volumen de Elastic Block Store (EBS) puede estar bajoaprovisionado.

Para mejorar el rendimiento, aumente la relación almacenamiento-IOPS en su volumen EBS. Por ejemplo, si la base de datos es de 500 GB, aumenta el IOPS a 1500, una relación de 3:1 por GB. Para obtener más información sobre el aumento de IOPS, consulte la documentación de AWS.

El nombre mongodb-kubernetes-operator-member-list de ConfigMap está codificado de forma rígida

Cuando ejecutas el plugin kubectl mongodb, como durante el procedimiento de inicio rápido de clústeres multikubernetes, el plugin crea un ConfigMap por defecto llamado mongodb-kubernetes-operator-member-list. Este ConfigMap contiene todos los integrantes de la implementación MongoDB de clústeres de Kubernetes múltiples. No es posible cambiar el nombre del ConfigMap. Para obtener más información sobre las banderas y acciones del plugin, consulte Referencia del plugin MongoDB.

mongos Las instancias no alcanzan el estado Ready/Fuentes/Fuentes después de desactivar la autenticación

Nota

Este problema solo se aplica a clústeres particionados que cumplan los siguientes criterios:

  • Implementado usando el Operador Kubernetes 1.13.0

  • Utilizar autenticación X.509

  • Utiliza kubernetes.io/tls secretos para certificados TLS para el MongoDB Agent

Si desactiva la autenticación spec.security.auth.enabled estableciendo false en, los Pods nunca alcanzan mongos un ready estado.

As a workaround, delete each mongos Pod in your deployment.

Ejecuta el siguiente comando para listar todos tus Pods:

kubectl get pods

Para cada pod cuyo nombre contenga mongos, bórrelo con el siguiente comando:

kubectl delete pod <podname>

Cuando eliminas un Pod, Kubernetes lo recrea. Cada Pod que Kubernetes recrea recibe la configuración actualizada y puede alcanzar un READY estado. Para confirmar que todos tus Pods están mongos en READY estado, ejecuta el siguiente comando:

kubectl get pods -n <metadata.namespace>

A response like the following indicates that all of your mongos Pods are 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

Actualiza las reglas del firewall de Google para solucionar problemas de WebHook

Cuando implementa Kubernetes Operator en clústeres privados de GKE (Google Kubernetes Engine), la MongoDB creación de los recursos o del recurso MongoDBOpsManager podría agotar el tiempo de espera. El siguiente mensaje podría aparecer en losError setting state to reconciling: Timeout: request did not complete within requested timeout 30s registros:.

Google configura sus firewalls para restringir el acceso a tus Pods de Kubernetes. Para utilizar el servicio de webhook, añade una nueva regla de firewall para conceder a GKE (Google Kubernetes motor) acceso al plano de control a su servicio webhook.

El servicio Webhook del Operador de Kubernetes se ejecuta en el puerto 443.

Configurar el almacenamiento persistente correctamente

Si no hay volúmenes persistentes disponibles al crear un recurso, el Pod resultante permanece en estado transitorio y el Operador falla (después de 20 reintentos) con el siguiente error:

Failed to update Ops Manager automation config: Some agents failed to register

Para evitar este error, haz lo siguiente:

Sólo para pruebas, también puedes establecer persistent : false. Esto no se debe utilizar en producción, ya que los datos no se conservan entre reinicios.

Remover Recursos antes de remover Kubernetes

En ocasiones, Ops Manager puede desviarse de Kubernetes. Esto ocurre principalmente cuando se eliminan recursos de Kubernetes de forma manual. Ops Manager puede seguir mostrando un agente de automatización que ha sido apagado.

Si deseas remover implementaciones de MongoDB en Kubernetes, utiliza la especificación de recursos para borrar recursos primero y así evitar que queden Agentes de Automatización inactivos.

Resolución de problemas que puedan ocurrir:

Crea espacios de nombres separados para el operador de Kubernetes y los recursos de MongoDB

La mejor estrategia es crear el operador de Kubernetes y sus recursos en diferentes namespaces para que las siguientes operaciones funcionen correctamente:

kubectl delete pods --all

or

kubectl delete namespace mongodb

Si el Operador de Kubernetes y los recursos están ubicados en el mismo mongodb namespace, entonces el operador también será eliminado en la misma operación. Esto significaría que no podría limpiar las configuraciones, las cuales tendrían que realizarse en la aplicación Ops Manager.

HTTPS activado después de la implementación

Recomendamos que habilites HTTPS antes de implementar tus recursos de MongoDB Ops Manager. Sin embargo, si habilitas HTTPS después de la implementación, tus recursos gestionados ya no podrán comunicarse con MongoDB Ops Manager y el operador de Kubernetes informará del estado de tus recursos Failed como.

Para resolver este problema, debes borrar tus Pods ejecutando el siguiente comando para cada pod:

kubectl delete pod <replicaset-pod-name>

Después de la eliminación, Kubernetes reinicia automáticamente los Pods eliminados. Durante este período, el recurso es inaccesible e incurre en tiempo de inactividad.

Tip

No se puede actualizar el MongoDB Agent en los pods de la base de datos de la aplicación

No puedes usar Ops Manager para actualizar los MongoDB Agent que se ejecutan en los pods de la base de datos de la aplicación. La versión de MongoDB Agent que se ejecuta en estos Pods está integrada en la imagen Docker de la base de datos de la aplicación.

Puedes usar el Kubernetes operador para actualizar la versión del MongoDB Agent en los Pods de la base de datos de la aplicación a medida que MongoDB publica nuevas imágenes.

Tip

No se pueden extraer las imágenes del operador de Enterprise Kubernetes Operator de IBM Cloud Paks

Si descarga las imágenes del Operador de Kubernetes de un registro de contenedores alojado en IBM Cloud Paks, IBM Cloud Paks cambia los nombres de las imágenes añadiendo un digest SHA a los nombres oficiales de las imágenes. Esta acción genera mensajes de error del Operador de Kubernetes similares a los siguientes:

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

Como solución temporal, actualiza la definición del recurso de Base de datos de la aplicación de Ops Manager en spec.applicationDatabase.podSpec.podTemplate para especificar los nuevos nombres de las imágenes del Operador de Kubernetes que contienen los digest SHAs, de forma similar al siguiente ejemplo.

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'

Memoria de la máquina frente a memoria del contenedor

El agente de automatización en Cloud Manager y Ops Manager informa el uso de memoria del host (RAM) en lugar del uso de memoria del contenedor de Kubernetes.

En MacOS, los hosts que usan Docker Desktop OpsManager no pueden descargar imágenes de bases de datos.

Si ve errores en los registros de OpsManager como:

['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

La siguiente combinación de configuraciones de Docker Desktop puede resolver el problema:

Volver
Solucionar problemas
Califique esta página

En esta página