Realización de actualización de rodamiento para nodos

Escenario

En una actualización sucesiva, se crea un nuevo nodo, las cargas de trabajo existentes se migran al nuevo nodo y, a continuación, se elimina el nodo antiguo. Figura 1 muestra el proceso de migración.

Figura 1 Migración de cargas de trabajo

Restricciones

• El nodo original y el nodo de destino al que se va a migrar la carga de trabajo deben estar en el mismo clúster.
• El clúster debe ser de v1.13.10 o posterior.
• El grupo de nodos predeterminado DefaultPool no admite esta configuración.

Escenario 1: El nodo original está en el DefaultPool

1. Cree un grupo de nodos. Para obtener más información, véase Creación de un grupo de nodos.
2. Haga clic en el nombre del grupo de nodos. La dirección IP del nuevo nodo se muestra en la lista de nodos.

3. Instale y configure kubectl. Para obtener más información, véase Conexión a un clúster con kubectl.

4. Migre la carga de trabajo.
   1. Agregue una mancha al nodo donde la carga de trabajo debe migrarse.

      kubectl taint node [node] key=value:[effect]

      En el comando anterior, [node] indica la dirección IP del nodo donde se encuentra la carga de trabajo que se va a migrar. El valor de [effect] puede ser NoSchedule, PreferNoSchedule o NoExecute. En este ejemplo, establezca este parámetro en NoSchedule.

      • NoSchedule: Los pods que no toleran esta mancha no se programan en el nodo; los pods existentes no se desalojan del nodo.
      • PreferNoSchedule: Kubernetes intenta evitar la programación de pods que no toleran esta mancha en el nodo.
      • NoExecute: Un pod es desalojado del nodo si ya se está ejecutando en el nodo, y no está programado en el nodo si aún no se está ejecutando en el nodo.
      

      Para restablecer una mancha, ejecute el kubectl taint node [node] key:[effect]- command para eliminar la mancha.

   2. Expulsa de forma segura la carga de trabajo en el nodo.

      kubectl drain [node]

      En el comando anterior, [node] indica la dirección IP del nodo donde se encuentra la carga de trabajo que se va a migrar.

   3. En el panel de navegación de la consola de CCE, elija Workloads > Deployments. En la lista de cargas de trabajo, el estado de la carga de trabajo que se va a migrar cambia de Running a Unready. Si el estado de la carga de trabajo cambia de nuevo a Running, la migración se realiza correctamente.
   

   Durante la migración de la carga de trabajo, si se configura la afinidad de nodos para la carga de trabajo, la carga de trabajo sigue mostrando un mensaje que indica que la carga de trabajo no está lista. En este caso, haga clic en el nombre de la carga de trabajo para ir a la página de detalles de la carga de trabajo. En la página de ficha Scheduling Policies, elimine la configuración de afinidad del nodo original y configure las políticas de afinidad y antiafinidad del nuevo nodo. Para obtener más información, véase Política de programación (afinidad/antiafinidad).

   Después de migrar correctamente la carga de trabajo, puede ver que la carga de trabajo se migra al nodo creado en 1 en la página de ficha Pods de la página de detalles de la carga de trabajo.

5. Elimine el nodo original.

   Una vez que la carga de trabajo se haya migrado correctamente y se ejecute correctamente, elimine el nodo original.

Escenario 2: El nodo original no está en el DefaultPool

1. Copie el grupo de nodos y agréguele nodos. Para obtener más información, véase Copia de un grupo de nodos.
2. Haga clic en View Node en la columna Operation del grupo de nodos. La dirección IP del nuevo nodo se muestra en la lista de nodos.

3. Migre la carga de trabajo.
   1. Haga clic en Edit a la derecha del grupo de nodos original y establezca Taints.
   2. Introduzca la clave y el valor de la mancha. Las opciones de Effect son NoSchedule, PreferNoSchedule y NoExecute. Seleccione NoExecute y haga clic en Add.
      • NoSchedule: Los pods que no toleran esta mancha no se programan en el nodo; los pods existentes no se desalojan del nodo.
      • PreferNoSchedule: Kubernetes intenta evitar la programación de pods que no toleran esta mancha en el nodo.
      • NoExecute: Un pod es desalojado del nodo si ya se está ejecutando en el nodo, y no está programado en el nodo si aún no se está ejecutando en el nodo.
      

      Si necesita restablecer la mancha, elimine el configurado.

   3. Haga clic en OK.
   4. En el panel de navegación de la consola de CCE, elija Workloads > Deployments. En la lista de cargas de trabajo, el estado de la carga de trabajo que se va a migrar cambia de Running a Unready. Si el estado de la carga de trabajo cambia de nuevo a Running, la migración se realiza correctamente.
   

   Durante la migración de la carga de trabajo, si se configura la afinidad de nodos para la carga de trabajo, la carga de trabajo sigue mostrando un mensaje que indica que la carga de trabajo no está lista. En este caso, haga clic en el nombre de la carga de trabajo para ir a la página de detalles de la carga de trabajo. En la página de ficha Scheduling Policies, elimine la configuración de afinidad del nodo original y configure las políticas de afinidad y antiafinidad del nuevo nodo. Para obtener más información, véase Política de programación (afinidad/antiafinidad).

   Después de migrar correctamente la carga de trabajo, puede ver que la carga de trabajo se migra al nodo creado en 1 en la página de ficha Pods de la página de detalles de la carga de trabajo.

4. Elimine el nodo original.

   Una vez que la carga de trabajo se haya migrado correctamente y se ejecute correctamente, elimine el nodo original.