Instale o Config Sync manualmente com o kubectl (não recomendado)

Esta página mostra como instalar a sincronização de configuração através de comandos kubectl.

Aviso: os métodos de instalação usados nesta página não são recomendados porque não são compatíveis com a Google Cloud consola nem com a CLI Google Cloud.

Antes de começar

Esta secção descreve os pré-requisitos que tem de cumprir antes de instalar o Config Sync através do kubectl.

Prepare o seu ambiente local

Antes de instalar o Config Sync, certifique-se de que preparou o seu ambiente local concluindo as seguintes tarefas:

• Criar ou ter acesso a uma fonte de informação.

• Instale e inicialize a CLI Google Cloud, que fornece os comandos gcloud, kubectl e nomos usados nestas instruções. Se usar o Cloud Shell, a Google Cloud CLI é pré-instalada.

• kubectl não está instalado por predefinição pela CLI do Google Cloud. Para instalar o kubectl, use o seguinte comando:

  gcloud components install kubectl
  

• Autentique-se no Google Cloud usando o comando gcloud auth login para poder transferir componentes do Config Sync.

Prepare os seus clusters

Criar ou ter acesso a um cluster do Google Kubernetes Engine que cumpra os requisitos do Config Sync.

Prepare as autorizações

O Google Cloud utilizador que instala o Config Sync precisa de autorizações do IAM para criar novas funções no seu cluster. Se necessário, conceda estas funções com os seguintes comandos:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

Substitua o seguinte:

• CLUSTER_NAME: o nome do seu cluster
• USER_ACCOUNT: o endereço de email da sua conta Google Cloud

Consoante a forma como configurou a CLI do Google Cloud no seu sistema local, pode ter de adicionar os campos --project e --zone.

Se precisar de conceder acesso do Config Sync ao OCI usando gcpserviceaccount como tipo de autenticação, para criar uma associação de políticas, também tem de ter a autorização iam.serviceAccounts.setIamPolicy. Pode obter esta autorização concedendo a função IAM de administrador da conta de serviço (roles/iam.serviceAccountAdmin). Também pode conseguir esta autorização com funções personalizadas ou outras funções predefinidas.

Para mais informações sobre a concessão de funções, consulte o artigo Gerir acesso.

Inscreva um cluster

Para inscrever um cluster no Config Sync, conclua os seguintes passos:

1. Implemente o Config Sync
2. Conceda acesso só de leitura ao Config Sync a uma das seguintes opções:
   • Git
   • OCI
   • Helm
3. Configure o Config Sync

Implemente o Config Sync

Depois de se certificar de que cumpre todos os pré-requisitos, pode implementar o Config Sync transferindo e aplicando um manifesto YAML:

1. Transfira a versão mais recente dos manifestos do Config Sync através do comando seguinte. Em alternativa, para transferir uma versão específica, consulte a secção Transferências.

   gcloud storage cp gs://config-management-release/released/latest/config-sync.tar.gz config-sync.tar.gz
   

2. Extraia o arquivo:

   tar -xzvf config-sync.tar.gz

3. No arquivo que extraiu no passo anterior, siga as instruções no ficheiro README.md fornecido para editar a personalização.

4. Para atualizar a instalação do Config Sync, aplique o manifesto renderizado que criou seguindo as README.md instruções:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Substitua CONFIG_SYNC_MANIFEST pelo nome do manifesto renderizado.

5. Substitua o comando nomos em todos os clientes pela nova versão. Esta alteração garante que o comando nomos pode sempre obter o estado de todos os clusters inscritos e validar as configurações dos mesmos.

Se esta ação falhar devido a um problema com o Config Sync que não seja devido a um erro de sintaxe YAML ou JSON, o objeto pode ser instanciado no cluster, mas pode não funcionar corretamente. Nesta situação, pode usar o comando nomos status para verificar se existem erros no objeto.

Uma instalação válida sem problemas tem o estado PENDING ou SYNCED.

Uma instalação inválida tem o estado NOT CONFIGURED e apresenta um dos seguintes erros:

• missing git-creds Secret
• git-creds Secret is missing the key specified by secretType

Para corrigir o problema, corrija o erro de configuração. Consoante o tipo de erro, pode ter de voltar a aplicar o manifesto do Config Sync ao cluster.

Se o problema for que se esqueceu de criar o git-credssegredo, o Config Sync deteta o segredo assim que o cria e não precisa de voltar a aplicar a configuração.

Conceda acesso só de leitura ao Config Sync

Se armazenar as suas configurações no Git, tem de conceder ao Config Sync acesso de leitura ao Git. Se armazenar as suas configurações como imagens OCI, tem de conceder ao Config Sync acesso de leitura ao OCI. Se armazenar as suas configurações no Helm, tem de conceder ao Config Sync acesso só de leitura ao Helm.

Conceda acesso só de leitura do Config Sync ao Git

O Config Sync precisa de acesso só de leitura ao seu repositório Git para poder ler as configurações comprometidas com o repositório e aplicá-las aos seus clusters.

Se o seu repositório não exigir autenticação para acesso só de leitura, pode continuar a configurar a sincronização de configuração e usar none como tipo de autenticação. Por exemplo, se puder procurar o repositório através de uma interface Web sem iniciar sessão ou se puder usar git clone para criar um clone do repositório localmente sem fornecer credenciais ou usar credenciais guardadas, não precisa de autenticar. Neste caso, não precisa de criar um Secret.

No entanto, a maioria dos utilizadores tem de criar credenciais porque o acesso de leitura ao respetivo repositório está restrito. Se forem necessárias credenciais, estas são armazenadas no git-creds segredo em cada cluster inscrito (a menos que esteja a usar uma conta de serviço Google). O segredo tem de ter o nome git-creds porque este é um valor fixo.

A sincronização de configurações suporta os seguintes mecanismos de autenticação:

• Par de chaves SSH (ssh)
• Cookiefile (cookiefile)
• Token (token)
• Conta de serviço Google (gcpserviceaccount)
• Conta de serviço predefinida do Compute Engine (gcenode)
• App GitHub (githubapp)

O mecanismo que escolher depende do que o seu repositório suporta. Geralmente, recomendamos a utilização de um par de chaves SSH. O GitHub e o Bitbucket suportam a utilização de um par de chaves SSH. No entanto, se estiver a usar um repositório nos Cloud Source Repositories ou no Secure Source Manager, recomendamos que use uma conta de serviço Google, uma vez que o processo é mais simples. Se a sua organização alojar o repositório e não souber que métodos de autenticação são suportados, contacte o seu administrador.

Para usar um repositório no Cloud Source Repositories como o seu repositório do Config Sync, conclua os seguintes passos para obter o URL do Cloud Source Repositories:

1. Apresentar todos os repositórios:

   gcloud source repos list
   

2. Na saída, copie o URL do repositório que quer usar. Por exemplo:

   REPO_NAME  PROJECT_ID  URL
   my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
   

   Tem de usar este URL quando configurar o Config Sync na secção seguinte. Se configurar o Config Sync através da Google Cloud consola, adiciona o URL no campo URL. Se configurar o Config Sync através da Google Cloud CLI, adiciona o URL ao campo syncRepo do ficheiro de configuração.

Par de chaves SSH

Um par de chaves SSH consiste em dois ficheiros: uma chave pública e uma chave privada. Normalmente, a chave pública tem uma extensão .pub.

Aviso: proteja os ficheiros criados por este comando. Concedem a capacidade de ler a partir do seu repositório.

Para usar um par de chaves SSH, conclua os seguintes passos:

1. Crie um par de chaves SSH para permitir que o Config Sync se autentique no seu repositório Git. Este passo é necessário se tiver de fazer a autenticação no repositório para o clonar ou ler a partir dele. Ignore este passo se um administrador de segurança lhe fornecer um par de chaves. Pode usar um único par de chaves para todos os clusters ou um par de chaves por cluster, consoante os seus requisitos de segurança e conformidade.

   O comando seguinte cria uma chave RSA de 4096 bits. Não recomendamos valores inferiores:

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   Substitua o seguinte:

   • GIT_REPOSITORY_USERNAME: o nome de utilizador que quer que o Config Sync use para autenticar no repositório
   • /path/to/KEYPAIR_FILENAME: um caminho para o par de chaves

   Se estiver a usar um anfitrião de repositório Git de terceiros, como o GitHub, ou quiser usar uma conta de serviço com o Cloud Source Repositories, recomendamos que use uma conta separada.

   Nota: tem de criar a chave SSH sem uma frase secreta. O Config Sync não suporta frases secretas de chaves SSH.

2. Configure o seu repositório para reconhecer a chave pública recém-criada. Consulte a documentação do seu fornecedor de alojamento Git. Para sua conveniência, incluímos instruções para alguns fornecedores de alojamento Git populares:

   • Cloud Source Repositories
   • Bitbucket
   • GitHub Recomendamos que crie chaves de implementação separadas para conceder acesso só de leitura a um único repositório do GitHub.
   • GitLab

3. Adicione a chave privada a um novo segredo no cluster:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   Substitua /path/to/KEYPAIR_PRIVATE_KEY_FILENAME pelo nome da chave privada (a que não tem o sufixo .pub).

4. (Recomendado) Para configurar a verificação de anfitriões conhecidos através da autenticação SSH, pode adicionar a chave de anfitriões conhecidos ao campo data.known_hosts no segredo git_creds. Para desativar a verificação known_hosts, pode remover o campo known_hosts do segredo. Para adicionar a chave de anfitriões conhecidos, execute o seguinte comando:

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   Em seguida, em data, adicione a entrada de anfitriões conhecidos:

   known_hosts: KNOWN_HOSTS_KEY
   

5. Elimine a chave privada do disco local ou proteja-a de outra forma.

6. Quando configurar o Config Sync e adicionar o URL do seu repositório Git, use o protocolo SSH. Se estiver a usar um repositório nos Cloud Source Repositories, tem de usar o seguinte formato quando introduzir o URL:

   ssh://[e-mail]:2022/p/PROJECT_ID/r/REPO_NAME
   

   Substitua o seguinte:

   • EMAIL: o seu Google Cloud nome de utilizador
   • PROJECT_ID: o ID do Google Cloud projeto onde o repositório está localizado
   • REPO_NAME: o nome do repositório

Cookiefile

Nota: a utilização de credenciais cookiefile só é suportada com os Cloud Source Repositories. Se quiser usar o GitHub com a autenticação cookiefile, pode usar os Cloud Source Repositories para replicar o seu repositório do GitHub.

O processo de aquisição de um cookiefile depende da configuração do seu repositório. Para ver um exemplo, consulte o artigo Gere credenciais estáticas na documentação dos Cloud Source Repositories. Normalmente, as credenciais são armazenadas no ficheiro .gitcookies no seu diretório inicial ou podem ser-lhe fornecidas por um administrador de segurança.

Para usar um cookiefile, conclua os seguintes passos:

1. Depois de criar e obter o cookiefile, adicione-o a um novo segredo no cluster.

   Se não usar um proxy HTTPS, crie o segredo com o seguinte comando:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   Se precisar de usar um proxy HTTPS, adicione-o ao segredo juntamente com cookiefile executando o seguinte comando:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Substitua o seguinte:

   • /path/to/COOKIEFILE: o caminho e o nome do ficheiro adequados
   • HTTPS_PROXY_URL: o URL do proxy HTTPS que usa quando comunica com o repositório Git
   Nota: não recomendamos a utilização de um proxy HTTP por motivos de segurança.

2. Proteja o conteúdo da cookiefile se ainda precisar dele localmente. Caso contrário, elimine-o.

Símbolo

Se a sua organização não permitir a utilização de chaves SSH, pode preferir utilizar um token. Com a sincronização de configuração, pode usar os tokens de acesso pessoal (PATs) do GitHub, os PATs ou as chaves de implementação do GitLab ou a palavra-passe da app do Bitbucket como token.

Para criar um segredo com o seu token, conclua os seguintes passos:

1. Crie um token através do GitHub, GitLab ou Bitbucket:

   • GitHub: crie um PAT. Conceda ao token o âmbito repo para que possa ler a partir de repositórios privados. Uma vez que associa um PAT a uma conta do GitHub, também recomendamos que crie um utilizador da máquina e associe o seu PAT ao utilizador da máquina.
   • GitLab: crie um PAT ou crie uma chave de implementação
   • Bitbucket: crie uma palavra-passe da app.

2. Depois de criar e obter o token, adicione-o a um novo segredo no cluster.

   Se não usar um proxy HTTPS, crie o segredo com o seguinte comando:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   Substitua o seguinte:

   • USERNAME: o nome de utilizador que quer usar.
   • TOKEN: o token que criou no passo anterior.

   Se precisar de usar um proxy HTTPS, adicione-o ao segredo juntamente com username e token executando o seguinte comando:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Substitua o seguinte:

   • USERNAME: o nome de utilizador que quer usar.
   • TOKEN: o token que criou no passo anterior.
   • HTTPS_PROXY_URL: o URL do proxy HTTPS que usa quando comunica com o repositório Git.
   Nota: não recomendamos a utilização de um proxy HTTP por motivos de segurança.

3. Proteja o token se ainda precisar dele localmente. Caso contrário, elimine-o.

Conta de serviço Google

Se o seu repositório estiver no Cloud Source Repositories ou no Secure Source Manager, e o seu cluster usar a Federação do Workload Identity do GKE para o GKE ou a Federação do Workload Identity da frota para o GKE, pode conceder ao Config Sync acesso a um repositório no mesmo projeto que o seu cluster gerido através de uma conta de serviço Google.

1. Se ainda não tiver uma conta de serviço, crie uma conta de serviço.

2. Conceda as funções IAM corretas à conta de serviço para que possa aceder ao repositório:

   Cloud Source Repositories

   Conceda a função de leitor do Cloud Source Repositories (roles/source.reader) do IAM à conta de serviço da Google. Para mais informações sobre as funções e as autorizações dos Cloud Source Repositories, consulte o artigo Conceda autorizações para ver repositórios.

   • Conceda autorização ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Conceda autorização específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no seu projeto.

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

   Secure Source Manager

   Conceda as funções do IAM Secure Source Manager Instance Accessor (roles/securesourcemanager.instanceAccessor) e Secure Source Manager Repo Reader (roles/securesourcemanager.repoReader) à conta de serviço Google. Para mais informações sobre as funções e as autorizações do Secure Source Manager, consulte Gestão de funções do repositório.

   • Conceda autorização ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.instanceAccessor \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.repoReader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Para conceder autorizações específicas do repositório, pode usar a interface Web do Secure Source Manager para o repositório. Para mais informações, consulte o artigo Conceda funções ao nível do repositório aos utilizadores.

3. Se configurar a sincronização de configuração através da Google Cloud consola, selecione Workload Identity Federation para GKE como o tipo de autenticação e, em seguida, adicione o email da sua conta de serviço.

   Se configurar o Config Sync através da CLI do Google Cloud, adicione gcpserviceaccount como secretType e, de seguida, adicione o email da conta de serviço a gcpServiceAccountEmail.

4. Se estiver a usar um repositório no Secure Source Manager, tem de usar o seguinte formato quando configurar o Config Sync e adicionar o URL do seu repositório Git:

   https://INSTANCE_ID-PROJECT_NUMBER-git.LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git
   

   Substitua o seguinte:

   • INSTANCE_ID: o nome da sua instância do Secure Source Manager.
   • PROJECT_ID: o ID do Google Cloud projeto onde a instância está localizada.
   • PROJECT_NUMBER: o Google Cloud número do projeto onde a instância está localizada.
   • LOCATION: a região onde a sua instância está localizada.
   • REPO_NAME: o nome do repositório.

5. Depois de configurar o Config Sync, crie uma associação de políticas de IAM entre a conta de serviço do Kubernetes e a conta de serviço Google. A conta de serviço do Kubernetes não é criada até configurar o Config Sync pela primeira vez.

   Se estiver a usar clusters registados numa frota, só tem de criar a associação de políticas uma vez por frota. Todos os clusters registados numa frota partilham a mesma federação de identidade da carga de trabalho para o GKEpool. Com o conceito de igualdade da frota, se adicionar a política de IAM à sua conta de serviço do Kubernetes num cluster, a conta de serviço do Kubernetes do mesmo espaço de nomes noutros clusters na mesma frota também recebe a mesma política de IAM.

   Esta associação permite que a conta de serviço do Kubernetes do Config Sync atue como a conta de serviço Google:

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

Substitua o seguinte:

• PROJECT_ID: o ID do projeto da organização.
• FLEET_HOST_PROJECT_ID: se estiver a usar a Workload Identity Federation do GKE para o GKE, é o mesmo que PROJECT_ID. Se estiver a usar a Workload Identity Federation para o GKE, este é o ID do projeto da frota no qual o seu cluster está registado.
• GSA_NAME: a conta de serviço Google personalizada que quer usar para se ligar ao Artifact Registry. A conta de serviço tem de ter a função de IAM Leitor do Artifact Registry (roles/artifactregistry.reader).
• KSA_NAME: a conta de serviço do Kubernetes para o reconciliador.
  • Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME. Se instalar o Config Sync através da Google Cloud consola ou da CLI do Google Cloud, o Config Sync cria automaticamente um objeto RootSync denominado root-sync.
• REPOSITORY: o nome do repositório.
• POLICY_FILE: o ficheiro JSON ou YAML com a política de gestão de identidades e acessos.

Nota: a criação desta associação de políticas requer a autorização iam.serviceAccounts.setIamPolicy.

Conta de serviço predefinida do Compute Engine

Se o seu repositório estiver no Cloud Source Repositories, e o seu cluster for o GKE com a Workload Identity Federation para o GKE desativada, pode usar gcenode como tipo de autenticação.

Se configurar a sincronização de configuração através da Google Cloud consola, selecione repositório do Google Cloud como o tipo de autenticação.

Se configurar o Config Sync através da Google Cloud CLI, adicione gcenode como secretType.

Se selecionar Repositório do Google Cloud ou gcenode, pode usar a conta de serviço predefinida do Compute Engine. Tem de conceder a função de IAM Leitor dos repositórios de origem da nuvem (roles/source.reader) à conta de serviço predefinida do Compute Engine. Para mais informações sobre as funções e as autorizações dos Cloud Source Repositories, consulte o artigo Conceda autorizações para ver repositórios.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:[e-mail]"

Substitua PROJECT_ID pelo ID do projeto da sua organização e substitua PROJECT_NUMBER pelo número do projeto da sua organização.

App GitHub

Se o seu repositório estiver no GitHub, pode usar githubapp como tipo de autenticação.

Para usar uma app GitHub, conclua os seguintes passos:

1. Siga as instruções no GitHub para aprovisionar uma app GitHub e conceder-lhe autorização para ler a partir do seu repositório.

2. Adicione a configuração da app GitHub a um novo segredo no cluster:

   Usar o ID de cliente

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Substitua CLIENT_ID pelo ID de cliente da app GitHub.
   • Substitua INSTALLATION_ID pelo ID de instalação da app GitHub.
   • Substitua /path/to/GITHUB_PRIVATE_KEY pelo nome do ficheiro que contém a chave privada.
   • Substitua BASE_URL pelo URL base do ponto final da API GitHub. Isto só é necessário quando o repositório não está alojado em www.github.com. Caso contrário, o argumento pode ser omitido e é predefinido como https://api.github.com/.

   Usar o ID da aplicação

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Substitua APPLICATION_ID pelo ID da aplicação para a app GitHub.
   • Substitua INSTALLATION_ID pelo ID de instalação da app GitHub.
   • Substitua /path/to/GITHUB_PRIVATE_KEY pelo nome do ficheiro que contém a chave privada.
   • Substitua BASE_URL pelo URL base do ponto final da API GitHub. Isto só é necessário quando o repositório não está alojado em www.github.com. Caso contrário, o argumento pode ser omitido e é predefinido como https://api.github.com/.

3. Elimine a chave privada do disco local ou proteja-a de outra forma.

4. Quando configurar a sincronização de configuração e adicionar o URL do seu repositório Git, use o tipo de autenticação githubapp.

Conceda acesso só de leitura do Config Sync ao OCI

O Config Sync precisa de acesso só de leitura à sua imagem OCI armazenada no Artifact Registry para poder ler as configurações incluídas na imagem e aplicá-las aos seus clusters.

Se a sua imagem não exigir autenticação para acesso só de leitura, pode continuar a configurar a sincronização de configuração e usar none como tipo de autenticação. Por exemplo, se a sua imagem for pública e qualquer pessoa na Internet puder aceder à mesma, não precisa de autenticar.

No entanto, a maioria dos utilizadores tem de criar credenciais para aceder a imagens restritas. A sincronização de configurações suporta os seguintes mecanismos de autenticação:

• Conta de serviço do Kubernetes (k8sserviceaccount)
• Conta de serviço Google (gcpserviceaccount)

• Conta de serviço predefinida do Compute Engine (gcenode)

Conta de serviço do Kubernetes

Pode usar uma conta de serviço do Kubernetes como tipo de autenticação se armazenar a sua imagem OCI no Artifact Registry e o seu cluster usar a federação de identidades da carga de trabalho do GKE para o GKE ou a federação de identidades da carga de trabalho da frota para o GKE.

1. Conceda a função de IAM Artifact Registry Reader (roles/artifactregistry.reader) à conta de serviço do Kubernetes com a federação de identidades da carga de trabalho para o pool do GKE. Para mais informações sobre as funções e as autorizações do Artifact Registry, consulte o artigo Configure funções e autorizações para o Artifact Registry.

   • Conceda autorização ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

     gcloud projects add-iam-policy-binding PROJECT_ID \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • Conceda autorização específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no seu projeto.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   Substitua o seguinte:

   • PROJECT_ID: o ID do projeto da organização.
   • FLEET_HOST_PROJECT_ID: se estiver a usar a Workload Identity Federation do GKE para o GKE, é o mesmo que PROJECT_ID. Se estiver a usar a Workload Identity Federation para o GKE, este é o ID do projeto da frota no qual o seu cluster está registado.
   • KSA_NAME: a conta de serviço do Kubernetes para o reconciliador.
     • Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME. Se instalar o Config Sync através da Google Cloud consola ou da CLI do Google Cloud, o Config Sync cria automaticamente um objeto RootSync denominado root-sync.
   • REPOSITORY: o ID do repositório.
   • LOCATION: a localização regional ou multirregional do repositório.
   Nota: a criação desta associação de políticas requer a autorização iam.serviceAccounts.setIamPolicy.

Conta de serviço predefinida do Compute Engine

Se armazenar o seu gráfico Helm no Artifact Registry e o seu cluster for GKE com a Workload Identity Federation para GKE desativada, pode usar gcenode como o seu tipo de autenticação. O Config Sync usa a conta de serviço predefinida do Compute Engine. Tem de conceder à sua conta de serviço predefinida do Compute Engine acesso de leitor ao Artifact Registry.

1. Conceda à conta de serviço do Compute Engine autorização de leitura ao Artifact Registry executando o seguinte comando:

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:[e-mail] \
      --role=roles/artifactregistry.reader
   

   Substitua PROJECT_ID pelo ID do projeto da sua organização e substitua PROJECT_NUMBER pelo número do projeto da sua organização.

Configure o Config Sync para uma autoridade de certificação

Para servidores configurados com certificados de uma autoridade de certificação (AC) que ainda não seja fidedigna, o Config Sync pode ser configurado para usar um certificado da AC para validar as ligações HTTPS ao servidor. Isto é suportado para servidores Git, Helm ou OCI. O certificado da AC tem de incluir certificados SSL completos (raiz/intermédio/folha). Se o seu servidor já estiver a usar uma AC fidedigna ou não estiver a estabelecer ligação através de HTTPS, pode ignorar este passo e deixar caCertSecretRef não definido.

RootSync

1. Obtenha o certificado da CA que foi usado para emitir o certificado para o seu servidor Git e guarde-o num ficheiro.

2. Para objetos RootSync, o Secret tem de ser criado no espaço de nomes config-management-system. Por exemplo:

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Quando configura a sincronização de configuração, defina o valor do campo caCertSecretRef.name no objeto RootSync como ROOT_CA_CERT_SECRET_NAME.

RepoSync

1. Obtenha o certificado da CA que foi usado para emitir o certificado para o seu servidor Git e guarde-o num ficheiro.

2. Para objetos RepoSync, o segredo tem de ser criado no mesmo espaço de nomes que o RepoSync. Por exemplo:

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Quando configurar o RepoSync, defina o valor do campo caCertSecretRef.name no objeto RepoSync como NAMESPACE_CA_CERT_SECRET_NAME.

Conceda acesso só de leitura da Config Sync ao Helm

O Config Sync precisa de acesso só de leitura ao seu repositório Helm para poder ler os gráficos Helm no seu repositório e instalá-los nos seus clusters.

Se o seu repositório não exigir autenticação para acesso só de leitura, pode continuar a configurar a sincronização de configuração e usar none como tipo de autenticação. Por exemplo, se o seu repositório Helm for público e qualquer pessoa na Internet puder aceder ao mesmo, não precisa de autenticar.

No entanto, a maioria dos utilizadores tem de criar credenciais para aceder a repositórios Helm privados. A sincronização de configurações suporta os seguintes mecanismos de autenticação:

• Token (token)
• Conta de serviço do Kubernetes (k8sserviceaccount)
• Conta de serviço Google (gcpserviceaccount)
• Conta de serviço predefinida do Compute Engine (gcenode)

Nota: o Config Sync não suporta a configuração de helm como o tipo de origem através da Google Cloud consola ou da CLI do Google Cloud. Pode configurar o objeto RootSync ou RepoSync para sincronizar a partir de um repositório Helm através da API Kubernetes ou declará-lo noutra fonte de verdade. Consulte a secção Configuração do repositório Helm para mais informações.

Símbolo

Crie um Secret com um nome de utilizador e uma palavra-passe do repositório Helm:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

Substitua o seguinte:

• SECRET_NAME: o nome que quer dar ao seu segredo.
• USERNAME: o nome de utilizador do repositório Helm.
• PASSWORD: a palavra-passe do repositório Helm.

Quando configurar a sincronização de configuração, vai usar o nome do segredo que escolheu para spec.helm.secretRef.name.

Conta de serviço do Kubernetes

Pode usar uma conta de serviço do Kubernetes como tipo de autenticação se armazenar o seu gráfico Helm no Artifact Registry e o seu cluster usar a federação de identidades da carga de trabalho do GKE para o GKE ou a federação de identidades da carga de trabalho da frota para o GKE.

1. Conceda a função de IAM Artifact Registry Reader (roles/artifactregistry.reader) à conta de serviço do Kubernetes com a federação de identidades da carga de trabalho para o pool do GKE. Para mais informações sobre as funções e as autorizações do Artifact Registry, consulte o artigo Configure funções e autorizações para o Artifact Registry.

   • Conceda autorização ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

     gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • Conceda autorização específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no seu projeto.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   Substitua o seguinte:

   • PROJECT_ID: o ID do projeto da organização.
   • FLEET_HOST_PROJECT_ID: se estiver a usar a Workload Identity Federation do GKE para o GKE, é o mesmo que PROJECT_ID. Se estiver a usar a Workload Identity Federation para o GKE, este é o ID do projeto da frota no qual o seu cluster está registado.
   • KSA_NAME: a conta de serviço do Kubernetes para o reconciliador.
     • Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME.
   • REPOSITORY: o ID do repositório.
   • LOCATION: a localização regional ou multirregional do repositório.

Nota: a criação desta associação de políticas requer a autorização iam.serviceAccounts.setIamPolicy.

Conta de serviço predefinida do Compute Engine

Se armazenar o seu gráfico Helm no Artifact Registry e o seu cluster for GKE com a Workload Identity Federation para GKE desativada, pode usar gcenode como o seu tipo de autenticação. O Config Sync usa a conta de serviço predefinida do Compute Engine. Tem de conceder à sua conta de serviço predefinida do Compute Engine acesso de leitor ao Artifact Registry. Pode ter de conceder o âmbito de storage-ro acesso para conceder autorização de leitura para obter imagens.

1. Conceda à conta de serviço do Compute Engine autorização de leitura ao Artifact Registry:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:[e-mail] \
       --role=roles/artifactregistry.reader
   

   Substitua PROJECT_ID pelo ID do projeto da sua organização e substitua PROJECT_NUMBER pelo número do projeto da sua organização.

Configure o Config Sync

Para configurar a sincronização a partir do repositório raiz, tem de criar um objeto RootSync que sincronize o repositório raiz com o cluster. Só pode criar um repositório raiz por cluster, e o repositório raiz pode ser um repositório não estruturado ou um repositório hierárquico.

1. Se estiver a usar o webhook de admissão do Config Sync (o webhook de admissão está desativado por predefinição) e a instalar o Config Sync num cluster privado, adicione uma regra de firewall para permitir a porta 10250. O webhook de admissão do Config Sync usa a porta 10250 para a prevenção de desvios.

2. Aguarde até que os CRDs RootSync e RepoSync estejam disponíveis:

   until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
   

3. 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 de leitura apenas ao Git para a sincronização de configuração.

     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 segredo 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

   Aviso: o Config Sync requer que a camada OCI esteja comprimida no formato tar ou tar+gzip. Outros formatos (por exemplo, tar+bz2) não são reconhecidos pelo Config Sync. A mudança de um REPO válido para uma imagem OCI com um formato não suportado faz com que os recursos geridos sejam removidos sem um erro.

   • 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 segredo 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 um 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 segredo 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.

4. Aplique as alterações:

   kubectl apply -f root-sync.yaml
   

Valide o estado de sincronização do repositório raiz

Pode usar o comando nomos status para inspecionar o estado de sincronização do repositório raiz:

nomos status

Deverá ver uma saída semelhante ao seguinte exemplo:

my_managed_cluster-1
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4

Valide a instalação do RootSync

Quando cria um objeto RootSync, o Config Sync cria um reconciliador com o prefixo root-reconciler. Um reconciliador é um pod implementado como uma implementação. Sincroniza manifestos de um repositório Git para um cluster.

Pode verificar se o objeto RootSync está a funcionar corretamente verificando o estado da implementação do reconciliador de raiz:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Substitua ROOT_SYNC_NAME pelo nome do RootSync.

Deverá ver uma saída semelhante ao seguinte exemplo:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Para outras formas de explorar o estado do seu objeto RootSync, consulte o artigo Monitorizar objetos RootSync e RepoSync.

Depois de terminar a configuração do repositório raiz, pode optar por configurar a sincronização a partir de vários repositórios. Estes repositórios são úteis se quiser um repositório que contenha configurações com âmbito de espaço de nomes sincronizadas com um espaço de nomes específico em vários clusters.

Atualize o Config Sync

Os passos para atualizar o Config Sync dependem da versão para a qual está a fazer a atualização e da versão a partir da qual está a fazer a atualização. A partir da versão 1.20.0, o Config Sync é fornecido como uma instalação autónoma sem o operador ConfigManagement. Se estiver a atualizar a partir de uma versão anterior a 1.20.0 para a versão 1.20.0 ou posterior, tem de desinstalar primeiro o operador ConfigManagement antes de fazer a atualização.

Se estiver a atualizar a partir de uma versão não suportada, deve fazer uma atualização passo a passo com incrementos de, no máximo, três versões secundárias de cada vez. Por exemplo, se a versão atual do Config Sync for 1.14.0, atualize primeiro para a versão 1.17.0 e, em seguida, para a versão 1.20.0.

Desinstale o operador ConfigManagement

Se estiver a atualizar de uma versão anterior à 1.20.0 para a versão 1.20.0 ou posterior, tem de desinstalar primeiro o operador ConfigManagement antes de fazer a atualização.

Pode verificar se a gestão de configuração está instalada no seu cluster executando o seguinte comando:

kubectl get configmanagement

Se o resultado não estiver vazio, a gestão de configuração está instalada no cluster. Para desinstalar a gestão da configuração, conclua os passos seguintes para desinstalar a gestão da configuração, mas deixe o Config Sync instalado no cluster. Recomendamos que use o nomos CLI para desinstalar o operador ConfigManagement, uma vez que tem uma interface mais completa e um processamento de erros mais robusto. Só deve usar o script de shell se não tiver acesso ao nomos CLI.

Aviso: certifique-se de que o controlador de hierarquia está desativado antes de continuar.

nomos (recomendado)

1. Certifique-se de que a CLI nomos tem a versão mais recente.

2. Execute o seguinte comando para atualizar o cluster no seu contexto kubectl atual:

   nomos migrate --remove-configmanagement
   

script shell

Copie o seguinte script de shell para um ficheiro e, em seguida, execute-o para atualizar o cluster no seu contexto kubectl atual.

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

Instale a nova versão do Config Sync

Para atualizar o Config Sync, conclua os passos seguintes para cada cluster inscrito:

1. Transfira o manifesto do Config Sync e os comandos nomos para a nova versão.

2. Extraia o arquivo:

   tar -xzvf config-sync.tar.gz

3. No arquivo que extraiu no passo anterior, siga as instruções no ficheiro README.md fornecido para editar a personalização.

   Nota: a edição do kustomization.yaml é necessária para algumas definições, por exemplo, definir um nome de cluster para utilização com um ClusterSelector ou incluir o ficheiro admission-webhook.yaml para utilização com a prevenção de desvio.

4. Para atualizar a instalação do Config Sync, aplique o manifesto renderizado que criou seguindo as README.md instruções:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Substitua CONFIG_SYNC_MANIFEST pelo nome do manifesto renderizado.

5. Substitua o comando nomos em todos os clientes pela nova versão. Esta alteração garante que o comando nomos pode sempre obter o estado de todos os clusters inscritos e validar as configurações dos mesmos.

Desinstale o Config Sync

Aviso: a eliminação de um objeto RootSync ou RepoSync não limpa as anotações e as etiquetas do Config Sync, e o webhook de admissão do Config Sync nega os pedidos que tentam eliminar estes recursos se o Config Sync ainda estiver ativado no cluster. A solução alternativa consiste em anular a gestão ou eliminar estes recursos geridos antes de eliminar o objeto RootSync ou RepoSync correspondente.

Para desinstalar o Config Sync, conclua os seguintes passos:

1. Um administrador central deve remover o repositório raiz:

   1. Se ativou o webhook e quer manter os seus recursos, desative a prevenção de desvio para recursos abandonados. Se não ativou o webhook, não tem de realizar passos adicionais para manter os seus recursos.

   2. Elimine o objeto RootSync executando o seguinte comando:

      kubectl delete -f root-sync.yaml
      

2. Remova todos os repositórios.

3. Com os manifestos que usou para instalar o Config Sync, também pode desinstalá-lo.

      kubectl delete -f CONFIG_SYNC_MANIFEST --ignore-not-found
   

Nota: a desativação desta funcionalidade não afeta as configurações que o Config Sync aplicou anteriormente aos seus clusters.

O que se segue?

• Descubra como configurar a sincronização a partir de vários repositórios.