Configure o controlador de configuração

Esta página mostra como configurar o Config Controller.

O Config Controller oferece um plano de controlo gerido baseado no Kubernetes. Além disso, as instâncias do Config Controller são pré-instaladas com o Policy Controller, o Config Sync e o Config Connector. Ao usar estes componentes, pode usar as ferramentas e os fluxos de trabalho do Kubernetes para gerir Google Cloud recursos e alcançar a consistência através de um fluxo de trabalho GitOps. Para saber mais, consulte a vista geral do Config Controller.

Se estiver a criar uma instância do Config Controller pela primeira vez, consulte o Início rápido: faça a gestão de recursos com o Config Controller.

Limitações

  • Uma vez que as instâncias do Config Controller são totalmente geridas, não pode registá-las numa frota.

Antes de começar

Antes de configurar o Config Controller, conclua os seguintes passos:

  1. Instale e inicialize a Google Cloud CLI, que fornece a CLI do Google Cloud usada nestas instruções. Se usar o Cloud Shell, a Google Cloud CLI já está instalada.

  2. Uma vez que o kubectl não está instalado por predefinição na Google CloudCLI, instale-o:

    gcloud components install kubectl

  3. Defina o Google Cloud projeto onde quer alojar o Config Controller:

    gcloud config set project PROJECT_ID

    Substitua PROJECT_ID pelo projeto Google Cloud que vai alojar o Config Controller.

  4. Ative as APIs necessárias:

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

Crie uma instância do Config Controller

Pode criar uma instância do Config Controller suportada por um cluster padrão ou um cluster do Autopilot. Ambos os tipos de clusters são privados.

Selecione um cluster padrão se quiser mais opções de personalização. Selecione um cluster do Autopilot se quiser uma instalação mais rápida, escala automática de pods horizontal e vertical, e funcionalidades de segurança melhoradas, como o SO otimizado para contentores, os nós do GKE protegidos, a federação de identidades da carga de trabalho para o GKE e o arranque seguro.

A criação de um novo cluster pode demorar até 15 minutos. Se quiser observar o que está a acontecer durante a criação, pode ver o Explorador de registos naGoogle Cloud consola.

Aceda ao Explorador de registos

Se encontrar erros durante a criação, consulte o artigo Resolva problemas do Config Controller para obter orientações sobre a resolução de problemas comuns.

Crie um cluster do Autopilot

Para criar uma instância do Config Controller num cluster do Autopilot, execute o seguinte comando:

gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION \
    --full-management

Substitua o seguinte:

  • CONFIG_CONTROLLER_NAME: o nome que quer dar à sua instância do Config Controller.
  • LOCATION: a localização onde quer criar a instância do Config Controller, por exemplo, us-central. Para ver uma lista das localizações suportadas, consulte o artigo Localizações.

Crie um cluster padrão

Para criar uma instância do Config Controller num cluster Standard, execute o seguinte comando:

gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION

Substitua o seguinte:

  • CONFIG_CONTROLLER_NAME: o nome que quer dar à sua instância do Config Controller.
  • LOCATION: a localização onde quer criar a instância do Config Controller, por exemplo, us-central. Para ver uma lista das localizações suportadas, consulte o artigo Localizações.

Pode definir vários parâmetros opcionais quando cria uma instância do Config Controller padrão. Para ver a lista completa de opções, consulte a gcloud anthos config controller create documentação.

Confirme a sua instância do Config Controller

Para confirmar que a instância do Config Controller está configurada, conclua os passos seguintes:

  1. Para verificar se as instâncias do Config Controller foram criadas, veja a lista de instâncias do Config Controller:

    gcloud anthos config controller list --location=LOCATION

    Deve ver um valor de RUNNING na coluna de estado. Se o estado for CREATING, a instância do controlador de configuração ainda está a ser criada e deve continuar a aguardar. Se vir ERROR, significa que encontrou um problema que não pode resolver sozinho. Contacte o Google Cloud apoio técnico para receber assistência.

  2. Para comunicar com o ponto final do Config Controller, obtenha as credenciais e as informações do ponto final adequadas:

    gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
    --location LOCATION

Use a sua instância do Config Controller

Agora que criou uma instância do Config Controller, pode começar a usar os componentes instalados e concluir as seguintes tarefas:

  • Use o Config Connector para criar Google Cloud recursos. Se tiver Google Cloud recursos existentes que quer usar com o Config Controller, saiba como adquirir um recurso existente.

  • Use o Policy Controller para aplicar restrições que aplicam a conformidade regulamentar e as normas do Kubernetes.

  • Depois de configurar o Config Sync, na secção seguinte, sincronize a instância do Config Controller com as configurações (incluindo restrições do Policy Controller e recursos do Config Connector) que estão armazenadas numa fonte de verdade.

Para ver um exemplo guiado que mostra como concluir estas tarefas com o Config Controller, consulte o artigo Início rápido: faça a gestão de recursos com o Config Controller.

Configure a instância do Config Controller

As secções seguintes explicam como configurar os componentes da sua instância do Config Controller.

Configure o Config Connector

Não tem de gerir nenhuma definição para a instalação do Config Connector. No entanto, tem de conceder autorizações do Config Controller para gerir Google Cloud recursos:

  1. Defina uma variável de ambiente para o email da sua conta de serviço:

    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
    -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"

  2. Crie a associação de políticas:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:${SA_EMAIL}" \
    --role "ROLE" \
    --project PROJECT_ID

    Substitua o seguinte:

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

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

Depois de conceder estas autorizações, pode começar a criar Google Cloud recursos.

Configure o Controlador de políticas

Pode ter de adicionar ou atualizar a política de IAM para permitir que o Policy Controller envie métricas.

Permita que o Policy Controller envie métricas executando este comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[gatekeeper-system/gatekeeper-admin]" \
  --role=roles/monitoring.metricWriter

Substitua PROJECT_ID pelo ID do projeto do Google Cloud cluster.

Configure o Config Sync

Se quiser que a instância do Config Controller seja sincronizada a partir de configurações armazenadas numa fonte de verdade, tem de configurar o Config Sync.

Se quiser usar o Config Sync para criar recursos do Config Connector, certifique-se de que também concedeu autorização ao Config Controller para gerir recursos.

Para configurar o Config Sync, crie e edite um objeto RootSync:

  1. Para sincronizar a partir de um repositório externo (por exemplo, o GitHub), configure o Cloud NAT com o GKE. Tem de o fazer porque os nós do cluster privado não têm acesso à Internet de saída.

  2. Guarde um dos seguintes manifestos como root-sync.yaml. Use a versão do manifesto que corresponde ao tipo de origem das suas configurações.

    Git

    # root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: ROOT_FORMAT
  git:
    repo: ROOT_REPOSITORY
    revision: ROOT_REVISION
    branch: ROOT_BRANCH
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    secretRef:
      name: ROOT_SECRET_NAME
    noSSLVerify: ROOT_NO_SSL_VERIFY
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME

    Substitua o seguinte:

    • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
    • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou adicione hierarchy para usar um repositório hierárquico. Estes valores são sensíveis a maiúsculas e minúsculas. Este campo é opcional e o valor predefinido é hierarchy. Recomendamos que adicione unstructured, uma vez que este formato permite organizar as configurações da forma mais conveniente para si.
    • ROOT_REPOSITORY: adicione o URL do repositório Git a usar como repositório raiz. Pode introduzir URLs através do protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
    • ROOT_REVISION: adicione a revisão do Git (etiqueta ou hash) ou o ramo a partir do qual sincronizar. Este campo é opcional e o valor predefinido é HEAD. Quando usar um hash, tem de ser um hash completo e não uma forma abreviada.
    • ROOT_BRANCH: adicione a ramificação do repositório a partir da qual quer sincronizar. Este campo é opcional e o valor predefinido é master. Recomendamos que use o campo revision para especificar um nome de ramificação para simplificar. Se o campo revision e o campo branch forem especificados, revision tem prioridade sobre branch.
    • ROOT_DIRECTORY: adicione o caminho no repositório Git ao diretório de raiz que contém a configuração que quer sincronizar. Este campo é opcional e a predefinição é o diretório de raiz (/) do repositório.

    • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

      • none: Não usar autenticação
      • ssh: Use um par de chaves SSH
      • cookiefile: use um cookiefile
      • token: usar um token
      • gcpserviceaccount: use uma conta de serviço Google para aceder a um Cloud Source Repositories.
      • gcenode: use uma conta de serviço Google para aceder a um Cloud Source Repositories. Selecione esta opção apenas se a Workload Identity Federation para o GKE não estiver ativada no seu cluster.

      Para mais informações sobre estes tipos de autenticação, consulte o artigo Conceder acesso só de leitura do Config Sync ao Git.

      Este campo é obrigatório.

    • ROOT_EMAIL: se adicionou gcpserviceaccount como o seu ROOT_AUTH_TYPE, adicione o endereço de email da conta de serviço Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME: adicione o nome do seu segredo. Se este campo estiver definido, tem de adicionar a chave pública do segredo ao fornecedor do Git. Este campo é opcional.

    • ROOT_NO_SSL_VERIFY: para desativar a validação do certificado SSL, defina este campo como true. O valor predefinido é false.

    • ROOT_CA_CERT_SECRET_NAME: adicione o nome do seu segredo. Se este campo estiver definido, o seu fornecedor de Git tem de usar um certificado emitido por esta autoridade de certificação (AC). O Secret tem de conter o certificado da AC numa chave com o nome cert. Este campo é opcional.

      Para saber como configurar o objeto Secret para o certificado da AC, consulte o artigo Configurar autoridade de certificação

    Para uma explicação dos campos e uma lista completa dos campos que pode adicionar ao campo spec, consulte Campos RootSync.

    Este manifesto cria um objeto RootSync que usa o Git como origem.

    OCI

    # root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: ROOT_FORMAT
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME

    Substitua o seguinte:

    • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
    • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou adicione hierarchy para usar um repositório hierárquico. Estes valores são sensíveis a maiúsculas e minúsculas. Este campo é opcional e o valor predefinido é hierarchy. Recomendamos que adicione unstructured, uma vez que este formato permite organizar as configurações da forma mais conveniente para si.
    • ROOT_IMAGE: o URL da imagem OCI a usar como repositório raiz, por exemplo, LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Por predefinição, a imagem é extraída da etiqueta latest, mas pode extrair imagens através de TAG ou DIGEST. Especifique TAG ou DIGEST em PACKAGE_NAME:
      • Para puxar por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Para puxar por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: adicione o caminho no repositório ao diretório de raiz que contém a configuração que quer sincronizar. Este campo é opcional e a predefinição é o diretório de raiz (/) do repositório.

    • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

      • none: Não usar autenticação
      • gcenode: use a conta de serviço predefinida do Compute Engine para aceder a uma imagem no Artifact Registry. Selecione esta opção apenas se a Workload Identity Federation para o GKE não estiver ativada no seu cluster.
      • gcpserviceaccount: use uma conta de serviço Google para aceder a uma imagem.

      Este campo é obrigatório.

    • ROOT_EMAIL: se adicionou gcpserviceaccount como o seu ROOT_AUTH_TYPE, adicione o endereço de email da conta de serviço Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_CA_CERT_SECRET_NAME: adicione o nome do seu segredo. Se este campo estiver definido, o seu fornecedor de OCI tem de estar a usar um certificado emitido por esta autoridade de certificação (AC). O Secret tem de conter o certificado da AC numa chave com o nome cert. Este campo é opcional.

    Para saber como configurar o objeto Secret para o certificado da AC, consulte o artigo Configurar autoridade de certificação

    Para uma explicação dos campos e uma lista completa dos campos que pode adicionar ao campo spec, consulte Campos RootSync.

    Este manifesto cria um objeto RootSync que usa uma imagem OCI como origem.

    Leme

    # root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: ROOT_FORMAT
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME

    Substitua o seguinte:

    • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
    • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou adicione hierarchy para usar um repositório hierárquico. Estes valores são sensíveis a maiúsculas e minúsculas. Este campo é opcional e o valor predefinido é hierarchy. Recomendamos que adicione unstructured, uma vez que este formato permite organizar as configurações da forma mais conveniente para si.
    • ROOT_HELM_REPOSITORY: o URL do repositório Helm a usar como repositório raiz. Pode introduzir URLs através do protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
    • HELM_CHART_NAME: adicione o nome do seu gráfico Helm. Este campo é obrigatório.
    • HELM_CHART_VERSION: a versão do seu gráfico. Este campo é opcional. Se não for especificado nenhum valor, é usada a versão mais recente.
    • HELM_RELEASE_NAME: o nome do lançamento do Helm. Este campo é opcional.
    • HELM_RELEASE_NAMESPACE: o espaço de nomes de destino para uma versão. Só define um espaço de nomes para recursos que contenham namespace: {{ .Release.Namespace }} nos respetivos modelos. Este campo é opcional. Se não for especificado nenhum valor, é usado o espaço de nomes predefinido config-management-system.
    • HELM_INCLUDE_CRDS: defina como true se quiser que o modelo Helm também gere uma CustomResourceDefinition. Este campo é opcional. Se não for especificado nenhum valor, a predefinição é false e não é gerado nenhum CRD.
    • VALUE: valores a usar em vez dos valores predefinidos que acompanham o gráfico Helm. Formate este campo da mesma forma que o ficheiro values.yaml do gráfico Helm. Este campo é opcional.

    • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

      • none: Não usar autenticação
      • token: use um nome de utilizador e uma palavra-passe para aceder a um repositório Helm privado.
      • gcenode: use a conta de serviço predefinida do Compute Engine para aceder a uma imagem no Artifact Registry. Selecione esta opção apenas se a Workload Identity Federation para o GKE não estiver ativada no seu cluster.
      • gcpserviceaccount: use uma conta de serviço Google para aceder a uma imagem.

      Este campo é obrigatório.

    • ROOT_EMAIL: se adicionou gcpserviceaccount como o seu ROOT_AUTH_TYPE, adicione o endereço de email da conta de serviço Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME: adicione o nome do seu segredo se token for o ROOT_AUTH_TYPE. Este campo é opcional.

    • ROOT_CA_CERT_SECRET_NAME: adicione o nome do seu segredo. Se este campo estiver definido, o seu fornecedor do Helm tem de usar um certificado emitido por esta autoridade de certificação (AC). O Secret tem de conter o certificado da AC numa chave com o nome cert. Este campo é opcional.

    Para saber como configurar o objeto Secret para o certificado da AC, consulte o artigo Configurar autoridade de certificação

    Para uma explicação dos campos e uma lista completa dos campos que pode adicionar ao campo spec, consulte Campos RootSync.

    Este manifesto cria um objeto RootSync que usa o Helm como origem.

  3. Para criar a configuração do Config Sync, crie um objeto RootSync aplicando o manifesto:

    kubectl apply -f root-sync.yaml

  4. Para verificar se as alterações foram aplicadas, veja o objeto RootSync:

    kubectl describe rootsync ROOT_SYNC_NAME -n config-management-system

Atualize o controlador de configuração

Uma vez que o Config Controller é um serviço gerido, a Google atualiza-o automaticamente. Para ver detalhes sobre as novas funcionalidades e saber que versões do Config Sync, Policy Controller e Config Connector o Config Controller usa, consulte as notas de lançamento do Config Controller.

Elimine a instância do Config Controller

Se decidir deixar de usar uma instância do Config Controller, limpe todos os recursos do Config Connector criados antes de eliminar o próprio cluster do Config Controller.

Se eliminar a instância do Config Controller sem eliminar primeiro os recursos aprovisionados, os recursos ficam num estado abandonado. Os recursos continuam a existir em Google Cloud (e incorrem em custos de faturação), mas não são geridos a partir da configuração declarativa.

Depois de eliminar todos os seus recursos, elimine o cluster do Config Controller:

gcloud anthos config controller delete \
    --location=LOCATION CONFIG_CONTROLLER_NAME

Considerações de produção

Quando passar para a produção, deve rever primeiro as considerações de alta disponibilidade para o Config Controller.

O que se segue?