Gerenciar objetos de cluster atuais

Quando o Config Sync gerencia um objeto de cluster, ele observa o objeto e o conjunto de configurações que afetam o objeto no repositório e garante que eles estejam em sincronia. Neste tópico, você verá como começar a gerenciar um objeto atual e como parar de gerenciar um objeto sem o excluir.

Um objeto em um cluster será gerenciado pelo Config Sync se tiver a anotação configmanagement.gke.io/managed: enabled e a anotação configsync.gke.io/resource-id, que rastreia as informações de grupo, tipo, namespace e nome de o objeto está correto.

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

O fluxograma a seguir descreve algumas situações que fazem com que um objeto seja gerenciado ou não:

O gráfico contém três fluxos separados: 1) começar a gerenciar um objeto, 2) parar de gerenciar um objeto e 3) excluir um objeto gerenciado.

1. Quero começar a gerenciar um objeto. O objeto tem um manifesto? Em outras palavras, o objeto tem uma configuração no repositório?
   • Não: crie um config 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 gerenciá-lo.
   • Sim: a configuração define a anotação a seguir? configmanagement.gke.io/managed: disabled
     • Não: o objeto é gerenciado por padrão.
     • Sim: edite o config para remover a anotação configmanagement.gke.io/managed: disabled. Quando a alteração é enviada ao repositório de origem, o Config Sync percebe a 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 gerenciar um objeto, mas não excluí-lo.
   • Edite a configuração do objeto no repositório e defina a anotação configmanagement.gke.io/managed: disabled. Quando a alteração da configuração é detectada, o Config Sync deixa de gerenciar o objeto.
3. Quero parar de gerenciar um objeto e excluí-lo.
   • Exclua a configuração do objeto do repositório. Quando você exclui uma configuração de um objeto gerenciado anteriormente, o Config Sync exclui o objeto de todos os clusters ou namespaces a que a configuração se aplica.

Além das anotações configmanagement.gke.io/managed: enabled e configsync.gke.io/resource-id, o Config Sync aplica o rótulo app.kubernetes.io/managed-by: configmanagement.gke.io a todos os objetos gerenciados por ele. Esse rótulo permite que você liste todos os objetos com facilidade por Config Sync.

Por que não aplicar a anotação manualmente?

O Config Sync usa um modelo declarativo para aplicar alterações de configuração aos clusters lendo a configuração pretendida no seu repositório. Se você tentar aplicar a anotação manualmente (usando o comando kubectl ou a API Kubernetes), o Config Sync substituirá o manual automaticamente pelo conteúdo do seu repositório.

Antes de começar

Os exemplos a seguir se baseiam nos Primeiros passos com o Config Sync. Antes de seguir adiante, siga o guia de início rápido e conclua todas as etapas antes de Explorar e testar a instalação do Config Sync.

Listar todos os objetos gerenciados

Para listar todos os objetos gerenciados pelo Config Sync em um determinado cluster ou namespace, use um seletor de rótulo como este:

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

Para listar todos os objetos não gerenciados pelo Config Sync, use um seletor de rótulos como este:

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

Por exemplo, este comando lista RoleBindings no namespace gamestore que são gerenciados pelo Config Sync:

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

A saída será assim:

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 namespace kube-system que não são gerenciados pelo Config Sync:

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

A saída será assim:

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

Começar a gerenciar um objeto atual

É possível criar uma configuração de um objeto atual do Kubernetes, como um namespace que já existia no cluster antes de instalar o Config Sync. No entanto, essa configuração será 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. Em um objeto atual, você precisa aplicar a anotação manualmente.

No caso específico dos namespaces, o Config Sync aplica configurações que criam novos objetos em um namespace não anotado e inclui neles as anotações configmanagement.gke.io/managed: enabled e configsync.gke.io/resource-id. No entanto, o Config Sync não modifica ou remove os objetos com escopo de cluster sem anotações incluídos em um cluster. Isso é ilustrado no diagrama em Como trabalhar com configurações ao longo do tempo.

O exemplo a seguir mostra como gerenciar um objeto Role existente. Primeiro, crie um objeto Role manualmente e comece a gerenciá-lo com o Config Sync.

1. Crie o papel myrole no namespace gamestore:

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

2. Veja as permissões concedidas pelo papel myrole:

   kubectl describe role -n gamestore myrole

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

   O papel só tem permissão para pods get.

3. No momento, o papel existe no cluster, mas a configuração do Config Sync não sabe sobre ele.

   1. Em um terminal, acesse o clone local do seu repositório.

   2. Use o comando a seguir para criar um manifesto YAML para myrole e salvar o manifesto em um novo arquivo chamado gamestore-myrole.yaml.

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

   3. Edite o arquivo gamestore-myrole.yaml.

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

      Salve as alterações. O arquivo 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. Confirme a alteração no repo.

   5. Aguarde alguns instantes até que o Config Management Operator valide a confirmação. Para conferir se o papel myrole agora é gerenciado pelo Config Sync, execute kubectl describe novamente.

      kubectl describe role myrole -n gamestore
      

Observe a anotação configmanagement.gke.io/managed: enabled, que indica que o objeto é gerenciado pelo Config Sync, e a anotação configsync.gke.io/resource-id, que rastreia as informações de grupo, tipo, namespace e nome. Observe também as anotações que mostram o caminho e o nome do arquivo no repo que causaram a alteração de configuração mais recente no objeto, e o hash do 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]

Parar de gerenciar um objeto gerenciado

Neste exemplo, mostramos como parar de gerenciar um objeto que o Config Sync está gerenciando no momento, como o papel myrole em Começar a gerenciar um objeto atual.

Observação: antes de remover um namespace do gerenciamento, entenda o que acontece com objetos no namespace que ainda são gerenciados.

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

    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
   

   Salve o arquivo.

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

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

4. Use o comando a seguir para verificar se as anotações e os rótulos do RoleBinding gamestore-webstore-admin estão vazios. 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 se o objeto está desativado, será possível remover a configuração do repositório e verificar se o objeto now-unagedaged não foi excluído do namespace. Se você quiser gerenciar o objeto novamente, você precisará adicionar sua configuração de volta ao seu repositório. Por isso, talvez você queira gerenciar objetos e deixar os configs no repositório.

Agora que o objeto não é gerenciado, ele não é criado ou recriado em clusters novos ou atuais e não é removido, mesmo que exista. Para retomar o gerenciamento de um objeto que você parou de gerenciar anteriormente, consulte o próximo exemplo, Retomar o gerenciamento de um objeto anteriormente não gerenciado.

Retomar o gerenciamento de um objeto anteriormente não gerenciado

Neste exemplo, você verá como retomar o gerenciamento de um objeto removido anteriormente, como em Parar de gerenciar um objeto atual. Ele presume que você não removeu a configuração do RoleBinding gamestore-webstore-admin.

1. Se você excluiu o RoleBinding gamestore-webstore-admin do repositório na última confirmação, execute as etapas a seguir.

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

      git revert HEAD~1
      

      Você precisará confirmar a operação de reversão.

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

      git push
      

2. Edite o arquivo 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. Salve o arquivo.

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

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

4. Para verificar se o objeto agora é gerenciado, liste suas 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
   ...
   

Parar de gerenciar um namespace

É possível parar de gerenciar um namespace da mesma forma que você para de gerenciar qualquer tipo de objeto. Se você quiser parar de gerenciar outros recursos no namespace, execute as etapas a seguir:

1. Adicione a anotação configmanagement.gke.io/managed:disabled à configuração do namespace e a todas as configurações no mesmo namespace. Todos os objetos no namespace precisam ter essa anotação.

   Cuidado: em uma fonte de verdade hierárquica, se o namespace for herdado de um namespace abstrato, ele não poderá ser desativado.

2. Confirme e envie suas alterações para o repositório. Aguarde a sincronização do operador com o repositório.

3. Exclua os recursos não gerenciados do repositório.

   Aviso: é um problema conhecido que, se você não estiver usando as APIs RootSync e RepoSync, a exclusão do namespace não gerenciado do repositório faz o namespace ser excluído do cluster ativo. Para os recursos não gerenciados que são excluídos acidentalmente, você precisa adicioná-los de volta manualmente ao cluster, como usar kubectl apply. Para usar as APIs RootSync e RepoSync, você precisa migrar o objeto ConfigManagement.

Se houver configurações gerenciadas dentro de um diretório de namespace não gerenciado, o reconciliador registrará erros, mas outras configurações continuarão sendo sincronizadas normalmente.

Excluir recursos gerenciados

Quando você remove um recurso individual de uma fonte de verdade, esse objeto é excluído do cluster na próxima sincronização que o Config Sync faz da fonte de verdade. Como alternativa, é possível ativar a propagação de exclusão, que permite excluir objetos em massa.

Excluir objetos individuais

Com o comportamento padrão do Config Sync, quando você remove um objeto de uma fonte de verdade, ele é excluído do cluster quando o Config Sync faz a sincronização com base na fonte de verdade.

Há várias maneiras de verificar o status do Config Sync ou de objetos específicos:

• Use nomos status.
• Use kubectl para examinar recursos.
• Use o comando gcloud alpha anthos config sync resources
• Use o painel do Config Sync.

Excluir objetos em massa

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Por padrão, a exclusão de um RootSync ou de um RepoSync faz com que o Config Sync abandone os objetos aplicados anteriormente com base na fonte de verdade. Como alternativa, ative a propagação de exclusão para excluir todos os objetos aplicados anteriormente.

Quando você ativa a propagação de exclusão em um objeto RootSync ou RepoSync e, em seguida, exclui esse objeto, o Config Sync exclui automaticamente todos os objetos gerenciados por esse RootSync ou RepoSync.

A propagação de exclusão pode facilitar a limpeza de recursos, por exemplo, se você estiver migrando para um novo namespace ou cluster, fazendo a limpeza após uma demonstração ou experimento ou desinstalando um aplicativo.

Opções de propagação de exclusão

A propagação de exclusão está desativada por padrão. Para ativá-la, adicione a anotação configsync.gke.io/deletion-propagation-policy: Foreground ao objeto RootSync ou RepoSync, como no seguinte exemplo:

# 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: init
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

Como alternativa, é possível atualizar um RootSync ou RepoSync atual para usar a propagação de exclusã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 você 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 você quer atualizar.

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

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 você quer atualizar.

RepoSync

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

Propagar a exclusão de objetos

Este exemplo mostra como aplicar a propagação de exclusão a um objeto RootSync ou RepoSync e, em seguida, excluir o RootSync ou RepoSync a fim de excluir todos os objetos gerenciados por ele.

Cuidado: para objetos RepoSync, não exclua o namespace em que o RepoSync está antes da conclusão da exclusão dele. Isso pode fazer com que o RoleBinding seja excluído antes que a propagação de exclusão seja concluída, causando um impasse que pode bloquear a exclusão do RepoSync e do namespace.

RootSync

1. Aplique a anotação a um objeto RootSync para ativar a propagação de exclusão:

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

2. Exclua o objeto RootSync e aguarde até que o Config Sync o exclua:

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

   A exclusão do RootSync pode levar alguns minutos para ser concluída.

RepoSync

1. Aplique a anotação a um objeto RepoSync para ativar a propagação de exclusão:

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

2. Exclua o objeto RepoSync e aguarde até que o Config Sync o exclua:

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

   A exclusão do RepoSync pode levar alguns minutos para ser concluída.

Impedir a exclusão de objetos do Kubernetes

Depois que você remover um objeto do Kubernetes de um repositório Git gerenciado pelo Config Sync, esse objeto também será excluído do cluster quando a nova confirmação for sincronizada com o cluster.

Se você quiser impedir que o Config Sync exclua o objeto quando a configuração dele for removida do repositório Git, siga estas etapas:

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

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

3. Aguarde a alteração ser sincronizada com o cluster.

Depois de concluir essas etapas, o Config Sync não excluirá esse objeto do cluster quando a configuração dele for removida do repositório Git, mas ainda poderá ser excluída por outros clientes.

Ignorar um objeto na fonte da verdade

Talvez você queira 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.

Adicione a anotação config.kubernetes.io/local-config: "true" aos objetos que devem ser ignorados pela Config Sync. Depois de adicionar essa anotação, o Config Sync ignora esse objeto como se ele fosse removido da fonte de verdade. Recursos com a anotação local-config definida como qualquer valor diferente de "false" são tratados como se definidos como "true" e são ignorados.