Preguntas más frecuentes: Kubernetes habilitado para Azure Arc y GitOps

  • Artículo

En este artículo se abordan las preguntas más frecuentes sobre Kubernetes habilitado para Azure Arc y GitOps.

¿Cuál es la diferencia entre Kubernetes habilitado para Azure Arc y Azure Kubernetes Service (AKS)?

AKS es la oferta de Kubernetes administrado de Azure. AKS facilita la implementación de un clúster de Kubernetes administrado en Azure al traspasar gran parte de la complejidad y sobrecarga operativa a Azure. Como Azure administra los maestros de Kubernetes, solo administra y mantiene los nodos de agente.

Kubernetes habilitado para Azure Arc permite ampliar las funcionalidades de administración de Azure (como Azure Monitor y Azure Policy) al conectar clústeres de Kubernetes a Azure. Usted mantiene el propio clúster de Kubernetes subyacente.

¿Es necesario conectar a Azure Arc los clústeres de AKS que se ejecutan en Azure?

Actualmente, no es necesario conectar un clúster de Azure Kubernetes Service (AKS) a Azure Arc en la mayoría de los escenarios. Es posible que quiera conectar un clúster para ejecutar determinados servicios habilitados para Azure Arc, como App Services y Data Services en la parte superior del clúster. Esto se puede hacer mediante la característica de ubicaciones personalizadas de Kubernetes habilitado para Azure Arc.

¿Debo conectar el clúster AKS-HCI y los clústeres de Kubernetes en Azure Stack Edge a Azure Arc?

La conexión del clúster AKS-HCI o los clústeres de Kubernetes en Azure Stack Edge a Azure Arc proporciona clústeres con representación de recursos en Azure Resource Manager. Con esta representación de recursos, se amplían algunas funcionalidades, como la configuración de clúster, Azure Monitor y Azure Policy (Gatekeeper), a los clústeres de Kubernetes conectados.

Si el clúster de Kubernetes habilitado para Azure Arc está en Azure Stack Edge, AKS en Azure Stack HCI (>= actualización de abril de 2021) o AKS en Windows Server 2019 Datacenter (>= actualización de abril de 2021), la configuración de Kubernetes se incluye sin cargo alguno.

¿Cómo puedo tratar los recursos expirados de Kubernetes habilitado para Azure Arc?

La identidad administrada asignada por el sistema asociada con el clúster de Kubernetes habilitado para Azure Arc solo la usan los agentes de Azure Arc para comunicarse con los servicios de Azure Arc. El certificado asociado a esta identidad administrada asignada por el sistema tiene una ventana de expiración de 90 días y los agentes seguirán intentando renovar este certificado entre el día 46 y el día 90. Para evitar que el certificado de identidad administrada expire, asegúrese de que el clúster esté en línea al menos una vez entre el día 46 y el día 90 para que se pueda renovar el certificado.

Si el certificado de identidad administrada expira, el recurso se considera Expired y todas las características de Azure Arc (como la configuración, la supervisión y la directiva) dejarán de funcionar en el clúster.

Para comprobar si el certificado de la identidad administrada está a punto de expirar para cualquier clúster especificado, ejecute el siguiente comando:

az connectedk8s show -n <name> -g <resource-group>

En la salida, el valor de managedIdentityCertificateExpirationTime indica cuándo expirará el certificado de identidad administrada (marca 90D para ese certificado).

Si el valor de managedIdentityCertificateExpirationTime indica una marca de tiempo del pasado, el campo connectivityStatus de la salida anterior se establecerá en Expired. En tales casos, para que el clúster de Kubernetes vuelva a funcionar con Azure Arc:

  1. Elimine el recurso y los agentes de Kubernetes habilitado para Azure Arc en el clúster.

    az connectedk8s delete -n <name> -g <resource-group>

  2. Vuelva a crear el recurso de Kubernetes habilitado para Azure Arc. Para hacerlo, implemente los agentes en el clúster.

    az connectedk8s connect -n <name> -g <resource-group>

Nota:

az connectedk8s delete también eliminará las configuraciones y las extensiones de clúster situadas sobre el clúster. Después de ejecutar az connectedk8s connect, vuelva a crear las configuraciones y las extensiones de clúster en el clúster, ya sea manualmente o mediante Azure Policy.

Si ya uso canalizaciones de CI/CD, ¿puedo seguir usando configuraciones y Kubernetes habilitado para Azure Arc y de GitOps?

Sí, todavía puede usar configuraciones en un clúster que recibe implementaciones a través de una canalización de CI/CD. En comparación con las canalizaciones de CI/CD tradicionales, las configuraciones de GitOps presentan ventajas adicionales.

Conciliación de desfase

La canalización de CI/CD aplica los cambios solo una vez durante la ejecución de la canalización. Sin embargo, el operador de GitOps del clúster sondea continuamente el repositorio de Git para capturar el estado deseado de los recursos de Kubernetes en el clúster. Si el operador de GitOps encuentra que el estado deseado de los recursos es diferente del estado real de los recursos en el clúster, se reconcilia este desfase.

Aplicación de GitOps a escala

Las canalizaciones de CI/CD son útiles para implementaciones controladas por eventos en el clúster de Kubernetes (por ejemplo, una inserción en un repositorio de Git). Sin embargo, para implementar la misma configuración en todos los clústeres de Kubernetes, configure manualmente las credenciales de cada clúster de Kubernetes en la canalización de CI/CD.

En el caso de Kubernetes habilitado para Azure Arc, como Azure Resource Manager administra las configuraciones de GitOps, puede automatizar la creación de la misma configuración en todos los recursos de Kubernetes habilitado para Azure Arc y de AKS mediante Azure Policy, en el ámbito de una suscripción o de un grupo de recursos. Esta funcionalidad es incluso aplicable a los recursos de Kubernetes habilitado para Azure Arc y AKS creados después de la asignación de directivas.

La característica aplica configuraciones de base de referencia (como directivas de red, enlaces de roles y directivas de seguridad de pods) en todo el inventario de clústeres de Kubernetes para satisfacer los requisitos de cumplimiento y gobernanza.

Cumplimiento de clústeres

El estado de cumplimiento de cada configuración de GitOps se notifica de nuevo a Azure. Esto le permite realizar un seguimiento de las implementaciones con errores.

¿Almacena Kubernetes habilitado para Azure Arc datos de los clientes fuera de la región del clúster?

La característica que permite almacenar los datos de clientes en una única región solo está disponible actualmente en la región de Sudeste Asiático (Singapur) de la geoárea Asia Pacífico y en la región Sur de Brasil (Estado de São Paulo) de la geoárea Brasil. En todas las demás regiones, los datos del cliente se almacenan en la geoárea. Esto es aplicable a las extensiones de Open Service Mesh habilitado para Azure Arc y del proveedor de secretos de Azure Key Vault compatibles con Kubernetes habilitado para Azure Arc. Para otras extensiones de clúster, consulte su documentación para obtener información sobre cómo almacenan los datos de los clientes. Para más información, consulte el Centro de confianza.

Pasos siguientes