El operador de Kubernetes administra las implementaciones de Ops Manager mediante MongoDBOpsManager
Recursopersonalizado en cada clúster de Kubernetes donde se implementa. El operador de Kubernetes supervisa la especificación del recurso para detectar cambios. Cuando la especificación cambia, el operador de Kubernetes valida los cambios y realiza las actualizaciones correspondientes en el recurso en cada clúster de Kubernetes donde se implementan los componentes de Ops Manager.
MongoDBOpsManager La especificación de recursos personalizados define los siguientes componentes de Ops Manager:
La base de datos de la aplicación
La aplicación Ops Manager
El demonio de respaldo
El siguiente diagrama describe los componentes relacionados para una implementación de Ops Manager:
En implementaciones de un solo clúster, estos componentes se implementan en el mismo clúster de Kubernetes donde se instala el operador de Kubernetes. Este clúster se conoce como "clúster del operador".
En implementaciones de múltiples clústeres, usted:
Implemente cada componente en diferentes clústeres de Kubernetes, conocidos como "clústeres miembro". También puede implementar una implementación multiclúster simplificada con un solo clúster de Kubernetes miembro. Para obtener más información, consulte Modo de clúster único y multiclúster.
Instale el operador de Kubernetes en un clúster de Kubernetes, conocido como "clúster del operador", desde donde gestiona todos los demás clústeres miembros. El clúster del operador también puede considerarse un clúster miembro, ya que también puede alojar los componentes de Ops Manager. Consulte el diagrama de arquitectura multiclúster.
Base de datos de la aplicación
Para la base de datos de la aplicación, el operador de Kubernetes implementa un conjunto de réplicas de MongoDB como un StatefulSet.
Cada Pod de la base de datos de la aplicación tiene los siguientes contenedores:
Agente de MongoDB. Para anular la versión del Agente de MongoDB, use la variable de entorno
$AGENT_IMAGEoagent.versionen el diagrama de Helm que utiliza para instalar el Operador de Kubernetes.Agente de supervisión. No puedes anular la versión del agente de supervisión. La versión que utiliza el operador de Kubernetes garantiza la compatibilidad con versiones anteriores con las versiones de Ops Manager.
Para ver la versión del agente de monitoreo:
Inspeccione
/usr/local/om_version_mapping.jsondentro del Pod para el Operador de Kubernetes o la imagen para el Operador de Kubernetes.Verifique la imagen del contenedor del Agente de Monitoreo en el Pod donde implementa la Base de Datos de la Aplicación.
En implementaciones de varios clústeres (cuando se spec.applicationDatabase.topology configura MultiCluster en), el operador de Kubernetes crea el StatefulSet en cada clúster de Kubernetes especificado para la base de datos de la aplicación spec.applicationDatabase.clusterSpecList en.
Las siguientes acciones se llevan a cabo en cada clúster miembro de Kubernetes que aloja nodos del conjunto de réplicas de MongoDB para la base de datos de la aplicación:
Kubernetes crea un pod en el StatefulSet por cada nodo que compone el conjunto de réplicas de la base de datos de la aplicación. Cada pod del StatefulSet ejecuta un
mongody el agente de MongoDB.Para que cada agente de MongoDB inicie
mongoden su pod del StatefulSet, debe especificar una versión específica del servidor MongoDB para la base de datos de la aplicación mediante la configuración. La versión especificada en esta configuración debe corresponder a la etiqueta del registrospec.applicationDatabase.versiondel contenedor.Cada agente de MongoDB
mongodinicia procesos en su pod de base de datos de aplicación. El agente de MongoDB agregamongodprocesos al conjunto de réplicas de la base de datos de aplicación.Configura el número de réplicas y otras opciones de configuración para el conjunto de réplicas de la base de datos de la aplicación
spec.applicationDatabaseen la colección delMongoDBOpsManagerrecurso personalizado. El operador de Kubernetes pasa esta configuración al agente de MongoDB mediante un secreto que monta en cada pod del conjunto de estado de la base de datos de la aplicación.En implementaciones de bases de datos de aplicaciones multiclúster (donde se
spec.applicationDatabase.topologyestableceMultiClusteren), se especifica el número de nodos en cada clúster miembro por separado para cada clúster miembrospec.applicationDatabase.clusterSpecListen. En implementaciones multiclúster,replicasse ignoraspec.applicationDatabaseel valor en.Cada vez que se actualiza la colección, el operador de Kubernetes aplica los cambios a la configuración del agente de MongoDB y a la especificación de StatefulSet, si corresponde. Si la especificación de StatefulSet cambia, Kubernetes actualiza los pods de forma continua y reinicia cada
spec.applicationDatabaseuno.Para proporcionar conectividad a cada pod de la base de datos de aplicaciones desde cada clúster de Kubernetes que la aloja, el operador de Kubernetes crea un servicio sin interfaz gráfica. En implementaciones multiclúster de la base de datos de aplicaciones, el operador de Kubernetes también crea un servicio por pod llamado
<om_resource_name>-db-N-svc(esto corresponde a) y utilizametadata.namesu FQDN,<om_resource_name>-db-0.<namespace>.svc.cluster.localcomo, como nombre de host para conectarse a un enmongodparticular.Según la clase de almacenamiento o el entorno en el que implemente el operador de Kubernetes, Kubernetes podría crear volúmenes persistentes mediante el aprovisionamiento de volúmenes dinámicos.
Puede personalizar las reclamaciones de volumen persistente para los pods de la base de datos de la aplicación utilizando
spec.applicationDatabase.podSpec.persistence.singleo.spec.applicationDatabase.podSpec.persistence.multiple
Topología de la base de datos de la aplicación
Para elegir un nodo principal, la mayoría de los nodos del conjunto de réplicas de la base de datos de la aplicación deben estar disponibles. Si la mayoría de los nodos del conjunto de réplicas fallan, este no podrá formar una mayoría de votos para elegir un nodo principal. Para obtener más información, consulte Arquitecturas de implementación de conjuntos de réplicas.
Si es posible, utilice un número impar de clústeres de Kubernetes miembros y distribuya los nodos de la base de datos de la aplicación entre centros de datos, zonas o clústeres de Kubernetes. Para obtener más información, consulte Conjuntos de réplicas distribuidos en dos o más centros de datos.
Considere los siguientes ejemplos de la topología de la base de datos de la aplicación:
Para una base de datos de aplicaciones de cinco miembros, algunas posibles distribuciones de miembros incluyen:
Dos clústeres: tres miembros para
Cluster 1y dos miembros paraCluster 2.Si
Cluster 2falla,Cluster 1aloja una cantidad suficiente de miembros del conjunto de réplicas de la base de datos de la aplicación para elegir un nodo principal.Si
Cluster 1falla,Cluster 2no tiene suficientes miembros de la base de datos de la aplicación para elegir un nodo principal.
Tres grupos: dos miembros para
Cluster 1, dos miembros paraCluster 2y un miembro paraCluster 3.Si falla un solo clúster, habrá suficientes miembros en los clústeres restantes para elegir un nodo principal.
Si dos clústeres fallan, no habrá suficientes miembros en ningún clúster restante para elegir un nodo principal.
Para una base de datos de aplicaciones de siete miembros, considere la siguiente distribución de miembros:
Dos grupos: cuatro miembros para
Cluster 1y tres miembros paraCluster 2.Si
Cluster 2falla, hay suficientes miembros enCluster 1para elegir un nodo principal.Si
Cluster 1falla, no hay suficientes miembros enCluster 2para elegir un nodo principal.
Aunque Cluster 2 cumple con el mínimo de tres miembros para la base de datos de aplicaciones, la mayoría de los siete miembros de la base de datos de aplicaciones deben estar disponibles para elegir un nodo principal.
Para obtener más información,consulte Recuperación ante desastres para Ops Manager y recursos de AppDB.
Aplicación Ops Manager
Una vez que la base de datos de la aplicación alcanza un estado de ejecución, el operador de Kubernetes comienza a implementar la aplicación Ops Manager:
Configura un StatefulSet en cada clúster de Kubernetes de los nodos.
Para cada conjunto de réplicas de Ops Manager que desee implementar, Kubernetes crea un pod en StatefulSet.
Cada Pod contiene un proceso de aplicación de Ops Manager.
Para que la implementación de Ops Manager en un solo clúster sea resistente a fallas de un solo pod, aumente la cantidad de réplicas que alojan la aplicación Ops Manager spec.replicas mediante.
Para que su implementación multiclúster de Ops Manager sea resistente a fallos en todo el centro de datos o zona, implemente la aplicación Ops Manager en varios clústeres de Kubernetes configurando spec.topology y spec.applicationDatabase.topology MultiClusteren. Consulte también Recuperación ante desastres para recursos de Ops Manager y AppDB.
Daemon de copias de seguridad
Si spec.backup.enabled es verdadero, en cada clúster miembro de Kubernetes, el operador de Kubernetes inicia el demonio de respaldo después de que la aplicación Ops Manager alcance la fase de ejecución. Para el demonio de respaldo, el operador de Kubernetes implementa un StatefulSet en cada clúster miembro de Kubernetes. En cada clúster miembro, Kubernetes crea tantos pods del demonio de respaldo en el StatefulSet como se especifica en. En implementaciones de un solo clúster, estas acciones se realizan en el clúster del operador que se utiliza para instalar el operador de Kubernetes e implementar los componentes de Ops spec.backup.members Manager.
Si habilita la copia de seguridad, configure el almacén de registros de operaciones, un almacén de bloques o un almacén de instantáneas S3en el spec.backup nivel global y no para cada clúster miembro de Kubernetes.
También puede cifrar trabajos de respaldo, pero se aplican limitaciones a las implementaciones donde la misma instancia de operador de Kubernetes no administra tanto MongoDBOpsManager como los recursos personalizados de MongoDB.
Si habilita la copia de seguridad, el operador de Kubernetes crea una reclamación de volumen persistente para la base de datos principal del demonio de copia de seguridad en cada clúster de Kubernetes miembro. Puede configurar la base de datos principal mediante el spec.backup.headDB ajuste.
El Operador de Kubernetes invoca las API de Ops Manager para garantizar que la configuración de copias de seguridad de la aplicación Ops Manager coincida con la que se define en las definiciones de recursos personalizados para cada nodo de Kubernetes.