Conceptos básicos de Kubernetes de Azure Kubernetes Service

  • Artículo

El desarrollo de aplicaciones continúa avanzando hacia un enfoque basado en contenedores, lo que aumenta nuestra necesidad de orquestar y administrar recursos. Como plataforma líder, Kubernetes proporciona una programación de confianza de cargas de trabajo de aplicaciones tolerantes a errores. Azure Kubernetes Service (AKS) es una oferta administrada de Kubernetes que simplifica aún más la implementación y administración de aplicaciones basadas en contenedores.

En este artículo se presentan conceptos básicos:

  • Componentes de la infraestructura de Kubernetes:

    • Plano de control
    • Nodos
    • Grupos de nodos

  • Recursos de carga de trabajo:

    • Pods
    • deployments
    • Conjuntos

  • Agrupar recursos mediante espacios de nombres.

¿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. Se centra en las cargas de trabajo de la aplicación, no en los componentes subyacentes de la infraestructura. 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 tanto aplicaciones con estado como sin estado, a medida que los equipos progresan a través de la adopción de aplicaciones basadas en microservicios.

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 administrado de Kubernetes que reduce la complejidad de la implementación y de tareas básicas de administración, como la coordinación de actualizaciones. 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:

  • Plano de control: proporciona los servicios básicos de Kubernetes y la orquestación de las cargas de trabajo de las aplicaciones.
  • Nodos: ejecutan las cargas de trabajo de las aplicaciones.

Kubernetes control plane and node components

Plano de control

Cuando crea un clúster AKS, se crea y configura automáticamente un plano de control. Este plano de control 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 es el modo en el que se exponen las API de Kubernetes subyacentes. Este componente proporciona la interacción de las herramientas de administración, como kubectl o el panel de Kubernetes.
etcd Para mantener el estado del clúster de Kubernetes y la configuración, el componente etcd de alta disponibilidad es un almacén de pares clave-valor en Kubernetes.
kube-scheduler Al crear o escalar aplicaciones, Scheduler determina qué nodos pueden ejecutar la carga de trabajo y los inicia.
kube-controller-manager El Administrador de controladores supervisa una cantidad de controladores más pequeños que realizan acciones como replicar pods y manejar operaciones de nodos.

AKS proporciona un plano de control de inquilino único con un servidor de API dedicado, Scheduler, etc. Usted define el número de nodos y su tamaño, mientras que la plataforma Azure configura la comunicación segura entre el plano de control y los nodos. La interacción con el plano de control se produce a través de las API de Kubernetes, como kubectl o el panel de Kubernetes.

Aunque no es necesario configurar componentes (como el almacén etcd de alta disponibilidad) con este plano de control administrado, usted no puede obtener acceso al plano de control directamente. 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 los posibles problemas, puede revisar los registros del plano de control mediante registros de Azure Monitor.

Para configurar o acceder directamente a un plano de control, implemente un clúster de Kubernetes autoadministrado mediante el proveedor de Cluster API de Azure.

Para los procedimientos recomendados asociados, consulte Procedimientos recomendados para administrar la seguridad y las actualizaciones de los clústeres en Azure Kubernetes Service (AKS).

Para obtener más información sobre la administración de costos de AKS, consulte Aspectos básicos de los costos de AKS y Precios de AKS.

Nodos y grupos de nodos

Para ejecutar las aplicaciones y los servicios de soporte técnico, necesitará un nodo de Kubernetes. Un 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.

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 Controla las redes virtuales en cada nodo. El proxy enruta el tráfico de red y administra las direcciones IP para los servicios y los pods.
entorno de ejecución de contenedor Permite que las aplicaciones en contenedores se ejecuten e interactúen con recursos adicionales, como la red virtual o el almacenamiento. Los clústeres de AKS que usan la versión 1.19 de Kubernetes u otras posteriores en nodos de Linux utilizan containerd como entorno de ejecución del contenedor. A partir de la versión 1.20 de Kubernetes para grupos de nodos de Windows, se puede usar containerd en versión preliminar en el entorno de ejecución del contenedor, aunque Docker sigue siendo el entorno de ejecución de contenedor predeterminado. Los clústeres de AKS que usan versiones anteriores de Kubernetes en los grupos de nodos emplean Docker como entorno de ejecución de contenedor.

Azure virtual machine and supporting resources for a Kubernetes node

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, Linux de Azure o Windows Server 2019. 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.

Para los discos administrados, el rendimiento y el tamaño predeterminado del disco se asignará según el número de SKU de máquina virtual y vCPU seleccionado. Para obtener más información, consulte Ajuste de tamaño predeterminado del disco del sistema operativo.

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.

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 la ejecución de los recursos de un nodo que se pueden asignar:

kubectl describe node [NODE_NAME]

Para mantener la funcionalidad y el rendimiento de los nodos, AKS reserva recursos 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.

Nota

El uso de complementos AKS como Container Insights (OMS) consumirá recursos de nodo adicionales.

Hay reservados dos tipos de recursos:

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.

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 que utiliza 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. Esto garantiza que un nodo siempre 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 se instala en todos los nodos de agente de Kubernetes para administrar la creación y terminación de contenedores. De forma predeterminada en AKS, el demonio kubelet tiene la regla de expulsión memory.available<750MiB, que garantiza que un nodo siempre tenga al menos 750 MiB asignables en todo momento. Cuando un host esté por debajo de ese umbral de memoria disponible, se activará kubelet para finalizar uno de los pods en ejecución y liberar 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 que esté por encima de 128 GB

Nota:

AKS reserva 2 GB adicionales para el proceso 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 hacer lo siguiente:

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

Las reservas de recursos anteriores no se pueden cambiar.

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. Un clúster de Kubernetes contiene al menos un grupo de nodos. El número de nodos y el tamaño 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 (2) 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 sobre cómo usar varios grupos de nodos en AKS, consulte Creación de varios grupos de nodos para un clúster en AKS.

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 nodo le permiten definir varios parámetros, por ejemplo, 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 sobre cómo controlar pods en grupos de nodos, consulte Procedimientos recomendados para las características avanzadas del programador en AKS.

Grupo de recursos de nodos

Al crear un clúster de AKS, debe especificar un grupo de recursos en el que crear el recurso de clúster. Además de este grupo de recursos, el proveedor de recursos de AKS también 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 de nodos se le asigna un nombre, como MC_myResourceGroup_myAKSCluster_eastus. Durante la creación del clúster, también tiene la opción de especificar el nombre asignado al grupo de recursos de nodos. 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.

Si modifica o elimina etiquetas creadas por Azure y otras propiedades de recursos en el grupo de recursos del nodo, es posible que obtenga resultados inesperados, como errores de escalado y de actualización. A medida que AKS administra el ciclo de vida de la infraestructura en el grupo de recursos de nodos, los cambios moverán el clúster a un estado no admitido.

Un escenario común en el que los clientes quieren modificar los recursos es mediante etiquetas. 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. Esto también puede conseguirse creando directivas de Azure cuyo ámbito sea el grupo de recursos administrado.

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). Para obtener más información, consulte ¿AKS ofrece un contrato de nivel de servicio?

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. Puede encontrar más información en Configuración del clúster en AKS.

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 una instancia de la aplicación. Un pod representa una instancia individual de la aplicación.

Los pods suelen tener una asignación de uno a uno 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 recursos 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. El 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 pods se implementan y administran mediante controladores de Kubernetes, como el controlador de implementación.

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 implementaciones para cambiar la configuración de los pods, la imagen del contenedor que se ha utilizado o el almacenamiento conectado. El controlador de implementación:

  • 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 (5) réplicas en la implementación, puede definir una interrupción del pod de 4 (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, el 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. Cree una implementación definiendo un archivo de manifiesto en formato YAML.

En el ejemplo siguiente, se crea una implementación básica del servidor web NGINX. La implementación especifica que se crearán tres (3) réplicas y requiere que el puerto 80 esté abierto en el contenedor. También se definen las solicitudes de recursos y los límites de CPU y memoria.

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 ejecutará la imagen nginx desde Docker Hub.
.spec.replicas Especifica cuántos pods se van a crear. Este archivo creará 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 para ejecutar réplicas en cualquier nodo disponible que cuente con recursos. Aunque este enfoque puede 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 lo siguiente:

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

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

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, use 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 haya iniciado el programador de Kubernetes predeterminado. Esta capacidad garantiza que los pods de DaemonSet se inicien antes de que se programen los pods tradicionales en una implementación o StatefulSet.

Como StatefulSets, DaemonSet se define 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 creará los pods en el nodo virtual.

Espacios de nombres

Los recursos de Kubernetes, como pods e implementaciones, se agrupan de forma lógica en un espacio 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.

Kubernetes namespaces to logically divide resources and applications

Cuando se crea un clúster de AKS, están disponibles los siguientes espacios de nombres:

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, este espacio puede usarse 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

En este artículo se tratan algunos de los componentes básicos de Kubernetes y cómo se aplican a los clústeres de AKS. Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte los artículos siguientes: