Azure Kubernetes Services (AKS) fundamentos

En este post vamos a ver los fundamentos de Azure Kubernetes Services, la implementación de Kubernetes como PaaS en la Nube de Microsoft.

¿Qué es Kubernetes?

Según la documentación oficial, Kubernetes es un motor de orquestación de contenedores de código abierto diseñado para automatizar el despliegue, el escalado y la gestión de aplicaciones en contenedores. Este proyecto de código abierto está alojado por la Cloud Native Computing Foundation (CNCF).

Se ha convertido en un estándar de facto para la gestión de aplicaciones modernas gracias a sus características clave respecto a Portabilidad y flexibilidad, Autoreparación, Escalado automático y Despliegues continuos.

Para mas detalles los invito a revisar el post Introducción a Kubernetes – Aprende Multi Cloud(s)

Particularidades de los Managed Kubernetes en la nube

Cómo todos los proveedores de Nube, Microsoft tambien tiene su implementación de Kubernetes. Azure Kuberentes Services (AKS) es uno de los principales competidores en el campo de Managed Kubernetes junto con EKS de Amazon y GKE de Google.

Este tipo de Plataformas en la nube basadas en Kubernetes nos brindan varias ventajas a los administradores a la hora de Implementar un Cluster. Para esto debemos entender, en alto nivel, como funciona un cluster de Kubernetes y cuales son los detalles de su implementación.

Arquitectura de Kubernetes on-premises

En alto nivel, la arquitectura de Kubernetes está compuesta por dos componentes principales: el Control Plane y los Nodos (Nodes), los cuales trabajan en conjunto para administrar y orquestar aplicaciones en contenedores.

1. Control Plane

El Control Plane es el cerebro de Kubernetes, tiene la visibilidad del estado del cluster a través de ETCD y responsable de tomar decisiones sobre el estado del clúster y manejar la orquestación general de los contenedores. Sus componentes principales son:

• API Server (api):
  Exposición de la API de Kubernetes que actúa como punto de entrada para todas las operaciones administrativas. Recibe peticiones (por ejemplo, kubectl) y las procesa.
• Controller Manager (c-m, c-cm):
  Gestiona los controladores que garantizan que el estado deseado del clúster se mantenga. Ejemplos incluyen replicar pods o manejar fallos en los nodos.
• etcd:
  Base de datos key-value que almacena toda la información de configuración y estado del clúster de forma consistente.
• Scheduler (sched):
  Decide en qué nodo se ejecutará cada pod basándose en requisitos de recursos y políticas definidas.

2. Nodos

Los nodos son las máquinas (físicas o virtuales) donde se ejecutan los contenedores de las aplicaciones. Cada nodo contiene los siguientes componentes:

• Kubelet:
  Es un agente que corre en cada nodo y se encarga de comunicarse con el Control Plane para asegurar que los contenedores se ejecuten según las instrucciones recibidas y estén en el estado deseado.
• Kube-proxy (k-proxy) o CNI:
  Componente que maneja las reglas de red para exponer los servicios de los pods dentro y fuera del clúster.

En estos casos, cada uno de los componentes es administrado por el equipo de IT.

• Requiere que el equipo de TI gestione toda la infraestructura física (servidores, redes, almacenamiento, refrigeración, energía, etc.).
• La instalación, configuración y mantenimiento del clúster (control plane y worker nodes) son responsabilidad del equipo interno.
• Se necesita un esfuerzo considerable para la implementación de alta disponibilidad y recuperación ante desastres.

Mantener un Cluster de Kuberntes no es tarea sencilla, requiere que los equipos de IT tengan este expertise y que tengan conocimientos profundos en Administración de Cluster de Kubernetes (CKA).

¿Qué es Azure Kubernetes Services (AKS)?

Azure Kubernetes Services (AKS) es una servicio PaaS que reduce la complejidad de administrar un Cluster completo de Kubernetes y gestiona el Panel de Control cambiando la responsabilidad de el mantenimiento y despliegue por parte de Azure. Es decir, que los administradores no necesitan ser expertos en Kubernetes ni tener experiencia en CKA para administrar el Cluster, simplemente, se delegan esas tareas a el proveedor de nube.

AKS maneja este Control Plane que es el encargado de gestionar, no solo los Worker Nodes sino tambien el resto de los objetos de Kubernetes. Tambien maneja el mantenimiento y monitoreo de salud de la plataforma.

En este sentido, el Control Plane es enteramente manejado por Azure pero los Worker Nodes son creados en nuestra subscripción de Azure en Virtual Machines:

Más precisamente, Azure utilizar Virtual Machine Scale Sets (VMSS), estos VMSS son los que gestionan nuestra infraestructura de Worker Nodes automaticamente a través del Control Plane gestionado por Azure.

Componentes de AKS

Node Pools

Los Node Pools son un grupo de Worker Nodes de Kubernetes que comparten las mismas configuraciones agrupados. Estos servidores son los que correrán las cargas de trabajo de contenedores. Al crear un AKS, se crea un System Node Pool que servirá para correr todos los servicios basicos para la funcionalidad del cluster como CoreDNS o Konnectivty. Luego, los administradores podemos crear User Node Pools con diferentes configuraciones para correr cargas de trabajo especificas.

Como mencionamos anteriormente, los administradores no vemos el Control Plane. Este es administrado por Azure en su propia infraestructura. En cambio, si vamos a poder ver los componentes de nuestros worker nodes y los recursos asociados.

Group de Recursos de AKS

En AKS, se crean dos grupos de recursos durante la implementación para soportar la infraestructura subyacente de Kubernetes en Azure.

Primer grupo de recursos:

• Es el grupo de recursos que el usuario crea manualmente al desplegar el clúster.
• Contiene únicamente el recurso del servicio de Kubernetes (AKS).
• Su propósito es actuar como el punto de referencia para la gestión del clúster en Azure.

Segundo grupo de recursos (Node Resource Group):

• Este grupo es creado automáticamente por el proveedor de recursos de AKS durante la implementación.
• Su nombre por defecto sigue el formato: MC_<nombre-del-grupo>_<nombre-del-cluster>_<región> (por ejemplo, MC_myResourceGroup_myAKSCluster_eastus).

Este segundo grupo de recursos, contiene todos los recursos de infraestructura asociados con el clúster, incluyendo:

• Virtual Machine Scale Sets (VMSS) para los nodos del clúster.
• Redes virtuales (VNet) y subredes.
• Discos gestionados utilizados por los nodos.
• Network Security Group (NSG).
• Identidades gestionadas (Managed Identity).
• Interfaces de red (NIC).
• Endpoints privados (Private Endpoints).
• Direcciones IP públicas (si aplica).
• Balanceadores de carga (Load Balancer).
• Zonas privadas de DNS.

Es importante tener en cuenta que la modificación manual de cualquier recurso dentro del Node Resource Group no es compatible y puede provocar fallos en la operación del clúster. Se recomienda restringir los permisos de modificación en este grupo de recursos para evitar cambios accidentales que puedan afectar la estabilidad del clúster.

Además, dado que AKS administra este grupo automáticamente, al eliminar el clúster de AKS, este segundo grupo de recursos también se elimina automáticamente. Por esta razón, se aconseja no agregar recursos personalizados a este grupo a menos que compartan el mismo ciclo de vida del clúster.

Modos del Cluster en AKS

Podemos encontar 2 modos:

• Automatic (actualmente en preview).
• Standard.

AKS Automatic

Es basicamente un offering similar a GKE AutoPilot en donde los administradores nisiquiera debemos gestionar los NodePools u otro recursos de la infra subyacente. Unicamente desplegamos nuestras aplicaciónes y AKS se encarga del resto. Tiene mayores ventajas de mantenimiento pero menor flexibilidad.

Caracteristicas

Características clave de AKS Automatic:

Gestión automatizada del clúster:

• No es necesario crear ni administrar Node Pools, ya que Azure asigna automáticamente los recursos de cómputo según las necesidades de la carga de trabajo.
• El control plane y los worker nodes están completamente gestionados por Azure.

Escalado inteligente:

• Ajusta dinámicamente la infraestructura utilizando Node Autoprovisioning, lo que permite la asignación óptima de recursos según la demanda de los pods.
• Escalado automático de pods con HPA, KEDA y VPA habilitados por defecto.

Seguridad y cumplimiento incorporados:

• Parches y actualizaciones automáticas sin interrupciones para los workloads gestionado enteramente por el Servicio.
• Integración con Azure RBAC y políticas de seguridad preconfiguradas.

Monitoreo integrado:

• Viene preconfigurado con herramientas de monitoreo como Managed Prometheus, Managed Grafana y Container Insights, disponibles a través del portal de Azure o la CLI.

Standard

El modo AKS Standard es la opción más utilizada y flexible, ofreciendo a los administradores control total sobre la infraestructura del clúster manejado.

Caracteristicas

Gestión manual de nodos:

• Creación y configuración de System Node Pools para ejecutar los componentes del clúster como CoreDNS y Konnectivity.
• Creación de User Node Pools para cargas de trabajo específicas con configuraciones personalizadas (por ejemplo, tipo de VM, escalabilidad, etc.).

Opciones de escalado:

• Escalado manual de los node pools.
• Opcionalmente, se pueden habilitar el Cluster Autoscaler, Node Auto-provisioning, KEDA (Kubernetes Event Driven Autoscaling) y VPA (Vertical Pod Autoscaler).

Control del mantenimiento:

• Se deben gestionar manualmente las actualizaciones del clúster o habilitar la actualización automática en canales específicos.
• Posibilidad de definir ventanas de mantenimiento programadas.

Seguridad personalizable:

• Opcionalmente se pueden habilitar medidas como Azure RBAC para Kubernetes, integración con Microsoft Entra (antiguo Azure AD) y políticas de seguridad.
• Integración de red a través de Azure CNI o Kubenet según la configuración elegida.

Networking en AKS

Para entender un poco más sobre como funciona el Networking en Kubernetes y, sobre todo, como se relaciona esto con los Kubernetes Managed Services, los invito a leer la siguiente nota: Kubernetes networking – Parte 1 – Aprende Multi Cloud(s) y Kubernetes networking – Parte 2 – Aprende Multi Cloud(s)

Basicamente la red de AKS se puede desplegar de 2 maneras:

Overlay Mode:

• Es el modelo más común y mas usado.
• Se da a los Pods un rango de IPs privadas, separadas logicamente del CIDR de la subnet de Azure donde los nodos fueron desplegados.
• El trafico saliente utiliza SNAT.
• Opciones de configuración: Azure CNI Overlay y kubenet.

Flat Network mode:

• Se asginan a los Pods IPs del mismo rango de la subnet en donde los nodos estan corriendo.
• El trafico saliente no utiliza SNAT, cada uno de los Pods está expuesto directamente al destino.
• Opciones de configuración: Azure CNI Pod Subnet y Azure CNI Node Subnet

Complemento de CNI	Modelo de redes	Resaltados de casos de uso
Superposición de Azure CNI	Overlay	– Mejor para la conservación de IP de red virtual
		– Número máximo de nodos admitidos por el servidor de API + 250 pods por nodo
		– Configuración más sencilla
		– Sin acceso directo al IP de pod externo
Subred de pod de Azure CNI	Plano	– Acceso directo a pods externos
		– Modos de uso eficaz de IP de red virtual o compatibilidad a gran escala de clústeres (versión preliminar)
Kubenet (heredado)	Overlay	– Prioriza la conservación de IP
		– Escalamiento limitado
		– Administración manual de rutas
Subred de nodo de Azure CNI (heredado)	Plano	– Acceso directo a pods externos
		– Configuración más sencilla
		– Escala limitada
		– Uso ineficaz de direcciones IP de red virtual