Arquitectura de línea de base en un clúster de Azure Kubernetes Service (AKS)

Esta arquitectura de referencia proporciona una arquitectura de infraestructura de línea base recomendada para implementar un clúster de Azure Kubernetes Service (AKS) en Azure. Usa nuestros principios de diseño y se basa en nuestros procedimientos recomendados arquitectónicos del Marco de buena arquitectura de Azure para guiar a un equipo interdisciplinario o varios equipos distintos, como las redes, la seguridad y la identidad mediante la implementación de esta infraestructura de uso general.

Esta arquitectura no se centra en una carga de trabajo, sino que se concentra en el propio clúster de AKS. La información aquí es la línea base mínima recomendada para la mayoría de los clústeres de AKS. Se integra con los servicios Azure que ofrecen capacidad de observación, una topología de red que admite el crecimiento multirregional y protege el tráfico dentro del clúster.

La arquitectura de destino está influenciada por los requisitos empresariales y, como resultado, puede variar entre distintos contextos de aplicación. Debe considerarse como punto de partida para las fases de preproducción y producción.

También hay una implementación de esta arquitectura que está disponible en GitHub: Implementación de referencia de la línea de base de Azure Kubernetes Service (AKS). Puede utilizarla como punto de partida alternativo y configurarla en función de sus necesidades.

Configuración de red

Topología de red
Plan de direcciones IP
Implementación de recursos de entrada

Cálculo del clúster

Cálculo del clúster base
Referencia de imagen de contenedor
Administración de directivas

Administración de identidades

Integración de Microsoft Entra ID para el clúster
Integración de Microsoft Entra ID para la carga de trabajo

Protección del flujo de datos

Protección del flujo de red
Adición de administración de secretos

Continuidad empresarial

Escalabilidad
Disponibilidad de clústeres y nodos
Disponibilidad y compatibilidad con varias regiones

Operaciones

Canalizaciones de CI/CD de carga de trabajo y clúster
Mantenimiento y métricas del clúster
Administración de costos e informes

Topología de red

Esta arquitectura usa una topología en estrella tipo hub-and-spoke. El centro y los radios se implementan en redes virtuales independientes conectadas a través del emparejamiento. Algunas de las ventajas de esta topología son:

• Administración segregada. Permite aplicar la gobernanza y cumplir el principio de privilegios mínimos. También admite el concepto de una zona de aterrizaje de Azure con separación de tareas.

• Minimiza la exposición directa a los recursos de Azure de la red pública de Internet.

• A menudo, las organizaciones operan con topologías en estrella tipo hub-and-spoke. Las topologías de red en estrella tipo hub-and-spoke se pueden expandir en el futuro y proporcionar aislamiento de la carga de trabajo.

• Todas las aplicaciones web requieren un servicio de firewall de aplicaciones web (WAF) para ayudar a controlar los flujos de tráfico HTTP.

• Una opción natural para las cargas de trabajo que abarcan varias suscripciones.

• Hace que la arquitectura sea extensible. Para acomodar nuevas características o cargas de trabajo, se pueden agregar nuevos radios en lugar de volver a diseñar la topología de red.

• Determinados recursos, como un firewall y DNS, pueden compartirse entre redes.

• Se alinea con las zonas de aterrizaje a escala empresarial de Azure.

Descargue un archivo Visio de esta arquitectura.

Para más información, consulte topología de red en estrella tipo hub-and-spoke en Azure.

Para revisar los cambios de diseño de red incluidos en la arquitectura de referencia básica de contenedores Windows en AKS, consulte el artículo complementario.

Hub

La red virtual de centro es el punto central de conectividad y observabilidad. Un centro de conectividad siempre contiene un Azure Firewall con directivas de firewall globales definidas por los equipos de TI centrales para aplicar la directiva de firewall en toda la organización, Azure Bastion, una subred de puerta de enlace para la conectividad VPN y Azure Monitor para la observabilidad de red.

Dentro de la red, se implementan tres subredes.

Subred para hospedar Azure Firewall

Azure Firewall es un firewall como servicio. La instancia de firewall protege el tráfico de red saliente. Sin este nivel de seguridad, el tráfico puede comunicarse con un servicio malintencionado de terceros que podría exfiltrar los datos confidenciales de la empresa. Azure Firewall Manager permite implementar y configurar de forma centralizada varias instancias de Azure Firewall y administrar directivas de Azure Firewall para este tipo de arquitectura de red virtual de concentrador.

Subred para hospedar una puerta de enlace

Esta subred es un marcador de posición de una puerta de enlace de ExpressRoute o VPN. La puerta de enlace proporciona conectividad entre los enrutadores de la red local y la red virtual.

Subred para hospedar Azure Bastion

Esta subred es un marcador de posición de Azure Bastion. Puede usar Bastion para acceder de forma segura a los recursos de Azure sin exponer los recursos a Internet. Esta subred solo se usa para la administración y las operaciones.

Radio

La red virtual de radios contiene el clúster de AKS y otros recursos relacionados. El radio tiene cuatro subredes:

Subred para hospedar Azure Application Gateway

AzureApplication Gateway es un equilibrador de carga de tráfico web que opera en el nivel 7. La implementación de referencia usa la SKU de Application Gateway v2 que habilita el firewall de aplicaciones web (WAF). WAF protege el tráfico entrante frente a los ataques de tráfico web comunes, incluidos los bots. La instancia tiene una configuración de IP de front-end pública que recibe las solicitudes del usuario. Por diseño, una instancia de Application Gateway requiere una subred dedicada.

Subred para hospedar los recursos de entrada

Traefik es el controlador de entrada que atenderá los recursos de entrada de Kubernetes para enrutar y distribuir el tráfico. Los equilibradores de carga internos de Azure existen en esta subred. Para más información, consulte Uso de un equilibrador de carga interno con Azure Kubernetes Service (AKS).

Subred para hospedar los nodos de clúster

AKS mantiene dos grupos independientes de nodos (o grupos de nodos). El grupo de nodos del sistema hospeda los pods que ejecutan los servicios principales del clúster. El grupo de nodos de usuario ejecuta la carga de trabajo y el controlador de entrada para facilitar la comunicación entrante para la carga de trabajo.

Subred para hospedar los puntos de conexión de Private Link

Las conexiones de Azure Private Link se crean para Azure Container Registry y Azure Key Vault, por lo que se puede acceder a estos servicios mediante puntos de conexión privados dentro de la red virtual de radio. Los puntos de conexión privados no requieren una subred dedicada y también se pueden colocar en la red virtual del concentrador. En la implementación de línea base, se implementan en una subred dedicada dentro de la red virtual de radio. Este enfoque reduce el tráfico que pasa la conexión de la red emparejada, mantiene los recursos que pertenecen al clúster en la misma red virtual y permite aplicar reglas de seguridad granulares en el nivel de subred mediante grupos de seguridad de red.

Para más información, consulte Opciones de implementación de Private Link.

Plan de direcciones IP

Descargue un archivo Visio de esta arquitectura.

El espacio de direcciones de la red virtual debe ser lo suficientemente grande como para contener todas las subredes. Tenga en cuenta todas las entidades que recibirán tráfico. Las direcciones IP de esas entidades se asignarán desde el espacio de direcciones de la subred. Tenga en cuenta estos puntos.

• Actualizar

  AKS actualiza los nodos con regularidad para asegurarse de que las características de seguridad de las máquinas virtuales subyacentes y otras revisiones del sistema estén actualizadas. Durante un proceso de actualización, AKS crea un nodo que hospeda temporalmente los pods, mientras que el nodo de actualización se acordona y se purga. A ese nodo temporal se le asigna una dirección IP de la subred del clúster.

  En el caso de los pods, es posible que necesite direcciones adicionales, en función de la estrategia. En el caso de las actualizaciones graduales, necesitará direcciones para los pods temporales que ejecutan la carga de trabajo mientras se actualizan los pods reales. Si usa la estrategia de reemplazo, se quitan los pods y se crean los nuevos. Por lo que, se reutilizan las direcciones asociadas a los pods anteriores.

• Escalabilidad

  Tenga en cuenta el número de todos los nodos del sistema y de usuario, así como su límite máximo de escalabilidad. Supongamos que desea escalar horizontalmente un 400 %. Necesitará cuatro veces el número de direcciones para todos los nodos escalados horizontalmente.

  En esta arquitectura, se puede establecer contacto con cada pod directamente. Por lo tanto, cada pod necesita una dirección individual. La escalabilidad del pod afectará al cálculo de la dirección. Esta decisión dependerá de su elección del número de pods que desea aumentar.

• Direcciones de Azure Private Link

  Factorice las direcciones que son necesarias para la comunicación con otros servicios de Azure a través de Private Link. En esta arquitectura, hay dos direcciones asignadas para los vínculos a Azure Container Registry y Key Vault.

• Ciertas direcciones están reservadas para uso de Azure. No se pueden asignar.

La lista anterior no es exhaustiva. Si el diseño tiene otros recursos que van a influir en el número de direcciones IP disponibles, acomode esas direcciones.

Esta arquitectura está diseñada para una sola carga de trabajo. En el caso de varias cargas de trabajo, puede que quiera aislar los grupos de nodos de usuario entre sí y del grupo de nodos de sistema. Esta opción da lugar a más subredes de menor tamaño. Además, el recurso de entrada puede resultar más complejo, por lo que es posible que necesite varios controladores de entrada que requieran direcciones IP adicionales.

Para el conjunto completo de consideraciones para esta arquitectura, consulte Topología de red de línea de base de AKS.

Para información relacionada con el planeamiento de IP para un clúster de AKS, consulte Planeamiento de direccionamiento IP del clúster.

Para revisar las consideraciones de planificación de direcciones IP incluidas en la arquitectura de referencia de contenedores Windows en AKS, consulte el artículo complementario.

Complementos y características en vista previa (gb)

Kubernetes y AKS son productos en continua evolución, con ciclos de lanzamiento más rápidos que el software para entornos locales. Esta arquitectura de línea base depende de las características en vista previa de AKS y los complementos de AKS seleccionados. La diferencia entre los dos son las siguientes:

• El equipo de AKS describe las características en vista previa (gb) como enviadas y mejorando. La razón detrás de eso es que muchas de las características en vista previa (gb) permanecen en ese estado solo unos meses antes de pasar a la fase de disponibilidad general (GA).
• Los complementos y extensiones de AKS proporcionan funcionalidades adicionales admitidas. AKS administra la instalación, la configuración y el ciclo de vida.

Esta arquitectura de línea de base no incluye todas las características o complementos en vista previa, sino solo las que agregan un valor significativo a un clúster de uso general. A medida que estas características salen de la versión preliminar, esta arquitectura de línea base se revisará en consecuencia. Hay algunas características en vista previa (gb) adicionales o complementos de AKS que es posible que quiera evaluar en clústeres de preproducción que aumenten la seguridad, la capacidad de administración u otros requisitos. En el caso de los complementos de terceros, debe instalarlos y mantenerlos, incluido el seguimiento de las versiones disponibles y la instalación de actualizaciones después de actualizar la versión de Kubernetes de un clúster.

Referencia de imágenes de contenedor

Además de la carga de trabajo, el clúster podría contener otras imágenes, como el controlador de entrada. Algunas de esas imágenes pueden residir en registros públicos. Tenga en cuenta estos puntos al extraerlas en el clúster.

• El clúster se ha autenticado para extraer la imagen.

• Si usa una imagen pública, considere la posibilidad de importarla al registro de contenedor que se alinea con su SLO. De lo contrario, la imagen podría estar sujeta a problemas de disponibilidad inesperados. Estos problemas pueden provocar problemas operativos si la imagen no está disponible cuando la necesita. Estas son algunas de las ventajas de usar el registro de contenedor en lugar de un registro público:

  • Puede bloquear el acceso no autorizado a las imágenes.
  • No tendrá dependencias públicas.
  • Puede acceder a los registros de extracción de imágenes para supervisar las actividades y evaluar los problemas de conectividad.
  • Aproveche las ventajas del examen de contenedores y el cumplimiento de imágenes integrados.

  Una opción es Azure Container Registry (ACR).

• Extraiga las imágenes de registros autorizados. Puede aplicar esta restricción mediante Azure Policy. En esta implementación de referencia, el clúster solo extrae imágenes de ACR, que se implementa como parte de la arquitectura.

Configuración del cálculo del clúster base

En AKS, cada grupo de nodos se asigna a un conjunto de escalado de máquinas virtuales. Los nodos son máquinas virtuales en cada grupo de nodos. Considere la posibilidad de usar un tamaño de máquina virtual más pequeño para el grupo de nodos del sistema a fin de minimizar los costos. Esta implementación de referencia implementa el grupo de nodos del sistema con tres nodos DS2_v2. Ese tamaño es suficiente para satisfacer la carga esperada de los pods del sistema. El disco del sistema operativo es de 512 GB.

Estas son algunas consideraciones para el grupo de nodos de usuario:

• Elija tamaños de nodo mayores para empaquetar el número máximo de pods establecido en un nodo. Minimizará la superficie de memoria de los servicios que se ejecutan en todos los nodos, como la supervisión y el registro.

• Implemente al menos dos nodos. De este modo, la carga de trabajo tendrá un patrón de alta disponibilidad con dos réplicas. Con AKS, puede cambiar el número de nodos sin volver a crear el clúster.

• Los tamaños de nodo reales de la carga de trabajo dependerán de los requisitos determinados por el equipo de diseño. Teniendo en cuenta los requisitos empresariales, hemos elegido DS4_v2 para la carga de trabajo de producción. Para reducir los costos, se podría disminuir el tamaño a DS3_v2, que es la recomendación mínima.

• Al planear la capacidad del clúster, suponga que la carga de trabajo puede consumir hasta el 80 % de cada nodo; el 20 % restante se reserva para los servicios AKS.

• Establezca el número máximo de pods por nodo en función del planeamiento de capacidad. Si está intentando establecer una línea base de capacidad, comience con un valor de 30. Ajuste ese valor en función de los requisitos de la carga de trabajo, el tamaño de los nodos y las restricciones de IP.

Integración de Microsoft Entra ID para el clúster

Es fundamental proteger el acceso hacia el clúster y desde él. Piense desde la perspectiva del clúster cuando efectúe las elecciones de seguridad:

• Acceso de dentro hacia fuera. Acceso de AKS a componentes de Azure, como la infraestructura de red, Azure Container Registry y Azure Key Vault. Autorice solo los recursos a los que el clúster tiene permitido acceder.
• Acceso de fuera hacia dentro. Proporcionar acceso a las identidades al clúster de Kubernetes. Autorice solo las entidades externas a las que se permite el acceso al servidor de API de Kubernetes y Azure Resource Manager.

Acceso de AKS a Azure

Hay dos maneras de administrar el acceso de AKS a Azure mediante Microsoft Entra ID: entidades de servicio o identidades administradas para recursos de Azure.

Entre las dos, se recomiendan las identidades administradas. Con las entidades de servicio, el usuario es responsable de administrar y rotar los secretos, ya sea manualmente o mediante programación. Con las identidades administradas, Microsoft Entra ID administra y realiza la autenticación y la rotación puntual de secretos automáticamente.

Se recomienda habilitar las identidades administradas para que el clúster pueda interactuar con los recursos externos de Azure mediante Microsoft Entra ID. Puede habilitar esta configuración solo durante la creación del clúster. Incluso si el Microsoft Entra ID no se usa inmediatamente, puede incorporarlo más adelante.

De forma predeterminada, el clúster usa dos identidades principales, la identidad del clúster y la identidad de kubelet. Los componentes del plano de control de AKS usan la identidad del clúster para administrar los recursos del clúster, incluidos los equilibradores de carga de entrada, las direcciones IP públicas administradas por AKS, etc. La identidad de kubelet se usa para la autenticación con Azure Container Registry (ACR). Algunos complementos también admiten la autenticación mediante una identidad administrada.

Por ejemplo, en el caso de dentro hacia fuera, vamos a estudiar el uso de identidades administradas cuando el clúster necesite extraer imágenes de un registro de contenedor. Esta acción requiere que el clúster obtenga las credenciales del registro. Una manera es almacenar esa información en forma de objeto de secreto de Kubernetes y usar imagePullSecrets para recuperar el secreto. No se recomienda este enfoque debido a las complejidades de seguridad. No solo necesita conocer previamente el secreto, sino también la divulgación de ese secreto a través de la canalización DevOps. Otro motivo es la sobrecarga operativa de la administración de la rotación del secreto. En su lugar, conceda acceso a acrPull a la identidad administrada de kubelet del clúster en el registro. Este enfoque soluciona estos problemas.

En esta arquitectura, el clúster tiene acceso a los recursos de Azure que están protegidos por Microsoft Entra ID y realizan operaciones que admiten identidades administradas. Asigne el control de acceso basado en rol de Azure (Azure RBAC) y los permisos a las identidades administradas del clúster, en función de las operaciones que el clúster pretenda hacer. El clúster se autentica en Microsoft Entra ID y, a continuación, se le permite o deniega el acceso en función de las funciones que se le hayan asignado. Estos son algunos ejemplos de esta implementación de referencia donde se han asignado roles integrados de Azure al clúster:

• Colaborador de red. La capacidad del clúster para controlar la red virtual de radio. Esta asignación de roles permite que la identidad asignada por el sistema de clúster AKS funcione con la subred dedicada para los servicios del controlador de entrada interno.
• Supervisión del publicador de métricas. La capacidad del clúster para enviar métricas a Azure Monitor.
• AcrPull. La capacidad del clúster para extraer imágenes de los registros de contenedor de Azure especificados.

Acceso al clúster

La integración de Microsoft Entra también simplifica la seguridad para el acceso de fuera hacia dentro. Supongamos que un usuario quiere usar kubectl. Como paso inicial, ejecuta el comando az aks get-credentials para obtener las credenciales del clúster. Microsoft Entra ID autenticará la identidad del usuario con los roles de Azure que tienen permitido obtener las credenciales del clúster. Para más información, consulte Permisos de los roles de clúster disponibles.

AKS permite el acceso a Kubernetes mediante el Microsoft Entra ID de dos maneras. La primera es usar Microsoft Entra ID como proveedor de identidades integrado con el sistema RBAC nativo de Kubernetes. La otra es usar Azure RBAC nativo para controlar el acceso al clúster. A continuación, se explican las dos.

Asociación de RBAC de Kubernetes a Microsoft Entra ID

Kubernetes admite el control de acceso basado en roles (RBAC) mediante lo siguiente:

• Un conjunto de permisos. Definido por un objeto Role o ClusterRole para permisos de todo el clúster.

• Enlaces que asignan usuarios y grupos a los que se les permite realizar las acciones. Definidos por un objeto RoleBinding o ClusterRoleBinding.

Kubernetes tiene algunos roles integrados como cluster-admin, edit, view, etc. Enlace esos roles a usuarios y grupos de Microsoft Entra para usar el directorio empresarial para administrar el acceso. Para más información, consulte Uso de RBAC de Kubernetes con la integraciónde Microsoft Entra.

Asegúrese de que los grupos de Microsoft Entra usados para el acceso al clúster y al espacio de nombres se incluyen en las revisiones de acceso de Microsoft Entra.

Uso de Azure RBAC para la autorización de Kubernetes

En lugar de usar RBAC nativo de Kubernetes (ClusterRoleBindings y RoleBindings) para la autorización con la autenticación integrada de Microsoft Entra, otra opción que recomendamos es usar Azure RBAC y las asignaciones de roles de Azure para aplicar comprobaciones de autorización en el clúster. Estas asignaciones de roles incluso se pueden agregar en los ámbitos de suscripción o grupo de recursos para que todos los clústeres del ámbito hereden un conjunto coherente de asignaciones de roles con respecto a quién tiene permisos para acceder a los objetos en el clúster de Kubernetes.

Para obtener más información, consulte Autorización de Azure RBAC para Kubernetes.

Cuentas locales

AKS admite la autenticación de usuarios de Kubernetes nativa. No se recomienda el acceso de usuario a los clústeres mediante este método. Se basa en certificados y se realiza de forma externa al proveedor de identidades principal, lo que dificulta el control de acceso y la gobernanza de los usuarios desde un punto central. Administre siempre el acceso al clúster mediante Microsoft Entra ID y configúrelo para deshabilitar explícitamente el acceso a la cuenta local.

En esta implementación de referencia, el acceso a través de cuentas de clúster locales se deshabilita explícitamente cuando se implementa el clúster.

Integración de Microsoft Entra ID para la carga de trabajo

De forma similar a las identidades administradas por el sistema de Azure para todo el clúster, puede asignar identidades administradas en el nivel de pod. Una identidad de carga de trabajo permite que la carga de trabajo hospedada tenga acceso a los recursos a través de Microsoft Entra ID. Por ejemplo, la carga de trabajo almacena archivos en Azure Storage. Cuando necesite acceder a esos archivos, el pod se autenticará en el recurso como una identidad administrada de Azure.

En esta implementación de referencia, las identidades administradas para pods se proporcionan a través de la identidad de carga de trabajo de Microsoft Entra ID en AKS. Esto se integra con las funcionalidades nativas de Kubernetes para federarse con proveedores de identidades externos. Para obtener más información sobre la federación de carga de trabajo de Microsoft Entra ID , consulte la información generalsiguiente.

Implementación de recursos de entrada

Los recursos de entrada de Kubernetes enrutan y distribuyen el tráfico entrante al clúster. Hay dos partes de los recursos de entrada:

• Equilibrador de carga interno. Administrado por AKS. Este equilibrador de carga expone el controlador de entrada a través de una dirección IP estática privada. Sirve de punto de contacto único que recibe los flujos entrantes.

  En esta arquitectura, se usa Azure Load Balancer. Se coloca fuera del clúster, en una subred dedicada a los recursos de entrada. Recibe el tráfico de Azure Application Gateway y la comunicación se realiza a través de TLS. Para información sobre el cifrado TLS para el tráfico entrante, consulte Flujo de tráfico de entrada.

• Controlador de entrada. Hemos elegido Traefik. Se ejecuta en el grupo de nodos de usuario del clúster. Recibe tráfico del equilibrador de carga interno, termina TLS y lo desvía a los pods de carga de trabajo a través de HTTP.

El controlador de entrada es un componente crítico del clúster. Tenga en cuenta estos puntos al configurar este componente.

• Como parte de las decisiones de diseño, elija un ámbito en el que se permitirá que opere el controlador de entrada. Por ejemplo, puede permitir que el controlador interactúe solo con los pods que ejecutan una carga de trabajo específica.

• Evite colocar réplicas en el mismo nodo para repartir la carga y garantizar la continuidad empresarial si un nodo está inactivo. Use podAntiAffinity para este propósito.

• Restrinja los pods para que se programen solo en el grupo de nodos de usuario mediante nodeSelectors. Esta configuración aislará la carga de trabajo y los pods del sistema.

• Abra puertos y protocolos que permitan a entidades específicas enviar tráfico al controlador de entrada. En esta arquitectura, Traefik solo recibe tráfico de Azure Application Gateway.

• El controlador de entrada debe enviar señales que indiquen el mantenimiento de los pods. Configure los valores readinessProbe y livenessProbe que supervisarán el mantenimiento de los pods en el intervalo especificado.

• Considere la posibilidad de restringir el acceso del controlador de entrada a recursos específicos y la de realizar determinadas acciones. Esa restricción puede implementarse mediante los permisos RBAC de Kubernetes. Por ejemplo, en esta arquitectura, se han concedido permisos a Traefik para ver, obtener y enumerar servicios y puntos de conexión usando reglas en el objeto ClusterRole de Kubernetes.

Para revisar el diseño de entrada utilizado en la arquitectura de referencia de contenedores Windows en AKS, consulte el artículo complementario.

Configuración del enrutador

El controlador de entrada usa rutas para determinar dónde enviar el tráfico. Las rutas especifican el puerto de origen en el que se recibe el tráfico e información sobre los puertos de destino y protocolos.

A continuación, se muestra un ejemplo de esta arquitectura:

Traefik usa el proveedor de Kubernetes para configurar las rutas. Los elementos annotations, tls y entrypoints indican que las rutas se atenderán a través de HTTPS. El elemento middlewares especifica que solo se permite el tráfico procedente de la subred de Azure Application Gateway. Las respuestas usarán la codificación gzip si el cliente acepta. Dado que Traefik realiza la terminación TLS, la comunicación con los servicios de back-end se realiza a través de HTTP.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

Protección del flujo de red

El flujo de red, en este contexto, se puede clasificar como:

• Tráfico de entrada. Desde el cliente a la carga de trabajo que se ejecuta en el clúster.

• Tráfico de salida. Desde un pod o un nodo del clúster a un servicio externo.

• Tráfico de pod a pod. Comunicación entre pods. Este tráfico incluye la comunicación entre el controlador de entrada y la carga de trabajo. Además, si la carga de trabajo se compone de varias aplicaciones implementadas en el clúster, la comunicación entre esas aplicaciones estará dentro de esta categoría.

• Tráfico de administración. Tráfico que va entre el cliente y el servidor de API de Kubernetes.

Descargue un archivo Visio de esta arquitectura.

Esta arquitectura tiene varios niveles de seguridad para proteger todos los tipos de tráfico.

Flujo de tráfico de entrada

La arquitectura solo acepta las solicitudes cifradas TLS del cliente. TLS v1.2 es la versión mínima permitida con un conjunto restringido de cifrados. La indicación de nombre de servidor (SNI) estricta está habilitada. TLS de un extremo a otro se configura a través de Application Gateway mediante el uso de dos certificados TLS diferentes, tal como se muestra en esta imagen.

Descargue un archivo Visio de esta arquitectura.

1. El cliente envía una solicitud HTTPS al nombre de dominio: bicycle.contoso.com. Ese nombre se asocia a través de un registro A de DNS a la dirección IP pública de Azure Application Gateway. Este tráfico se cifra para asegurarse de que no se puede inspeccionar o cambiar el tráfico entre el explorador cliente y la puerta de enlace.

2. Application Gateway cuenta con un firewall de aplicaciones web (WAF) integrado, negocia el protocolo de enlace TLS para bicycle.contoso.com y solo permite cifrados seguros. Application Gateway es un punto de terminación TLS, ya que es necesario para procesar reglas de inspección WAF y ejecutar reglas de enrutamiento que desvían el tráfico al back-end configurado. El certificado TLS se almacena en Azure Key Vault. Se accede mediante una identidad administrada asignada por el usuario integrada con Application Gateway. Para información sobre esta característica, consulte Terminación TLS con certificados de Key Vault.

3. A medida que el tráfico se mueve de Application Gateway al servidor back-end, se cifra de nuevo con otro certificado TLS (comodín para *.aks-ingress.contoso.com) mientras se reenvía al equilibrador de carga interno. Este nuevo cifrado garantiza que el tráfico poco seguro no fluya hacia la subred del clúster.

4. El controlador de entrada recibe el tráfico cifrado a través del equilibrador de carga. El controlador es otro punto de terminación TLS para *.aks-ingress.contoso.com y reenvía el tráfico a los pods de carga de trabajo a través de HTTP. Los certificados se almacenan en Azure Key Vault y se montan en el clúster mediante el controlador de la interfaz de almacenamiento de contenedor (CSI). Para más información, consulte Administración de secretos.

Puede implementar el tráfico TLS de un extremo a otro en cada salto hasta el pod de carga de trabajo. Asegúrese de medir el rendimiento, la latencia y el impacto operativo al tomar la decisión de proteger el tráfico de pod a pod. Para la mayoría de los clústeres de un solo inquilino, con un adecuado control de acceso basado en roles del plano de control y una serie de prácticas del ciclo de vida de desarrollo de software basta para cifrar con TLS hasta el controlador de entrada y protegerlo con un firewall de aplicaciones web (WAF). Esto minimizará la sobrecarga de administración de la carga de trabajo y el impacto en el rendimiento de la red. Los requisitos de cumplimiento y carga de trabajo determinarán dónde se realizará la terminación TLS.

Flujo de tráfico de salida

En esta arquitectura, se recomienda que todo el tráfico de salida del clúster se comunique a través de Azure Firewall o su propia aplicación virtual de red similar, en lugar de otras opciones, como NAT Gateway o proxy HTTP. Para el control de confianza cero y la capacidad de inspeccionar el tráfico, todo el tráfico de salida del clúster se mueve a través de Azure Firewall. Puede implementar esa opción mediante rutas definidas por el usuario (UDR). El siguiente salto de la ruta es la dirección IP privada de Azure Firewall. Aquí, Azure Firewall decide si se debe bloquear o permitir el tráfico de salida. Esta decisión se basa en las reglas específicas definidas en Azure Firewall o en las reglas integradas de inteligencia sobre amenazas.

Una alternativa al uso de Azure Firewall es usar la característica proxy HTTP de AKS. Toda la salida del tráfico del clúster se establece primero en la dirección IP del proxy HTTP, que decide reenviar el tráfico o quitarlo.

Con cualquiera de los métodos, revise las reglas de red de salida necesarias para AKS.

Una excepción al control de confianza cero es cuando el clúster necesita comunicarse con otros recursos de Azure. Por ejemplo, el clúster debe extraer una imagen actualizada del registro de contenedor o secretos de Azure Key Vault. El enfoque recomendado es usar Azure Private Link. La ventaja es que las subredes específicas llegan directamente al servicio en lugar del tráfico entre el clúster y los servicios que pasan por Internet. Una desventaja es que Private Link necesita una configuración adicional en lugar de usar el servicio de destino a través de su punto de conexión público. Además, no todos los servicios o las SKU de Azure admiten Private Link. En esos casos, considere la posibilidad de habilitar un Punto de conexión de servicio de Virtual Network en la subred para tener acceso al servicio.

Si Private Link o los puntos de conexión de servicio no son una opción, puede llegar a otros servicios a través de sus puntos de conexión públicos y controlar el acceso a través de reglas de Azure Firewall y el firewall integrado en el servicio de destino. Dado que este tráfico pasará por las direcciones IP estáticas del firewall, esas direcciones se pueden agregar a la lista de direcciones IP permitidas del servicio. Una desventaja es que Azure Firewall debe tener reglas adicionales para asegurarse de que solo se permite el tráfico de una subred específica. Tenga en cuenta esas direcciones cuando planee varias direcciones IP para el tráfico de salida con Azure Firewall; de lo contrario, podría llegar al agotamiento del puerto. Para más información sobre el planeamiento de varias direcciones IP, consulte Restringir y controlar el tráfico saliente.

Para revisar las consideraciones de salida específicas de Windows utilizadas en la arquitectura de referencia de contenedores Windows en AKS, consulte el artículo complementario.

Tráfico de pod a pod

De forma predeterminada, un pod puede aceptar el tráfico de cualquier otro pod del clúster. El elemento NetworkPolicy de Kubernetes se utiliza para restringir el tráfico de red entre pods. Aplique las directivas con prudencia; de lo contrario, podría darse una situación en la que un flujo de red crítico se bloqueara. Permita solo rutas de comunicación específicas, según sea necesario, como el tráfico entre el controlador de entrada y la carga de trabajo. Para más información, consulte las directivas de red.

Habilite la directiva de red cuando se aprovisione el clúster porque no se puede agregar más tarde. Hay algunas opciones para las tecnologías que implementan NetworkPolicy. Se recomienda Azure Network Policy, que requiere Azure Container Networking Interface (CNI), consulte la nota siguiente. Otras opciones incluyen Calico Network Policy, una opción de código abierto conocida. Tenga en cuenta Calico si debe administrar directivas de red para todo el clúster. Calico no está incluida en el soporte técnico estándar de Azure.

Para información, véase:Diferencias entre la directiva de red de Azure y las directivas de Calico y sus funcionalidades.

Tráfico de administración

Como parte de la ejecución del clúster, el servidor de API de Kubernetes recibirá el tráfico de los recursos que quieran realizar operaciones de administración en el clúster, como las solicitudes para crear recursos o la escala del clúster. Algunos ejemplos de estos recursos son el grupo de agentes de compilación en una canalización DevOps, una subred Bastion y los propios grupos de nodos. En lugar de aceptar este tráfico de administración de todas las direcciones IP, use la característica de intervalos IP autorizados de AKS para permitir solo el tráfico de intervalos IP autorizados al servidor de API.

Para más información, consulte Definición de intervalos IP de servidor de API autorizado.

Para un nivel de control adicional, a costa de complejidad adicional, puede aprovisionar un clúster de AKS privado. Mediante el uso de un clúster privado, puede asegurarse de que el tráfico entre el servidor de API y los grupos de nodos permanece solo en la red privada y no está expuesto a la red. Para más información, consulte Clústeres privados de AKS.

Adición de administración de secretos

Almacene los secretos en un almacén de claves administrado, como Azure Key Vault. La ventaja es que el almacén administrado controla la rotación de secretos, ofrece un cifrado de alta seguridad, proporciona un registro de auditoría de acceso y mantiene los secretos principales fuera de la canalización de implementación. En esta arquitectura, el firewall de Azure Key Vault está habilitado y configurado con conexiones de vínculo privado a los recursos de Azure que necesitan acceder a secretos y certificados.

Azure Key Vault está bien integrado con otros servicios de Azure. Use la característica integrada de esos servicios para acceder a los secretos. Para ver un ejemplo sobre cómo Azure Application Gateway accede a los certificados TLS para el flujo de entrada, consulte la sección Flujo de tráfico de entrada.

El modelo de permisos de RBAC de Azure para Key Vault permite asignar las identidades de carga de trabajo a la asignación de roles Usuario de secretos de Key Vault o Lector de Key Vault y acceder a los secretos. Para más información, consulte Acceso a Azure Key Vault mediante RBAC.

Acceso a los secretos del clúster

Deberá usar identidades de carga de trabajo para permitir que un pod acceda a los secretos de un almacén específico. Para facilitar el proceso de recuperación, use uncontrolador CSI de almacén de secretos. Cuando el pod necesita un secreto, el controlador se conecta al almacén especificado, recupera el secreto de un volumen y monta ese volumen en el clúster. A continuación, el pod puede obtener el secreto del sistema de archivos del volumen.

El controlador CSI tiene muchos proveedores para admitir varios almacenes administrados. En esta implementación, hemos elegido el controlador CSI del almacén de secretos de Azure Key Vault con el complemento para recuperar el certificado TLS de Azure Key Vault y cargarlo en el pod que ejecuta el controlador de entrada. Se realiza durante la creación del pod y el volumen almacena las claves públicas y privadas.

Almacenamiento de carga de trabajo

La carga de trabajo usada en esta arquitectura no tiene estado. Si necesita almacenar el estado, se recomienda conservarlo fuera del clúster. La guía para el estado de la carga de trabajo está fuera del ámbito de este artículo.

Para más información sobre las opciones de almacenamiento, consulte Opciones de almacenamiento de aplicaciones en Azure Kubernetes Service (AKS).

Administración de directivas

Una manera eficaz de administrar un clúster de AKS consiste en aplicar la gobernanza por medio de directivas. Kubernetes implementa directivas a través de OPA Gatekeeper. En el caso de AKS, las directivas se proporcionan a través de Azure Policy. Cada directiva se aplica a todos los clústeres de su ámbito. La aplicación de Azure Policy la determina en última instancia OPA Gatekeeper en el clúster; y todas las comprobaciones de directiva quedan registradas. Los cambios de directiva no se reflejan inmediatamente en el clúster, espere ver algunos retrasos.

Hay dos escenarios diferentes que Azure Policy ofrece para administrar los clústeres de AKS:

• Impedir o restringir la implementación de clústeres de AKS en un grupo de recursos o una suscripción mediante la evaluación de los estándares de las organizaciones. Por ejemplo, seguir una convención de nomenclatura, especificar una etiqueta, etc.
• Proteger el clúster de AKS mediante Azure Policy para Kubernetes.

Al establecer las directivas, aplíquelas en función de los requisitos de la carga de trabajo. Tenga en cuenta estos factores:

• ¿Desea establecer una colección de directivas (denominadas iniciativas) o elegir directivas individuales? Azure Policy incluye dos iniciativas integradas: una básica y otra restringida. Cada una de las iniciativas es una colección de directivas integradas aplicables a un clúster de AKS. Se recomienda seleccionar una de las iniciativas y elegir directivas adicionales para el clúster y los recursos (ACR, Application Gateway, Key Vault, etc.) que interactúan con el clúster, según los requisitos de su organización.

• ¿Desea auditar o denegar la acción? En el modo de auditoría, la acción está permitida, pero se identifica como no compatible. Utilice procesos específicos para comprobar periódicamente los estados no compatibles y adoptar las medidas necesarias. En el modo de denegación, la acción se bloquea porque infringe la directiva. Tenga cuidado cuando elija este modo porque puede ser demasiado restrictivo para que la carga de trabajo funcione.

• ¿Tiene áreas en la carga de trabajo que no deben ser compatibles por diseño? Azure Policy permite especificar espacios de nombres de Kubernetes que están exentos de la aplicación de directivas. Se recomienda seguir aplicando las directivas en el modo de auditoría para estar al tanto de esas instancias.

• ¿Debe cumplir requisitos que las directivas integradas no abarcan? Puede crear una definición de Azure Policy personalizada para aplicar sus directivas personalizadas de OPA Gatekeeper. No aplique directivas personalizadas directamente en el clúster. Para más información sobre cómo crear directivas personalizadas, consulte Creación y asignación de definiciones de directivas personalizadas.

• ¿Tiene requisitos a nivel de toda la organización? En caso afirmativo, agregue esas directivas en el nivel de grupo de administración. El clúster también debe asignar sus propias directivas para la carga de trabajo, aunque la organización tenga directivas genéricas.

• Las directivas de Azure se asignan a ámbitos específicos. Asegúrese de que las directivas de producción también se comprueben en el entorno de preproducción. De lo contrario, al hacer una implementación en el entorno de producción, es posible que se encuentre con restricciones adicionales imprevistas que no se tuvieron en cuenta en preproducción.

En esta implementación de referencia Azure Policy se habilita al crear el clúster de AKS y asigna la iniciativa restrictiva en el modo de auditoría para obtener visibilidad sobre los casos de incumplimiento.

La implementación también establece directivas adicionales que no forman parte de una iniciativa integrada. Esas directivas se establecen en el modo de denegación. Por ejemplo, hay una directiva para comprobar que las imágenes solo se extraigan del ACR implementado. Considere la posibilidad de crear sus propias iniciativas personalizadas. Integre las directivas aplicables a la carga de trabajo en una única asignación.

Para observar cómo funciona Azure Policy dentro del clúster, acceda a los registros de todos los pods en el espacio de nombres gatekeeper-system y a los registros de los pods azure-policy y azure-policy-webhook en el espacio de nombres kube-system.

Para revisar las consideraciones de Azure Policy específicas de Windows incluidas en la arquitectura de referencia de contenedores Windows en AKS, consulte el artículo complementario.

Escalabilidad de nodos y pods

Con una demanda creciente, Kubernetes puede escalar horizontalmente agregando más pods a los nodos existentes, mediante el escalado horizontal automático de pods (HPA). Cuando ya no se puedan programar más pods, el número de nodos debe aumentarse mediante el escalado automático de clústeres de AKS. Una solución de escalado completa debe contar con maneras de escalar las réplicas de pods y el número de nodos en el clúster.

Hay dos enfoques: el escalado automático o el escalado manual.

La forma manual o mediante programación requiere que supervise y establezca alertas sobre el uso de la CPU o las métricas personalizadas. Para el escalado de pods, el operador de la aplicación puede aumentar o disminuir el número de réplicas de pods ajustando el elemento ReplicaSet a través de las API de Kubernetes. Para el escalado de clústeres, una forma es recibir una notificación cuando se produce un error en el programador de Kubernetes. Otra manera es inspeccionar los pods pendientes a lo largo del tiempo. Puede ajustar el número de nodos a través de la CLI de Azure o el portal.

El enfoque recomendado es el escalado automático porque algunos de estos mecanismos manuales están integrados en el escalador automático.

Como enfoque general, empiece por pruebas de rendimiento con un número mínimo de pods y nodos. Use esos valores para establecer la expectativa de línea base. A continuación, use una combinación de métricas de rendimiento y escalado manual para localizar cuellos de botella y comprender la respuesta de la aplicación al escalado. Por último, use estos datos para establecer los parámetros del escalado automático. Para información sobre un escenario de ajuste del rendimiento con AKS, consulte Escenario de ajuste del rendimiento: Transacciones empresariales distribuidas.

Escalador horizontal automático de pods

El escalador horizontal automático de pods (HPA) es un recurso de Kubernetes que escala el número de pods.

En el recurso HPA, se recomienda establecer el número mínimo y máximo de réplicas. Estos valores restringen los límites de escalado automático.

HPA puede escalar en función del uso de la CPU, del uso de memoria y de métricas personalizadas. De forma preestablecida, solo se proporciona el uso de la CPU. La definición de HorizontalPodAutoscaler especifica los valores de destino de esas métricas. Por ejemplo, la especificación establece un uso objetivo de CPU. Mientras se ejecutan los pods, el controlador HPA usa Metrics API de Kubernetes para comprobar el uso de CPU de cada pod. Compara ese valor con el uso objetivo y calcula la proporción. A continuación, usa la proporción para determinar si los pods están sobreasignados o infraasignados. Se basa en el programador de Kubernetes para asignar nuevos pods a nodos o quitar pods de nodos.

Podría haber una condición de carrera en la que HPA compruebe antes de que se complete una operación de escalado. El resultado puede ser un cálculo de proporción incorrecto. Para los detalles, consulte Recuperación de eventos de escalado.

Si la carga de trabajo está orientada a eventos, una conocida opción de código abierto es KEDA. Tenga en cuenta KEDA si la carga de trabajo está controlada por un origen de eventos, como la cola de mensajes, en lugar de estar enlazada a la memoria o a la CPU. KEDA admite muchos orígenes de eventos (o escaladores). Puede encontrar la lista de escaladores de KEDA admitidos aquí incluido Azure Monitor Scaler; una manera cómoda de escalar las cargas de trabajo de KEDA en función de métricas de Azure Monitor.

Cluster Autoscaler

El escalador automático de clústeres es un componente de complemento de AKS que escala el número de nodos de un grupo de nodos. Se debe agregar durante el aprovisionamiento del clúster. Necesita un escalador automático de clústeres independiente para cada grupo de nodos de usuario.

El programador de Kubernetes desencadena el escalador automático de clústeres. Cuando el programador de Kubernetes no puede programar un pod debido a las restricciones de recursos, el escalado automático aprovisiona automáticamente un nuevo nodo en el grupo de nodos. Por el contrario, el escalador automático de clústeres comprueba la capacidad sin usar de los nodos. Si el nodo no se está ejecutando con una capacidad esperada, los pods se mueven a otro nodo y se quita el nodo no utilizado.

Al habilitar el escalador automático, establezca el número máximo y mínimo de nodos. Los valores recomendados dependen de la expectativa de rendimiento de la carga de trabajo, de cuánto se desea que crezca el clúster y de las implicaciones de costos. El número mínimo es la capacidad reservada para ese grupo de nodos. En esta implementación de referencia, el valor mínimo se establece en 2 debido a la naturaleza simple de la carga de trabajo.

En el grupo de nodos del sistema, el valor mínimo recomendado es 3.

Para revisar las consideraciones de escalado incluidas en la arquitectura de referencia de contenedores Windows en AKS, consulte el artículo complementario.

Decisiones de continuidad del negocio

Para mantener la continuidad el negocio, defina el Acuerdo de Nivel de Servicio para la infraestructura y la aplicación. Para información sobre el cálculo del tiempo de actividad mensual, consulte SLA para Azure Kubernetes Service (AKS).

Nodos de clúster

Para cumplir el nivel mínimo de disponibilidad de las cargas de trabajo, se necesitan varios nodos en un grupo de nodos. Si un nodo deja de funcionar, otro nodo del grupo de nodos del mismo clúster puede seguir ejecutando la aplicación. En cuanto a la confiabilidad, se recomiendan tres nodos para el grupo de nodos del sistema. Para el grupo de nodos de usuario, empiece con dos nodos al menos. Si necesita una mayor disponibilidad, aprovisione más nodos.

Aísle las aplicaciones de los servicios del sistema colocándolo en un grupo de nodos independiente, denominado grupo de nodos de usuario. De este modo, los servicios de Kubernetes se ejecutan en nodos dedicados y no compiten con la carga de trabajo. Se recomienda usar etiquetas y marcas para identificar el grupo de nodos para programar la carga de trabajo y asegurarse de que el grupo de nodos del sistema está marcado con CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

El mantenimiento regular del clúster, como las actualizaciones puntuales, es crucial para la confiabilidad. También se recomienda supervisar el mantenimiento de los pods a través de sondeos.

Disponibilidad de pods

Protección de los recursos de pods. Se recomienda encarecidamente que las implementaciones especifiquen los requisitos de los recursos de pods. Después, el programador puede programar correctamente el pod. La confiabilidad disminuiría considerablemente si no se pueden programar pods.

Establecimiento de presupuestos de interrupciones de pods. Este valor determina cuántas réplicas de una implementación pueden desactivarse durante un evento de actualización. Para más información, consulte Presupuestos de interrupciones de pods.

Configure varias réplicas en la implementación para controlar las interrupciones, como los errores de hardware. En el caso de los eventos planeados, como las actualizaciones, un presupuesto de interrupciones puede garantizar que exista el número necesario de réplicas de pods para controlar la carga esperada de la aplicación.

Establecimiento de cuotas de recursos en los espacios de nombres de la carga de trabajo. La cuota de recursos de un espacio de nombres garantizará que las solicitudes y los límites de pods se establezcan correctamente en una implementación. Para más información, consulte Aplicación de cuotas de recursos.

Establecimiento de solicitudes y límites de pods. La configuración de estos límites permite a Kubernetes asignar eficazmente recursos de CPU y memoria a los pods y tener una mayor densidad de contenedor en un nodo. Los límites también pueden aumentar la confiabilidad con costos reducidos debido a una mejor utilización del hardware.

Para calcular los límites, pruebe y establezca una línea de base. Comience con valores iguales para solicitudes y límites. A continuación, ajuste los valores gradualmente hasta que haya establecido un umbral que pueda provocar inestabilidad en el clúster.

Estos límites se pueden especificar en los manifiestos de implementación. Para más información, consulte Establecimiento de solicitudes y límites de pod.

Zonas de disponibilidad y compatibilidad con varias regiones

Si el Acuerdo de Nivel de Servicio requiere un tiempo de actividad mayor, protéjase frente a interrupciones mediante zonas de disponibilidad. Puede usar zonas de disponibilidad si la región las admite. Los componentes del plano de control y los nodos de los grupos de nodos se pueden distribuir entre las zonas. Si no está disponible una zona completa, un nodo de otra zona dentro de la región sigue estando disponible. Cada grupo de nodos se asigna a un conjunto de escalado de máquinas virtuales independiente, que administra las instancias de nodos y la escalabilidad. El servicio AKS administra las operaciones y la configuración del conjunto de escalado. Estas son algunas consideraciones al habilitar varias zonas:

• Infraestructura completa. Elija una región que admita zonas de disponibilidad. Para más información, consulte Limitaciones y disponibilidad de región. Si desea comprar un Acuerdo de Nivel de Servicio de tiempo de actividad, elija una región que admita esa opción. El Acuerdo de Nivel de Servicio de tiempo de actividad es mayor cuando se usan zonas de disponibilidad.

• Clúster. Las zonas de disponibilidad solo se pueden establecer cuando se crea el grupo de nodos y no se pueden cambiar más adelante. Los tamaños de nodo deben admitirse en todas las zonas para que sea posible la distribución esperada. El conjunto de escalado de máquinas virtuales subyacente proporciona la misma configuración de hardware entre zonas.

  La compatibilidad con varias zonas no solo se aplica a los grupos de nodos, sino también al plano de control. El plano de control de AKS abarcará las zonas solicitadas, como los grupos de nodos. Si no usa la compatibilidad con zonas en el clúster, no se garantiza que los componentes del plano de control se distribuyan entre las zonas de disponibilidad.

• Recursos dependientes. Para obtener una ventaja de zona completa, todas las dependencias de servicio también deben admitir zonas. Si un servicio dependiente no admite zonas, es posible que un error de zona provoque un error en el servicio.

Por ejemplo, un disco administrado está disponible en la zona en la que se aprovisiona. En caso de error, el nodo podría moverse a otra zona, pero el disco administrado no se moverá con el nodo a esa zona.

Para simplificar, en esta arquitectura, AKS se implementa en una sola región con grupos de nodos que abarcan las zonas de disponibilidad 1, 2 y 3. Otros recursos de la infraestructura, como Azure Firewall y Application Gateway se implementan en la misma región también con compatibilidad con varias zonas. La replicación geográfica se habilita para Azure Container Registry.

Varias regiones

La habilitación de zonas de disponibilidad no será suficiente si toda la región deja de funcionar. Para tener una mayor disponibilidad, ejecute varios clústeres de AKS en diferentes regiones.

• Use regiones emparejadas. Considere la posibilidad de usar una canalización de CI/CD que esté configurada para usar una región emparejada a fin de recuperarse de errores de región. Una ventaja de utilizar regiones emparejadas es la confiabilidad durante las actualizaciones. Azure se asegura de que solo se actualice una región del par cada vez. Ciertas herramientas de DevOps, como flux, pueden facilitar las implementaciones de varias regiones.

• Si un recurso de Azure admite redundancia geográfica, proporcione la ubicación en la que el servicio redundante tendrá su secundario. Por ejemplo, la habilitación de la replicación geográfica para Azure Container Registry replicará automáticamente las imágenes en las regiones de Azure seleccionadas y proporcionará un acceso continuado a las imágenes incluso si una región experimenta una interrupción.

• Elija un enrutador de tráfico que pueda distribuir el tráfico entre zonas o regiones, en función de sus requisitos. Esta arquitectura implementa Azure Load Balancer porque puede distribuir el tráfico no web entre zonas. Si necesita distribuir el tráfico entre regiones, se debe tomar en consideración Azure Front Door. Para otras consideraciones, consulte Elección de equilibrador de carga.

Recuperación ante desastres

En caso de error en la región primaria, debería poder crear rápidamente una instancia nueva en otra región. Estas son algunas recomendaciones:

• Use regiones emparejadas.

• Una carga de trabajo sin estado se puede replicar de forma eficaz. Si necesita almacenar el estado en el clúster (no recomendado), asegúrese de hacer una copia de seguridad de los datos con frecuencia en la región emparejada.

• Integre la estrategia de recuperación, como la replicación en otra región, como parte de la canalización de DevOps para satisfacer sus objetivos de nivel de servicio (SLO).

• Al aprovisionar cada servicio de Azure, elija características que admitan la recuperación ante desastres. Por ejemplo, en esta arquitectura, Azure Container Registry está habilitado para la replicación geográfica. Si una región deja de funcionar, puede extraer imágenes de la región replicada.

Copia de seguridad del clúster

Para muchas arquitecturas, el aprovisionamiento de un nuevo clúster y su devolución al estado operativo se pueden lograr a través del [arranque del clúster}(#cluster-bootstrapping) basado en GitOps, seguido de la implementación de la aplicación. Sin embargo, si hay un estado crítico de los recursos, como ConfigMaps, trabajos y potencialmente secretos que, por algún motivo, no se pueden capturar en el proceso de arranque, considere la posibilidad de usar la estrategia de recuperación. Por lo general, se recomienda ejecutar cargas de trabajo sin estado en Kubernetes, pero si su arquitectura incluye estado basado en disco, también deberá considerar su estrategia de recuperación para ese contenido.

Cuando la copia de seguridad del clúster deba formar parte de la estrategia de recuperación, tendrá que instalar una solución que coincida con los requisitos empresariales dentro del clúster. Este agente será responsable de insertar el estado de los recursos del clúster en un destino de su elección y coordinar las instantáneas de volumen persistentes basadas en Azure Disk.

Velero de VMware es un ejemplo de una solución común de copia de seguridad de Kubernetes que puede instalar y administrar directamente. Como alternativa, la extensión de copia de seguridad de AKS se puede usar para proporcionar una implementación administrada de Velero. La extensión de copia de seguridad de AKS admite la copia de seguridad de recursos de Kubernetes y de volúmenes persistentes, con programaciones y ámbito de copia de seguridad externalizados como configuración del almacén en Azure Backup.

La implementación de referencia no implementa la copia de seguridad, lo que implicaría la administración, supervisión, pago y protección de recursos adicionales de Azure en la arquitectura; por ejemplo, una cuenta de Azure Storage, una configuración y almacén de Azure Backup y Acceso de confianza. GitOps combinado con la intención de ejecutar la carga de trabajo sin estado es la solución de recuperación implementada.

Elige y valida una solución que cumpla el objetivo empresarial, incluido el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) definidos. Defina este proceso de recuperación en un runbook de equipo y póngalo en práctica para todas las cargas de trabajo críticas para la empresa.

SLA del servidor de API de Kubernetes

AKS se puede usar como servicio gratuito, pero ese nivel no ofrece un Acuerdo de Nivel de Servicio con respaldo financiero. Para obtener ese contrato de nivel de servicio, debe elegir el nivel Estándar. Se recomienda que todos los clústeres de producción usen el nivel Estándar. Reserve clústeres de nivel Gratis para los clústeres de preproducción. Cuando se combina con Azure Availability Zones, el Acuerdo de Nivel de Servicio de la API de Kubernetes se incrementa al 99,95 %. Los grupos de nodos y otros recursos se incluyen bajo su propio Acuerdo de Nivel de Servicio.

Compensación

Existe un equilibrio entre costo y disponibilidad en la implementación de la arquitectura entre zonas y, especialmente, regiones. Algunas características de replicación, como la replicación geográfica en Azure Container Registry, están disponibles en las SKU Premium, lo que resulta más caro. El costo también aumentará, ya que se aplican cargos de ancho de banda cuando el tráfico se mueve entre zonas y regiones.

Además, se espera una latencia de red adicional en la comunicación de los nodos entre zonas o regiones. Mida el impacto de esta decisión arquitectónica en la carga de trabajo.

Prueba con simulaciones y conmutaciones por error forzadas

Garantice la confiabilidad mediante pruebas de conmutación por error forzadas con interrupciones simuladas, como la detención de un nodo y la desactivación de todos los recursos de AKS en una zona determinada para simular un error de zona o invocar un fallo de dependencia externa. Azure Chaos Studio también puede aprovecharse para simular varios tipos de interrupciones en Azure y en el clúster.

Para más información, consulte Azure Chaos Studio.

Supervisión y recopilación de métricas

Azure Monitor Container Insights es la herramienta recomendada para supervisar el rendimiento de las cargas de trabajo de contenedor, ya que puede ver eventos en tiempo real. Captura los registros de contenedor de los pods en ejecución y los agrega para su visualización. También recopila información de la API de métricas sobre la utilización de memoria y CPU para supervisar el mantenimiento de los recursos y cargas de trabajo en ejecución. También puede usarla para supervisar el rendimiento a medida que se escalan los pods. Incluye la recopilación de datos de telemetría críticos para la supervisión, el análisis y la visualización de los datos recopilados para identificar tendencias y configurar alertas para recibir notificaciones proactivas de problemas críticos.

La mayoría de las cargas de trabajo hospedadas en pods emiten métricas de Prometheus. Container Insights es capaz de integrarse con Prometheus para ver las métricas de aplicación y carga de trabajo que recopila de nodos y Kubernetes.

Hay algunas soluciones de terceros que se integran con Kubernetes que puede aprovechar, como Datadog, Grafana o New Relic, si su organización ya las usa.

Con AKS, Azure administra algunos servicios principales de Kubernetes y los registros de los componentes del plano de control de AKS se implementan en Azure como registros de recursos. Se recomienda que la mayoría de los clústeres tengan los siguientes elementos habilitados en todo momento, ya que pueden ayudarle a solucionar problemas del clúster y tener una densidad de registro relativamente baja:

• Registro sobre ClusterAutoscaler para obtener observabilidad de las operaciones de escalado. Para más información, consulte Recuperación de registros y estado del escalador automático del clúster.
• KubeControllerManager para tener observabilidad de la interacción entre Kubernetes y el plano de control de Azure.
• KubeAuditAdmin para tener observabilidad de las actividades que modifican el clúster. No hay ninguna razón para habilitar KubeAudit y KubeAuditAdmin, ya que KubeAudit es un superconjunto de KubeAuditAdmin que también incluye operaciones que no modifican (lectura).
• Guard captura el Microsoft Entra ID y las auditorías de RBAC de Azure.

Puede resultar muy útil habilitar otras categorías de registro, como KubeScheduler o KubeAudit, durante el desarrollo temprano del ciclo de vida del clúster o de la carga de trabajo, donde el escalado automático del clúster, la ubicación y programación de pods y datos similares agregados podrían ayudar a solucionar problemas de operaciones de clúster o carga de trabajo. Mantener los registros de solución de problemas extendidos a jornada completa, una vez que se han terminado las necesidades de solución de problemas, ingerir y almacenar en Azure Monitor se puede considerar como un costo innecesario.

Aunque Azure Monitor incluye un conjunto de consultas de registro existentes con las que empezar, también puede usarlas como base para ayudar a crear sus propias consultas. A medida que crece la biblioteca, puede guardar y reutilizar consultas de registro mediante uno o varios paquetes de consultas. La biblioteca personalizada de consultas ayuda a habilitar la observabilidad adicional en el estado y el rendimiento de los clústeres de AKS y a dar soporte a los objetivos de nivel de servicio (SLO).

Para más información sobre nuestros procedimientos recomendados de supervisión para AKS, consulte Supervisión de Azure Kubernetes Service (AKS) con Azure Monitor.

Para revisar las consideraciones de supervisión específicas de Windows incluidas en la arquitectura de referencia de contenedores Windows en AKS, consulte el artículo complementario.

Habilitación de la recuperación automática

Supervise el mantenimiento de los pods estableciendo sondeos de ejecución y preparación. Si se detecta un pod que no responde, Kubernetes reinicia el pod. El sondeo de ejecución determina si el pod es correcto. Si no responde, Kubernetes reiniciará el pod. El sondeo de preparación determina si el pod está listo para recibir solicitudes o tráfico.

Actualizaciones del clúster de AKS

Es primordial definir una estrategia de actualización que sea coherente con los requisitos de la empresa. Comprender el nivel de previsibilidad de la fecha y hora de actualización de la versión del clúster de AKS o de sus nodos y el grado de control deseado sobre qué imagen o binarios específicos se instalan son aspectos fundamentales que delinearán su proyecto de actualización del clúster de AKS. La previsibilidad está ligada a dos propiedades principales de actualización del clúster de AKS que son la cadencia de actualización y la ventana de mantenimiento. El control reside en si las actualizaciones se instalan manual o automáticamente. Las organizaciones con clústeres de AKS que no están sujetas a una estricta normativa de seguridad podrían considerar actualizaciones semanales o incluso mensuales, mientras que el resto debe actualizar los parches con etiqueta de seguridad tan pronto como estén disponibles (diariamente). Las organizaciones que operan clústeres de AKS como infraestructura inmutable no los están actualizando. Esto significa que no se realizan actualizaciones automáticas ni manuales. En su lugar, cuando una actualización deseada está disponible, se implementa un sello de réplica y solo cuando la nueva instancia de infraestructura está lista se vacía la antigua, lo que les proporciona el máximo nivel de control.

Una vez determinado el plan de actualización del clúster de AKS, se puede mapear fácilmente en las opciones de actualización disponibles para los nodos de AKS y la versión del clúster de AKS:

• Nodos de AKS:

  1. Ninguna actualización/Actualizaciones manuales: esta opción se usa para infraestructuras inmutables o cuando se prefieren las actualizaciones manuales. Así se consigue un mayor nivel de previsibilidad y control sobre las actualizaciones de los nodos de AKS.
  2. Actualizaciones automáticas desatendidas: AKS ejecuta actualizaciones nativas del sistema operativo. Esto proporciona previsibilidad al configurar ventanas de mantenimiento alineadas con lo que conviene la empresa. Podría basarse en las horas punta y en lo que es mejor desde el punto de vista operativo. El nivel de control es bajo, ya que no es posible saber de antemano qué se va a instalar específicamente en el nodo de AKS.
  3. Actualizaciones automáticas de imágenes de nodo: se recomienda actualizar automáticamente las imágenes de nodo de AKS cuando estén disponibles nuevos discos duros virtuales (VHD). Diseñe las ventanas de mantenimiento para que se ajusten al máximo a las necesidades de la empresa. Para las actualizaciones de VHD con etiqueta de seguridad, se recomienda configurar una ventana de mantenimiento diaria que ofrezca la menor previsibilidad. Las actualizaciones regulares de VHD pueden configurarse con una ventana de mantenimiento semanal, quincenal o incluso mensual. En función de si la necesidad es de VHD con etiqueta de seguridad o normales, combinada con la ventana de mantenimiento programada, la previsibilidad fluctúa para ofrecer más o menos flexibilidad y ajustarse a las necesidades de la empresa. Aunque lo ideal sería dejar esto siempre en manos de las necesidades empresariales, la realidad obliga a las organizaciones a encontrar el punto de inflexión. El nivel de control es bajo, ya que no es posible saber de antemano qué binarios concretos se han incluido en un nuevo VHD y, aun así, este tipo de actualizaciones automáticas son la opción recomendada, ya que las imágenes son examinadas antes de estar disponibles.

  Nota:

  Para obtener más información sobre cómo configurar las actualizaciones automáticas de los nodos de AKS, consulte Actualización automática de las imágenes del sistema operativo del nodo.

• Versión del clúster de AKS:

  1. Ninguna actualización/Actualizaciones manuales: esta opción se usa para infraestructuras inmutables o cuando se prefieren las actualizaciones manuales. Esto logra la mayor previsibilidad de nivel y el control sobre las actualizaciones de la versión del clúster de AKS. Se recomienda optar por ello, ya que de este modo se tiene un control total y se ofrece la posibilidad de probar una nueva versión del clúster de AKS (es decir, de 1.14.x a 1.15.x) en entornos inferiores antes de pasar a producción.
  2. Actualizaciones automáticas: no se recomienda aplicar revisiones o actualizar automáticamente un clúster de producción de ninguna forma (es decir, de 1.16.x a 1.16.y) a la nueva versión de clúster de AKS disponible sin haberla probado adecuadamente en entornos inferiores. Aunque los componentes ascendentes de Kubernetes y las actualizaciones de la versión del clúster de AKS se coordinan proporcionando una cadencia regular, la recomendación sigue siendo mantenerse a la defensiva con los clústeres de AKS en producción para aumentar la previsibilidad y el control sobre el proceso de actualización. En cambio, considere esta configuración para entornos inferiores como parte de la excelencia operativa para permitir ejecuciones proactivas de pruebas rutinarias y así detectar posibles problemas con la máxima antelación.

Mantenga actualizada la versión de Kubernetes con las versiones N-2 admitidas. La actualización a la versión más reciente de Kubernetes es fundamental porque se publican nuevas versiones con frecuencia.

Para más información, consulte Actualización regular a la versión más reciente de Kubernetes y Actualización de un clúster de Azure Kubernetes Service (AKS).

La notificación de los eventos que genera el clúster, como la disponibilidad de la nueva versión de AKS del clúster, se puede lograr mediante el tema del sistema de AKS para Azure Event Grid. La implementación de referencia implementa este tema del sistema de Event Grid para que pueda suscribirse al evento Microsoft.ContainerService.NewKubernetesVersionAvailable desde la solución de notificación de la secuencia de eventos.

Actualizaciones semanales

AKS proporciona nuevas imágenes de nodo que tienen las actualizaciones más recientes del sistema operativo y el entorno de ejecución. Estas nuevas imágenes no se aplican automáticamente. Es responsable de decidir con qué frecuencia se deben actualizar las imágenes. Se recomienda tener un proceso para actualizar la imagen base de los grupos de nodos semanalmente. Para obtener más información, consulte Actualización de la imagen de nodo de Azure Kubernetes Service (AKS) y Notas de la versión de AKS.

Actualizaciones diarias

Entre las actualizaciones de imágenes, los nodos de AKS descargan e instalan revisiones del sistema operativo y el entorno de ejecución de forma individual. Una instalación puede requerir que se reinicien las VM de los nodos. AKS no reiniciará los nodos debido a actualizaciones pendientes. Tiene un proceso que supervisa los nodos de las actualizaciones aplicadas que requieren un reinicio y realiza el reinicio de esos nodos de una manera controlada. Una opción de código abierto es Kured (demonio de reinicio de Kubernetes).

Al mantener las imágenes de nodo sincronizadas con la última versión semanal, se minimizarán estas solicitudes de reinicio ocasionales a la vez que se mantiene una posición de seguridad mejorada. Confiar solo en las actualizaciones de imágenes de nodo garantizará la compatibilidad con AKS y la revisión de seguridad semanal. Mientras que la aplicación de actualizaciones diarias solucionará los problemas de seguridad con mayor rapidez, no se han probado necesariamente en AKS. Siempre que sea posible, use la actualización de imagen de nodo como estrategia de revisión de seguridad semanal principal.

Supervisión de la seguridad

Supervise la infraestructura de contenedores tanto de las amenazas activas como de los potenciales riesgos de la seguridad:

• Habilite Microsoft Defender para contenedores para identificar y corregir las recomendaciones de Defender for Cloud para las imágenes de contenedor.
• Microsoft Defender para contenedores examina periódicamente las imágenes de contenedor en busca de vulnerabilidades.
• Microsoft Defender para contenedores también genera alertas de seguridad en tiempo real para actividades sospechosas.
• Para información sobre la protección de la seguridad aplicada a los hosts de máquina virtual de AKS, consulte Protección de la seguridad en el sistema operativo del host.

Operaciones de clúster y de carga de trabajo (DevOps)

A continuación, se indican algunas consideraciones. Para más información, consulte el pilar Excelencia operativa.

Arranque del clúster

Una vez completado el aprovisionamiento, tiene un clúster en funcionamiento, pero es posible que todavía haya pasos necesarios antes de implementar las cargas de trabajo. El proceso de preparación del clúster se llama arranque y puede constar de acciones como la implementación de las imágenes de los requisitos previos en los nodos del clúster, la creación de espacios de nombres y cualquier otra cosa que satisfaga los requisitos del caso de uso o la organización.

Para reducir la brecha entre un clúster aprovisionado y un clúster que se ha configurado correctamente, los operadores del clúster deben pensar en el aspecto que tendrá su proceso de arranque único y preparar los recursos pertinentes de antemano. Por ejemplo, si es importante que Kured se ejecute en cada nodo antes de implementar las cargas de trabajo de aplicación, el operador del clúster querrá asegurarse de que ya exista una instancia de ACR que contenga la imagen de Kured de destino antes de aprovisionar el clúster.

El proceso de arranque se puede configurar mediante uno de los métodos siguientes:

• Configuración propia con una herramienta similar a Flux o Argo CD
• Pipelines
• Extensión de clúster Flux v2 con GitOps

Una de las principales ventajas de usar la extensión de clúster Flux v2 con GitOps para AKS es que realmente no hay ninguna diferencia entre un clúster aprovisionado y un clúster arrancado. Configura el entorno con una base de administración sólida en el futuro y también admite la inclusión de ese arranque como plantillas de recursos para alinearse con la estrategia de IaC.

Por último, cuando se usa la extensión, no es necesario kubectl para ninguna parte del proceso de arranque y el uso del acceso basado en kubectl se puede reservar para situaciones de interrupción de emergencia. Entre las plantillas para las definiciones de recursos de Azure y el arranque de manifiestos mediante la extensión de GitOps, se pueden realizar todas las actividades de configuración normales sin necesidad de usar kubectl.

Aislamiento de las responsabilidades de la carga de trabajo

Divida la carga de trabajo por equipos y tipos de recursos para administrar cada parte de forma individual.

Comience por una carga de trabajo básica que contenga los componentes fundamentales y vaya construyendo sobre ella. Una tarea inicial puede ser configurar las redes. Aprovisione las redes virtuales para el centro y los radios, y las subredes dentro de esas redes. Por ejemplo, el radio tiene subredes independientes para los grupos de nodos de usuario y del sistema, y los recursos de entrada. Una subred para Azure Firewall en el centro.

Otra parte podría ser integrar la carga de trabajo básica con Microsoft Entra ID.

Uso de la infraestructura como código (IaC)

Elija un método declarativo idempotente sobre un enfoque imperativo, siempre que sea posible. En lugar de escribir una secuencia de comandos que especifiquen opciones de configuración, use la sintaxis declarativa que describe los recursos y sus propiedades. Una opción es una plantilla de Azure Resource Manager (ARM). Otra es Terraform.

Asegúrese de que aprovisiona los recursos según las directivas de control. Por ejemplo, al seleccionar los tamaños de máquina virtual correctos, manténgase dentro de las restricciones de costos y las opciones de zona de disponibilidad para que coincidan con los requisitos de la aplicación.

Si tiene que escribir una secuencia de comandos, use la CLI de Azure. Estos comandos cubren una variedad de servicios de Azure y se pueden automatizar mediante scripting. La CLI de Azure es compatible con Windows y Linux. Otra opción multiplataforma es Azure PowerShell. Su elección dependerá del conjunto de aptitudes preferidas.

Almacene y cree versiones de los scripts y los archivos de plantillas en el sistema de control de código fuente.

Carga de trabajo de CI/CD

Las canalizaciones de flujo de trabajo e implementación deben tener la capacidad de crear e implementar aplicaciones de forma continua. Las actualizaciones se deben implementar de forma segura y rápida, y poderse revertir en caso de que haya problemas.

La estrategia de implementación debe incluir una canalización de entrega continua (CD) confiable y automatizada. Los cambios en las imágenes de contenedor de carga de trabajo deben implementarse automáticamente en el clúster.

En esta arquitectura, hemos elegido las Acciones de GitHub para administrar el flujo de trabajo y la implementación. Otras opciones populares son Azure DevOps Services y Jenkins.

Clúster de CI/CD

Descargue un archivo Visio de esta arquitectura.

En lugar de usar un enfoque imperativo como kubectl, use herramientas que sincronicen automáticamente los cambios del clúster y del repositorio. Para administrar el flujo de trabajo, como el lanzamiento de una nueva versión y la validación de esa versión antes de la implementación en producción, tome en consideración un flujo de GitOps.

Una parte esencial del flujo de CI/CD es el arranque de un clúster recién aprovisionado. Un enfoque de GitOps es útil para este fin, lo que permite a los operadores definir de forma declarativa el proceso de arranque como parte de la estrategia de IaC y ver la configuración reflejada en el clúster automáticamente.

Cuando se usa GitOps, se implementa un agente en el clúster para asegurarse de que el estado del clúster esté coordinado con la configuración almacenada en el repositorio de Git privado. Un agente de este tipo es Flux, que usa uno o varios operadores del clúster para desencadenar implementaciones dentro de Kubernetes. Flux realiza estas tareas:

• Supervisa todos los repositorios configurados.
• Detecta los nuevos cambios de configuración.
• Desencadena implementaciones.
• Actualiza la configuración de ejecución deseada en función de los cambios.

También puede establecer directivas que rijan cómo se implementan esos cambios.

Este es un ejemplo que muestra cómo automatizar la configuración del clúster con GitOps y Flux:

Descargue un archivo Visio de esta arquitectura.

1. Un desarrollador confirma los cambios en el código fuente, como los archivos de configuración YAML, que se almacenan en un repositorio de Git. Después, los cambios se insertan en un servidor de Git.

2. Flux se ejecuta en un pod junto con la carga de trabajo. Flux tiene acceso de solo lectura al repositorio de Git para asegurarse de que Flux solo aplica los cambios solicitados por los desarrolladores.

3. Flux reconoce los cambios en la configuración y los aplica mediante los comandos kubectl.

4. Los desarrolladores no tienen acceso directo a la API de Kubernetes a través de kubectl.

5. Tenga directivas de rama en el servidor de Git. De este modo, varios desarrolladores pueden aprobar un cambio mediante una solicitud de incorporación de cambios antes de que se aplique a producción.

Aunque GitOps y Flux se pueden configurar manualmente, se recomienda la extensión de clúster de GitOps con Flux v2 para AKS.

Estrategias de implementación de carga de trabajo y clúster

Implemente cualquier cambio (componentes de arquitectura, carga de trabajo, configuración de clúster) en al menos un clúster AKS de preproducción. Si lo hace, simulará el cambio y podrá resolver problemas antes de la implementación en producción.

Ejecute pruebas o validaciones en cada fase antes de pasar a la siguiente para asegurarse de que puede insertar actualizaciones en el entorno de producción de una manera muy controlada y minimizar la interrupción de problemas de implementación imprevistos. Esta implementación debe seguir un patrón similar al de producción, y usar la misma canalización de Acciones de GitHub u operadores de Flux.

Las técnicas de implementación avanzada, como la implementación azul-verde, pruebas A/B y versiones de valores controlados, requerirán un proceso adicional y herramientas potenciales. Flagger es una conocida solución de código abierto que le ayudará a resolver sus escenarios de implementación avanzada.

Administración de costos

Empiece por revisar la lista de comprobación de diseño de optimización de costos y la lista de recomendaciones descritas en Marco de buena arquitectura para AKS. Use lacalculadora de precios de Azure para estimar los costos de los servicios usados en la arquitectura. Otros procedimientos recomendados se describen en la sección Optimización de costos enMarco de buena arquitectura de Microsoft Azure.

Considere la posibilidad de habilitar el análisis de costos de AKS para la asignación de costos de infraestructura de clúster pormenorizadas mediante construcciones específicas de Kubernetes.

Para revisar las consideraciones de administración de costos específicas de las cargas de trabajo basadas en Windows incluidas en la arquitectura de referencia de contenedores Windows en AKS, consulte el artículo complementario.

Aprovisionamiento

• No hay ningún costo asociado con AKS para la implementación, administración y operaciones del clúster de Kubernetes. Lo que influye en el costo son las instancias de máquina virtual, el almacenamiento, los datos de registro y los recursos de red consumidos por el clúster. Considere la posibilidad de elegir máquinas virtuales más baratas para grupos de nodos de sistema. La SKU de DS2_v2 es un tipo de máquina virtual típico para el grupo de nodos del sistema.

• No tenga la misma configuración para los entornos de desarrollo/pruebas y los de producción. Las cargas de trabajo de producción tienen requisitos adicionales para la alta disponibilidad y suelen ser más costosas. Esta configuración no es necesaria en el entorno de desarrollo y pruebas.

• Para cargas de trabajo de producción, agregue un Acuerdo de Nivel de Servicio de tiempo de actividad. Sin embargo, se ahorra con los clústeres diseñados para desarrollo/pruebas o cargas de trabajo experimentales en los que no es necesario garantizar la disponibilidad. Por ejemplo, SLO es suficiente. Además, si la carga de trabajo lo admite, considere la posibilidad de usar grupos de nodos de acceso puntual dedicados que ejecuten VM de acceso puntual.

  En el caso de cargas de trabajo que no son de producción que incluyen Azure SQL Database o Azure App Service como parte de la arquitectura de la carga de trabajo de AKS, evalúe si puede usar suscripciones de desarrollo/pruebas de Azure para recibir descuentos de servicio.

• En lugar de comenzar con un clúster sobredimensionado para satisfacer las necesidades de escalado, aprovisione un clúster con un número mínimo de nodos y permita que el escalador automático del clúster supervise y tome las decisiones de tamaño.

• Establezca las solicitudes y los límites de pod para permitir que Kubernetes asigne recursos de nodo con mayor densidad, de modo que se utilice la capacidad del hardware.

• La habilitación de los diagnósticos en el clúster puede aumentar el costo.

• Si se espera que la carga de trabajo se realice durante un período largo, puede confirmar instancias reservadas de máquina virtual de uno o tres años para reducir los costos de nodo. Para obtener más información, vea Máquinas virtuales reservadas.

• Use etiquetas al crear grupos de nodos. Las etiquetas son útiles para crear informes personalizados para realizar el seguimiento de los costos incurridos. Las etiquetas proporcionan la capacidad de realizar un seguimiento del total de gastos y de asignar cualquier costo a un equipo o recurso específico. Además, si el clúster se comparte entre equipos, cree informes de devolución por consumidor para identificar los costos medidos de servicios en la nube compartidos. Para más información, consulte Especificación de un valor taint o una etiqueta para un grupo de nodos.

• Las transferencias de datos entre las zonas de disponibilidad de una región no son gratuitas. Si la carga de trabajo es de varias regiones o hay transferencias entre zonas de disponibilidad, espere un costo de ancho de banda adicional. Para más información, consulte Tráfico entre zonas de facturación y regiones.

• Cree presupuestos para permanecer dentro de las restricciones de costo identificadas por la organización. Una forma consiste en crear presupuestos a través de Azure Cost Management. También puede crear alertas para recibir notificaciones cuando se superen determinados umbrales. Para más información, consulte Creación de un presupuesto con una plantilla.

Supervisión

Con el fin de supervisar el costo de todo el clúster, junto con el costo de proceso también se recopila información de costo del almacenamiento, el ancho de banda, el firewall y los registros. Azure proporciona varios paneles para supervisar y analizar el costo:

• Azure Advisor

• Azure Cost Management

Idealmente, supervise el costo en tiempo real o, al menos, a una cadencia regular para tomar medidas antes del final del mes, cuando ya se hayan calculado los costos. Supervise también la tendencia mensual a lo largo del tiempo para mantenerse dentro del presupuesto.

Para tomar decisiones controladas por datos, identifique qué recurso (nivel pormenorizado) supone más costo. Tenga unos buenos conocimientos de los medidores que se usan para calcular el uso de cada recurso. Mediante el análisis de métricas, puede determinar si la plataforma tiene un tamaño sobredimensionado. Puede ver los medidores de uso en las métricas de Azure Monitor.

Optimización

Actúe según las recomendaciones proporcionadas por Azure Advisor. Existen otras formas de optimización:

• Habilite el escalador automático de clústeres para detectar y quitar nodos infrautilizados en el grupo de nodos.

• Elija una SKU inferior para los grupos de nodos, si la carga de trabajo lo admite.

• Si la aplicación no requiere el escalado de ráfagas, considere la posibilidad de dimensionar el clúster con el tamaño correcto mediante el análisis de las métricas de rendimiento a lo largo del tiempo.

• Si la carga de trabajo lo admite, escale los grupos de nodos de usuario a 0 nodos cuando no se espera que se ejecuten. Además, si no hay cargas de trabajo programadas para ejecutarse en el clúster, considere la posibilidad de usar la característica para iniciar y detener AKS para cerrar todo tipo de proceso, lo que incluye el grupo de nodos del sistema y el plano de control de AKS.

Para obtener más información relacionada con los costos, consulte Precios de AKS.

Pasos siguientes

Continúe aprendiendo sobre la arquitectura de línea de base de AKS:

• Para obtener más información sobre el hospedaje de microservicios en línea de base de AKS, consulte Arquitectura avanzada de microservicios de Azure Kubernetes Service (AKS).
• Para implementar la línea de base de AKS en varias regiones, consulte Línea de base de AKS para clústeres de varias regiones.
• Para implementar la línea de base de AKS en un entorno PCI-DSS 3.2.1, consulte Clúster regulado de AKS para PCI-DSS 3.2.1.
• Para más información sobre las consideraciones a tener en cuenta a la hora de agregar contenedores Windows a la arquitectura de referencia, consulte el artículo complementario: Contenedores de Windows en la arquitectura de referencia de AKS

Más información sobre AKS

• Para revisar el plan de desarrollo del producto de AKS, consulte Plan de desarrollo de Azure Kubernetes Service en GitHub.
• Si necesita una actualización sobre Kubernetes, complete las rutas de aprendizaje Introducción a Kubernetes y Desarrollo de implementación de aplicaciones en Kubernetes.

Recursos relacionados

Consulte las siguientes guías relacionadas:

• Revisión del Marco de buena arquitectura de Azure para Azure Kubernetes Service (AKS)
• El Acelerador de zonas de aterrizaje de AKS, que es una implementación a escala empresarial basada en esta arquitectura. El acelerador le ayuda a configurar el entorno de Azure de forma coherente y repetible mediante infraestructura como código (IaC) para una implementación de Azure Kubernetes Service (AKS).
• Guía de operaciones del día 2 de Azure Kubernetes Service

Consulte las siguientes arquitecturas relacionadas:

• Arquitectura de microservicios en Azure Kubernetes Service
• Uso de Azure Firewall para ayudar a proteger un clúster de Azure Kubernetes Service (AKS)
• GitOps para Azure Kubernetes Service
• Streaming de datos con AKS