Faça a gestão dos objetos de cluster existentes

Quando o Config Sync gere um objeto de cluster, monitoriza o objeto e o conjunto de configurações no repositório que afetam o objeto e garante que estão sincronizados. Este tópico descreve como começar a gerir um objeto existente e como parar de gerir um objeto que está atualmente a ser gerido sem o eliminar.

Um objeto num cluster é gerido pela sincronização de configuração se tiver a anotação configmanagement.gke.io/managed: enabled e a anotação configsync.gke.io/resource-id, que acompanha as informações do grupo, tipo, espaço de nomes e nome do objeto, estiver correta.

O formato da anotação configsync.gke.io/resource-id é GROUP_KIND_NAMESPACE_NAME para um objeto com âmbito de espaço de nomes e GROUP_KIND_NAME para um objeto com âmbito de cluster.

O fluxograma seguinte descreve algumas situações que fazem com que um objeto se torne gerido ou não gerido:

O diagrama contém três fluxos separados: 1) começar a gerir um objeto, 2) parar de gerir um objeto e 3) eliminar um objeto gerido.

1. Quero começar a gerir um objeto. O objeto tem um manifesto? Por outras palavras, o objeto tem uma configuração no repositório?
   • Não: crie uma configuração para o objeto. O Config Sync define a anotação configmanagement.gke.io/managed: enabled, define a anotação configsync.gke.io/resource-id para corresponder ao objeto e começa a gerir o objeto.
   • Sim: a configuração define a seguinte anotação? configmanagement.gke.io/managed: disabled
     • Não: o objeto é gerido por predefinição.
     • Sim: edite a configuração para remover a anotação configmanagement.gke.io/managed: disabled. Quando a alteração é enviada para o repositório de origem, o Config Sync repara na alteração, aplica a anotação configmanagement.gke.io/managed: enabled e a anotação configsync.gke.io/resource-id e aplica a configuração.
2. Quero parar de gerir um objeto, mas não o eliminar.
   • Edite a configuração do objeto no repositório e defina a anotação configmanagement.gke.io/managed: disabled. Quando a alteração de configuração é detetada, o Config Sync deixa de gerir o objeto.
3. Quero parar de gerir um objeto e eliminá-lo.
   • Elimine a configuração do objeto do repositório. Quando elimina uma configuração para um objeto gerido anteriormente, o Config Sync elimina o objeto de todos os clusters ou espaços de nomes aos quais a configuração se aplica.

Além da anotação configmanagement.gke.io/managed: enabled e da anotação configsync.gke.io/resource-id, a sincronização de configuração aplica a etiqueta app.kubernetes.io/managed-by: configmanagement.gke.io a todos os objetos que gere. Esta etiqueta permite-lhe listar facilmente todos os objetos por Config Sync.

Porque não aplicar a anotação manualmente?

O Config Sync usa um modelo declarativo para aplicar alterações de configuração aos seus clusters lendo a configuração pretendida do seu repositório. Se tentar aplicar a anotação manualmente (através do comando kubectl ou da API Kubernetes), o Config Sync substitui automaticamente a anotação manual pelo conteúdo do seu repositório.

Antes de começar

Os exemplos seguintes baseiam-se no artigo Comece a usar o Config Sync. Antes de iniciar os passos seguintes, siga o início rápido e conclua todos os passos antes de Explorar e testar a instalação do Config Sync.

Apresentar todos os objetos geridos

Para apresentar uma lista de todos os objetos geridos pela sincronização de configuração num determinado cluster ou espaço de nomes, use um seletor de etiquetas como o seguinte:

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

Para apresentar uma lista de todos os objetos não geridos pela sincronização de configuração, use um seletor de etiquetas da seguinte forma:

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

Por exemplo, este comando lista RoleBindings no espaço de nomes gamestore que são geridos pela sincronização de configuração:

kubectl get rolebindings -n gamestore \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

O resultado é semelhante ao seguinte:

NAME                              ROLE                                          AGE
configsync.gke.io:ns-reconciler   ClusterRole/configsync.gke.io:ns-reconciler   34h
gamestore-admin                   ClusterRole/admin                             34h
gamestore-webstore-admin          ClusterRole/webstore-admin                    34h

Este comando lista RoleBindings no espaço de nomes kube-system que não são geridos pela sincronização de configuração:

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

O resultado é semelhante ao seguinte:

NAME                                             AGE
fluentd-gcp-scaler-binding                       2d21h
gce:cloud-provider                               2d21h
heapster-binding                                 2d21h
metrics-server-auth-reader                       2d21h
system::leader-locking-kube-controller-manager   2d21h
system::leader-locking-kube-scheduler            2d21h
system:controller:bootstrap-signer               2d21h
system:controller:cloud-provider                 2d21h
system:controller:token-cleaner                  2d21h

Comece a gerir um objeto existente

Pode criar uma configuração para um objeto Kubernetes existente, como um espaço de nomes, que já exista no seu cluster antes de instalar o Config Sync. No entanto, esta configuração é ignorada, a menos que o objeto tenha a anotação configmanagement.gke.io/managed: enabled e a anotação configsync.gke.io/resource-id correta. Para um objeto existente, tem de aplicar a anotação manualmente.

Especificamente para os espaços de nomes, o Config Sync aplica configurações que criam novos objetos num espaço de nomes não anotado e aplica as anotações configmanagement.gke.io/managed: enabled e configsync.gke.io/resource-id a esses objetos. No entanto, o Config Sync recusa-se a modificar ou remover qualquer objeto com âmbito de cluster não anotado de um cluster. Isto é ilustrado no diagrama em Trabalhar com configurações ao longo do tempo.

O exemplo seguinte demonstra como gerir um objeto Role existente. Primeiro, crie uma função manualmente e, em seguida, comece a geri-la com o Config Sync.

1. Crie a função myrole no espaço de nomes gamestore:

   kubectl create role -n gamestore myrole --verb=get --resource=pods

2. Veja as autorizações concedidas pela função myrole:

   kubectl describe role -n gamestore myrole

   Name:         myrole
   Labels:       <none>
   Annotations:  <none>
   PolicyRule:
     Resources  Non-Resource URLs  Resource Names  Verbs
     ---------  -----------------  --------------  -----
     pods       []                 []              [get]
   

   A função só tem autorização para get pods.

3. Neste ponto, a função existe no cluster, mas o Config Sync não a conhece.

   1. Num terminal, aceda ao clone local do seu repositório.

   2. Use o comando seguinte para criar um manifesto YAML para myrole e guardar o manifesto num novo ficheiro denominado gamestore-myrole.yaml.

      kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
      

   3. Edite o ficheiro gamestore-myrole.yaml.

      1. Remova todos os campos na chave metadata, exceto name e namespace.
      2. Adicione o verbo list depois de get no campo da lista rules.verbs.

      Guarde as alterações. O ficheiro resultante tem o seguinte conteúdo:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: myrole
        namespace: gamestore
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      

   4. Consolide a alteração no repositório.

   5. Aguarde alguns momentos para que o operador ConfigManagement repare na confirmação. Para verificar se a função myrole é agora gerida pelo Config Sync, execute kubectl describe novamente.

      kubectl describe role myrole -n gamestore
      

Repare na anotação configmanagement.gke.io/managed: enabled, que indica que o objeto é gerido pela sincronização de configuração, e na anotação configsync.gke.io/resource-id, que acompanha as informações do grupo, do tipo, do espaço de nomes e do nome. Repare também nas anotações que mostram o caminho e o nome do ficheiro no repositório que causou a alteração de configuração mais recente ao objeto, e o hash Git que representa a confirmação.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

Deixe de gerir um objeto gerido

Este exemplo mostra como parar de gerir um objeto que o Config Sync está a gerir atualmente, como a função em myroleComeçar a gerir um objeto existente.

Nota: antes de remover um espaço de nomes da gestão, certifique-se de que compreende o que acontece aos objetos nesse espaço de nomes que ainda são geridos.

1. Edite o ficheiro no clone local do seu repositório e adicione uma secção annotations: que corresponda ao texto a negrito abaixo:config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      annotations:
        configmanagement.gke.io/managed: disabled
      name: gamestore-webstore-admin
      namespace: gamestore
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-gamestore
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: webstore-admin
      apiGroup: rbac.authorization.k8s.io
   

   Guarde o ficheiro.

2. Crie uma confirmação do Git com as suas alterações e envie a confirmação para o seu repositório.

3. Aguarde alguns momentos para que o Config Sync detete e aplique a nova confirmação.

4. Use o seguinte comando para validar se as anotações e as etiquetas do gamestore-webstore-admin RoleBinding estão vazias. O Config Sync não define a anotação configmanagement.gke.io/managed como disabled no objeto.

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml
   

   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     annotations:
     name: gamestore-webstore-admin
     namespace: gamestore
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-gamestore
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: webstore-admin
     apiGroup: rbac.authorization.k8s.io
   

Depois de verificar que o objeto está agora desativado, pode remover a configuração do repositório e verificar se o objeto agora não gerido não é eliminado do espaço de nomes. Se quiser gerir novamente o objeto, tem de adicionar novamente a respetiva configuração ao repositório. Por este motivo, é recomendável anular a gestão dos objetos e deixar as respetivas configurações no repositório.

Agora que o objeto não é gerido, não é criado nem recriado em clusters novos ou existentes, e não é removido, mesmo que exista. Para retomar a gestão de um objeto que deixou de gerir anteriormente, consulte o exemplo seguinte, Retomar a gestão de um objeto anteriormente não gerido.

Retome a gestão de um objeto anteriormente não gerido

Este exemplo mostra como retomar a gestão de um objeto que removeu anteriormente da gestão, como em Pare de gerir um objeto existente. Assume que não removeu a configuração para o RoleBinding gamestore-webstore-admin.

1. Se eliminou o gamestore-webstore-admin RoleBinding do seu repositório no último commit, siga estes passos.

   1. Use git revert para reverter a última confirmação:

      git revert HEAD~1
      

      É-lhe pedido que confirme a operação de reversão.

   2. Envie a reversão da confirmação para o seu repositório.

      git push
      

2. Edite o ficheiro config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml no clone local do seu repositório e remova a anotação configmanagement.gke.io/managed: disabled. Guarde o ficheiro.

3. Confirme e envie a alteração. O Config Sync faz o seguinte:

   • Repara na alteração
   • Aplica a anotação configmanagement.gke.io/managed: enabled e a anotação configsync.gke.io/resource-id; o objeto é agora gerido.
   • Aplica a configuração, como aconteceria com qualquer objeto gerido.

4. Para verificar se o objeto é agora gerido, liste as respetivas anotações:

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     annotations:
       configmanagement.gke.io/cluster-name: my-cluster
       configmanagement.gke.io/managed: enabled
       configsync.gke.io/resource-id: rbac.authorization.k8s.io_rolebinding_gamestore_gamestore-webstore-admin
   ...
   

Pare de gerir um espaço de nomes

Pode parar de gerir um espaço de nomes da mesma forma que para de gerir qualquer tipo de objeto. Se quiser parar de gerir outros recursos no espaço de nomes, siga estes passos:

1. Adicione a anotação configmanagement.gke.io/managed:disabled à configuração do espaço de nomes e a todas as configurações no mesmo espaço de nomes. Todos os objetos no espaço de nomes têm de ter esta anotação.

   Aviso: numa origem de dados hierárquica, se o espaço de nomes for herdado de um espaço de nomes abstrato, não pode ser não gerido.

2. Confirme e envie as alterações para o repositório. Aguarde que o operador sincronize com o repositório.

3. Elimine os recursos não geridos do repositório.

   Aviso: é um problema conhecido que, se não estiver a usar as APIs RootSync e RepoSync, a eliminação do espaço de nomes não gerido do repositório faz com que o espaço de nomes seja eliminado do cluster publicado. Para os recursos não geridos que são eliminados acidentalmente, tem de os adicionar novamente manualmente no cluster, por exemplo, através de kubectl apply. Para usar as APIs RootSync e RepoSync, tem de migrar o seu objeto ConfigManagement.

Se existirem configurações para configurações geridas num diretório de espaço de nomes não gerido, o reconciliador regista erros, mas outras configurações continuam a ser sincronizadas normalmente.

Elimine recursos geridos

Quando remove um recurso individual de uma fonte de verdade, esse objeto é eliminado do cluster quando o Config Sync sincroniza novamente a partir da fonte de verdade. Em alternativa, pode ativar a propagação da eliminação, que lhe permite eliminar objetos em massa.

Elimine objetos individuais

Com o comportamento predefinido do Config Sync, quando remove um objeto de uma fonte de verdade, esse objeto é eliminado do cluster quando o Config Sync é sincronizado a partir da fonte de verdade.

Existem várias formas de verificar o estado da sincronização de configuração ou o estado de objetos específicos:

• Use nomos status.
• Use kubectl para examinar os recursos.
• Use o painel de controlo do Config Sync.

Elimine objetos em massa

Pré-visualização

Este produto ou funcionalidade está sujeito aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. Os produtos e as funcionalidades pré-GA estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Por predefinição, a eliminação de um RootSync ou um RepoSync faz com que o Config Sync abandone os objetos que foram aplicados anteriormente a partir da fonte de verdade. Em alternativa, pode ativar a propagação da eliminação para eliminar todos os objetos aplicados anteriormente.

Quando ativa a propagação da eliminação num objeto RootSync ou RepoSync e, em seguida, elimina esse objeto, o Config Sync elimina automaticamente todos os objetos que foram geridos por esse RootSync ou RepoSync.

A propagação da eliminação pode ajudar a simplificar a limpeza de recursos, por exemplo, se estiver a migrar para um novo espaço de nomes ou cluster, a limpar após uma demonstração ou um experimento, ou a desinstalar uma aplicação.

Opções de propagação da eliminação

A propagação da eliminação está desativada por predefinição. Para ativar a propagação da eliminação, adicione a anotação configsync.gke.io/deletion-propagation-policy: Foreground ao objeto RootSync ou RepoSync, como no exemplo seguinte:

# example-rootsync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: example-rootsync
  namespace: config-management-system
  annotations:
    configsync.gke.io/deletion-propagation-policy: Foreground
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: main
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

Em alternativa, pode atualizar um RootSync ou um RepoSync existente para usar a propagação da eliminação executando o seguinte comando:

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

Substitua ROOTSYNC_NAME pelo nome do RootSync que quer atualizar.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

Substitua REPOSYNC_NAME pelo nome do RepoSync que quer atualizar.

Para desativar a propagação da eliminação, remova a anotação ou altere o valor para configsync.gke.io/deletion-propagation-policy: Orphan:

Nota: a partir da versão 1.21.0, o Config Sync deixa de gerir todos os objetos quando usa a política de propagação de eliminação Orphan. Antes da versão 1.21.0, o Config Sync anotava os objetos como sendo geridos pelo objeto RootSync ou RepoSync eliminado. O novo comportamento garante que os objetos órfãos podem ser atualizados por outros clientes ou adotados por um novo objeto RootSync ou RepoSync.

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

Substitua ROOTSYNC_NAME pelo nome do RootSync que quer atualizar.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

Propague a eliminação de objetos

Este exemplo mostra como aplicar a propagação da eliminação a um objeto RootSync ou RepoSync e, em seguida, eliminar o RootSync ou o RepoSync para eliminar todos os objetos que foram geridos pelo RootSync ou pelo RepoSync.

Aviso: para objetos RepoSync, não elimine o espaço de nomes em que o RepoSync se encontra antes de o RepoSync terminar a eliminação. Se o fizer, o RoleBinding pode ser eliminado antes da conclusão da propagação da eliminação, o que provoca um impasse que pode bloquear a eliminação do RepoSync e do espaço de nomes.

RootSync

1. Aplique a anotação a um objeto RootSync para ativar a propagação da eliminação:

   kubectl patch RootSync example-rootsync \
     --namespace config-management-system \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. Elimine o objeto RootSync e aguarde que o Config Sync o elimine:

   kubectl delete RootSync example-rootsync --namespace config-management-system --wait
   

   A eliminação do RootSync pode demorar alguns minutos.

RepoSync

1. Aplique a anotação a um objeto RepoSync para ativar a propagação da eliminação:

   kubectl patch RepoSync example-reposync \
     --namespace example-namespace \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. Elimine o objeto RepoSync e aguarde que o Config Sync o elimine:

   kubectl delete RepoSync example-reposync --namespace example-namespace --wait
   

   A eliminação do RepoSync pode demorar alguns minutos.

Impeça a eliminação de objetos do Kubernetes

Depois de remover um objeto Kubernetes de um repositório Git gerido pelo Config Sync, este objeto também é eliminado do cluster quando a nova confirmação é sincronizada com o cluster.

Se quiser impedir que o Config Sync elimine o objeto quando a respetiva configuração for removida do repositório Git, pode seguir estes passos:

1. Adicione a anotação client.lifecycle.config.k8s.io/deletion: detach à configuração do objeto no repositório Git.

2. Consolide e envie a alteração no repositório Git.

3. Aguarde até que a alteração seja sincronizada com o cluster.

Depois de concluir estes passos, o Config Sync não elimina este objeto do cluster quando a respetiva configuração é removida do repositório Git, mas continua a poder ser eliminado por outros clientes.

Ignore um objeto na fonte de informação fidedigna

Pode querer que o Config Sync ignore um objeto na sua fonte de verdade. Por exemplo, uma configuração de função kpt nunca deve ser aplicada ao cluster.

Para objetos que quer que o Config Sync ignore, adicione a anotação config.kubernetes.io/local-config: "true" ao objeto. Depois de adicionar esta anotação, o Config Sync ignora este objeto como se tivesse sido removido da fonte de verdade. Os recursos com a anotação local-config definida para qualquer valor que não seja "false" são tratados como se estivesse definida para "true" e são ignorados.