Redes, balanceo de carga, malha de servicios

Descripción general de redes

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 de Ops Manager después de conectarse

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

Malla de servicio

Agregue los nodos que alojan las instancias de la base de datos de la aplicación y las instancias de la aplicación de 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 el operador de Kubernetes y las instancias de Ops Manager, recomendamos que añadas el clúster del operador, que es el clúster de Kubernetes donde instalas el operador de Kubernetes, a la misma malla de servicios, aunque no es un requisito estricto. Si incluye el clúster de operadores en la misma malla de servicios, podrá usarlo como host para la aplicación Ops Manager y las instancias de 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 operador" en el que despliega el propio Operador de Kubernetes.

• Los “nodos Kubernetes clústeres” que alojarán las instancias de la aplicación Ops Manager.

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

Contar con la misma malla de servicios 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 base de datos de la aplicación implementadas en múltiples clústeres de Kubernetes.

Después de implementar las instancias de la Base de Datos de la Aplicación en los clústeres nodo de Kubernetes, el endpoint API de cada instancia de Ops Manager que se implemente en los clústeres nodo de Kubernetes debe ser capaz de conectarse directamente a cada una de las instancias de la Base de Datos de la Aplicación. Esto permite que el Kubernetes operador complete las etapas necesarias para implementar instancias de Ops Manager en los clústeres nodos, como crear usuarios administradores y configurar copias de seguridad.

Equilibrio de carga

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

Para implementaciones multi-clúster de la Aplicación Ops Manager, cada clúster puede exponer sus Pods que alojan la Aplicación Ops Manager individualmente utilizando un servicio del tipo LoadBalancer .

Crear un servicio de LoadBalancer usando spec.externalConnectivity y redirige 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 de Kubernetes envía el tráfico de manera rotativa a todos los Pods disponibles que alojan la aplicación Ops Manager.

Dado que el operador de Kubernetes no admite el balanceo de carga del tráfico a todos los pods en todos los clústeres de Kubernetes, debes configurar el balanceo 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 se puede configurar el balanceo de carga en varios clústeres de Kubernetes.

• Ejemplo de diagrama 1: Balanceador de carga externo

• Ejemplo de diagrama 2: Balanceo de carga por un malla de servicios, con un proxy

Ejemplo de diagrama 1: Balanceador de carga externo

Configura un balanceador de carga de red externo (un proxy passthrough) 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 es sin estado. El equilibrador de carga puede reenviar el tráfico al servicio LoadBalancer de cada clúster de forma rotativa, o a un clúster a la vez, si configuras el equilibrador de carga de tal manera que, mientras un clúster está activo, el otro clúster está pasivo. El siguiente diagrama ilustra este enfoque.

haga clic para ampliar

En este diagrama:

1. El operador de Kubernetes crea un servicio externo de tipo LoadBalancer, denominado <om_resource_name>-svc-ext, con una dirección IP externa asignada, en cada clúster nodo. Puedes configurar este servicio globalmente para todos los clústeres nodo utilizando spec.externalConnectivity. O, si este servicio es específico para cada clúster nodo, puedes configurarlo usando spec.clusterSpecList.externalConnectivity.

   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.

Ejemplo de diagrama 2: Balanceo de carga por un malla de servicios, con un proxy

Utiliza las capacidades de balanceo de carga entre clústeres que proporciona un malla de servicios.

En cada clúster de Kubernetes, el Kubernetes Operator crea un servicio, llamado <om_resource_name>-svc, que puedes usar para distribuir el tráfico a todos los Pods disponibles que hospedan las instancias de la aplicación Ops Manager en todos los clústeres nodo.

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

El siguiente diagrama ilustra este enfoque.

haga clic para ampliar

En este diagrama:

1. En cada clúster nodo, el Operador de Kubernetes crea un servicio de tipo ClusterIP al que se puede acceder utilizando <om_resource_name>-svc.<namespace>.svc.cluster.local. Es un servicio que contiene en sus endpoints todos los Pods implementados en este clúster nodo.

2. El tráfico entre clústeres de Kubernetes es gestionado por el service mesh. Cuando el Operador de Kubernetes crea servicios en cada clúster nodo para la Aplicación Ops Manager, el Operador de Kubernetes no asigna un sufijo de índice de clúster a los nombres de estos servicios. Por lo tanto, el service mesh puede realizar el equilibrio de carga de tráfico en todos los Pods que hospeden la aplicación Ops Manager en todos los clústeres.

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

4. Aunque cada clúster tiene desplegado un servicio <om_resource_name>-svc ClusterIP, este servicio no gestiona el tráfico de usuarios. Cuando el usuario accede al servicio en Member Cluster 1, el service mesh gestiona el tráfico.

5. Cada pod que hospeda la aplicación Ops Manager lleva 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.