Execução de atualização contínua para nós

Cenário

Em uma atualização contínua, um novo nó é criado, as cargas de trabalho existentes são migradas para o novo nó e, em seguida, o nó antigo é excluído. Figura 1 mostra o processo de migração.

Figura 1 Migração da carga de trabalho

Restrições

• O nó original e o nó de destino para o qual a carga de trabalho será migrada devem estar no mesmo cluster.
• O cluster deve ser v1.13.10 ou posterior.
• O pool de nós padrão DefaultPool não oferece suporte a essa configuração.

Cenário 1: o nó original está em DefaultPool

1. Crie um pool de nós. Para mais detalhes, consulte Criação de um pool de nós.
2. Na página da lista de pool de nós, clique em View Node na coluna Operation do pool de nós de destino. O endereço IP do novo nó é exibido na lista de nós.

3. Instale e configure o kubectl. Para mais detalhes, consulte Conexão a um cluster usando o kubectl.

4. Migre a carga de trabalho.
   1. Adicione uma mancha ao nó para onde a carga de trabalho precisa ser migrada.

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

      No comando anterior, [node] indica o endereço IP do nó onde a carga de trabalho a ser migrada está localizada. O valor de [effect] pode ser NoSchedule, PreferNoSchedule ou NoExecute. Neste exemplo, defina este parâmetro como NoSchedule.

      • NoSchedule: os pods que não toleram essa mancha não são agendados no nó; os pods existentes não são despejados do nó.
      • PreferNoSchedule: o Kubernetes tenta evitar o agendamento de pods que não toleram essa mancha no nó.
      • NoExecute: um pod é despejado do nó se já estiver em execução no nó e não está agendado para o nó se ainda não estiver em execução no nó.
      

      Para redefinir uma mancha, execute o comando kubectl taint node [node] key:[effect]- command para remover a mancha.

   2. Despeja com segurança a carga de trabalho no nó.

      kubectl drain [node]

      No comando anterior, [node] indica o endereço IP do nó onde a carga de trabalho a ser migrada está localizada.

   3. No painel de navegação do console do CCE, escolha Workloads > Deployments. Na lista de cargas de trabalho, o status da carga de trabalho a ser migrada é alterado de Running para Unready. Se o status da carga de trabalho mudar para Running novamente, a migração será bem-sucedida.
   

   Durante a migração da carga de trabalho, se a afinidade do nó estiver configurada para a carga de trabalho, a carga de trabalho continuará exibindo uma mensagem indicando que a carga de trabalho não está pronta. Nesse caso, clique no nome da carga de trabalho para ir para a página de detalhes da carga de trabalho. Na página Scheduling Policies, exclua a configuração de afinidade do nó original e configure as políticas de afinidade e antiafinidade do novo nó. Para mais detalhes, consulte Política de agendamento (afinidade/antiafinidade).

   Depois que a carga de trabalho for migrada com êxito, você poderá exibir que a carga de trabalho foi migrada para o nó criado em 1 na página de guia Pods da página de detalhes da carga de trabalho.

5. Exclua o nó original.

   Depois que a carga de trabalho for migrada com êxito e executada corretamente, exclua o nó original.

Cenário 2: o nó original não está em DefaultPool

1. Copie o pool de nós e adicione nós a ele. Para mais detalhes, consulte Cópia de um pool de nós.
2. Clique em View Node na coluna Operation do pool de nós. O endereço IP do novo nó é exibido na lista de nós.

3. Migre a carga de trabalho.
   1. Clique em Edit à direita do pool de nós original e configure Taints.
   2. Insira a chave e o valor de uma mancha. As opções de Effect são NoSchedule, PreferNoSchedule e NoExecute. Selecione NoExecute e clique em Add.
      • NoSchedule: os pods que não toleram essa mancha não são agendados no nó; os pods existentes não são despejados do nó.
      • PreferNoSchedule: o Kubernetes tenta evitar o agendamento de pods que não toleram essa mancha no nó.
      • NoExecute: um pod é despejado do nó se já estiver em execução no nó e não está agendado para o nó se ainda não estiver em execução no nó.
      

      Para redefinir a mancha, exclua a configurada.

   3. Clique em OK.
   4. No painel de navegação do console do CCE, escolha Workloads > Deployments. Na lista de cargas de trabalho, o status da carga de trabalho a ser migrada é alterado de Running para Unready. Se o status da carga de trabalho mudar para Running novamente, a migração será bem-sucedida.
   

   Durante a migração da carga de trabalho, se a afinidade do nó estiver configurada para a carga de trabalho, a carga de trabalho continuará exibindo uma mensagem indicando que a carga de trabalho não está pronta. Nesse caso, clique no nome da carga de trabalho para ir para a página de detalhes da carga de trabalho. Na página Scheduling Policies, exclua a configuração de afinidade do nó original e configure as políticas de afinidade e antiafinidade do novo nó. Para mais detalhes, consulte Política de agendamento (afinidade/antiafinidade).

   Depois que a carga de trabalho é migrada, você pode exibir que a carga de trabalho é migrada para o nó criado em 1 na página de guia Pods da página de detalhes da carga de trabalho.

4. Exclua o nó original.

   Depois que a carga de trabalho for migrada com êxito e executada corretamente, exclua o nó original.