Compartir a través de


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

En esta arquitectura de referencia se describe cómo Azure Arc amplía la configuración y la administración de clústeres de Kubernetes en centros de datos de clientes, ubicaciones perimetrales y varios entornos de nube.

Arquitectura

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

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

El siguiente flujo de trabajo corresponde al diagrama anterior:

  • Kubernetes habilitado para Azure Arc: Adjunte 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 (AKS): 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: Adjunte clústeres de Kubernetes certificados por Cloud Native Computing Foundation (CNCF) que se hospedan en entornos en la nube locales o que no son de Microsoft.

  • Azure Policy: Implemente y administre directivas para clústeres de Kubernetes habilitados para Azure Arc.

  • Azure Monitor: Observe y supervise los clústeres de Kubernetes habilitados para Azure Arc.

Componentes

  • Azure Arc amplía la plataforma Azure, lo que permite crear aplicaciones y servicios que se pueden ejecutar entre centros de datos, en el perímetro y en entornos multinube.

  • 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 herramientas de Azure para administrar estos clústeres y clústeres hospedados en AKS.

Posibles casos de uso

Los usos habituales de esta arquitectura incluyen:

  • Administración del inventario, agrupación y etiquetado de clústeres de Kubernetes locales y clústeres hospedados en AKS.

  • Uso de Azure Monitor para supervisar clústeres de Kubernetes en entornos híbridos.

  • Uso de Azure Policy para ayudar a implementar y aplicar directivas para clústeres de Kubernetes en entornos híbridos.

  • Uso de Azure Policy para ayudar a implementar y aplicar GitOps.

  • Maximizar la inversión de la unidad de procesamiento de gráficos (GPU) local mediante el entrenamiento e implementación de flujos de trabajo de Azure Machine Learning.

  • Uso del servicio administrado de Azure Monitor para Prometheus y Managed Grafana para supervisar y visualizar las cargas de trabajo de Kubernetes.

Recomendaciones

Puede aplicar las siguientes recomendaciones a la mayoría de los escenarios. Sígalas a menos que tenga un requisito concreto que las invalide.

Registro de clústeres

Puede registrar cualquier clúster de Kubernetes de CNCF activo. Necesita un kubeconfig archivo para acceder al clúster y un rol de administrador de clústeres en el clúster para implementar agentes de Kubernetes habilitados para Azure Arc. Use la CLI de Azure para realizar tareas de registro de clúster. El usuario o la entidad de servicio que usa para los az login comandos y az connectedk8s connect requiere permisos de lectura y escritura en el Microsoft.Kubernetes/connectedClusters tipo de recurso. 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 connectedk8s extensión. Se requiere la versión 2.3 o posterior de la CLI de Azure para instalar las extensiones de la CLI de Kubernetes habilitadas para Azure Arc.

Agentes de Azure Arc para Kubernetes

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

  • deployment.apps/config-agent Supervisa el clúster conectado para 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 es un operador de operadores que organiza las interacciones entre los componentes de Azure Arc.

  • deployment.apps/metrics-agent recopila métricas de otros agentes de Azure Arc para asegurarse de que estos agentes funcionan de forma óptima.

  • deployment.apps/cluster-metadata-operator recopila metadatos del clúster, incluida la versión del clúster, el recuento de nodos y la versión del agente de Azure Arc.

  • deployment.apps/resource-sync-agent sincroniza los metadatos del clúster mencionados anteriormente con Azure.

  • deployment.apps/clusteridentityoperator mantiene el certificado de Managed Service Identity que usan otros agentes para comunicarse con Azure.

  • deployment.apps/flux-logs-agent recopila registros de los operadores de flujo que se implementan como parte de la configuración del control de código fuente.

  • Instala deployment.apps/extension-manager y administra el ciclo de vida de los gráficos de Helm de extensión.

  • deployment.apps/kube-aad-proxy controla la autenticación de las solicitudes enviadas al clúster a través de la característica de conexión del clúster de AKS.

  • deployment.apps/clusterconnect-agent es un agente de proxy inverso que permite que la característica de conexión del clúster proporcione acceso al servidor de API 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 es un servidor de webhook de autenticación y autorización que se usa para el control de acceso basado en rol (RBAC) de Microsoft Entra. Es un componente opcional que solo se implementa si Azure RBAC está habilitado en el clúster.

  • deployment.apps/extension-events-collector recopila registros relacionados con la administración del ciclo de vida de las extensiones. Agrega estos registros en eventos que corresponden a cada operación, como Crear, Actualizar y Eliminar.  

  • deployment.apps/logcollector recopila telemetría de plataforma para ayudar a garantizar el estado operativo de la plataforma.

Para más información, consulte Conexión de un clúster de Kubernetes existente a 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 funcionalidades de supervisión sólidas para clústeres de motores de AKS y AKS. También puede configurar Azure Monitor Container Insights para supervisar clústeres de Kubernetes habilitados para Azure Arc hospedados fuera de Azure. Esta configuración proporciona una supervisión completa de los clústeres de Kubernetes en Azure, locales y en entornos en la nube que no son de Microsoft.

Azure Monitor Container Insights proporciona visibilidad del rendimiento mediante la recopilación de métricas de memoria y procesador de controladores, nodos y contenedores. Estas métricas están disponibles en Kubernetes a través de metrics API. También se recopilan registros del contenedor. Después de habilitar la supervisión desde clústeres de Kubernetes, una versión en contenedor del agente de Log Analytics recopila automáticamente métricas y registros. 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, consulte Características de Azure Monitor para la supervisión de Kubernetes.

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

Para más información, consulte Habilitar la supervisión de clústeres de Kubernetes.

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

Use Azure Policy para asegurarse de que cada recurso o Microsoft.ContainerService/managedClusters recurso habilitado para Microsoft.Kubernetes/connectedclusters GitOps se haya aplicado específico Microsoft.KubernetesConfiguration/fluxConfigurations en él. 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, elija una definición de las definiciones 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 para el fluxConfiguration objeto que se crea. Cuando se crea la asignación, el motor de Azure Policy identifica todos los connectedCluster recursos o managedCluster que están en el ámbito y, a continuación, aplica el fluxConfiguration objeto a cada recurso.

Si usa varios repositorios de origen para cada clúster, como un repositorio para el operador central de TI o clúster y otros repositorios para los equipos de aplicaciones, active esta característica mediante varias asignaciones de directivas y configure cada asignación de directiva para usar un repositorio de origen diferente.

Para 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 definir el estado deseado de las configuraciones de Kubernetes, como implementaciones y espacios de nombres, en un repositorio de origen. Este repositorio puede ser un repositorio de Git o Helm, buckets o Azure Blob Storage. Este proceso va seguido de una implementación basada en sondeos y 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 en el microsoft.flux clúster. Las fluxConfiguration propiedades de recursos representan dónde y cómo deben fluir los recursos de Kubernetes desde el repositorio de origen al clúster. Los fluxConfiguration datos se almacenan cifrados en reposo en una base de datos de Azure Cosmos DB para ayudar a garantizar la confidencialidad de los datos.

El flux-config agente que se ejecuta en el clúster supervisa los recursos de extensión nuevos o actualizados fluxConfiguration en el recurso de Kubernetes habilitado para Azure Arc, implementa aplicaciones desde el repositorio de origen y propaga todas las actualizaciones realizadas en .fluxConfiguration Puede crear varios fluxConfiguration recursos mediante el namespace ámbito en el mismo clúster de Kubernetes habilitado para Azure Arc para lograr 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 del repositorio de origen se incluye la definición de una configuración de línea base para su organización que puede incluir roles y enlaces comunes de RBAC, agentes de supervisión, agentes de registro y servicios en 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 base de la organización y, a continuación, aplicar esa configuración a varios clústeres de Kubernetes simultáneamente. También puede implementar aplicaciones en un clúster desde varios repositorios de origen.

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

Ejecución de Machine Learning

En Machine Learning, puede elegir un clúster de AKS (o Kubernetes habilitado para Azure Arc) como destino de proceso para los procesos de aprendizaje automático. Esta funcionalidad le permite entrenar o implementar modelos de aprendizaje automático en su propia infraestructura autohospedada (o multinube). Este enfoque le permite combinar sus inversiones locales en GPU con la facilidad de administración que proporciona Machine Learning en la nube.

Supervisión de cargas de trabajo de Kubernetes con Prometheus y Grafana administrados

Azure Monitor proporciona un servicio administrado para las implementaciones de Prometheus y Grafana, para que pueda aprovechar estas populares herramientas de supervisión de Kubernetes. Este servicio administrado le permite usar estas herramientas sin necesidad de administrar y actualizar las implementaciones usted mismo. Para analizar las métricas de Prometheus, use el explorador de métricas con PromQL.

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 especifique.
https://login.microsoftonline.com:443, , https://<region>.login.microsoft.com, login.windows.net Necesario para capturar y actualizar tokens de Azure Resource Manager.
https://mcr.microsoft.com:443 https://*.data.mcr.microsoft.com: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 Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar 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 ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, vea Lista de comprobación de revisión de diseño para lade confiabilidad.

  • En la mayoría de los escenarios, la ubicación que elija 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 almacenan en la geografía de Azure que contiene la región especificada. Este detalle puede afectar a la elección de la 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. Si tiene varias ubicaciones que proporcionan un servicio con redundancia geográfica, conecte las máquinas de cada ubicación a otra región de Azure. Esta práctica mejora la resistencia si se produce una interrupción regional. Para más información, consulte Regiones admitidas para Kubernetes habilitado para Azure Arc.

  • Debe asegurarse de que los servicios de la solución se admiten en la región donde se implementa Azure Arc.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, vea Lista de comprobación de revisión de diseño para security.

  • 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. Esta práctica es útil en canalizaciones de integración continua y entrega continua, 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 se deben crear mediante la identidad administrada. Los clústeres existentes, que incluyen Azure y los clústeres locales, no se pueden migrar a identidades administradas. Para más información, consulte Uso de una identidad administrada en AKS.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costos.

Para conocer las consideraciones generales sobre los costos, consulte Principios de diseño de optimización de costos.

Excelencia operativa

La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo mantienen en ejecución en producción. Para obtener más información, vea Lista de comprobación de revisión de diseño para la excelencia operativa.

  • Antes de configurar los clústeres de Kubernetes habilitados para Azure Arc, revise los límites de suscripción de Azure Resource Manager y los límites del grupo de recursos para planear el número de clústeres.

  • Use Helm, que es una herramienta de empaquetado de código abierto, para instalar y administrar los ciclos de vida de la aplicación de Kubernetes. De forma similar a los administradores de paquetes de Linux, como APT e Yum, use Helm para administrar gráficos de Kubernetes, que son paquetes de recursos de Kubernetes preconfigurados.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

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: