26. Bootstrapping de várias zonas

Tempo estimado até à conclusão: 3 horas

Proprietário do componente operacional: MZ

Perfil de competências: engenheiro de implementação

26.1. Vista geral

A inicialização de várias zonas envolve a configuração do plano de controlo global de raiz. A primeira zona num universo estabelece o plano de controlo global. As zonas adicionais juntam-se ao plano de controlo global. A associação a um plano de controlo global é um processo mais complexo do que o estabelecimento do plano de controlo, porque é necessário estabelecer confiança entre o plano de controlo global do universo e a nova zona. Quando adere a um plano de controlo global, existem duas zonas envolvidas:

  • Zona de ancoragem: uma zona que já faz parte do plano de controlo global. Esta tem de ser a zona cuja instância do GitLab é usada para aplicar alterações de infraestrutura como código (IaC) à API global do universo.
  • Zona de associação: a zona que está a associar-se ao plano de controlo global.

Inicializou a primeira zona do universo em Inicializar várias zonas. Essa zona serve como zona de referência quando outras zonas se juntam ao universo.

Se já existir uma API global no universo e estiver a iniciar uma zona que está a juntar-se ao universo, conclua os seguintes passos.

26.2. Inicialização autónoma de várias zonas em zonas que se juntam a um universo

Confirme se arrancou o modo de várias zonas na zona principal antes de continuar.

26.2.1. Inicie o contentor da ferramenta de IO

Para segurança e capacidade de auditoria, o processo de arranque da multizona tem de ser realizado com credenciais pessoais para aceder ao Kubernetes (não a uma configuração do Kubernetes de administrador) e à IaC para aprovação de várias partes de pedidos de autorização para realizar ações confidenciais. Todas as ferramentas necessárias para realizar as ações de arranque estão incluídas no contentor da ferramenta de IO. Consulte o processo de configuração do contentor da ferramenta de IO OOPS-P0065 para saber como iniciar o contentor no ambiente da OIC. Uma zona que adere ao plano de controlo global envolve interações com duas zonas, uma das quais (a zona de ancoragem) não está a funcionar em condições de dia 0, pelo que têm de ser usadas medidas de autenticação e autorização ao nível da produção para garantir que a segurança da zona de ancoragem não é comprometida.

26.2.2. Inicialize o repositório do GitLab

Use credenciais do fornecedor de identidade (IdP) configurado na configuração de infraestrutura como código e siga o processo OOPS-P0066 para gerir o acesso de utilizadores 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.

Indique o nome de utilizador e a palavra-passe quando lhe for pedido.

26.2.3. Adicione as funções necessárias

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

  • Adicione uma associação de funções de cluster com a função de cluster mz-bootstrap-joining-editor no cluster root-admin da zona de junção.
  • Adicione uma associação de funções de cluster com a função de cluster mz-bootstrap-anchor-reader no cluster root-admin da zona de âncora.
  • Adicione uma associação de funções com a função mz-bootstrap-viewer no espaço de nomes mz-system na API global da zona de âncora.

26.2.4. Criar pedido de token

Quando junta um plano de controlo global, é estabelecido um contacto entre a zona de junção e a zona de âncora através de um token de arranque da API global. Um pedido de token é usado para pedir um token à API global na zona de âncora.

  1. Crie um novo ramo para um pedido de união:

    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 admissão de clientes conforme descrito na nota no final da secção.

  2. Inicie sessão na zona de participação. Consulte a interface de linhas de comando gcloud para ver detalhes. Isto é necessário porque o comando gdcloud no passo seguinte interage com o cluster de administrador raiz na zona de associação para obter um par de chaves de encriptação de chave pública para transferir em segurança o token de arranque da zona de âncora para a zona de associação.

  3. Gere o ficheiro YAML de pedido 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 ficheiro kustomization.yaml.

    1. Abra o ficheiro:

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

    2. Se o ficheiro já existir, 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. Guarde o ficheiro e saia do vim.

  5. Consolide as alterações no ramo:

    git add infrastructure
git commit

  6. Envie o ramo para o GitLab:

    git push

  7. Obter as alterações unidas no ramo main. Consulte o manual de procedimentos IAC-R0004 para ver detalhes.

26.2.5. Criar chave

Siga estes passos para criar o token de arranque na zona de associação:

  1. Crie um novo ramo para um pedido de união:

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

  2. Inicie sessão na zona de âncora. Consulte a interface de linhas de comando gcloud para ver detalhes. Isto é necessário porque o comando gdcloud no passo seguinte interage com a API global na zona de âncora para criar e encriptar um token de arranque.

  3. Gere o ficheiro 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 ficheiro kustomization.yaml.

    1. Abra o ficheiro:

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

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

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

    3. Guarde o ficheiro e saia do vim.

  5. Consolide as alterações no ramo:

    git add infrastructure
git commit

  6. Envie o ramo para o GitLab:

    git push

  7. Obter as alterações unidas no ramo main. Consulte o manual de procedimentos IAC-R0004 para ver detalhes.

26.2.6. Crie o recurso de arranque

Siga estes passos para criar o recurso de arranque no cluster de administrador raiz da zona de associação:

  1. Crie um novo ramo para um pedido de união:

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

  2. Inicie sessão na zona de âncora. Consulte a interface de linhas de comando gdcloud para obter detalhes. Isto é necessário porque, durante uma operação de associação, o comando gdcloud no passo seguinte interage com o cluster de administrador principal na zona de ancoragem para obter informações de conetividade para interagir com a API global na zona de ancoragem.

  3. Gere o ficheiro YAML de arranque:

    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 ficheiro kustomization.yaml:

    1. Abra o ficheiro:

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

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

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

    3. Guarde o ficheiro e saia do vim.

  5. Consolide as alterações no ramo:

    git add infrastructure
git commit

  6. Envie o ramo para o GitLab:

    git push

  7. Obter as alterações unidas no ramo main. Consulte o manual de procedimentos IAC-R0004 para ver detalhes.

Após a união das alterações, a IaC propaga o recurso Bootstrap para o cluster de administrador raiz da nova zona, onde é reconciliado. Esta é uma operação assíncrona, pelo que a API global não vai estar disponível imediatamente após a união.

26.2.7. Valide a implementação bem-sucedida da API global

Para validar a implementação da API global, siga estes passos:

  1. Inicie sessão na zona de participação. Consulte a interface de linhas de comando gcloud para ver detalhes.

  2. Obtenha uma configuração do Kubernetes para a API global de raiz (global-api). Consulte o manual de procedimentos IAM-R0004 para obter detalhes.

  3. Valide a conetividade com a API global na zona de associação:

    kubectl version

26.2.8. Limpe o par de chaves

Para eliminar o par de chaves usado para transferir o token de arranque da zona de âncora para a zona de associação, siga estes passos:

  1. Inicie sessão na zona de participação. Consulte a interface de linhas de comando gcloud para ver detalhes.

  2. Obtenha uma configuração do Kubernetes para o cluster de administrador raiz (root-admin). Consulte o manual de procedimentos IAM-R0004 para obter detalhes.

  3. Execute o seguinte comando para eliminar o par de chaves:

    kubectl delete keypair -n global-kube-system kp

26.2.9. Pedido de limpeza de tokens

Para eliminar o ficheiro YAML de pedido de token, siga estes passos:

  1. Crie um novo ramo para um pedido de união:

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

  2. Elimine o ficheiro YAML do pedido de token:

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

  3. Atualize o ficheiro kustomization.yaml.

    1. Abra o ficheiro:

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

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

  4. Consolide as alterações no ramo:

    git add infrastructure
git commit

  5. Envie o ramo para o GitLab:

    git push

  6. Obter as alterações unidas no ramo main. Consulte o manual de procedimentos IAC-R0004 para ver detalhes.

26.2.10. Limpe o token

Depois de a API global estar disponível na zona de junção, elimine o token, uma vez que já não é necessário:

  1. Crie um novo ramo para um pedido de união:

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

  2. Elimine o ficheiro YAML da chave:

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

  3. Atualize o ficheiro kustomization.yaml, se já existir.

    1. Abra o ficheiro:

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

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

  4. Consolide as alterações no ramo:

    git add infrastructure
git commit

  5. Envie o ramo para o GitLab:

    git push

  6. Obter as alterações unidas no ramo main. Consulte o manual de procedimentos IAC-R0004 para ver detalhes.

26.2.11. Sincronize a hora com outros fusos horários

  1. Siga o artigo NTP P0007 – Configure Multizone SyncServers para sincronizar a hora nesta zona com as outras zonas.

26.2.12. Valide se a API global está em bom estado

Após a conclusão do processo de arranque da API global, execute verificações de estado para confirmar que a API está em bom estado:

  1. Obtenha o nome da zona a partir do servidor da API do cluster de administrador principal:

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

  2. Verifique a data/hora do último heartbeat da API global:

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

    A indicação de tempo do batimento cardíaco é preenchida em status.lastHeartbeat. A data/hora é atualizada a cada 30 segundos. Uma API global em bom estado tem a data/hora do último sinal de vida com uma antiguidade máxima de 30 segundos.

26.2.13. Prolongue a data de validade da AC etcd global

A autoridade de certificação (AC) do etcd global tem uma data de validade de 90 dias. O etcd global é um cluster etcd com instâncias implementadas em várias zonas do GDC. Não existe automatização para rodar a AC.

Estas instruções devem ser aplicadas às zonas existentes que já aderiram ao universo multizona. Depois de as zonas existentes serem atualizadas, a zona seguinte que vai juntar-se a este universo pode ignorar esta secção.

26.2.13.1. Verifique a data de validade

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

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 validade já estiver definida para cerca de um ano, não é necessária mais nenhuma ação. Se for inferior a um ano, consulte o artigo Rode o CA com uma duração mais longa.

26.2.13.2. Rode o CA com uma duração mais longa

Siga as instruções em MZ-T0001 para rodar o CA. Certifique-se de que a especificação do certificado da nova AC contém um valor de duration: 8760h.