Directivas de soporte técnico para Azure Kubernetes Service

En este artículo se describen las directivas y limitaciones del soporte técnico de Azure Kubernetes Service (AKS). También se describen la administración de los nodos de agente, los componentes administrados del plano de control, los componentes de código abierto de terceros y la administración de la seguridad o las revisiones.

Actualizaciones de servicio y versiones

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

Características administradas en AKS

Los componentes base de la nube de infraestructura como servicio (IaaS), como los de proceso o red, proporcionan a los usuarios acceso a opciones de personalización y controles de nivel bajo. Por el contrario, AKS proporciona una implementación de Kubernetes inmediata que le ofrece un conjunto habitual de configuraciones y funcionalidades que necesita para su clúster. Como usuario de AKS, tiene opciones de personalización e implementación limitadas. A cambio, no tiene que preocuparse de administrar directamente los clústeres de Kubernetes.

Con AKS, obtiene un de plano de control totalmente administrado. El plano de control contiene todos los componentes y servicios necesarios para operar y entregar clústeres de Kubernetes a los usuarios finales. Microsoft mantiene y opera todos los componentes de Kubernetes.

Microsoft administra y supervisa los siguientes componentes mediante el panel de control:

• Servidores de la API de Kubernetes o Kubelet
• Etcd o un almacén de pares clave-valor compatible, que proporciona calidad de servicio (QoS), escalabilidad y tiempo de ejecución
• Servicios DNS (por ejemplo, kube-dns o CoreDNS)
• Redes o proxy de Kubernetes, excepto cuando se usa BYOCNI
• Cualquier complemento adicional o componente del sistema que se ejecute en el espacio de nombres del sistema de Kubernetes.

AKS no es una solución de plataforma como servicio (PaaS). Algunos componentes, como los nodos de agente, tienen responsabilidad compartida, por lo que debe ayudar a mantener el clúster de AKS. Se requiere la participación del usuario, por ejemplo, para aplicar una revisión de seguridad del sistema operativo en el nodo de agente.

Los servicios son administrados en el sentido en que Microsoft y el equipo de AKS implementan y operan el servicio, y son responsables de su disponibilidad y funcionalidad. Los clientes no pueden modificar estos componentes administrados. Microsoft limita la personalización para garantizar una experiencia de usuario coherente y escalable.

Responsabilidad compartida

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

Dado que los nodos de agente ejecutan código privado y almacenan información confidencial, el equipo de Soporte técnico de Microsoft solo puede acceder a ellos con restricciones. El equipo de Soporte técnico de Microsoft no puede iniciar sesión en estos nodos, ejecutar comandos en ellos ni ver sus registros sin el consentimiento expreso o la asistencia del cliente.

Cualquier modificación realizada directamente en los nodos de agente mediante cualquiera de las API de IaaS hace que el clúster sea incompatible. Cualquier modificación aplicada a los nodos de agente debe realizarse mediante mecanismos nativos de Kubernetes, como Daemon Sets.

Del mismo modo, aunque puede agregar metadatos al clúster y a los nodos, como etiquetas, si cambia cualquiera de los metadatos creados por el sistema, el clúster deja de ser compatible.

Cobertura de soporte de AKS

Microsoft proporciona soporte técnico para lo siguiente:

• Conectividad a todos los componentes de Kubernetes que el servicio Kubernetes proporciona y admite, como el servidor de API.
• La administración, el tiempo de actividad, la calidad de servicio y las operaciones de los servicios del plano de control de Kubernetes (por ejemplo, el plano de control de Kubernetes, el servidor de API, etcd y coreDNS).
• Almacén de datos etcd. La compatibilidad incluye las copias de seguridad automatizadas y transparentes de todos los datos de etcd cada 30 minutos para la restauración del estado del clúster y la planificación ante desastres. Ni usted ni nadie puede acceder directamente a estas copias de seguridad. Garantizan la coherencia y confiabilidad de los datos. La reversión a petición o la restauración no se admiten como una característica.
• Los puntos de integración en el controlador del proveedor de nube de Azure para Kubernetes. Estos incluyen las integraciones en otros servicios de Azure, como los equilibradores de carga, los volúmenes persistentes o las redes (Kubernetes y Azure CNI, excepto cuando BYOCNI está en uso).
• 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 relacionados con las redes, como Azure CNI, kubenet, u otros problemas de funcionalidades o acceso de red, excepto cuando BYOCNI está en uso. Podrían incluir los de resolución de DNS, pérdida de paquetes, enrutamiento, etc. Microsoft admite diversos escenarios de redes:
  • Kubenet y Azure CNI mediante redes virtuales administradas o con subredes personalizadas (modelo Traiga sus propias subredes).
  • Conectividad con otros servicios y aplicaciones de Azure
  • Controladores de entrada y las configuraciones del equilibrador de carga o de entrada
  • Rendimiento y latencia de la red
  • Directivas de red

Nota

Todas las acciones de clúster realizadas por Microsoft/AKS se realizan con su consentimiento en un rol de Kubernetes integrado aks-service y el enlace de roles integrado aks-service-rolebinding. Este rol permite a AKS solucionar problemas de clústeres, pero no puede modificar permisos ni crear roles, enlaces de roles ni otras acciones de privilegios elevados. El acceso a roles solo se habilita en incidencias de soporte técnico activos con acceso Just-in-Time (JIT).

Microsoft no proporciona soporte técnico para lo siguiente:

• 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

  El Soporte técnico de Microsoft puede aconsejar sobre la funcionalidad del clúster de AKS, la personalización y los ajustes (por ejemplo, los problemas y los 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 se implementan con clústeres de AKS. 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. Cuando la herramienta de código abierto de terceros integre el proveedor de nube de Azure de Kubernetes u otros errores específicos de AKS, Microsoft es compatible con 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 que se enumeran en la documentación de AKS.

• Complementos de CNI personalizados o de terceros que se usen en el modo BYOCNI.

• Escenarios independientes y proactivos. El soporte técnico de Microsoft proporciona soporte reactivo para ayudar a resolver problemas activos de forma oportuna y profesional. Sin embargo, el soporte técnico en espera o proactivo para ayudarle a eliminar los riesgos operativos, aumentar la disponibilidad y optimizar el rendimiento no están cubiertos. Los clientes aptos pueden ponerse en contacto con su equipo de cuenta para recibir la designación al servicio de Administración de eventos de Azure. Se trata de un servicio de pago ofrecido por ingenieros de soporte técnico de Microsoft que incluye una evaluación proactiva del riesgo de soluciones y cobertura durante el evento.

• Vulnerabilidades o CVE con una corrección del proveedor que tiene menos de 30 días de antigüedad. Siempre que ejecute el VHD actualizado, no debe ejecutar ninguna imagen de contenedor de CVE con una corrección del proveedor que tenga más de 30 días de antigüedad. Es responsabilidad del cliente actualizar el VHD y proporcionar listas filtradas al soporte técnico de Microsoft. Una vez actualizado el VHD, es responsabilidad del cliente filtrar los informes de vulnerabilidades o CVE y proporcionar una lista solo con vulnerabilidades o CVE con una corrección del proveedor que tenga más de 30 días de antigüedad. Si ese será el caso, el soporte técnico de Microsoft se asegurará de trabajar internamente y abordar los componentes con una corrección del proveedor publicada hace más de 30 días. Además, Microsoft proporciona compatibilidad relacionada con vulnerabilidades o CVE solo para componentes administrados por Microsoft (es decir, imágenes de nodo de AKS, imágenes de contenedor administradas para aplicaciones que se implementan durante la creación del clúster o a través de la instalación de un complemento administrado). Para más información sobre la administración de vulnerabilidades para AKS, visite esta página.

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

Responsabilidades de Microsoft sobre los nodos de agente de AKS

Microsoft y usted comparten la responsabilidad sobre los nodos de agente de Kubernetes en los que:

• La imagen del sistema operativo base ha requerido adiciones (por ejemplo, agentes de red y de supervisión).
• Los nodos de agente reciban automáticamente revisiones del sistema operativo.
• Los problemas con los componentes del plano de control de Kubernetes que se ejecuten en los nodos de agente se remedian automáticamente. Estos componentes incluyen lo siguiente:
  • Kube-proxy
  • Túneles de red que proporcionan rutas de acceso de comunicación para los componentes maestros de Kubernetes
  • Kubelet
  • containerd

Nota

Si un nodo de agente no está operativo, AKS podría reiniciar componentes individuales o todo el nodo de agente. Estas operaciones de reinicio se automatizan y proporcionan corrección automática de los problemas comunes. Si desea obtener más información sobre los mecanismos de corrección automática, consulte Reparación automática de nodo.

Responsabilidades del cliente sobre los nodos de agente de AKS

Microsoft proporciona revisiones y nuevas imágenes para los nodos de imagen semanalmente, pero no las revisará automáticamente de forma predeterminada. Para mantener los componentes del sistema operativo y del runtime del nodo de agente con las últimas revisiones, debe mantener una programación de actualizaciones de imagen de nodo periódicas o automatizarlas.

De forma similar, AKS lanza periódicamente nuevas revisiones de Kubernetes y versiones secundarias. Estas actualizaciones pueden contener mejoras de seguridad o funcionalidad para Kubernetes. Usted es el responsable de mantener actualizada la versión de Kubernetes de los clústeres y de acuerdo con la directiva de versión de compatibilidad con Kubernetes AKS.

Personalización de usuarios de nodos de agente

Nota

Los nodos de agente de AKS aparecen en Azure Portal como recursos de Azure IaaS estándar. Sin embargo, estas máquinas virtuales se implementan en un grupo de recursos de Azure personalizado (con el prefijo MC_*). No se puede cambiar la imagen de sistema operativo base ni realizar ninguna personalización directa en estos nodos mediante las API o los recursos de IaaS. Los cambios personalizados que no se realicen a través de la API de AKS no se conservarán en caso de actualización, escala o reinicio. Además, cualquier cambio en las extensiones de los nodos, como CustomScriptExtension, puede provocar un comportamiento inesperado y debe prohibirse. 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 administra el ciclo de vida y las operaciones de los nodos de agente en su nombre, por lo que no admite la modificación de los recursos de IaaS asociados a los nodos de agente. Un ejemplo de una operación no admitida es la personalización de un conjunto de escalado de máquinas virtuales del grupo de nodos mediante la modificación manual de las configuraciones en el Azure Portal o desde la API.

En el caso de las configuraciones o paquetes específicos de la carga de trabajo, AKS recomienda usar Kubernetes daemon sets.

El uso de contenedores de Kubernetes de iniciación y con privilegios daemon sets permite ajustar, modificar o instalar software de terceros en los nodos de agente del clúster. Algunos ejemplos de estas personalizaciones incluyen agregar software personalizado de examen de seguridad o actualizar la configuración de sysctl.

Aunque se trata de una ruta de acceso recomendada si se cumplen los requisitos anteriores, los servicios de ingeniería y soporte técnico de AKS no pueden ayudarle en la solución de problemas o en el diagnóstico de modificaciones que indiquen que el nodo no está disponible debido a un daemon set personalizado implementado.

Problemas de seguridad y aplicación de revisiones

Si se encuentra un error de seguridad en uno o más componentes administrados de AKS, el equipo de AKS revisa todos los clústeres afectados para mitigar el problema. Como alternativa, el equipo de AKS le proporciona instrucciones de actualización.

En el caso de los nodos de agente afectados por un error de seguridad, Microsoft le notifica con detalles sobre el impacto y los pasos para corregir o mitigar el problema de seguridad.

Acceso a los nodos y mantenimiento

Aunque puede iniciar sesión en los nodos de agente y cambiarlos, esto no es recomendable, ya que los cambios pueden hacer que un clúster deje de ser compatible.

Puertos de red, acceso y grupos de seguridad de red

Solo puede personalizar NSG en subredes personalizadas. No puede personalizar NSG en subredes administradas o en el nivel de NIC de los nodos del agente. AKS tiene requisitos de salida para puntos de conexión específicos, para controlar la salida y garantizar la conectividad necesaria; consulte Limitación del tráfico de salida. Para la entrada, los requisitos se basan en las aplicaciones que ha implementado en el clúster.

Nodos detenidos, no asignados y sin preparar

Si no necesita que las cargas de trabajo de AKS se ejecuten continuamente, puede detener el clúster de AKS, lo cual detiene todos los grupos de nodos y el plano de control. Puede volver a iniciarlo cuando sea necesario. Si detiene un clúster mediante el comando az aks stop, el estado del clúster se conserva durante un máximo de 12 meses. Después de 12 meses, se eliminan el estado del clúster y todos sus recursos.

No se admite la anulación manual de todos los nodos de clúster desde las API de IaaS, la CLI de Azure o Azure Portal para detener un clúster de AKS o un grupo de nodos. El clúster se considerará fuera de soporte técnico y AKS lo detendrá después de 30 días. Los clústeres están sujetos a la misma directiva de conservación de 12 meses que un clúster detenido correctamente.

Los clústeres con cero nodos Preparados (o todos Sin preparar) y cero máquinas virtuales En ejecución se detendrán después de 30 días.

AKS se reserva el derecho de archivar los planos de control que se han configurado fuera de las directrices de compatibilidad durante períodos prolongados iguales o superiores a 30 días. AKS mantiene copias de seguridad de los metadatos de etcd del clúster y puede reasignar fácilmente el clúster. Esta reasignación se inicia con cualquier operación PUT haciendo que el clúster vuelva a ser compatible, como una actualización o un escalado a los nodos de agente activos.

Todos los clústeres de una suscripción suspendida se detendrán inmediatamente y se eliminarán después de 90 días. Todos los clústeres de una suscripción eliminada se eliminarán inmediatamente.

Características de Kubernetes alfa y beta no admitidas

Dentro del proyecto de Kubernetes ascendente, AKS solo admite características estables. A menos que se documente lo contrario, AKS no admite características alfa que estén disponibles 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 requieran 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. Considere estas características como versión preliminar o características 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 se encuentran en asistencia al mejor esfuerzo , ya que estas características están en versión preliminar y no están pensadas para la producción. Los equipos de soporte técnico de AKS solo proporcionan soporte técnico durante el horario comercial. Para obtener más información, consulte las preguntas más frecuentes de 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 o solucionar dentro del sistema de AKS. 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). Para los componentes que pertenecen a Microsoft (por ejemplo, el proveedor de nube de Azure), el personal de AKS y Azure se comprometen a solucionar los problemas ascendentes en la comunidad.

Cuando la causa principal de un problema de soporte técnico se debe a uno o más errores ascendentes, los equipos de soporte técnico e ingeniería de AKS:

• 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 el archivo de problemas conocidos se explica:

  • El problema, con vínculos a los errores ascendentes.
  • La solución y los detalles sobre una actualización u otra manera de que la solución persista.
  • Escalas de tiempo aproximadas de la inclusión del problema en función de la cadencia de la versión ascendente.