Esta página foi traduzida pela API Cloud Translation.

Migre um cluster de utilizadores para o plano de controlo V2

Este documento mostra como migrar um cluster de utilizadores da versão 1.29 usando o kubeception para o plano de controlo V2. Se os seus clusters estiverem na versão 1.30 ou superior, recomendamos que siga as instruções em Planeie a migração de clusters para funcionalidades recomendadas.

1.29: pré-visualização
1.28: não disponível

Acerca dos planos de controlo do cluster de utilizadores

Antes da versão 1.13 do Google Distributed Cloud, o plano de controlo de um cluster de utilizadores era executado num ou mais nós num cluster de administrador. Este tipo de plano de controlo é denominado kubeception. Na versão 1.13, foi introduzido o Controlplane V2 para novos clusters de utilizadores. Quando o Controlplane V2 está ativado, o plano de controlo para o cluster de utilizador é executado no próprio cluster de utilizador.

As vantagens do Controlplane V2 incluem o seguinte:

Isolamento de falhas. Uma falha do cluster de administração não afeta os clusters de utilizadores.
Separação operacional. Uma atualização do cluster de administrador não causa tempo de inatividade para os clusters de utilizadores.
Separação da implementação. Pode colocar os clusters de administrador e de utilizador em domínios de falha ou sites geográficos diferentes. Por exemplo, um cluster de utilizadores numa localização periférica pode estar num site geográfico diferente do cluster de administrador.

Requisitos

Para migrar um cluster de utilizadores para o plano de controlo V2, o cluster de utilizadores tem de cumprir os seguintes requisitos:

O cluster de utilizadores tem de ter a versão 1.29 ou superior. O cluster de administrador e os conjuntos de nós podem ter uma ou duas versões secundárias inferiores à do cluster de utilizador. Se necessário, atualize o cluster.
O cluster de utilizadores tem de ter o Dataplane V2 ativado. Este campo é imutável. Por isso, se o Dataplane V2 não estiver ativado no cluster, não pode migrá-lo para o Controlplane V2.
O cluster de utilizadores tem de ser configurado para usar o MetalLB ou um equilibrador de carga manual. Se o cluster de utilizadores estiver a usar o equilibrador de carga do SeeSaw, pode migrá-lo para o MetalLB.
Reveja o documento de planeamento de endereços IP e certifique-se de que tem endereços IP suficientes disponíveis para os nós do plano de controlo do cluster de utilizadores. Os nós do plano de controlo requerem endereços IP estáticos e precisa de um endereço IP adicional para um novo IP virtual (VIP) do plano de controlo.

Prepare-se para a migração

Se a encriptação de segredos sempre ativa tiver sido ativada no cluster de utilizadores, tem de seguir os passos em Desative a encriptação de segredos sempre ativa e desencripte os segredos antes de iniciar a migração. Caso contrário, o novo cluster do plano de controlo V2 não consegue desencriptar segredos.

Antes de iniciar a migração, execute o seguinte comando para ver se a encriptação de segredos sempre ativada foi ativada em algum momento:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Se o resultado do comando anterior estiver vazio, significa que a encriptação de segredos sempre ativada nunca foi ativada. Pode iniciar a migração.

Se o resultado do comando anterior não estiver vazio, significa que a encriptação de segredos sempre ativos foi ativada anteriormente. Antes da migração, tem de seguir os passos na secção seguinte para garantir que o novo cluster do plano de controlo V2 consegue desencriptar segredos.

O exemplo seguinte mostra uma saída não vazia:

{"generatedKeyVersions":{"keyVersions":[1]}}

Desative a encriptação de segredos sempre ativa e desencripte os segredos, se necessário

Para desativar a encriptação de segredos sempre ativa e desencriptar segredos, siga os passos abaixo:

No ficheiro de configuração do cluster de utilizadores, para desativar a encriptação de segredos sempre ativos, adicione um campo disabled: true à secção secretsEncryption:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Atualize o cluster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Substitua o seguinte:
- ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador
- USER_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de utilizadores

Faça uma atualização contínua num DaemonSet específico da seguinte forma:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Obtenha os manifestos de todos os segredos no cluster do utilizador, no formato YAML:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Para que todos os segredos sejam armazenados no etcd como texto simples, volte a aplicar todos os segredos no cluster do utilizador:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Já pode iniciar a migração para o plano de controlo V2. Após a conclusão da migração, pode reativar a encriptação de segredos sempre ativa no cluster.

Corrija webhooks de carga de trabalho configurados incorretamente

Se tiver webhooks que incluam pods do sistema no espaço de nomes kube-system, adicione namespaceSelector para filtrar o espaço de nomes kube-system.

Por exemplo,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

Atualize o ficheiro de configuração do cluster de utilizadores

Faça as seguintes alterações ao ficheiro de configuração do cluster de utilizadores existente:

Defina enableControlplaneV2 como verdadeiro.
Opcionalmente, torne o plano de controlo do cluster de utilizadores do Controlplane V2 altamente disponível (HA). Para alterar de um cluster não HA para um cluster HA, altere masterNode.replicas de 1 para 3.
Adicione o endereço IP estático (ou os endereços) para os nós do plano de controlo do cluster de utilizadores à secção network.controlPlaneIPBlock.ips. O endereço IP (ou os endereços) dos nós do plano de controlo tem de estar na mesma VLAN que os nós de trabalho. Os nomes de anfitrião são obrigatórios.
Preencha a máscara de rede e o gateway na secção network.controlPlaneIPBlock.
Se a secção network.hostConfig estiver vazia, preencha-a.
Se o cluster de utilizadores usar o balanceamento de carga manual, configure o balanceador de carga conforme descrito na secção seguinte.
Se o cluster de utilizadores usar o equilíbrio de carga manual, defina loadBalancer.manualLB.controlPlaneNodePort e loadBalancer.manualLB.konnectivityServerNodePort como 0, uma vez que não são necessários quando o Controlplane V2 está ativado.
Atualize o campo loadBalancer.vips.controlPlaneVIP com o novo endereço IP do VIP do plano de controlo. Tenha em atenção que tem de estar na mesma VLAN que os IPs do nó do plano de controlo.
Todos os campos anteriores são imutáveis, exceto quando atualiza o cluster para a migração. Certifique-se de que verifica todas as definições.
Execute gkectl diagnose cluster e corrija os problemas encontrados pelo comando.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Substitua o seguinte:
- ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
- USER_CLUSTER_NAME: o nome do cluster de utilizadores.

Ajuste a configuração manual do balanceador de carga

Se o seu cluster de utilizadores usar o equilíbrio de carga manual, siga o passo nesta secção. Caso contrário, ignore esta secção.

Tal como configura o balanceador de carga para um cluster de utilizadores do CPv2, para cada um dos três novos endereços IP de nós do plano de controlo que especificou na secção network.controlPlaneIPBlock, configure os mapeamentos no balanceador de carga:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Atualize o cluster

Execute o seguinte comando para migrar o cluster para o plano de controlo V2:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Substitua o seguinte:

ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
USER_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de utilizadores.

O comando faz o seguinte:

Crie o plano de controlo de um novo cluster com o ControlPlane V2 ativado.
Pare o plano de controlo do Kubernetes do cluster kubeception.
Tire um instantâneo do etcd do cluster kubeception.
Desligue os nós do plano de controlo do cluster de utilizador do cluster kubeception. Tenha em atenção que, para efeitos de recuperação de falhas, ou seja, o regresso ao cluster kubeception, os nós não são eliminados até à conclusão da migração.
Restaure os dados do cluster no novo plano de controlo com a captura instantânea do etcd mencionada acima.
Ligue os nós do nodepool do cluster kubeception ao novo plano de controlo, que é acessível com o novo controlPlaneVIP.
Reconcilie o cluster de utilizadores restaurado para cumprir o estado final do cluster com o ControlPlane V2 ativado.

Notas

Durante a migração, não existe indisponibilidade para as cargas de trabalho do cluster de utilizadores.
Durante a migração, existe alguma indisponibilidade para o plano de controlo do cluster de utilizadores. Mais especificamente, o plano de controlo fica indisponível entre o passo 2 e a conclusão do passo 6. (O tempo de inatividade é inferior a 7 minutos com base nos nossos testes, mas a duração real depende da sua infraestrutura).
No final da migração, os nós do plano de controlo do cluster de utilizadores dos clusters kubeception são eliminados. Se o cluster de administrador tiver network.ipMode.type definido como "static", pode reciclar alguns dos IPs estáticos não utilizados removendo-os do ficheiro de configuração do cluster de administrador e executando gkectl update admin. Pode listar os objetos de nós do cluster de administrador com kubectl get nodes -o wide para ver que IPs estão em utilização.
Após a migração, o endereço VIP do plano de controlo antigo continua a funcionar, mas é instável. Não confie nisso. Atualize todas as dependências da antiga morada de IP virtual para usar a nova morada de IP virtual assim que possível.

Após a migração

Se desativou a encriptação de segredos sempre ativa antes da migração, siga os passos abaixo para reativar a funcionalidade:

No ficheiro de configuração do cluster de utilizadores, defina secretsEncryption.generatedKey.disabled como falso. Por exemplo:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false
```

Atualize o cluster de utilizadores:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG