Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Migrando o Azure In-tree para Out-of-tree

O Kubernetes está se afastando da manutenção de provedores de nuvem in-tree.

A partir do Kubernetes 1.29, provedores de nuvem dentro da árvore foram desativados. Você deve desativar DisableCloudProviders e DisableKubeletCloudCredentialProvider para usar o provedor de nuvem Azure in-tree ou migrar do provedor de nuvem in-tree para o provedor fora da árvore. Você pode desativar os gates de recursos necessários definindo feature-gates=DisableCloudProviders=false como um argumento adicional para o Kubelet, o Gerenciador de Controladores e o Servidor API do cluster na configuração avançada do cluster. Além disso, defina DisableKubeletCloudCredentialProvider=false nos argumentos do Kubelet para habilitar a funcionalidade in-tree para autenticação em registros de contêiner Azure para credenciais de pull de imagem. Veja documentação upstream para mais detalhes.

No Kubernetes v1.30 e versões posteriores, os provedores de nuvem in-tree foram removidos. O Rancher permite que você faça upgrade para o Kubernetes v1.30 quando migra de um provedor in-tree para um provedor fora da árvore.

Para migrar do provedor de nuvem in-tree para o provedor de nuvem Azure fora da árvore, você deve parar o gerenciador de controladores kube do cluster existente e instalar o gerenciador de controladores de nuvem Azure.

Se for aceitável ter algum tempo de inatividade durante a migração, siga as instruções para configuração de um provedor de nuvem externo. Estas instruções descrevem como configurar o provedor de nuvem fora da árvore para um cluster recém-provisionado. Durante a configuração, haverá algum tempo de inatividade, pois há um intervalo de tempo entre quando o antigo provedor de nuvem para de funcionar e quando o novo provedor de nuvem começa a funcionar.

Se sua configuração não puder tolerar qualquer tempo de inatividade do plano de controle, você deve habilitar a migração de líder. Isso facilita uma transição suave dos controladores no gerenciador de controladores kube para seus equivalentes no gerenciador de controladores de nuvem.

Importante:

A documentação do Kubernetes documentação de migração do controlador de nuvem afirma que é possível migrar com a mesma versão do Kubernetes, mas pressupõe que a migração faz parte de um upgrade do Kubernetes. Consulte a documentação do Kubernetes sobre migrando para usar o gerenciador de controladores de nuvem para ver se você precisa personalizar sua configuração antes de migrar. Confirme seus valores de configuração de migração. Se o seu provedor de nuvem fornecer uma implementação do controlador Node IPAM, você também precisa migrar o controlador IPAM.

A partir da versão 1.26 do Kubernetes, os tipos de volume persistente in-tree kubernetes.io/azure-disk e kubernetes.io/azure-file estão descontinuados e não são mais suportados. Não há planos para remover esses drivers após sua descontinuação, no entanto, você deve migrar para os drivers CSI correspondentes, disk.csi.azure.com e file.csi.azure.com. Para revisar as opções de migração para suas classes de armazenamento e atualizar seu cluster para usar os drivers CSI do Azure Disks e Azure Files, veja Migrar de drivers in-tree para drivers CSI.

  • RKE2

  • RKE

  1. Atualize a configuração do cluster para habilitar a migração de líder:

    spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
          kube-controller-manager-arg:
            - enable-leader-migration
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/control-plane-role
              operator: In
              values:
                - 'true'

    Observe que o provedor de nuvem ainda está azure nesta etapa:

    spec:
  rkeConfig:
    machineGlobalConfig:
      cloud-provider-name: azure

  2. Cordon os nós do plano de controle para que os pods do controlador de nuvem do Azure sejam executados apenas em nós após a atualização para o provedor de nuvem externo:

    kubectl cordon -l "node-role.kubernetes.io/control-plane=true"

  3. Para implantar o gerenciador do controlador de nuvem do Azure, use qualquer uma das opções disponíveis:

    Confirme que o chart está instalado, mas que os novos pods ainda não estão em execução devido aos nós do plano de controle que estão em cordonamento.

  4. Para habilitar a migração de líder, adicione --enable-leader-migration aos argumentos do contêiner de cloud-controller-manager:

    kubectl -n kube-system patch deployment cloud-controller-manager \
--type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'

  5. Atualize o cluster de provisionamento para alterar o provedor de nuvem e remover os argumentos de migração de líder do gerenciador do controlador kube. Se estiver atualizando a versão do Kubernetes, defina a versão do Kubernetes também na seção spec.kubernetesVersion do arquivo YAML do cluster.

    spec:
  rkeConfig:
    machineGlobalConfig:
      cloud-provider-name: external

    Remova enable-leader-migration do gerenciador do controlador kube:

    spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
          kube-controller-manager-arg:
            - enable-leader-migration
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/control-plane-role
              operator: In
              values:
                - 'true'

  6. Descordone os nós do plano de controle para que os pods do controlador de nuvem do Azure agora sejam executados em nós:

    kubectl uncordon -l "node-role.kubernetes.io/control-plane=true"

  7. Atualize o cluster. Os pods cloud-controller-manager devem agora estar em execução.

    kubectl rollout status deployment -n kube-system cloud-controller-manager
kubectl rollout status daemonset -n kube-system cloud-node-manager

  8. O provedor de nuvem é responsável por definir o ProviderID do nó. Verifique se todos os nós estão inicializados com o ProviderID:

    kubectl describe nodes | grep "ProviderID"

  9. (Opcional) Você também pode desativar a migração de líder após o upgrade, pois a migração de líder não é necessária com apenas um cloud-controller-manager. Atualize a implantação cloud-controller-manager para remover a migração de líder dos argumentos do contêiner:

    - --enable-leader-migration=true

  1. Atualize a configuração do cluster para habilitar a migração de líder em cluster.yml:

    services:
  kube-controller:
    extra_args:
      enable-leader-migration: "true"

    Observe que o provedor de nuvem ainda está azure nesta etapa:

    cloud_provider:
  name: azure

  2. Cordon os nós do plano de controle, para que os pods do controlador de nuvem do Azure sejam executados em nós apenas após o upgrade para o provedor de nuvem externo:

    kubectl cordon -l "node-role.kubernetes.io/controlplane=true"

  3. Para instalar o gerenciador de controlador de nuvem do Azure, siga os mesmos passos que ao instalar o provedor de nuvem do Azure em um novo cluster:

  4. Confirme que o chart está instalado, mas que os novos pods ainda não estão em execução devido aos nós do plano de controle que estão em cordonamento. Após atualizar o cluster na próxima etapa, o RKE fará upgrade e descordonará cada nó, e agendará os pods cloud-controller-manager.

  5. Para habilitar a migração de líder, adicione --enable-leader-migration aos argumentos do contêiner de cloud-controller-manager:

    kubectl -n kube-system patch deployment cloud-controller-manager \
--type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'

  6. Atualize cluster.yml para mudar o provedor de nuvem para external e remover os argumentos de migração de líder do kube-controller.

    rancher_kubernetes_engine_config:
  cloud_provider:
    name: external

    Remova enable-leader-migration se você não quiser que ele esteja habilitado em seu cluster:

    services:
  kube-controller:
    extra_args:
      enable-leader-migration: "true"

  7. Se você estiver atualizando a versão do Kubernetes do cluster, defina a versão do Kubernetes também.

  8. Atualize o cluster. Os pods cloud-controller-manager devem agora estar em execução.

    kubectl rollout status deployment -n kube-system cloud-controller-manager
kubectl rollout status daemonset -n kube-system cloud-node-manager

  9. O provedor de nuvem é responsável por definir o ProviderID do nó. Verifique se todos os nós estão inicializados com o ProviderID:

    kubectl describe nodes | grep "ProviderID"

  10. (Opcional) Você também pode desativar a migração de líder após o upgrade, pois a migração de líder não é necessária com apenas um cloud-controller-manager. Atualize a implantação cloud-controller-manager para remover a migração de líder dos argumentos do contêiner:

    - --enable-leader-migration=true