Configurar o Config Controller

Prévia

Este produto é coberto pelos Termos de ofertas pré-disponibilidade geral dos Termos de Serviço do Google Cloud Platform. Os produtos pré-disponibilidade geral podem ter suporte limitado, e as mudanças realizadas podem não ser compatíveis com outras versões pré-GA. Para mais informações, consulte as descrições das fases de lançamento.

Esta página mostra como configurar o Config Controller. O Config Controller é um serviço hospedado para provisionar e orquestrar os recursos do Anthos e do Google Cloud. Ele oferece um endpoint de API que pode provisionar, acionar e orquestrar recursos do Google Cloud como parte do Anthos Config Management. Para saber mais sobre o Config Controller, consulte Visão geral do Config Controller.

Antes de começar

Antes de configurar o Config Controller, você precisa concluir as seguintes etapas:

1. Instale e inicialize o SDK do Cloud, que fornece os comandos gcloud, kubectl e nomos usados nessas instruções. Se você usa o Cloud Shell, o SDK do Cloud vem pré-instalado.

   O kubectl não é instalado por padrão pelo SDK do Cloud. Para instalar o kubectl, execute o seguinte comando:

   gcloud components install kubectl
   

2. Crie ou permita a criação de uma rede padrão. O Config Controller depende dele. Para criar uma rede padrão, execute o seguinte comando:

   gcloud compute networks create default --subnet-mode=auto
   

Configurar o Config Controller

Crie um controlador de configuração com os seguintes comandos da ferramenta gcloud:

1. Ative o serviço no projeto para usar os comandos da ferramenta gcloud subsequentes:

   gcloud services enable krmapihosting.googleapis.com \
       container.googleapis.com \
       cloudresourcemanager.googleapis.com
   

2. Crie seu controlador de configuração. Essa operação pode levar mais de 15 minutos.

   gcloud alpha anthos config controller create CONFIG_CONTROLLER_NAME \
       --location=us-central1
   

   Substitua CONFIG_CONTROLLER_NAME pelo nome que você quer dar ao controlador.

   Observação: use us-central1 como location.

3. Depois que sua instância for criada, ela aparecerá na lista de instâncias. Para ver a lista de instâncias, execute o seguinte comando:

   gcloud alpha anthos config controller list --location=us-central1
   

4. Faça a autenticação com a instância para aplicar os manifestos:

   gcloud alpha anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
       --location us-central1
   

5. Conceda permissão ao Config Controller para gerenciar os recursos do Google Cloud no projeto:

   export PROJECT_ID=$(gcloud config get-value project)
   export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
       -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
   gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
       --member "serviceAccount:${SA_EMAIL}" \
       --role "roles/owner" \
       --project "${PROJECT_ID}"
   

   Observação: se a operação anterior falhar, verifique se os controladores estão prontos.

Gerenciar recursos do Google Cloud com o Config Controller

Depois de concluir a configuração do Config Controller, você estará pronto para usar o Config Controller para gerenciar recursos do Google Cloud.

Neste exemplo, você criará um Cloud Source Repositories que pode ser usado na seção Configurar o GitOps.

1. Crie um arquivo chamado service.yaml e copie o arquivo YAML a seguir nele.

   # service.yaml
   
   apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
   kind: Service
   metadata:
     name: sourcerepo.googleapis.com
     namespace: config-control
   

   Observação: o Config Controller usa o namespace config-control para gerenciar recursos no projeto.

2. Aplique o manifesto e aguarde para ativar o Cloud Source Repositories:

   kubectl apply -f service.yaml
   kubectl wait -f service.yaml --for=condition=Ready
   

3. Crie um arquivo chamado repo.yaml e copie o arquivo YAML a seguir nele:

   # repo.yaml
   
   apiVersion: sourcerepo.cnrm.cloud.google.com/v1beta1
   kind: SourceRepoRepository
   metadata:
     name: REPO_NAME
     namespace: config-control
   

   Substitua REPO_NAME pelo nome dos Cloud Source Repositories que você quer fornecer.

4. Aplique o manifesto para criar o repositório:

   kubectl apply -f repo.yaml
   

Configure o GitOps

É possível sincronizar configurações no seu repositório Git com o Config Controller usando o Config Sync. No exemplo desta seção, você usará o Cloud Source Repositories criado na seção anterior.

Observação: é preciso que o repositório seja inicializado antes de continuar.

1. Crie um arquivo chamado gitops-iam.yaml e copie o arquivo YAML a seguir nele.

   # gitops-iam.yaml
   
   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMServiceAccount
   metadata:
     name: config-sync-sa
     namespace: config-control
   spec:
     displayName: ConfigSync
   
   ---
   
   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: config-sync-wi
     namespace: config-control
   spec:
     member: serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/importer]
     role: roles/iam.workloadIdentityUser
     resourceRef:
       apiVersion: iam.cnrm.cloud.google.com/v1beta1
       kind: IAMServiceAccount
       name: config-sync-sa
   
   ---
   
   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: allow-configsync-sa-read-csr
     namespace: config-control
   spec:
     member: serviceAccount:config-sync-sa@PROJECT_ID.iam.gserviceaccount.com
     role: roles/source.reader
     resourceRef:
       apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
       kind: Project
       external: projects/PROJECT_ID
   

   Substitua PROJECT_ID pelo ID do projeto em que o Config Controller está em execução.

2. Aplique o manifesto para conceder ao Config Sync acesso ao repositório.

   kubectl apply -f gitops-iam.yaml
   

3. Para ter configurações no repositório sincronizadas com o Config Controller usando o Config Sync, crie um arquivo chamado config-management.yaml e cole o seguinte texto nele:

   # config-management.yaml
   
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     enableMultiRepo: false
     clusterName: krmapihost-CONFIG_CONTROLLER_NAME
     git:
       policyDir: DIRECTORY
       gcpServiceAccountEmail: config-sync-sa@PROJECT_ID.iam.gserviceaccount.com
       secretType: gcpserviceaccount
       syncBranch: BRANCH
       syncRepo: REPO
     sourceFormat: unstructured
   

   Substitua:

   • CONFIG_CONTROLLER_NAME pelo nome do Config Controller.
   • DIRECTORY: o caminho no repositório Git ao diretório raiz que contém a configuração que você quer sincronizar. O padrão é o diretório raiz do repositório.
   • PROJECT_ID: o ID do projeto;
   • BRANCH: a ramificação do repositório com que sincronizar. O padrão é a ramificação principal (mestre).
   • REPO: o URL do repositório Git para usar como fonte. É possível inserir URLs usando o protocolo HTTPS.

   Para informações mais detalhadas sobre como configurar o Config Sync, consulte Como conceder acesso somente leitura do Config Sync ao Git.

4. Aplique a configuração com o comando kubectl apply:

   kubectl apply -f config-management.yaml
   

Verificar o sucesso

É possível verificar a configuração inicial seguindo estas etapas:

1. Verifique se todos os controladores foram configurados com sucesso no Config Controller:

   kubectl wait pod --all --all-namespaces --for=condition=Ready
   

2. Verifique se o repositório Git está sincronizado com o Config Controller com o Config Sync usando o comando nomos:

   nomos status --contexts $(kubectl config current-context)
   

Excluir o Config Controller

Se você decidir parar de usar o Config Controller, limpe todos os recursos criados. Primeiro, você precisa remover recursos do Config Controller antes de excluir o próprio Config Controller.

Excluir o controlador de configuração sem primeiro excluir os recursos provisionados deixa os recursos em um estado abandonado. Os recursos ainda existem no Google Cloud (e geram cobranças de faturamento), mas não são gerenciados pela configuração declarativa.

Depois que todos os recursos forem excluídos, será possível excluir o Config Controller usando a ferramenta gcloud:

gcloud alpha anthos config controller delete --location=us-central1 CONFIG_CONTROLLER_NAME

Solução de problemas

Rede padrão

Ao criar o controlador de configuração, você pode receber um erro sobre a indisponibilidade da rede padrão:

Error 400: Project \"PROJECT_ID\" has no network named \"default\"., badRequest\n\n  on main.tf line 35, in resource \"google_container_cluster\" \"acp_cluster\"

Esse erro ocorre porque o Config Controller depende da rede padrão no Google Cloud. Para resolver isso, crie uma nova rede padrão:

gcloud compute networks create default --subnet-mode=auto

Observação: é necessário ativar as sub-redes automáticas na rede padrão para que esse comando funcione.

Como alternativa, você pode selecionar uma rede diferente usando a sinalização --network no comando gcloud alpha anthos config controller create.

CIDR IPv4 do plano de controle

A criação do Config Controller usa uma sub-rede padrão 172.16.0.128/28 para o CIDR IPv4 do plano de controle. Se houver um conflito no bloco CIDR IPv4, a criação do Config Controller falhará com este erro:

Cloud SSA\n\nError: Error waiting for creating GKE cluster: Invalid value for field PrivateClusterConfig.MasterIpv4CidrBlock: 172.16.0.128/28 conflicts with an existing subnet in one of the peered VPCs.

Se você vir esse erro, selecione um CIDR IPv4 particular diferente e use-o usando a sinalização --master-ipv4-cidr-block no comando gcloud alpha anthos config controller create.

Para encontrar os blocos CIDR IPv4 que já estão em uso:

1. Encontre o nome do peering usando o seguinte comando:

   gcloud compute networks peerings list --network=NETWORK
   

   Substitua NETWORK pelo nome da rede que você quer procurar.

   Você receberá uma resposta como esta:

   NAME                                     NETWORK  PEER_PROJECT               PEER_NETWORK                            PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
   gke-n210ce17a4dd120e16b6-7ebf-959a-peer  default  gke-prod-us-central1-59d2  gke-n210ce17a4dd120e16b6-7ebf-0c27-net            False                 False                 ACTIVE  [2021-06-08T13:22:07.596-07:00]: Connected.
   

2. Para mostrar o CIDR IPv4 que está sendo usado pelo peering, use o seguinte comando:

   gcloud compute networks peerings list-routes PEERING_NAME \
       --direction=INCOMING \
       --network=NETWORK \
       --region=us-central1
   

   Substitua:

   • PEERING_NAME pelo nome de peering que você quer procurar.
   • NETWORK pelo nome da rede que você quer pesquisar.
   Observação: use us-central1 como region.

Implantação e Config Sync

As configurações no repositório Git são sincronizadas com o Config Controller usando o Config Sync. É possível verificar erros neste processo de sincronização usando o comando nomos:

nomos status  --contexts $(kubectl config current-context)

Recursos do Config Connector

Campos e recursos imutáveis

Alguns campos nos recursos subjacentes do Google Cloud são imutáveis, como IDs do projeto ou o nome da sua rede VPC. O Config Connector bloqueia as edições nesses campos e não pode ativar as alterações. Se quiser editar um desses campos imutáveis, primeiro exclua o recurso original (por meio do Git) antes de adicioná-lo novamente com os novos valores preferidos.

Recursos travados

Em alguns casos, os recursos podem não ser excluídos corretamente, conforme reportado por nomos status. Isso pode ser corrigido ao remover os finalizadores do recurso e excluí-lo manualmente. Por exemplo, para excluir um IAMPolicyMember que esteja travado, execute o seguinte comando:

kubectl patch IAMPolicyMember logging-sa-iam-permissions -p '{"metadata":{"finalizers":[]}}' --type=merge -n config-control
kubectl delete IAMPolicyMember logging-sa-iam-permissions -n config-control