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 detalla la administración de nodos del agente, los componentes del plano de control administrados, los componentes que no son Microsoft de código abierto y la administración de revisiones o seguridad.

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, proporcionan acceso 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 limitadas de personalización e implementación y no administra los clústeres de Kubernetes directamente.

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:

• El servidor de la API de Kubernetes y kubelet.
• etcd o un almacén de clave-valor compatible, que proporciona calidad de servicio (QoS), escalabilidad y tiempo de ejecución.
• Servicios DNS como CoreDNS.
• kube-proxy y las redes de clúster, 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

Al crear un clúster, se definen los nodos del agente de Kubernetes que crea AKS. Las cargas de trabajo se ejecutan en estos nodos. Tenga en cuenta las siguientes restricciones del nodo de agente:

• Soporte técnico de Microsoft tiene acceso limitado. Dado que los nodos del agente ejecutan código privado y almacenan datos confidenciales, Soporte técnico de Microsoft no pueden iniciar sesión en, ejecutar comandos o ver los registros de estos nodos sin su permiso o ayuda expresa.
• Use mecanismos nativos de Kubernetes para los cambios. Cualquier modificación realizada directamente en los nodos del agente a través de las API de IaaS hace que el clúster no sea compatible. Aplique cambios mediante mecanismos nativos de Kubernetes como .DaemonSet
• No cambie los metadatos creados por el sistema. Puede añadir metadatos como etiquetas y rótulos, pero cambiar cualquier metadato creado por el sistema hace que el clúster deje de ser compatible.

División de responsabilidad

La siguiente matriz resume la responsabilidad de soporte en un clúster de AKS y compara AKS con Kubernetes autoadministrado que ejecuta localmente. En AKS, Microsoft administra el plano de control y la plataforma principal. Puede administrar la configuración del nodo, las cargas de trabajo, la configuración de red y los datos. Las áreas compartidas son aquellas en las que Microsoft proporciona y mantiene una funcionalidad y usted la habilita, configura o programa. Use la matriz como guía de un vistazo y, a continuación, consulte las secciones detalladas siguientes para obtener detalles de soporte técnico.

Use la siguiente clave para leer la matriz:

Para las áreas compartidas en la siguiente matriz, la tabla muestra lo que proporciona Microsoft y de qué es usted responsable:

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:

Cualquier acción de clúster llevada a cabo por Microsoft o AKS se realiza con su consentimiento en el marco de un rol integrado de Kubernetes aks-service y una vinculación de roles integrada aks-service-rolebinding, que vincula el rol a la identidad de servicio de aks-support Soporte técnico de Microsoft. Este rol permite a AKS solucionar y diagnosticar problemas de clúster, pero no puede modificar permisos ni crear roles o enlaces de roles, ni realizar otras acciones con 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.

Algunos de estos escenarios tienen más matices sobre lo que Microsoft todavía puede ayudar. Para obtener más información, consulte Detalles sobre escenarios no admitidos.

Detalles sobre escenarios no admitidos

Varios escenarios no admitidos han agregado matices sobre lo que Microsoft todavía puede ayudar con:

• Uso de Kubernetes. 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 no Microsoft. 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 que no Microsoft. Estos proyectos no se proporcionan como parte del plano de control de Kubernetes ni se implementan con clústeres de AKS y pueden incluir Istio, Helm, Envoy u otros. Microsoft puede proporcionar soporte según posibilidades para proyectos como Helm. En los casos en que la herramienta se integre con el proveedor de nube de Azure para Kubernetes o se trate de otros errores específicos de AKS, Microsoft ofrece soporte para los ejemplos y las aplicaciones de la documentación de Microsoft.
• Personalizaciones de red. En el caso de las personalizaciones distintas de las enumeradas en la documentación de AKS, Soporte técnico de Microsoft no puede configurar dispositivos ni aplicaciones virtuales destinadas a proporcionar tráfico saliente para el clúster, como VPN o firewalls. En función del mejor esfuerzo, Soporte técnico de Microsoft puede recomendar la configuración necesaria para Azure Firewall, pero no para otros dispositivos que no sean de Microsoft.
• Controladores de entrada que no son de Microsoft. En el caso de controladores como nginx, kongo traefik, esto incluye problemas de funcionalidad que surgen después de las operaciones específicas de AKS, como un controlador de entrada que deja de funcionar después de una actualización de la versión de Kubernetes, lo que podría derivar de incompatibilidades entre la versión del controlador de entrada y la nueva versión de Kubernetes. Para una opción con soporte completo, considere un controlador de entrada administrado por Microsoft.
• Scripts personalizados de DaemonSet. Aunque el uso DaemonSet es el enfoque recomendado para optimizar, modificar o instalar software que no sea de Microsoft en los nodos del agente cuando los parámetros del archivo de configuración no son suficientes, Soporte técnico de Microsoft no pueden solucionar problemas derivados de los scripts personalizados debido a su naturaleza personalizada.
• Soporte de guardia y proactivo. Soporte técnico de Microsoft proporciona soporte reactivo para resolver incidencias en curso. No se incluye el soporte de reserva o proactivo para eliminar riesgos operativos, aumentar la disponibilidad y optimizar el rendimiento. Los clientes elegibles pueden ponerse en contacto con el equipo de su cuenta para ser propuestos para Azure Event Management service, un servicio de pago que incluye una evaluación proactiva de riesgos de la solución y cobertura durante el evento.
• CV con menos de 30 días de antigüedad. Siempre que ejecutes el VHD actualizado, no deberías tener ninguna CVE en imágenes de contenedor con una corrección del proveedor de más de 30 días de antigüedad. Es su responsabilidad actualizar el VHD y, a continuación, filtrar el informe de CVE y proporcionar a Soporte técnico de Microsoft una lista únicamente de los CVE cuya corrección del proveedor tenga más de 30 días de antigüedad. Microsoft trabaja internamente a continuación para solucionar los componentes afectados con una corrección del proveedor publicada hace más de 30 días. Microsoft proporciona compatibilidad relacionada con CVE solo para componentes administrados por Microsoft, como imágenes de nodo de AKS y imágenes de contenedor administradas implementadas durante la creación del clúster o a través de un complemento administrado. Para obtener más información, consulte Administración de vulnerabilidades para Azure Kubernetes Service (AKS).
• Ejemplos de código personalizados. Soporte técnico de Microsoft puede proporcionar y revisar pequeños ejemplos de código dentro de un caso de soporte técnico para demostrar cómo usar características de un producto de Microsoft, pero no puede proporcionar ejemplos de código personalizados específicos de su entorno o aplicación.
• Lógica personalizada de Azure Policy. Soporte técnico de Microsoft puede proporcionar instrucciones generales sobre cómo se aplican y evalúan las definiciones de Azure Policy personalizadas en AKS. La solución de problemas detallada de la lógica de directivas creadas por el cliente (incluidas las directivas basadas en Rego), como por qué una directiva específica permite o deniega una carga de trabajo, normalmente está fuera del ámbito de soporte técnico.

Traiga sus propios límites de soporte técnico de CNI

Al implementar un clúster con bring your own CNI (BYOCNI) mediante --network-plugin none, Soporte técnico de Microsoft no puede ayudar con problemas relacionados con CNI. Usted es responsable del ciclo de vida del complemento de CNI y debe buscar soporte técnico del proveedor del complemento de CNI. Microsoft todavía da soporte a incidencias que no están relacionadas con el CNI.

Para obtener más información, consulte Bring your own CNI (BYOCNI).

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.

En la tabla siguiente se resumen las responsabilidades del nodo del agente de un vistazo. Las secciones siguientes proporcionan los detalles.

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.
• El sistema corrige automáticamente los problemas con los componentes del plano de control de Kubernetes que se ejecutan en los nodos del agente. Estos componentes incluyen los siguientes elementos:
  • kube-proxy
  • Túneles de red que proporcionan rutas de comunicación al plano de control 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. Para 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 Kubernetes con privilegios init y DaemonSet le permite ajustar o modificar, o instalar software que no es de Microsoft en 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 del agente y cambiarlos, no realice esta operación. Los cambios pueden hacer que un clúster no sea compatible.

Puertos de red, acceso y grupos de seguridad de red

Solo puede personalizar grupos de seguridad de red (NSG) en subredes personalizadas. En la tabla siguiente se muestra dónde puede personalizar los NSG:

AKS tiene requisitos de salida para puntos de conexión específicos. Para controlar la salida y garantizar la conectividad necesaria, consulte Limitar el tráfico de salida. Para ingress, los requisitos se basan en las aplicaciones que despliegas en el clúster.

Nodos detenidos, no asignados y sin preparar

En la tabla siguiente se resume lo que sucede con un clúster de AKS en cada estado del ciclo de vida y la escala de tiempo asociada:

Si no necesita que las cargas de trabajo de AKS se ejecuten continuamente, detenga el clúster de AKS, que detiene todos los grupos de nodos y el plano de control, e inícielo de nuevo cuando sea necesario. La desasignación manual de nodos mediante las API de IaaS, el CLI de Azure o el portal de Azure no es una manera compatible de detener un clúster.

AKS se reserva el derecho de archivar aviones de control configurados fuera de las directrices de soporte técnico durante períodos de 30 días o más. AKS mantiene copias de seguridad de los metadatos del clúster etcd y puede reasignar el clúster en cualquier operación PUT que lo devuelva a soporte técnico, como una actualización o escalado a nodos de agente activos.

Características de Kubernetes alfa y beta no admitidas

AKS admite características estables y beta en el proyecto de Kubernetes ascendente, pero no características alfa a menos que se documente lo contrario. En la tabla siguiente se resume la compatibilidad por tipo de característica:

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.

Contenido relacionado

• Planes de tarifa de AKS
• Versiones de Kubernetes compatibles en AKS
• Soporte a largo plazo para AKS
• Actualización automática de un clúster de AKS
• Actualizar automáticamente las imágenes del sistema operativo del nodo de AKS
• Administración de vulnerabilidades para AKS
• Reparación automática de nodos AKS
• Traiga su propia CNI (BYOCNI)