Visão geral do Config Sync

O Config Sync permite que operadores de cluster e administradores de plataforma implantem configurações e políticas consistentes. É possível implantar essas configurações e políticas em clusters individuais do Kubernetes, vários clusters que abrangem ambientes híbridos e de várias nuvens e vários namespaces dentro dos clusters. Esse processo simplifica e automatiza o gerenciamento de configurações e políticas em escala. O Config Sync também permite que equipes de desenvolvimento gerenciem de maneira independente seus namespaces nos clusters, enquanto ainda estão sujeitos a proteções de política definidas pelos administradores.

Usando os mesmos princípios do próprio Kubernetes, o Config Sync reconcilita continuamente o estado de clusters registrados com um conjunto central de configuração declarativa do Kubernetes, os arquivos chamadosconfigurações. As configurações são armazenadas em um ou mais repositórios Git, mantendo-as consistentes para os objetos do Kubernetes configurados. Essa abordagem do GitOps (também chamada de configuração como código) permite que você gerencie e implante configurações comuns com um processo auditável, transacional, visível e com a versão controlada.

No diagrama a seguir, mostramos como um administrador de plataforma pode criar configurações consistentes para três clusters diferentes aplicando configurações aos clusters e namespaces dentro do cluster:

Um administrador de plataforma implantando várias configurações nos clusters.

Benefícios do Config Sync

Os exemplos a seguir destacam alguns dos benefícios que o Config Sync oferece:

  • Redução do risco de "operações de sombra": se as alterações não verificadas são enviadas para clusters ativos, pode ser difícil entender as diferenças entre a configuração documentada e o ambiente ativo. É possível exigir que todas as alterações na configuração do cluster sejam propagadas usando o Config Sync, bloquear o acesso direto à API Kubernetes e rastrear as alterações nas fontes de verdade no Git.
  • Exigência de revisões de código: antes de enviar qualquer alteração ao ambiente em tempo real, você pode usar o Config Sync para exigir revisões de código e auditar exatamente qual confirmação causou uma alteração na configuração.
  • Redução da inatividade devido a interrupções relacionadas à configuração: o Config Sync permite usar uma estratégia de reverter e investigar para reverter alterações interruptivas e colocar os clusters ativos novamente em bom estado de funcionamento, antes de corrigir a alteração problemática e aplicá-la como uma nova confirmação.
  • Use os pipelines de integração contínua/implantação contínua (CI/CD): use um fluxo de trabalho de CI/CD para renderizar a configuração com qualquer ferramenta e formato que você preferir, testar e validar suas alterações e confirmá-las automaticamente, quando os testes forem aprovados. Em seguida, o Config Sync aplica as alterações e monitora e corrige os deslocamentos de configuração.

Noções básicas do Config Sync

Pré-requisitos

O Config Sync usa namespaces, rótulos e anotações como partes principais de sua implementação. Compreender bem esses conceitos é útil antes de começar a usar o produto.

Configurar clusters

O Config Sync permite criar um conjunto comum de políticas e configurações no nível do cluster, como Restrições do controlador de políticas, e os aplica de maneira consistente em todos os clusters registrados e conectados de uma única fonte de confiança no Git. Antes de configurar um cluster, é preciso criar um config e um repositório.

Configs

Um config é uma declaração de configuração do Kubernetes escrita em YAML ou JSON. O Config Sync lê e aplica a configuração a um ou mais clusters para criar ou configurar um objeto ou recurso do Kubernetes neles, ou fornecer informações necessárias para o Config Sync. Um config pode conter qualquer detalhe de configuração que pode ser aplicado a um cluster do Kubernetes usando kubectl edit ou kubectl apply. Também é possível declarar várias configurações em um único arquivo.

Antes de escrever uma configuração, entenda os campos obrigatórios e opcionais permitidos para esse objeto do Kubernetes.

Para mais informações, consulte a Visão geral de configurações e Como configurar objetos do Kubernetes, que mostra como criar uma configuração.

Repositórios

O repositório (ou repo) é o repositório Git, onde configs são armazenados, incluindo o config para o próprio Config Sync. Ao configurar o Config Sync, você configura o repositório, a ramificação e o subdiretório que o Config Sync monitora em busca de alterações.

O Config Sync permite sincronizar configurações de vários repositórios com o mesmo conjunto de clusters. Ativar a capacidade de sincronizar com vários repositórios permite que você tenha acesso a funcionalidades adicionais, por exemplo, ignorar mutações de objetos. Ative essa funcionalidade mesmo se você quiser apenas usar um repositório raiz e não quiser usar repositórios de namespace. Para saber mais, consulte Sincronização de vários repositórios.

É possível criar um repositório raiz e repositórios de namespace:

  • Repositório raiz: este repositório permite sincronizar configurações com escopo de cluster e com escopo de namespace. O repositório raiz usa credenciais de nível de administrador para aplicar políticas a namespaces de aplicativos e substituir as alterações locais que se deslocam do estado que você declarou nas configurações. Um administrador central normalmente rege o repositório raiz, e somente um repositório raiz pode existir para cada cluster.

    É possível usar duas estruturas diferentes para o repositório raiz:

    • Não estruturado: o formato de origem não estruturado permite organizar as configurações no seu repositório da maneira mais conveniente. Esse formato pode ser útil principalmente se você estiver organizando e/ou gerando configurações usando uma ferramenta como kustomize, kpt ou helm. Não estruturado é o formato recomendado para a maioria dos usuários. Para mais informações, consulte Como usar um repositório não estruturado.

    • Hierárquico: o formato de origem hierárquico, ou estruturado, separa as configurações em categorias distintas para a configuração de sistema, metadados de cluster, configuração no nível do cluster e configuração de namespace para ajudar você a organizar as configurações. Ele também é compatível com a herança hierárquica de configuração em vários namespaces, com base na estrutura de diretórios. Isso é discutido com mais detalhes na seção Como configurar namespaces. Hierárquico é o formato de repositório padrão do Config Sync. Para mais informações, consulte Como usar o repositório do Config Sync e Visão geral do Repositório hierárquico.

  • Repositórios de namespace: são opcionais e podem conter configurações com escopo de namespace sincronizadas com um namespace específico entre os clusters. É possível delegar a configuração e o controle de um repositório de namespace para usuários não administrativos. Os repositórios de namespace precisam usar o formato de repositório não estruturado. Para mais informações, consulte Como configurar a sincronização a partir de repositórios de namespace.

Como configurar vários clusters

O Config Sync ajuda você a implantar configurações e políticas consistentes em vários clusters, que podem abranger ambientes híbridos e de várias nuvens.

O Config Sync ajuda você a configurar vários clusters fornecendo as seguintes opções:

Recomendamos que você registre seus clusters. O registro dos clusters facilita a observação do status atual de todos os clusters por meio do Console do Google Cloud e permite a configuração e o gerenciamento centralizados do Config Sync nos clusters registrados. Para mais informações, consulte Como registrar um cluster, Como configurar o Config Sync e Como atualizar versões do Config Sync.

Como configurar namespaces

A configuração de namespaces com o Config Sync fornece os seguintes recursos:

  • É possível provisionar namespaces do Kubernetes de maneira consistente com políticas com escopo de namespace, como papéis do RBAC, entre clusters registrados e conectados. Com as políticas com escopo de namespace, é mais fácil implementar e gerenciar a multilocação nos seus clusters.
  • Aplicar políticas a vários namespaces relacionados, sem duplicar configurações, e com a capacidade de substituir ou estender um config para um determinado namespace ou conjunto de namespaces, facilitando a aplicação de políticas consistentes em locatários.

Esses recursos funcionam de maneira diferente em formatos de repositório não estruturados e hierárquicos.

Com repositórios não estruturados, é possível usar o Hierarchy Controller para propagar políticas em hierarquias de namespace definidas para seus clusters. Para mais informações, consulte a Visão geral do controlador de hierarquia.

Com os repositórios hierárquicos, é possível usar grupos de namespaces chamados de namespaces abstratos para controlar a quais políticas de namespaces devem ser propagados. Os namespaces abstratos exigem a organização de namespaces de forma hierárquica na árvore de diretórios do repositório. Para mais informações, consulte Como configurar namespaces e objetos com escopo de namespace e a Visão geral da herança de namespace.

Tanto os formatos não estruturados quanto o hierárquico são compatíveis com a segmentação de conjuntos de namespaces não hierárquicos usando seletores de rótulo.

O comando nomos

O Config Sync fornece uma API. Os comandos nomos e nomos.exe consomem a API, simplificam o processo de configuração de um repositório usando o formato hierárquico e validam as configurações.

Para mais informações, consulte Como usar o comando nomos.

A seguir