Compartir a través de

Directivas de soporte técnico para AKS habilitadas por Azure Arc

  • Artículo

Se aplica a: AKS en Azure Stack HCI 22H2, AKS en Windows Server

En este artículo se proporcionan detalles sobre las directivas de soporte técnico y las limitaciones de AKS habilitados por Arc. En el artículo también se describe la administración de nodos de clúster, los componentes del plano de control, los componentes de código abierto de terceros y la administración de revisiones o seguridad.

Actualizaciones de servicio y versiones

  • Microsoft ofrece una ventana de soporte técnico de 1 año para cada versión secundaria de Kubernetes, empezando por la fecha de lanzamiento inicial. Durante este período, AKS Arc publica versiones secundarias o de revisión posteriores para garantizar la compatibilidad continua.
  • Un clúster de Kubernetes que funciona en una versión secundaria en desuso debe actualizarse a una versión compatible para poder admitirse.
  • Una vez que una versión secundaria está en desuso, los clústeres que todavía se ejecutan en esta versión seguirán funcionando. Todavía puede realizar operaciones como escalar o reducir verticalmente, pero AKS Arc muestra una advertencia durante las operaciones del clúster.
  • Una vez que una versión secundaria está en desuso, se quita de los servidores de Microsoft. En ese momento, los clústeres de Kubernetes que usan esta versión no pueden actualizar las versiones de Kubernetes o del sistema operativo y deben actualizarse a la versión más reciente. En algunos casos, esta actualización también puede significar una nueva implementación completa si el sistema no está en un estado correcto.

Para obtener información sobre la versión, consulte las notas de la versión de AKS Arc. Para obtener información sobre las características de la versión preliminar, consulte Características en versión preliminar de AKS Arc.

Características administradas en AKS Arc

Como usuario de AKS Arc, tiene opciones limitadas de personalización e implementación. Sin embargo, no es necesario preocuparse ni administrar directamente el plano de control y la instalación del clúster de Kubernetes. Los componentes de nube de infraestructura como servicio (IaaS) base, como los componentes de proceso o de red, permiten acceder a opciones de personalización y controles de bajo nivel.

Por el contrario, AKS Arc proporciona una implementación de Kubernetes llave en mano que proporciona el conjunto común de configuraciones y funcionalidades que necesita para el clúster. Con AKS Arc, obtiene un plano de control parcialmente administrado. El plano de control contiene todos los componentes y servicios que debe ofrecer y proporciona clústeres de Kubernetes para los usuarios finales. Microsoft mantiene todos los componentes de Kubernetes.

Microsoft mantiene los siguientes componentes a través del clúster de administración y las imágenes base de máquina virtual asociadas:

  • kubelet o servidores de API de Kubernetes.
  • etcd o un almacén de clave-valor compatible, que proporciona calidad de servicio (QoS), escalabilidad y tiempo de ejecución.
  • Servicios DNS (por ejemplo, kube-dns o CoreDNS).
  • Proxy o red de Kubernetes.
  • Cualquier otro complemento o componente del sistema que se ejecute en el kube-system espacio de nombres.

AKS Arc no es una solución de plataforma como servicio (PaaS). Algunos componentes, como los clústeres de cargas de trabajo, el plano de control y los nodos de trabajo, tienen responsabilidad compartida. Los usuarios deben ayudar a mantener el clúster de Kubernetes. La entrada del usuario es necesaria, por ejemplo, para aplicar una revisión de seguridad del sistema operativo (SO) o para la actualización a una versión más reciente de Kubernetes.

Los servicios se administran en el sentido de que Microsoft y el equipo de AKS proporcionan las herramientas que implementan el clúster de administración, el plano de control y los nodos del agente para los clústeres de cargas de trabajo. No se pueden modificar estos componentes administrados. Microsoft limita la personalización para garantizar una experiencia de usuario coherente y escalable. Para obtener una solución totalmente personalizable en la nube, consulte el motor de AKS.

Directiva de versión admitida

Las versiones de Kubernetes en AKS Arc siguen la directiva de versión de Kubernetes.

AKS Arc no garantiza ningún entorno de ejecución (u otro) para los clústeres fuera de la lista de versiones admitidas. "Fuera del soporte técnico" significa que:

  • El clúster funciona en una versión secundaria en desuso. La versión que utiliza está fuera de la lista de versiones admitidas.
  • Se le pide que actualice el clúster a una versión compatible al solicitar soporte técnico.

Para obtener información sobre las versiones de Kubernetes admitidas, consulte Versiones admitidas de Kubernetes.

AKS Arc sigue los períodos de tiempo de soporte técnico de la versión de la plataforma para esos productos. Es decir, AKS Arc no se admite en versiones no admitidas de esos productos. Para obtener más información, consulte sus directivas de soporte técnico:

Responsabilidad compartida

Cuando se crea un clúster, se definen los nodos del agente de Kubernetes que crea AKS Arc. Las cargas de trabajo se ejecutan en esos nodos.

Dado que los nodos del agente ejecutan código privado y almacenan datos confidenciales, Soporte técnico de Microsoft tiene acceso limitado a ellos. Soporte técnico de Microsoft no puede iniciar sesión para ejecutar comandos ni ver los registros de estos nodos sin su permiso o ayuda expresa. Cualquier modificación directa de los nodos del agente mediante cualquiera de las API de IaaS hace que el clúster no sea compatible. Cualquier modificación realizada en los nodos del agente debe realizarse mediante mecanismos nativos de Kubernetes, como Daemon Sets.

Del mismo modo, aunque puede agregar metadatos, como etiquetas y etiquetas, al clúster y a los nodos, al cambiar cualquiera de los metadatos creados por el sistema, el clúster no es compatible.

Cobertura de soporte técnico de AKS Arc

Microsoft proporciona soporte técnico para las siguientes características y componentes:

  • Conectividad a todos los componentes de Kubernetes que el servicio Kubernetes proporciona y admite, como el servidor de API.
  • Servicios del plano de control de Kubernetes (por ejemplo, plano de control de Kubernetes, servidor de API, etcd y coreDNS).
  • Almacén de datos etcd.
  • Integración con Azure Arc y el servicio de facturación de Azure.
  • Preguntas o problemas sobre la personalización de los componentes del plano de control, como el servidor de API de Kubernetes, etcd y coreDNS.
  • Problemas con las redes, el acceso a la red y la funcionalidad. Los problemas podrían incluir la resolución dns, la pérdida de paquetes y el enrutamiento. Microsoft admite diversos escenarios de redes:
    • Compatibilidad de instalación básica con Flannel y Calico CNI. Estos CNI están controlados por la comunidad y se admiten. Soporte técnico de Microsoft solo proporciona compatibilidad básica de instalación y configuración.
    • Conectividad con otros servicios y aplicaciones de Azure.
    • Controladores de entrada y configuración del equilibrador de carga o entrada.
    • Rendimiento y latencia de red.

Nota:

Las acciones de clúster realizadas por los equipos de soporte técnico de Microsoft AKS Arc se realizan con consentimiento y asistencia del usuario. Soporte técnico de Microsoft no inicia sesión en el clúster a menos que configure el acceso para el ingeniero de soporte técnico.

Microsoft no proporciona soporte técnico para las siguientes áreas:

  • Preguntas acerca de cómo usar Kubernetes. Por ejemplo, el Soporte técnico de Microsoft no aconseja sobre la creación controladores de entrada personalizados, el uso de cargas de trabajo de aplicación o la aplicación de herramientas o paquetes de software de código abierto de terceros.

    Nota:

    Soporte técnico de Microsoft puede aconsejar sobre la funcionalidad, la personalización y el ajuste del clúster en AKS Arc; por ejemplo, los problemas y procedimientos de las operaciones de Kubernetes.

  • Proyectos de código abierto de terceros que no se proporcionan como parte del plano de control de Kubernetes o implementados cuando se crean clústeres en AKS Arc. Estos proyectos pueden incluir Istio, Helm, Envoy u otros.

    Nota:

    Microsoft puede hacer lo posible por ayudar con proyectos de código abierto de terceros como Helm. Donde la herramienta de código abierto de terceros se integra con Kubernetes u otros errores específicos de AKS Arc, Microsoft admite ejemplos y aplicaciones de la documentación de Microsoft.

  • Software de código cerrado de terceros. Este software puede incluir herramientas de análisis de seguridad y dispositivos o software de red.

  • Personalizaciones de red distintas de las enumeradas en la documentación de AKS Arc.

Cobertura de soporte técnico de AKS Arc para nodos de agente

Responsabilidades de Microsoft para los nodos del agente de AKS Arc

Microsoft y los clientes comparten la responsabilidad sobre los nodos de agente de Kubernetes donde:

  • La imagen base del sistema operativo requiere adiciones (como la supervisión y los agentes de red).
  • Los nodos de agente reciban automáticamente revisiones del sistema operativo.
  • Los problemas con los componentes del plano de control de Kubernetes que se ejecutan en los nodos de agente se corrigen automáticamente durante el ciclo de actualización o al reimplementarse el nodo de agente. Estos componentes incluyen:
    • kube-proxy
    • Túneles de red que proporcionan rutas de comunicación a los componentes maestros de Kubernetes:
      • kubelet
      • Moby o ContainerD

Nota:

Si un nodo del agente no está operativo, AKS Arc podría reiniciar componentes individuales o todo el nodo del agente. Estas operaciones de reinicio automatizado proporcionan corrección automática para problemas comunes.

Responsabilidades del cliente para los nodos del agente de AKS Arc

Microsoft proporciona revisiones y nuevas imágenes para los nodos de imagen mensualmente, pero no las revisará automáticamente de forma predeterminada. Para mantener el sistema operativo del nodo de agente y los componentes en tiempo de ejecución revisados, debe mantener una programación de actualización normal o automatizar la aplicación de revisiones.

De forma similar, AKS Arc publica periódicamente nuevas revisiones de Kubernetes y versiones secundarias. Estas actualizaciones pueden contener mejoras de seguridad o funcionalidad para Kubernetes. Es responsable de mantener actualizada la versión de Kubernetes del clúster según la directiva de versiones admitidas de AKS Arc.

Personalización de usuarios de nodos de agente

Nota:

Los nodos del agente de AKS Arc aparecen en Hyper-V como recursos de máquina virtual normales. Estas máquinas virtuales se implementan con una imagen personalizada del sistema operativo y los componentes de Kubernetes administrados y compatibles. No se puede cambiar la imagen de sistema operativo base ni realizar personalizaciones directas en estos nodos mediante las API o los recursos de Hyper-V. Los cambios personalizados que no se realicen a través de la API de AKS-HCI no se conservan a través de una actualización, escala, actualización o reinicio, y pueden representar el clúster no admitido. Evite realizar cambios en los nodos de agente a menos que el equipo de Soporte técnico de Microsoft le indique que realice cambios.

AKS Arc administra el ciclo de vida y las operaciones de las imágenes de nodo del agente en su nombre. No se admite la modificación de los recursos asociados a los nodos del agente. Por ejemplo, no se admite la personalización de la configuración de red de una máquina virtual cambiando manualmente las configuraciones a través de la API o herramientas de Hyper-V.

Para configuraciones o paquetes específicos de la carga de trabajo, debe usar conjuntos de demonios de Kubernetes.

Al usar contenedores con privilegios daemon sets e iniciales de Kubernetes, puede optimizar o modificar o instalar software de terceros en nodos del agente de clúster. Por ejemplo, puede agregar software de examen de seguridad personalizado o configuración de actualización sysctl . Aunque se recomienda esta ruta de acceso si se aplican los requisitos anteriores, la ingeniería y el soporte técnico de AKS Arc no pueden ayudar a solucionar problemas ni diagnosticar modificaciones que representan el nodo no disponible debido a una implementación daemon setpersonalizada.

Problemas de seguridad y aplicación de revisiones

Si se encuentra un error de seguridad en uno o varios de los componentes administrados de AKS Arc, el equipo de AKS Arc aplica revisiones a todas las imágenes de sistema operativo afectadas para mitigar el problema y el equipo proporciona instrucciones de actualización a los usuarios.

En el caso de los nodos de agente afectados por un error de seguridad, Microsoft le notifica los detalles sobre el impacto y los pasos para corregir o mitigar el problema de seguridad. Normalmente, los pasos incluyen una actualización de imagen de nodo o una actualización de revisión de clúster.

Acceso a los nodos y mantenimiento

Aunque puede iniciar sesión y cambiar los nodos del agente, no se recomienda esta operación porque los cambios pueden hacer que un clúster no sea compatible.

Puertos de red, grupos de DIRECCIONES IP y acceso

Solo puede personalizar la configuración de red mediante subredes definidas por AKS Arc. No se puede personalizar la configuración de red en el nivel de NIC de los nodos del agente. AKS Arc tiene requisitos de salida para puntos de conexión específicos, para controlar la salida y garantizar la conectividad necesaria. Para más información, consulte Requisitos del sistema de AKS Arc.

Clústeres detenidos o desconectados

Como se ha descrito anteriormente, desasignar manualmente todos los nodos de clúster a través de las API de Hyper-V, la CLI o MMC hace que el clúster no sea compatible.

Los clústeres detenidos durante más de 90 días ya no se pueden actualizar. Los planos de control de los clústeres de este estado no son compatibles después de 30 días y no se pueden actualizar a la versión más reciente.

El clúster de administración de AKS Arc debe poder conectarse a Azure a través del tráfico saliente HTTPS a puntos de conexión de Azure conocidos al menos cada 30 días para mantener las operaciones del día 2, como la actualización y el escalado del grupo de nodos. Si el clúster de administración está desconectado dentro del período de 30 días, las cargas de trabajo seguirán ejecutándose y funcionan según lo previsto hasta que el clúster de administración y o Azure Local vuelvan a conectarse y sincronizarse con Azure. Una vez que se vuelva a conectar, todas las operaciones del día 2 deben recuperarse y continuar según lo previsto. Consulte Requisitos de conectividad de Azure local de Azure para más información. Después de 30 días, Azure Local impide la creación de nuevas máquinas virtuales.

Si el clúster se ejecuta en Windows Server 2019 o Windows Server 2022, la plataforma host subyacente no tiene el requisito de conexión periódica de 30 días.

Nota:

El inicio o el final del período de 30 días puede ser diferente del período de validez en AKS Arc y Azure Local. Detener o desasignar manualmente todos los nodos de clúster a través de las API de Hyper-V,CLI/MMC durante períodos prolongados superiores a 30 días y fuera de los procedimientos de mantenimiento normales hace que el clúster no sea compatible.

Suscripción eliminada o suspendida

Si la suscripción de Azure se suspende o elimina, los clústeres de AKS no son compatibles después de 60 días, a menos que se restablezca la suscripción antes de alcanzar el límite de 60 días. También se aplican todas las demás limitaciones descritas anteriormente. Una vez eliminada la suscripción, la conexión de clúster a Azure no se puede recuperar y Azure Local y AKS Arc deben volver a implementarse para poder volver a conectarse a Azure.

Características de Kubernetes en versión preliminar y beta no admitidas

AKS Arc solo admite características estables y beta en el proyecto de Kubernetes ascendente. A menos que se documente lo contrario, AKS Arc no admite ninguna característica de versión preliminar que esté disponible en el proyecto de Kubernetes ascendente.

Características en versión preliminar o marcas de característica

Para las características y la funcionalidad que requieren pruebas ampliadas y comentarios de los usuarios, Microsoft publica nuevas características en versión preliminar o características con una marca de característica. Tenga en cuenta estas características preliminares o beta. Las características en versión preliminar o con marca de característica no son para producción. Los cambios continuos en las API y el comportamiento, las soluciones de errores y otros cambios pueden dar lugar a inestabilidad en los clústeres y tiempo de inactividad.

Las características de la versión preliminar pública reciben compatibilidad con "mejor esfuerzo", ya que estas características están en versión preliminar y no están pensadas para producción. Estas características solo son compatibles con los equipos de soporte técnico de AKS Arc durante el horario comercial. Para obtener más información, consulte las preguntas más frecuentes sobre Soporte técnico de Azure.

Problemas y errores ascendentes

Dada la velocidad de desarrollo del proyecto ascendente de Kubernetes, siempre se producen errores. Algunos de estos errores no se pueden revisar ni solucionar en el sistema AKS Arc. En su lugar, las correcciones de errores requieren mayores revisiones en los proyectos ascendentes (como Kubernetes, los sistemas operativos del nodo o de agente y kernels). En el caso de los componentes que Microsoft posee (como los proveedores de API de clúster para Azure Local), el personal de AKS Arc y Azure se compromete a corregir problemas ascendentes en la comunidad.

Cuando un problema de soporte técnico está causado por uno o varios errores ascendentes, los equipos de soporte técnico e ingeniería de AKS Arc harán lo siguiente:

  • Identificarán y vincularán los errores ascendentes con detalles que lo justifiquen para intentar explicar por qué afecta al clúster o a la carga de trabajo. Los clientes recibirán vínculos a los repositorios necesarios para que puedan consultar los problemas y cuándo una nueva versión proporciona correcciones.
  • Proporcionarán posibles soluciones alternativas o mitigaciones. Si se puede mitigar el problema, se archiva un problema conocido en el repositorio de AKS en Azure Local y Windows Server. La presentación de problemas conocidos explica:
    • El problema, con vínculos a los errores ascendentes.
    • Solución alternativa y detalles sobre una actualización u otra opción para la solución.
    • Escalas de tiempo aproximadas de la inclusión del problema en función de la cadencia de la versión ascendente.

Pasos siguientes