Un volumen EBS con aprovisionamiento insuficiente provoca largos tiempos de espera de IOPS
Si usaste 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, aumente la relación almacenamiento/IOPS de su volumen EBS. Por ejemplo, si su base de datos tiene 500 GB, aumente las IOPS 1500 a, lo 3 que equivale a una1 relación de: por GB. Para obtener más información sobre cómo aumentar las IOPS, consulte la documentación de AWS.
Nombre de ConfigMap mongodb-kubernetes-operator-member-list está codificado
Cuando ejecuta el complemento kubectl mongodb, como 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 listo después de deshabilitar la autenticación
Nota
Este problema se aplica únicamente a clústeres fragmentados que cumplen los siguientes criterios:
Implementado mediante el operador Kubernetes 1.13.0
Utilizar autenticación X.509
Utilice los secretos kubernetes.io/tls para los certificados TLS para el agente de MongoDB
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, elimine cada Pod en su mongos implementación.
Ejecute el siguiente comando para enumerar todos sus pods:
kubectl get pods
Para cada Pod con un nombre que contenga mongos, elimínelo con el siguiente comando:
kubectl delete pod <podname>
Al eliminar un pod, Kubernetes lo vuelve a crear. Cada pod que Kubernetes vuelve a crear recibe la configuración actualizada y puede alcanzar el READY estado. Para confirmar que todos sus pods mongos son,READY ejecute el siguiente comando:
kubectl get pods -n <metadata.namespace>
Una respuesta como la siguiente indica que todos sus mongos Pods READY son:
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 usar el servicio de webhook, agrega una nueva regla de firewall para otorgar a GKE (Google Kubernetes Engine) acceso al plano de control de tu servicio de webhook.
El servicio webhook del operador de Kubernetes se ejecuta en el puerto 443.
Configurar correctamente el almacenamiento persistente
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, realice una de las siguientes acciones:
Proporcionar volúmenes persistentes o
Establezca
persistent : falsepara el recurso
Solo para pruebas, también puede persistent : false configurar. Esto no debe usarse en producción, ya que los datos no se conservan entre reinicios.
Eliminar recursos antes de eliminar Kubernetes
En ocasiones, Ops Manager puede diferir de Kubernetes. Esto suele ocurrir cuando se eliminan manualmente recursos de Kubernetes. Ops Manager puede seguir mostrando un agente de automatización que se ha cerrado.
Si desea eliminar implementaciones de MongoDB en Kubernetes, use la especificación de recursos para eliminar recursos primero de modo que no queden agentes de automatización inactivos.
Resolución de problemas que puedan ocurrir:
Crear espacios de nombres separados para el operador de Kubernetes y los recursos de MongoDB
La mejor estrategia es crear un operador de Kubernetes y sus recursos en diferentes espacios de nombres para que las siguientes operaciones funcionen correctamente:
kubectl delete pods --all
or
kubectl delete namespace mongodb
Si el operador de Kubernetes y los recursos se encuentran en el mismo mongodb espacio de nombres, el operador también se eliminaría en la misma operación. Esto significaría que no se podrían limpiar las configuraciones, lo cual debería hacerse en la aplicación Ops Manager.
HTTPS habilitado después de la implementación
Le recomendamos que habilite HTTPS antes de implementar sus recursos de Ops Manager. Sin embargo, si lo hace después de la implementación, sus recursos administrados ya no podrán comunicarse con Ops Manager y el operador de Kubernetes informará el estado de sus recursos Failed como.
Para resolver este problema, debes eliminar tus Pods ejecutando el siguiente comando para cada Pod:
kubectl delete pod <replicaset-pod-name>
Tras la eliminación, Kubernetes reinicia automáticamente los pods eliminados. Durante este periodo, el recurso es inaccesible y genera tiempo de inactividad.
No se puede actualizar el agente de MongoDB en los pods de la base de datos de la aplicación
No se puede usar Ops Manager para actualizar los agentes de MongoDB que se ejecutan en los pods de la base de datos de la aplicación. La versión del agente de MongoDB que se ejecuta en estos pods está integrada en la imagen de Docker de la base de datos de la aplicación.
Puede utilizar el operador de Kubernetes para actualizar la versión del agente de MongoDB en los pods de la base de datos de aplicaciones 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 alternativa, actualice la definición del recurso de base de datos de la aplicación Ops Manager en spec.applicationDatabase.podSpec.podTemplate para especificar los nuevos nombres para las imágenes del operador de Kubernetes que contienen los SHA de resumen, de manera 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 la memoria del host (RAM) en lugar del uso de la memoria del contenedor de Kubernetes.
En MacOS, los hosts que utilizan 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: