Editar

Implementación y administración híbridas de Azure Arc para clústeres de Kubernetes

Azure Arc
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Policy
Control de acceso basado en rol de Azure

Esta arquitectura de referencia muestra cómo Azure Arc extiende la configuración y la administración de clústeres de Kubernetes en centros de datos de clientes, ubicaciones perimetrales y varios entornos en la nube.

Architecture

Diagrama de arquitectura que muestra una topología de Azure Arc para Kubernetes.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

La arquitectura consta de los siguientes aspectos:

  • Kubernetes habilitado para Azure Arc. Asocie y configure clústeres de Kubernetes dentro o fuera de Azure mediante Kubernetes habilitado para Azure Arc. Cuando un clúster de Kubernetes está asociado a Azure Arc, se le asigna un identificador de Azure Resource Manager y una identidad administrada.
  • Azure Kubernetes Service . Hospede clústeres de Kubernetes en Azure para reducir la complejidad y la sobrecarga operativa de la administración de clústeres de Kubernetes.
  • Clúster de Kubernetes local . Asocie los clústeres de Kubernetes certificados de Cloud Native Computing Foundation (CNCF) hospedados en entornos de nube locales o de terceros.
  • Azure Policy . Implemente y administre directivas para clústeres de Kubernetes habilitados para ARC.
  • Azure Monitor. Observe y supervise los clústeres de Kubernetes habilitados para ARC.

Componentes

  • Azure Arc es un puente que amplía la plataforma Azure, lo que permite crear aplicaciones y servicios que se pueden ejecutar en centros de datos, en el perímetro y en entornos multinube.
  • Azure Kubernetes Service (AKS) es un servicio administrado para implementar y escalar clústeres de Kubernetes.
  • Azure Policy permite lograr el cumplimiento de la nube en tiempo real a escala con una gobernanza de recursos coherente.
  • Azure Monitor proporciona observabilidad completa de las aplicaciones, la infraestructura y la red.

Detalles del escenario

Puede usar Azure Arc para registrar clústeres de Kubernetes hospedados fuera de Microsoft Azure. Después, puede usar las herramientas de Azure para administrar estos clústeres junto con los clústeres hospedados en Azure Kubernetes Service (AKS).

Posibles casos de uso

Los usos habituales de esta arquitectura incluyen:

  • Administración de clústeres de Kubernetes locales junto con clústeres hospedados en AKS para el inventario, la agrupación y el etiquetado.
  • Uso de Azure Monitor para supervisar clústeres de Kubernetes en entornos híbridos.
  • Uso de Azure Policy para implementar y aplicar directivas para clústeres de Kubernetes en entornos híbridos.
  • Uso de Azure Policy para implementar y aplicar GitOps.

Recomendaciones

Las siguientes secciones ofrecen recomendaciones aplicables a la mayoría de los escenarios. Microsoft recomienda que las siga a menos que tenga un requisito que las invalide.

Registro de clústeres

Puede registrar cualquier clúster de Kubernetes de CNCF activo. Necesitará un archivo kubeconfig para acceder al clúster y un rol de administrador del clúster en el clúster para implementar los agentes de Kubernetes habilitados para Arc. Usará la Interfaz de la línea de comandos de Azure (CLI de Azure) para realizar las tareas de registro del clúster. El usuario o la entidad de servicio que se usa con los comandos az login y az connectedk8s connect debe tener obligatoriamente los permisos de Lectura y Escritura en el tipo de recurso Microsoft.Kubernetes/connectedClusters. El rol Clúster de Kubernetes - Incorporación de Azure Arc tiene estos permisos y se puede usar para las asignaciones de roles en la entidad de seguridad de usuario o la entidad de servicio. Helm 3 es necesario para incorporar el clúster que usa la extensión connectedk8s. Se requiere la CLI de Azure versión 2.3 o posterior para instalar las extensiones de la Interfaz de la línea de comandos de Kubernetes habilitado para Azure Arc.

Agentes de Azure Arc para Kubernetes

Kubernetes habilitado para Azure Arc consta de algunos agentes (también denominados operadores) que se ejecutan en el clúster implementado en el espacio de nombres azure-arc:

  • deployment.apps/config-agent. Busca en el clúster conectado los recursos de configuración de control de código fuente que se aplican en el clúster y actualiza el estado de cumplimiento.
  • deployment.apps/controller-manager. Operador de operadores que organiza las interacciones entre los componentes de Azure Arc.
  • deployment.apps/metrics-agent. Recopila métricas de otros agentes de Arc para asegurarse de que presentan un rendimiento óptimo.
  • deployment.apps/cluster-metadata-operator. Recopila metadatos del clúster, la versión del clúster, el número de nodos y la versión del agente de Azure Arc.
  • deployment.apps/resource-sync-agent. Sincroniza con Azure los metadatos de clúster mencionados anteriormente.
  • deployment.apps/clusteridentityoperator. Mantiene el certificado de Managed Service Identity (MSI) que usan otros agentes para la comunicación con Azure.
  • deployment.apps/flux-logs-agent. Recopila registros de los operadores de Flux que se implementan como parte de la configuración de control de código fuente.
  • deployment.apps/extension-manager. Instala y administra el ciclo de vida de los gráficos de Helm de extensiones.
  • deployment.apps/kube-azure-ad-proxy. Se usa para la autenticación de solicitudes enviadas al clúster mediante Conexión de clúster.
  • deployment.apps/clusterconnect-agent. Agente proxy inverso que habilita la característica Conexión de clúster para que proporcione acceso a apiserver del clúster. Se trata de un componente opcional que solo se implementa si la característica Conexión de clúster está habilitada en el clúster.
  • deployment.apps/guard. Un servidor de webhook de autenticación y autorización que se usa para el control de acceso basado en roles (RBAC) de Microsoft Entra. Se trata de un componente opcional que solo se implementa si la característica RBAC de Azure está habilitada en el clúster.

Para más información, consulte Conexión de un clúster de Kubernetes habilitado para Azure Arc.

Supervisión de clústeres mediante Azure Monitor Container Insights

La supervisión de los contenedores es fundamental. Azure Monitor Container Insights proporciona una experiencia de supervisión enriquecida para los clústeres de AKS y del motor de AKS. También puede configurar Azure Monitor Container Insights con el fin de supervisar clústeres de Kubernetes habilitado para Azure Arc hospedados fuera de Azure. Esto proporciona una supervisión completa de los clústeres de Kubernetes en entornos de nube de Azure, locales y de terceros.

Azure Monitor Container Insights le brinda la posibilidad de visibilizar el rendimiento mediante la recopilación de métricas del procesador y de la memoria de los controladores, nodos y contenedores, métricas que están disponibles en Kubernetes mediante la interfaz de programación de aplicaciones (API) de métricas. También se recopilan registros del contenedor. Una vez habilitada la supervisión de clústeres de Kubernetes, se recopilan métricas y registros automáticamente mediante una versión en contenedor del agente de Log Analytics. Las métricas se escriben en el almacén de métricas y los datos de registro se incluyen en el almacén de registros asociado a su área de trabajo de Log Analytics. Para más información acerca de Azure Monitor Container Insights, consulte Introducción a Azure Monitor Container Insights.

Puede habilitar Azure Monitor Container Insights para una o varias implementaciones de Kubernetes existentes mediante un script de Bash o PowerShell.

Para habilitar la supervisión de clústeres de Kubernetes habilitados para Arc, consulte Habilitación de la supervisión en el clúster de Kubernetes habilitado para Azure Arc.

Uso de Azure Policy para habilitar la implementación de aplicaciones basadas en GitOps

Use Azure Policy para exigir que cada recurso Microsoft.Kubernetes/connectedclusters o Microsoft.ContainerService/managedClusters habilitado para Git-Ops tenga aplicado un recurso Microsoft.KubernetesConfiguration/fluxConfigurations específico. Por ejemplo, puede aplicar una configuración de línea de base a uno o varios clústeres o implementar aplicaciones específicas en varios clústeres. Para usar Azure Policy, seleccione una definición de las Definiciones de directivas integradas de Azure Policy para Kubernetes habilitado para Azure Arc y, a continuación, cree una asignación de directiva.

Cuando cree la asignación de directiva, establezca el ámbito en un grupo de recursos o una suscripción de Azure. Establezca también los parámetros del elemento fluxConfiguration que se crea. Cuando se crea la asignación, el motor de Policy identifica todos los recursos connectedCluster o managedCluster que se encuentran en el ámbito y, a continuación, aplica fluxConfiguration a cada uno.

Si usa varios repositorios de origen para cada clúster (por ejemplo, un repositorio para el operador de clúster o TI central, y otros para los equipos de aplicaciones), actívelo mediante varias asignaciones de directiva, cada una configurada para utilizar un repositorio de origen diferente.

Para obtener más información, consulte Implementación de aplicaciones de forma coherente a escala mediante configuraciones de Flux v2 y Azure Policy.

Implementación de aplicaciones mediante GitOps

GitOps es la práctica de declarar el estado deseado de la configuración de Kubernetes (implementaciones, espacios de nombres, etc.) en un repositorio de origen, como un repositorio Git o Helm, cubos o Azure Blob Storage. A esto le sigue una implementación de sondeo basada en extracción de estas configuraciones en el clúster mediante un operador.

La conexión entre el clúster y uno o varios repositorios de origen se habilita mediante la implementación de la extensión microsoft.flux en el clúster. Las propiedades del recurso fluxConfiguration representan dónde y cómo deben fluir los recursos de Kubernetes desde el repositorio de origen al clúster. Los datos de fluxConfiguration se almacenan cifrados en reposo en una base de datos de Azure Cosmos DB para garantizar su confidencialidad.

El elemento flux-config que se ejecuta en el clúster es responsable de inspeccionar los recursos de extensión de fluxConfiguration nuevos o actualizados en el recurso de Kubernetes habilitado para Azure Arc, de implementar aplicaciones desde el repositorio de origen y de propagar las actualizaciones realizadas en fluxConfiguration. Incluso puede crear varios recursos de fluxConfiguration mediante el ámbito de espacio de nombres en el mismo clúster de Kubernetes habilitado para Azure Arc para lograr la función de multiinquilino.

El repositorio de origen puede contener cualquier recurso de Kubernetes válido, incluidos espacios de nombres, ConfigMaps, implementaciones y DaemonSets. También puede contener gráficos de Helm para implementar aplicaciones. Entre los escenarios comunes de repositorio de origen se incluye la definición de una configuración de línea de base para la organización, que podría incluir roles y enlaces de control de acceso basado en rol (RBAC) comunes, agentes de supervisión o registro, o servicios para todo el clúster.

También puede administrar una colección mayor de clústeres, que se puede implementar en entornos heterogéneos. Por ejemplo, puede tener un repositorio que defina la configuración de línea de base para la organización y, después, aplicarla a varios clústeres de Kubernetes simultáneamente. También puede implementar aplicaciones en un clúster desde varios repositorios de origen.

Para obtener más información, consulte Implementación de aplicaciones con GitOps con Flux v2.

Topología, red y enrutamiento

Los agentes de Azure Arc requieren los siguientes protocolos, puertos y direcciones URL de salida para funcionar:

Punto de conexión (DNS) Descripción
https://management.azure.com:443 Necesario para que el agente se conecte a Azure y registre el clúster.
https://[region].dp.kubernetesconfiguration.azure.com:443 Extremo de plano de datos para que el agente inserte el estado y obtenga la información de configuración, donde [region] representa la región de Azure que hospeda la instancia de AKS.
https://docker.io:443 Necesario para extraer imágenes de contenedor.
https://github.com:443, git://github.com:9418 Los repositorios de GitOps de ejemplo se hospedan en GitHub. El agente de configuración requiere conectividad con el punto de conexión de Git que se especifique.
https://login.microsoftonline.com:443 Necesario para capturar y actualizar tokens de Azure Resource Manager.
https://azurearcfork8s.azurecr.io:443 Necesario para extraer imágenes de contenedor para agentes de Azure Arc.

Para obtener una lista completa de las direcciones URL de los servicios de Azure Arc, consulte Requisitos de red de Azure Arc.

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.

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.

  • En la mayoría de los casos, la ubicación que seleccione al crear el script de instalación debe ser la región de Azure más cercana geográficamente a los recursos locales. El resto de los datos se almacenarán en la geografía de Azure que contiene la región que especifique, lo que también puede afectar a su elección de región si tiene requisitos de residencia de datos. Si se produce una interrupción en la región de Azure a la que está conectada la máquina, la interrupción no afectará a la máquina conectada, aunque es posible que las operaciones de administración que usan Azure no se puedan completar. Para lograr resistencia en caso de una interrupción regional, si dispone de varias ubicaciones que proporcionan un servicio con redundancia geográfica, es mejor conectar las máquinas de cada ubicación a una región diferente de Azure. En el caso de las regiones disponibles, consulte Regiones admitidas para Kubernetes habilitado para Azure Arc.
  • Debe asegurarse de que los servicios a los que se hace referencia en la sección Arquitectura se admiten en la región en la que se implementa Azure Arc.

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.

  • Puede usar Azure RBAC para administrar el acceso a Kubernetes habilitado para Azure Arc en entornos locales y de Azure que use identidades de Microsoft Entra. Para más información, consulte Uso de la autorización de Azure RBAC para Kubernetes.
  • Microsoft recomienda usar una entidad de servicio que tenga privilegios limitados para incorporar clústeres de Kubernetes a Azure Arc. Este procedimiento es útil en canalizaciones de CI/CD, como Azure Pipelines y Acciones de GitHub. Para más información, consulte Creación de una entidad de servicio de incorporación habilitada para Azure Arc.
  • Para simplificar la administración de la entidad de servicio, puede usar identidades administradas en AKS. Sin embargo, los clústeres deben crearse con la identidad administrada, y los clústeres existentes (incluidos los clústeres locales y de Azure) no se pueden migrar a identidades administradas. Para obtener más información, consulte Uso de identidades administradas en Azure Kubernetes Service.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

En la sección Principios de la optimización de costos del Marco de buena arquitectura de Microsoft Azure se describen consideraciones generales sobre el costo.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

  • Antes de configurar los clústeres de Kubernetes habilitados para Azure Arc, revise los límites de suscripción y los límites del grupo de recursos de Azure Resource Manager para planear el número de clústeres.
  • Use Helm, la herramienta de empaquetado de código abierto, para instalar y administrar los ciclos de vida de las aplicaciones de Kubernetes. Helm, que funciona de forma similar a los administradores de paquetes de Linux como APT y Yum, se usa para administrar los gráficos de Kubernetes, que son paquetes de recursos de Kubernetes preconfigurados.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Guía híbrida relacionada:

Arquitecturas relacionadas: