Revisión del Marco de buena arquitectura de Azure : Azure Kubernetes Service (AKS)

  • Artículo

En este artículo se proporcionan procedimientos recomendados de arquitectura para Azure Kubernetes Service (AKS). La guía se basa en los cinco pilares de excelencia de la arquitectura:

  • Confiabilidad
  • Seguridad
  • Optimización de costos
  • Excelencia operativa
  • Eficiencia del rendimiento

Suponemos que comprende los principios de diseño del sistema, tiene conocimientos prácticos de Azure Kubernetes Service y está bien familiarizado con sus características. Para más información, vea Azure Kubernetes Service.

Requisitos previos

Comprender los pilares de Well-Architected Framework puede ayudar a producir una arquitectura en la nube de alta calidad, estable y eficaz. Se recomienda revisar la carga de trabajo mediante la evaluación de revisión de Azure Well-Architected Framework .

Para el contexto, considere la posibilidad de revisar una arquitectura de referencia que refleje estas consideraciones en su diseño. Se recomienda empezar con la arquitectura de línea base para un clúster de Azure Kubernetes Service (AKS) y una arquitectura de microservicios en Azure Kubernetes Service. Revise también el acelerador de zonas de aterrizaje de AKS, que proporciona un enfoque arquitectónico y una implementación de referencia para preparar las suscripciones de zona de aterrizaje para un clúster de Azure Kubernetes Service escalable (AKS).

Confiabilidad

En la nube, reconocemos que se producen errores. En lugar de intentar evitar todos los errores, el objetivo es minimizar los efectos que pueden provocar los errores de un único componente. Use la siguiente información para minimizar las instancias con errores.

Al analizar la confiabilidad con Azure Kubernetes Service, es importante distinguir entre la confiabilidad del clúster y la confiabilidad de la carga de trabajo. La confiabilidad del clúster es una responsabilidad compartida entre el administrador del clúster y su proveedor de recursos, mientras que la confiabilidad de la carga de trabajo es el dominio de un desarrollador. Azure Kubernetes Service tiene consideraciones y recomendaciones para ambos roles.

En la lista de comprobación de diseño y la lista de recomendaciones siguientes, se realizan llamadas para indicar si cada opción es aplicable a la arquitectura del clúster, a la arquitectura de carga de trabajo o a ambas.

Diseño de una lista de comprobación

  • Arquitectura del clúster: Para cargas de trabajo críticas, use zonas de disponibilidad para los clústeres de AKS.
  • Arquitectura del clúster: Planee el espacio de direcciones IP para asegurarse de que el clúster puede escalar de forma confiable, incluido el control del tráfico de conmutación por error en topologías de varios clústeres.
  • Arquitectura del clúster: Habilite Container Insights para supervisar el clúster y configurar alertas para eventos que afectan a la confiabilidad.
  • Arquitectura de carga de trabajo: Asegúrese de que las cargas de trabajo están creadas para admitir el escalado horizontal y notificar la preparación y el estado de las aplicaciones.
  • Arquitecturas de clúster y carga de trabajo: Asegúrese de que la carga de trabajo se ejecuta en grupos de nodos de usuario y elija la SKU de tamaño correcta. Como mínimo, incluya dos nodos para grupos de nodos de usuario y tres nodos para el grupo de nodos del sistema.
  • Arquitectura del clúster: Use el Acuerdo de Nivel de Servicio de tiempo de actividad de AKS para cumplir los objetivos de disponibilidad de las cargas de trabajo de producción.

Recomendaciones de configuración de AKS

Explore la tabla siguiente de recomendaciones para optimizar la configuración de AKS para confiabilidad.

Recomendación Prestación
Arquitecturas de clúster y carga de trabajo: Controlar la programación de pods mediante selectores de nodo y afinidad. Permite que el programador de Kubernetes aísle lógicamente las cargas de trabajo mediante hardware en el nodo. A diferencia de las tolerancias, los pods sin un selector de nodo coincidente se pueden programar en nodos etiquetados, lo que permite que los recursos no usados de los nodos consuman, pero da prioridad a los pods que definen el selector de nodos coincidente. Use la afinidad de nodo para más flexibilidad, lo que le permite definir lo que sucede si el pod no puede coincidir con un nodo.
Arquitectura del clúster: Asegúrese de seleccionar correctamente el complemento de red en función de los requisitos de red y el tamaño del clúster. Azure CNI es necesario para escenarios específicos, por ejemplo, grupos de nodos basados en Windows, requisitos de red específicos y directivas de red de Kubernetes. Consulte Kubenet frente a Azure CNI para más información.
Arquitecturas de clúster y carga de trabajo: Use el Acuerdo de Nivel de Servicio de tiempo de actividad de AKS para los clústeres de nivel de producción. El contrato de nivel de servicio de tiempo de actividad de AKS garantiza lo siguiente:
- Disponibilidad del 99.95% del punto de conexión del servidor de API de Kubernetes para los clústeres que usan Availability Zones.
- Disponibilidad del 99.9% para clústeres de AKS que no usan Azure Availability Zones.
Arquitecturas de clúster y carga de trabajo: Configure la supervisión del clúster con Container Insights. Container Insights ayuda a supervisar el estado y el rendimiento de los controladores, nodos y contenedores que están disponibles en Kubernetes a través de Metrics API. La integración con Prometheus permite la recopilación de métricas de aplicaciones y cargas de trabajo.
Arquitectura del clúster: Use zonas de disponibilidad para maximizar la resistencia dentro de una región de Azure mediante la distribución de nodos de agente de AKS entre centros de datos físicamente independientes. Al distribuir grupos de nodos entre varias zonas, los nodos de un grupo de nodos seguirán ejecutándose aunque otra zona haya caído. Si existen requisitos de coubicación, se puede usar una implementación normal de AKSS basada en VMSS en una sola zona o grupos de selección de ubicación de proximidad para minimizar la latencia interno.
Arquitectura del clúster: Adopte una estrategia de varias regiones mediante la implementación de clústeres de AKS implementados en diferentes regiones de Azure para maximizar la disponibilidad y proporcionar continuidad empresarial. Las cargas de trabajo accesibles desde Internet deben aprovechar Azure Front Door o Azure Traffic Manager para enrutar el tráfico globalmente entre clústeres de AKS.
Arquitecturas de clúster y carga de trabajo: Defina las solicitudes de recursos de pod y los límites en los manifiestos de implementación de aplicaciones y aplique con Azure Policy. Los límites de recursos de memoria y CPU del contenedor son necesarios para evitar el agotamiento de recursos en el clúster de Kubernetes.
Arquitecturas de clúster y carga de trabajo: Mantenga el grupo de nodos del sistema aislado de las cargas de trabajo de la aplicación. Los grupos de nodos del sistema requieren una SKU de máquina virtual de al menos 2 vCPU y 4 GB de memoria, pero se recomienda 4 vCPU o más. Consulte Grupos de nodos del sistema y del usuario para conocer los requisitos detallados.
Arquitecturas de clúster y carga de trabajo: Separe las aplicaciones de los grupos de nodos dedicados en función de los requisitos específicos. Las aplicaciones pueden compartir la misma configuración y necesitan máquinas virtuales habilitadas para GPU, máquinas virtuales optimizadas para CPU o memoria, o la capacidad de escalar a cero. Evite un gran número de grupos de nodos para reducir la sobrecarga de administración adicional.
Arquitectura del clúster: Use una puerta de enlace NAT para clústeres que ejecutan cargas de trabajo que realizan muchas conexiones salientes simultáneas. Para evitar problemas de confiabilidad con Azure Load Balancer limitaciones con un tráfico saliente simultáneo elevado, en su lugar, una puerta de enlace NAT para admitir tráfico de salida confiable a escala.

Para obtener más sugerencias, consulte Principios del pilar de confiabilidad.

Azure Policy

Azure Kubernetes Service ofrece una amplia variedad de directivas de Azure integradas que se aplican tanto al recurso de Azure como a las directivas típicas de Azure, como a las directivas típicas de Azure, mediante el complemento Azure Policy para Kubernetes, también dentro del clúster. Hay una gran cantidad de directivas y aquí se resumen las directivas clave relacionadas con este pilar. Para obtener una vista más detallada, consulte Definiciones de directivas integradas para Kubernetes.

Arquitectura de clúster y carga de trabajo

Además de las definiciones de Azure Policy integradas, se pueden crear directivas personalizadas para el recurso de AKS y para el complemento Azure Policy para Kubernetes. Esto le permite agregar restricciones de confiabilidad adicionales que le gustaría aplicar en el clúster y la arquitectura de carga de trabajo.

Seguridad

La seguridad constituye uno de los aspectos más importantes de cualquier arquitectura. Para explorar cómo AKS puede reforzar la seguridad de la carga de trabajo de la aplicación, se recomienda revisar los principios de diseño de seguridad. Si el clúster de Azure Kubernetes Service debe diseñarse para ejecutar una carga de trabajo confidencial que cumpla los requisitos normativos del estándar de seguridad de datos del sector de tarjetas de pago (PCI-DSS 3.2.1), revise el clúster regulado de AKS para PCI-DSS 3.2.1.

Para obtener información sobre la compatibilidad y los requisitos del nivel de impacto 5 (IL5) de DoD con AKS, revise Azure Government requisitos de aislamiento il5.

Al analizar la seguridad con Azure Kubernetes Service, es importante distinguir entre la seguridad del clúster y la seguridad de las cargas de trabajo. La seguridad del clúster es una responsabilidad compartida entre el administrador del clúster y su proveedor de recursos, mientras que la seguridad de la carga de trabajo es el dominio de un desarrollador. Azure Kubernetes Service tiene consideraciones y recomendaciones para ambos roles.

En la lista de comprobación de diseño y la lista de recomendaciones siguientes, se realizan llamadas para indicar si cada opción es aplicable a la arquitectura del clúster, a la arquitectura de carga de trabajo o a ambas.

Diseño de una lista de comprobación

  • Arquitectura del clúster: Use identidades administradas para evitar administrar y rotar los principios del servicio.
  • Arquitectura del clúster: Use el control de acceso basado en rol (RBAC) de Kubernetes con Microsoft Entra ID para el acceso con privilegios mínimos y minimice la concesión de privilegios de administrador para proteger la configuración y el acceso a secretos.
  • Arquitectura del clúster: Use Microsoft Defender para contenedores con Azure Sentinel para detectar y responder rápidamente a amenazas en el clúster y las cargas de trabajo que se ejecutan en ellos.
  • Arquitectura del clúster: Implemente un clúster de AKS privado para asegurarse de que el tráfico de administración de clústeres al servidor de API permanece en la red privada. O bien, use la lista de permitidos del servidor de API para clústeres no privados.
  • Arquitectura de carga de trabajo: Use un Web Application Firewall para proteger el tráfico HTTP(S).
  • Arquitectura de carga de trabajo: Asegúrese de que la canalización de CI/CID está protegida con el examen compatible con contenedores.

Recomendaciones

Explore la tabla siguiente de recomendaciones para optimizar la configuración de AKS para la seguridad.

Recomendación Prestación
Arquitectura del clúster: Use la integración de Microsoft Entra. El uso de Microsoft Entra ID centraliza el componente de administración de identidades. Cualquier cambio en el estado del grupo o cuenta del usuario se actualiza automáticamente al acceder al clúster de AKS. Los desarrolladores y propietarios de aplicaciones del clúster de Kubernetes necesitan obtener acceso a diferentes recursos.
Arquitectura del clúster: Autentíquese con Microsoft Entra ID en Azure Container Registry. AKS y Microsoft Entra ID habilitan la autenticación con Azure Container Registry sin el uso de imagePullSecrets secretos. Consulte Autenticación con Azure Container Registry desde Azure Kubernetes Service para obtener más información.
Arquitectura del clúster: Proteja el tráfico de red al servidor de API con un clúster de AKS privado. De forma predeterminada, el tráfico de red entre los grupos de nodos y el servidor de API viaja por la red troncal de Microsoft; mediante un clúster privado, puede asegurarse de que el tráfico de red al servidor de API permanece solo en la red privada.
Arquitectura del clúster: En el caso de los clústeres de AKS no privados, use intervalos IP autorizados del servidor de API. Al usar clústeres públicos, todavía puede limitar el tráfico que puede llegar al servidor de API de clústeres mediante la característica de intervalo IP autorizado. Incluya orígenes como las direcciones IP públicas de los agentes de compilación de implementación, la administración de operaciones y el punto de salida de los grupos de nodos (como Azure Firewall).
Arquitectura del clúster: Proteja el servidor de API con Microsoft Entra RBAC. Asegurar el acceso al servidor de API de Kubernetes es una de los procedimientos más importantes que puede hacer para proteger su clúster. Integre el control de acceso basado en rol (RBAC) de Kubernetes con Microsoft Entra ID para controlar el acceso al servidor de API. Deshabilite las cuentas locales para aplicar todo el acceso al clúster mediante identidades basadas en Microsoft Entra ID.
Arquitectura del clúster: Use directivas de red de Azure o Calico. Proteja y controle el tráfico de red entre pods de un clúster.
Arquitectura del clúster: Protección de clústeres y pods con Azure Policy. Azure Policy puede ayudar a aplicar medidas de seguridad y aplicación a escala en los clústeres de una manera centralizada y coherente. También puede controlar qué pods de funciones se conceden y si algo se está ejecutando en la directiva de la empresa.
Arquitectura del clúster: Proteja el acceso de contenedor a los recursos. Limite el acceso a las acciones que los contenedores pueden realizar. Proporcione el menor número de permisos, y evite el uso de la raíz o de elevación de privilegios.
Arquitectura de carga de trabajo: Use un Web Application Firewall para proteger el tráfico HTTP(S). Para examinar el tráfico entrante en busca de posibles ataques, use un firewall de aplicaciones web como Azure Web Application Firewall (WAF) en Azure Application Gateway o Azure Front Door.
Arquitectura del clúster: Controlar el tráfico de salida del clúster. Asegúrese de que el tráfico saliente del clúster pasa a través de un punto de seguridad de red, como Azure Firewall o un proxy HTTP.
Arquitectura del clúster: Use el Id. de carga de trabajo de Microsoft Entra de código abierto y el controlador CSI del almacén de secretos con Azure Key Vault. Proteja y rote secretos, certificados y cadenas de conexión en Azure Key Vault con cifrado seguro. Proporciona un registro de auditoría de acceso y mantiene los secretos principales fuera de la canalización de implementación.
Arquitectura del clúster: Use Microsoft Defender para contenedores. Supervise y mantenga la seguridad de los clústeres, contenedores y sus aplicaciones.

Para obtener más sugerencias, consulte Principios de diseño de seguridad.

Azure Advisor ayuda a garantizar y mejorar el servicio Azure Kubernetes. Realiza recomendaciones sobre un subconjunto de los elementos enumerados en la sección de directiva siguiente, como clústeres sin RBAC configurado, falta Microsoft Defender configuración, acceso de red sin restricciones al servidor de API. Del mismo modo, realiza recomendaciones de carga de trabajo para algunos de los elementos de la iniciativa de seguridad de pods. Revise las recomendaciones.

Definiciones de directiva

Azure Policy ofrece varias definiciones de directivas integradas que se aplican tanto al recurso de Azure como a AKS, como las definiciones de directiva estándar, y el uso del complemento Azure Policy para Kubernetes, también dentro del clúster. Muchas de las directivas de recursos de Azure se incluyen en audit/deny, pero también en una variante Deploy If Not Exists .

Hay una gran cantidad de directivas y aquí se resumen las directivas clave relacionadas con este pilar. Para obtener una vista más detallada, consulte Definiciones de directivas integradas para Kubernetes.

Arquitectura del clúster

  • Microsoft Defender de directivas basadas en la nube
  • Directivas de configuración y modo de autenticación (Microsoft Entra ID, RBAC, deshabilitación de la autenticación local)
  • Directivas de acceso de red del servidor de API, incluido el clúster privado

Arquitectura de clúster y carga de trabajo

  • Iniciativas de seguridad de pods de clúster de Kubernetes: cargas de trabajo basadas en Linux
  • Incluir directivas de funcionalidad de pod y contenedor, como AppArmor, sysctl, límites de seguridad, SELinux, seccomp, contenedores con privilegios, credenciales de API de clúster de montaje automático
  • Montaje, controladores de volumen y directivas del sistema de archivos
  • Directivas de red de pod/contenedor, como la red de host, el puerto, las direcciones IP externas permitidas, los HTTP y los equilibradores de carga internos

Azure Kubernetes Service implementaciones a menudo también usan Azure Container Registry para gráficos de Helm e imágenes de contenedor. Azure Container Registry también admite una amplia variedad de directivas de Azure que abarcan restricciones de red, control de acceso y Microsoft Defender para la nube, que complementa una arquitectura de AKS segura.

Además de las directivas integradas, se pueden crear directivas personalizadas para el recurso de AKS y para el complemento de Azure Policy para Kubernetes. Esto le permite agregar restricciones de seguridad adicionales que le gustaría aplicar en el clúster y la arquitectura de carga de trabajo.

Para obtener más sugerencias, consulte Conceptos de seguridad de AKS y evalúe nuestras recomendaciones de protección de seguridad basadas en el banco de pruebas de KUBERNetes de CIS.

Optimización de costos

La optimización de costos consiste en comprender las diferentes opciones de configuración y los procedimientos recomendados para reducir los gastos innecesarios y mejorar las eficiencias operativas. Antes de seguir las instrucciones de este artículo, se recomienda revisar los siguientes recursos:

Al analizar la optimización de costos con Azure Kubernetes Service, es importante distinguir entre el costo de los recursos del clúster y el costo de los recursos de carga de trabajo. Los recursos del clúster son una responsabilidad compartida entre el administrador del clúster y su proveedor de recursos, mientras que los recursos de carga de trabajo son el dominio de un desarrollador. Azure Kubernetes Service tiene consideraciones y recomendaciones para ambos roles.

En la lista de comprobación de diseño y la lista de recomendaciones, se realizan llamadas para indicar si cada opción es aplicable a la arquitectura del clúster, a la arquitectura de carga de trabajo o a ambas.

Para la optimización de costos del clúster, vaya a la calculadora de precios de Azure y seleccione Azure Kubernetes Service de los productos disponibles. Puede probar diferentes planes de configuración y pago en la calculadora.

Diseño de una lista de comprobación

  • Arquitectura del clúster: use la SKU de máquina virtual adecuada por grupo de nodos y las instancias reservadas en las que se espera una capacidad a largo plazo.
  • Arquitecturas del clúster y la carga de trabajo: use el tamaño y el nivel de disco administrado adecuados.
  • Arquitectura del clúster: revise las métricas de rendimiento, empezando por la CPU, la memoria, el almacenamiento y la red, para identificar las oportunidades de optimización de costos por clúster, nodos y espacio de nombres.
  • Arquitectura de clúster y carga de trabajo: Use escaladores automáticos para escalar verticalmente cuando las cargas de trabajo estén menos activas.

Recomendaciones

Consulte la siguiente tabla de recomendaciones para optimizar la configuración de AKS en cuanto al costo.

Recomendación Prestación
Arquitecturas de clúster y carga de trabajo: Alinee la selección de SKU y el tamaño del disco administrado con los requisitos de carga de trabajo. Hacer coincidir la selección con las demandas de carga de trabajo garantiza que no paga por los recursos innecesarios.
Arquitectura del clúster: Seleccione el tipo de instancia de máquina virtual correcto. La selección del tipo de instancia de máquina virtual correcta es fundamental, ya que afecta directamente al costo de la ejecución de aplicaciones en AKS. La elección de una instancia de alto rendimiento sin un uso adecuado puede dar lugar a gastos despilfarro, mientras que elegir una instancia eficaz puede provocar problemas de rendimiento y un mayor tiempo de inactividad. Para determinar el tipo de instancia de máquina virtual adecuado, tenga en cuenta las características de la carga de trabajo, los requisitos de recursos y las necesidades de disponibilidad.
Arquitectura del clúster: Seleccione máquinas virtuales basadas en la arquitectura arm. AKS admite la creación de nodos de agente de Ubuntu arm64, así como una combinación de nodos de arquitectura intel y ARM dentro de un clúster que puede aportar un mejor rendimiento a un costo menor.
Arquitectura del clúster: Seleccione Azure Spot Virtual Machines. Las máquinas virtuales de acceso puntual le permiten aprovechar la capacidad de Azure no utilizada con descuentos significativos (hasta un 90 % en comparación con los precios de pago por uso). Si Azure necesita capacidad de vuelta, la infraestructura de Azure expulsa los nodos de spot.
Arquitectura del clúster: Seleccione la región adecuada. Debido a muchos factores, el costo de los recursos varía por región en Azure. Evalúe los requisitos de costo, latencia y cumplimiento para asegurarse de que ejecuta la carga de trabajo de forma rentable y no afecta a los usuarios finales ni crea cargos de red adicionales.
Arquitectura de carga de trabajo: Mantener imágenes pequeñas y optimizadas. La optimización de las imágenes ayuda a reducir los costos, ya que los nodos nuevos necesitan descargar estas imágenes. Compile imágenes de forma que permita que el contenedor se inicie lo antes posible para ayudar a evitar errores o tiempos de espera de solicitudes de usuario mientras la aplicación se está iniciando, lo que puede provocar un exceso de aprovisionamiento.
Arquitectura del clúster: Habilite Cluster Autoscaler para reducir automáticamente el número de nodos de agente en respuesta al exceso de capacidad de los recursos. Reducir verticalmente automáticamente el número de nodos del clúster de AKS le permite ejecutar un clúster eficaz cuando la demanda es baja y escalar verticalmente cuando la demanda vuelve.
Arquitectura del clúster: Habilite el aprovisionamiento automático de nodos para automatizar la selección de SKU de máquina virtual. El aprovisionamiento automático de node simplifica el proceso de selección de SKU y decide, en función de los requisitos de recursos de pod pendientes, la configuración óptima de la máquina virtual para ejecutar cargas de trabajo de la manera más eficaz y rentable.
Arquitectura de carga de trabajo: Use horizontal pod Autoscaler. Ajuste el número de pods de una implementación en función del uso de cpu u otras métricas de selección, que admiten operaciones de escalado de clústeres.
Arquitectura de carga de trabajo: Use Vertical Pod Autoscaler (versión preliminar). Derechos de los pods y establecimiento dinámico de solicitudes y límites en función del uso histórico.
Arquitectura de carga de trabajo: Use el escalado automático controlado por eventos (KEDA) de Kubernetes. Escale en función del número de eventos que se están procesando. Elija entre un amplio catálogo de escaladores KEDA de más de 50.
Arquitecturas de clúster y carga de trabajo: Adopte una materia financiera en la nube y una práctica cultural para impulsar la propiedad del uso de la nube. La base de habilitar la optimización de costos es la propagación de un clúster de ahorro de costos. A menudo se usa un enfoque de operaciones financieras (FinOps) para ayudar a las organizaciones a reducir los costos de la nube. Es una práctica que implica la colaboración entre los equipos de finanzas, operaciones e ingeniería para impulsar la alineación con los objetivos de ahorro de costos y aportar transparencia a los costos en la nube.
Arquitectura de clúster: Regístrese en Reservas de Azure o plan de ahorro de Azure. Si planea correctamente la capacidad, la carga de trabajo es predecible y existe durante un período de tiempo prolongado, regístrese en una reserva de Azure o en un plan de ahorro para reducir aún más los costos de los recursos.
Arquitectura de clúster: Configure la supervisión del clúster con Container Insights. La ayuda de Container Insights proporciona información útil sobre los clústeres inactivos y los recursos no asignados. Container Insights también admite la recopilación de métricas de Prometheus y se integra con Azure Managed Grafana para obtener una vista holística de la aplicación y la infraestructura.
Arquitectura de clúster: Configure el complemento Análisis de costos de AKS. La extensión de clúster de análisis de costos permite obtener información detallada sobre los costos asociados a varios recursos de Kubernetes en los clústeres o espacios de nombres.

Para obtener más sugerencias, consulte Principios del pilar de optimización de costos y Optimización de costos en Azure Kubernetes Service.

Definiciones de directiva

Aunque no hay directivas integradas relacionadas con la optimización de costos, se pueden crear directivas personalizadas para el recurso de AKS y para el complemento de Azure Policy para Kubernetes. Esto le permite agregar restricciones de optimización de costos adicionales que le gustaría aplicar en la arquitectura de clúster y carga de trabajo.

Eficiencia de la nube

Hacer que las cargas de trabajo sean más sostenibles y eficientes en la nube, requiere la combinación de esfuerzos en torno a la optimización de costos, la reducción de las emisiones de carbono y la optimización del consumo energético. Optimizar el costo de la aplicación es el paso inicial para hacer que las cargas de trabajo sean más sostenibles.

Aprenda a crear cargas de trabajo de AKS sostenibles y eficaces, en Principios de ingeniería de software sostenible en Azure Kubernetes Service (AKS).

Excelencia operativa

La supervisión y el diagnóstico son fundamentales. No solo puede medir las estadísticas de rendimiento, sino que también puede usar métricas para solucionar problemas y corregirlos rápidamente. Se recomienda revisar los principios de diseño de excelencia operativa y la guía de operaciones del día 2.

Al analizar la excelencia operativa con Azure Kubernetes Service, es importante distinguir entre la excelencia operativa del clúster y la excelencia operativa de la carga de trabajo. Las operaciones de clúster son una responsabilidad compartida entre el administrador del clúster y su proveedor de recursos, mientras que las operaciones de carga de trabajo son el dominio de un desarrollador. Azure Kubernetes Service tiene consideraciones y recomendaciones para ambos roles.

En la lista de comprobación de diseño y la lista de recomendaciones siguientes, se realizan llamadas para indicar si cada opción es aplicable a la arquitectura del clúster, a la arquitectura de carga de trabajo o a ambas.

Diseño de una lista de comprobación

  • Arquitectura de clúster: Use una implementación basada en plantillas mediante Bicep, Terraform u otros. Asegúrese de que todas las implementaciones son repetibles, rastreables y almacenadas en un repositorio de código fuente.
  • Arquitectura de clúster: Cree un proceso automatizado para asegurarse de que los clústeres se arrancan con las configuraciones e implementaciones necesarias para todo el clúster. Esto suele realizarse mediante GitOps.
  • Arquitectura de carga de trabajo: Use un proceso de implementación repetible y automatizado para la carga de trabajo dentro del ciclo de vida de desarrollo de software.
  • Arquitectura de clúster: Habilite la configuración de diagnóstico para asegurarse de que se registran las interacciones del servidor de API principal o del plano de control.
  • Arquitecturas de clúster y carga de trabajo: Habilite Container Insights para recopilar métricas, registros y diagnósticos para supervisar la disponibilidad y el rendimiento del clúster y las cargas de trabajo que se ejecutan en él.
  • Arquitectura de carga de trabajo: La carga de trabajo debe diseñarse para emitir telemetría que se pueda recopilar, que también debe incluir líneas dinámicas y estados de preparación.
  • Arquitecturas de clúster y carga de trabajo: Use prácticas de ingeniería de caos destinadas a Kubernetes para identificar problemas de confiabilidad de aplicaciones o plataformas.
  • Arquitectura de carga de trabajo: Optimice la carga de trabajo para que funcione e implemente de forma eficaz en un contenedor.
  • Arquitecturas de clúster y carga de trabajo: Aplique la gobernanza de clústeres y cargas de trabajo mediante Azure Policy.

Recomendaciones

Explore la tabla siguiente de recomendaciones para optimizar la configuración de AKS para las operaciones.

Recomendación Prestación
Arquitecturas de clúster y carga de trabajo: Revise la documentación de procedimientos recomendados de AKS . Para compilar y ejecutar aplicaciones correctamente en AKS, hay consideraciones clave para comprender e implementar. Estas áreas incluyen las características de servicios multiinquilino y programador, seguridad de pod y clúster, o continuidad empresarial y recuperación ante desastres.
Arquitecturas de clúster y carga de trabajo: Revise Azure Chaos Studio. Azure Chaos Studio puede ayudar a simular errores y desencadenar situaciones de recuperación ante desastres.
Arquitecturas de clúster y carga de trabajo: Configure la supervisión del clúster con Container Insights. Container Insights ayuda a supervisar el rendimiento de los contenedores mediante la recopilación de métricas de memoria y procesador de controladores, nodos y contenedores que están disponibles en Kubernetes a través de metrics API y registros de contenedor.
Arquitectura de carga de trabajo: Supervise el rendimiento de las aplicaciones con Azure Monitor. Configure Application Insights para la supervisión basada en código de las aplicaciones que se ejecutan en un clúster de AKS.
Arquitectura de carga de trabajo: Configure la extracción de métricas de Prometheus con Container Insights. Container Insights, que forman parte de Azure Monitor, proporcionan una experiencia de incorporación sin problemas para recopilar métricas de Prometheus. Referencia Configuración de la extracción de métricas de Prometheus para obtener más información.
Arquitectura de clúster: Adopte una estrategia de varias regiones mediante la implementación de clústeres de AKS implementados en diferentes regiones de Azure para maximizar la disponibilidad y proporcionar continuidad empresarial. Las cargas de trabajo accesibles desde Internet deben aprovechar Azure Front Door o Azure Traffic Manager para enrutar el tráfico globalmente entre clústeres de AKS.
Arquitectura de clúster: Operacionalice los clústeres y los estándares de configuración de pods con Azure Policy. Azure Policy puede ayudar a aplicar medidas de seguridad y aplicación a escala en los clústeres de una manera centralizada y coherente. También puede controlar qué pods de funciones se conceden y si algo se está ejecutando en la directiva de la empresa.
Arquitectura de carga de trabajo: Use las funcionalidades de la plataforma en el proceso de ingeniería de versiones. Los controladores de entrada y Kubernetes admiten muchos patrones de implementación avanzados para su inclusión en el proceso de ingeniería de versiones. Considere patrones como implementaciones azul-verde o versiones controladas.
Arquitecturas de clúster y carga de trabajo: En el caso de las cargas de trabajo críticas, use implementaciones azules o verdes de nivel de stamp. Automatice las áreas de diseño críticas, incluida la implementación y las pruebas.

Para obtener más sugerencias, consulte Principios del pilar de excelencia operativa.

Azure Advisor también realiza recomendaciones sobre un subconjunto de los elementos enumerados en la sección de directiva siguiente, como las versiones de AKS no admitidas y la configuración de diagnóstico no configurada. Del mismo modo, realiza recomendaciones de carga de trabajo en torno al uso del espacio de nombres predeterminado.

Definiciones de directiva

Azure Policy ofrece varias definiciones de directivas integradas que se aplican tanto al recurso de Azure como a AKS, como las definiciones de directivas estándar, y el uso del complemento Azure Policy para Kubernetes, también dentro del clúster. Muchas de las directivas de recursos de Azure vienen en la variante Audit/Deny, pero también en una variante Deploy If Not Exists .

Hay una gran cantidad de directivas y las directivas clave relacionadas con este pilar se resumen aquí. Para obtener una vista más detallada, consulte Definiciones de directivas integradas para Kubernetes.

Arquitectura de clúster

  • complemento de Azure Policy para Kubernetes
  • Directivas de configuración de GitOps
  • Directivas de configuración de diagnóstico
  • Restricciones de versión de AKS
  • Impedir la invocación de comando

Arquitectura de clústeres y cargas de trabajo

  • Restricciones de implementación del espacio de nombres

Además de las directivas integradas, se pueden crear directivas personalizadas para el recurso de AKS y para el complemento Azure Policy para Kubernetes. Esto le permite agregar restricciones de seguridad adicionales que le gustaría aplicar en el clúster y la arquitectura de la carga de trabajo.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Se recomienda revisar los principios de eficiencia del rendimiento.

Al analizar el rendimiento con Azure Kubernetes Service, es importante distinguir entre el rendimiento del clúster y el rendimiento de la carga de trabajo. El rendimiento del clúster es una responsabilidad compartida entre el administrador del clúster y su proveedor de recursos, mientras que el rendimiento de la carga de trabajo es el dominio de un desarrollador. Azure Kubernetes Service tiene consideraciones y recomendaciones para ambos roles.

En la lista de comprobación de diseño y la lista de recomendaciones siguientes, se realizan llamadas para indicar si cada opción es aplicable a la arquitectura del clúster, a la arquitectura de carga de trabajo o a ambas.

Diseño de una lista de comprobación

A medida que toma decisiones de diseño para Azure Kubernetes Service, revise los principios de eficiencia del rendimiento.

  • Arquitecturas de clúster y carga de trabajo: Realice e iteración en un ejercicio detallado del plan de capacidad que incluya SKU, configuración de escalado automático, direccionamiento IP y consideraciones de conmutación por error.
  • Arquitectura de clúster: Habilite el escalador automático del clúster para ajustar automáticamente el número de nodos de agente en las demandas de carga de trabajo de respuesta.
  • Arquitectura de clúster: Use el escalador automático horizontal de pods para ajustar el número de pods de una implementación en función del uso de la CPU u otras métricas selectas.
  • Arquitecturas de clúster y carga de trabajo: Realice actividades de prueba de carga en curso que ejercen el escalador automático de pods y clústeres.
  • Arquitecturas de clúster y carga de trabajo: Separe las cargas de trabajo en distintos grupos de nodos, lo que permite escalar de forma independiente.

Recomendaciones

Explore la tabla siguiente de recomendaciones para optimizar la configuración de Azure Kubernetes Service para el rendimiento.

Recomendación Prestación
Arquitecturas de clúster y carga de trabajo: Desarrolle un plan de capacidad detallado y revise y revise continuamente. Después de formalizar el plan de capacidad, se debe actualizar con frecuencia observando continuamente el uso de recursos del clúster.
Arquitectura de clúster: Habilite el escalador automático del clúster para ajustar automáticamente el número de nodos del agente en respuesta a las restricciones de recursos. La capacidad automática de ampliar o reducir verticalmente la cantidad de nodos en el clúster de AKS le permite ejecutar un clúster de forma eficaz y rentable.
Arquitecturas de clúster y carga de trabajo: Separe las cargas de trabajo en distintos grupos de nodos y considere la posibilidad de escalar grupos de nodos de usuario. A diferencia de los grupos de nodos del sistema que siempre requieren nodos en ejecución, los grupos de nodos de usuario permiten escalar o reducir verticalmente.
Arquitectura de carga de trabajo: Use las características avanzadas del programador de AKS. Ayuda a controlar el equilibrio de recursos para las cargas de trabajo que las requieren.
Arquitectura de carga de trabajo: Use métricas significativas de escalado de cargas de trabajo. No todas las decisiones de escalado se pueden derivar de métricas de CPU o memoria. A menudo, las consideraciones de escala proceden de puntos de datos más complejos o incluso externos. Use KEDA para crear un conjunto de reglas de escalado automático significativo basado en señales específicas de la carga de trabajo.

Para obtener más sugerencias, consulte Principios del pilar de eficiencia del rendimiento.

Definiciones de directiva

Azure Policy ofrece varias definiciones de directivas integradas que se aplican tanto al recurso de Azure como a AKS, como las definiciones de directivas estándar, y el uso del complemento Azure Policy para Kubernetes, también dentro del clúster. Muchas de las directivas de recursos de Azure vienen en la variante Audit/Deny, pero también en una variante Deploy If Not Exists .

Hay una gran cantidad de directivas y las directivas clave relacionadas con este pilar se resumen aquí. Para obtener una vista más detallada, consulte Definiciones de directivas integradas para Kubernetes.

Arquitectura de clústeres y cargas de trabajo

  • Límites de recursos de CPU y memoria

Además de las directivas integradas, se pueden crear directivas personalizadas para el recurso de AKS y para el complemento Azure Policy para Kubernetes. Esto le permite agregar restricciones de seguridad adicionales que le gustaría aplicar en el clúster y la arquitectura de la carga de trabajo.

Recursos adicionales

Guía del Centro de arquitectura de Azure

Guía de Cloud Adoption Framework

Pasos siguientes