El operador de Kubernetes gestiona las implementaciones de Ops Manager utilizando el MongoDBOpsManager
recurso personalizado en cada clúster de Kubernetes donde implementes el recurso. El operador de Kubernetes supervisa la especificación del recurso en busca de cambios. Cuando cambia la especificación, el operador de Kubernetes valida los cambios y realiza las actualizaciones apropiadas en el recurso de cada uno de los clústeres de Kubernetes en los que implemente los componentes de Ops Manager.
MongoDBOpsManager La recurso personalizados especificación define los siguientes componentes de Ops Manager:
La base de datos de la aplicación
La aplicación Ops Manager
El daemon de copias de seguridad
El siguiente diagrama describe los componentes relacionados con la implementación de Ops Manager:
En las implementaciones de un solo clúster, implementas estos componentes en el mismo clúster de Kubernetes donde instalas el Operador de Kubernetes. Este clúster es conocido como el "clúster de operadores".
En implementaciones multiclúster, tú:
Implemente cada componente en diferentes clústeres de Kubernetes, conocidos como "clústeres nodos". También puedes implementar una implementación simplificada de múltiples clústeres con un solo clúster de nodos de Kubernetes. Para aprender más, consulta Modo de clúster único y múltiple.
Instale el Operador de Kubernetes en un clúster de Kubernetes, conocido como "clúster del operador" desde donde el Operador de Kubernetes gestiona todos los demás clústeres miembros. El clúster operador también puede considerarse un clúster nodo ya que también puede alojar los componentes de Ops Manager. Consulta 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 despliega un set de réplicas de MongoDB como un StatefulSet.
Cada Pod para la base de datos de la aplicación tiene los siguientes contenedores:
MongoDB Agent. Para anular la versión del MongoDB Agent, usa la variable de entorno
$AGENT_IMAGEoagent.versionen la gráfica Helm que utilizas 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 supervisión:
Inspecciona
/usr/local/om_version_mapping.jsondentro del Pod del Operador de Kubernetes o la imagen del Operador de Kubernetes.Verifica la imagen del contenedor del agente de supervisión en el Pod donde implementes la base de datos de la aplicación.
En las implementaciones de varios clústeres (cuando se establece spec.applicationDatabase.topology en MultiCluster), el operador de Kubernetes crea el StatefulSet en cada clúster de Kubernetes especificado para la base de datos de la aplicación en spec.applicationDatabase.clusterSpecList.
Las siguientes acciones tienen lugar en cada uno de los clústeres de Kubernetes nodos que alojan nodos del set de réplicas de MongoDB para la base de datos de la aplicación:
Kubernetes crea un Pod en el StatefulSet para cada nodo que compone el set de réplicas de tu base de datos de la aplicación. Cada pod en el StatefulSet ejecuta un
mongody el Agente MongoDB.Para permitir que cada MongoDB Agent inicie
mongoden su pod dentro del StatefulSet, es necesario especificar una versión específica del MongoDB Server para la base de datos de la aplicación utilizando la configuraciónspec.applicationDatabase.version. La versión que especifiques en esta configuración debe corresponder a la etiqueta en el registro del contenedor.Cada MongoDB Agent inicia
mongoden su Pod de base de datos de la aplicación. MongoDB Agent agrega procesosmongodal set de réplicas de la base de datos de la aplicación.Configure la cantidad de réplicas y otras opciones de configuración para el set de réplicas de la base de datos de la aplicación en la colección
spec.applicationDatabasedentro del recurso personalizadoMongoDBOpsManager. El operador de Kubernetes transfiere esta configuración a los agentes de MongoDB mediante un secreto que el operador de Kubernetes monta en cada Pod del StatefulSet de la base de datos de la aplicación.En las implementaciones de base de datos de la aplicación de varios clústeres (donde
spec.applicationDatabase.topologyestá configurado enMultiCluster), se debe especificar el número de nodos en cada clúster miembro por separado para cada clúster miembro enspec.applicationDatabase.clusterSpecList. En implementaciones multiclúster, la configuraciónreplicasenspec.applicationDatabasese ignora.Cada vez que actualice la
spec.applicationDatabasecolección, el Operador de Kubernetes aplica los cambios a la configuración del MongoDB Agent y a la especificación de StatefulSet, si corresponde. Si la especificación del StatefulSet cambia, Kubernetes actualiza los pods de forma progresiva y reinicia cada pod.Para proporcionar conectividad a cada Application Database Pod desde cada clúster de Kubernetes que aloje la base de datos de la aplicación, el operador de Kubernetes crea un servicio sin cabecera. En las implementaciones multi-clúster de la base de datos de la aplicación, el operador de Kubernetes también crea un servicio por Pod denominado
<om_resource_name>-db-N-svc(esto corresponde ametadata.name) y utiliza su FQDN, como<om_resource_name>-db-0.<namespace>.svc.cluster.local, como hostname para conectar a un determinadomongod.Dependiendo del StorageClass o del entorno en el que se implemente el operador Kubernetes, Kubernetes podría crear los volúmenes persistentes utilizando provisión dinámica de volúmenes.
Puedes personalizar las Reclamaciones de volumen persistente para los Pods de base de datos de la aplicación usando
spec.applicationDatabase.podSpec.persistence.singleospec.applicationDatabase.podSpec.persistence.multiple.
Topología de bases de datos de la aplicación
Para elegir un primario, una mayoría de los nodos del set de réplicas de base de datos de la aplicación deben estar disponibles. Si la mayoría de los nodos del set de réplicas fallan, dicho conjunto no podrá formar una mayoría de votación para elegir un nodo primario. Para saber más, consulta Arquitecturas de implementación en set de réplicas.
Si es posible, utiliza una cantidad impar de nodos Kubernetes y distribuye los nodos de su base de datos de la aplicación a través de diferentes centros de datos, zonas o clústeres de Kubernetes. Para obtener más información, consulta Conjuntos de sets de réplicas distribuidos en dos o más centros de datos.
Considera los siguientes ejemplos de la topología de la Base de Datos de la aplicación:
Para una base de datos de la aplicación con cinco nodos, algunas posibles distribuciones de nodos incluyen:
Dos clústeres: tres nodos en
Cluster 1y dos nodos enCluster 2.Si
Cluster 2falla,Cluster 1aloja un número suficiente de miembros del set de réplicas de la base de datos de la aplicación para elegir un nodo primario.Si
Cluster 1falla,Cluster 2no tiene suficientes miembros de la base de datos de la aplicación para elegir un nodo primario.
Tres clústeres: dos nodos a
Cluster 1, dos nodos aCluster 2y un nodo aCluster 3.Si algún clúster individual falla, hay suficientes nodos en los clústeres restantes para elegir un nodo primario.
Si dos clústeres fallan, no hay suficientes nodos en ningún clúster restante para elegir un nodo primario.
Para una base de datos de la aplicación compuesta por siete nodos, considere la siguiente distribución de nodos:
Dos clústeres: cuatro miembros para
Cluster 1y tres miembros paraCluster 2.Si
Cluster 2falla, hay suficientes nodos enCluster 1para elegir un nodo primario.Si
Cluster 1falla, no hay suficientes nodos enCluster 2para elegir un nodo primario.
Si bien Cluster 2 cumple con el mínimo de tres nodos para la base de datos de la aplicación, la mayoría de los siete nodos de la base de datos de la aplicación deben estar disponibles para elegir un nodo primario.
Para obtener más información, consulta Recuperación ante desastres para los recursos de Ops Manager y AppDB.
Aplicación Ops Manager
Después de que la Base de Datos de la Aplicación alcance un estado de En 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 desees implementar, Kubernetes crea un Pod en el StatefulSet.
Cada pod contiene un proceso de la Aplicación Ops Manager.
Para que la implementación de Ops Manager de un solo clúster sea resistente a las fallas de un solo Pod, aumenta el número de réplicas que alojan la aplicación de Ops Manager utilizando spec.replicas.
Para hacer que su implementación de Ops Manager de múltiples clústeres sea resistente a fallas de centros de datos o zonas enteras, despliegue la aplicación de Ops Manager en múltiples clústeres de Kubernetes configurando spec.topology y spec.applicationDatabase.topology en MultiCluster. Consulta también Recuperación ante desastres para recursos de Ops Manager y AppDB.
Daemon de copias de seguridad
Si spec.backup.enabled es true, entonces en cada clúster miembro de Kubernetes, el operador de Kubernetes inicia el daemon de copias de seguridad después de que la aplicación Ops Manager alcance la etapa Running. Para el daemon de copias de seguridad, el operador de Kubernetes implementa un StatefulSet en cada nodo de Kubernetes. En cada clúster miembro, Kubernetes crea tantos pods de daemon de copias de seguridad en el StatefulSet como se especifica en spec.backup.members. En implementaciones de clúster único, estas acciones tienen lugar en el clúster del operador que utilizas para instalar Kubernetes Operator e implementar los componentes de Ops Manager.
Si habilitas la copia de seguridad, configura el oplog store, un almacenamiento en bloques o un S3 almacenamiento de snapshot a nivel global spec.backup, y no para cada clúster nodo de Kubernetes.
También puedes cifrar las tareas de copia de seguridad, pero se aplican limitaciones a las implementaciones en las que la misma instancia del operador de Kubernetes no administra tanto los recursos personalizados MongoDBOpsManager como MongoDB.
Si habilita la copia de seguridad, el Operador de Kubernetes crea un Reclamo de Volumen Persistente para el base de datos principal del daemon de copias de seguridad en cada clúster miembro de Kubernetes. Puedes configurar la base de datos principal utilizando la opción spec.backup.headDB.
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.