Neste tutorial, apresentamos uma solução pronta para uso que usa o Google Distributed Cloud (somente software) em bare metal e o Config Sync para implantar clusters do Kubernetes na borda em escala. Este tutorial é para operadores e desenvolvedores de plataformas. Antes de ler este documento, confira se você conhece as seguintes tecnologias e conceitos:
- Manuais do Ansible.
- Implantações de borda e seus desafios.
- Como trabalhar com um projeto do Google Cloud.
- Como implantar um aplicativo da Web em contêiner.
- Interfaces de linha de comando
gcloud
ekubectl
.
Neste tutorial, você usará máquinas virtuais (VMs) do Compute Engine para emular os nós implantados na borda e um aplicativo de ponto de venda de amostra como a carga de trabalho de borda. O software do Google Distributed Cloud e o Config Sync oferecem gerenciamento e controle centralizados para o cluster de borda. O Config Sync extrai novas configurações do GitHub de forma dinâmica e aplica essas políticas e configurações aos clusters.
Arquitetura de implantação na borda
Uma implantação de borda de varejo é uma boa maneira de ilustrar a arquitetura usada em uma implantação típica de cluster bare metal.
Uma loja física é o ponto de interação mais próximo entre uma unidade empresarial e o consumidor. Os sistemas de software das lojas precisam executar cargas de trabalho, receber atualizações oportunas e relatar métricas essenciais de isolamento do sistema de gerenciamento central da empresa. Além disso, esses sistemas de software precisam ser projetados para que possam ser expandidos para outros locais da loja no futuro. Embora qualquer implantação de cluster bare metal atenda a todos esses requisitos para sistemas de software de loja, o perfil de borda permite um caso de uso importante: implantações em ambientes com recursos de hardware limitados, como uma vitrine de loja de varejo.
O diagrama a seguir mostra uma implantação de cluster bare metal que usa o perfil de borda em uma loja de varejo:
O diagrama anterior mostra uma loja física típica de varejo. A loja tem dispositivos
inteligentes como leitores de cartão, máquinas de ponto de venda, câmeras e impressoras. A
loja também tem três dispositivos de hardware de computação física (com os rótulos Node 1
,
Node 2
e Node 3
). Todos esses dispositivos estão conectados a um interruptor de rede
central. Assim, os três dispositivos de computação estão conectados entre si por meio de uma
rede da camada 2. Os dispositivos de computação conectados em rede formam a infraestrutura
bare metal. O software do Google Distributed Cloud está sendo executado em cada um dos
três dispositivos de computação. Esses dispositivos também têm armazenamento próprio em disco e são
configurados para replicação de dados entre eles para alta disponibilidade.
O diagrama também mostra os seguintes componentes principais que fazem parte de uma implantação de cluster bare metal:
O componente marcado como MetalLB é o balanceador de carga em pacote.
O componente Config Sync permite sincronizar o estado do cluster com os repositórios de origem. É um complemento opcional altamente recomendado que requer instalação e configuração separadas. Para mais informações sobre como configurar o Config Sync e a nomenclatura diferente, consulte a documentação do Config Sync.
O repositório raiz e o repositório de namespace mostrados na parte superior do diagrama fora do local da loja representam dois repositórios de origem.
As alterações no cluster são enviadas para esses repositórios de origem central. As implantações de cluster em vários locais de borda extraem atualizações dos repositórios de origem. Esse comportamento é representado pelas setas que conectam os dois repositórios no diagrama aos componentes do Config Sync dentro do cluster em execução nos dispositivos.
Outro componente importante representado como parte do cluster é o ambiente de execução de VM no GDC. O ambiente de execução de VM no GDC permite executar cargas de trabalho atuais baseadas em VM no cluster sem a necessidade de conteinerização. A documentação do ambiente de execução de VMs no GDC explica como ativar e implantar as cargas de trabalho da VM no cluster.
O componente marcado como Aplicativo indica um software implantado no cluster pela loja de varejo. O aplicativo de ponto de venda visto nos quiosques de uma loja pode ser um exemplo desse tipo de aplicativo.
As caixas na parte inferior do diagrama representam os vários dispositivos (como quiosques, tablets ou câmeras) dentro de uma loja de varejo e todos estão conectados a um chave de rede central. A rede local dentro da loja permite que os aplicativos em execução no cluster alcancem esses dispositivos.
Na próxima seção, você vai conferir a emulação dessa implantação de loja de varejo no Google Cloud usando VMs do Compute Engine. Essa emulação é a usada no tutorial a seguir para testar um cluster bare metal.
Implantação de borda emulada em Google Cloud
O diagrama a seguir é uma representação de tudo que você configurou no Google Cloud neste tutorial. Esse diagrama se relaciona com o diagrama da loja de varejo da seção anterior. Essa implantação representa um local de borda emulado em que o aplicativo de ponto de venda está implantado. A arquitetura também mostra um exemplo de carga de trabalho de aplicativo de ponto de venda que você usa neste tutorial. Você acessa o aplicativo do ponto de venda dentro do cluster usando um navegador da Web como um quiosque.
As três máquinas virtuais (VMs) do Compute Engine no diagrama anterior representam o hardware ou os nós físicos em um local de borda típico. Esse hardware seria conectado a interruptores de rede para compor a infraestrutura bare metal. No nosso ambiente emulado em Google Cloud, essas VMs são conectadas entre si pela rede padrão de nuvem privada virtual (VPC) no projeto do Google Cloud.
Em uma instalação típica de cluster bare metal, é possível configurar seus próprios balanceadores de carga. No entanto, neste tutorial, você não vai configurar um balanceador de carga externo. Em vez disso, use o balanceador de carga MetalLB em pacote. O balanceador de carga MetalLB empacotado exige conectividade de rede de camada 2 entre os nós. Portanto, a conectividade da camada 2 entre as VMs do Compute Engine é ativada criando uma rede de sobreposição VxLAN sobre a rede padrão de nuvem privada virtual (VPC).
No retângulo denominado "Rede L2 overlay (VxLAN)", os componentes do software em execução dentro das três VMs do Compute Engine são mostrados. Esse retângulo da VxLAN inclui o deployment do cluster, que contém um namespace do Kubernetes dentro do cluster. Todos os componentes dentro desse namespace do Kubernetes formam o aplicativo de ponto de venda implantado no cluster. O aplicativo de ponto de venda tem três microsserviços: servidor de API, inventário e pagamentos. Todos esses componentes representam um "application" mostrado no diagrama da arquitetura de lançamento anterior do Edge.
O balanceador de carga MetalLB agrupado do cluster não pode ser acessado diretamente de fora das VMs. O diagrama mostra um proxy reverso do NGINX sendo configurado para ser executado dentro das VMs, com o objetivo de encaminhar o tráfego que chega às VMs do Compute Engine para o balanceador de carga. Essa é apenas uma solução alternativa para os fins deste tutorial em que os nós de borda são emulados usando Google Cloud VMs do Compute Engine. Em um local de borda real, isso pode ser feito com a configuração adequada de rede.
Objetivos
- Use as VMs do Compute Engine para emular uma infraestrutura bare metal executada em um local de borda.
- Use o Google Distributed Cloud para criar um cluster na infraestrutura de borda emulada.
- Conecte e registre o cluster com Google Cloud.
- Implante uma carga de trabalho de aplicativo de ponto de venda de amostra no cluster.
- Use o console do Google Cloud para verificar e monitorar o aplicativo de ponto de venda que opera no local de borda.
- Use o Config Sync para atualizar o aplicativo de ponto de venda que é executado no cluster.
Antes de começar
No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.
Verifique se o faturamento está ativado para seu projeto do Cloud. Saiba como verificar se o faturamento está ativado em um projeto.
Instale e inicialize a CLI do Google Cloud.
Copie e clone o repositório anthos-samples
Todos os scripts usados neste tutorial são armazenados no repositório anthos-samples. A estrutura de pastas em
/anthos-bm-edge-deployment/acm-config-sink
é organizada de acordo com o que é esperado pelo Config Sync.
Clone esse repositório na sua própria conta do GitHub antes de continuar com as etapas a seguir.
Caso ainda não tenha um, crie uma conta no GitHub.
Crie um token de acesso pessoal para usar na configuração do Config Sync. Isso é necessário para que os componentes da sincronização de configuração no cluster sejam autenticados com sua conta do GitHub ao tentar sincronizar novas alterações.
- Selecione somente o escopo
public_repo
. - Salve o token de acesso criado em um local seguro para uso posterior.
- Selecione somente o escopo
Copie o repositório
anthos-samples
para sua própria conta do GitHub:- Acesse o repositório anthos-samples.
- Clique no ícone Bifurcar no canto superior direito da página.
- Clique na conta de usuário do GitHub para a qual você quer bifurcar o repositório. Você
será redirecionado automaticamente para a página com a versão bifurcada do
repositório
anthos-samples
.
Abra um terminal no ambiente local.
Clone o repositório bifurcado executando o seguinte comando, em que GITHUB_USERNAME é o nome de usuário da sua conta do GitHub:
git clone https://github.com/GITHUB_USERNAME/anthos-samples cd anthos-samples/anthos-bm-edge-deployment
Configurar o ambiente da estação de trabalho
Para concluir a implantação de borda descrita neste documento, você precisa de uma estação de trabalho com acesso à Internet e às seguintes ferramentas instaladas:
- Docker
- Ferramenta de interface de linha de comando envsubst (geralmente pré-instalada no Linux e em outros sistemas operacionais semelhantes ao Unix)
Execute todos os comandos do tutorial na estação de trabalho configurada nesta seção.
Na estação de trabalho, inicialize as variáveis de ambiente em uma nova instância do shell:
export PROJECT_ID="PROJECT_ID" export REGION="us-central1" export ZONE="us-central1-a" # port on the admin Compute Engine instance you use to set up an nginx proxy # this allows to reach the workloads inside the cluster via the VM IP export PROXY_PORT="8082" # should be a multiple of 3 since N/3 clusters are created with each having 3 nodes export GCE_COUNT="3" # url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples" # this is the username used to authenticate to your fork of this repository export SCM_TOKEN_USER="GITHUB_USERNAME" # access token created in the earlier step export SCM_TOKEN_TOKEN="ACCESS_TOKEN"
Substitua os seguintes valores:
- PROJECT_ID: é seu ID do projeto no Google Cloud.
- GITHUB_USERNAME: seu nome de usuário do GitHub.
- ACCESS_TOKEN: o token de acesso pessoal que você criou para o repositório do GitHub.
Mantenha os valores padrão das outras variáveis de ambiente. Eles são explicados nas seções a seguir.
Na estação de trabalho, inicialize a Google Cloud CLI:
gcloud config set project "${PROJECT_ID}" gcloud services enable compute.googleapis.com gcloud config set compute/region "${REGION}" gcloud config set compute/zone "${ZONE}"
Na estação de trabalho, crie a conta de serviço Google Cloud para as instâncias do Compute Engine. Esse script cria o arquivo de chave JSON para a nova conta de serviço em
<REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json
. Ele também configura o keyring e a chave do Cloud Key Management Service para a criptografia de chaves privadas SSH../scripts/create-primary-gsa.sh
O exemplo a seguir é apenas uma parte do script. Para conferir o script inteiro, clique em Ver no GitHub.
Provisionar as instâncias do Compute Engine
Nesta seção, você cria as VMs do Compute Engine em que o Google Distributed Cloud somente de software será instalado. Você também verifica a conectividade com essas VMs antes de prosseguir para a seção de instalação.
Na estação de trabalho, crie chaves SSH usadas para comunicação entre as instâncias do Compute Engine:
ssh-keygen -f ./build-artifacts/consumer-edge-machine
Criptografe a chave privada SSH usando o Cloud Key Management Service:
gcloud kms encrypt \ --key gdc-ssh-key \ --keyring gdc-ce-keyring \ --location global \ --plaintext-file build-artifacts/consumer-edge-machine \ --ciphertext-file build-artifacts/consumer-edge-machine.encrypted
Gere o arquivo de configuração do ambiente
.envrc
e use o comando source. Depois de criado, confira no arquivo.envrc
se as variáveis de ambiente foram substituídas pelos valores corretos.envsubst < templates/envrc-template.sh > .envrc source .envrc
Veja a seguir um exemplo de arquivo
.envrc
gerado pela substituição das variáveis de ambiente no arquivotemplates/envrc-template.sh
. As linhas atualizadas foram destacadas:Crie instâncias do Compute Engine:
./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \ tee ./build-artifacts/gce-info
Instalar um cluster bare metal com o Ansible
O script usado neste guia cria clusters em grupos de três
instâncias do Compute Engine. O número de clusters criados é controlado pela
variável de ambiente GCE_COUNT
. Por exemplo, você define a variável de ambiente
GCE_COUNT
como 6
para criar dois clusters com 3
instâncias de VM cada.
Por padrão, a variável de ambiente GCE_COUNT
é definida como 3
. Portanto, neste
guia, será criado um cluster com 3
instâncias do Compute Engine. As instâncias são nomeadas com um prefixo cnuc-
seguido por um número. A primeira instância de VM de cada cluster funciona como a estação de trabalho do administrador a partir da qual a instalação é acionada. O cluster também recebe o mesmo nome da VM da estação de trabalho
do administrador (por exemplo, cnuc-1
, cnuc-4
, cnuc-7
).
O playbook do Ansible faz o seguinte:
- Configura as instâncias do Compute Engine com as ferramentas necessárias, como
docker
,bmctl
,gcloud
enomos
. - Instala um cluster bare metal nas instâncias configuradas do Compute Engine.
- Cria um cluster autônomo chamado
cnuc-1
. - Registra o cluster
cnuc-1
com Google Cloud. - Instala o Config Sync no cluster
cnuc-1
. - Configura o Config Sync para sincronizar com as configurações de cluster localizadas
em
anthos-bm-edge-deployment/acm-config-sink
no repositório bifurcado. - Gere o
Login token
do cluster.
Siga estas etapas para configurar e iniciar o processo de instalação:
Na estação de trabalho, crie a imagem do Docker usada na instalação. Essa imagem tem todas as ferramentas necessárias para o processo de instalação, como Ansible, Python e Google Cloud CLI.
gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/
Se executado com êxito, o build produz uma saída como esta:
... latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498 DONE ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 2238baa2-1f41-440e-a157-c65900b7666b 2022-08-17T19:28:57+00:00 6M53S gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz gcr.io/my_project/consumer-edge-install (+1 more) SUCCESS
Gere o arquivo de inventário do Ansible no modelo:
envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml
Execute o script de instalação que inicia um contêiner do Docker a partir da imagem criada anteriormente. O script usa internamente o Docker para gerar o contêiner com uma montagem de volume para o diretório de trabalho atual. Após a conclusão desse script, você precisa estar dentro do contêiner do Docker que foi criado. Acione a instalação do Ansible de dentro desse contêiner.
./install.sh
Se executado com sucesso, o script produz uma saída como esta:
... Check the values above and if correct, do you want to proceed? (y/N): y Starting the installation Pulling docker install image... ============================== Starting the docker container. You will need to run the following 2 commands (cut-copy-paste) ============================== 1: ./scripts/health-check.sh 2: ansible-playbook all-full-install.yaml -i inventory 3: Type 'exit' to exit the Docker shell after installation ============================== Thank you for using the quick helper script! (you are now inside the Docker shell)
No contêiner do Docker, verifique o acesso às instâncias do Compute Engine:
./scripts/health-check.sh
Se executado com sucesso, o script produz uma saída como esta:
... cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
No contêiner do Docker, execute o playbook do Ansible para instalar um cluster bare metal em instâncias do Compute Engine:
Após a conclusão, você vai ver o
Login Token
do cluster impresso na tela.ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log
Se executada corretamente, a instalação vai produzir uma saída como esta:
... TASK [abm-login-token : Display login token] ************************************************************************** ok: [cnuc-1] => { "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd 4CwanGlof6s-fbu8" } skipping: [cnuc-2] skipping: [cnuc-3] PLAY RECAP *********************************************************************************************************** cnuc-1 : ok=205 changed=156 unreachable=0 failed=0 skipped=48 rescued=0 ignored=12 cnuc-2 : ok=128 changed=99 unreachable=0 failed=0 skipped=108 rescued=0 ignored=2 cnuc-3 : ok=128 changed=99 unreachable=0 failed=0 skipped=108 rescued=0 ignored=2
Fazer login no cluster no console do Google Cloud
Depois que o playbook Ansible for concluído, um cluster independente será instalado nas VMs do Compute Engine. Esse cluster também é registrado em Google Cloud, usando o agente do Connect. No entanto, para conferir detalhes sobre esse cluster, faça login nele pelo console do Google Cloud.
Para fazer login no cluster, siga estas etapas:
Copie o token da saída do manual do Ansible na seção anterior.
No console do Google Cloud, acesse a página Clusters do Kubernetes e use o token copiado para fazer login no cluster
cnuc-1
.Acessar a página de clusters do Kubernetes
- Na lista de clusters, clique em
cnuc-1
e, em seguida, clique em Fazer login.
Ações
ao lado do cluster - Selecione Token e cole o token copiado.
- Clique em Login.
- Na lista de clusters, clique em
- No console do Google Cloud, acesse a página Configuração na seção Recursos.
Na guia Pacotes, verifique a coluna Status da sincronização na tabela de clusters.
Verifique se o status é Sincronizado. Um status de Sincronizado indica que o
Config Sync
sincronizou suas configurações do GitHub com o cluster implantado, cnuc-1
.
Configurar um proxy para tráfego externo
O cluster instalado nas etapas anteriores usa um balanceador de carga em pacote chamado
MetalLB. Esse serviço do balanceador de carga só pode ser
acessado por um endereço IP de nuvem privada virtual (VPC). Para rotear
o tráfego que chega pelo IP externo para o balanceador de carga em pacote, configure um
serviço de proxy reverso no host de administrador (cnuc-1
). Esse serviço de proxy reverso
permite acessar o servidor da API do aplicativo de ponto de venda pelo
IP externo do host de administrador (cnuc-1
).
Os scripts de instalação nas etapas anteriores instalaram o NGINX nos hosts de administrador com um arquivo de configuração de amostra. Atualizamos esse arquivo para usar o endereço IP do serviço do balanceador de carga e reiniciamos o NGINX.
Na estação de trabalho, use o SSH para fazer login na estação de trabalho de administrador:
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1
Na estação de trabalho do administrador, configure o proxy reverso do NGINX para encaminhar o tráfego para o serviço do balanceador de carga do servidor de API. Consiga o endereço IP do serviço do tipo balanceador de carga do Kubernetes:
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
Atualize o arquivo de configuração do modelo com o endereço IP buscado:
sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \ /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"
Reinicie o NGINX para garantir que a nova configuração seja aplicada:
sudo systemctl restart nginx
Confira o status do servidor NGINX para informar "ativo (em execução)":
sudo systemctl status nginx
Quando o NGINX está em execução, ele produz uma saída como o exemplo a seguir:
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago Docs: man:nginx(8) Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 92573 (nginx) Tasks: 17 (limit: 72331) Memory: 13.2M CGroup: /system.slice/nginx.service ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; ├─92574 nginx: worker process ├─92575 nginx: worker process ├─92577 nginx: .... ... ...
Saia da sessão SSH para a instância de administrador.
exit
Saia da sessão do shell para o contêiner do Docker. Ao sair da instância de administrador, você ainda está dentro do contêiner do Docker usado para a instalação:
exit
Acessar o aplicativo de ponto de venda
Com a configuração do proxy externo, é possível acessar o aplicativo em execução no cluster. Para acessar o aplicativo de ponto de venda de amostra, siga as etapas abaixo.
Na estação de trabalho, acesse o endereço IP externo da instância do Compute Engine para administrador e acesse a IU do aplicativo do ponto de venda:
EXTERNAL_IP=$(gcloud compute instances list \ --project ${PROJECT_ID} \ --filter="name:cnuc-1" \ --format="get(networkInterfaces[0].accessConfigs[0].natIP)") echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"
Quando os scripts são executados com sucesso, eles produzem uma saída como esta:
Point the browser to: 34.134.194.84:8082
Abra o navegador da Web e navegue até o endereço IP mostrado na saída do comando anterior. É possível acessar e testar o aplicativo de ponto de venda de amostra, conforme mostrado na captura de tela de exemplo a seguir:
Usar o Config Sync para atualizar o servidor da API
Para atualizar o aplicativo de amostra para uma versão mais recente, atualize os
arquivos de configuração no repositório raiz. O Config Sync detecta
as atualizações e faz as alterações automaticamente no cluster. Neste exemplo,
o repositório raiz é o anthos-samples
que você clonou no
início deste guia. Para ver como o aplicativo de ponto de venda de amostra pode
passar por uma implantação de upgrade para uma versão mais recente, conclua as etapas a seguir.
Na estação de trabalho, atualize o campo
image
para alterar a versão do servidor de API dev1
parav2
. A configuração YAML da implantação está no arquivo emanthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml
.Adicione, confirme e envie as alterações para seu repositório bifurcado:
git add acm-config-sink/namespaces/pos/api-server.yaml git commit -m "chore: updated api-server version to v2" git push
No console do Google Cloud, acesse a página Config Sync para verificar o Status da especificação de configuração. Verifique se o status é Sincronizado.
No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes Engine para verificar se a implantação está atualizada.
Quando o status da Implantação for OK, aponte o navegador para o endereço IP da seção anterior a fim de visualizar o aplicativo de ponto de venda. A versão no título mostra "V2", indicando que a mudança do aplicativo foi implantada, conforme mostrado no exemplo de captura de tela a seguir:
Talvez seja necessário fazer uma atualização forçada da guia do navegador para ver as alterações.
Limpar
Para evitar cobranças Google Cloud desnecessárias, exclua os recursos usados neste guia quando terminar. É possível excluir esses recursos manualmente ou excluir o projeto do Google Cloud, o que também elimina todos os recursos. Além disso, convém limpar as alterações feitas na estação de trabalho local:
Estação de trabalho local
Os arquivos a seguir precisam ser atualizados para limpar as alterações feitas pelos
scripts de instalação.
- Remova os endereços IP da VM do Compute Engine adicionados ao arquivo
/etc/hosts
. - Remova a configuração SSH de
cnuc-*
no arquivo~/.ssh/config
. - Remova as impressões digitais da VM do Compute Engine do arquivo
~/.ssh/known_hosts
.
Excluir projeto
Se você criou um projeto dedicado para este procedimento, exclua o projeto do Google Cloud
pelo console do Google Cloud.
Manual
Se você usou um projeto atual para este procedimento, faça o seguinte:
- Cancele o registro de todos os clusters do Kubernetes cujos nomes tenham o prefixo
cnuc-
. - Exclua todas as VMs do Compute Engine cujos nomes tenham o prefixo
cnuc-
. - Exclua o bucket do Cloud Storage cujo nome tenha o prefixo
abm-edge-boot
. - Exclua as regras de firewall
allow-pod-ingress
eallow-pod-egress
. - Exclua o secret do Secret Manager.
install-pub-key
A seguir
É possível expandir ainda mais este guia adicionando outro local de borda. Definir a
variável de ambiente GCE_COUNT
como 6
e executar novamente as mesmas etapas das
seções anteriores cria três novas instâncias do Compute Engine
(cnuc-4
, cnuc-5
, cnuc-6
) e um novo cluster independente chamado cnuc-4
.
Também é possível atualizar as configurações de cluster
no repositório bifurcado para aplicar seletivamente versões diferentes do
aplicativo de ponto de venda aos dois clusters, cnuc-1
e cnuc-4
, usando
ClusterSelectors.
Para mais detalhes sobre as etapas individuais deste guia e os scripts envolvidos, consulte o repositório anthos-samples.