Antes de comenzar

Precauciones

• Los clústeres actualizados no se pueden revertir. Por lo tanto, realice la actualización durante las horas no pico para minimizar el impacto en sus servicios.
• Antes de actualizar un clúster, obtenga información sobre las características y diferencias de cada versión de clúster de Notas del lanzamiento de Kubernetes para evitar excepciones debido al uso de una versión de clúster incompatible.
• No apagar, reiniciar o eliminar nodos durante la actualización del clúster. De lo contrario, la actualización falla.
• Antes de actualizar un clúster, deshabilite las políticas de ajuste automático para evitar que se escala el nodo durante la actualización. De lo contrario, la actualización falla.
• Si modifica localmente la configuración de un nodo de clúster, la actualización del clúster puede fallar o la configuración puede perderse después de la actualización. Por lo tanto, modifique las configuraciones de la consola de CCE (página de lista de clústeres o grupos de nodos) para que se hereden automáticamente durante la actualización.
• Durante la actualización del clúster, los servicios de carga de trabajo en ejecución no se interrumpirán, pero el acceso al servidor de API se interrumpirá temporalmente.
• Antes de actualizar el clúster, compruebe si el clúster está en buen estado. Si el clúster es anormal, puede intentar rectificar el error. Si el error persiste, envíe un ticket de servicio para obtener ayuda.
• Para garantizar la seguridad de los datos, se recomienda realizar una copia de respaldo de los datos antes de actualizar el clúster. Durante la actualización, no se recomienda realizar ninguna operación en el clúster.
• Durante la actualización del clúster, la mancha node.kubernetes.io/upgrade (el efecto es de NoSchedule) se agrega al nodo. Una vez completada la actualización del clúster, se elimina la mancha. No agregue manchas con el mismo nombre de clave en el nodo. Incluso si las manchas tienen diferentes efectos, pueden ser eliminados por el sistema por error después de la actualización.

Restricciones

• Actualmente, solo se pueden actualizar los clústeres de CCE que consisten en los nodos de VM y los clústeres de CCE Turbo. Los clústeres de Kunpeng solo se pueden actualizar a v1.19.
• Actualmente, los clústeres que utilizan imágenes privadas no se pueden actualizar.
• Después de actualizar el clúster, si la vulnerabilidad de containerd del motor de contenedor se corrige en las Notas de la versión del clúster, debe reiniciar manualmente containerd para que la actualización surta efecto. Lo mismo se aplica a los pods existentes.
• Si monta el archivo docker.sock en un nodo en un pod en modo HostPath, Docker se reiniciará durante la actualización, pero el archivo de calcetín en el contenedor no cambia. Como resultado, sus servicios pueden ser anormales, se recomienda montar el archivo de calcetín montando el directorio.
• Si se utiliza initContainer o Istio en la actualización in situ de un clúster de v1.15, preste atención a las siguientes restricciones:

  En kubelet 1.16 y versiones posteriores, las clases de QoS son diferentes de las versiones anteriores. En kubelet 1.15 y versiones anteriores, solo se cuentan los contenedores en el spec.containers. En kubelet 1.16 y versiones posteriores, se cuentan los contenedores tanto en spec.containers como en spec.initContainers. La clase de QoS de un pod cambiará después de la actualización. Como resultado, el contenedor en el pod se reinicia. Se recomienda modificar la clase de QoS del contenedor de servicio antes de la actualización para evitar este problema. Para obtener más información, véase Tabla 1.

  Tabla 1 Cambios de clase de QoS antes y después de la actualización

  Init Container (Calculado según spec.initContainers)	Service Container (Calculado según spec.containers)	Pod (Calculado según spec.containers y spec.initContainers)	Impactado o no
  Guaranteed	Besteffort	Burstable	Sí
  Guaranteed	Burstable	Burstable	No
  Guaranteed	Guaranteed	Guaranteed	No
  Besteffort	Besteffort	Besteffort	No
  Besteffort	Burstable	Burstable	No
  Besteffort	Guaranteed	Burstable	Sí
  Burstable	Besteffort	Burstable	Sí
  Burstable	Burstable	Burstable	No
  Burstable	Guaranteed	Burstable	Sí

Copia de respaldo de actualización

Cómo hacer una copia de respaldo de un nodo:

• Copia de respaldo de la base de datos etcd: CCE realiza automáticamente una copia de respaldo de la base de datos etcd durante la actualización del clúster.
• Copia de seguridad del nodo principal (recomendado manual confirmation required): En la página de confirmación de la actualización, haga clic en Backup para hacer una copia de respaldo de todo el nodo principal del clúster. El proceso de copia de respaldo utiliza el servicio Cloud Backup and Recovery (CBR) y tarda unos 20 minutos. Si hay muchas tareas de copia de respaldo en la nube en el sitio actual, el tiempo de copia de respaldo puede prolongarse.