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.
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 chamadopod-accountant
que não tem a anotaçãoconfigmanagement.gke.io/managed: enabled
, e não há config para o objeto ClusterRole no repo. O Anthos Config Management não configura o ClusterRolepod-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 chamadoquota-viewer
. Como o config é criado no diretóriocluster/
, ele afeta todos os clusters registrados. O Anthos Config Management detecta a configuração recém-confirmada e a aplica. O ClusterRolequota-viewer
agora existe no cluster, tem a anotaçãoconfigmanagement.gke.io/managed: enabled
e está em sincronia com o conteúdo dequota-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 ClusterRolequota-viewer
do cluster.É possível começar a gerenciar um objeto atual em um cluster adicionando a anotação
configmanagement.gke.io/managed: enabled
.O cluster
foo-corp
tem um diretório de namespace chamadoshipping-dev
. Dentro desse diretório de namespace, há um config para um papel chamadojob-creator
e tem a anotaçãoconfigmanagement.gke.io/managed: enabled
. Alguém atualiza o arquivonamespaces/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 chamadopod-creator
e um arquivo/namespaces/pod-creator/pod-creator.yaml
correspondente no repo. O diagrama mostra queshipping-prod
,shipping-staging
eshipping-dev
são todos os namespaces (cada um deles tem um arquivonamespace.yaml
que define um namespace) no diretório do namespace abstratoshipping-dev-backend
. Cada um desses namespaces herda o RoleBindingpod-creator
.Algum tempo depois, alguém modifica o RoleBinding
pod-creator
no diretório de namespaceshipping-prod
. O operador detecta a alteração e atualizapod-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 RoleBindingpod-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 namespaceshipping-prod
. Não há config para o papelsecret-admin
no repo. O papelsecret-admin
não tem a anotaçãoconfigmanagement.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 papelsecret-admin
. Ainda não há nenhum config correspondente no repo, portanto, o Anthos Config Management exclui o papelsecret-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 namespaceaudit
no cluster e aplica a anotaçãoconfigmanagement.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çãoconfigmanagement.gke.io/managed: enabled
. No entanto, o diretório de namespaceshipping-dev
no repo tem um RoleBinding chamadojob-creators
, que tem a anotaçãoconfigmanagement.gke.io/managed: enabled
.Alguém adiciona um config para o namespace
shipping-dev
ao repo, mas não há config para o RoleBindingjob-creators
. Como não existe nenhum config para o RoleBinding, mas o RoleBinding tem a anotaçãoconfigmanagement.gke.io/managed: enabled
, o Anthos Config Management exclui o RoleBinding.Mais tarde, alguém adiciona um config para o RoleBinding
job-creators
. O RoleBindingjob-creators
é recriado com as propriedades definidas no config.
A seguir
- Crie uma configuração.
- Saiba como gerenciar namespaces e objetos com escopo de namespace.
- Criar uma restrição