Usar um repositório não estruturado

Ao usar um repositório não estruturado, é possível organizar seu repositório da maneira que for mais conveniente para você. Essa flexibilidade permite sincronizar a configuração atual do Kubernetes com o repositório do Config Sync. Por exemplo, se você quiser sincronizar um gráfico Helm com seu cluster, execute o comando helm template e confirme a manifesto renderizado no seu repositório. Para mais informações, consulte o tutorial Como usar o Config Sync com o Helm.

Os repositórios não estruturados são preferíveis para a maioria dos casos de uso. No entanto, também é possível criar um repositório hierárquico para separar configurações em categorias distintas.

Limitações

Os repositórios não estruturados têm as seguintes limitações:

  • Não é possível usar o objeto HierarchyConfig do Kubernetes em um repositório não estruturado.

  • Os namespaces abstratos não são compatíveis com repositórios não estruturados.

  • Se você estiver usando o comando nomos vet, adicione a sinalização --source-format=unstructured. Por exemplo:

    nomos vet --source-format=unstructured

Objetos com escopo no namespace

É possível declarar NamespaceSelectors em um repositório não estruturado. Para declarar um NamespaceSelector, adicione a anotação metadata.namespace ou NamespaceSelector. Declarar as duas anotações é inválido. Se os recursos com escopo de namespace não declararem metadata.namespace ou a anotação NamespaceSelector, o Config Sync usará o namespace "padrão" do cluster. Para saber mais, consulte Limitar quais namespaces uma configuração afeta.

Objetos com escopo no cluster

Em um repositório não estruturado, ClusterSelectors funciona normalmente.

Configurar um repositório não estruturado

Para configurar um repositório não estruturado, defina o valor de spec.sourceFormat como unstructured no objeto RootSync:

  # root-sync.yaml
  apiVersion: configsync.gke.io/v1beta1
  kind: RootSync
  metadata:
    name: ROOT_SYNC_NAME
    namespace: config-management-system
  spec:
    sourceFormat: unstructured
    git:
      repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
      branch: main
      dir: config-sync-quickstart/multirepo/root
      auth: ssh
      secretRef:
        name: SECRET_NAME

Substitua:

  • ROOT_SYNC_NAME: adicione o nome do objeto RootSync. O nome precisa ser exclusivo no cluster e ter no máximo 26 caracteres.
  • SECRET_NAME pelo nome do Secret.

Converter um repositório hierárquico em um repositório não estruturado

Se você estiver usando um repositório hierárquico e quiser convertê-lo em um repositório não estruturado, no seu repositório, execute:

nomos hydrate PATH

Substitua PATH pelo caminho para o diretório.

Esse comando cria um diretório compiled/ no diretório de trabalho atual. Nesse diretório, um subdiretório é criado para cada cluster registrado, com as configurações totalmente resolvidas, e cada subdiretório pode ser usado em um repositório não estruturado.

Para mais detalhes, consulte comandos nomos.

Se você preferir converter o repositório manualmente, siga estas instruções:

  1. Remova as configurações Repo do diretório system/ do repositório do Git. O recurso Repo não é necessário para o repositório não estruturado.

  2. O diretório de namespace abstrato não é compatível com o repositório não estruturado. Portanto, é necessário declarar o namespace de todos os recursos originalmente incluídos no diretório namespaces/ e nos subdiretórios dele.

  3. A herança de namespaces não é compatível com o repositório não estruturado. Portanto, você precisa declarar todos os recursos herdados originalmente nos namespaces descendentes, ou seja, os recursos originalmente no diretório namespaces/.

Exemplo de formato para um repositório não estruturado

Veja no exemplo a seguir como organizar as configurações (incluindo recursos do Google Cloud) em um repositório não estruturado:

├── manifests
│   ├── access-control
│   │   ├── ...
│   ├── change-control
│   │   ├── ...
│   ├── git-ops
│   │   └── ...
│   ├── logging-monitoring
│   │   └── ...
│   ├── networking
│   │   └── ...
│   ├── project-factory
│   │   └── ...
│   └── resource-hierarchy
│   │   └── ...
├── raw-configs
│   ├── access-control
│   │   └── ...
│   ├── change-control
│   │   └── ...
│   ├── git-ops
│   │   └── ...
│   ├── logging-monitoring
│   │   └── ...
│   ├── networking
│   │   └── ...
│   ├── project-factory
│   │   └── ...
│   └── resource-hierarchy
│   │   └── ...
└── scripts
    └── render.sh

Neste exemplo, as configurações brutas estão em um diretório raw-configs. Em seguida, é possível usar um script ou um pipeline automatizado para renderizar as configurações brutas e armazenar a saída no diretório manifests. Ao configurar o Config Sync, ele é configurado para ser sincronizado do seu diretório manifests.

A seguir