Compartir a través de

Introducción al registro de clústeres

  • Artículo

Mejore la resistencia de las funciones de red nativas en la nube con el registro de clústeres (CR) de Azure Operator Service Manager (AOSM)

Historial de documentos

  • Creado y publicado por primera vez: 26 de julio de 2024
  • Actualizado para alta disponibilidad: 16 de octubre de 2024
  • Actualizado para GC: 5 de noviembre de 2024

Dependencias de características

Esta característica requiere el siguiente entorno mínimo:

  • Versión mínima de la API de ARM de AOSM: 2023-09-01
  • Primera versión, sin alta disponibilidad (HA) para la extensión de Kubernetes de función de red (NF): 1.0.2711-7
  • Primera versión, con alta disponibilidad para la extensión de Kubernetes de NF: 2.0.2810-144
  • Primera versión, con GC para la extensión de Kubernetes de NF: 2.0.2860-160

Introducción al registro de clústeres

El registro de clústeres (CR) de Azure Operator Service Manager (AOSM) permite realizar una copia local de las imágenes de contenedor en el clúster Nexus K8s. Cuando la función de red en contenedor (CNF) se instala con el registro de clúster activado, las imágenes de contenedor se extraen del almacén de artefactos AOSM remoto y se guardan en este registro de clúster local. Con un webhook mutante, el registro de clúster intercepta automáticamente las solicitudes de imagen y sustituye la ruta de acceso del Registro local para evitar cambios en el empaquetado del publicador. Con el registro del clúster, el acceso de la CNF a las imágenes de contenedor sobrevive a la pérdida de conectividad con el almacén de artefactos remoto.

Principales casos de uso y ventajas

Las funciones de red nativas en la nube (CNF) necesitan acceso a imágenes de contenedor, no solo durante la implementación inicial mediante el almacén de artefactos de AOSM, sino también para mantener operativa la función de red. Algunos de estos escenarios incluyen:

  • Reinicios del pod: detener e iniciar un pod puede dar lugar a que un nodo de clúster extraiga imágenes de contenedor del registro.
  • Operaciones del programador de Kubernetes: durante las asignaciones de pod a nodo, según las reglas de perfil del programador, si el nuevo nodo no tiene las imágenes de contenedor almacenadas en caché localmente, el nodo extrae imágenes de contenedor del registro.

Ventajas del uso del registro de clúster de AOSM:

  • Proporciona las imágenes locales necesarias para evitar la interrupción de CNF cuando se pierde la conectividad con el almacén de artefactos AOSM.
  • Disminuye el número de extracción de imágenes en el almacén de artefactos de AOSM, ya que cada nodo de clúster ahora extrae imágenes solo del registro local.
  • Supera los problemas con las direcciones URL del Registro con formato incorrecto, mediante el uso de un webhook mutante para sustituir la ruta de acceso de dirección URL del registro local adecuada.

Funcionamiento del registro de clúster

El registro de clúster de AOSM está habilitado mediante la extensión Arc K8s del operador de funciones de red (NFO). En la siguiente CLI se muestra cómo está habilitado el registro de clústeres en un clúster Nexus K8s.

az k8s-extension create --cluster-name
                        --cluster-type {connectedClusters}
                        --extension-type {Microsoft.Azure.HybridNetwork}
                        --name
                        --resource-group
                        --scope {cluster}
                        --release-namespace {azurehybridnetwork}
                        --release-train {preview, stable}
                        --config Microsoft.CustomLocation.ServiceAccount=azurehybridnetwork-networkfunction-operator
                        [--auto-upgrade {false, true}]
                        [--config global.networkfunctionextension.enableClusterRegistry={false, true}]
                        [--config global.networkfunctionextension.enableLocalRegistry={false, true}]
                        [--config global.networkfunctionextension.enableEarlyLoading={false,true}]
                        [--config global.networkfunctionextension.clusterRegistry.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.storageClassName=]
                        [--config global.networkfunctionextension.clusterRegistry.storageSize=]
                        [--config global.networkfunctionextension.webhook.pod.mutation.matchConditionExpression=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold=]
                        [--version]

Cuando la característica del registro de clústeres está habilitada en la extensión Network Function Operator Arc K8s, las imágenes de contenedor implementadas desde el almacén de artefactos de AOSM son accesibles localmente en el clúster Nexus K8s. El usuario puede elegir el tamaño de almacenamiento persistente para el registro de clústeres.

Nota:

Si el usuario no proporciona ninguna entrada, se usa un volumen persistente predeterminado de 100 GB.

Componentes del registro de clúster

La característica del registro de clúster implementa pods auxiliares en el clúster perimetral de destino para ayudar a la extensión NFO.

Reconciliador de componentes

  • Este pod principal se encarga de conciliar los objetos de recursos personalizados (CRO) creados por K8sBridge con la ayuda del proveedor de recursos (RP) Microsoft.Kubernetes, Hybrid Relay y el agente Arc que se ejecutan en el clúster.

Webhook de mutación de pods

  • Estos pods implementan webhooks de admisión de mutación de Kubernetes, que sirven una instancia de la API mutada. La API mutar hace dos cosas:
    • Modifica la ruta de acceso del Registro de imágenes a la dirección IP del Registro local, sustituyendo el almacén de artefactos de AOSM Azure Container Registry (ACR).
    • Crea una CR de artefacto en el clúster perimetral.

Reconciliador de artefactos

  • Este pod reconcilia los CRO de artefacto creados por el webhook mutante.

Registro

  • Este pod almacena y recupera imágenes de contenedor para CNF.

Registro de clústeres: recolección de elementos no utilizados

La extensión de clúster de AOSM ejecuta un trabajo de recolección de elementos no utilizados (GC) en segundo plano para limpiar las imágenes de contenedor de manera periódica. Este trabajo se ejecutará en función de una programación, comprobará si el uso del registro de clúster ha alcanzado el umbral especificado y, si es así, iniciará el proceso de recolección de elementos no utilizados. El usuario final se encarga de configurar la programación y el umbral del trabajo, pero, de forma predeterminada, el trabajo se ejecuta una vez por día en un umbral de uso del 0 %.

Limpieza de manifiestos de imagen de elementos no utilizados

AOSM mantiene referencias entre el recurso propietario del pod y las imágenes consumidoras en el registro del cluster. Al iniciar el proceso de limpieza de imágenes, las imágenes se identificarán que no están vinculadas a ningún pod, emitiendo una eliminación temporal para quitarlas del registro del clúster. Este tipo de eliminación temporal no libera inmediatamente el espacio de almacenamiento del registro del clúster. La eliminación de archivos de imagen reales depende de la recolección de elementos no utilizados del registro de distribución CNCF que se describe a continuación.

Nota:

La referencia entre el propietario de un pod y sus imágenes de contenedor garantiza que AOSM no elimine imágenes por error. Por ejemplo, si un pod de replicaset se cae, AOSM no dereferenciará las imágenes del contenedor. AOSM solo desreferencia las imágenes de contenedor cuando se elimina el conjunto de réplicas. El mismo principio se aplica a los pods administrados por trabajos y daemonsets de Kubernetes.

Distribución de recolección de elementos no utilizados CNCF

AOSM configura el registro de clúster mediante el registro de distribución CNCF de código abierto. Por lo tanto, AOSM se basa en las funcionalidades de recolección de elementos no utilizados que proporciona la recolección de elementos no utilizados | DistribuciónCNCF. En general, sigue el proceso estándar de "marcado y barrido" de 2 fases para eliminar archivos de imagen para liberar espacio de almacenamiento del Registro.

Nota:

Este proceso requiere el registro de clúster en modo de solo lectura. Si las imágenes se cargan cuando el registro no está en modo de sólo lectura, existe el riesgo de que las capas de imágenes se borren por error, lo que daría lugar a una imagen dañada. El Registro requiere el bloqueo en modo de solo lectura durante un período de hasta 1 minuto. Por lo tanto, AOSM aplazará otra implementación NF cuando el registro del clúster esté en modo de solo lectura.

Parámetros de configuración de recolección de elementos no utilizados

Los parámetros siguientes configuran la programación y el umbral para el trabajo de recolección de elementos no utilizados.

Consideraciones de alta disponibilidad y resistencia

La extensión NF de AOSM usa un registro perimetral y un webhook mutante para admitir características clave.

  • Incorporación de gráficos de Helm sin necesidad de personalizar la ruta de acceso de la imagen.
  • Un registro de clúster local para acelerar las operaciones de pods y habilitar la compatibilidad en modo desconectado. Estos componentes esenciales deben ser altamente disponibles y resistentes.

Resumen de los cambios de alta disponibilidad

Con alta disponibilidad, el registro de clúster y los pods de webhook ahora admiten un conjunto de réplicas con un mínimo de tres réplicas y un máximo de cinco réplicas. La configuración de la clave de conjunto de réplicas es la siguiente:

  • Se usa la estrategia de actualización gradual del lanzamiento.
  • Los PodDisruptionBudgets (PDB) se usan para la disponibilidad durante las interrupciones voluntarias.
  • La antiafinidad de pods se usa para distribuir pods uniformemente entre nodos.
  • El sondeo de preparación se usa para asegurarse de que los pods estén listos antes de atender el tráfico.
  • Los pods de carga de trabajo de AOSM solo se asignan al grupo de nodos del sistema.
  • Los pods se escalan horizontalmente en carga de CPU y memoria.

Réplicas

  • Un clúster que ejecuta varias copias o réplicas de una aplicación proporciona el primer nivel de redundancia. Tanto el registro de clúster como el webhook se definen como "kind:deployment" con un mínimo de tres réplicas.

DeploymentStrategy

  • Se usa una estrategia rollingUpdate para ayudar a lograr actualizaciones de tiempo de inactividad cero y admitir el lanzamiento gradual de aplicaciones. La configuración maxUnavailable predeterminada solo permite quitar un pod a la vez, hasta que se creen suficientes pods para satisfacer la directiva de redundancia.

Presupuesto de interrupción de pods

  • Un presupuesto de interrupción de pods (PDB) protege a los pods frente a la interrupción voluntaria, y se implementa junto con los objetos Deployment, ReplicaSet o StatefulSet. En el caso de los pods del operador AOSM, se usa un PDB con el parámetro minAvailable de 2.

Falta de afinidad de pod

  • La antiafinidad de pods controla la distribución de pods de aplicaciones entre varios nodos del clúster. Con alta disponibilidad, la antiafinidad de pods de AOSM se realiza mediante los parámetros siguientes:
    • Se usa un modo de programación para definir cómo se aplica estrictamente la regla.
      • requiredDuringSchedulingIgnoredDuringExecution(Hard): los pods deben estar programados de forma que se satisfaga la regla definida. Si no hay topologías que cumplan los requisitos de la regla, el pod no se programa.
      • preferredDuringSchedulingIgnoredDuringExecution(Soft): este tipo de regla expresa una preferencia para programar pods, pero no exige un requisito estricto. Si hay topologías que cumplen los criterios de preferencia disponibles, Kubernetes programa el pod. Si no hay topologías de este tipo disponibles, el pod todavía se puede programar en otros nodos que no cumplan las preferencias.
    • Un selector de etiquetas se usa para establecer como destino pods específicos para los que se aplica la afinidad.
    • Se usa una clave de topología para definir las necesidades del nodo.
  • La ubicación del nodo Nexus se distribuye uniformemente entre zonas de manera predeterminada, por lo que la distribución de los pods entre nodos también proporciona redundancia zonal.
  • Los pods de operadores de AOSM usan una antiafinidad de tipo "soft" con peso 100 y clave de topología basada en nombres de host de nodos.

Storage

  • Dado que el registro perimetral de AOSM tiene varias réplicas que se distribuyen entre nodos, el volumen persistente debe admitir el modo de acceso ReadWriteMany (RWX). El volumen "nexus-shared" de PVC está disponible en clústeres Nexus y admite el modo de acceso RWX.

Supervisión mediante sondeos de preparación

  • AOSM usa sondeos de preparación http para saber cuándo un contenedor está listo para empezar a aceptar el tráfico. Un pod se considera listo cuando todos sus contenedores están listos. Cuando un pod no está listo, se quita de los equilibradores de carga de servicio.

Grupo de nodos del sistema

  • Todos los pods de operador de AOSM se asignan al grupo de nodos del sistema. Este grupo impide que los pods de aplicación mal configurados o rouge afecten a los pods del sistema.

Escalado horizontal

  • En Kubernetes, HorizontalPodAutoscaler (HPA) actualiza, de manera automática, un activo de carga de trabajo con el objetivo de escalar, de manera automática, la carga de trabajo para que coincida con la demanda. Los pods de operador de AOSM tienen configurados los siguientes parámetros de directiva HPA;
    • Una réplica mínima de tres.
    • Una réplica máxima de cinco.
    • TargetAverageUtilization para CPU y memoria del 80 %.

Límites de recursos

  • Los límites de activos se usan para evitar una sobrecarga de activos en los nodos en los que se ejecutan los pods de AOSM. AOSM usa dos parámetros de activos para limitar el consumo de CPU y memoria.
    • Solicitud de activos: la cantidad mínima que se debe reservar para un pod. Este valor debe establecerse en el uso de activos bajo la carga normal de la aplicación.
    • Límite de activos: la cantidad máxima que debe usar un pod, si el uso alcanza el límite que finaliza. Todos los contenedores de operadores de AOSM se configuran con la solicitud adecuada, el límite de CPU y memoria.

Limitaciones conocidas de alta disponibilidad

  • Los clústeres de Nexus AKS (NAKS) con un único nodo activo en el grupo de agentes del sistema no son adecuados para alta disponibilidad. La topología de producción de Nexus debe usar al menos tres nodos activos en el grupo de agentes del sistema.
  • La clase de almacenamiento nexus-shared es un servicio de almacenamiento del sistema de archivos de red (NFS). Este servicio de almacenamiento NFS está disponible por red de servicio en la nube (CSN). Cualquier clúster de Nexus Kubernetes conectado a la CSN puede aprovisionar el volumen persistente desde este grupo de almacenamiento compartido. El grupo de almacenamiento está limitado actualmente a un tamaño máximo de 1 TiB a partir de Network Cloud (NC) 1, 3.10 mientras que NC 3.12 tiene una opción de 16 TiB.
  • La antiafinidad de pods solo se ocupa de la ubicación inicial de los pods, el escalado posterior de pods y la reparación, y sigue la lógica de programación de K8s estándar.

Preguntas más frecuentes

¿Puedo usar el registro de clústeres de AOSM con una aplicación CNF implementada anteriormente?

Si ya hay una aplicación CNF implementada sin el registro de clústeres, las imágenes de contenedor no están disponibles automáticamente. El registro de clústeres debe estar habilitado antes de implementar la función de red con AOSM.

¿Puedo cambiar el tamaño de almacenamiento después de una implementación?

El tamaño de almacenamiento no se puede modificar después de la implementación inicial. Se recomienda configurar el tamaño del volumen entre tres y cuatro veces el tamaño inicial.

¿Puedo enumerar los archivos almacenados actualmente en el repositorio de clústeres?

El siguiente comando se puede usar para enumerar archivos en un formato legible:

 kubectl get artifacts -A -o jsonpath='{range .items[*]}{.spec.sourceArtifact}'

Este comando debería generar una salida similar a la siguiente:

 ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0