26. Inicializar várias zonas

Tempo estimado para a conclusão: 3 horas

Proprietário do componente operacional: MZ

Perfil de habilidade: engenheiro de implantação

26.1. Visão geral

O bootstrapping multizona envolve a configuração do plano de controle global raiz. A primeira zona em um universo estabelece o plano de controle global. Outras zonas entram no plano de controle global. A inclusão em um plano de controle global é um processo mais complexo do que o estabelecimento do plano de controle, porque é preciso estabelecer confiança entre o plano de controle global do universo e a nova zona. Ao participar de um plano de controle global, duas zonas estão envolvidas:

  • Zona de ancoragem: uma zona que já faz parte do plano de controle global. Essa deve ser a zona cuja instância do GitLab é usada para aplicar mudanças de infraestrutura como código (IaC) à API global do universo.
  • Zona de junção: a zona que está entrando no plano de controle global.

Você inicializou a primeira zona do universo em Inicializar multizona. Essa zona serve como âncora quando outras zonas entram no universo.

Se já houver uma API global no universo e você estiver inicializando uma zona que está entrando no universo, siga estas etapas.

26.2. Inicializar várias zonas em zonas que entram em um universo

Confirme se você inicializou várias zonas na zona de ancoragem antes de continuar.

26.2.1. Iniciar contêiner da ferramenta de E/S

Para segurança e capacidade de auditoria, o processo de inicialização de várias zonas precisa ser realizado usando credenciais pessoais para acessar o Kubernetes (não uma configuração de administrador do Kubernetes) e IaC para aprovação de outra parte de solicitações de autorização para realizar ações sensíveis. Todas as ferramentas necessárias para realizar as ações de bootstrap estão incluídas no contêiner de ferramentas de E/S. Consulte o processo de configuração do contêiner da ferramenta de E/S OOPS-P0065 para saber como iniciar o contêiner no ambiente do OIC. Uma zona que entra no plano de controle global envolve interações com duas zonas, uma das quais (a zona de ancoragem) não está operando em condições do dia zero. Portanto, medidas de autenticação e autorização no nível de produção precisam ser usadas para garantir que a segurança da zona de ancoragem não seja comprometida.

26.2.2. Inicializar o repositório do GitLab

Use as credenciais do provedor de identidade (IdP) configurado em Configuração de infraestrutura como código e siga o processo OOPS-P0066 para gerenciar o acesso de usuários do GitLab.

Clone o repositório de IaC da zona de ancoragem:

git clone https://iac.GLOBAL_DNS_DOMAIN/gdch/iac.git /tmp/iac

Substitua GLOBAL_DNS_DOMAIN pelo domínio DNS do universo.

Informe o nome de usuário e a senha quando solicitado.

26.2.3. Adicionar os papéis necessários

Siga as instruções no runbook do processo de elevação de acesso e privilégios IAM-R0005 para criar as vinculações de função e função de cluster necessárias:

  • Adicione uma vinculação de papel de cluster com o papel de cluster mz-bootstrap-joining-editor no cluster root-admin da zona de junção.
  • Adicione uma vinculação de papel de cluster com o papel de cluster mz-bootstrap-anchor-reader no cluster root-admin da zona de ancoragem.
  • Adicione uma vinculação de papel com o papel mz-bootstrap-viewer no namespace mz-system na API global da zona de ancoragem.

26.2.4. Criar solicitação de token

Ao participar de um plano de controle global, o contato é estabelecido entre a zona participante e a zona de ancoragem usando um token de bootstrap da API global. Uma solicitação de token é usada para pedir um token da API global na zona de ancoragem.

  1. Crie uma ramificação para uma solicitação de mesclagem:

    cd /tmp/iac
git checkout -b JOINING_ZONE_NAME-mz-token-request

    Substitua JOINING_ZONE_NAME pelo nome da zona, conforme derivado do Questionário de coleta de informações do cliente, conforme descrito na nota ao final da seção.

  2. Faça login na zona de junção. Consulte a interface de linha de comando gdcloud para mais detalhes. Isso é necessário porque o comando gdcloud na próxima etapa interage com o cluster de administrador raiz na zona de junção para receber um par de chaves de criptografia de chave pública para transferir com segurança o token de inicialização da zona de ancoragem para a zona de junção.

  3. Gere o arquivo YAML de solicitação de token:

    gdcloud system multi-zone create-token-request --cluster root --zone JOINING_ZONE_NAME --client-type api-join --namespace global-kube-system --output-file /tmp/iac/infrastructure/global/orgs/root/mz-token-request.yaml

  4. Crie ou atualize o arquivo kustomization.yaml.

    1. Abra o arquivo:

      vim infrastructure/global/orgs/root/kustomization.yaml

    2. Se o arquivo já existia, adicione um item mz-token-request.yaml à lista resources. Caso contrário, adicione o YAML do recurso completo:

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: global-root-kustomization
resources:
- mz-token-request.yaml

    3. Salve o arquivo e saia do vim.

  5. Confirme as mudanças na ramificação:

    git add infrastructure
git commit

  6. Envie a ramificação para o GitLab:

    git push

  7. Mescle as mudanças na ramificação main. Consulte o runbook IAC-R0004 para mais detalhes.

26.2.5. Criar token

Siga estas etapas para criar o token de inicialização na zona de junção:

  1. Crie uma ramificação para uma solicitação de mesclagem:

    cd /tmp/iac
git checkout main
git pull --ff-only
git checkout -b JOINING_ZONE_NAME-mz-token

  2. Faça login na zona de ancoragem. Consulte a interface de linha de comando gdcloud para mais detalhes. Isso é necessário porque o comando gdcloud na próxima etapa interage com a API global na zona de ancoragem para criar e criptografar um token de inicialização.

  3. Gere o arquivo YAML do token:

    gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace global-kube-system --output-file /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-token.yaml

  4. Crie ou atualize o arquivo kustomization.yaml.

    1. Abra o arquivo:

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml

    2. Se o arquivo já existia, adicione um item mz-token.yaml à lista resources. Caso contrário, adicione o YAML completo do recurso:

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: root-admin-kustomization
resources:
- mz-token.yaml

    3. Salve o arquivo e saia do vim.

  5. Confirme as mudanças na ramificação:

    git add infrastructure
git commit

  6. Envie a ramificação para o GitLab:

    git push

  7. Mescle as mudanças na ramificação main. Consulte o runbook IAC-R0004 para mais detalhes.

26.2.6. Criar o recurso de inicialização

Siga estas etapas para criar o recurso de inicialização no cluster de administrador raiz da zona de junção:

  1. Crie uma ramificação para uma solicitação de mesclagem:

    cd /tmp/iac
git checkout main
git pull --ff-only
git checkout -b JOINING_ZONE_NAME-mz-bootstrap

  2. Faça login na zona de ancoragem. Consulte a interface de linha de comando gdcloud para mais detalhes. Isso é necessário porque, durante uma operação de junção, o comando gdcloud na próxima etapa interage com o cluster de administrador raiz na zona de ancoragem para recuperar informações de conectividade para interagir com a API global na zona de ancoragem.

  3. Gere o arquivo YAML de bootstrap:

    gdcloud system multi-zone create-bootstrap --type join --output-file /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-bootstrap.yaml

  4. Crie ou atualize o arquivo kustomization.yaml:

    1. Abra o arquivo:

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml

    2. Se o arquivo já existia, adicione um item mz-token.yaml à lista resources. Caso contrário, adicione o YAML completo do recurso:

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: root-admin-kustomization
resources:
- mz-bootstrap.yaml

    3. Salve o arquivo e saia do vim.

  5. Confirme as mudanças na ramificação:

    git add infrastructure
git commit

  6. Envie a ramificação para o GitLab:

    git push

  7. Mescle as mudanças na ramificação main. Consulte o runbook IAC-R0004 para mais detalhes.

Depois que as mudanças são mescladas, a IaC propaga o recurso Bootstrap para o novo cluster de administrador raiz da zona, onde ele é reconciliado. Essa é uma operação assíncrona, então a API global não vai estar disponível imediatamente após a fusão.

26.2.7. Validar a implantação bem-sucedida da API global

Para validar a implantação da API global, siga estas etapas:

  1. Faça login na zona de junção. Consulte a interface de linha de comando gdcloud para mais detalhes.

  2. Consiga uma configuração do Kubernetes para a API global raiz (global-api). Consulte o runbook IAM-R0004 para mais detalhes.

  3. Verifique a conectividade com a API global na zona de junção:

    kubectl version

26.2.8. Limpar par de chaves

Para excluir o par de chaves usado para transferir o token de inicialização da zona de ancoragem para a zona de junção, siga estas etapas:

  1. Faça login na zona de junção. Consulte a interface de linha de comando gdcloud para mais detalhes.

  2. Consiga uma configuração do Kubernetes para o cluster de administrador raiz (root-admin). Consulte o runbook IAM-R0004 para mais detalhes.

  3. Execute o comando a seguir para excluir o par de chaves:

    kubectl delete keypair -n global-kube-system kp

26.2.9. Limpar solicitação de token

Para excluir o arquivo YAML de solicitação de token, siga estas etapas:

  1. Crie uma ramificação para uma solicitação de mesclagem:

    cd /tmp/iac
git checkout main
git pull --ff-only
git checkout -b JOINING_ZONE_NAME-mz-token-request-delete

  2. Exclua o arquivo YAML de solicitação de token:

    rm /tmp/iac/infrastructure/global/orgs/root/mz-token-request.yaml

  3. Atualize o arquivo kustomization.yaml.

    1. Abra o arquivo:

      vim infrastructure/global/orgs/root/kustomization.yaml

    2. Remova o item mz-token-request.yaml da lista resources, salve o arquivo e saia do vim.

  4. Confirme as mudanças na ramificação:

    git add infrastructure
git commit

  5. Envie a ramificação para o GitLab:

    git push

  6. Mescle as mudanças na ramificação main. Consulte o runbook IAC-R0004 para mais detalhes.

26.2.10. Limpar token

Depois que a API global estiver disponível na zona de junção, exclua o token, já que ele não será mais necessário:

  1. Crie uma ramificação para uma solicitação de mesclagem:

    cd /tmp/iac
git checkout main
git pull --ff-only
git checkout -b JOINING_ZONE_NAME-mz-token-delete

  2. Exclua o arquivo YAML do token:

    rm /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-token.yaml

  3. Atualize o arquivo kustomization.yaml se ele já existir.

    1. Abra o arquivo:

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml

    2. Remova o item mz-token.yaml da lista resources, salve o arquivo e saia do vim.

  4. Confirme as mudanças na ramificação:

    git add infrastructure
git commit

  5. Envie a ramificação para o GitLab:

    git push

  6. Mescle as mudanças na ramificação main. Consulte o runbook IAC-R0004 para mais detalhes.

26.2.11. Sincronizar o horário com outros fusos

  1. Siga NTP P0007: configurar SyncServers multizona para sincronizar o horário desta zona com as outras.

26.2.12. Verificar se a API global está íntegra

Após a conclusão do processo de bootstrap da API global, faça verificações de integridade para confirmar que a API está íntegra:

  1. Consiga o nome da zona do servidor da API do cluster de administrador raiz:

    export ZONE_NAME=$(kubectl get controlplane -n mz-system cp -o jsonpath='{.spec.zone}')

  2. Verifique o carimbo de data/hora do último sinal de funcionamento da API global:

    kubectl get globalapizone -n mz-system ${ZONE_NAME} -o yaml

    O carimbo de data/hora do pulso é preenchido em status.lastHeartbeat. O carimbo de data/hora é atualizado a cada 30 segundos. Uma API global íntegra tem o último carimbo de data/hora de pulsação com no máximo 30 segundos.

26.2.13. Estender a data de validade da CA global do etcd

A autoridade certificadora (CA) do etcd global tem uma data de validade de 90 dias. O etcd global é um cluster etcd com instâncias implantadas em várias zonas do GDC. Não há automação para fazer a rotação da CA.

Essas instruções devem ser aplicadas às zonas atuais que já entraram no universo multizona. Depois que as zonas atuais forem atualizadas, a próxima zona que vai entrar nesse universo poderá pular esta seção.

26.2.13.1. Verificar a data de validade

Use a configuração do Kubernetes do administrador para o cluster de administrador raiz em qualquer zona. Confira a data de validade da CA:

export CA_NAME=$(kubectl get etcdca etcd -n global-kube-system -o jsonpath="{.spec.rootCA.name}")

kubectl get secret $CA_NAME -n global-kube-system -o jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -enddate -noout -in -

Se a data de expiração já estiver definida para cerca de um ano, nenhuma outra ação será necessária. Se for menor que um ano, consulte Fazer a rotação da CA com uma duração maior.

26.2.13.2. Alternar a CA com uma duração mais longa

Siga MZ-T0001 para alternar a CA. Verifique se a especificação do certificado da nova CA contém um valor de duration: 8760h.