Como usar o conjunto de ferramentas do GKE Enterprise com o Active Assist

---

Este documento faz parte de uma série sobre os padrões de arquitetura que as empresas podem usar para otimizar o alcance da nuvem em escala usando o Active Assist. Neste tutorial, mostramos como criar um pipeline de automação para recomendações do Active Assist que funciona com o conjunto de ferramentas do GKE Enterprise. Ele é destinado a pessoas que usam o Config Management para gerenciar os ambientes do GKE Enterprise e o Config Connector para gerenciar os recursos do Google Cloud. As outras partes da série são as seguintes:

• Padrões para usar o Active Assist em grande escala
• Como usar pipelines sem servidor com o Active Assist
• Como usar o conjunto de ferramentas do GKE Enterprise com o Active Assist (este documento)

O pipeline de automação criado neste tutorial pode ajudar você a conseguir o seguinte:

• Como escalonar o uso do portfólio do Active Assist na sua organização.
• Transformar o Active Assist em parte de um pipeline de integração e entrega contínuas (CI/CD).
• Controlar a análise e a atuação das recomendações do Active Assist usando criações como problemas do GitHub e solicitações de envio.

Neste tutorial, também usamos o kpt, um kit de ferramentas de código aberto desenvolvido pelo Google para ajudar a gerenciar, manipular, personalizar e aplicar arquivos de dados de configuração de recursos do Kubernetes.

Arquitetura

O diagrama de arquitetura a seguir mostra os componentes que serão usados neste tutorial.

Os componentes são usados das seguintes maneiras:

• Um repositório do GitHub não se repete (DRY, na sigla em inglês), e é usado para modelos do Config Connector que você implanta em projetos da organização do Google Cloud.
• Um ou mais repositórios do GitHub específicos para um projeto ou ambiente e que têm arquivos de configuração hidratados. Esses repositórios hidratados são destinados aos ambientes que são gerenciados pelo Config Sync. Eles usam o Config Connector para ativar e gerenciar os recursos do Google Cloud na organização.
• Um cluster do GKE que usa o Config Sync para controle de versões e detecção de desvio. Esse cluster também tem o Config Connector instalado. O Config Connector permite que o cluster gerencie os recursos do Google Cloud na organização.
• Um gatilho do Cloud Build que aciona uma versão quando um modelo é enviado por push para o repositório DRY do GitHub.
• Um gatilho programado do Cloud Build que aciona um build periodicamente; O job de compilação usa uma função kpt. A função invoca as APIs do Active Assist Recommender para buscar recomendações ativas. Ele revisa e analisa recomendações para determinar se os recursos do Google Cloud que o Config Connector gerencia precisam ser redimensionados ou otimizados. A função kpt cria um problema do GitHub no repositório DRY com os detalhes da alteração recomendada se os recursos do Google Cloud gerenciados pelo Config Connector precisarem ser redimensionados ou otimizados.

O fluxo de trabalho dessa arquitetura é o seguinte:

1. As equipes autorizadas com acesso ao repositório DRY criam e gerenciam modelos do Config Connector no repositório.
2. Um job do Cloud Build é acionado quando um modelo é criado ou modificado e verificado na ramificação main.
3. O job do Cloud Build hidrata os modelos invocando os setters kpt. O job envia os arquivos de configuração hidratados para o repositório hidratado do GitHub. O Secret Manager é usado para armazenar chaves de implantação do GitHub para o repositório particular.
4. O Config Sync monitora alterações no repositório hidratado e aplica atualizações encontradas no repositório ao cluster gerenciado.
5. O Config Connector monitora alterações e ativa recursos do Google Cloud se algum recurso precisar ser criado ou atualizado como resultado das alterações do Kubernetes Resource Model (KRM) aplicadas pelo Config Sync.
6. Um gatilho programado do Cloud Build é executado periodicamente para invocar a API Recommender para buscar recomendações ativas para os projetos que o Config Connector gerenciou.
7. O job programado do Cloud Build executa uma função kpt personalizada para invocar a API Recommender e buscar e analisar recomendações ativas.
8. A função kpt cria um problema no GitHub que mostra uma comparação da configuração atual do recurso e da configuração recomendada para o recurso. Com essa abordagem, os problemas do GitHub são criados no repositório DRY, o que facilita o acompanhamento das alterações no repositório.

Objetivos

• Crie os seguintes repositórios de amostra do GitHub:
  • Um repositório DRY para o Config Connector KRMs.
  • Um repositório para armazenar arquivos de configuração hidratados gerados com setters kpt.
• Criar um cluster do GKE com o Config Sync e o Config Connector.
• Crie uma função kpt de amostra para recuperar recomendações do Active Assist para projetos gerenciados pelo Config Connector.
• Crie um gatilho do Cloud Build que será acionado quando um modelo for enviado para a ramificação main do repositório DRY.
• Criar um job programado do Cloud Build que seja executado periodicamente para recuperar recomendações do Active Assist disponíveis para os recursos gerenciados pelo Config Connector.
• Teste o pipeline completo com as recomendações de stub fornecidas no repositório do GitHub para este tutorial.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• Cloud Build
• Cloud Run
• Firestore
• Pub/Sub
• Container Registry
• Cloud Scheduler
• Google Kubernetes Engine (GKE) Enterprise Edition

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

1. No console do Google Cloud, acesse a página do seletor de projetos.

   Acessar o seletor de projetos

2. Selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.
3. Anote o ID do projeto do Google Cloud. Você usará esse ID na próxima seção ao configurar o ambiente. Este projeto é chamado em todo o tutorial como o projeto build.

4. Ative as APIs Cloud Build, Firestore, App Engine, Pub/Sub, Cloud Run, Cloud Scheduler e Cloud Source Repositories.

   Ative as APIs

   Você usará as credenciais padrão do aplicativo para este tutorial. Se for solicitado que você crie credenciais na página Adicionar credenciais ao seu projeto, clique em Cancelar.

5. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Como configurar o ambiente

Neste tutorial, todos os comandos serão executados no Cloud Shell.

1. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

2. Defina variáveis para o ID e o número do projeto build atual do Google Cloud:

   export RECO_MGR_PROJECT=PROJECT_ID
   gcloud config set project $RECO_MGR_PROJECT
   export RECO_MGR_PROJECT_NUMBER=$(gcloud projects describe $RECO_MGR_PROJECT --format='value(projectNumber)')
   

   Substitua PROJECT_ID pelo ID do projeto que você anotou na seção anterior.

3. Defina as variáveis da região de implantação:

   export REGION=us-central1
   export ZONE=us-central1-a
   

4. Clone o repositório que contém o código do aplicativo de amostra usado neste tutorial:

   git clone https://github.com/GoogleCloudPlatform/activeassist-anthos-toolchain.git
   

5. Acesse o diretório do projeto:

   cd activeassist-anthos-toolchain
   

Criar o pipeline

Nesta seção, você cria os componentes para criar o pipeline. As recomendações do Active Assist são geradas com base em padrões de uso e métricas do sistema. Cada categoria de recomendação pode usar uma janela de tempo padrão diferente para analisar os dados de uso e as métricas com base nas recomendações geradas. Para testar o pipeline completo, o repositório clonado em uma etapa anterior fornece recomendações de exemplo (stubs) que você usa para executar o pipeline completo.

Como alternativa, se você estiver executando o pipeline em um projeto de amostra que tenha recursos e recomendações atuais, faça as alterações apropriadas no código de amostra e execute o pipeline.

Configurar amostras de repositórios particulares do GitHub

Nas seções a seguir, você irá configurar os repositórios do GitHub de amostra para este tutorial.

Configurar um repositório privado do GitHub do DRY

1. Crie um repositório particular do GitHub para o repositório DRY. Anote o nome do repositório.

2. No Cloud Shell, crie uma variável de ambiente para o nome de usuário do GitHub e o nome do repositório DRY:

   export REPO_OWNER=YOUR_GITHUB_USERNAME
   export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
   

   Substitua:

   • YOUR_GITHUB_USERNAME: seu nome de usuário do GitHub.
   • YOUR_PRIVATE_DRY_REPO: o nome do repositório DRY.

3. Crie um token de acesso pessoal (PAT, na sigla em inglês) para gerar problemas neste repositório. O pipeline cria problemas do GitHub se há recomendações do Active Assist que precisam ser revisadas. Para mais informações sobre como criar PATs no GitHub, consulte a documentação do GitHub.

   Ao definir um escopo para esse token, selecione Controle total de repositórios particulares.

4. No Cloud Shell, crie uma variável de ambiente para o PAT que você gerou:

   export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
   

   Substitua YOUR_PERSONAL_ACCESS_TOKEN pelo seu próprio token.

Configurar um repositório particular hidratado do GitHub

1. Crie um repositório particular do GitHub para o repositório hidratado. Anote o nome do repositório.

2. No Cloud Shell, defina uma variável de ambiente para o repositório hidratado:

   export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO
   export HYDRATED_REPO='[e-mail]:$REPO_OWNER/$HYDRATED_REPO_NAME.git'
   

   Substitua YOUR_PRIVATE_HYDRATED_REPO pelo nome do seu repositório hidratado.

3. Crie um par de chaves de implantação:

   ssh-keygen -t rsa -b 4096 \
   -C 'active-assist-robot' \
   -N '' \
   -f $(pwd)/active-assist-robot
   

   Uma chave de implantação permite implantar no repositório particular do GitHub ao executar um job do Cloud Build para hidratar arquivos de configuração.

4. Imprima a chave gerada:

   cat $(pwd)/active-assist-robot.pub
   

5. Adicione a chave de implantação ao repositório particular do GitHub. Selecione Permitir acesso de gravação ao adicionar a chave de implantação. Para saber como adicionar chaves de implantação a repositórios do GitHub, consulte a documentação do GitHub sobre Como gerenciar chaves de implantação.

Faça upload das chaves do GitHub para o Secret Manager

1. No Cloud Shell, crie um secret para armazenar a chave privada do par de chaves de implantação:

   gcloud secrets create github-ssh-key \
     --data-file=$(pwd)/active-assist-robot
   

2. Crie um secret para armazenar o PAT:

   echo $GITHUB_TOKEN | gcloud secrets create github-pat --data-file=-
   

Criar um cluster do GKE

Nesta seção, você cria um cluster do GKE com o complemento do Config Connector, cria uma identidade e configura o Config Connector. Você também configura o Config Sync. É possível usar o Config Sync para criar uma configuração comum em toda a infraestrutura, incluindo políticas personalizadas, e aplicá-la no local e na nuvem. O Config Sync avalia alterações e as distribui para todos os clusters do Kubernetes, sempre refletindo o estado esperado nos clusters.

1. No Cloud Shell, crie um novo cluster do GKE com o complemento Config Connector ativado:

   gcloud container clusters create sample-ops \
     --machine-type n1-standard-4 \
     --zone $ZONE \
     --release-channel regular \
     --addons ConfigConnector \
     --workload-pool=$RECO_MGR_PROJECT.svc.id.goog \
     --enable-stackdriver-kubernetes \
     --enable-ip-alias
   

2. Conclua as seções a seguir no guia Como instalar com o complemento GKE para criar uma identidade e configurar o Config Connector.

   1. Como criar uma identidade
   2. Como configurar o Config Connector

3. Instale o Config Sync no cluster do GKE que você criou. Ao configurar o Config Sync, faça o seguinte:

   1. Use um token para conceder acesso somente leitura ao Config Sync ao Git. Use o token do GitHub que você Criou quando você configura um repositório privado do DRY no GitHub. O token está disponível por meio da variável de ambiente $GITHUB_TOKEN.
   2. Configurar o Config Sync usando gcloud. Defina as seguintes configurações:
      1. sourceFormat: hierarchy
      2. syncRepo: https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
      3. syncBranch: main
      4. secretType: token
      5. policyDir: não preencha essa opção

Crie um gatilho do Cloud Build para enviar ao repositório hidratado

Nas seções a seguir, você vai criar um gatilho do Cloud Build que será acionado quando os modelos forem enviados para a ramificação principal do seu repositório YOUR_PRIVATE_DRY_REPO. Este gatilho executa as etapas que hidratam os modelos de KRM de configuração como dados no repositório YOUR_PRIVATE_DRY_REPO e envia os arquivos de configuração hidratados para seu repositório YOUR_PRIVATE_HYDRATED_REPO.

Conectar o Cloud Build aos repositórios GitHub.

Nesta seção, você conecta os repositórios YOUR_PRIVATE_DRY_REPO e YOUR_PRIVATE_HYDRATED_REPO do GitHub ao Cloud Build.

1. Acesse a página do Marketplace do GitHub para o aplicativo Cloud Build:

   Acessar a página do aplicativo Cloud Build

2. Clique em Configurar com o Google Cloud Build.

3. Se solicitado, faça login no GitHub.

4. Selecione Somente repositórios selecionados.

   Use a lista suspensa Selecionar repositórios para ativar o acesso aos repositórios YOUR_PRIVATE_DRY_REPO e YOUR_PRIVATE_HYDRATED_REPO por meio do aplicativo Cloud Build.

5. Clique em Install.

6. Faça login no Google Cloud. A página Autorização é exibida e você precisa autorizar o aplicativo Google Cloud Build para se conectar ao Google Cloud.

7. Clique em Authorize Google Cloud Build by GoogleCloudBuild. Você será redirecionado para o Console do Google Cloud.

8. Selecione seu projeto do Google Cloud.

9. Selecione a caixa de seleção de consentimento e clique em Avançar.

10. Clique em Install.

11. Faça login no Google Cloud. A página Autorização é exibida e você precisa autorizar o aplicativo Google Cloud Build para se conectar ao Google Cloud.

12. Clique em Authorize Google Cloud Build by GoogleCloudBuild. Você será redirecionado para o Console do Google Cloud.

13. Selecione seu projeto do Google Cloud.

14. Selecione a caixa de seleção de consentimento e clique em Avançar.

15. Na página Selecionar repositório exibida, selecione os seguintes repositórios do GitHub:

    • YOUR_PRIVATE_DRY_REPO
    • YOUR_PRIVATE_HYDRATED_REPO

16. Clique em Conectar e em Concluído.

Crie um gatilho do Cloud Build para o repositório DRY

1. No Cloud Shell, execute o seguinte comando:

   envsubst < cloudbuild.template.yaml > cloudbuild.yaml
   

   O comando gera um arquivo cloudbuild.yaml.

2. Crie o gatilho:

   gcloud beta builds triggers create github \
     --name ActiveAssistDemo \
     --repo-name=$DRY_REPO_NAME \
     --repo-owner=$REPO_OWNER \
     --branch-pattern="main" \
     --build-config=cloudbuild.yaml
   

3. Conceda permissão à conta de serviço do Cloud Build para acessar o Secret Manager:

   gcloud secrets add-iam-policy-binding github-ssh-key  \
     --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
     --role="roles/secretmanager.secretAccessor"
   
   gcloud secrets add-iam-policy-binding github-pat  \
     --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
     --role="roles/secretmanager.secretAccessor"
   

Criar um gatilho programado do Cloud Build para recomendações do Active Assist

Observação: use stubs para testar o pipeline neste tutorial. Ao usar o pipeline para seus projetos do Google Cloud, verifique se a conta de serviço do Cloud Build tem as permissões necessárias para buscar recomendações do Active Assist.

Nas seções a seguir, você cria um gatilho programado do Cloud Build que é executado periodicamente. Esse gatilho busca recomendações do Active Assist usando uma função kpt e determina se há recomendações ativas para os recursos no repositório YOUR_PRIVATE_HYDRATED_REPO. A função kpt também cria um problema do GitHub no seu repositório YOUR_PRIVATE_HYDRATED_REPO. Se houver recomendações ativas para a configuração de recursos que precisam ser analisadas e acionadas.

Gerar uma imagem do Cloud Build

Nesta seção, você gera uma imagem do Cloud Build que tem componentes kpt, gh e nós.

1. No Cloud Shell, crie e envie uma imagem do Docker para o Container Registry:

   gcloud auth configure-docker
   
   docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
   
   docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
   

Crie um gatilho do Cloud Build para seu repositório hidratado

1. No Cloud Shell, crie o arquivo de configuração necessário para configurar o gatilho programado do Cloud Build:

    envsubst < cloudbuild-scheduled-recommendations.template.yaml > cloudbuild-scheduled-recommendations.yaml
   

2. Crie o gatilho do Cloud Build:

   gcloud beta builds triggers create github \
     --name ActiveAssistScheduledRecommendations \
     --repo-name=YOUR_PRIVATE_HYDRATED_REPO \
     --repo-owner=$REPO_OWNER \
     --branch-pattern="main" \
     --build-config=cloudbuild-scheduled-recommendations.yaml
   

3. Consiga o ID deste gatilho:

   export TRIGGER_ID=`gcloud beta builds triggers describe \
     ActiveAssistScheduledRecommendations \
     --format="value(id)"`
   

Criar um job do Cloud Scheduler para invocar o gatilho

1. No Cloud Shell, crie uma conta de serviço:

   gcloud iam service-accounts create build-invoker \
      --description "Service Account used by Cloud Scheduler to invoke the sample scheduled Cloud Build job" \
      --display-name "recommender-scheduler-sa" \
      --project $RECO_MGR_PROJECT
   

   Os jobs do Cloud Scheduler usam essa conta de serviço para executar o serviço recommender-parser.

2. Conceda as permissões à conta de serviço para invocar um job do Cloud Build:

   gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
     --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
     --role roles/cloudbuild.builds.editor \
     --project $RECO_MGR_PROJECT
   
    gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
      --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
      --role roles/serviceusage.serviceUsageConsumer \
      --project $RECO_MGR_PROJECT
   

3. Crie um job do Cloud Scheduler para invocar o gatilho criado na etapa anterior:

   gcloud scheduler jobs create http scheduled-build \
      --project $RECO_MGR_PROJECT \
      --time-zone "America/Los_Angeles" \
      --schedule="0 */3 * * *" \
      --uri="https://cloudbuild.googleapis.com/v1/projects/${RECO_MGR_PROJECT}/triggers/${TRIGGER_ID}:run" \
      --description="Scheduler job to invoke Cloud Build" \
      --oauth-service-account-email="build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com" \
      --headers="Content-Type=application/json" \
      --http-method="POST" \
   

   Selecione Y se aparecer a seguinte mensagem:

   There is no App Engine app in the project.

   Se for solicitado que você escolha a região em que quer armazenar o aplicativo do App Engine, selecione a região us-central.

Confirmar e enviar os arquivos de configuração do Cloud Build para o GitHub

Envie os dois arquivos de configuração do Cloud Build que você criou para seu repositório YOUR_PRIVATE_DRY_REPO:

git remote add dry https://github.com/$REPO_OWNER/$DRY_REPO_NAME.git

git add cloudbuild.yaml
git add cloudbuild-scheduled-recommendations.yaml
git commit -m "Added cloudbuild configuration YAMLs"
git push dry main

Talvez seja necessário inserir suas credenciais do GitHub quando você as envia para o repositório particular.

Analisar o resultado do job do Cloud Build

Quando você confirma e envia alterações para o repositório YOUR_PRIVATE_DRY_REPO, o job do Cloud Build é acionado. Se o job do Cloud Build for executado com êxito, vários recursos serão criados. Nesta seção, você verifica se os recursos foram criados após a conclusão do job do Cloud Build.

1. No Cloud Shell, no cluster sample-ops, valide se você tem um namespace chamado activeassist-kcc:

   kubectl get ns | grep activeassist-kcc
   

2. O Config Connector implanta uma instância de amostra do Compute Engine em execução no projeto PROJECT_ID.

   Valide se a instância do Compute Engine está no projeto:

    gcloud compute instances list | grep \
    computeinstance-sample-cloudmachine
   

   O tipo MACHINE_TYPE dessa máquina é n1-standard-1.

Executar testes completos

Para permitir que você teste o pipeline completo, o repositório que você clonou para este tutorial fornece recomendações de exemplo (stubs). Você usa esses stubs para executar o pipeline completo. O stub imita um payload de recomendação do Active Assist e tem uma recomendação para alterar o tipo de máquina para a instância do Compute Engine implantada no tipo de instância n1-standard-1 para o tipo de instância g1-small. de dados.

Nesta seção, você invocará o gatilho programado do Cloud Build manualmente para executar o job que usa uma função kpt para buscar recomendações do Active Assist. Você também verifica se um problema do GitHub foi criado no repositório YOUR_PRIVATE_DRY_REPO.

1. Abra a página Gatilhos de compilação no console do Google Cloud.

   Abrir a página “Gatilhos de compilação”

2. Selecione o gatilho ActiveAssistScheduledRecommendations.

3. Para testar manualmente o gatilho, clique em Executar na entrada do seu gatilho na lista de gatilhos.

   O gatilho cria um problema do GitHub no seu repositório YOUR_PRIVATE_DRY_REPO. O problema é similar a:

   gcloud auth configure-docker
   
   docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
   
   docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
   

   No problema de amostra, a saída da função kpt mostra que o tipo MACHINE_TYPE atual da instância do Compute Engine é do tipo n1-standard-1. A recomendação do Active Assist é alterá-lo para um tipo g1-small.

   Os revisores de controle de versão da sua empresa podem analisar os problemas automatizados do GitHub e tomar as medidas adequadas para ela.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Cuidado: excluir um projeto tem os seguintes efeitos:
• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.
1. No Console do Google Cloud, acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir

• Saiba mais sobre as tecnologias sem servidor do Google Cloud.
• Leia sobre como integrar as recomendações do Policy Intelligence em um pipeline de infraestrutura como código (IaC, na sigla em inglês).