Visão geral das configurações

Esta página descreve os configs, os arquivos que o Anthos Config Management lê no Git e se aplica aos clusters automaticamente. É possível criar um config e enviá-lo para seu repo.

O Anthos Config Management mantém seus clusters inscritos em sincronia usando configs. Um config é um arquivo YAML ou JSON armazenado no repo e contém os mesmos tipos de detalhes de configuração que podem ser aplicados manualmente a um cluster usando o comando kubectl apply. Este tópico aborda como os configs funcionam, como escrevê-los e como o Anthos Config Management os aplica aos clusters registrados.

O Anthos Config Management é projetado para operadores que gerenciam muitos clusters. É possível garantir que seus clusters atendam aos padrões de negócios e conformidade, permitindo que o Anthos Config Management gerencie namespaces, papéis, RoleBindings, ResourceQuotas e outros objetos importantes do Kubernetes em toda a frota. É possível criar um config para qualquer objeto do Kubernetes que possa existir em um cluster.

Como trabalhar com configs ao longo do tempo

A árvore de decisões a seguir ilustra os resultados de diferentes alterações de configurações em um grupo hipotético de clusters gerenciados pelo Anthos Config Management ao longo do tempo. Seguindo o diagrama, algumas ações hipotéticas dos operadores de cluster e os resultados dessas ações são discutidos e usados para ilustrar como o Anthos Config Management funciona.

Este cluster usa o repo de exemplo. O cluster já está registrado no operador.

Exemplo de árvore de decisões ilustrando ações e resultados para o Anthos Config Management ao longo do tempo

  • O Anthos Config Management aplica configs somente quando pelo menos uma das seguintes situações for verdadeira:

    • Há um config relevante no repo.
    • A anotação configmanagement.gke.io/managed: enabled foi aplicada ao objeto Kubernetes.

    O cluster foo-corp tem um ClusterRole chamado pod-accountant que não tem a anotação configmanagement.gke.io/managed: enabled, e não há config para o objeto ClusterRole no repo. O Anthos Config Management não configura o ClusterRole pod-accountant.

  • O Anthos Config Management aplica uma alteração relevante automaticamente quando ela está confirmada para o repo.

    Um administrador de cluster confirma um config para o arquivo cluster/quota-viewer-clusterrole.yaml no repo. Esse config define um ClusterRole chamado quota-viewer. Como o config é criado no diretório cluster/, ele afeta todos os clusters registrados. O Anthos Config Management detecta a configuração recém-confirmada e a aplica. O ClusterRole quota-viewer agora existe no cluster, tem a anotação configmanagement.gke.io/managed: enabled e está em sincronia com o conteúdo de quota-viewer-clusterrole.yaml.

    Algum tempo depois, alguém exclui o arquivo cluster/quota-viewer-clusterrole.yaml do repo. O Anthos Config Management detecta essa alteração e remove o ClusterRole quota-viewer do cluster.

  • É possível começar a gerenciar um objeto atual adicionando a anotação configmanagement.gke.io/managed: enabled.

    O cluster foo-corp tem um diretório de namespace chamado shipping-dev. Dentro desse diretório de namespace, há um config para um papel chamado job-creator e tem a anotação configmanagement.gke.io/managed: enabled. Alguém atualiza o arquivo namespaces/dev/shipping-dev/job-creator-role.yaml. O operador detecta e aplica a alteração.

  • O Anthos Config Management permite que você aplique alterações de configuração aos namespaces de forma hierárquica agrupada.

    O cluster foo-corp tem um RoleBinding chamado pod-creator e um arquivo /namespaces/pod-creator/pod-creator.yaml correspondente no repo. O diagrama mostra que shipping-prod, shipping-staging e shipping-dev são todos os namespaces (cada um deles tem um arquivo namespace.yaml que define um namespace) no diretório do namespace abstrato shipping-dev-backend. Cada um desses namespaces herda o RoleBinding pod-creator.

    Algum tempo depois, alguém modifica o RoleBinding pod-creator no diretório de namespace shipping-prod. O operador detecta a alteração e atualiza pod-creator para que corresponda ao config no repo.

    Por fim, alguém remove o config pod-creator do repo. O Anthos Config Management detecta a alteração e remove o RoleBinding pod-creator de cada um dos três namespaces.

  • O Anthos Config Management permite aplicar alterações manualmente e não gerencia objetos, a menos que eles tenham a anotação configmanagement.gke.io/managed: enabled.

    Alguém cria manualmente um novo papel chamado secret-admin no namespace shipping-prod. Não há config para o papel secret-admin no repo. O papel secret-admin não tem a anotação configmanagement.gke.io/managed: enabled. O Anthos Config Management não faz nada.

    Algum tempo depois, alguém adiciona manualmente a anotação configmanagement.gke.io/managed:enabled ao papel secret-admin. Ainda não há nenhum config correspondente no repo, portanto, o Anthos Config Management exclui o papel secret-admin do namespace.

  • O Anthos Config Management cria namespaces ausentes se existirem configs para eles.

    Alguém confirma um novo config para o namespace audit, que não existe no cluster. O Anthos Config Management cria o namespace audit no cluster e aplica a anotação configmanagement.gke.io/managed: enabled.

  • O Anthos Config Management pode gerenciar configurações para um namespace que não tem a anotação configmanagement.gke.io/managed: enabled.

    O namespace shipping-dev existe no cluster, mas não tem a anotação configmanagement.gke.io/managed: enabled. No entanto, o diretório de namespace shipping-dev no repo tem um RoleBinding chamado job-creators, que tem a anotação configmanagement.gke.io/managed: enabled.

    Alguém adiciona um config para o namespace shipping-dev ao repo, mas não há config para o RoleBinding job-creators. Como não existe nenhum config para o RoleBinding, mas o RoleBinding tem a anotação configmanagement.gke.io/managed: enabled, o Anthos Config Management exclui o RoleBinding.

    Mais tarde, alguém adiciona um config para o RoleBinding job-creators. O RoleBinding job-creators é recriado com as propriedades definidas no config.

A seguir