Docs Menu
Docs Home
/ /

Redes, equilibrio de carga, malla de servicios

Tenga en cuenta los siguientes requisitos adicionales al implementar la aplicación Ops Manager en varios clústeres de Kubernetes:

La siguiente tabla describe:

  • Orígenes de conexiones a las instancias de la aplicación de Ops Manager

  • Las tareas que realiza la aplicación Ops Manager después de conectarse

  • La URL de Ops Manager que utiliza cada tipo de conexión y cómo configurarla.

Origen de la conexión
Propósito o acción
URL al Administrador de operaciones

El operador de Kubernetes

Configura la instancia de Ops Manager y habilita la supervisión después de que la base de datos de la aplicación esté en estado de ejecución

A través de un administrador de operaciones predeterminado FQDN en el formato: <om_resource_name>-svc.<namespace>.svc.cluster.local o el valor de spec.opsManagerURL

El operador de Kubernetes

Configura un recurso MongoDB específico o una implementación de recurso MongoDBMultiCluster

A través del ConfigMap del proyecto, configurado al crear un proyecto

Agente de MongoDB en los pods de la base de datos de la aplicación

Recibe la configuración de Automatización

Sin necesidad de conectarse a una instancia de Ops Manager, el agente de MongoDB se ejecuta en modo sin interfaz gráfica.

Agente de supervisión en los pods de la base de datos de la aplicación

Envía datos de monitoreo

A través de un FQDN de Ops Manager predeterminado en el formato: <om_resource_name>-svc.<namespace>.svc.cluster.local o el valor de spec.opsManagerURL

Agente de MongoDB en los pods de recursos MongoDB o MongoDBMultiCluster

Recibe los procesos de configuración, backup y restauración de Automatización

A través del ConfigMap del proyecto, configurado al crear un proyecto

Agente de monitoreo en los pods de recursos MongoDB o MongoDBMultiCluster

Envía datos de monitoreo

A través del ConfigMap del proyecto, configurado al crear un proyecto

Usuario

Utiliza la interfaz de usuario o API de Ops Manager

A través de un dominio público externo de la instancia de Ops Manager expuesta externamente, configurada con spec.externalConnectivity

Agregue los nodos que alojan las instancias de la base de datos de la aplicación y las instancias de la aplicación Ops Manager a la misma malla de servicio para permitir lo siguiente:

  • Conectividad de red entre componentes implementados.

  • Resolución DNS entre clústeres.

Para simplificar la configuración de red entre las instancias de Kubernetes Operator y Ops Manager, recomendamos agregar el clúster de operadores (el clúster de Kubernetes donde se instala Kubernetes Operator) a la misma malla de servicios, aunque no es un requisito obligatorio. Si incluye el clúster de operadores en la misma malla de servicios, podrá usarlo como host para las instancias de la aplicación Ops Manager y la base de datos de la aplicación.

Configure una malla de servicios para los siguientes clústeres de Kubernetes e inclúyalos en la configuración de la malla:

  • El "clúster de operadores" en el que se implementa el propio operador de Kubernetes.

  • Los "clústeres de Kubernetes miembro" que alojarán las instancias de la aplicación Ops Manager.

  • Clústeres de miembros adicionales de Kubernetes, o los mismos clústeres de miembros utilizados para Ops Manager, que alojarán las instancias de la base de datos de la aplicación.

Tener la misma malla de servicio configurada para todos los clústeres de Kubernetes garantiza que cada instancia de Ops Manager pueda establecer una conexión segura con cualquiera de las instancias de la base de datos de aplicaciones implementadas en varios clústeres de Kubernetes.

Después de implementar las instancias de la base de datos de la aplicación en los clústeres de Kubernetes miembros, el punto final de la API de cada instancia de Ops Manager que implemente en los clústeres de Kubernetes miembros debe poder conectarse directamente a cada una de las instancias de la base de datos de la aplicación. Esto permite al operador de Kubernetes completar las etapas necesarias para implementar las instancias de Ops Manager en los clústeres miembros, como la creación de usuarios administradores y la configuración de copias de seguridad.

En la mayoría de los casos, debe proporcionar un acceso externo a la aplicación Ops Manager para permitir el acceso del usuario a la interfaz de usuario de Ops Manager.

Para implementaciones de múltiples clústeres de la aplicación Ops Manager, cada clúster puede exponer sus pods que alojan la aplicación Ops Manager individualmente mediante un servicio de LoadBalancertipo.

Cree un LoadBalancer servicio con spec.externalConnectivity y apunte un dominio externo a la dirección IP externa de ese servicio. Incluso si configura más de una instancia de la aplicación Ops Manager, el servicio Kubernetes envía tráfico de forma rotatoria a todos los pods disponibles que alojan la aplicación Ops Manager.

Dado que el operador de Kubernetes no admite el equilibrio de carga del tráfico a todos los pods en todos los clústeres de Kubernetes, debe configurar el equilibrio de carga fuera de la configuración del operador de Kubernetes.

Los siguientes ejemplos y diagramas ilustran algunas de las muchas formas en las que puede configurar el equilibrio de carga en múltiples clústeres de Kubernetes.

Configure un balanceador de carga de red externo (un proxy de paso) para todos los clústeres de Kubernetes que alojan la aplicación Ops Manager y la base de datos de la aplicación. La aplicación Ops Manager no tiene estado. El balanceador de carga puede reenviar tráfico al servicio LoadBalancer de cada clúster mediante un sistema de reenvío por turnos, o a un clúster a la vez, si se configura de forma que, mientras un clúster esté activo, el otro esté pasivo. El siguiente diagrama ilustra este enfoque.

Diagrama que muestra el ejemplo de red de alto nivel de la implementación de la aplicación Ops Manager en múltiples clústeres de Kubernetes donde el tráfico se distribuye mediante un balanceador de carga externo.
haga clic para ampliar

En este diagrama:

  1. El operador de Kubernetes crea un servicio externo de tipo,LoadBalancer <om_resource_name>-svc-extllamado, con una dirección IP externa asignada en cada clúster miembro. Puede configurar este servicio globalmente para todos los clústeres miembro mediante. O bien, si este servicio es específico para cada clúster miembro, puede spec.externalConnectivity configurarlo spec.clusterSpecList.externalConnectivity mediante.

    Cada servicio que el operador de Kubernetes crea para la aplicación Ops Manager siempre contiene todos los pods que alojan la aplicación Ops Manager del clúster actual.

Utilice las capacidades de equilibrio de carga entre clústeres proporcionadas por una malla de servicios.

En cada clúster de Kubernetes, el operador de Kubernetes crea un servicio, <om_resource_name>-svcllamado, que puede usar para distribuir el tráfico entre todos los pods disponibles que alojan las instancias de la aplicación Ops Manager en todos los clústeres miembros.

Puede implementar un componente proxy, como Nginx o HAProxy, en uno de los clústeres, exponerlo externamente a través de Internet mediante su FQDN público y configurar el proxy para reenviar todo el tráfico de red a través del paso a través de TCP al servicio <om_resource_name>-svc.<namespace>.svc.cluster.local denominado.

El siguiente diagrama ilustra este enfoque.

Diagrama que muestra el ejemplo de red de alto nivel de la implementación de la aplicación Ops Manager en múltiples clústeres de Kubernetes donde el tráfico se distribuye mediante un balanceador de carga dentro de una malla de servicios y se utiliza un servicio proxy.
haga clic para ampliar

En este diagrama:

  1. En cada clúster miembro, el operador de Kubernetes crea un servicio de tipo al ClusterIP que se puede acceder <om_resource_name>-svc.<namespace>.svc.cluster.local mediante. Este servicio contiene en sus puntos finales todos los pods implementados en este clúster miembro.

  2. El tráfico entre clústeres de Kubernetes se gestiona mediante la malla de servicios. Cuando el operador de Kubernetes crea servicios en cada clúster miembro para la aplicación Ops Manager, no asigna un sufijo de índice de clúster a los nombres de estos servicios. Por lo tanto, la malla de servicios puede equilibrar la carga de tráfico en todos los pods que alojan la aplicación Ops Manager en todos los clústeres.

  3. En cada clúster miembro, el operador de Kubernetes implementa un StatefulSet llamado <om_resource_name>-<cluster-index>. Por ejemplo, om-0 es el nombre del StatefulSet del clúster miembro con el índice 0.

  4. Aunque cada clúster tiene implementado un servicio <om_resource_name>-svc ClusterIP, este no gestiona el tráfico del usuario. Cuando el usuario accede al servicio en Member Cluster 1, la malla de servicios gestiona el tráfico.

  5. Cada pod que aloja la aplicación Ops Manager recibe el nombre de su StatefulSet. Por ejemplo, om-1-2 es el nombre del pod número 2 en el clúster con el índice 1.

Volver

Diagrama

En esta página