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
If you disable authentication by setting spec.security.auth.enabled to false, the mongos Pods never reach a ready state.
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>
When you delete a Pod, Kubernetes recreates it. Each Pod that Kubernetes recreates receives the updated configuration and can reach a READY state. To confirm that all of your mongos Pods are READY, run the following command:
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
When you deploy Kubernetes Operator to GKE (Google Kubernetes Engine) private clusters, the MongoDB resources or MongoDBOpsManager resource creation could time out. The following message might appear in the logs: Error setting state to reconciling: Timeout: request did not complete within requested timeout 30s.
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:
Proporcione Volúmenes persistentes o
Establezca
persistent : falsepara el recurso
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.
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.
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: