Use um repositório não estruturado

A utilização de um repositório não estruturado permite-lhe organizar o repositório da forma mais conveniente para si. Esta flexibilidade permite-lhe sincronizar a sua configuração do Kubernetes existente com o repositório do Config Sync. Por exemplo, se quiser sincronizar um gráfico do Helm com o seu cluster, pode executar o comando helm template e confirmar o manifesto renderizado no seu repositório. Para mais informações, consulte o tutorial Usar o Config Sync com o Helm.

Recomendamos repositórios não estruturados para a maioria dos exemplos de utilização. No entanto, também pode criar um repositório hierárquico para separar as configurações em categorias distintas.

Limitações

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

Objetos ao nível do espaço de nomes

Pode declarar NamespaceSelectors num repositório não estruturado. Para declarar um NamespaceSelector, adicione a anotação metadata.namespace ou NamespaceSelector. Declarar ambas as anotações é inválido. Se os recursos com âmbito de espaço de nomes não declararem metadata.namespace ou a anotação NamespaceSelector, o Config Sync usa o espaço de nomes "default" do cluster. Para saber mais, consulte o artigo Limite os espaços de nomes que uma configuração afeta.

Objetos ao nível do cluster

Num repositório não estruturado, a função ClusterSelectors funciona normalmente.

Configure 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 o seguinte:

  • ROOT_SYNC_NAME: adicione o nome do objeto RootSync. O nome deve ser exclusivo no cluster e ter, no máximo, 26 carateres.
  • SECRET_NAME com o nome do segredo.

Converta um repositório hierárquico num repositório não estruturado

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

nomos hydrate PATH

Substitua PATH pelo caminho para o seu diretório.

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

Para mais detalhes, consulte os comandos nomos.

Se preferir converter o repositório manualmente, siga as seguintes instruções:

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

  2. O diretório de espaço de nomes abstrato não é suportado num repositório não estruturado. Por isso, tem de declarar o espaço de nomes de todos os recursos originalmente incluídos no diretório namespaces/ e nos respetivos subdiretórios.

  3. A herança do espaço de nomes não é suportada no repositório não estruturado. Por conseguinte, tem de declarar todos os recursos que são originalmente herdados nos espaços de nomes descendentes, nomeadamente os que estão originalmente no diretório namespaces/.

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

O exemplo seguinte demonstra como pode organizar as suas configurações (incluindo Google Cloud recursos) num 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 não processadas estão num diretório raw-configs. Em seguida, pode usar um script ou um pipeline automatizado para renderizar as configurações não processadas e armazenar o resultado no diretório manifests. Quando configura o Config Sync, configura-o para sincronizar a partir do seu diretório manifests.

O que se segue?