Glossário

Nesta página, fornecemos definições breves de termos usados com frequência no Anthos Config Management. O glossário é escrito pressupondo que você já conhece os termos básicos do Kubernetes.

B

  • Blueprint: um blueprint é um pacote de configurações e políticas implantáveis e reutilizáveis que implementam e documentam uma solução específica. Os blueprints permitem criar infraestrutura, plataformas e serviços de aplicativos compondo e conectando recursos de nuvem com uma configuração declarativa. Para saber mais, consulte a Visão geral de blueprints.

C

  • ClusterSelector: um ClusterSelector é um tipo especial de config que usa labelSelectors do Kubernetes. Use um ClusterSelector para limitar os clusters a que um config específico é aplicado com base nos rótulos do cluster. Também é possível usar os ClusterSelectors para limitar quais clusters instanciam um objeto com escopo de namespace. Para saber mais, consulte Como usar ClusterSelectors.

  • Config: um config é uma declaração de configuração do Kubernetes escrita em YAML ou JSON. O Config Sync lê e aplica o config 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. As configurações precisam ser armazenadas em um repositório. Para saber mais, consulte Como usar configs em repositórios do Git.

  • Config Controller: Config Controller é um serviço hospedado para provisionar e orquestrar recursos do Anthos e do Google Cloud. Ele oferece um endpoint de API que pode provisionar, acionar e orquestrar recursos do Google Cloud. Para saber mais, consulte Visão geral do Config Controller.

  • 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, em vários clusters que abrangem ambientes híbridos e de várias nuvens, bem como em vários namespaces dentro dos clusters. Para saber mais, consulte Visão geral do Config Sync.

  • Restrição: uma restrição é um conjunto de regras e parâmetros que controlam a interação com um cluster do Kubernetes. Ao definir uma ou mais restrições, o Policy Controller permite aplicar uma política a um cluster do Kubernetes. Depois que uma restrição é aplicada, as solicitações ao servidor de API são verificadas em relação à restrição e são rejeitadas se não estiverem em conformidade. Para saber mais, consulte Como criar restrições.

  • Modelo de restrição: um modelo de restrição define o esquema e a lógica da restrição. Os modelos de restrição podem ser provenientes do Google e de terceiros ou criados por você. Saiba mais sobre como criar novos modelos em Como escrever um modelo de restrição.

  • Biblioteca de modelos de restrição: a biblioteca de modelos de restrição é um conjunto de políticas pré-criadas incluídas no Anthos Policy Controller para controles comuns de segurança e conformidade. Para saber mais, consulte Biblioteca de modelos de restrição.

F

  • Frota: as frotas (anteriormente conhecidas como ambientes) são um conceito do Google Cloud para organizar de maneira lógica clusters e outros recursos, permitindo que você use e gerencie recursos de vários clusters e aplique políticas consistentes nos sistemas. As frotas são uma parte essencial de como a funcionalidade corporativa de vários clusters funciona no Google Cloud. Para saber mais, consulte Introdução às frotas.

H

  • Repositório hierárquico: um repositório hierárquico, também conhecido como repositório estruturado, é um repositório que separa configurações em categorias distintas. Há categorias para configuração do sistema, metadados de cluster, configuração no nível do cluster e configuração de namespace. Também é possível usar o formato de repositório não estruturado, que é o formato recomendado para a maioria dos usuários. Para mais informações, consulte Visão geral do repositório hierárquico.

L

  • Zonas de destino: as zonas de destino do Google Cloud fornecem um conjunto de modelos de configuração (blueprints) que representam práticas recomendadas comuns da empresa. Ao adotar esses blueprints de zona de destino, você pode configurar uma "zona de destino" de nuvem empresarial, onde é possível implantar com segurança as cargas de trabalho. Para mais informações, consulte Implantar um blueprint de zona de destino.

N

  • Repositório de namespace: os repositórios de namespace são repositórios não estruturados que podem ser configurados de modo que usuários não administrativos possam controlá-los. Esses repositórios contêm configurações com escopo de namespace sincronizadas com um namespace específico entre os clusters. Para mais informações, consulte Como configurar a sincronização a partir de repositórios de namespace.

  • NamespaceSelector: são usados para limitar quais objetos com escopo de namespace podem herdar um config. O comportamento é um pouco diferente para repositórios hierárquicos e não estruturados. Para mais informações, consulte Como limitar os namespaces afetados por um config.

  • nomos: nomos é uma ferramenta de linha de comando para verificar a sintaxe das configurações antes de confirmá-las no repositório e para depurar problemas no Config Sync, cluster ou repositório. Para saber mais, consulte Como usar o comando nomos.

P

  • Policy Controller: permite aplicar políticas totalmente programáveis aos clusters. Essas políticas atuam como uma "guarda" e impedem que qualquer alteração na configuração da API Kubernetes viole os controles de segurança, operação ou de conformidade. Para saber mais, consulte Visão geral do Policy Controller.

S

R

  • Reconciliador: um reconciliador é um pod implantado como uma implantação. Ele sincroniza manifestos de um repositório Git com um cluster.

  • Restrições referenciais: uma restrição referencial é um tipo de restrição que referencia outro objeto na definição. Por exemplo, "não permitir que dois serviços tenham o mesmo nome de host". Para saber mais, consulte Como escrever modelos de restrição referencial.

  • Cluster registrado: um cluster registrado em uma frota. Para saber mais, consulte Como registrar um cluster.

  • RepoSync: um objeto RepoSync sincroniza o repositório de namespaces com o cluster. Para saber mais, consulte os campos RootSync e RepoSync.

  • ResourceGroup: um ResourceGroup é um recurso que agrega o status de reconciliação de todos os recursos para cada repositório Git sincronizado com o cluster. O Config Sync gera automaticamente o recurso personalizado (CR, na sigla em inglês) do ResourceGroup. Para saber mais, consulte os campos ResourceGroup.

  • root-reconciler: quando você cria um objeto RootSync, o Config Sync cria um reconciliador chamado root-reconciler.

  • 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. Cada cluster pode ter apenas um repositório raiz, e um administrador central normalmente controla esse repositório.

  • RootSync: um objeto RootSync sincroniza o repositório raiz com o cluster. Quando você configura a sincronização a partir do repositório raiz, usando o Console do Google Cloud ou a ferramenta de linha de comando gcloud, o Config Sync cria automaticamente um objeto RootSync. Se você usar kubectl, precisará criar um objeto RootSync.

U

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