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

En esta arquitectura de referencia, crearemos una infraestructura de línea de base que implemente un clúster de Azure Kubernetes Service (AKS). En este artículo se incluyen recomendaciones para la red, la seguridad, la identidad, la administración y la supervisión del clúster en función de los requisitos empresariales de una organización.

Hay disponible una implementación de esta arquitectura en  GitHub: Implementación de referencia de la línea de base segura de Azure Kubernetes Service (AKS). Puede usarla como punto de partida y configurarla según 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

Proceso para el clúster base
Referencia de imagen de contenedor
Administración de directivas

Administración de identidades

Integración de Azure AD para el clúster
Integración de Azure AD 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 controlar el radio de explosión. También admite el concepto de zona de aterrizaje 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.

Hub

La red virtual de centro es el punto central de conectividad y observabilidad. 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 flujo puede comunicarse con un servicio malintencionado de terceros que podría exfiltrar los datos confidenciales de la empresa.

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 contendrá el clúster de AKS y otros recursos relacionados. El radio tiene tres 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. 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.

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 de Contoso y el controlador de entrada para facilitar la comunicación entrante para la carga de trabajo. La carga de trabajo es una aplicación sencilla de ASP.NET.

Para información adicional, consulte Topología de red en estrella tipo hub-and-spoke en Azure.

Plan de direcciones IP

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 desee aislar los grupos de nodos de usuario entre sí y del grupo de nodos de sistema. Esta opción puede dar lugar a más subredes de menor tamaño. Además, el recurso de entrada puede ser más complejo. Es posible que necesite varios controladores de entrada que requieran direcciones 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.

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 en el registro de contenedor que se alinea con el 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 Azure Active Directory 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 Azure Active Directory (Azure AD): 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, Azure AD 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 Azure AD. Puede habilitar esta configuración solo durante la creación del clúster. Incluso si Azure AD no se utiliza inmediatamente, puede incorporarlo más adelante.

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 acrPull a la identidad administrada 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 Azure AD 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 autenticará en Azure AD y, a continuación, se le permitirá o denegará el acceso en función de los roles 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 Azure AD también simplifica la seguridad para el acceso de fuera hacia dentro. Supongamos que un usuario quiere usar kubectl. Como paso inicial, envía el comando az aks get-credentials para obtener las credenciales del clúster. Azure AD 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 Azure Active Directory de dos maneras. La primera es usar Azure Active Directory 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 Azure Active Directory

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

Kubernetes tiene algunos roles integrados como cluster-admin, edit, view, etc. Enlace esos roles a usuarios y grupos de Azure Active Directory para usar el directorio de la empresa para administrar el acceso. Para más información, consulte Uso del acceso basado en rol de Kubernetes con integración de Azure AD.

Asegúrese de que los grupos de Azure AD que se usan para el acceso al clúster y al espacio de nombres están incluidos en las revisiones de acceso de Azure AD.

Uso de la autorización de Azure RBAC para Kubernetes

En lugar de usar RBAC de Kubernetes con la autenticación integrada de AAD, otra opción es usar Azure RBAC y las asignaciones de roles para exigir el acceso al clúster. La ventaja de usar Azure RBAC es que no es necesario configurar roles de RBAC y enlaces de roles nativos de Kubernetes.

Para más información, consulte Roles de Azure.

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 Azure Active Directory y configure este 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 Azure Active Directory para la carga de trabajo

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

En esta implementación de referencia, las identidades de pod administradas se facilitan mediante aad-pod-identity.

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.

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/v1beta1
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: /
        backend:
          serviceName: aspnetapp-service
          servicePort: http

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.

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.

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. El tráfico se mueve de Application Gateway al servidor back-end y se cifra de nuevo con otro certificado TLS (comodín para *.aks-ingress.contoso.com) a medida que 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

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 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. El enfoque recomendado es usar Azure Private Link. La ventaja es que subredes específicas llegan directamente al servicio. Además, el tráfico entre el clúster y el servicio no se expone a la red pública de 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 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 la dirección IP estática del firewall, esa dirección se puede agregar a la lista de direcciones IP permitidas del servicio. Una desventaja es que Azure Firewall deberá tener reglas adicionales para asegurarse de que solo se permite el tráfico de una subred específica.

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

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.

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.

Acceso a los secretos del clúster

Deberá usar identidades administradas de pod 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 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. Cuente con algún retraso.

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 que esté al tanto de esos casos.

• ¿Debe cumplir requisitos que las directivas integradas no abarcan? En estos casos excepcionales, cree una definición de Azure Policy personalizada para aplicar sus directivas personalizadas de OPA Gatekeeper. No aplique directivas directamente en el clúster.

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

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

Escalador automático de clústeres

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.

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 la aplicación de los servicios del sistema colocándolo en un grupo de nodos independiente. De este modo, los servicios de Kubernetes se ejecutan en nodos dedicados y no compiten con la carga de trabajo. Se recomienda el uso de etiquetas y valores taint para identificar el grupo de nodos para programar la carga de trabajo.

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 superior, proteja contra la pérdida de actividad en una zona. 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.

Acuerdo de Nivel de Servicio de tiempo de actividad del servidor de la 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 Acuerdo de Nivel de Servicio, debe agregar un Acuerdo de Nivel de Servicio de tiempo de actividad a la compra. Se recomienda que todos los clústeres de producción usen esta opción. Reserve los clústeres sin esta opción para usarlos como 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 desactivació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 reducir una dependencia externa.

Supervisión y recopilación de métricas

La característica Azure Monitor para contenedores es la herramienta recomendada para la supervisión y el registro, ya que se pueden 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. Puede usarla para supervisar el rendimiento como la escala de pods. Otra ventaja es que puede usar fácilmente Azure Portal para configurar gráficos y paneles. Tiene la capacidad de crear alertas que desencadenen runbooks de Automation, Azure Functions y otras soluciones.

La mayoría de las cargas de trabajo hospedadas en pods emiten métricas de Prometheus. Azure Monitor tiene la capacidad de extraer métricas de Prometheus y visualizarlas.

Hay algunas utilidades de terceros integradas con Kubernetes. Aproveche las plataformas de registro y métricas, como Grafana o Datadog, si su organización ya las usa.

Con AKS, Azure administra algunos servicios principales de Kubernetes. Los registros de esos servicios solo se deben habilitar por solicitud del servicio de soporte al cliente. Sin embargo, se recomienda habilitar estos orígenes de registro, ya que pueden ayudarle a solucionar problemas del clúster:

• 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 en el programador de pods.
• KubeAuditAdmin para tener observabilidad en las actividades que modifican el clúster.

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 de seguridad

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 Azure Defender para Kubernetes para detectar amenazas en los clústeres de Kubernetes.
• Use Azure Security Center (ASC) para supervisar la postura con respecto a la seguridad de Kubernetes.
• 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.

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 Azure Active Directory.

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 son las plantillas 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

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. 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. Kubernetes y AKS no admiten de forma nativa esa experiencia. Una opción recomendada es flux. Usa uno o varios operadores en el 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 de la implementación de referencia que muestra cómo automatizar la configuración del clúster con GitOps y Flux.

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. Tenga directivas de rama en el servidor de Git. De este modo, varios desarrolladores pueden aprobar un cambio antes de que se aplique a producción.

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

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.

Aprovisionamiento

• No hay ningún costo asociado con AKS para la implementación, administración y operaciones del clúster de Kubernetes. El controlador principal de costos son las instancias de máquina virtual, el almacenamiento y los recursos de red que usa el clúster. Considere la posibilidad de elegir máquinas virtuales más baratas para grupos de nodos de sistema. La SKU recomendada es DS2_v2.

• 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 serán más costosas. Puede que no sea necesario en el entorno de desarrollo/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 dentro de 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 facturación, 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

• 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 ver la hoja de ruta del producto de AKS, consulte Hoja de ruta de Azure Kubernetes Service en GitHub.

Artículos relacionados

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 en Microsoft Learn.