Todos los productos
Search

Este producto

    Container Service for Kubernetes:Upgrade clusters

    Centro de documentos

    Container Service for Kubernetes:Upgrade clusters

    Última actualización: Sep 04, 2026

    Para evitar riesgos de seguridad y estabilidad asociados con versiones de clúster obsoletas, y para acceder a las funciones más recientes de Kubernetes y al soporte técnico, actualice la versión de su clúster de manera oportuna. ACK proporciona comprobaciones previas a la actualización, admite directivas de actualización configurables con control de ritmo, y ofrece monitoreo del progreso de actualización para garantizar un proceso sin contratiempos.

    Razones para actualizar

    ACK permite crear clústeres con las tres minor versions más recientes de Kubernetes. Por ejemplo, si ACK es compatible con Kubernetes 1.31, 1.32 y 1.33, ya no podrá crear clústeres que utilicen la versión 1.30. Tampoco puede crear clústeres que usen versiones de parche expiradas. Para obtener más información, consulte version guide.

    Ejecutar una versión obsoleta implica riesgos de seguridad y estabilidad. Cuando una versión deja de ser compatible, su clúster no recibe nuevas funciones, correcciones de bugs ni soporte técnico oportuno, y queda vulnerable a fallas de seguridad sin parches.

    Importante

    Al actualizar un clúster, ACK ejecuta comprobaciones previas. Sin embargo, estas comprobaciones no detectan todas las configuraciones de funciones o API incompatibles. Según el shared responsibility model, usted es responsable de mantenerse informado sobre los lanzamientos de versiones mediante la lectura de documentos de ayuda y el monitoreo de mensajes en la consola e internos. Antes de actualizar un clúster, revise las notas de la versión correspondiente.

    Impacto de la actualización

    ACK proporciona directivas de actualización por fases y en lotes para garantizar la continuidad y estabilidad de los pods de su aplicación durante la actualización del clúster.

    • Comprobación previa: Antes de actualizar el plano de control o un node pool, ACK ejecuta una comprobación previa para identificar posibles riesgos de compatibilidad. Estos riesgos incluyen API obsoletas, versiones de componentes incompatibles y problemas con el estado de nodos o discos. ACK también ofrece sugerencias para resolver estos problemas. La comprobación previa no afecta los servicios de su clúster.

    • Plano de control:

      • Clústeres administrados por ACK: El API Server es gestionado por ACK y se reinicia de forma gradual durante la actualización. Este proceso normalmente no afecta las aplicaciones en ejecución. Si una aplicación depende en gran medida del API Server, es posible que deba reintentar conexiones debido a breves desconexiones.

      • Clústeres dedicados de ACK: Durante la actualización, ACK realiza una actualización in situ en cada nodo maestro de forma secuencial. Este proceso normalmente no afecta las aplicaciones en ejecución. Si una aplicación depende en gran medida del API Server, es posible que deba reintentar conexiones debido a breves desconexiones.

    • Node pool: Los nodos se actualizan en lotes para garantizar la continuidad del servicio. Personalice la directiva de actualización por lotes, por ejemplo, especificando el número máximo de nodos por lote y el intervalo entre lotes, para controlar el impacto en sus servicios.

      • Durante una actualización in situ, los discos no se reemplazan y los nodos no se reinicializan. Los pods de la aplicación continúan ejecutándose y los servicios no se interrumpen.

      • Una actualización con reemplazo de disco del sistema implica drenar el nodo, reemplazar el disco del sistema y reinicializar el nodo. Tenga en cuenta los siguientes impactos:

        • Durante una actualización con reemplazo de disco del sistema, ACK drena el nodo. Los pods del nodo se desalojan hacia otros nodos disponibles de acuerdo con el Pod Disruption Budget (PDB). Para garantizar alta disponibilidad, utilice una estrategia de despliegue con múltiples réplicas, distribuya las cargas de trabajo en varios nodos y configure un PDB para los servicios críticos con el fin de controlar la cantidad de pods que pueden verse afectados simultáneamente. Esto ayuda a mantener la continuidad del servicio durante las operaciones de mantenimiento de nodos.

        • Durante una actualización con reemplazo de disco del sistema, ACK reinicializa el nodo según la configuración actual del node pool. Esta configuración incluye ajustes como el método de inicio de sesión del nodo, la imagen del sistema operativo y la versión del entorno de ejecución de contenedores. Actualice la configuración del node pool mediante editing the node pool. Cualquier cambio realizado en el nodo por otros medios se sobrescribe durante la actualización.

        • Si un pod en el nodo hace referencia a un HostPath que apunta al disco del sistema, los datos en el directorio HostPath se pierden tras una actualización con reemplazo de disco del sistema.

    Proceso de actualización

    La actualización de un clúster de ACK implica actualizar el plano de control y los node pools. Ejecute una comprobación previa antes de comenzar y programe la actualización fuera del horario pico para minimizar el impacto. Una vez completada la actualización del plano de control, compruebe cuidadosamente el estado operativo del clúster. Luego, actualice los node pools para igualar la versión del plano de control.

    image

    1. Preparación

    • Determine la versión destino para la actualización basándose en ACK release notes. ACK solo admite la actualización de una versión menor a la vez. No puede saltar versiones ni revertir a una anterior.

    • Lea detenidamente version guide correspondiente a la versión destino. Asegúrese de comprender las consideraciones de actualización, los cambios principales y las funciones obsoletas para evitar problemas de compatibilidad posteriores.

    • Planifique una ventana de mantenimiento para el clúster. Ejecute comprobaciones previas con antelación para identificar riesgos potenciales y realice la actualización fuera del horario pico.

    2. Actualización del plano de control

    1. Ejecute una comprobación previa: Antes de actualizar, ejecute una comprobación previa. Proceda con la actualización solo después de que todos los elementos de comprobación se aprueben o se corrijan todos los problemas identificados.

      La comprobación previa inspecciona elementos como API obsoletas (para la versión 1.20 y posteriores), compatibilidad de componentes, compatibilidad de configuración de funciones, estado del clúster y estado de los componentes del plano de control.

    2. Realice la actualización: Una vez aprobada la comprobación previa, proceda con la actualización.

      • Clústeres administrados por ACK y clústeres ACK Serverless: ACK gestiona la actualización. Se actualizan los componentes del plano de control, incluidos kube-apiserver, kube-controller-manager, kube-scheduler y kube-proxy.

      • Clústeres dedicados de ACK: Se utiliza una actualización in situ para maximizar la continuidad del servicio y reducir los riesgos de migración de datos y ajustes de configuración.

        Haga clic para ver el proceso

        1. Cuando ACK detecta que etcd y el entorno de ejecución de contenedores de su clúster necesitan actualizarse, los actualiza en los nodos maestros uno por uno.

        2. Los nodos maestros se seleccionan y actualizan de uno en uno. Se muestra el ID del nodo maestro que se está actualizando actualmente.

        3. Actualice los componentes maestros, incluidos kube-apiserver, kube-controller-manager, kube-scheduler y kube-proxy.

        4. Actualice kubelet en los nodos maestros.

    3. Comprobación posterior a la actualización: Compruebe que la versión del clúster esté actualizada y que los componentes principales, las aplicaciones, la creación de pods y la adición de nodos funcionen correctamente.

    3. Actualización del node pool

    La actualización de un node pool implica actualizar kubelet y el entorno de ejecución de contenedores.

    1. Ejecute una comprobación previa: Antes de actualizar, ejecute una comprobación previa. Proceda con la actualización solo después de que todos los elementos de comprobación se aprueben o se corrijan todos los problemas identificados.

      La comprobación previa inspecciona elementos como el estado de los nodos, los recursos del sistema, el estado de los discos y el entorno de red.

    2. Configure la directiva de actualización y realice la actualización: Elija un método de actualización (in situ o reemplazo de disco) y configure la directiva de actualización por lotes. Esto incluye especificar el número máximo de nodos por lote y si se deben crear instantáneas automáticamente.

    3. Comprobación posterior a la actualización: Compruebe que las versiones de kubelet y del entorno de ejecución de contenedores estén actualizadas, y que la programación de pods y las aplicaciones funcionen correctamente.

    4. Otros procedimientos

    • Cambiar la imagen del sistema operativo: Para actualizar la imagen del sistema operativo de un node pool o cambiar el tipo de sistema operativo (por ejemplo, de Alibaba Cloud Linux 2 a Alibaba Cloud Linux 3), consulte Change the operating system.

    • Componentes del clúster: ACK actualiza únicamente el plano de control y componentes principales como kube-proxy. Actualice manualmente otros components del clúster a través de la página Add-ons fuera del horario pico. Consulte Component overview and release notes para conocer los requisitos de compatibilidad de versiones.

    Consideraciones de actualización

    Planos de control

    • Debe actualizar la versión de Kubernetes de un clúster de ACK de forma secuencial a través de las versiones compatibles. No se admiten reversiones. Para realizar múltiples actualizaciones, monitoree la estabilidad de los servicios de su clúster después de cada actualización antes de iniciar la siguiente.

    • Antes de actualizar, consulte Upgrade clusters para obtener una descripción general. Revise version guide y las notas de la versión correspondientes a cada release. Asegúrese de comprender los detalles de la versión, deprecated APIs y las consideraciones de actualización para evitar problemas de incompatibilidad causados por cambios de funciones en versiones posteriores.

    • La actualización del plano de control no afecta las aplicaciones en ejecución. El API Server se reinicia de forma gradual durante la actualización. Si su aplicación depende en gran medida del API Server, debe poder reintentar conexiones.

    • Kubernetes 1.24 y versiones posteriores no admiten Docker como entorno de ejecución de contenedores integrado. Al actualizar un clúster de la versión 1.22 a la 1.24 o posterior, debe Migrate the node container runtime from Docker to containerd.

    • Evite realizar operaciones y mantenimiento (O&M) en el clúster durante la actualización del plano de control.

    Node pools

    • Comprobaciones previas a la actualización

      • Las actualizaciones de clúster utilizan yum para descargar los paquetes de software necesarios. Si modificó manualmente las configuraciones de red de los nodos o utilizó una imagen de sistema operativo (OS) personalizada, asegúrese de que yum funcione correctamente en sus nodos. Ejecute yum makecache para comprobarlo.

      • ACK no valida estrictamente las imágenes de sistema operativo personalizadas. Por lo tanto, no se puede garantizar una actualización exitosa.

      • Si realizó cambios de configuración en el clúster, como habilitar la partición SWAP o modificar configuraciones de kubelet o del entorno de ejecución mediante comandos, la actualización del clúster podría fallar o sus configuraciones personalizadas podrían sobrescribirse.

      • Después de actualizar un clúster a la versión 1.18, ACK configura Node resource reservation policy de forma predeterminada. Si no se configura la reserva de recursos y el uso de recursos del nodo es alto, es posible que los pods no se programen rápidamente tras ser desalojados. Reserve recursos para sus nodos. Mantenga el uso de CPU en un 50% o menos y el uso de memoria en un 70% o menos.

      • En clústeres que ejecutan la versión 1.24 o anterior, si los pods de una carga de trabajo están configurados únicamente con un Startup Probe, los pods entrarán brevemente en estado NotReady después de que kubelet se reinicie. Despliegue cargas de trabajo con múltiples réplicas en diferentes nodos. Esto garantiza que haya suficientes pods disponibles si un nodo se reinicia.

      • Mantenga al menos un 20% de espacio libre en disco. Esto evita el desalojo de pods causado por capacidad de disco insuficiente durante una actualización.

    • Restricciones de actualización de node pools

      • Las actualizaciones de node pools solo admiten operaciones de escalado horizontal hacia afuera (scale-out). No se admiten operaciones de reducción (scale-in).

      • Si tiene nodos worker no administrados que no pertenecen a un node pool, migrelos. Para obtener más información, consulte Migrate unmanaged nodes to a node pool.

      • No se admite la actualización de node pools de Lingjun durante la actualización de un clúster de ACK.

      • Al actualizar nodos mediante el reemplazo de sus discos, ACK los reinicializa según la configuración actual del node pool. Esto incluye el método de inicio de sesión, etiquetas (labels), taints, imagen del sistema operativo y versión del entorno de ejecución. Para actualizar las configuraciones del node pool, consulte Edit a node pool. Si modificó los nodos de cualquier otra forma, la actualización sobrescribirá sus cambios.

      • Si un pod en un nodo hace referencia a un HostPath que apunta al disco del sistema, los datos en el directorio HostPath se perderán tras una actualización con reemplazo de disco.

      • Al actualizar un node pool en un clúster de versión 1.31 o anterior, el proceso también actualiza el NVIDIA Device Plugin y restablece cualquiera de sus configuraciones no estándar.

    • Escalado de nodos y programación

      • Si la función de escalado de nodos está habilitada en el clúster, cluster-autoscaler se actualiza automáticamente a la última versión tras una actualización exitosa para garantizar que la función de auto scaling no se vea afectada. Después de actualizar el clúster, confirme que la versión de cluster-autoscaler sea correcta. Para obtener más información, consulte Enable node autoscaling.

      • Durante la actualización de un clúster, los nodos con Scaling Mode establecido en Swift podrían fallar en la actualización porque se apagan. Si algunos nodos no se actualizaron debido a Swift tras completar la actualización, se recomienda eliminarlos manualmente.

    • Red y disponibilidad del servicio

      • Si un pod utiliza la dirección SLB de un Service de tipo LoadBalancer para acceder a otro pod en el mismo nodo, y el parámetro externalTrafficPolicy del Service está configurado como Local, es posible que ambos pods ya no estén en el mismo nodo después de la rotación de nodos. Esto puede provocar un fallo en la conexión de red.

      • Al actualizar nodos mediante el reemplazo de sus discos, ACK drena los nodos. Este proceso desaloja los pods hacia otros nodos activos respetando el Pod Disruption Budget (PDB). Para garantizar alta disponibilidad, despliegue cargas de trabajo con múltiples réplicas en diferentes nodos. Además, configure un PDB para los servicios críticos con el fin de controlar la cantidad de pods que pueden verse afectados simultáneamente.

        El tiempo de espera predeterminado para drenar un nodo es de 30 minutos. Si la migración de pods no se completa dentro del periodo de espera, ACK finaliza la actualización para garantizar la estabilidad del servicio.

    Métodos de actualización

    Actualización in situ y reemplazo de disco del sistema

    Para las actualizaciones del plano de control, ACK gestiona el proceso en clústeres administrados por ACK y clústeres ACK Serverless. Los clústeres dedicados de ACK se actualizan mediante una actualización in situ.

    Para la actualización de un node pool, ACK ofrece dos métodos: actualización in situ y actualización con reemplazo de disco del sistema.

    • Actualización in situ: Las actualizaciones se realizan directamente en los nodos existentes sin reemplazar el disco del sistema ni reinicializar el nodo. Los datos originales del nodo no se ven afectados. Las configuraciones relacionadas con la instancia de ECS, como direcciones IP y montajes de discos, permanecen sin cambios. Sin embargo, las configuraciones de componentes gestionados por ACK, como containerd y kubelet, pueden ajustarse según las diferencias entre versiones de componentes.

      Para personalizar las configuraciones de containerd o kubelet, consulte Customize node pool kubelet configurations y Customize containerd configurations for a node pool .

    • Actualización con reemplazo de disco del sistema: Este método reemplaza el disco del sistema y reinicializa el nodo. Aunque las direcciones IP y los montajes de discos de datos permanecen sin cambios, todos los datos en el disco del sistema se eliminan. Habilite las instantáneas de disco y haga una copia de seguridad del disco del sistema antes de continuar.

      Los discos de datos conectados al nodo no se ven afectados.

    Casos especiales

    Se requiere una actualización con reemplazo de disco del sistema en los siguientes escenarios:

    • Migración del entorno de ejecución de contenedores: A partir de la versión 1.24, Kubernetes ya no admite Docker como entorno de ejecución integrado. Debe migrar a containerd utilizando el método de reemplazo de disco.

      Para obtener más información, consulte Migrate the node container runtime from Docker to containerd .

    • Cambios de sistema operativo: A partir de la versión 1.30, CentOS y Alibaba Cloud Linux 2 ya no son compatibles. Utilice el reemplazo de disco para cambiar a un operating system compatible.

      Para obtener más información, consulte Change the operating system .

    • Node pools de Windows: Upgrading Windows node pools requiere el método de reemplazo de disco.

    Alternativa: Actualización gradual mediante un nuevo node pool

    En lugar de actualizar los nodos existentes, puede realizar una actualización gradual creando un nuevo node pool con la configuración destino. Migre las aplicaciones gradualmente estableciendo el antiguo node pool como no programable o actualizando la programación de las cargas de trabajo. Una vez verificada la migración, elimine el antiguo node pool.

    Se le facturará por ambos node pools mientras coexistan; elimine el pool antiguo inmediatamente después de la migración para controlar los costos.

    Preguntas frecuentes

    • ¿Cómo actualizo mi clúster manualmente?

      Para obtener más información, consulte Manually upgrade a cluster. Primero, complete la comprobación previa. Luego, realice la actualización y verifique que el resultado cumpla con sus expectativas.

    • ¿Cuáles son las mejores prácticas para actualizar un clúster?

      • Mantenga una frecuencia regular de actualizaciones: Monitoree version guide, los documentos de ayuda y las notificaciones oficiales. Actualice oportunamente para garantizar soporte continuo y seguridad.

      • Cree un plan de actualización: Dado que las actualizaciones implican cambios importantes como la depreciación de API, cree un plan detallado basado en el tamaño del clúster y las necesidades del negocio. Reserve una ventana de mantenimiento fuera del horario pico y valide la actualización en un entorno de prueba antes de aplicarla en producción.

      • Utilice actualizaciones automáticas: Puede usar la función automatic cluster upgrade. ACK genera un plan de actualización con antelación, activa una comprobación previa y actualiza el clúster dentro de la ventana de mantenimiento especificada. Esto reduce la carga operativa de gestión de versiones.

        También puede create an ACK managed cluster in Intelligent Hosting Mode. La versión del clúster se actualiza automáticamente mediante ACK.

    • ¿Cuánto tiempo tarda la actualización de un clúster?

      • Plano de control: Para clústeres administrados por ACK y clústeres ACK Serverless, la actualización es gestionada por ACK y tarda aproximadamente 5 minutos. Para un clúster dedicado de ACK, los nodos maestros se actualizan secuencialmente, lo cual toma unos 8 minutos por nodo.

      • Node pool: La duración depende de la configuración de lotes de nodos. Una actualización in situ tarda entre 5 y 10 minutos por lote. Una actualización con reemplazo de disco del sistema sin instantáneas tarda unos 8 minutos por lote, pero la duración real depende del proceso de drenado del nodo. Si opta por crear instantáneas, el proceso de actualización esperará a que se creen. El tiempo necesario para crear una instantánea depende de la cantidad de datos.

    • ¿Puedo permanecer en una versión indefinidamente y no actualizar mi clúster?

      No, no puede. Los posibles riesgos de seguridad en versiones obsoletas pueden afectar no solo a sus clústeres, sino también a la seguridad general de Alibaba Cloud. ACK no permite que los clústeres permanezcan en un estado obsoleto durante un periodo prolongado y realiza actualizaciones forzadas para llevarlos a una versión segura y estable.

      Se recomienda actualizar la versión de su clúster oportunamente. Para obtener más información, consulte Manually upgrade a cluster. Esto le permite beneficiarse de las funciones más recientes y recibir un mejor soporte técnico de ACK. Antes de actualizar, consulte release notes correspondiente a la versión destino para comprender sus cambios de funciones y notas importantes. Habilite la función automatic cluster upgrade para garantizar que su clúster se actualice automática y periódicamente.

    • ¿ACK admite saltar versiones menores durante una actualización?

      No, no lo admite. Debe actualizar su clúster de una versión menor a la vez. Además, antes de actualizar el plano de control del clúster, asegúrese de que la versión de los nodos del clúster coincida con la versión del plano de control.

    • La versión de mi clúster es muy antigua. ¿Cómo puedo actualizarla rápidamente?

      Puede utilizar una de las siguientes soluciones.

      • Solución 1: Actualice el clúster de una versión menor a la vez. Después de cada actualización, compruebe si sus aplicaciones empresariales en el clúster se ejecutan correctamente antes de proceder con la siguiente actualización. Para obtener más información, consulte Manually upgrade a cluster.

      • Solución 2: Cree un clúster que ejecute la versión más reciente, migre gradualmente sus aplicaciones al nuevo clúster y luego retire el clúster antiguo. Para obtener información sobre cómo crear y configurar un clúster, consulte Create an ACK managed cluster.

    • ¿Cómo cambio de Docker a containerd al actualizar un clúster de la versión 1.22 a la 1.24?

      ACK ya no admite Docker como entorno de ejecución de contenedores integrado en la versión 1.24 y posteriores. Debe migrar el entorno de ejecución de contenedores de sus nodos de Docker a containerd.

      Puede cambiar el entorno de ejecución en el node pool original utilizando la función de actualización de node pools, o bien puede crear un nuevo node pool con containerd y migrar sus cargas de trabajo. Para obtener más información, consulte Migrate the container runtime of nodes from Docker to containerd.

    • ¿Cómo garantiza ACK la estabilidad durante la actualización de un clúster?

      Un clúster de ACK consta de un plano de control y node pools.

      • Actualización del plano de control: ACK proporciona una función de comprobación previa a la actualización que inspecciona API obsoletas, compatibilidad de componentes, compatibilidad de configuración de funciones y componentes del plano de control. Los resultados de la comprobación no afectan el funcionamiento normal de las aplicaciones en el clúster. Si la comprobación falla, se proporcionan sugerencias de reparación en la consola. Para obtener más información, consulte Manually upgrade a cluster.

      • Actualización del node pool: La actualización de un node pool incluye la actualización de kubelet y containerd. ACK proporciona una función de comprobación previa a la actualización que inspecciona el estado de los nodos, los recursos del sistema, el estado de los discos y el entorno de red. Los resultados de la comprobación no afectan el funcionamiento normal de las aplicaciones en el clúster. Si la comprobación falla, se proporcionan sugerencias de reparación en la consola.

        También puede configurar una directiva de actualización para controlar el ritmo de la misma. Por ejemplo, puede especificar los nodos a actualizar, establecer el número máximo de nodos que se pueden actualizar en cada lote y configurar una directiva de pausa de actualización. Si los discos del sistema de sus nodos contienen datos empresariales importantes, también puede crear snapshots para los nodos antes de actualizar el node pool. Para obtener más información, consulte Upgrade a node pool.

    • ¿Qué debo saber antes de actualizar un clúster?

      No se puede revertir la actualización de un clúster. Tras la validación, actualice primero un entorno de prueba y luego el entorno de producción. También puede upgrade specific nodes first para realizar verificaciones durante el proceso de actualización.

      Las versiones de componentes compatibles, las funciones y las funciones obsoletas varían según la versión de Kubernetes. Para obtener más información, consulte release notes correspondiente a las diferentes versiones.

      Revise notes on control plane upgrades.

      Revise notes on node pool upgrades.

    • ¿Los clústeres con versiones expiradas aún pueden usarse normalmente?

      Sí. Sin embargo, los clústeres obsoletos presentan riesgos de seguridad y estabilidad. Actualice a una versión con mantenimiento lo antes posible.

      Debido a que los clústeres de ACK utilizan una arquitectura administrada, estos riesgos de seguridad no solo afectan a su clúster, sino que también pueden impactar la seguridad general de Alibaba Cloud. Por lo tanto, ACK no permite que los clústeres permanezcan en un estado obsoleto durante un periodo prolongado y realiza una actualización obligatoria a una versión segura y estable. Para obtener más información, consulte Mandatory upgrade of outdated versions.

    • ¿Se admite la reversión de versión después de actualizar un clúster?

      No. No se admiten reversiones para el plano de control, kubelet o las versiones del entorno de ejecución de contenedores después de una actualización.

      Durante la actualización de un node pool, si hay datos importantes del servicio almacenados en el disco del sistema de un nodo, cree una snapshot para el nodo antes de la actualización para respaldar y restaurar los datos del nodo.

    • ¿Qué operación debo realizar primero si necesito actualizar un clúster y migrarlo a un clúster administrado ACK Pro?

      Complete la migración del clúster antes de iniciar la actualización. Una vez que los servicios se verifiquen como estables, proceda con la actualización de versión.

    • ¿Qué hago si la comprobación previa reporta API obsoletas?

      Para Kubernetes 1.20 o posterior, ACK proporciona notificaciones para deprecated APIs. Aunque esto no bloquea la actualización, corrija estos problemas de antemano para garantizar la compatibilidad de las aplicaciones con la nueva versión.

    • ¿Cómo resuelvo una advertencia de "versión de componente demasiado baja" en las comprobaciones previas?

      ACK actualiza únicamente el plano de control y ciertos componentes principales como kube-proxy. Identifique otros components que requieran actualizaciones a través de la página Add-ons en la consola. Puede consultar components que necesitan actualizarse. Antes de continuar, revise Component overview and release notes para garantizar la compatibilidad de versiones. Programe estas actualizaciones de componentes fuera del horario pico para minimizar el impacto en el servicio.

    • ¿Cómo resuelvo un fallo de actualización con el error "the aliyun service is not running on the instance"?

      Este error ocurre porque Cloud Assistant no está disponible, lo que provoca que el comando de actualización falle. Inicie o reinicie Cloud Assistant y luego intente nuevamente la actualización del clúster. Para obtener más información, consulte Start, stop, or uninstall Cloud Assistant Agent.

    • ¿Cómo resuelvo un error "PLEG not healthy" en un nodo?

      Este error indica que el contenedor o el entorno de ejecución de contenedores no responde. Reinicie el nodo y luego intente la actualización nuevamente.

    • ¿Qué debo hacer si obtengo un error **invalid object doesn't have additional properties** al actualizar un clúster?

      Después de actualizar un clúster, también debe actualizar su versión local de kubectl. Si no la actualiza oportunamente, puede encontrar errores como invalid object doesn't have additional properties al usar kubectl localmente, ya que su versión difiere de la versión del API Server del clúster. Para obtener más información sobre cómo instalar o actualizar kubectl, consulte Install and Set Up kubectl. Es fundamental sincronizar su versión de kubectl con la versión del servidor API del clúster para evitar problemas de compatibilidad.