Volumen de EBS insuficientemente aprovisionado causa tiempos de espera prolongados para IOPS
Si utilizaste kops para aprovisionar un clúster de Kubernetes en SiAWS y está experimentando un rendimiento deficiente y tiempos de espera de IOPS elevados, es posible que su volumen Elastic Block Store (EBS) no esté aprovisionado lo suficiente.
Para mejorar el rendimiento, incremente la relación almacenamiento/IOPS de su volumen EBS. Por ejemplo, si su base de datos tiene 500 GB, aumente los IOPS a 1500, lo que representa una tasa de 3:1 por GB. Para obtener más información sobre el aumento de IOPS, consulta la documentación de AWS.
Nombre de ConfigMap mongodb-kubernetes-operator-member-list está codificado de forma fija
Cuando ejecutas el plugin kubectl mongodb, por ejemplo durante el
Procedimiento de inicio rápido para clústeres multi-Kubernetes: el complemento crea un ConfigMap predeterminado mongodb-kubernetes-operator-member-list llamado. Este ConfigMap contiene todos los miembros de la implementación de MongoDB en clústeres multi-Kubernetes. No se puede cambiar el nombre del ConfigMap. Para obtener más información sobre las marcas y acciones del complemento, consulte la Referencia del complemento de 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 deshabilita la autenticación spec.security.auth.enabled configurando false en, los Pods nunca alcanzarán mongos un ready estado.
Como solución alternativa, borra cada Pod mongos en tu implementación.
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 vuelve a crear. Cada Pod que Kubernetes recrea recibe la configuración actualizada y puede llegar a un estado READY. Para confirmar que todos sus mongos Pods están READY, ejecute el siguiente comando:
kubectl get pods -n <metadata.namespace>
Una respuesta como la siguiente indica que todos tus Pods mongos están 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
Actualizar las reglas del firewall de Google para solucionar problemas de webhook
Al implementar Kubernetes Operator en clústeres privados de GKE (Google Kubernetes Engine), la MongoDB creación de recursos o de MongoDBOpsManager podría agotar el tiempo de espera. Podría aparecer el siguiente mensaje 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 cuando crea 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 en el mismo mongodb namespace, entonces el operador también se eliminaría 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 habilite HTTPS antes de implementar sus recursos de Ops Manager. Sin embargo, si habilita HTTPS después de la implementación, sus recursos gestionados ya no podrán comunicarse con el Gestor de Operaciones y el Operador de Kubernetes informará del estado de los recursos como Failed.
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 imágenes del operador de Enterprise Kubernetes desde IBM Cloud Paks
Si extrae 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 resumen 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: