El operador de Kubernetes gestiona las implementaciones de Ops Manager utilizando el 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 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 para una 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 multiclúster.
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 de 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 monitoreo:
Inspecciona
/usr/local/om_version_mapping.jsondentro del Pod del Operador de Kubernetes o la imagen del 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 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 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 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.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 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 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 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,<om_resource_name>-db-0.<namespace>.svc.cluster.localcomo, como nombre de host para conectarse a un enmongodparticular.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 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 clústeres: 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 nodos enCluster 2para elegir un nodo primario.
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 desees implementar, Kubernetes crea un Pod en el StatefulSet.
Cada Pod contiene un proceso de aplicación de 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 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 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 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.