Directivas de soporte técnico para Azure Kubernetes Service

En este artículo se describen las directivas de soporte técnico y las limitaciones 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 AKS.

Características administradas en AKS

AKS es una combinación de infraestructura como servicio (IaaS) y plataforma como servicio (PaaS). Los componentes en la nube de IaaS base, como los componentes de proceso o de red, permiten acceder a controles de bajo nivel y opciones de personalización. 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 a través del plano de control:

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

Algunos componentes, como los nodos del agente, tienen responsabilidad compartida, donde 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 managed en el sentido de que Microsoft y el equipo de AKS implementan, operan y son responsables de la disponibilidad y funcionalidad del servicio. 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 del agente ejecutan código privado y almacenan datos confidenciales, Soporte técnico de Microsoft solo pueden acceder a ellos de forma limitada. Soporte técnico de Microsoft no puede iniciar sesión, ejecutar comandos ni ver los registros de estos nodos sin su permiso o ayuda expresa.

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 del agente debe realizarse mediante mecanismos nativos de Kubernetes como .DaemonSet

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

Cobertura de soporte de AKS

En las secciones siguientes se describen los escenarios admitidos y no admitidos para el soporte técnico de AKS.

Escenarios admitidos

Microsoft proporciona soporte técnico para los ejemplos siguientes:

• Conectividad con todos los componentes de Kubernetes que el servicio Kubernetes proporciona y admite, como el servidor de API.
• Administración, tiempo de actividad, QoS y operaciones de servicios del plano de control de Kubernetes, como el servidor de API, etcd, y coreDNS.
• etcd almacén de datos. La compatibilidad incluye copias de seguridad automatizadas y transparentes de todos los etcd datos cada 30 minutos para la planeación ante desastres y la restauración del estado del clúster. Ni usted ni nadie puede acceder directamente a estas copias de seguridad. Garantizan la coherencia y confiabilidad de los datos. La reversión o restauración a petición no se admite como una característica.
• Cualquier punto de integración del controlador de proveedor de nube de Azure para Kubernetes. Estas incluyen integraciones en otros servicios de Azure, como equilibradores de carga, volúmenes persistentes o redes (Kubernetes y Azure CNI, excepto cuando se usa BYOCNI).
• Preguntas o problemas sobre la personalización de componentes del plano de control, como el servidor de API de Kubernetes, etcdy coreDNS.
• Problemas de redes, como Azure CNI, kubenet u otros problemas de acceso y funcionalidad 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 varios escenarios de red:
  • Kubenet y Azure CNI mediante redes virtuales administradas o con subredes personalizadas (traiga sus propias).
  • Conectividad con otros servicios y aplicaciones de Azure.
  • Controladores de entrada administrados por Microsoft o configuraciones del balanceador de carga.
  • Rendimiento y latencia de red.
  • Componentes y funcionalidades de las directivas de red gestionadas por Microsoft.

Las acciones de clúster realizadas por Microsoft/AKS se realizan con su consentimiento en un rol integrado de Kubernetes aks-service y enlace de roles integrado aks-service-rolebinding, que enlaza el rol a la identidad del servicio aks-support Soporte técnico de Microsoft. 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).

Escenarios no soportados

Microsoft no proporciona soporte técnico para los escenarios siguientes:

• Preguntas acerca de cómo usar Kubernetes. Por ejemplo, Soporte técnico de Microsoft no proporciona consejos sobre cómo crear controladores de entrada personalizados, usar cargas de trabajo de aplicaciones o aplicar paquetes o herramientas de software de código abierto o de terceros.

  Soporte técnico de Microsoft puede aconsejar sobre la funcionalidad, la personalización y el ajuste del clúster de AKS (por ejemplo, problemas y procedimientos de 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.

  Microsoft puede proporcionar soporte técnico lo mejor posible para proyectos de código abierto de terceros como Helm. Donde la herramienta de código abierto de terceros se integra con el proveedor de nube de Kubernetes Azure o en caso de problemas específicos de AKS, 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.

• Configurar o solucionar problemas de código específico de la aplicación o del comportamiento de aplicaciones o herramientas de terceros que se ejecuten dentro del clúster de AKS. Esto incluye problemas de implementación de aplicaciones no relacionados con la propia plataforma de AKS.

• Emisión, renovación o administración de certificados para aplicaciones que se ejecutan en AKS.

• Personalizaciones de red distintas de las que se enumeran en la documentación de AKS. Por ejemplo, Soporte técnico de Microsoft no pueden configurar dispositivos ni aplicaciones virtuales destinados a proporcionar tráfico saliente para el clúster de AKS, como VPN o firewalls.

  Según el principio de mejor esfuerzo, Soporte técnico de Microsoft puede aconsejar sobre la configuración necesaria para Azure Firewall, pero no para otros dispositivos de terceros.

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

• Configuración o solución de problemas de directivas de red no administradas Microsoft. Aunque se admite el uso de directivas de red, Soporte técnico de Microsoft no puede investigar problemas derivados de configuraciones de directivas de red personalizadas.

• Configurar o solucionar problemas de controladores de entrada no administrados por Microsoft, como nginx, kong, traefik, etc. Esto incluye abordar los problemas de funcionalidad que surgen después de operaciones específicas de AKS, como cuando un controlador de entrada deja de funcionar tras una actualización de versión de Kubernetes. Estos problemas pueden derivar de incompatibilidades entre la versión del controlador de entrada y la nueva versión de Kubernetes. Para una opción totalmente compatible, considere usar una opción de controlador de ingreso administrado por Microsoft.

• Configuración o solución de problemas DaemonSet (incluidos los scripts) usados para personalizar las configuraciones de nodo. Aunque el uso de DaemonSet es el enfoque recomendado para optimizar, modificar o instalar software de terceros en nodos de agente de clúster cuando configuración de parámetros de archivo no son suficientes, Soporte técnico de Microsoft no puede solucionar problemas derivados de los scripts personalizados usados en DaemonSet debido a su naturaleza personalizada.

• Escenarios independientes y proactivos. 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. Clientes elegibles pueden ponerse en contacto con el equipo de su cuenta para recibir el servicio de administración de eventos de Azure. Es un servicio de pago proporcionado por ingenieros de soporte técnico de Microsoft que incluye una evaluación de riesgos y cobertura proactiva durante los eventos.

• 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 disco duro virtual (VHD) y proporcionar listas filtradas al soporte técnico de Microsoft. Después de actualizar el disco duro virtual, 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 es así, el soporte técnico de Microsoft se asegurará de que se trabaje internamente y se aborden los componentes con una corrección por el 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. Por ejemplo, imágenes de nodo de AKS, imágenes de contenedor administradas para aplicaciones que se implementan durante la creación del clúster o mediante la instalación de un complemento administrado. Para obtener más información sobre la administración de vulnerabilidades para AKS, visite Administración de la vulnerabilidad para Azure Kubernetes Service (AKS).

• Ejemplos de código personalizados o scripts. Aunque Soporte técnico de Microsoft puede proporcionar pequeños ejemplos de código y revisiones de estos dentro de un incidente de soporte para demostrar cómo usar las características de un producto de Microsoft, Soporte técnico de Microsoft no puede proporcionar ejemplos de código personalizados específicos para su entorno o aplicación.

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

En las secciones siguientes se describen las responsabilidades de Microsoft y del cliente en los nodos de agentes de AKS.

Responsabilidades de Microsoft para los nodos de agente de AKS

Microsoft y tú comparten la responsabilidad de los nodos del agente de Kubernetes donde:

• La imagen base del sistema operativo tiene adiciones necesarias, como los agentes de supervisión y 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 ejecuten en los nodos de agente se remedian automáticamente. Estos componentes incluyen los siguientes elementos:
  • Kube-proxy
  • Túneles de red que proporcionan rutas de acceso de comunicación para los componentes maestros de Kubernetes
  • Kubelet
  • containerd

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

Responsabilidades del cliente sobre los nodos de agente de AKS

Microsoft proporciona revisiones y nuevas imágenes para los nodos de imagen semanalmente. Para mantener actualizados los componentes del sistema operativo y del runtime del nodo agente, debe aplicar estas revisiones y actualizaciones periódicamente de forma manual o automática. Microsoft no admite imágenes de nodo que tienen más de 90 días. Para más información, consulte:

• Actualice manualmente las imágenes de nodo de AKS.
• Actualice automáticamente las imágenes de nodo de AKS.

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

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 personalizar un conjunto de escalado de máquinas virtuales del grupo de nodos cambiando manualmente las configuraciones en el portal de Azure o desde la API.

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

El uso de contenedores de tipo DaemonSet y init con privilegios de Kubernetes permite a los clientes 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 recomienda esta ruta de acceso si se aplican los requisitos anteriores, la ingeniería y el soporte técnico de AKS no pueden ayudar a solucionar problemas ni diagnosticar modificaciones que dejan el nodo no disponible debido a una DaemonSet implementación personalizada.

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 los 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

Es posible que solo personalice los NSG en subredes personalizadas. Es posible que no personalice los grupos de seguridad de red 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 el ingreso, 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, que 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 desasignación manual de todos los nodos de clúster desde las API de IaaS, el CLI de Azure o el portal de Azure 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 del clúster etcd y puede reasignar fácilmente el clúster. Esta reasignación la inicia cualquier operación PUT que restaure el soporte del clúster, como una actualización o un escalamiento a 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 ninguna característica alfa que esté disponible en el proyecto de Kubernetes ascendente.

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

En el caso de las características y funcionalidades que requieren pruebas extendidas y comentarios de los usuarios, Microsoft publica nuevas características o características en versión preliminar detrás de una marca de características. 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 Azure Preguntas más frecuentes sobre soporte técnico.

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 parches más grandes en proyectos upstream (como Kubernetes, sistemas operativos de nodo o agente y kernel). En el caso de los componentes que Microsoft posee (como el proveedor de nube de Azure), AKS y el personal de Azure están comprometidos a corregir 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 reciben vínculos a los repositorios necesarios para que puedan ver los problemas y ver 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. La documentación sobre los problemas conocidos 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.