Conceptos básicos de Kubernetes de Azure Kubernetes Service (AKS)

En este artículo se describen los conceptos básicos de Azure Kubernetes Service (AKS), un servicio de Kubernetes administrado que puede usar para implementar y operar aplicaciones en contenedores a escala en Azure. Le ayuda a obtener información sobre los componentes de infraestructura de Kubernetes y a comprender mejor cómo funciona Kubernetes en AKS.

¿Qué es Kubernetes?

Kubernetes es una plataforma de rápida evolución que administra aplicaciones basadas en contenedores y sus componentes de red y almacenamiento asociados. Kubernetes se centra en las cargas de trabajo de la aplicación y no en los componentes de infraestructura subyacentes. Kubernetes proporciona un enfoque declarativo en las implementaciones, respaldado por un sólido conjunto de API para las operaciones de administración.

Usted puede compilar y ejecutar aplicaciones modernas, portátiles y basadas en microservicios usando Kubernetes para orquestar y administrar la disponibilidad de sus componentes. Kubernetes admite aplicaciones sin estado y con estado.

Como plataforma abierta, Kubernetes le permite compilar aplicaciones con el lenguaje de programación, el sistema operativo, las bibliotecas o el bus de mensajería que prefiera. La integración continua y las herramientas de entrega continua (CI/CD) existentes pueden integrarse con Kubernetes para programar e implementar versiones.

AKS proporciona un servicio de Kubernetes administrado que reduce la complejidad de la implementación y de tareas básicas de administración. La plataforma Azure administra el plano de control de AKS, y usted solo paga los nodos de AKS que ejecutan sus aplicaciones.

Arquitectura del clúster de Kubernetes

Un clúster de Kubernetes se divide en dos componentes:

• El plano de control, que proporciona los servicios básicos de Kubernetes y la orquestación de las cargas de trabajo de las aplicaciones, así como
• Nodos, que ejecutan las cargas de trabajo de las aplicaciones.

Plano de control

Cuando crea un clúster de AKS, la plataforma Azure crea y configura automáticamente su plano de control asociado. Este plano de control de inquilino único se proporciona sin coste alguno como recurso administrado de Azure que se extrae del usuario. Usted solo paga los nodos asociados al clúster de AKS. El plano de control y sus recursos solo residen en la región en la que creó el clúster.

El plano de control incluye los siguientes componentes principales de Kubernetes:

Componente	Descripción
kube-apiserver	El servidor de API expone las API de Kubernetes subyacentes y proporciona la interacción con las herramientas de administración, como kubectl o el panel de Kubernetes.
etcd	etcd es un almacén de clave-valor de alta disponibilidad en Kubernetes que ayuda a mantener el estado del clúster y la configuración de Kubernetes.
kube-scheduler	Al crear o escalar aplicaciones, el programador determina qué nodos pueden ejecutar la carga de trabajo e inicia los nodos identificados.
kube-controller-manager	El administrador de controladores supervisa un número de controladores más pequeños que realizan acciones, como replicar pods y controlar operaciones de nodos.

Tenga en cuenta que no puede acceder directamente al plano de control. Las actualizaciones del plano de control y de los nodos de Kubernetes se orquestan a través de CLI de Azure o de Azure Portal. Para solucionar posibles problemas, puede revisar los registros del plano de control mediante Azure Monitor.

Nota:

Si quiere configurar o acceder directamente a un plano de control, puede implementar un clúster de Kubernetes autoadministrado mediante el proveedor de Cluster API de Azure.

Nodos

Para ejecutar las aplicaciones y los servicios de soporte técnico, necesitará un nodo de Kubernetes. Cada clúster de AKS tiene al menos un nodo, una máquina virtual de Azure que ejecuta los componentes de nodo de Kubernetes y el entorno de ejecución del contenedor.

Los nodos incluyen los siguientes componentes principales de Kubernetes:

Componente	Descripción
kubelet	Agente de Kubernetes que procesa las solicitudes de orquestación desde el plano de control y la programación de la ejecución de los contenedores solicitados.
kube-proxy	El proxy controla las redes virtuales en cada nodo, enrutando el tráfico de red y administrando el direccionamiento IP de los servicios y pods.
entorno de ejecución de contenedor	El runtime del contenedor permite que las aplicaciones en contenedores se ejecuten e interactúen con otros recursos, como la red virtual o el almacenamiento. Para obtener más información, consulte Configuración del entorno de ejecución de contenedor.

El tamaño de la máquina virtual de Azure para los nodos define las CPU, la memoria, el tamaño y el tipo del almacenamiento disponible, por ejemplo, SSD de alto rendimiento o HDD normal. Planee el tamaño de los nodos en función de si las aplicaciones pueden requerir grandes cantidades de CPU y memoria o almacenamiento de alto rendimiento. Escale horizontalmente el número de nodos del clúster de AKS para satisfacer la demanda. Para obtener más información sobre el escalado, consulte Opciones de escalado para aplicaciones en AKS.

En AKS, la imagen de máquina virtual para los nodos del clúster se basa en Ubuntu Linux, Azure Linux o Windows Server 2022. Al crear un clúster de AKS o escalar horizontalmente el número de nodos, la plataforma Azure crea y configura automáticamente el número solicitado de máquinas virtuales. Los nodos de agente se facturan como máquinas virtuales estándar, por lo que cualquier descuento en el tamaño de la máquina virtual, incluidas reservas de Azure se aplica automáticamente.

En el caso de los discos administrados, de manera predeterminada, el tamaño del disco y el rendimiento se asignan según el número de SKU de máquina virtual y vCPU seleccionados. Para obtener más información, consulte Dimensionamiento del disco del SO predeterminado.

Nota:

Si necesita una configuración y un control avanzados en el sistema operativo y el entorno de ejecución del contenedor de nodos de Kubernetes, puede implementar un clúster autoadministrado mediante el proveedor de Cluster API de Azure.

Configuración del sistema operativo

AKS admite Ubuntu 22.04 y Azure Linux 2.0 como el sistema operativo (SO) de nodo para clústeres con Kubernetes 1.25 y versiones posteriores. Ubuntu 18.04 también se puede especificar en la creación del grupo de nodos para las versiones 1.24 y anteriores de Kubernetes.

AKS admite Windows Server 2022 como el SO predeterminado para los grupos de nodos de Windows en clústeres con Kubernetes 1.25 y versiones posteriores. Windows Server 2019 también se puede especificar en la creación del grupo de nodos para las versiones 1.32 y anteriores de Kubernetes. Windows Server 2019 se está retirando después de que la versión 1.32 de Kubernetes llegue al final del ciclo de vida y no se admitirá en futuras versiones. Para obtener más información sobre esta retirada, consulte las notas de la versión de AKS.

Configuración del entorno de ejecución de contenedor

Un entorno de ejecución de contenedor es un software que ejecuta contenedores y administra imágenes de contenedor en un nodo. El entorno de ejecución ayuda a abstraer las llamadas sys o la funcionalidad específica del SO para ejecutar contenedores en Linux o Windows. En el caso de los grupos de nodos de Linux, containerd se usa para la versión 1.19 de Kubernetes y versiones posteriores. Para los grupos de nodos de Windows Server 2019 y 2022, containerd está disponible con carácter general y será la única opción del entorno de ejecución en la versión 1.23 de Kubernetes y versiones posteriores. A partir de mayo de 2023, Docker se retira y deja de recibir soporte. Para obtener más información sobre esta retirada, consulte las notas de la versión de AKS.

Containerd es un entorno de ejecución de contenedor básico compatible con OCI (Open Container Initiative) que proporciona el conjunto mínimo de funciones necesarias para ejecutar contenedores y administrar imágenes en un nodo. Con los nodos basados en containerd y los grupos de nodos, el kubelet se comunica directamente con containerd mediante el complemento CRI (interfaz del entorno de ejecución del contenedor) y eliminará los saltos adicionales del flujo de datos, en comparación con la implementación de CRI de Docker. Como tal, verá una mejor latencia de inicio del pod y un menor uso de recursos (CPU y memoria).

Containerd funciona en todas las versiones de disponibilidad general de Kubernetes en AKS, en cada versión de Kubernetes a partir de v1.19 y admite todas las características de Kubernetes y AKS.

Importante

Los clústeres con grupos de nodos de Linux creados en Kubernetes versión 1.19 o superior utilizan containerd de manera predeterminada para el runtime de contenedores. Los clústeres con grupos de nodos en versiones de Kubernetes admitidas anteriormente reciben Docker para su entorno de ejecución de contenedores. Los grupos de nodos de Linux se actualizarán a containerd una vez que la versión de Kubernetes del grupo de nodos se actualice a una versión compatible con containerd.

containerd está disponible con carácter general en el caso de los clústeres con grupos de nodos de Windows Server 2019 y 2022 y es la única opción del entorno de ejecución del contenedor para Kubernetes v1.23 y versiones posteriores. Todavía puede usar clústeres y grupos de nodos de Docker en versiones inferiores a la 1.23, pero Docker ya no se admite a partir de septiembre de 2023. Para más información, consulte Adición de un grupo de nodos de Windows Server con containerd.

Se recomienda probar las cargas de trabajo en grupos de nodos de AKS con containerd antes de usar clústeres con una versión de Kubernetes compatible con containerd para sus grupos de nodos.

Limitaciones y diferencias de containerd

• Para containerd, se recomienda usar crictl en lugar de la CLI de Docker para solucionar problemas de pods, contenedores e imágenes de contenedor en nodos Kubernetes. Para obtener más información sobre crictl, consulte Uso general y Opciones de configuración de cliente.

  • Containerd no proporciona la funcionalidad completa de la CLI de Docker. Solo está disponible para solucionar problemas.
  • crictl ofrece una vista de los contenedores más compatible con Kubernetes, con conceptos como pods, etc.

• Containerd configura el registro mediante el formato de registro cri estandarizado. La solución de registro debe admitir el formato de registro cri, como Azure Monitor para contenedores.

• Ya no puede tener acceso al motor de Docker, /var/run/docker.sock, ni usar Docker en Docker (DinD).

  • Si actualmente extrae los registros de aplicación o los datos de supervisión del motor de Docker, utilice en su lugar Container Insights. AKS no admite la ejecución de comandos fuera de banda en los nodos del agente que podrían provocar inestabilidad.
  • No se recomienda compilar imágenes ni usar directamente el motor de Docker. Kubernetes no es totalmente consciente de esos recursos consumidos y esos métodos presentan numerosos problemas, que se detallan aquí y aquí.

• Al compilar imágenes, puede seguir usando su flujo de trabajo de compilación de Docker como de costumbre, a menos que vaya a compilar imágenes dentro del clúster de AKS. En este caso, considere la posibilidad de utilizar el enfoque recomendado para compilar imágenes con ACR Tasks. O bien, una alternativa más segura dentro del clúster, como Docker Buildx.

Reservas de recursos

AKS usa recursos de nodo para ayudar al nodo a funcionar como parte del clúster. Este uso puede crear discrepancias entre los recursos totales del nodo y los recursos que se pueden asignar en AKS. Tenga esto presente al establecer solicitudes y límites para los pods implementados por el usuario.

Para buscar el recurso asignable de un nodo, puede usar el comando kubectl describe node:

kubectl describe node [NODE_NAME]

Para mantener el rendimiento y la funcionalidad de los nodos, AKS reserva dos tipos de recursos, CPU y memoria, en cada nodo. A medida que aumentan los recursos de un nodo, la reserva de recursos también crece debido a la mayor necesidad de administrar pods implementados por el usuario. Tenga en cuenta que no se pueden cambiar las reservas de recursos.

Nota:

El uso de complementos de AKS, como Container Insights (OMS), consume recursos adicionales de nodo.

CPU

La CPU reservada depende del tipo de nodo y de la configuración del clúster, lo que puede provocar que haya menos CPU para asignar, debido a la ejecución de otras características. En la siguiente tabla se muestra la reserva de CPU en milinúcleos:

Núcleos de CPU en el host	1	2	4	8	16	32	64
Reservado para Kube (milinúcleos)	60	100	140	180	260	420	740

Memoria

La memoria reservada en AKS incluye la suma de dos valores:

Importante

Las versiones preliminares de AKS 1.29 en enero de 2024 e incluyen ciertos cambios en las reservas de memoria. Estos cambios se detallan en la siguiente sección.

AKS 1.29 y versiones posteriores

1. El demonio kubelet tiene la regla de expulsión memory.available<100Mi de forma predeterminada. Esta regla garantiza que un nodo tenga al menos 100Mi asignables en todo momento. Cuando un host esté por debajo de ese umbral de memoria disponible, kubelet desencadenará la finalización de uno de los pods en ejecución y liberará memoria en la máquina host.

2. Tasa de reservas de memoria establecida según el valor más pequeño de: 20 MB * número máximo de pods admitidos en el nodo + 50 MB o 25 % de los recursos totales de la memoria del sistema.

   Ejemplos:

   • Si la máquina virtual proporciona 8 GB de memoria y el nodo admite hasta 30 pods, AKS reserva 20 MB * 30 pods como máximo + 50 MB = 650 MB para kube-reserved. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Si la máquina virtual proporciona 4 GB de memoria y el nodo admite hasta 70 pods, AKS reserva 25 % * 4 GB = 1000 MB para kube-reserved, ya que esto es menor que 20 MB * 70 pods como máximo + 50 MB = 1450 MB.

   Para obtener más información, consulte Configuración del número máximo de pods por nodo en un clúster de AKS.

Versiones de AKS anteriores a 1.29

1. El demonio kubelet tiene la regla de expulsión memory.available<750Mi de forma predeterminada. Esta regla garantiza que un nodo tenga al menos 750Mi asignables en todo momento. Cuando un host está por debajo de ese umbral de memoria disponible, el kubelet desencadena la terminación de uno de los pods en ejecución y libera memoria en el equipo host.
2. Tasa regresiva de reservas de memoria para que el demonio “kubelet” funcione correctamente (kube-reserved).
   • 25 % de los primeros 4 GB de memoria
   • 20 % de los siguientes 4 GB de memoria (hasta 8 GB)
   • 10 % de los siguientes 8 GB de memoria (hasta 16 GB)
   • 6 % de los siguientes 112 GB de memoria (hasta 128 GB)
   • 2 % de cualquier memoria superior a 128 GB

Nota:

AKS reserva 2 GB adicionales para los procesos del sistema en los nodos de Windows que no forman parte de la memoria calculada.

Las reglas de asignación de memoria y CPU están diseñadas para:

• mantienen los nodos de agente en buen estado, incluidos algunos pods del sistema host críticos para el mantenimiento del clúster y
• hacen que el nodo informe de un volumen menor de memoria y CPU asignables que del que informaría si no formase parte de un clúster de Kubernetes.

Por ejemplo, si un nodo ofrece 7 GB, informará del 34 % de la memoria no asignable, incluido el umbral de expulsión estricto de 750 Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Además de las reservas para Kubernetes mismo, el sistema operativo del nodo subyacente también reserva una cantidad de recursos de CPU y memoria para mantener las funciones del sistema operativo.

Para consultar los procedimientos recomendados asociados, consulteProcedimientos recomendados para características básicas del programador en Azure Kubernetes Service (AKS).

Grupos de nodos

Nota:

El grupo de nodos de Linux en Azure ahora está disponible con carácter general (GA). Para obtener información sobre las ventajas y los pasos de implementación, consulte Introducción al host de contenedor de Linux en Azure para AKS.

Los nodos de la misma configuración se agrupan en grupos de nodos. Cada clúster de Kubernetes contiene al menos un grupo de nodos. Debe definir el número de nodos y los tamaños iniciales se definen al crear un clúster de AKS, que crea un grupo de nodos predeterminado. Este grupo de nodos predeterminado de AKS contiene las máquinas virtuales subyacentes que ejecutan los nodos del agente.

Nota:

Para asegurarse de que el clúster funcione de forma fiable, debe ejecutar al menos dos nodos del grupo predeterminado.

Los clústeres de AKS se escalan o actualizan con relación al grupo de nodos predeterminado. También se puede optar por escalar o actualizar un grupo de nodos específico. Para las operaciones de actualización, los contenedores en ejecución se programan en otros nodos del grupo de nodos hasta que todos los nodos se actualizan correctamente.

Para obtener más información, consulte Creación de grupos de nodos y Administración de grupos de nodos.

Ajuste de tamaño predeterminado del disco del sistema operativo

Al crear un nuevo clúster o agregar un nuevo grupo de nodos a un clúster existente, de manera predeterminada el tamaño del disco del sistema operativo viene determinado por el número de vCPU. El número de vCPU se basa en la SKU de máquina virtual. En la siguiente tabla se muestra el tamaño de disco del sistema operativo predeterminado para cada SKU de máquina virtual:

Núcleos de SKU de máquina virtual (vCPU)	Nivel predeterminado del disco del sistema operativo	IOPS aprovisionadas	Rendimiento aprovisionado (Mbps)
1 - 7	P10/128 G	500	100
8 - 15	P15/256 G	1100	125
16 - 63	P20/512 G	2300	150
64+	P30/1024 G	5000	200

Importante

El ajuste de tamaño predeterminado del disco del sistema operativo solo se usa en nuevos clústeres o grupos de nodos cuando no se admiten discos del sistema operativo efímeros y no se especifica un tamaño de disco del sistema operativo predeterminado. El tamaño predeterminado del disco del sistema operativo podría afectar al rendimiento o al costo del clúster. No se puede cambiar el tamaño del disco del sistema operativo después de la creación del clúster o del grupo de nodos. Este ajuste de tamaño de disco predeterminado afecta a los clústeres o grupos de nodos creados en julio de 2022 o posteriores.

Selectores de nodos

En un clúster de AKS con varios grupos de nodos, es posible que tenga que indicar a Scheduler de Kubernetes qué grupo de nodos se debe utilizar para un recurso determinado. Por ejemplo, los controladores de entrada no deben ejecutarse en los nodos de Windows Server. Los selectores de nodos se usan para definir varios parámetros, como el sistema operativo del nodo, para controlar dónde se debe programar un pod.

El siguiente ejemplo básico programa una instancia de NGINX en un nodo Linux mediante el selector de nodos "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Para más información, consulte Procedimientos recomendados para características avanzadas del programador en Azure Kubernetes Service (AKS).

Grupo de recursos de nodos

Al crear un clúster de AKS, especifique un grupo de recursos de Azure para crear los recursos del clúster en. Además de este grupo de recursos, el proveedor de recursos de AKS crea y administra un grupo de recursos independiente denominado grupo de recursos de nodos. El grupo de recursos de nodos contiene los siguientes recursos de infraestructura:

• Conjuntos de escalado de máquinas virtuales y máquinas virtuales para cada nodo de los grupos de nodos
• Red virtual del clúster
• Almacenamiento del clúster

De forma predeterminada, al grupo de recursos del nodo se le asigna un nombre con el siguiente formato: MC_resourceGroupName_clusterName_location. Durante la creación del clúster, puede especificar el nombre asignado al grupo de recursos de nodos. Al usar una plantilla de Azure Resource Manager, puede definir el nombre mediante la propiedad nodeResourceGroup. Al usar la CLI de Azure, se usa el parámetro --node-resource-group con el comando az aks create, como se muestra en el siguiente ejemplo:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

Al eliminar el clúster de AKS, el proveedor de recursos de AKS elimina automáticamente el grupo de recursos de nodos.

El grupo de recursos de nodos tiene las siguientes limitaciones:

• No puede especificar un grupo de recursos existente para el grupo de recursos de nodos.
• No puede especificar otra suscripción para el grupo de recursos de nodos.
• No puede cambiar el nombre del grupo de recursos de nodos una vez se haya creado el clúster.
• No puede especificar los nombres de los recursos administrados dentro del grupo de recursos de nodos.
• No puede modificar o eliminar las etiquetas creadas en Azure de los recursos administrados del grupo de recursos de nodos.

La modificación de las etiquetas creadas por Azure en los recursos del grupo de recursos de nodos en el clúster de AKS es una acción no admitida que interrumpe el objetivo de nivel de servicio (SLO, por sus siglas en inglés). Si modifica o elimina etiquetas creadas por Azure u otras propiedades de recursos en el grupo de recursos del nodo, es posible que obtenga resultados inesperados, como errores de escalado y actualización. AKS administra el ciclo de vida de la infraestructura en el grupo de recursos del nodo, por lo que los cambios mueven el clúster a un estado no admitido. Para obtener más información, consulte ¿AKS ofrece un contrato de nivel de servicio?

AKS le permite crear y modificar etiquetas que se propaguen a los recursos del grupo de recursos del nodo, y puede agregar esas etiquetas al crear o actualizar el clúster. Es posible que quiera crear o modificar etiquetas personalizadas, por ejemplo, para asignar un centro de costos o una unidad de negocio. También puede crear directivas de Azure con un ámbito en el grupo de recursos administrados.

Para reducir la posibilidad de cambios en el grupo de recursos de nodos que afecta a los clústeres, puede habilitar el bloqueo del grupo de recursos de nodos para aplicar una asignación de denegación a los recursos de AKS. para obtener más información, consulte Grupo de recursos totalmente administrado (versión preliminar).

Advertencia

Si no tiene habilitado el bloqueo del grupo de recursos de nodos, puede modificar directamente cualquier recurso del grupo de recursos de nodos. La modificación directa de los recursos del grupo de recursos de nodos puede hacer que el clúster sea inestable o no responda.

Pods

Kubernetes utiliza pods para ejecutar instancias de la aplicación. Un único pod representa una instancia individual de la aplicación.

Los pods suelen tener una asignación individual con un contenedor. En escenarios avanzados, un pod puede contener varios contenedores. Los pods de varios contenedores se programan conjuntamente en el mismo nodo y permiten que los contenedores compartan recursos relacionados.

Al crear un pod, puede definir solicitudes de recursos para solicitar una determinada cantidad de memoria o CPU. Scheduler de Kubernetes intenta satisfacer la solicitud programando los pods para que se ejecuten en un nodo con recursos disponibles. También puede especificar límites de recursos máximos, con el fin de impedir que un pod consuma demasiados recursos de proceso del nodo subyacente. Nuestro procedimiento recomendado consiste en incluir límites de recursos para todos los pods, con el fin de ayudar a Scheduler de Kubernetes a identificar qué recursos son necesarios y cuáles se permiten.

Para obtener más información, consulte Pods de Kubernetes y Ciclo de vida de pods de Kubernetes.

Un pod es un recurso lógico, pero las cargas de trabajo de aplicaciones se ejecutan en los contenedores. Los pods suelen ser recursos efímeros y descartables. Los pods programados por separado carecen de algunas de las características de alta disponibilidad y redundancia de Kubernetes. En su lugar, los controladores de Kubernetes, como el controlador de implementación, implementa y administra pods.

Implementaciones y manifiestos YAML

Una implementación representa pods idénticos administrados por el controlador de implementación de Kubernetes. Una implementación define el número de réplicas de pod que deben crearse. Scheduler de Kubernetes garantiza que se programen pods adicionales en nodos correctos si los pods o los nodos tienen problemas. Puede actualizar las implementaciones para cambiar la configuración de pods, la imagen de contenedor o el almacenamiento conectado.

El controlador de implementación administra el ciclo de vida de la implementación y realiza las siguientes acciones:

• purga y finaliza un número determinado de réplicas;
• crea réplicas a partir de la nueva definición de implementación;
• continúa el proceso hasta que se actualizan todas las réplicas de la implementación.

La mayoría de las aplicaciones sin estado de AKS debe usar el modelo de implementación en lugar de programar pods individuales. Kubernetes puede supervisar el mantenimiento de las implementaciones para garantizar que se ejecute el número de réplicas necesario dentro del clúster. Cuando se programan por separado, los pods no se reinician en caso de producirse un problema, ni tampoco se vuelven a programar en nodos correctos si el que sufre un problema es su nodo actual.

No es aconsejable trastocar decisiones de administración con un proceso de actualización si la aplicación requiere un número mínimo de instancias disponibles. Los presupuestos de interrupción de pods definen el número de réplicas de una implementación que se pueden quitar durante una actualización o la actualización de un nodo. Por ejemplo, si tiene cinco réplicas en la implementación, puede definir una interrupción del pod de cuatro para permitir que solo se elimine o se vuelva a programar una réplica a la vez. Como en el caso de los límites de recursos de pods, nuestro procedimiento recomendado consiste en definir presupuestos de interrupción de pods en aplicaciones que requieran que siempre esté presente un número mínimo de réplicas.

Normalmente, las implementaciones se crean o administran con kubectl create o kubectl apply. Puede crear una implementación definiendo un archivo de manifiesto en formato YAML. En el siguiente ejemplo se muestra un archivo de manifiesto de implementación básico para un servidor web NGINX:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

Un desglose de las especificaciones de implementación en el archivo de manifiesto DE YAML es el siguiente:

Especificación	Descripción
.apiVersion	Especifica el grupo de API y el recurso de API que desea usar al crear el recurso.
.kind	Especifica el tipo de recurso que se desea crear.
.metadata.name	Especifica el nombre de la implementación. Este archivo YAML de ejemplo ejecuta la imagen de nginx desde Docker Hub.
.spec.replicas	Especifica cuántos pods se van a crear. Este archivo YAML de ejemplo crea tres pods duplicados.
.spec.selector	Especifica qué pods se verán afectados por esta implementación.
.spec.selector.matchLabels	Contiene un mapa de pares {key, value} que permiten a la implementación buscar y administrar los pods creados.
.spec.selector.matchLabels.app	Tiene que coincidir con .spec.template.metadata.labels.
.spec.template.labels	Especifica los pares {clave, valor} adjuntos al objeto.
.spec.template.app	Tiene que coincidir con .spec.selector.matchLabels.
.spec.spec.containers	Especifica la lista de contenedores que pertenecen al pod.
.spec.spec.containers.name	Especifica el nombre del contenedor especificado como una etiqueta DNS.
.spec.spec.containers.image	Especifica el nombre de la imagen de contenedor.
.spec.spec.containers.ports	Especifica la lista de puertos que se van a exponer desde el contenedor.
.spec.spec.containers.ports.containerPort	Especifica el número de puertos que se van a exponer en la dirección IP del pod.
.spec.spec.resources	Especifica los recursos de proceso necesarios para el contenedor.
.spec.spec.resources.requests	Especifica la cantidad mínima de recursos de proceso necesarios.
.spec.spec.resources.requests.cpu	Especifica la cantidad mínima de CPU necesaria.
.spec.spec.resources.requests.memory	Especifica la cantidad mínima de memoria necesaria.
.spec.spec.resources.limits	Especifica la cantidad máxima de recursos de proceso permitidos. El kubelet aplica este límite.
.spec.spec.resources.limits.cpu	Especifica la cantidad máxima de CPU permitida. El kubelet aplica este límite.
.spec.spec.resources.limits.memory	Especifica la cantidad máxima de CPU permitida. El kubelet aplica este límite.

Es posible crear aplicaciones más complejas incluyendo servicios, como equilibradores de carga, en el manifiesto YAML.

Para más información, consulte el artículo sobre las implementaciones de Kubernetes.

Administración de paquetes con Helm

Helm se usa normalmente para administrar aplicaciones en Kubernetes. Puede implementar recursos compilando y usando gráficos públicos de Helm ya existentes que contengan una versión empaquetada de código de aplicación y manifiestos YAML de Kubernetes. Estos gráficos de Helm pueden almacenarse localmente o en un repositorio remoto, como un repositorio de gráficos de Helm de Azure Container Registry.

Para usar Helm, instale el cliente de Helm en el equipo o use el cliente de Helm en Azure Cloud Shell. Busque o cree gráficos de Helm y, después, instálelos en el clúster de Kubernetes. Para más información, consulte Instalación de aplicaciones existentes con Helm en AKS.

StatefulSets y DaemonSets

El controlador de implementación usa Scheduler de Kubernetes y ejecuta réplicas en cualquier nodo disponible con recursos disponibles. Aunque este enfoque podría bastar en el caso de aplicaciones sin estado, el controlador de implementación no es la opción ideal en el caso de aplicaciones que requieran las siguientes especificaciones:

• Una convención de nomenclatura o un almacenamiento persistentes
• Una réplica en cada nodo seleccionado dentro de un clúster

Pero hay dos recursos de Kubernetes con los que puede administrar estos tipos de aplicaciones: StatefulSets y DaemonSets.

StatefulSets: mantienen el estado de las aplicaciones más allá del ciclo de vida de un determinado pod. DaemonSets: garantizan la ejecución de una instancia en cada nodo en un fase inicial del proceso de arranque de Kubernetes.

StatefulSets

El desarrollo de aplicaciones modernas suele tener como objetivo aplicaciones sin estado. En el caso de las aplicaciones con estado, como las que incluyen componentes de base de datos, puede usar StatefulSets. Al igual que las implementaciones, un StatefulSet crea y administra al menos un pod idéntico. Las réplicas de un StatefulSet siguen un enfoque estable y secuencial de operaciones de implementación, escalado, actualización y finalización. Con un StatefulSet, la convención de nomenclatura, los nombres de red y el almacenamiento persisten como réplicas que se vuelven a programar.

Puede definir la aplicación en formato YAML usando kind: StatefulSet. Después, el controlador del StatefulSet controla la implementación y administración de las réplicas necesarias. Los datos se escriben en el almacenamiento persistente, proporcionado por Azure Managed Disks o Azure Files. Con un StatefulSet, el almacenamiento persistente subyacente permanece aunque se elimine el StatefulSet.

Para más información, consulte el objeto StatefulSets de Kubernetes.

Importante

Las réplicas de StatefulSet se programan y se ejecutan en cualquier nodo disponible en un clúster de AKS. Para asegurarse de que al menos un pod del conjunto se ejecute en un nodo, debe usar un DaemonSet en su lugar.

DaemonSets

Para la recopilación o supervisión de registros específicos, puede que necesite ejecutar un pod en todos los nodos o en un conjunto de nodos seleccionados. Puede usar DaemonSets para implementar en uno o varios pods idénticos. El controlador DaemonSet garantiza que cada nodo especificado ejecute una instancia del pod.

El controlador de DaemonSet puede programar los pods en los nodos al principio del proceso de arranque del clúster, antes de que se inicie el programador de Kubernetes predeterminado. Esta capacidad garantiza que se programen los pods en un estado DaemonSet antes que los pods tradicionales en una implementación o StatefulSet.

Como StatefulSets, puede definir DaemonSet como parte de una definición de YAML mediante kind: DaemonSet.

Para más información, consulte el objeto DaemonSets de Kubernetes.

Nota:

Si usa el complemento de nodos virtuales, DaemonSets no crea pods en el nodo virtual.

Espacios de nombres

Los recursos de Kubernetes, como pods e implementaciones, se agrupan de forma lógica en espacios de nombres, con el fin de dividir un clúster de AKS y crear, visualizar o administrar el acceso a recursos. Por ejemplo, puede crear espacios de nombres para separar grupos de negocios. Los usuarios solo pueden interactuar con los recursos dentro de sus espacios de nombres asignados.

Los siguientes espacios de nombres están disponibles al crear un clúster de AKS:

Espacio de nombres	Descripción
default	Espacio donde se crean los pods y las implementaciones de forma predeterminada si no se proporciona ninguno. En entornos más pequeños, puede implementar aplicaciones directamente en el espacio de nombres predeterminado sin crear separaciones lógicas adicionales. Al interactuar con la API de Kubernetes, como con kubectl get pods, el espacio de nombres predeterminado se utiliza cuando no se especifica ninguno.
kube-system	Espacio donde existen los recursos básicos, por ejemplo, características de red como el DNS y el proxy, o bien el panel de Kubernetes. Normalmente, el usuario no implementa sus propias aplicaciones en este espacio de nombres.
kube-public	Aunque no suele utilizarse, puede usar este espacio para que los recursos sean visibles en todo el clúster y para que puedan verlos todos los usuarios.

Para más información, consulte los espacios de nombres de Kubernetes.

Pasos siguientes

Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte los artículos siguientes:

• Acceso e identidad de AKS
• Seguridad AKS
• Redes virtuales de AKS
• Almacenamiento de AKS
• Escala AKS