Preguntas más frecuentes: Azure Kubernetes Fleet Manager

Se aplica a: ✔️ Administrador de flota ✔️ Administrador de flota con clúster de concentrador

En este artículo se tratan las preguntas más frecuentes sobre Fleet Manager de Azure Kubernetes.

Preguntas más frecuentes sobre el servicio Fleet Manager

¿Fleet Manager es un recurso regional o global?

Fleet Manager es un recurso regional. El soporte para la conmutación por error de región en casos de recuperación ante desastres está en la hoja de ruta.

¿Cuántos clústeres puedo unir a Fleet Manager?

Fleet Manager (con o sin un clúster de concentrador) admite la unión de hasta 1000 clústeres de Kubernetes. Los clústeres miembro pueden ser una combinación de AKS y Kubernetes habilitado para Arc.

Si desea que Fleet Manager admita más de 1000 clústeres, agregue comentarios.

¿Qué clústeres de Kubernetes puedo unir como miembros?

Fleet Manager permite a los usuarios autorizados agregar cualquier clúster de Kubernetes habilitado para AKS, AKS Automatic o Arc en cualquier suscripción y región de Azure siempre y cuando la suscripción Azure esté asociada al mismo inquilino de Microsoft Entra ID que Fleet Manager.

¿Admite Fleet Manager identidades administradas?

Sí, Fleet Manager admite identidades administradas asignadas por el sistema y asignadas por el usuario. Para obtener más información, consulte la documentación sobre el uso de identidades administradas con Fleet Manager.

¿Qué ocurre cuando cambio la identidad de clúster de un clúster unido?

El cambio de la identidad de un clúster miembro interrumpe la comunicación entre Fleet Manager y ese clúster miembro. Aunque el agente miembro usa la nueva identidad para comunicarse con Fleet Manager, Fleet Manager todavía debe ser consciente de la nueva identidad. Ejecute este comando para resolver:

az fleet member create \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${MEMBER_NAME} \
    --member-cluster-id ${MEMBER_CLUSTER_ID}

Relación con Kubernetes habilitado para Azure Arc

Fleet Manager admite tanto clústeres de AKS hospedados Azure como clústeres de Kubernetes habilitados para Azure Arc como clústeres miembro.

Relación con clústeres de Azure Kubernetes Service

Azure Kubernetes Service (AKS) simplifica la implementación de un clúster de Kubernetes administrado en Azure descargando la sobrecarga operativa en Azure. Como servicio de Kubernetes hospedado, Azure controla las tareas críticas, como la supervisión y el mantenimiento del estado. Dado que el plano de control de Kubernetes está administrado por Azure, solo se mantienen los nodos del agente. Las cargas de trabajo reales se ejecutan en los clústeres de AKS.

Azure Kubernetes Gestor de Flotas le ayuda a gestionar escenarios a gran escala y multi-clúster para clústeres del servicio de Azure Kubernetes. Azure Kubernetes Fleet Manager proporciona una representación de grupo para los clústeres de AKS y ayuda a los usuarios a orquestar actualizaciones de clúster, propagación de recursos de Kubernetes y equilibrio de carga de varios clústeres. Las cargas de trabajo de usuario no se pueden ejecutar en el clúster del centro de Fleet Manager.

¿Puedo aprovisionar nuevos clústeres de AKS desde Fleet Manager?

La creación y la administración del ciclo de vida de los nuevos clústeres de AKS se encuentra en nuestra hoja de ruta. Proporcione comentarios si la compatibilidad con la creación de clústeres es un escenario importante para usted.

¿Es necesario administrar las actualizaciones en el clúster del centro de Fleet Manager?

No. El clúster de concentrador de Fleet Manager es un recurso administrado por Microsoft. Microsoft actualiza automáticamente el clúster del concentrador a la versión más reciente de Kubernetes o la imagen de nodo a medida que estén disponibles.

Si intenta actualizar o modificar el clúster de concentrador (que es un clúster de AKS de un solo nodo denominado hub), un conjunto de reglas de denegación impide que se apliquen los cambios.

¿Por qué mi clúster hub de Fleet Manager ha pasado de Error a En ejecución?

El clúster hub de Fleet Manager es un clúster de AKS administrado por Microsoft creado en su suscripción. No es necesario realizar ninguna acción en el clúster del concentrador.

Si hay un problema en el aprovisionamiento o la operación del clúster concentrador, puede pasar a un estado de Failed.

Fleet Manager reconcilia automáticamente el clúster central como parte de las operaciones periódicas de mantenimiento estándar, lo que puede hacer que el clúster central pase a un estado Running.

Cuando un clúster hub está en Failed, no genera ningún coste, pero cuando pasa a Running, se genera un coste.

Actualizaciones de varios clústeres: preguntas más frecuentes automatizadas o manuales

¿Qué clústeres admiten las actualizaciones de varios clústeres?

¿Qué canales de actualización de AKS admite Fleet Manager?

Fleet Manager admite los siguientes canales de actualización de AKS:

• Rapid: actualizaciones de la versión de Kubernetes compatible con AKS (N) más reciente.
• Estable: actualizaciones del canal estable de Kubernetes (N-1), donde "N" es la versión de Kubernetes compatible con AKS más reciente.
• NodeImage: VHD de la imagen de nodo actualizado con parches (de errores y seguridad) con un ciclo de publicación semanal.
• TargetKubernetesVersion (Revisión de Kubernetes): actualiza los clústeres a la versión de revisión más reciente de la versión de destino especificada cuando la revisión está disponible. Admite versiones secundarias de Kubernetes que solo están disponibles a través de AKS Long-Term Support (LTS).
• SecurityPatch (imágenes de nodos Linux): Actualizaciones del sistema operativo de la imagen del nodo que proporcionan parches de seguridad administrados por AKS aplicados al VHD existente que se ejecuta en el nodo.

Canales de AKS no admitidos actualmente:

• No gestionado: actualizaciones de la imagen del sistema operativo del nodo aplicadas directamente mediante el mecanismo de aplicación de parches integrado del sistema operativo (solo nodos Linux). Actualmente no hay planes para que Fleet Manager admita esta opción.

La versión menor de Kubernetes de destino en mi perfil de actualización automática ya no recibe soporte de la comunidad. ¿Qué se puede hacer?

Ustedes pueden:

• Permita el soporte a largo plazo (LTS) en el perfil de actualización automática y habilítelo para cualquier clúster de su flota que desee conservar en la versión menor específica. Asegúrese de que solo los clústeres de LTS se incluyen en la estrategia de actualización que use.
• Actualice el perfil de actualización automática a una nueva versión secundaria de Kubernetes de destino. Los clústeres se actualizan a la revisión más reciente en la versión secundaria especificada de Kubernetes cuando se publica.

Para obtener información sobre cómo habilitar LTS en perfiles de actualización automática, consulte Actualizaciones de la versión de Kubernetes de destino. Para obtener información sobre cómo habilitar LTS en clústeres administrados, consulte Compatibilidad a largo plazo.

¿Qué ocurre si dejo habilitadas las actualizaciones automáticas del clúster de AKS?

Si deja habilitadas las actualizaciones automáticas del clúster de AKS, Fleet Manager o la actualización automática del clúster de AKS realizará la actualización, según cuál de los dos se ejecute primero.

Fleet Manager no cambia la configuración de actualización automática del clúster de AKS.

Si desea que Fleet Manager administre las actualizaciones automáticas, deshabilite la actualización automática en cada clúster de AKS miembro.

Compatibilidad con la ventana de mantenimiento del clúster de AKS

Una ventana de mantenimiento define cuándo se puede actualizar un clúster de forma segura.

Fleet Manager respeta la configuración de la ventana de mantenimiento por clúster para cada clúster miembro.

Cuando se abre una ventana de mantenimiento, las actualizaciones no se inician inmediatamente. Entre los motivos se incluyen:

• Límites de simultaneidad: aunque se abra una ventana de mantenimiento, es posible que un clúster no se actualice debido a la configuración de simultaneidad de la estrategia.
• Sondeo normal: Fleet Manager sondea las ventanas de mantenimiento abiertas cada 60 minutos, por lo que el tiempo de espera máximo es de 60 minutos desde la ventana abierta.

¿Cuál es el ámbito de las actualizaciones coherentes de imágenes de nodo?

La coherencia del nodo solo se garantiza para todos los clústeres contenidos en una sola ejecución de actualización donde elija la consistent image opción .

No hay ninguna garantía de coherencia para las versiones de imagen de nodo en ejecuciones de actualización independientes.

¿Cómo puedo averiguar qué imágenes de nodo se usaron en una ejecución de actualización?

La ejecución de actualización enumera las imágenes de nodo seleccionadas utilizadas en ella. Puede acceder a esta información incluso si no se ha iniciado la ejecución de la actualización.

Se puede seleccionar más de una imagen de nodo porque los grupos de nodos diferentes funcionan en todos los clústeres seleccionados para la actualización.

Para buscar las imágenes seleccionadas, use este comando CLI de Azure:

az fleet updaterun show \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${UPDATE_RUN_NAME} \
    --query "status.nodeImageSelection.selectedNodeImageVersions"

También puede usar la View JSON opción en la página Información general de ejecución de actualizaciones de Azure Portal para ver los datos sin procesar de una ejecución de actualización.

Mi ejecución de actualización está en un estado pendiente durante bastante tiempo. ¿Qué debo hacer?

Las ejecuciones de actualizaciones de Fleet Manager pueden estar en un estado pendiente por muchas razones. Puede ver el estado de una actualización ejecutada a través del portal de Azure o siguiendo la documentación de supervisión.

Las dos razones más comunes para los estados pendientes largos son:

• Ventanas de mantenimiento del clúster miembro: si la ventana de mantenimiento de un clúster miembro no está abierta, la ejecución de la actualización entra en un estado en pausa. Esta pausa bloquea la finalización del grupo de actualizaciones o la fase hasta que se abra la siguiente ventana de mantenimiento. Para continuar con la ejecución de la actualización, omita manualmente el clúster. Si omite el clúster, no estará sincronizado con el resto de los clústeres miembros durante la ejecución de la actualización.

• La versión de Kubernetes o de la imagen de nodo no está disponible en la región de Azure: si la nueva versión de Kubernetes o de la imagen de nodo no se publica en la región de Azure en la que se encuentra un clúster miembro, la ejecución de la actualización entra en un estado pendiente. Puede comprobar el seguimiento de versiones de AKS para ver el estado regional de la versión. Aunque puede omitir el clúster de miembros, si hay otros clústeres en la misma región de Azure, tampoco se pueden actualizar.

Mi ejecución de actualización automática se inició y, a continuación, entró inmediatamente en un estado pendiente. ¿Por qué?

Consulte la pregunta anterior.

He intentado generar una ejecución de actualización desde mi perfil de actualización automática, pero no puedo ver la ejecución de la actualización.

Al generar manualmente una ejecución de actualización a partir de un perfil de actualización automática, es posible que la ejecución de la actualización resultante ya exista.

Este escenario puede surgir si el perfil de actualización automática generó automáticamente la ejecución de la actualización o si la ejecución de la actualización se generó manualmente.

El nombre de la ejecución de actualización generada se basa en la especificación de actualización del perfil de actualización automática, que solo cambia cuando se actualizan propiedades como la imagen del nodo o la versión de Kubernetes.

Normalmente, verá este problema en el portal de Azure cuando la ejecución de actualización existente no sea la más reciente. Si te encuentras con este problema y no puedes encontrar la ejecución de actualización, utiliza la CLI de Azure para generar la ejecución y ver el nombre de la misma. Microsoft planea corregir este problema en el portal de Azure en el futuro.

Si crea una ejecución de actualización y esta ya existe, la ejecución de actualización existente no se modifica.

La edición de mi estrategia de actualización no cambió las ejecuciones de actualización existentes que la usaron. ¿Por qué no?

Al crear una ejecución de actualización, la estrategia se copia a la ejecución de actualización para que los cambios en la estrategia no afecten a las ejecuciones de actualización en curso.

¿Cómo se impide que un único error de clúster detenga toda la ejecución de la actualización?

Use la configuración maxAllowedFailures en las fases y grupos de su estrategia de actualización (disponible a partir de la versión 2026-06-02-preview de la API). Esta configuración le permite especificar cuántos fallos de los clústeres miembros se pueden tolerar antes de que el grupo o la fase se marque como fallido. Los valores pueden ser un entero fijo (por ejemplo, "3") o un porcentaje (por ejemplo, "25%"). Cuando no está establecido o "0", un único fallo detiene toda la ejecución.

Para obtener más información, consulte Errores máximos permitidos (versión preliminar).

¿Por qué mi ejecución o grupo de actualización muestra Completado aunque los miembros hayan fallado?

Al establecer maxAllowedFailures, Fleet Manager solo evalúa el número de actualizaciones fallidas de miembros. No aplica una tasa de éxito mínima. Por lo tanto, una ejecución, una fase o un grupo de actualización puede terminar en Completed aunque algunos o todos sus miembros hayan fallado, siempre que no se supere el umbral configurado cuando Fleet Manager toma sus decisiones de planificación.

Este resultado es esperado e intencionado, no un error. Inspeccione siempre FailureCount, los estados en el nivel de miembro y los motivos de error antes de tratar la implementación como correcta. Para la mayoría de las estrategias de actualización, los umbrales basados en porcentajes son más fáciles de razonar que los valores absolutos.

¿Qué reglas y limitaciones debo saber al usar maxAllowedFailures?

Tenga en cuenta las siguientes reglas:

• La característica está disponible a partir de la versión de API 2026-06-02-preview.
• Cuando se desconfigura maxAllowedFailures o se establece en "0", Fleet Manager utiliza un comportamiento de error rápido y se detiene después de la primera actualización fallida de un miembro.
• El umbral se evalúa solo con el recuento de errores. No aplica una tasa de éxito mínima.
• Una ejecución, fase o grupo puede mostrarse Completed incluso cuando se producen errores, siempre y cuando no se supere el umbral configurado.
• FailureCount puede ser mayor que maxAllowedFailures cuando las actualizaciones se ejecutan en paralelo, ya que es posible que se produzca un error en varias actualizaciones de miembros antes de que Fleet Manager deje de programar más trabajo.
• Los umbrales de nivel de etapa y de nivel de grupo se evalúan de forma independiente, y los fallos de nivel de etapa se acumulan entre todos los grupos de la etapa.
• Para la mayoría de los despliegues, los umbrales porcentuales son más fáciles de entender y escalan mejor que los números fijos, especialmente en grupos pequeños.

¿Puedo aprobar previamente una aprobación?

No. Solo puede aprobar una actualización después de comprobar que los clústeres miembro están listos para la actualización o que la actualización se ha completado correctamente. Si desea aprobar previamente, considere la posibilidad de no configurar una aprobación en su estrategia.

¿Expiran las aprobaciones?

No, las aprobaciones esperan hasta que sean aprobadas. No se puede configurar un período de tiempo para aprobaciones.

¿Puedo omitir una aprobación?

Si desea omitir las actualizaciones del clúster miembro junto con la aprobación de acceso, omita la fase o grupo que abarca. Si desea continuar con las actualizaciones, debe conceder la aprobación.

¿Cómo se elimina una aprobación?

Como en la pregunta anterior, si desea continuar con una actualización, debe conceder la aprobación. Si intenta limpiar el recurso de entrada subyacente, debe eliminar la ejecución de actualización asociada, lo que elimina todas las entradas vinculadas a la ejecución de la actualización.

¿Puedo configurar una aprobación posterior a la etapa junto con una espera posterior a la etapa?

Sí. La espera posterior a la etapa comienza al mismo tiempo que la aprobación. Ambos deben completarse antes de que continúe la ejecución de la actualización.

¿Puedo agregar aprobaciones a las estrategias de actualización existentes?

Sí. Puede editar la estrategia existente para incluir aprobaciones. Sin embargo, las ejecuciones de actualización existentes que creó mediante la estrategia no se actualizan.

¿Cómo interactúan las puertas de inicio programadas con las ventanas de mantenimiento del clúster de AKS?

Las puertas de inicio programadas y las ventanas de mantenimiento planificado del clúster de AKS son controles independientes. Se deben cumplir ambas condiciones antes de que un clúster empiece a actualizarse. Por ejemplo, si una puerta de inicio programada se completa a las 2:00 a. m., pero la ventana de mantenimiento de un clúster no se abre hasta las 6:00 a. m., el clúster espera hasta las 6:00 a. m. para comenzar su actualización.

¿Cómo puedo controlar el orden de las actualizaciones del clúster en una ejecución de actualización?

Las etiquetas de miembro y los grupos de actualizaciones son dos maneras diferentes de seleccionar qué clústeres se incluyen en cada fase y grupo de la estrategia de actualización. Cada clúster miembro se puede asignar a un grupo de actualizaciones, pero puede tener varias etiquetas. Las etiquetas de miembro (con memberSelector) ofrecen más flexibilidad y admiten escenarios de selección complejos, por lo que son la manera recomendada de seleccionar miembros de flota para las estrategias de actualización. Para obtener más información, consulte Agrupación de clústeres mediante etiquetas de miembro.

¿Es necesario especificar grupos si se establece un selector de miembros en el nivel de fase?

No. Cuando se establece memberSelector en una fase sin definir ningún grupo, todos los clústeres coincidentes se tratan como un único grupo. La fase maxConcurrency controla cuántos clústeres se actualizan simultáneamente. Solo tiene que definir grupos en una fase si desea crear particiones de los miembros correspondientes en subconjuntos paralelos con diferentes configuraciones de simultaneidad.

¿Qué ocurre con la actualización de grupos si se establece un selector de miembros en el nivel de grupo?

Si establece un memberSelector a nivel de grupo, el campo del name del grupo solo se usa como identificador de visualización para los informes de estado y el registro de eventos. memberSelector tiene prioridad sobre el nombre del grupo de actualización al seleccionar clústeres para el grupo.

Preguntas más frecuentes sobre la selección de ubicación de recursos del clúster

¿Puedo seleccionar recursos dentro de un espacio de nombres para la propagación?

Sí. Fleet Manager admite tanto la colocación de recursos con ámbito de clúster como con ámbito de espacio de nombres:

• ClusterResourcePlacement: propaga los recursos con ámbito de clúster y los espacios de nombres completos (incluido todo su contenido) a los clústeres miembro. Para obtener más información, consulte Uso de ClusterResourcePlacement para implementar recursos con ámbito de clúster.
• ResourcePlacement: proporciona un control preciso para seleccionar y propagar recursos específicos con ámbito de espacio de nombres (como ConfigMaps, Secrets, Deployments) dentro de un espacio de nombres. Para obtener más información, consulte Uso de ResourcePlacement para desplegar recursos delimitados por namespaces.

Plan de desarrollo

El plan de desarrollo de Azure Fleet Manager de Kubernetes está disponible en GitHub. El equipo recibe solicitudes de características, preguntas e informes de errores.

Pasos siguientes

• Creación de una flota y unión a clústeres miembros.
• Guías de solución de problemas para Fleet Manager.