Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Utilizzo di Config Sync in più ambienti con il rendering automatico

Questo tutorial mostra come configurare Config Sync per Google Kubernetes Engine in due ambienti, uno per lo sviluppo e uno per la produzione, utilizzando le best practice per Config Sync.

In questo scenario, fai parte di un team di amministratori della piattaforma di Foo Corp. Le applicazioni di Foo Corp vengono sottoposte a deployment in GKE, con risorse suddivise in due progetti, dev e prod. Il progetto dev contiene un cluster GKE di sviluppo, mentre il progetto prod contiene il cluster GKE di produzione. Il tuo obiettivo come amministratore della piattaforma è garantire che entrambi gli ambienti rispettino le norme di Foo Corp e che le risorse di livello base, come gli spazi dei nomi Kubernetes e gli account di servizio, rimangano coerenti in entrambi gli ambienti.

Il seguente diagramma mostra una panoramica degli ambienti che configurerai in questo tutorial:

Una panoramica degli ambienti che hai configurato in questo tutorial.

Questo tutorial sfrutta la funzionalità di rendering automatico di Config Sync per eseguire il rendering delle risorse sul cluster. Ogni cluster è configurato per la sincronizzazione da una directory contenente un file di configurazione Kustomization, che attiva automaticamente il processo di rendering in Config Sync. Per maggiori dettagli, consulta Utilizzare un repository con configurazioni Kustomize e grafici Helm.

Come mostrato nel diagramma precedente, in questo tutorial creerai le seguenti risorse:

Due Google Cloud progetti che rappresentano gli ambienti di sviluppo e produzione.
Due cluster GKE, dev e prod, nei progetti separati, con Config Sync installato.

Architettura del repository

In questo tutorial, configurerai Config Sync per la sincronizzazione con le configurazioni nella config-source/ directory del repository di esempio. Questa directory contiene le seguenti directory e file:

config-source/
├── base
│   ├── foo
│   │   ├── kustomization.yaml
│   │   ├── namespace.yaml
│   │   └── serviceaccount.yaml
│   ├── kustomization.yaml
│   ├── pod-creator-clusterrole.yaml
│   └── pod-creator-rolebinding.yaml
├── cloudbuild.yaml
├── overlays
│   ├── dev
│   │   └── kustomization.yaml
│   └── prod
│       └── kustomization.yaml
└── README.md

La directory config-source include i manifest base/ e le sovrapposizioni Kustomize dev/ e prod/. Ogni directory contiene un file kustomization.yaml, che elenca i file che Kustomize deve gestire e applicare al cluster. In dev/kustomization.yaml e prod/kustomization.yaml è definita una serie di patch. Queste patch manipolano le risorse base/ per l'ambiente specifico.

Ad esempio, il RoleBinding di sviluppo consente a tutti gli sviluppatori di Foo Corp di eseguire il deployment dei pod nel cluster di sviluppo, mentre il RoleBinding di produzione consente solo a un agente di deployment continuo, deploy-bot@foo-corp.com, di eseguire il deployment dei pod in produzione:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
patches:
# ServiceAccount - make name unique per environ
- target:
    kind: ServiceAccount
    name: foo-ksa
  patch: |-
    - op: replace
      path: /metadata/name
      value: foo-ksa-dev
    - op: replace
      path: /metadata/namespace
      value: foo-dev
# Pod creators - give all Foo Corp developers access
- target:
    kind: RoleBinding
    name: pod-creators
  patch: |-
    - op: replace
      path: /subjects/0/name
      value: developers-all@foo-corp.com
commonLabels:
  environment: dev

Obiettivi

Configurare Config Sync per eseguire automaticamente il rendering e la sincronizzazione della configurazione per i due ambienti separati.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Google Kubernetes Engine

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi Google Cloud utenti potrebbero avere diritto a una prova senza costi.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per saperne di più, consulta Esegui la pulizia.

Prima di iniziare

Prima di iniziare questo tutorial, assicurati di aver completato i seguenti passaggi:

Nella Google Cloud console, nella pagina di selezione del progetto, scegli o crea due Google Cloud progetti.

Nota: se non prevedi di conservare le risorse che crei in questa procedura, crea un progetto anziché selezionarne uno esistente. Al termine di questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

Vai al selettore di progetti
Verifica che la fatturazione sia attivata per il tuo Google Cloud progetto.
Esegui l'upgrade di Google Cloud CLI all'ultima versione.
Installa o esegui l'upgrade del comando nomos

Creare e registrare i cluster

Per consentirti di concentrarti sul flusso di lavoro che devi utilizzare quando configuri Config Sync per più ambienti, la multi-environments-kustomize directory contiene script che puoi utilizzare per automatizzare la configurazione di Config Sync.

Clona il repository di esempio:

git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git

Vai alla cartella che contiene le risorse necessarie per questo tutorial:
```
cd anthos-config-management-samples/multi-environments-kustomize/
```
Per eseguire gli script utilizzati in questo tutorial, imposta le seguenti variabili:
```
export DEV_PROJECT="DEV_PROJECT_ID"
export PROD_PROJECT="PROD_PROJECT_ID"
export DEV_CLUSTER_ZONE="DEV_CLUSTER_ZONE"
export PROD_CLUSTER_ZONE="PROD_CLUSTER_ZONE"
export CM_CONFIG_DIR="config-sync-rendering"
```
Sostituisci quanto segue:
- DEV_PROJECT_ID: l'ID progetto del Google Cloud progetto che vuoi utilizzare come progetto di sviluppo
- PROD_PROJECT_ID: l'ID progetto del Google Cloud progetto che vuoi utilizzare come progetto di produzione
- DEV_CLUSTER_ZONE: la zona di Compute Engine in cui vuoi creare il cluster di sviluppo. Ad esempio, us-central1-c.
- PROD_CLUSTER_ZONE: la zona di Compute Engine in cui vuoi creare il cluster di produzione
Per creare due cluster, esegui lo script ./create-clusters.sh:
```
./create-clusters.sh
```
Questo script crea un cluster GKE denominato dev nel progetto di sviluppo e un cluster GKE denominato prod nel progetto di produzione. Questo script abilita anche l'API GKE e si connette ai cluster dev e prod in modo che tu possa accedere alle relative API con kubectl.

Output di esempio:
```
kubeconfig entry generated for dev.
Fetching cluster endpoint and auth data.
kubeconfig entry generated for prod.
⭐️ Done creating clusters.
```
Per registrare i cluster in due parchi risorse separati, esegui lo script register-clusters.sh:
```
./register-clusters.sh
```
Questo script crea un Google Cloud account di servizio e una chiave per la registrazione del cluster GKE, quindi utilizza il gcloud container fleet memberships register comando per registrare i cluster dev e prod in GKE nei rispettivi progetti.

Output di esempio:
```
Waiting for Feature Config Management to be created...done.
⭐️ Done registering clusters.
```

Configurare Config Sync

Ora che hai creato e registrato i cluster, puoi installare Config Sync e verificarne l'installazione.

Installare Config Sync

Per installare Config Sync, esegui lo script install-config-sync.sh sul cluster di sviluppo e di produzione:

./install-config-sync.sh

Output previsto:

🔁 Installing ConfigSync on the dev cluster...
Updated property [core/project].
Switched to context "DEV_CLUSTER".
Waiting for Feature Config Management to be updated...done.
🔁 Installing ConfigSync on the prod cluster...
Updated property [core/project].
Switched to context "PROD_CLUSTER".
Waiting for Feature Config Management to be updated...done.

Config Sync ora esegue la sincronizzazione con le configurazioni nei repository.

Verificare la configurazione

In questa sezione verificherai che i cluster eseguano la sincronizzazione con le configurazioni nel repository:

Per controllare lo stato dell'installazione di Config Sync, esegui il nomos status comando:

nomos status

Dovresti vedere che sia il cluster di sviluppo sia quello di produzione sono ora sincronizzati con i rispettivi repository:

gke_DEV_PROJECT_ID_us-central1-c_dev
  --------------------
  <root>   https://github.com/GoogleCloudPlatform/anthos-config-management-samples/multi-environments-kustomize/config-source/overlays/dev@main
  SYNCED   8f2e196f
  Managed resources:
     NAMESPACE   NAME                                                 STATUS
                 clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                 namespace/default                                    Current
                 namespace/foo                                        Current
     default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
     foo         serviceaccount/foo-ksa-dev                           Current

*gke_PROD_PROJECT_ID_us-central1-c_prod
   --------------------
   <root>   https://github.com/GoogleCloudPlatform/anthos-config-management-samples/multi-environments-kustomize/config-source/overlays/prod@main
   SYNCED   c91502ee
   Managed resources:
      NAMESPACE   NAME                                                 STATUS
                  clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                  namespace/default                                    Current
                  namespace/foo                                        Current
      default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
      foo         serviceaccount/foo-ksa-prod                          Current

  ```

Utilizza kubectl per passare al cluster di sviluppo:

kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"

Per verificare che le risorse siano sincronizzate, recupera gli spazi dei nomi. Dovresti visualizzare lo spazio dei nomi foo.

kubectl get namespace

Output di esempio:

NAME                           STATUS   AGE
config-management-monitoring   Active   9m38s
config-management-system       Active   9m38s
default                        Active   47h
foo                            Active   9m5s
kube-node-lease                Active   47h
kube-public                    Active   47h
kube-system                    Active   47h
resource-group-system          Active   9m30s

Ora hai configurato il rendering automatico della configurazione per un ambiente di sviluppo e di produzione, in più Google Cloud progetti e ambienti.

Liberare spazio

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Eliminare tutte le risorse

Per eliminare le risorse che hai creato in questo tutorial, ma mantenere intatti i progetti di sviluppo e di produzione, esegui lo script di pulizia:

./cleanup.sh

Eliminare i progetti

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per, le attività descritte in questo documento, eliminerai anche tutto il lavoro che hai svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Nella Google Cloud console, vai alla pagina Gestisci risorse.
Vai a Gestisci risorse
Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
Nella finestra di dialogo, digita l'ID progetto, quindi fai clic su Arresta per eliminare il progetto.

Passaggi successivi

Scopri di più sui deployment sicuri con Config Sync