Creación de un clúster de Kubernetes de alta disponibilidad en Azure Stack Hub

En este artículo, se describe cómo diseñar y operar una infraestructura de alta disponibilidad basada en Kubernetes con el motor de Azure Kubernetes Service (AKS) en Azure Stack Hub. La solución se basa en un escenario que tiene un conjunto estricto de restricciones. La aplicación se debe ejecutar en el entorno local y no debe llegar ningún dato personal a los servicios en la nube pública. Los datos de supervisión y aquellos otros que no constituyan información de identificación personal se pueden enviar a Azure para su procesamiento. Se puede acceder a servicios externos, como un registro de contenedor público, pero se pueden filtrar mediante un servidor proxy o un firewall.

Helm y Let's Encrypt son marcas comerciales de sus respectivas empresas. El uso de estas marcas no implica ninguna aprobación.

Architecture

Descargue un archivo de Visio de todos los diagramas de este artículo.

Flujo de trabajo

En el diagrama anterior, se muestra la arquitectura de la aplicación de ejemplo que se ejecuta en Kubernetes en Azure Stack Hub. La aplicación consta de estos componentes:

1. Un clúster de Kubernetes, basado en el motor de AKS, en Azure Stack Hub.
2. cert-manager, que proporciona un conjunto de herramientas para la administración de certificados en Kubernetes. Se usa para solicitar automáticamente certificados de Let's Encrypt.
3. Un espacio de nombres de Kubernetes que contiene los componentes de la aplicación para lo siguiente:
   1. el front-end (ratings-web)
   2. la API (ratings-api)
   3. la base de datos (ratings-mongodb)
4. Un controlador de entrada que enruta el tráfico HTTP/HTTPS a los puntos de conexión del clúster de Kubernetes.

Se usa la aplicación de ejemplo para mostrar la arquitectura de la aplicación. Todos los componentes son ejemplos. La arquitectura contiene solo la implementación de una única aplicación. Para lograr la alta disponibilidad, la implementación se ejecuta al menos dos veces en dos instancias de Azure Stack Hub. Se pueden ejecutar en una sola ubicación o en dos o más sitios:

Los servicios como Azure Container Registry y Azure Monitor se hospedan fuera de Azure Stack Hub en Azure o en el entorno local. Este diseño híbrido protege a la solución frente a la interrupción de una sola instancia de Azure Stack Hub.

Componentes

• Azure Stack Hub es una extensión de Azure que puede ejecutar cargas de trabajo en un entorno local y proporcionar servicios de Azure en su centro de datos.
• AKS Engine for Azure Stack proporciona una herramienta de línea de comandos para ayudar a aprovisionar un clúster de Kubernetes autoadministrado en Azure Stack Hub. Utiliza Azure Resource Manager para crear, destruir y mantener clústeres aprovisionados con recursos IaaS básicos en Azure Stack Hub.
• Virtual Network proporciona la infraestructura de red en cada instancia de Azure Stack Hub para las máquinas virtuales que hospedan la infraestructura del clúster de Kubernetes.
• Azure Load Balancer se usa para el punto de conexión de API de Kubernetes y el controlador de entrada Nginx. El equilibrador de carga enruta el tráfico externo (por ejemplo, Internet) hacia los nodos y las máquinas virtuales que proporcionan un servicio específico.
• Container Registry se usa para almacenar imágenes privadas de Docker y gráficos de Helm, que están implementados en el clúster. El motor de AKS se puede autenticar con Container Registry mediante una identidad de Microsoft Entra. Kubernetes no requiere Container Registry. Puede usar otros registros de contenedor, como Docker Hub.
• Azure Repos es un conjunto de herramientas de control de versiones que se puede usar para administrar el código. También puede usar GitHub u otros repositorios basados en Git.
• Azure Pipelines forma parte de Azure DevOps Services. Ejecuta compilaciones, pruebas e implementaciones automatizadas. También puede usar soluciones de CI/CD de terceros, como Jenkins.
• Azure Monitor recopila y almacena métricas y registros, como las métricas de la plataforma de los servicios de Azure de la solución y los datos de telemetría de la aplicación. Use estos datos para supervisar la aplicación, configurar alertas y paneles y realizar el análisis de causa principal de los errores. Azure Monitor se integra con Kubernetes para recopilar métricas de controladores, nodos, contenedores, registros de contenedor y registros de nodos del plano de control.
• Azure Traffic Manager es un equilibrador de carga de tráfico basado en DNS que puede usar para distribuir el tráfico de forma óptima a servicios de otras regiones de Azure o implementaciones de Azure Stack Hub. Traffic Manager también proporciona alta disponibilidad y capacidad de respuesta. Los puntos finales de la aplicación deben ser accesibles desde el exterior para ser añadidos como puntos finales a Azure Traffic Manager.
• El controlador de entrada de Kubernetes expone rutas HTTP(S) a los servicios de un clúster de Kubernetes. Puede usar NGINX o cualquier controlador de entrada adecuado.
• Helm es un administrador de paquetes para la implementación de Kubernetes. Proporciona una manera de agrupar diferentes objetos de Kubernetes, como Deployments, Services y Secrets, en un único "gráfico". Puede publicar, implementar, crear versiones y actualizar un objeto de gráfico. Puede usar Container Registry como repositorio para almacenar gráficos de Helm empaquetados.

Alternativas

Azure Traffic Manager es una de las opciones para distribuir el tráfico entre dos puntos finales accesibles desde Internet. También podrían utilizarse otras soluciones de equilibrio de carga para distribuir el tráfico entre las instancias de Azure Stack Hub. Puede haber situaciones en las que los puntos finales de la aplicación alojados en Azure Stack Hub deban restringirse únicamente a su red privada. En estos casos, pueden utilizarse Load Balancers de terceros para equilibrar la carga de tráfico entre las instancias de Azure Stack Hub de su red, tanto si están ubicadas en el mismo centro de datos como si están desplegadas en varios centros de datos.

Detalles del escenario

La aplicación de ejemplo que se muestra aquí está diseñada para usar soluciones nativas de Kubernetes en lugar de servicios nativos de la plataforma siempre que sea posible. Este diseño evita la dependencia del proveedor. Por ejemplo, la aplicación usa un back-end de base de datos de MongoDB autohospedado en lugar de un servicio PaaS o un servicio externo de bases de datos. Para más información, consulte la ruta de aprendizaje Introducción a Kubernetes en Azure.

Posibles casos de uso

Muchas organizaciones desarrollan soluciones nativas de nube que aprovechan las ventajas de los servicios y las tecnologías de vanguardia como Kubernetes. Aunque Azure proporciona centros de datos en la mayoría de las regiones del mundo, a veces las aplicaciones críticas para la empresa se deben ejecutar en una ubicación específica. Entre las posibles preocupaciones, se incluyen:

• Sensibilidad respecto a la ubicación.
• Latencia entre la aplicación y los sistemas locales.
• Conservación del ancho de banda.
• Conectividad.
• Requisitos normativos o legales.

Azure, en combinación con Azure Stack Hub, aborda la mayoría de estos problemas. Este artículo proporciona un amplio conjunto de opciones, decisiones y consideraciones que le ayudarán a diseñar con éxito soluciones basadas en Kubernetes de alta disponibilidad en Azure Stack Hub.

El escenario que se describe aquí es común para las organizaciones con cargas de trabajo críticas de entornos muy regulados y restringidos. Es aplicable en dominios como finanzas, defensa y gubernamental.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Diseño

Esta solución incorpora algunas recomendaciones generales que se explican con más detalle en las siguientes secciones de este artículo:

• La aplicación usa soluciones nativas de Kubernetes para evitar la dependencia del proveedor.
• La aplicación usa una arquitectura de microservicios.
• Azure Stack Hub no necesita conectividad de Internet de entrada. Permite la conectividad de salida a Internet.

Estos procedimientos recomendados son aplicables también a cargas de trabajo y escenarios reales.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

La escalabilidad ayuda a proporcionar acceso uniforme, confiable y con un buen rendimiento a la aplicación.

El escenario de ejemplo implementa la escalabilidad en tres capas de la pila de aplicaciones. A continuación, se muestra información general de las capas:

Nivel de arquitectura	Afecta a	¿Cómo lo hago?
Application	Application	Escalado horizontal basado en el número de pods, réplicas o instancias de contenedor.*
Clúster	Clúster de Kubernetes	Número de nodos (entre 1 y 50), tamaños de SKU de máquina virtual y, mediante el comando scale manual del motor de AKS, grupos de nodos.
Infraestructura	Azure Stack Hub	Número de nodos, capacidad y unidades de escalado en una implementación de Azure Stack Hub.

* Mediante Horizontal Pod Autoscaler de Kubernetes, que proporciona escalado automático basado en métricas o escalado vertical mediante el dimensionamiento de las instancias de contenedor (CPU o memoria).

Azure Stack Hub (nivel de infraestructura)

Dado que Azure Stack Hub se ejecuta en hardware físico en un centro de datos, la infraestructura de Azure Stack Hub es la base de esta implementación. Al seleccionar el hardware para la instancia de Azure Stack Hub, debe elegir la CPU, la densidad de memoria, la configuración de almacenamiento y el número de servidores. Para obtener más información sobre la escalabilidad de Azure Stack Hub, consulte estos recursos:

• Introducción al planeamiento de capacidad de Azure Stack Hub
• Incorporación de nodos de la unidad de escalado en Azure Stack Hub

Clúster de Kubernetes (nivel de clúster)

El propio clúster de Kubernetes consta de componentes de IaaS de Azure and Azure Stack Hub y se basa en ellos, incluidos los recursos de proceso, almacenamiento y red. Las soluciones de Kubernetes se componen de nodos del plano de control y nodos de trabajo, que se implementan como máquinas virtuales en Azure y Azure Stack Hub.

• Los nodos del plano de control proporcionan los servicios básicos de Kubernetes y la orquestación de las cargas de trabajo de las aplicaciones.
• Los nodos de trabajo ejecutan las cargas de trabajo de las aplicaciones.

Al elegir tamaños de máquina virtual para la implementación inicial, tenga en cuenta lo siguiente:

• El costo. Al planear los nodos de trabajo, tenga en cuenta el costo total por máquina virtual. Por ejemplo, si las cargas de trabajo de las aplicaciones requieren recursos limitados, debe planear la implementación de máquinas virtuales de menor tamaño. Azure Stack Hub, al igual que Azure, se factura normalmente por consumo, por lo que el ajuste adecuado del tamaño de las máquinas virtuales para los roles de Kubernetes es fundamental para optimizar los costos de consumo.

• Escalabilidad. Puede lograr la escalabilidad del clúster mediante el escalado y la reducción horizontal del número de nodos de trabajo y del plano de control, o mediante la adición de grupos de nodos. (Actualmente, no se pueden agregar grupos de nodos en Azure Stack Hub). Puede escalar el clúster en función de los datos de rendimiento recopilados con Container Insights (Azure Monitor y Log Analytics).

  Si la aplicación necesita más o menos recursos, puede escalar o reducir horizontalmente el número de nodos, entre 1 y 50 nodos. Si necesita más de 50 nodos, puede crear otro clúster en una suscripción independiente. No se pueden escalar verticalmente las máquinas virtuales reales a otro tamaño de máquina virtual sin volver a implementar el clúster.

  Implemente el escalado manualmente mediante la máquina virtual auxiliar del motor de AKS que usó para implementar el clúster de Kubernetes. Para más información, consulte Escalado de clústeres de Kubernetes.

• Cuotas. Tenga en cuenta las cuotas que ha configurado al planear una implementación de AKS en Azure Stack Hub. Asegúrese de que cada suscripción tenga las cuotas y los planes adecuados configurados. La suscripción deberá acomodar la cantidad de proceso, almacenamiento y otros servicios necesarios para los clústeres a medida que estos se escalan horizontalmente.

• Cargas de trabajo de las aplicaciones. Consulte los conceptos de clústeres y cargas de trabajo en el artículo Conceptos básicos de Kubernetes de Azure Kubernetes Service (AKS). Este artículo puede ayudarle a definir el ámbito del tamaño de máquina virtual en función de las necesidades de proceso y memoria de la aplicación.

Aplicación (nivel de aplicación)

En la capa de aplicación, la solución usa Horizontal Pod Autoscaler de Kubernetes. Horizontal Pod Autoscaler puede aumentar o disminuir el número de réplicas (pods o instancias de contenedor) de la implementación en función de varias métricas, como el uso de CPU.

Otra opción consiste en escalar las instancias de contenedor verticalmente. Puede realizar este tipo de escalado cambiando la cantidad de CPU y memoria que se solicita y está disponible para una implementación específica. Para obtener más información, consulte Administración de recursos para contenedores.

Redes y conectividad

Las redes y la conectividad también afectan a las tres capas descritas anteriormente. En la tabla siguiente, se muestran las capas y los servicios que contienen.

Nivel	Afecta a	¿Qué?
Application	Application	Cómo se puede acceder a la aplicación. Si se va a exponer a Internet.
Clúster	Clúster de Kubernetes	API de Kubernetes, máquina virtual del motor de AKS, extracción de imágenes de contenedor (salida), envío de datos de supervisión y de telemetría (salida).
Infraestructura	Azure Stack Hub	Accesibilidad de los puntos de conexión de administración de Azure Stack Hub, como los del portal y los de Azure Resource Manager.

Application

En la capa de aplicación, la consideración más importante es si la aplicación se expone a Internet y se puede acceder a ella desde Internet. Desde la perspectiva de Kubernetes, el acceso de Internet requiere exponer una implementación o un pod mediante un servicio de Kubernetes o un controlador de entrada.

Una aplicación se puede exponer con una dirección IP pública mediante un equilibrador de carga o un controlador de entrada sin ser accesible mediante Internet. Azure Stack Hub puede tener una dirección IP pública visible solo en la intranet local. No todas las direcciones IP públicas son verdaderamente accesibles desde Internet.

Además del tráfico de entrada a la aplicación, también debe tener en cuenta el tráfico saliente o de salida. Estos son algunos casos de uso que requieren tráfico de salida:

• Extracción de imágenes de contenedor almacenadas en Docker Hub o Container Registry
• Recuperación de gráficos de Helm
• Emisión de datos de Application Insights u otros datos de supervisión
• Conectar a aplicaciones externas

Algunos entornos empresariales pueden requerir el uso de servidores proxy transparentes o no transparentes. Estos servidores requieren una configuración específica en varios componentes del clúster. La documentación del motor de AKS contiene los detalles sobre cómo acomodar los servidores proxy de red. Para más información, consulte Motor de AKS y servidores proxy.

Por último, debe fluir el tráfico entre clústeres entre las instancias de Azure Stack Hub. La solución que se describe aquí consta de clústeres de Kubernetes individuales que se ejecutan en instancias individuales de Azure Stack Hub. El tráfico entre ellas, al igual que el tráfico de replicación entre dos bases de datos, se considera tráfico externo. El tráfico externo se debe enrutar mediante una VPN de sitio a sitio o direcciones IP públicas de Azure Stack Hub. Vpn de sitio a sitio ofrece más seguridad para las transferencias de datos y es preferible.

Clúster

No es necesario que el clúster de Kubernetes sea accesible mediante Internet. La parte importante es la API de Kubernetes que se usa para operar un clúster, por ejemplo, mediante kubectl. Todos los usuarios que operan el clúster o implementan aplicaciones y servicios sobre él deben poder acceder al punto de conexión de la API de Kubernetes. Este tema se trata con más detalle desde la perspectiva de DevOps en la sección Implementación (CI/CD) de este artículo.

En el nivel de clúster, existen también algunas consideraciones para el tráfico de salida:

• Actualizaciones de nodos (para Ubuntu)
• Datos de supervisión (enviados a Log Analytics)
• Otros agentes que requieren tráfico de salida (específico del entorno de cada implementador)

Antes de implementar el clúster de Kubernetes mediante el motor de AKS, planee el diseño de redes final. Puede ser más eficaz implementar un clúster en una red existente en lugar de crear una red virtual dedicada. Por ejemplo, puede usar una conexión VPN de sitio a sitio existente que ya esté configurada en el entorno de Azure Stack Hub.

Infraestructura

La infraestructura hace referencia al acceso a los puntos de conexión de administración de Azure Stack Hub. Los puntos de conexión incluyen los portales de administración y de inquilino, así como los puntos de conexión de administración y de inquilino de Azure Resource Manager. Estos puntos de conexión son necesarios para trabajar con Azure Stack Hub y sus servicios principales.

Datos y almacenamiento

Se implementan dos instancias de la aplicación, en dos clústeres de Kubernetes individuales, en dos instancias de Azure Stack Hub. Para este diseño, es necesario tener en cuenta cómo replicar y sincronizar los datos entre las instancias.

Azure proporciona funcionalidad integrada para replicar el almacenamiento en varias regiones y zonas dentro de la nube. Actualmente, no hay ninguna manera nativa de replicar el almacenamiento en dos instancias de Azure Stack Hub. Forman dos nubes independientes y no hay ninguna manera general de administrarlas como un conjunto. Al planear la resistencia de las aplicaciones que se ejecutan en Azure Stack Hub, tenga en cuenta esta independencia en las implementaciones y el diseño de la aplicación.

En la mayoría de los casos, la replicación del almacenamiento no será necesaria para una aplicación resistente y de alta disponibilidad implementada en AKS. Pero debe tener en cuenta el almacenamiento independiente por instancia de Azure Stack Hub en el diseño de la aplicación. Si este diseño es un problema, tenga en cuenta las soluciones de almacenamiento adjunto que ofrecen los asociados de Microsoft. Estas proporcionan una solución de replicación del almacenamiento en varias instancias de Azure Stack Hub y Azure. Para obtener más información, consulte la sección Soluciones de asociados de este artículo.

Esta arquitectura tiene en cuenta estos elementos:

Configuración

Esta categoría incluye la configuración de Azure Stack Hub, el motor de AKS y el propio clúster de Kubernetes. Debe automatizar la configuración tanto como sea posible y almacenarla como infraestructura como código en un sistema de control de versiones basado en Git como Azure DevOps o GitHub. No se pueden sincronizar fácilmente estas configuraciones en varias implementaciones. Se recomienda almacenar y aplicar la configuración desde fuera y usar la canalización de DevOps.

Application

Debe almacenar la aplicación en un repositorio basado en Git. Si lo hace, siempre que haya una nueva implementación, cambios en la aplicación o a una recuperación ante desastres, puede implementar la aplicación fácilmente mediante Azure Pipelines.

Datos

Los datos son el aspecto más importante en la mayoría de los diseños de aplicaciones. Los datos de la aplicación deben permanecer sincronizados entre las distintas instancias de esta. También necesita una estrategia de copia de seguridad y recuperación ante desastres para los datos en caso de que se produzca una interrupción.

Si trabaja con datos en varias ubicaciones, la implementación de una solución resistente y de alta disponibilidad es aún más compleja. Tenga en cuenta lo siguiente:

• Latencia y conectividad de red entre las instancias de Azure Stack Hub.
• Disponibilidad de identidades para servicios y permisos. Cada instancia de Azure Stack Hub se integra con un directorio externo. Durante la implementación, puede elegir entre usar Microsoft Entra ID o los Servicios de federación de Active Directory (AD FS). De este modo, tiene la opción de usar una única identidad que pueda interactuar con varias instancias independientes de Azure Stack Hub.

Continuidad empresarial y recuperación ante desastres

La continuidad empresarial y la recuperación ante desastres (BCDR) son una consideración importante en Azure Stack Hub y en Azure. La diferencia principal es que, en Azure Stack Hub, el operador debe administrar todo el proceso de BCDR. En Azure, Microsoft administra automáticamente partes de BCDR.

BCDR afecta a las mismas áreas que se describen en la sección anterior:

• Infraestructura y configuración
• Disponibilidad de la aplicación
• Datos de aplicación

Estas áreas son responsabilidad del operador de Azure Stack Hub. Los detalles pueden variar, en función de la organización. Planee el BCDR según las herramientas y procesos disponibles.

Infraestructura y configuración

En esta sección se describe la infraestructura física y lógica y la configuración de Azure Stack Hub. Incluye las acciones de los espacios de administración y de inquilino.

El operador de Azure Stack Hub (o administrador) es responsable del mantenimiento de las instancias de Azure Stack Hub. Este mantenimiento incluye la red, el almacenamiento, la identidad y otros elementos que se encuentran fuera del ámbito de este artículo. Para más información sobre los detalles específicos de las operaciones de Azure Stack Hub, consulte estos recursos:

• Recuperación de datos de Azure Stack Hub con el servicio Copia de seguridad de infraestructura
• Habilitación de la copia de seguridad de Azure Stack Hub desde el portal del administrador
• Recuperación después de una pérdida de datos grave
• Procedimientos recomendados del servicio Infrastructure Backup

Azure Stack Hub es la plataforma y el tejido sobre los que se implementan las aplicaciones de Kubernetes. El propietario de la aplicación de Kubernetes es un usuario de Azure Stack Hub que tiene acceso para implementar la infraestructura de la aplicación necesaria para la solución. En este caso, la infraestructura de la aplicación es el clúster de Kubernetes, que se implementa mediante el motor de AKS, y los servicios circundantes.

Estos componentes se implementan en Azure Stack Hub. La oferta de Azure Stack Hub restringe los componentes. Asegúrese de que la oferta aceptada por el propietario de la aplicación de Kubernetes tenga capacidad suficiente, expresada en cuotas de Azure Stack Hub, para implementar toda la solución. Tal como se recomienda en la sección anterior, debe automatizar la implementación de la aplicación mediante la infraestructura como código y canalizaciones de implementación como Azure Pipelines.

Para más información sobre las ofertas y cuotas de Azure Stack Hub, consulte Introducción a los servicios, los planes, las ofertas y las suscripciones de Azure Stack Hub.

Es importante guardar y almacenar de forma segura la configuración del motor de AKS, incluidas sus salidas. Estos archivos contienen información confidencial que se usa para acceder al clúster de Kubernetes, por lo que se debe proteger frente a la exposición a usuarios que no son administradores.

Disponibilidad de la aplicación

La aplicación no debe basarse en las copias de seguridad de una instancia implementada. Como procedimiento estándar, vuelva a implementar la aplicación por completo siguiendo los patrones de infraestructura como código. Por ejemplo, vuelva a implementar con Azure Pipelines. El procedimiento de BCDR debe incluir la reimplementación de la aplicación en el mismo clúster de Kubernetes o en otro.

Datos de aplicación

Los datos de la aplicación son el componente crítico de BCDR. En las secciones anteriores, se describen técnicas para replicar y sincronizar los datos entre dos o más instancias de una aplicación. En función de la infraestructura de base de datos (como MySQL, MongoDB o SQL Server) usada para almacenar los datos, hay varias técnicas de disponibilidad y copia de seguridad de bases de datos disponibles.

Para lograr la integridad, se recomienda usar una de las siguientes soluciones:

• Una solución de copia de seguridad nativa para la base de datos específica.
• Una solución de copia de seguridad que admita la copia de seguridad y la recuperación del tipo de base de datos que emplea la aplicación.

Disponibilidad

Kubernetes en Azure Stack Hub, cuando se implementa mediante el motor de AKS, no es un servicio administrado. Se trata de la implementación y configuración automatizadas de un clúster de Kubernetes que utiliza la infraestructura como servicio (IaaS) de Azure. Por lo tanto, proporciona la misma disponibilidad que la infraestructura subyacente.

La infraestructura de Azure Stack Hub ya es resistente a los errores y proporciona funcionalidades, como los conjuntos de disponibilidad, para distribuir los componentes entre varios dominios de error y de actualización. No obstante, la tecnología subyacente (clústeres de conmutación por error) puede experimentar un cierto tiempo de inactividad de las máquinas virtuales de un servidor físico afectado si se produce un error de hardware.

Es recomendable implementar el clúster de Kubernetes de producción, así como la carga de trabajo, en dos o más clústeres. Estos clústeres se deben hospedar en diferentes ubicaciones o centros de datos y usar tecnologías como Traffic Manager para enrutar a los usuarios en función del tiempo de respuesta del clúster o la geografía.

Los clientes que tienen un único clúster de Kubernetes suelen conectarse a la dirección IP de servicio o al nombre DNS de una aplicación determinada. En una implementación de varios clústeres, los clientes deben conectarse a un nombre DNS de Traffic Manager que apunte a los servicios o entradas en cada clúster de Kubernetes.

El propio clúster de Kubernetes, implementado mediante el motor de AKS, debe constar de al menos tres nodos del plano de control y dos nodos de trabajo.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

La seguridad y la identidad son especialmente importantes cuando la solución abarca instancias independientes de Azure Stack Hub. Kubernetes y Azure, incluido Azure Stack Hub, tienen diferentes mecanismos de control de acceso basado en rol (RBAC):

• RBAC de Azure controla el acceso a Azure y Azure Stack Hub, incluida la capacidad de crear nuevos recursos de Azure. Los permisos se pueden asignar a usuarios, grupos o entidades de servicio. (Una entidad de servicio es una identidad de seguridad utilizada por las aplicaciones).
• El control de acceso basado en rol de Kubernetes controla los permisos para la API de Kubernetes. Por ejemplo, la creación de pods y la enumeración de pods son acciones que se pueden autorizar o denegar a un usuario mediante RBAC. Para asignar permisos de Kubernetes a los usuarios, puede crear roles y enlaces de rol.

Identidad y control de acceso basado en rol de Azure Stack Hub

Azure Stack Hub proporciona dos opciones de proveedor de identidades. El proveedor que use dependerá del entorno y de si se ejecuta en un entorno conectado o desconectado:

• Microsoft Entra ID solo se puede usar en un entorno conectado.
• AD FS en un bosque de Active Directory tradicional se puede usar en un entorno conectado o desconectado.

El proveedor de identidades administra usuarios y grupos, incluida la autenticación y autorización para acceder a los recursos. Se puede conceder acceso a los recursos de Azure Stack Hub como suscripciones y grupos de recursos, y a recursos individuales, como las máquinas virtuales y los equilibradores de carga. Por coherencia, considere la posibilidad de usar los mismos grupos, directos o anidados, para todas las instancias de Azure Stack Hub. A continuación se muestra un ejemplo de configuración:

Este ejemplo contiene un grupo dedicado (mediante Microsoft Entra ID o AD FS) para un propósito específico, por ejemplo, para proporcionar permisos de Colaborador para el grupo de recursos que contiene la infraestructura del clúster de Kubernetes en una instancia específica de Azure Stack Hub (aquí, "Colaborador del clúster de K8s de Seattle"). A continuación, estos grupos se anidan en un grupo general que contiene los subgrupos de cada instancia de Azure Stack Hub.

El usuario de ejemplo tiene ahora permisos de Colaborador en los grupos de recursos que contienen todo el conjunto de recursos de infraestructura de Kubernetes. El usuario tiene acceso a los recursos de ambas instancias de Azure Stack Hub, ya que estas comparten el mismo proveedor de identidades.

Identidad de Kubernetes y RBAC

De manera predeterminada, un clúster de Kubernetes no usa el mismo proveedor de identidades que la instancia de Azure Stack Hub subyacente. Las máquinas virtuales que hospedan el clúster de Kubernetes, el plano de control y los nodos de trabajo usan la clave SSH especificada cuando se implementó el clúster. Esta clave SSH es necesaria para la conexión a estos nodos mediante SSH.

La API de Kubernetes (a la que se tiene acceso, por ejemplo, mediante kubectl) también está protegida por cuentas de servicio, incluida una cuenta de servicio de administrador del clúster predeterminada. Las credenciales de esta cuenta de servicio se almacenan inicialmente en el archivo .kube/config de los nodos del plano de control de Kubernetes.

Administración de secretos y credenciales de aplicaciones

Tiene varias opciones para almacenar secretos, como cadenas de conexión y credenciales de base de datos, entre las que se incluyen:

• Azure Key Vault
• Secretos de Kubernetes
• Soluciones de terceros como HashiCorp Vault (que se ejecuta en Kubernetes)

No almacene secretos ni credenciales en texto no cifrado en los archivos de configuración, en el código de la aplicación ni en los scripts. Y no los almacene en un sistema de control de versiones. En su lugar, la automatización de la implementación debe recuperar los secretos según sea necesario.

Revisión y actualización

El proceso de revisión y actualización en AKS está automatizado parcialmente. Las actualizaciones de versiones de Kubernetes se desencadenan manualmente, mientras que las actualizaciones de seguridad se aplican automáticamente. Estas actualizaciones pueden incluir las revisiones de seguridad del sistema operativo o las actualizaciones del kernel. AKS no reinicia automáticamente los nodos de Linux para completar el proceso de actualización.

El proceso de revisión y actualización de un clúster de Kubernetes implementado mediante el motor de AKS en Azure Stack Hub es no administrado. Es responsabilidad del operador del clúster.

El motor de AKS ayuda con las dos tareas más importantes:

• Actualizar a una versión más reciente de la imagen de Kubernetes y del sistema operativo base
• Actualizar solo la imagen del sistema operativo base

Las imágenes más recientes del sistema operativo base contienen las últimas correcciones de seguridad del sistema operativo y las actualizaciones del kernel.

El utilidad de actualización desatendida instala automáticamente las actualizaciones de seguridad que se publican antes de que haya disponible una nueva versión de la imagen del sistema operativo base en el Marketplace de Azure Stack Hub. La actualización desatendida está habilitada de manera predeterminada e instala las actualizaciones de seguridad automáticamente, pero no reinicia los nodos de clúster de Kubernetes. Puede automatizar el reinicio de los nodos mediante el demonio de reinicio de Kubernetes de código abierto (kured). El demonio Kured supervisa los nodos de Linux que requieren un reinicio y, después, administra automáticamente la reprogramación de los pods en ejecución y el proceso de reinicio de los nodos.

Implementación (CI/CD)

Azure y Azure Stack Hub exponen las mismas API REST de Resource Manager. Estas API se tratan como se haría en cualquier otra plataforma en la nube de Azure (Azure, Azure China 21Vianet, Azure Government). Las distintas plataformas en la nube pueden usar diferentes versiones de API y Azure Stack Hub solo proporciona un subconjunto de servicios. El identificador URI del punto de conexión de administración también es diferente para cada plataforma en la nube y cada instancia de Azure Stack Hub.

Aparte de las pequeñas diferencias mencionadas, las API REST de Resource Manager proporcionan una manera coherente de interactuar con Azure y Azure Stack Hub. Puede usar el mismo conjunto de herramientas aquí como lo haría con cualquier otra plataforma en la nube de Azure. Puede usar Azure DevOps, herramientas como Jenkins, o PowerShell para implementar y coordinar los servicios en Azure Stack Hub.

Consideraciones

Una de las principales diferencias en las implementaciones de Azure Stack Hub es la implementación de la accesibilidad a Internet. La accesibilidad a Internet determina si se debe seleccionar un agente de compilación hospedado por Microsoft o uno autohospedado para los trabajos de CI/CD.

Un agente autohospedado se puede ejecutar sobre Azure Stack Hub (como una máquina virtual de IaaS) o en una subred con acceso a Azure Stack Hub. Para más información sobre las diferencias, consulte Agentes de Azure Pipelines.

El siguiente gráfico de flujo puede ayudarle a decidir si necesita un agente de compilación autohospedado o un agente de compilación hospedado por Microsoft:

• ¿Se puede acceder a los puntos de conexión de administración de Azure Stack Hub mediante Internet?
  • Sí: puede usar Azure Pipelines con agentes hospedados por Microsoft para conectarse a Azure Stack Hub.
  • No: se necesitan agentes autohospedados que puedan conectarse a los puntos de conexión de administración de Azure Stack Hub.
• ¿Se puede acceder al clúster de Kubernetes mediante Internet?
  • Sí: puede usar Azure Pipelines con agentes hospedados por Microsoft para interactuar directamente con el punto de conexión de la API de Kubernetes.
  • No: se necesitan agentes autohospedados que puedan conectarse al punto de conexión de la API del clúster de Kubernetes.

Si los puntos de conexión de administración de Azure Stack Hub y la API de Kubernetes son accesibles mediante Internet, la implementación puede usar un agente hospedado por Microsoft. Esta implementación da como resultado la siguiente arquitectura de aplicación:

Si no se puede acceder a los puntos de conexión de Resource Manager, a la API de Kubernetes, o a ambos, directamente mediante Internet, puede utilizar un agente de compilación autohospedado para ejecutar los pasos de la canalización. Este diseño requiere menos conectividad. Se puede implementar solo con conectividad de red local a los puntos de conexión de Resource Manager y la API de Kubernetes:

La solución puede usar un clúster de Kubernetes implementado y organizado con el motor de AKS en cada instancia de Azure Stack Hub. Incluye una aplicación que consta de un front-end, una capa intermedia, servicios de back-end (por ejemplo, MongoDB) y un controlador de entrada basado en NGINX. En lugar de usar una base de datos hospedada en el clúster de Kubernetes, puede usar almacenes de datos externos. Entre las opciones de base de datos, se incluyen MySQL, SQL Server o cualquier tipo de base de datos hospedada fuera de Azure Stack Hub o en IaaS. Estas configuraciones se encuentran fuera del ámbito de este artículo.

Soluciones de socios

Puede utilizar soluciones de asociados de Microsoft para ampliar las funcionalidades de Azure Stack Hub. Estas soluciones pueden ser útiles en implementaciones de aplicaciones que se ejecutan en clústeres de Kubernetes.

Soluciones de almacenamiento y datos

Como se indicó anteriormente, a diferencia de Azure, Azure Stack Hub no tiene actualmente una solución nativa para replicar el almacenamiento en varias instancias. En Azure Stack Hub, cada instancia es su propia nube independiente. Sin embargo, puede obtener soluciones de asociados de Microsoft que permiten la replicación del almacenamiento en instancias de Azure Stack Hub y en Azure:

• Scality proporciona almacenamiento a escala web. El almacenamiento definido por software Scality RING convierte los servidores x86 básicos en un bloque de almacenamiento ilimitado para cualquier tipo de datos a escala de petabytes.
• Cloudian proporciona un almacenamiento escalable sin límites que consolida conjuntos de datos masivos en un único entorno.

Pasos siguientes

• Introducción a Azure Stack Hub
• ¿Qué es Azure Repos?
• ¿Qué es Azure Pipelines?
• Introducción a Azure Monitor
• Patrón de escalado entre nubes (datos locales)
• Patrón de aplicación distribuida geográficamente
• Formación: Azure Stack Hub

Recursos relacionados

• Arquitectura de microservicios en Azure Kubernetes Service (AKS)
• Implementación de un clúster de Kubernetes de alta disponibilidad en Azure Stack Hub