Neste documento, mostramos como migrar um cluster de usuário da versão 1.29 ou mais recente usando o kubeception para o Controlplane V2.
1.29: visualização
1.28: não disponível
1.16: não disponível
Sobre os planos de controle do cluster de usuário
Antes da versão 1.13 do Google Distributed Cloud, o plano de controle de um cluster de usuário era executado em um ou mais nós em um cluster de administrador. Esse tipo de plano de controle é chamado de kubeception. Na versão 1.13, o Controlplane V2 foi introduzido para novos clusters de usuário. Quando o Controlplane V2 está ativado, o plano de controle do cluster de usuário é executado no próprio cluster.
Os benefícios do Controlplane V2 incluem:
Isolamento de falhas. Uma falha no cluster de administrador não afeta os clusters de usuário.
Separação operacional. Um upgrade de cluster de administrador não causa inatividade para clusters de usuário.
Separação de implantação. É possível colocar os clusters de administrador e de usuário em diferentes domínios de falha ou locais geográficos. Por exemplo, um cluster de usuário em um local de borda pode estar em uma localização geográfica diferente do cluster de administrador.
Requisitos
Para migrar um cluster de usuário para o Controlplane V2, ele precisa atender aos seguintes requisitos:
O cluster de usuário precisa ter a versão 1.29 ou mais recente. O cluster de administrador e os pools de nós podem ser uma ou duas versões secundárias menores que o cluster de usuário. Se necessário, faça upgrade do cluster.
O cluster de usuário precisa ter o Dataplane V2 ativado. Esse campo não pode ser modificado. Portanto, se o Dataplane V2 não estiver ativado no cluster, não será possível migrá-lo para o Controlplane V2.
O cluster de usuário precisa ser configurado para usar o MetalLB ou um balanceador de carga manual. Se o cluster de usuário estiver usando o balanceador de carga SeeSaw, migre-o para o MetalLB.
Consulte o documento de planejamento de endereços IP e verifique se você tem endereços IP suficientes disponíveis para os nós do plano de controle do cluster de usuário. Os nós do plano de controle exigem endereços IP estáticos, e você vai precisar de um endereço IP extra para um novo IP virtual (VIP) do plano de controle.
Atualizar o arquivo de configuração do cluster de usuário
Faça as seguintes alterações no arquivo de configuração do cluster de usuário atual:
Defina
enableControlplaneV2
como verdadeiro.Se quiser, torne o plano de controle para o cluster de usuário do Controlplane V2 altamente disponível (HA, na sigla em inglês). Para mudar de um cluster que não é de alta disponibilidade para um cluster de alta disponibilidade, altere
masterNode.replicas
de 1 para 3.Adicione os endereços IP estáticos dos nós do plano de controle do cluster de usuário à seção
network.controlPlaneIPBlock.ips
.Preencha a máscara de rede e o gateway na seção
network.controlPlaneIPBlock
.Se a seção
network.hostConfig
estiver vazia, preencha-a.Se o cluster de usuário usar balanceamento de carga manual, configure o balanceador de carga para incluir os IPs de nó do plano de controle para o tráfego do plano de dados:
- (
ingressVIP
:80) -> (CP_NODE_IP_ADDRESSES:ingressHTTPNodePort
) - (
ingressVIP
:443) -> (CP_NODE_IP_ADDRESSES:ingressHTTPSNodePort
)
- (
Atualize o campo
loadBalancer.vips.controlPlaneVIP
com o novo endereço IP do VIP do plano de controle. Observe que ele precisa estar na mesma VLAN que os IPs de nó do plano de controle.Todos os campos anteriores são imutáveis, exceto durante a atualização do cluster para a migração. Verifique todas as configurações.
Execute
gkectl diagnose cluster
e corrija todos os problemas que o comando encontrar.gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME
Substitua:
ADMIN_CLUSTER_KUBECONFIG
: o caminho do arquivo kubeconfig do cluster de administradorCLUSTER_NAME
: o nome do cluster do usuário.
Ajustar a configuração manual do balanceador de carga
Se o cluster de usuário usar balanceamento de carga manual, siga a etapa desta seção. Caso contrário, pule esta seção.
Da mesma forma que configurar o balanceador de carga para um cluster de usuário do CPv2, configure os mapeamentos no balanceador de carga para cada um dos três novos endereços IP do nó do plano de controle especificados na seção network.controlPlaneIPBlock:
- (ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
- (ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
Atualizar o cluster
Execute o comando a seguir para migrar o cluster para o Controlplane V2:
gkectl update cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG
Substitua:
ADMIN_CLUSTER_KUBECONFIG
: o caminho do arquivo kubeconfig do cluster de administrador.USER_CLUSTER_CONFIG
: o caminho do arquivo de configuração do cluster de usuário.
O comando faz o seguinte:
Crie o plano de controle de um novo cluster com o ControlPlane V2 ativado.
Interrompa o plano de controle do Kubernetes do cluster do Kubeception.
Crie um snapshot do etcd do cluster do Kubeception.
Desligue os nós do plano de controle do cluster de usuário do cluster do kubeception. Para recuperação de falhas, ou seja, para o cluster de kubeception, os nós não são excluídos até a conclusão da migração.
Restaure os dados do cluster no novo plano de controle com o snapshot do etcd mencionado acima.
Conecte os nós do pool de nós do cluster do kubeception ao novo plano de controle, que pode ser acessado com o novo
controlPlaneVIP
.Reconcilie o cluster de usuário restaurado para atender ao estado final do cluster com o ControlPlane V2 ativado.
Observações
Durante a migração, não há inatividade para as cargas de trabalho do cluster de usuário.
Durante a migração, há algum tempo de inatividade para o plano de controle do cluster de usuário. Mais especificamente, o plano de controle fica indisponível entre a etapa 2 e a conclusão da etapa 6. Com base em nossos testes, o tempo de inatividade é inferior a sete minutos, mas a duração real depende da sua infraestrutura.
No final da migração, os nós do plano de controle do cluster de usuário dos clusters de kubeception são excluídos. Se o cluster de administrador tiver network.ipMode.type definido como "static", você poderá reciclar alguns dos IPs estáticos não utilizados removendo-os do arquivo de configuração do cluster de administrador e executando
gkectl update admin
. É possível listar os objetos de nó do cluster de administrador comkubectl get nodes -o wide
para ver quais IPs estão em uso.