Compartir a través de

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:

  • Fiabilidad
  • Seguridad
  • Optimización de costes
  • Excelencia operativa
  • Eficiencia del rendimiento

Se supone 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 del marco bien diseñado puede ayudar a generar 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 del marco de trabajo de Azure Well-Architected.

En 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 de un clúster de Azure Kubernetes Service (AKS) y la 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 escalable de Azure Kubernetes Service (AKS).

Fiabilidad

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, la arquitectura de carga de trabajo o ambas.

Diseño de una lista de comprobación

  • Arquitectura de clúster: para cargas de trabajo críticas, use zonas de disponibilidad para los clústeres de AKS.
  • Arquitectura de clúster: planee el espacio de direcciones IP para asegurarse de que el clúster se puede escalar de forma confiable, incluido el control del tráfico de conmutación por error en topologías de varios clústeres.
  • Arquitectura de clúster: revise los procedimientos recomendados para supervisar Kubernetes con Azure Monitor para determinar la mejor estrategia de supervisión para las cargas de trabajo.
  • Arquitectura de la carga de trabajo: asegúrese de que las cargas de trabajo están creadas para admitir el escalado horizontal y 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 adecuada. Como mínimo, incluya dos nodos para los grupos de nodos de usuario y tres nodos para el grupo de nodos del sistema.
  • Arquitectura de 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 la confiabilidad.

Recomendación Prestación
Arquitecturas de clúster y carga de trabajo: controle la programación de pods mediante selectores de nodos 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 toleraciones, los pods sin un selector de nodos 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 de clúster: asegúrese de seleccionar correctamente el complemento de red en función de los requisitos de red y el ajuste de 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 clústeres de nivel de producción. El contrato de nivel de servicio de tiempo de actividad de AKS garantiza lo siguiente:
- 99.95% disponibilidad del punto de conexión del servidor de API de Kubernetes para clústeres de AKS que usan Azure Availability Zones o
- Disponibilidad del 99.9% para clústeres de AKS que no usan Azure Availability Zones.
Arquitecturas de clúster y carga de trabajo: revise los procedimientos recomendados para supervisar Kubernetes con Azure Monitor para determinar la mejor estrategia de supervisión para las cargas de trabajo. N/D
Arquitectura de 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 incluso si se ha inactivo otra zona. Si existen requisitos de coubicación, se puede usar una implementación normal de AKS basada en conjuntos de escalado de máquinas virtuales en una sola zona o grupos de selección de ubicación de proximidad para minimizar la latencia interno.
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.
Arquitecturas de clúster y carga de trabajo: defina las solicitudes y límites de recursos de pod en los manifiestos de implementación de aplicaciones y aplique con Azure Policy. Los límites de recursos de MEMORIA y CPU de 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 a grupos de nodos dedicados en función de 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 adicional de administración.
Arquitectura de 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 limitaciones de Azure Load Balancer 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 integradas de Azure que se aplican tanto al recurso de Azure como a las directivas típicas de Azure como al complemento azure Policy para Kubernetes, también dentro del clúster. Hay numerosas políticas clave relacionadas con este pilar que 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

  • Los clústeres tienen sondeos de estado de preparación o ejecución configurados para la especificación de pod.

Además de las definiciones integradas de Azure Policy, 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 confiabilidad adicionales que le gustaría aplicar en el clúster y la arquitectura de carga de trabajo.

Seguridad

La seguridad es 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, consulte Requisitos de aislamiento il5 de Azure Government.

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, la arquitectura de carga de trabajo o ambas.

Diseño de una lista de comprobación

  • Arquitectura de clúster: use identidades administradas para evitar la administración y rotación de los principios de servicio.
  • Arquitectura de clúster: use el control de acceso basado en rol (RBAC) de Kubernetes con el identificador de Microsoft Entra 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 de 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 de 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 firewall de aplicaciones web 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 de clúster: use la integración de Microsoft Entra. Mediante Microsoft Entra ID se 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 de clúster: autentíquese con el identificador de Entra de Microsoft 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 más información.
Arquitectura de 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 de clúster: para 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 de clúster: proteja el servidor de API con RBAC de Microsoft Entra. 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 identificadores de Microsoft Entra.
Arquitectura de 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 de clúster: proteja 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 de 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 firewall de aplicaciones web 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 App de Azure lication Gateway o Azure Front Door.
Arquitectura de clúster: control del 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 de clúster: use la 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 gire secretos, certificados y cadena 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 de 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 directivas siguiente, como los clústeres sin RBAC configurado, la configuración de Microsoft Defender que falta, el 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 del pod. 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 numerosas políticas clave relacionadas con este pilar que se resumen aquí. Para obtener una vista más detallada, consulte Definiciones de directivas integradas para Kubernetes.

Arquitectura de clúster

  • Directivas basadas en Microsoft Defender para la nube
  • Directivas de configuración y modo de autenticación (Id. de Microsoft Entra, RBAC, deshabilitación de la autenticación local)
  • Directivas de acceso de red de API Server, incluido el clúster privado

Arquitectura de clústeres y cargas 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 de sistema de archivos
  • Directivas de red de pod/contenedor, como la red host, el puerto, las direcciones IP externas permitidas, los HTTP y los equilibradores de carga internos

Las implementaciones de Azure Kubernetes Service suelen usar 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 for Cloud, 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 la prueba comparativa 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, la arquitectura de carga de trabajo o ambas.

Para la optimización de costos del clúster, vaya a la calculadora de precios de Azure y seleccione Azure Kubernetes Service en 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. La coincidencia de la selección con las demandas de carga de trabajo garantiza que no paga por los recursos innecesarios.
Arquitectura de clúster: seleccione el tipo de instancia de máquina virtual correcto. Seleccionar el tipo de instancia de máquina virtual adecuado es fundamental, ya que afecta directamente al costo de ejecutar aplicaciones en AKS. Elegir una instancia de alto rendimiento sin un uso adecuado puede dar lugar a gastos desperdiciados, mientras que elegir una instancia menos 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 de clúster: seleccione máquinas virtuales basadas en la arquitectura de Arm. AKS admite la creación de nodos de agente de Ubuntu de 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 de 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 recuperar la capacidad, la infraestructura de Azure expulsará los nodos de acceso puntual.
Arquitectura de clúster: seleccione la región adecuada. Debido a muchos factores, el costo de los recursos varía según la región de 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 adicionales de red.
Arquitectura de carga de trabajo: mantenga 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 de solicitud de usuario o tiempos de espera mientras se inicia la aplicación, lo que puede provocar un sobreaprovisionamiento.
Arquitectura de clúster: habilite el escalador automático de clústeres para reducir automáticamente el número de nodos de agente en respuesta a un exceso de capacidad de recursos. El escalado vertical automático del número de nodos del clúster de AKS le permite ejecutar un clúster eficaz cuando la demanda es baja y se escala verticalmente cuando se devuelve la demanda.
Arquitectura de 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 la 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). Rightsize your pods and dynamically set requests and limits based on historic usage( Rightsize your pods and dynamically set requests and limits based on historic usage.
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 catálogo enriquecido 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 la habilitación de 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 Azure Reservations o en El 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 recursos.
Arquitectura de clúster: revise los procedimientos recomendados para supervisar Kubernetes con Azure Monitor para determinar la mejor estrategia de supervisión para las cargas de trabajo. N/D
Arquitectura de clúster: configure el complemento Análisis de costos de AKS. La extensión de clúster de análisis de costos le permite obtener información detallada sobre los costos asociados a varios recursos de Kubernetes en los clústeres o espacios de nombres.

Para 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 el clúster y la arquitectura de carga de trabajo.

Eficiencia en 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, la arquitectura de carga de trabajo o 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: revise los procedimientos recomendados para supervisar Kubernetes con Azure Monitor para determinar la mejor estrategia de supervisión para las cargas de trabajo.
  • Arquitectura de carga de trabajo: la carga de trabajo debe diseñarse para emitir telemetría que se puede 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: revise los procedimientos recomendados para supervisar Kubernetes con Azure Monitor para determinar la mejor estrategia de supervisión para las cargas de trabajo. N/D
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 funcionalidades de 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: para cargas de trabajo críticas, use implementaciones azules o verdes de nivel de sello. 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 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 numerosas políticas clave relacionadas con este pilar que 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 comandos

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

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad que tiene la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan realizado 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, la arquitectura de carga de trabajo o ambas.

Diseño de una lista de comprobación

A medida que tome 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 itere 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 de clústeres 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 de selección.
  • 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 grupos de nodos diferentes, 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, debe actualizarse con frecuencia observando continuamente el uso de recursos del clúster.
Arquitectura de clúster: habilite el escalador automático de clústeres 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 de las cargas de trabajo que las requieren.
Arquitectura de carga de trabajo: use métricas de escalado de cargas de trabajo significativas. 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 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 numerosas políticas clave relacionadas con este pilar que 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 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.

Recursos adicionales

Guía del Centro de arquitectura de Azure

Guía de Cloud Adoption Framework

Pasos siguientes