Configurazione di Config Controller
Questa pagina mostra come configurare Config Controller.
Config Controller fornisce un piano di controllo gestito, basato su Kubernetes. Inoltre, le istanze Config Controller sono preinstallate su Policy Controller, Config Sync e Config Connector. Utilizzando questi componenti, puoi sfruttare gli strumenti e i flussi di lavoro di Kubernetes per gestire le risorse Google Cloud e ottenere coerenza utilizzando un flusso di lavoro GitOps. Per saperne di più, consulta la Panoramica di Config Controller.
Se è la prima volta che crei un'istanza di Config Controller, consulta la Guida rapida: gestione delle risorse con Config Controller.
Limitazioni
- Poiché le istanze di Config Controller sono completamente gestite, non puoi registrarle con un parco risorse.
Prima di iniziare
Prima di configurare Config Controller, completa i seguenti passaggi:
- Installa e inizializza l'interfaccia a riga di comando di Google Cloud, che fornisce Google Cloud CLI utilizzata in queste istruzioni. Se utilizzi Cloud Shell, Google Cloud CLI è già installato.
Poiché
kubectl
non è installato per impostazione predefinita dall'interfaccia a riga di comando di Google Cloud, installalo:gcloud components install kubectl
Imposta il progetto Google Cloud in cui vuoi ospitare Config Controller:
gcloud config set project PROJECT_ID
Sostituisci
PROJECT_ID
con il progetto Google Cloud che ospiterà Config Controller.Abilita le API che ti servono:
gcloud services enable krmapihosting.googleapis.com \ anthos.googleapis.com \ cloudresourcemanager.googleapis.com \ serviceusage.googleapis.com
Crea un'istanza di Config Controller
Puoi creare un'istanza di Config Controller supportata da un cluster Standard o da un cluster Autopilot. Entrambi i tipi di cluster sono privati.
Seleziona un cluster standard se vuoi avere più opzioni di personalizzazione. Seleziona un cluster Autopilot se vuoi un'installazione più rapida, una scalabilità automatica orizzontale e verticale dei pod e funzionalità di sicurezza avanzate come Container-Optimized OS, Nodi GKE schermati, Workload Identity e Avvio protetto.
Crea un'istanza di Config Controller:
Standard
Crea un'istanza di Config Controller supportata da un cluster GKE standard privato:
gcloud anthos config controller create CONFIG_CONTROLLER_NAME \ --location=LOCATION
Sostituisci quanto segue:
CONFIG_CONTROLLER_NAME
: il nome che vuoi assegnare all'istanza di Config Controller.LOCATION
: aggiungi una delle seguenti regioni:us-central1
us-east1
us-east4
us-east5
us-west2
northamerica-northeast1
northamerica-northeast2
europe-north1
europe-west1
europe-west3
europe-west6
australia-southeast1
australia-southeast2
asia-northeast1
asia-northeast2
asia-southeast1
Questa è la regione in cui è creata l'istanza di Config Controller. Non sono supportate altre regioni.
Puoi impostare più parametri facoltativi durante la creazione di un'istanza di Config Controller standard. Per l'elenco completo delle opzioni, consulta la documentazione di
gcloud anthos config controller create
.Autopilot
Per creare un'istanza di Config Controller supportata da un cluster GKE Autopilot privato, esegui questo comando:
gcloud anthos config controller create CONFIG_CONTROLLER_NAME \ --location=LOCATION \ --full-management
Sostituisci quanto segue:
CONFIG_CONTROLLER_NAME
: il nome che vuoi assegnare al controller.LOCATION
: aggiungi una delle seguenti regioni:us-central1
us-east1
us-east4
us-east5
us-west2
northamerica-northeast1
northamerica-northeast2
europe-north1
europe-west1
europe-west3
europe-west6
australia-southeast1
australia-southeast2
asia-northeast1
asia-northeast2
asia-southeast1
Non sono supportate altre regioni.
Questa operazione può richiedere fino a 15 minuti. Se vuoi osservare cosa succede durante la creazione, puoi visualizzare Esplora log nella console Google Cloud.
Se si verificano errori durante la creazione, consulta Risolvere i problemi di Config Controller per indicazioni sulla risoluzione dei problemi comuni.
Per verificare che le istanze di Config Controller siano state create, visualizza l'elenco di istanze di Config Controller:
gcloud anthos config controller list --location=LOCATION
Nella colonna dello stato dovresti vedere un valore
RUNNING
. Se lo stato èCREATING
, l'istanza di Config Controller è ancora in fase di creazione e devi continuare ad attendere. Se vediERROR
, hai riscontrato un problema che non riesci a risolvere autonomamente. Contatta l'Assistenza Google Cloud per ricevere supporto.Per comunicare con l'endpoint di Config Controller, recupera le credenziali e le informazioni appropriate:
gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \ --location LOCATION
Utilizza la tua istanza di Config Controller
Ora che hai creato un'istanza di Config Controller, puoi iniziare a utilizzare i componenti installati e completare le attività seguenti:
Utilizzare Config Connector per creare le risorse di Google Cloud. Se già disponi di risorse Google Cloud che vuoi utilizzare con Config Controller, scopri come acquisire una risorsa esistente.
Utilizza Policy Controller per applicare i vincoli che applicano la conformità normativa e gli standard Kubernetes.
Dopo aver configurato Config Sync, nella sezione seguente sincronizza l'istanza di Config Controller con le configurazioni (inclusi i vincoli di Policy Controller e le risorse di Config Connector) archiviate in una fonte attendibile.
Per un esempio guidato che mostra come completare queste attività con Config Controller, consulta Guida rapida: gestione delle risorse con Config Controller.
Configura l'istanza di Config Controller
Le sezioni seguenti spiegano come configurare i componenti dell'istanza di Config Controller.
Configura Config Connector
Non è necessario gestire alcuna impostazione per l'installazione di Config Connector. Tuttavia, devi concedere le autorizzazioni di Config Controller per gestire le risorse Google Cloud:
Imposta una variabile di ambiente per l'email dell'account di servizio:
export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \ -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
Crea l'associazione dei criteri:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:${SA_EMAIL}" \ --role "ROLE" \ --project PROJECT_ID
Sostituisci quanto segue:
PROJECT_ID
: il tuo ID progettoROLE
: un insieme di ruoli predefiniti o ruoli personalizzati che soddisfano le tue esigenze. In alternativa, puoi utilizzareroles/owner
per ambienti non di produzione. Per saperne di più sulle autorizzazioni IAM di Config Controller, consulta Autorizzazioni IAM per Config Controller.
Se l'operazione precedente non va a buon fine, controlla se i controller sono pronti:
kubectl wait pod --all --all-namespaces --for=condition=Ready
Dopo aver concesso queste autorizzazioni, puoi iniziare a creare risorse Google Cloud.
Configura Policy Controller
La configurazione di Policy Controller è facoltativa, ma puoi apportare modifiche all'installazione predefinita, se necessario.
Per configurare Policy Controller, modifica i campi spec.policyController
dell'oggetto ConfigManagement denominato config-management
. Config Controller crea automaticamente
questo oggetto ConfigManagement durante l'installazione. Quando modifichi l'oggetto
ConfigManagement, non impostare spec.policyController.enabled
su false
.
Config Controller esegue automaticamente l'override di questa modifica. Per il monitoraggio, devi anche consentire a Policy Controller di inviare le metriche.
Consenti a Policy Controller di inviare metriche eseguendo questo comando:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:PROJECT_ID.svc.id.goog[gatekeeper-system/gatekeeper-admin]" \
--role=roles/monitoring.metricWriter
Sostituisci PROJECT_ID
con l'ID progetto Google Cloud del cluster.
Configura Config Sync
Se vuoi che l'istanza di Config Controller sincronizzi le configurazioni archiviate in un'origine attendibile, devi configurare Config Sync.
Se vuoi utilizzare Config Sync per creare risorse di Config Connector, assicurati di aver concesso anche l'autorizzazione di Config Controller per la gestione delle risorse.
Per configurare Config Sync, crea e modifica un oggetto RootSync:
Per eseguire la sincronizzazione da un repository esterno (ad esempio GitHub), configura Cloud NAT con GKE. È necessario farlo perché i nodi del cluster privato non hanno accesso a internet in uscita.
Salva uno dei seguenti manifest come
root-sync.yaml
. Utilizza la versione del manifest corrispondente al tipo di origine per le configurazioni.Git
# root-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RootSync metadata: name: ROOT_SYNC_NAME namespace: config-management-system spec: sourceType: git sourceFormat: ROOT_FORMAT git: repo: ROOT_REPOSITORY revision: ROOT_REVISION branch: ROOT_BRANCH dir: ROOT_DIRECTORY auth: ROOT_AUTH_TYPE gcpServiceAccountEmail: ROOT_EMAIL secretRef: name: ROOT_SECRET_NAME noSSLVerify: ROOT_NO_SSL_VERIFY caCertSecretRef: name: ROOT_CA_CERT_SECRET_NAME
Sostituisci quanto segue:
ROOT_SYNC_NAME
: aggiungi il nome dell'oggetto RootSync.ROOT_FORMAT
: aggiungiunstructured
per utilizzare un repository non strutturato o aggiungihierarchy
per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito èhierarchy
. Ti consigliamo di aggiungereunstructured
poiché questo formato ti consente di organizzare le configurazioni nel modo più comodo per te.ROOT_REPOSITORY
: aggiungi l'URL del repository Git da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio,https://github.com/GoogleCloudPlatform/anthos-config-management-samples
utilizza il protocollo HTTPS. Questo campo è obbligatorio.ROOT_REVISION
: aggiungi la revisione Git (tag o hash) da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito èHEAD
. A partire da Config Sync versione 1.17.0, puoi anche specificare un nome ramo nel camporevision
. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.ROOT_BRANCH
: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito èmaster
. A partire da Config Sync versione 1.17.0, consigliamo di utilizzare il camporevision
per specificare un nome ramo per semplicità. Se sono specificati sia il camporevision
che il campobranch
,revision
ha la precedenza subranch
.ROOT_DIRECTORY
: aggiungi il percorso del repository Git alla directory radice contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory root (/
) del repository.ROOT_AUTH_TYPE
: aggiungi uno dei seguenti tipi di autenticazione:none
: nessuna autenticazionessh
: utilizza una coppia di chiavi SSHcookiefile
: usa uncookiefile
token
: usa un tokengcpserviceaccount
: utilizza un account di servizio Google per accedere a Cloud Source Repositories.gcenode
: utilizza un account di servizio Google per accedere a Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.
Per maggiori informazioni su questi tipi di autenticazione, consulta Concedere a Config Sync l'accesso di sola lettura a Git.
Questo campo è obbligatorio.
ROOT_EMAIL
: se hai aggiuntogcpserviceaccount
comeROOT_AUTH_TYPE
, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio,acm@PROJECT_ID.iam.gserviceaccount.com
.ROOT_SECRET_NAME
: aggiungi il nome del secret. Se questo campo è impostato, devi aggiungere la chiave pubblica del secret al provider Git. Questo campo è facoltativo.ROOT_NO_SSL_VERIFY
: per disabilitare la verifica del certificato SSL, imposta questo campo sutrue
. Il valore predefinito èfalse
.ROOT_CA_CERT_SECRET_NAME
: aggiungi il nome del tuo Secret. Se questo campo viene impostato, il tuo provider Git deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominatacert
. Questo campo è facoltativo.Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'operatore per un'autorità di certificazione
Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo
spec
, consulta Campi RootSync.Questo manifest crea un oggetto
RootSync
che utilizza Git come origine.OCI
# root-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RootSync metadata: name: ROOT_SYNC_NAME namespace: config-management-system spec: sourceType: oci sourceFormat: ROOT_FORMAT oci: image: ROOT_IMAGE dir: ROOT_DIRECTORY auth: ROOT_AUTH_TYPE gcpServiceAccountEmail: ROOT_EMAIL caCertSecretRef: name: ROOT_CA_CERT_SECRET_NAME
Sostituisci quanto segue:
ROOT_SYNC_NAME
: aggiungi il nome dell'oggetto RootSync.ROOT_FORMAT
: aggiungiunstructured
per utilizzare un repository non strutturato o aggiungihierarchy
per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito èhierarchy
. Ti consigliamo di aggiungereunstructured
poiché questo formato ti consente di organizzare le configurazioni nel modo più comodo per te.ROOT_IMAGE
: l'URL dell'immagine OCI da utilizzare come repository principale, ad esempioLOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME
. Per impostazione predefinita, l'immagine viene estratta dal taglatest
, ma puoi estrarre le immagini in base aTAG
oDIGEST
. SpecificaTAG
oDIGEST
inPACKAGE_NAME
:- Per eseguire il pull in base a
TAG
:LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
- Per eseguire il pull in base a
DIGEST
:LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
- Per eseguire il pull in base a
ROOT_DIRECTORY
: aggiungi il percorso del repository alla directory radice contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory root (/
) del repository.ROOT_AUTH_TYPE
: aggiungi uno dei seguenti tipi di autenticazione:none
: nessuna autenticazionegcenode
: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.gcpserviceaccount
: utilizza un account di servizio Google per accedere a un'immagine.
Questo campo è obbligatorio.
ROOT_EMAIL
: se hai aggiuntogcpserviceaccount
comeROOT_AUTH_TYPE
, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio,acm@PROJECT_ID.iam.gserviceaccount.com
.ROOT_CA_CERT_SECRET_NAME
: aggiungi il nome del tuo Secret. Se questo campo viene impostato, il provider OCI deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominatacert
. Questo campo è facoltativo.
Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'operatore per un'autorità di certificazione
Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo
spec
, consulta Campi RootSync.Questo manifest crea un oggetto
RootSync
che utilizza un'immagine OCI come origine.Helm
# root-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RootSync metadata: name: ROOT_SYNC_NAME namespace: config-management-system spec: sourceType: helm sourceFormat: ROOT_FORMAT helm: repo: ROOT_HELM_REPOSITORY chart: HELM_CHART_NAME version: HELM_CHART_VERSION releaseName: HELM_RELEASE_NAME namespace: HELM_RELEASE_NAMESPACE values: foo: bar: VALUE_1 baz: - qux: VALUE_2 xyz: VALUE_3 includeCRDs: HELM_INCLUDE_CRDS auth: ROOT_AUTH_TYPE gcpServiceAccountEmail: ROOT_EMAIL secretRef: name: ROOT_SECRET_NAME caCertSecretRef: name: ROOT_CA_CERT_SECRET_NAME
Sostituisci quanto segue:
ROOT_SYNC_NAME
: aggiungi il nome dell'oggetto RootSync.ROOT_FORMAT
: aggiungiunstructured
per utilizzare un repository non strutturato o aggiungihierarchy
per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito èhierarchy
. Ti consigliamo di aggiungereunstructured
poiché questo formato ti consente di organizzare le configurazioni nel modo più comodo per te.ROOT_HELM_REPOSITORY
: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio,https://github.com/GoogleCloudPlatform/anthos-config-management-samples
utilizza il protocollo HTTPS. Questo campo è obbligatorio.HELM_CHART_NAME
: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.HELM_CHART_VERSION
: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata l'ultima versione.HELM_RELEASE_NAME
: il nome della release Helm. Questo campo è facoltativo.HELM_RELEASE_NAMESPACE
: lo spazio dei nomi target per una release. Imposta uno spazio dei nomi solo per le risorse che contengononamespace: {{ .Release.Namespace }}
nei modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinitoconfig-management-system
.HELM_INCLUDE_CRDS
: impostalo sutrue
se vuoi che il modello Helm generi anche una CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito èfalse
e non verrà generato un CRD.VALUE
: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo come nel file helm chart's values.yaml. Questo campo è facoltativo.ROOT_AUTH_TYPE
: aggiungi uno dei seguenti tipi di autenticazione:none
: nessuna autenticazionetoken
: utilizza un nome utente e una password per accedere a un repository Helm privato.gcenode
: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.gcpserviceaccount
: utilizza un account di servizio Google per accedere a un'immagine.
Questo campo è obbligatorio.
ROOT_EMAIL
: se hai aggiuntogcpserviceaccount
comeROOT_AUTH_TYPE
, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio,acm@PROJECT_ID.iam.gserviceaccount.com
.ROOT_SECRET_NAME
: aggiungi il nome del tuo secret setoken
èROOT_AUTH_TYPE
. Questo campo è facoltativo.ROOT_CA_CERT_SECRET_NAME
: aggiungi il nome del tuo Secret. Se questo campo viene impostato, il provider Helm deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominatacert
. Questo campo è facoltativo.
Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'operatore per un'autorità di certificazione
Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo
spec
, consulta Campi RootSync.Questo manifest crea un oggetto
RootSync
che utilizza Helm come origine.Per creare la configurazione di Config Sync, crea un oggetto RootSync applicando il manifest:
kubectl apply -f root-sync.yaml
Per verificare che le modifiche siano state applicate, visualizza l'oggetto RootSync:
kubectl describe rootsync ROOT_SYNC_NAME -n config-management-system
Esegui l'upgrade di Config Controller
Poiché Config Controller è un servizio gestito, Google lo esegue automaticamente. Per maggiori dettagli sulle nuove funzionalità e per scoprire quali versioni di Config Sync, Policy Controller e Config Connector vengono utilizzate da Config Controller, consulta le note di rilascio di Config Controller.
Elimina l'istanza di Config Controller
Se decidi di interrompere l'utilizzo di un'istanza di Config Controller, esegui la pulizia di tutte le risorse di Config Connector create prima di eliminare il cluster stesso di Config Controller.
Se elimini l'istanza di Config Controller senza prima eliminare le risorse di cui è stato eseguito il provisioning, le risorse rimangono in uno stato abbandonata. Le risorse esistono ancora in Google Cloud (e sono soggette ad addebiti), ma non sono gestite dalla configurazione dichiarativa.
Dopo aver eliminato tutte le risorse, elimina il cluster di Config Controller:
gcloud anthos config controller delete \
--location=LOCATION CONFIG_CONTROLLER_NAME
Considerazioni sulla produzione
Durante il passaggio in produzione, devi prima esaminare le considerazioni sull'alta disponibilità per Config Controller.
Passaggi successivi
- Scopri le best practice per la scalabilità di Config Controller
- Risolvi i problemi di Config Controller.
- Richiedere assistenza.
- Scopri di più sulla sincronizzazione di configurazioni e criteri con Config Sync.
- Scopri di più sull'applicazione di criteri con Policy Controller.
- Scopri di più sulle risorse di Config Connector.