Installazione tramite DHCP

Questa pagina spiega come installare GKE On-Prem in un ambiente VMware vSphere 6.5 utilizzando un server DHCP (Dynamic Host Configuration Protocol) esistente per assegnare indirizzi IP ai nodi del cluster. Puoi anche installarlo utilizzando IP statici.

Panoramica

Le istruzioni in questa pagina mostrano come creare un cluster di amministrazione e un cluster utente con tre nodi. Ogni nodo viene eseguito su una macchina virtuale (VM) in un cluster vSphere e ogni nodo ha un indirizzo IP assegnato da un server DHCP nel tuo ambiente.

Dopo aver creato i cluster, puoi crearne altri e aggiungerli o rimuoverli in un cluster utente.

Prima di iniziare

  1. Configura l'ambiente on-prem come descritto in Requisiti di sistema.

  2. Completa le procedure descritte in Preparare l'installazione.

  3. Crea una workstation di amministrazione in vSphere.

  4. Accedi alla tua workstation di amministrazione tramite SSH:

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

  5. Se utilizzi un proxy, devi configurare Google Cloud CLI per il proxy, in modo da poter eseguire i comandi gcloud e gsutil. Per istruzioni, consulta la pagina sulla configurazione dell'interfaccia a riga di comando gcloud da utilizzare dietro un proxy/firewall.

  6. Accedi a Google Cloud utilizzando le credenziali del tuo account:

    gcloud auth login

  7. Registra gcloud come assistente credenziali di Docker. Scopri di più su questo comando:

    gcloud auth configure-docker

  8. Imposta un progetto predefinito. L'impostazione di un ambiente Google Cloud predefinito comporta l'esecuzione di tutti i comandi dell'interfaccia a riga di comando gcloud sul progetto, quindi non è necessario specificare il progetto per ogni comando:

    gcloud config set project [PROJECT_ID]

    Sostituisci [PROJECT_ID] con l'ID progetto. Puoi trovare l'ID progetto nella console Google Cloud o eseguendo gcloud config get-value project.

Utilizzo delle prenotazioni DHCP per i nodi del cluster

In Kubernetes, è importante che gli indirizzi IP dei nodi non cambino mai. Se un indirizzo IP del nodo cambia o non è più disponibile, può interrompere il cluster. Per evitare ciò, valuta la possibilità di utilizzare le prenotazioni DHCP per assegnare i nodi di indirizzi permanenti nei tuoi cluster di amministrazione e utente. L'utilizzo delle prenotazioni DHCP garantisce che a ogni nodo vengano assegnati gli stessi indirizzi IP dopo il riavvio o il rinnovo del lease.

Scelta di un registro di immagini container per l'installazione

Per eseguire l'installazione, GKE On-Prem deve sapere dove eseguire il pull dei suoi componenti cluster containerizzati. Puoi scegliere tra due opzioni:

Container Registry

Per impostazione predefinita, GKE On-Prem utilizza un registro di immagini container esistente di proprietà di Google ospitato da Container Registry. Oltre a configurare il tuo proxy per consentire il traffico da gcr.io, questa operazione non richiede una configurazione aggiuntiva.

Registro Docker privato

Puoi scegliere di utilizzare un registro Docker privato per l'installazione. GKE On-Prem esegue il push dei componenti del cluster al registro Docker.

Prima dell'installazione, devi configurare il Registro di sistema. Durante l'installazione, devi compilare il file di configurazione di GKE On-Prem con le informazioni sul registro.

(Facoltativo) Configurare un registro Docker privato per l'installazione

Questa sezione spiega come configurare un registro Docker esistente per l'installazione di GKE On-Prem. Per scoprire come creare un registro Docker, consulta Eseguire un registro accessibile esternamente. Dopo aver configurato il registro, compila il campo privateregistryconfig del file di configurazione di GKE On-Prem.

Se vuoi utilizzare un registro Docker privato per l'installazione, la VM della tua workstation di amministrazione deve considerare attendibile la CA che ha firmato il tuo certificato. GKE On-Prem non supporta i registri Docker non protetti. Quando avvii il registro Docker, devi fornire un certificato e una chiave. Il certificato può essere firmato da un'autorità di certificazione pubblica (CA) o in autonomia.

Per stabilire questo trust, esegui i passaggi seguenti dalla VM della workstation di amministrazione:

  1. Crea una cartella in cui conservare il certificato:

    sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]

    dove [REGISTRY_SERVER] è l'indirizzo IP o il nome host della VM che esegue il registro Docker.

  2. Copia il file del certificato in /etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt. Devi assegnare un nome al file ca.crt, anche se in origine aveva un nome diverso.

  3. Riavvia il servizio Docker:

    sudo service docker restart

  4. Verifica di poter accedere a Docker:

    docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]

    dove [USERNAME] e [PASSWORD] sono le credenziali per l'accesso al registro Docker.

Ora, quando esegui gkectl prepare durante l'installazione, viene eseguito il push delle immagini necessarie per l'installazione nel registro Docker.

Risoluzione dei problemi di configurazione del Registro di sistema

  • GET https://[REGISTRY_SERVER]/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers): Assicurati di avere l'indirizzo IP corretto della VM che esegue il tuo registro Docker.

  • login attempt to https://[REGISTRY_SERVER]/v2/ failed with status: 401 Unauthorized: Verifica che il tuo nome utente e la password siano corretti.

  • GET https://[REGISTRY_SERVER]/v1/users/: x509: certificate signed by unknown authority: la VM della workstation di amministrazione non considera attendibile il certificato.

Crea le chiavi private degli account di servizio nella workstation di amministrazione

In Preparazione all'installazione, hai creato quattro account di servizio. Ora devi creare un file di chiave privata JSON per ciascuno di questi account di servizio. Dovrai fornire queste chiavi durante l'installazione.

Elenca gli indirizzi email degli account di servizio

Elenca prima gli account di servizio nel progetto Google Cloud:

gcloud iam service-accounts list

Per un progetto Google Cloud denominato my-gcp-project, l'output di questo comando sarà il seguente:

gcloud iam service-accounts list
NAME                                    EMAIL
                                        access-service-account@my-gcp-project.iam.gserviceaccount.com
                                        register-service-account@my-gcp-project.iam.gserviceaccount.com
                                        connect-service-account@my-gcp-project.iam.gserviceaccount.com
                                        stackdriver-service-account@my-gcp-project.iam.gserviceaccount.com

Prendi nota dell'indirizzo email di ogni account. L'account email pertinente viene fornito per ciascuna delle seguenti sezioni.

Accesso all'account di servizio

gcloud iam service-accounts keys create access-key.json \
--iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]

dove [ACCESS_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio di accesso.

Registra account di servizio

gcloud iam service-accounts keys create register-key.json \
--iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]

dove [REGISTER_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio di registrazione.

Connetti account di servizio

gcloud iam service-accounts keys create connect-key.json \
--iam-account [CONNECT_SERVICE_ACCOUNT_EMAIL]

dove [CONNECT_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio di connessione.

Account di servizio Cloud Monitoring

gcloud iam service-accounts keys create stackdriver-key.json \
--iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]

dove [STACKDRIVER_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio di Cloud Monitoring.

Attivazione dell'account di servizio di accesso per Google Cloud CLI

L'attivazione dell'account di servizio di accesso per l'interfaccia a riga di comando gcloud fa sì che tutti i comandi gcloud e gsutil vengano eseguiti come quell'account di servizio. Poiché il tuo account di servizio di accesso è incluso nella lista consentita per l'accesso ai binari di GKE On-Prem, l'attivazione dell'account per gcloud CLI ti autorizza a scaricare i programmi binari di GKE On-Prem da Cloud Storage.

Per attivare l'account di servizio di accesso, esegui il comando seguente. Assicurati di fornire il percorso del file della chiave dell'account se non si trova nella directory di lavoro attuale:

gcloud auth activate-service-account --key-file=access-key.json

Generazione di un file di configurazione

Per avviare un'installazione, esegui gkectl create-config per generare un file di configurazione. Puoi modificare il file con le specifiche dell'ambiente e con quelle che preferisci.

Per generare il file, esegui questo comando, dove --config [PATH] è facoltativo e accetta un percorso e un nome per il file di configurazione. L'omissione di --config crea config.yaml nella directory di lavoro attuale:

gkectl create-config [--config [PATH]]

Modificare il file di configurazione

Ora che hai generato il file di configurazione, devi modificarlo per adattarlo all'ambiente e soddisfare le tue aspettative per i tuoi cluster. Le sezioni seguenti spiegano ogni campo, i valori previsti e dove potresti trovare le informazioni. Alcuni campi sono commentati per impostazione predefinita. Se alcuni di questi campi sono pertinenti per l'installazione, rimuovi il commento e fornisci i valori.

bundlepath

Un bundle GKE On-Prem è un insieme di file YAML. Collettivamente, i file YAML descrivono tutti i componenti in una specifica release di GKE On-Prem.

Quando crei una workstation di amministrazione, questa include un bundle di /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz. La versione di questo bundle corrisponde alla versione dell'OVA che hai utilizzato per creare la workstation di amministrazione.

Imposta il valore di bundlepath sul percorso del file del bundle della workstation di amministrazione. In altre parole, imposta bundlepath su:

/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz

dove [VERSION] è la versione di GKE On-Prem che stai installando. L'ultima versione è 1.1.2-gke.0.

Tieni presente che puoi liberare il file del bundle in una posizione diversa o assegnargli un nome diverso. Assicurati che nel file di configurazione il valore di bundlepath corrisponda al percorso del file del bundle, qualunque sia.

Specifica vCenter

La specifica vCenter Server, vcenter, contiene le informazioni sulla tua istanza vCenter Server che GKE On-Prem deve installare nel tuo ambiente.

vcenter.credentials.address

Il campo vcenter.credentials.address contiene l'indirizzo IP o il nome host del server vCenter.

Prima di compilare il vsphere.credentials.address field, scarica e controlla il certificato di pubblicazione del server vCenter. Inserisci questo comando per scaricare il certificato e salvarlo in un file denominato vcenter.pem.

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

Apri il file del certificato per vedere il nome comune del soggetto e il nome alternativo del soggetto:

openssl x509 -in vcenter.pem -text -noout

L'output mostra il Common Name (CN) di Subject. Potrebbe essere un indirizzo IP o un nome host. Ad esempio:

Subject: ... CN = 203.0.113.100
Subject: ... CN = my-host.my-domain.example

L'output potrebbe anche includere uno o più nomi DNS in Subject Alternative Name:

X509v3 Subject Alternative Name:
    DNS:vcenter.my-domain.example

Scegli il nome comune Subject o uno dei nomi DNS in Subject Alternative Name da utilizzare come valore vcenter.credentials.address nel file di configurazione. Ad esempio:

vcenter:
  credentials:
    address: "203.0.113.1"
    ...

vcenter:
  credentials:
    address: "my-host.my-domain.example"
    ...

Devi scegliere un valore visualizzato nel certificato. Ad esempio, se l'indirizzo IP non compare nel certificato, non puoi utilizzarlo per vcenter.credentials.address.

vcenter.credentials

GKE On-Prem deve conoscere il nome utente e la password di vCenter Server. Per fornire queste informazioni, imposta i valori username e password in vcenter.credentials. Ad esempio:

vcenter:
  credentials:
    ...
    username: "my-name"
    password: "my-password"

vcenter.datacenter, .datastore, .cluster, .network

GKE On-Prem ha bisogno di alcune informazioni sulla struttura del tuo ambiente vSphere. Per fornire queste informazioni, imposta i valori in vcenter. Ad esempio:

vcenter:
  ...
  datacenter: "MY-DATACENTER"
  datastore: "MY-DATASTORE"
  cluster: "MY-VSPHERE-CLUSTER"
  network: "MY-VIRTUAL-NETWORK"

vcenter.resourcepool

Un pool di risorse vSphere è un raggruppamento logico di VM vSphere nel cluster vSphere. Se utilizzi un pool di risorse diverso da quello predefinito, specifica il nome in vcenter.resourcepool. Ad esempio:

vcenter:
  ...
  resourcepool: "my-pool"

Se vuoi che GKE On-Prem esegua il deployment dei nodi nel pool di risorse predefinito del cluster vSphere, fornisci una stringa vuota a vcenter.resourcepool. Ad esempio:

vcenter:
  ...
  resourcepool: ""

vcenter.datadisk

GKE On-Prem crea un disco di macchina virtuale (VMDK) per conservare i dati degli oggetti Kubernetes per il cluster di amministrazione. Il programma di installazione crea automaticamente il VMDK, ma devi fornire un nome per il VMDK nel campo vcenter.datadisk. Ad esempio:

vcenter:
  ...
  datadisk: "my-disk.vmdk"
Datastore vSAN: creazione di una cartella per il VMDK

Se utilizzi un datastore vSAN, devi inserire il VMDK in una cartella. La cartella deve essere creata manualmente in anticipo. Per farlo, puoi utilizzare govc per creare una cartella:

govc datastore.mkdir my-gke-on-prem-folder

Attualmente, un problema noto richiede che tu fornisca a vcenter.datadisk il percorso dell'identificatore univoco universale (UUID) della cartella anziché il relativo percorso file. Per trovare l'UUID della cartella, apri il client vCenter, seleziona il datastore, quindi seleziona la cartella. Copia l'UUID della cartella. Puoi anche eseguire il comando seguente, dove [ADMIN_CONTROL_PLANE_VM] è la VM vSphere che esegue il piano di controllo dell'amministratore:

govc vm.info -json ./vm/[ADMIN_CONTROL_PLANE_VM] | jq '.VirtualMachines[0].Config.Hardware.Device[] | select(.Backing | has("FileName")) | .Backing.FileName'

Quindi, fornisci l'UUID della cartella nel campo vcenter.datadisk. Ad esempio:

vcenter:
...
datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"

vcenter.cacertpath

Quando un client, come GKE On-Prem, invia una richiesta a vCenter Server, il server deve dimostrare la propria identità al client presentando un certificato. Il certificato è firmato da un'autorità di certificazione (CA). Il client verifica il certificato del server utilizzando il certificato della CA.

Imposta vcenter.cacertpath sul percorso del certificato dell'autorità di certificazione. Ad esempio:

vcenter:
  ...
  cacertpath: "/my-cert-folder/altostrat.crt"

Che il tuo server vCenter utilizzi un certificato autofirmato o un certificato firmato da una CA pubblica, puoi ottenere il certificato della CA eseguendo questo comando sulla workstation di amministrazione:

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

dove [VCENTER_IP] è l'indirizzo IP del tuo server vCenter.

Specifica del proxy

Il campo proxy contiene le informazioni sul proxy HTTPS fornito dall'utente e gli indirizzi che devono essere esclusi dal proxy. Ad esempio:

proxy:
  url: "https://password:username@domain"
  noproxy: "100.151.222.0/24,corp.domain,100.151.2.1"
  • proxy.url è l'URL del proxy HTTPS.
  • proxy.noproxy include il CIDR, i domini e gli indirizzi IP che non devono utilizzare il proxy. In genere ciò include la subnet vSphere e l'indirizzo del Registro di sistema privato se utilizzi un registro Docker privato.

Specifica del cluster di amministrazione

Il cluster di amministrazione, admincluster, contiene le informazioni necessarie a GKE On-Prem per creare il cluster di amministrazione.

admincluster.vcenter.network

In admincluster.vcenter.network, puoi specificare una rete vCenter per i nodi del cluster di amministrazione. Tieni presente che questa operazione sostituisce l'impostazione globale fornita in vcenter. Ad esempio:

admincluster:
  vcenter:
    network: MY-ADMIN-CLUSTER-NETWORK

admincluster.ipblockfilepath

Questo campo viene utilizzato se utilizzi IP statici. Poiché stai utilizzando un server DHCP per allocare indirizzi IP, lascia vuoto il campo admincluster.ipblockfilepath.

admincluster.bigip.credentials (modalità di bilanciamento del carico integrata)

Se utilizzi la modalità di bilanciamento del carico integrata, GKE On-Prem deve conoscere l'indirizzo IP o il nome host, il nome utente e la password del bilanciatore del carico F5 BIG-IP. Imposta i valori sotto admincluster.bigip per fornire queste informazioni. Ad esempio:

admincluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.2"
      username: "my-admin-f5-name"
      password: "rJDlm^%7aOzw"

admincluster.bigip.credentials (modalità di bilanciamento del carico integrata)

Se utilizzi la modalità di bilanciamento del carico integrata, devi creare una partizione BIG-IP per il tuo cluster di amministrazione. Imposta admincluster.bigip.partition sul nome della partizione. Ad esempio:

admincluster:
  ...
  bigip:
    partition: "my-admin-f5-partition"

admincluster.vips

Imposta il valore di admincluster.vips.controlplanevip sull'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster di amministrazione. Imposta il valore ingressvip sull'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il controller Ingress in entrata nel cluster di amministrazione. Ad esempio:

admincluster:
  ...
  vips:
    controlplanevip: 203.0.113.3
    ingressvip: 203.0.113.4

admincluster.serviceiprange e admincluster.podiprange

Il cluster di amministrazione deve avere un intervallo di indirizzi IP da utilizzare per i servizi e un intervallo di indirizzi IP da utilizzare per i pod. Questi intervalli sono specificati dai campi admincluster.serviceiprange e admincluster.podiprange. Questi campi vengono compilati quando esegui gkectl create-config. Se vuoi, puoi modificare i valori compilati con quelli di tua scelta.

Gli intervalli di servizi e pod non devono sovrapporsi. Inoltre, gli intervalli di servizi e pod non devono sovrapporsi agli indirizzi IP utilizzati per i nodi in qualsiasi cluster.

Esempio:

admincluster:
  ...
  serviceiprange: 10.96.232.0/24
  podiprange: 192.168.0.0/16

Specifica del cluster utente

La specifica del cluster utente usercluster contiene le informazioni necessarie a GKE On-Prem per creare il cluster utente iniziale.

Disabilitazione delle regole anti-affinità DRS di VMware (facoltativo)

A partire dalla versione 1.1.0-gke.6, GKE On-Prem crea automaticamente le regole di anti-affinità VMware Distributed Resource Scheduler (DRS) per i nodi del cluster utente, in modo da distribuirle in almeno tre host fisici del data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità viene attivata automaticamente per i nuovi cluster e per i cluster esistenti.

Questa funzionalità richiede che l'ambiente vSphere soddisfi le seguenti condizioni:

  • DRS VMware è abilitato. VMware DRS richiede l'edizione della licenza vSphere Enterprise Plus. Per informazioni su come abilitare DRS, consulta Creazione di un cluster DRS.
  • L'account utente vSphere fornito nel campo vcenter dispone dell'autorizzazione Host.Inventory.EditCluster.
  • Sono disponibili almeno tre host fisici.

Se non hai abilitato DRS o se non hai almeno tre host in cui è possibile pianificare le VM vSphere, aggiungi usercluster.antiaffinitygroups.enabled: false al file di configurazione. Ad esempio:

usercluster:
  ...
  antiaffinitygroups:
    enabled: false
Per i cluster che eseguono più di tre nodi
Se vSphere vMotion sposta un nodo in un host diverso, i carichi di lavoro del nodo dovranno essere riavviati prima di essere distribuiti nuovamente tra gli host.

usercluster.vcenter.network

In usercluster.vcenter.network, puoi specificare una rete vCenter per i nodi del cluster utente. Tieni presente che questa operazione sostituisce l'impostazione globale fornita in vcenter. Ad esempio:

usercluster:
  vcenter:
    network: MY-USER-CLUSTER-NETWORK

usercluster.ipblockfilepath

Questo campo viene utilizzato se utilizzi IP statici. Poiché stai utilizzando un server DHCP per allocare indirizzi IP, lascia vuoto il campo usercluster.ipblockfilepath.

usercluster.bigip.credentials (modalità di bilanciamento del carico integrata)

Se utilizzi la modalità di bilanciamento del carico integrata, GKE On-Prem deve conoscere l'indirizzo IP o il nome host, il nome utente e la password del bilanciatore del carico BIG-IP F5 che intendi utilizzare per il cluster utente. Imposta i valori in usercluster.bigip per fornire queste informazioni. Ad esempio:

usercluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.5"
      username: "my-user-f5-name"
      password: "8%jfQATKO$#z"
  ...

usercluster.bigip.partition (modalità di bilanciamento del carico integrata)

Devi creare una partizione BIG-IP per il tuo cluster utente. Imposta usercluster.bigip.partition sul nome della partizione. Ad esempio:

usercluster:
  ...
  bigip:
    partition: "my-user-f5-partition"
  ...

usercluster.vips

Imposta il valore usercluster.vips.controlplanevip sull'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente. Imposta il valore di ingressvip sull'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il controller Ingress in entrata del cluster utente. Ad esempio:

usercluster:
  ...
  vips:
    controlplanevip: 203.0.113.6
    ingressvip: 203.0.113.7

usercluster.serviceiprange e usercluster.podiprange

Il cluster utente deve avere un intervallo di indirizzi IP da utilizzare per i servizi e un intervallo di indirizzi IP da utilizzare per i pod. Questi intervalli sono specificati dai campi usercluster.serviceiprange e usercluster.podiprange. Questi campi vengono compilati quando esegui gkectl create-config. Se vuoi, puoi modificare i valori compilati con quelli di tua scelta.

Gli intervalli di servizi e pod non devono sovrapporsi. Inoltre, gli intervalli di servizi e pod non devono sovrapporsi agli indirizzi IP utilizzati per i nodi in qualsiasi cluster.

Esempio:

usercluster:
  ...
  serviceiprange: 10.96.233.0/24
  podiprange: 172.16.0.0/12

usercluster.clustername

Imposta il valore di usercluster.clustername con un nome a tua scelta. Scegli un nome che non superi i 40 caratteri. Ad esempio:

usercluster:
  ...
  clustername: "my-user-cluster-1"

usercluster.masternode.replicas

Il campo usercluster.masternode.replicas specifica il numero di nodi del piano di controllo che vuoi che il cluster utente abbia. Il nodo del piano di controllo di un cluster utente esegue il piano di controllo utente, i componenti del piano di controllo Kubernetes. Questo valore deve essere 1 o 3:

  • Imposta questo campo su 1 per eseguire un piano di controllo dell'utente.
  • Imposta questo campo su 3 se vuoi che abbia un piano di controllo dell'utente ad alta disponibilità composto da tre nodi del piano di controllo, ognuno dei quali esegue un piano di controllo dell'utente.

usercluster.masternode.cpus e usercluster.masternode.memorymb

I campi usercluster.masternode.cpus e usercluster.masternode.memorymb specificano quante CPU e quanta memoria, in megabyte, è allocata a ciascun nodo del piano di controllo del cluster utente. Ad esempio:

usercluster:
  ...
  masternode:
    cpus: 4
    memorymb: 8192

usercluster.workernode.replicas

Il campo usercluster.workernode.replicas specifica il numero di nodi worker che vuoi che il cluster utente abbia. I nodi worker eseguono i carichi di lavoro del cluster.

usercluster.workernode.cpus e usercluster.workernode.memorymb

I campi usercluster.masternode.cpus e usercluster.masternode.memorymb specificano quante CPU e quanta memoria, in megabyte, è allocata a ciascun nodo worker del cluster utente. Ad esempio:

usercluster:
  ...
  workernode:
    cpus: 4
    memorymb: 8192
    replicas: 3

usercluster.oidc

Se vuoi che i client del cluster utente utilizzino l'autenticazione OIDC, imposta i valori per i campi in usercluster.oidc. La configurazione dell'OIDC è facoltativa.

Per scoprire come configurare OIDC, consulta Autenticazione con OIDC.

Informazioni sull'installazione della versione 1.0.2-gke.3

La versione 1.0.2-gke.3 introduce i seguenti campi OIDC (usercluster.oidc). Questi campi consentono di accedere a un cluster dalla console Google Cloud:

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Nella versione 1.0.2-gke.3, se vuoi utilizzare OIDC, il campo clientsecret è obbligatorio anche se non vuoi accedere a un cluster da Google Cloud Console. In tal caso, puoi fornire un valore segnaposto per clientsecret:

oidc:
clientsecret: "secret"

usercluster.sni

L'indicazione del nome del server (SNI), un'estensione di Transport Layer Security (TLS), consente ai server di presentare più certificati su un singolo indirizzo IP e una porta TCP, a seconda del nome host indicato dal client.

Se la tua CA è già distribuita come CA attendibile ai client esterni al tuo cluster utente e vuoi fare affidamento su questa catena per identificare i cluster attendibili, puoi configurare il server API Kubernetes con un certificato aggiuntivo che viene presentato ai client esterni dell'indirizzo IP del bilanciatore del carico.

Per utilizzare SNI con i tuoi cluster utente, devi avere una CA e una infrastruttura a chiave pubblica (PKI). Esegui il provisioning di un certificato di pubblicazione separato per ogni cluster utente e GKE On-Prem aggiunge ogni certificato di pubblicazione aggiuntivo al rispettivo cluster utente.

Per configurare SNI per il server API Kubernetes del cluster utente, fornisci i valori per usercluster.sni.certpath (percorso del certificato esterno) e usercluster.sni.keypath (percorso del file della chiave privata del certificato esterno). Ad esempio:

usercluster:
  ...
  sni:
    certpath: "/my-cert-folder/example.com.crt"
    keypath: "/my-cert-folder/example.com.key"

lbmode

Puoi utilizzare il bilanciamento del carico integrato con DHCP. La modalità di bilanciamento del carico integrata si applica al cluster di amministrazione e al cluster utente iniziale. Si applica anche a eventuali cluster utente aggiuntivi che creerai in futuro. Integra la modalità di bilanciamento del carico utilizzando F5 BIG-IP come bilanciatore del carico.

Imposta il valore di lbmode su Integrated. Ad esempio:

lbmode: Integrated

gkeconnect

La specifica gkeconnect contiene le informazioni necessarie a GKE On-Prem per configurare la gestione dei cluster on-prem da Google Cloud Console.

Imposta gkeconnect.projectid sull'ID del progetto Google Cloud in cui vuoi gestire i tuoi cluster on-prem.

Imposta il valore gkeconnect.registerserviceaccountkeypath sul percorso del file della chiave JSON per l'account di servizio di registrazione. Imposta il valore gkeconnect.agentserviceaccountkeypath sul percorso del file della chiave JSON per l'account di servizio di connessione.

Se vuoi che l'agente Connect utilizzi un proxy per comunicare con Google Cloud, imposta il valore gkeconnect.proxy nell'URL del proxy. Utilizza il formato http(s)://[PROXY_ADDRESS].

Esempio:

gkeconnect:
  projectid: "my-project"
  registerserviceaccountkeypath: "/my-key-folder/register-key.json"
  agentserviceaccountkeypath: "/my-key-folder/connect-key.json"
  proxy: https://203.0.113.20

stackdriver

La specifica stackdriver contiene le informazioni necessarie a GKE On-Prem per archiviare le voci di log generate dai cluster on-prem.

Imposta stackdriver.projectid sull'ID del progetto Google Cloud in cui vuoi visualizzare i log di Stackdriver relativi ai tuoi cluster on-prem.

Imposta stackdriver.clusterlocation in una regione Google Cloud in cui vuoi archiviare i log di Stackdriver. È consigliabile scegliere una regione vicina al data center on-premise.

Imposta stackdriver.enablevpc su true se la rete del cluster è controllata da un VPC. Ciò garantisce che tutta la telemetria passi attraverso gli indirizzi IP limitati di Google.

Imposta stackdriver.serviceaccountkeypath sul percorso del file della chiave JSON per l'account di servizio Stackdriver Logging. Ad esempio:

stackdriver:
  projectid: "my-project"
  clusterlocation: "us-west1"
  enablevpc: false
  serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"

privateregistryconfig

Se hai un registro Docker privato, il campo privateregistryconfig contiene le informazioni che GKE On-Prem utilizza per eseguire il push delle immagini al registro privato. Se non specifichi un registro privato, gkectl estrae le immagini container di GKE On-Prem dal suo repository Container Registry, gcr.io/gke-on-prem-release, durante l'installazione.

In privatedockerregistry.credentials, imposta address sull'indirizzo IP della macchina che esegue il registro Docker privato. Imposta username e password il nome utente e la password del registro Docker privato.

Quando Docker estrae un'immagine dal registro privato, il registro deve dimostrare la propria identità presentando un certificato. Il certificato del registry viene firmato da un'autorità di certificazione (CA). Docker utilizza il certificato della CA per convalidare il certificato del Registro di sistema.

Imposta privateregistryconfig.cacertpath sul percorso del certificato dell'autorità di certificazione. Ad esempio:

privateregistryconfig
  ...
  cacertpath: /my-cert-folder/registry-ca.crt

gcrkeypath

Imposta il valore di gcrkeypath sul percorso del file della chiave JSON del tuo account di servizio di accesso. Ad esempio:

gcrkeypath: "/my-key-folder/access-key.json"

cloudauditlogging

Se vuoi inviare gli audit log di Kubernetes al progetto Google Cloud, compila la specifica cloudauditlogging. Ad esempio:

cloudauditlogging:
  projectid: "my-project"
  # A GCP region where you would like to store audit logs for this cluster.
  clusterlocation: "us-west1"
  # The absolute or relative path to the key file for a GCP service account used to
  # send audit logs from the cluster
  serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"

Scopri di più sull'utilizzo dell'audit logging.

Convalida del file di configurazione

Dopo aver modificato il file di configurazione, esegui gkectl check-config per verificare che il file sia valido e possa essere utilizzato per l'installazione:

gkectl check-config --config [PATH_TO_CONFIG]

Se il comando restituisce un messaggio FAILURE, correggi i problemi e convalida di nuovo il file.

Salta le convalide

I seguenti comandi gkectl eseguono automaticamente le convalide sul file di configurazione:

  • gkectl prepare
  • gkectl create cluster
  • gkectl upgrade

Per saltare le convalide di un comando, passa --skip-validation-all. Ad esempio, per saltare tutte le convalide per gkectl prepare:

gkectl prepare --config [PATH_TO_CONFIG] --skip-validation-all

Per visualizzare tutti i flag disponibili per saltare specifiche convalide:

gkectl check-config --help

Esecuzione di gkectl prepare

Prima dell'installazione, devi eseguire gkectl prepare sulla workstation di amministrazione per inizializzare l'ambiente vSphere. gkectl prepare esegue le seguenti attività:

  • Importa l'immagine del sistema operativo del nodo in vSphere e contrassegnala come modello.

  • Facoltativamente, convalida le affermazioni di compilazione delle immagini container, verificando che siano state create e firmate da Google e pronte per il deployment.

Esegui gkectl prepare con il file di configurazione di GKE On-Prem, dove --validate-attestations è facoltativo:

gkectl prepare --config [CONFIG_FILE] --validate-attestations

L'output positivo di --validate-attestations è Image [IMAGE_NAME] validated.

Installazione di GKE On-Prem

Hai creato un file di configurazione che specifica l'aspetto e l'aspetto dei tuoi cluster e hai convalidato il file. Hai eseguito gkectl prepare per inizializzare il tuo ambiente con il software GKE On-Prem. Ora è tutto pronto per avviare una nuova installazione di GKE On-Prem.

Per installare GKE On-Prem, esegui il comando seguente:

gkectl create cluster --config [CONFIG_FILE]

dove [CONFIG_FILE] è il file di configurazione che hai generato e modificato.

Puoi riutilizzare il file di configurazione per creare cluster utente aggiuntivi.

Ripresa di un'installazione

Se l'installazione viene interrotta dopo la creazione del cluster di amministrazione, puoi ripristinarla nel seguente modo:

  • Rimozione della specifica admincluster dal file di configurazione in corso...
  • In esecuzione di nuovo gkectl create cluster, passando il file kubeconfig del cluster di amministrazione.
gkectl create cluster --config [CONFIG_FILE] \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

dove [ADMIN_CLUSTER_NAME] è il kubeconfig del cluster di amministrazione, creato nella directory di lavoro all'avvio dell'installazione.

Problemi noti

Al momento non puoi riprendere un'installazione se stai creando un cluster utente ad alta disponibilità. Questo problema verrà risolto in una release futura.

Connessione dei cluster a Google

Attivazione del traffico in entrata

Quando il cluster utente è in esecuzione, devi abilitare il traffico in entrata creando un oggetto Gateway. La prima parte del manifest del gateway è sempre questa:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system

Puoi personalizzare il resto del manifest in base alle tue esigenze. Ad esempio, questo manifest indica che i client possono inviare richieste sulla porta 80 utilizzando il protocollo HTTP/2 e qualsiasi nome host:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"

Se vuoi accettare le richieste HTTPS, devi fornire uno o più certificati che il controller Ingress può presentare ai client.

Per fornire un certificato:

  1. Crea un secret che contenga il certificato e la chiave.
  2. Creare un oggetto Gateway o modificare un oggetto Gateway esistente che faccia riferimento al tuo Secret. Il nome dell'oggetto Gateway deve essere istio-autogenerated-k8s-ingress.

Supponiamo, ad esempio, che tu abbia già creato un file del certificato, ingress-wildcard.crt e un file della chiave ingress-wildcard.key.

Crea un secret denominato ingressgateway-wildcard-certs:

kubectl create secret tls \
    --namespace gke-system \
    ingressgateway-wildcard-certs \
    --cert ./ingress-wildcard.crt \
    --key ./ingress-wildcard.key

Di seguito è riportato un manifest per un gateway che fa riferimento al tuo secret. I client possono chiamare sulla porta 443 utilizzando il protocollo HTTPS e qualsiasi nome host che corrisponde a *.example.com. Tieni presente che il nome host nel certificato deve corrispondere al nome host nel manifest, *.example.com in questo esempio:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"
  - hosts:
    - "*.example.com"
    port:
      name: https-demo-wildcard
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: ingressgateway-wildcard-certs

Puoi creare più certificati TLS per host diversi modificando il manifest del gateway.

Salva il manifest in un file denominato my-gateway.yaml e crea il gateway:

kubectl apply -f my-gateway.yaml

Ora puoi utilizzare gli oggetti Kubernetes Ingress nel modo standard.

Limitazioni

Limitazione Descrizione
Limiti massimi e minimi per cluster e nodi

Vedi Quote e limiti. Le prestazioni del tuo ambiente potrebbero influire su questi limiti.
Unicità per i nomi dei cluster utente

Tutti i cluster utente registrati nello stesso progetto Google Cloud devono avere nomi univoci.
Impossibile eseguire il deployment in più di un data center vCenter e/o vSphere

Attualmente, puoi eseguire il deployment di un cluster di amministrazione e di un insieme di cluster utente associati in un singolo data center vCenter e/o vSphere. Non puoi eseguire il deployment degli stessi cluster di amministratore e utente in più di un data center vCenter e/o vSphere.
Impossibile modificare in modo dichiarativo le configurazioni dei cluster dopo la creazione Anche se puoi creare cluster aggiuntivi e ridimensionare i cluster esistenti, non puoi modificare un cluster esistente tramite il relativo file di configurazione.

Risolvere i problemi

Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.

Diagnosi dei problemi del cluster con gkectl

Utilizza i comandi gkectl diagnoseper identificare i problemi del cluster e condividere le informazioni sul cluster con Google. Consulta Diagnosticare i problemi del cluster.

Comportamento predefinito di logging

Per gkectl e gkeadm è sufficiente utilizzare le impostazioni di logging predefinite:

  • Per impostazione predefinita, le voci di log vengono salvate nel seguente modo:

    • Per gkectl, il file di log predefinito è /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e il file è collegato correttamente al file logs/gkectl-$(date).log nella directory locale in cui esegui gkectl.
    • Per gkeadm, il file di log predefinito è logs/gkeadm-$(date).log nella directory locale in cui esegui gkeadm.
  • Tutte le voci di log vengono salvate nel file di log, anche se non vengono stampate nel terminale (quando --alsologtostderr è false).
  • Il livello di dettaglio -v5 (impostazione predefinita) copre tutte le voci di log necessarie al team di assistenza.
  • Il file di log contiene anche il comando eseguito e il messaggio di errore.

Ti consigliamo di inviare il file di log al team di assistenza quando hai bisogno di aiuto.

Specifica di una posizione non predefinita per il file di log

Per specificare una posizione non predefinita per il file di log gkectl, utilizza il flag --log_file. Il file di log specificato non verrà simbolizzato nella directory locale.

Per specificare una posizione non predefinita per il file di log gkeadm, utilizza il flag --log_file.

Individuare i log dell'API Cluster nel cluster di amministrazione

Se l'avvio di una VM non va a buon fine dopo l'avvio del piano di controllo amministratore, puoi provare il debug controllando i log dei controller API del cluster nel cluster di amministrazione:

  1. Trova il nome del pod dei controller API del cluster nello spazio dei nomi kube-system, dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. Apri i log del pod, dove [POD_NAME] è il nome del pod. Se vuoi, puoi utilizzare grep o uno strumento simile per cercare gli errori:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Debug dei problemi BIG-IP di F5 mediante kubeconfig del nodo del piano di controllo del cluster di amministrazione

Dopo un'installazione, GKE On-Prem genera un file kubeconfig nella home directory della workstation di amministrazione denominata internal-cluster-kubeconfig-debug. Questo file kubeconfig è identico a kubeconfig del cluster di amministrazione, tranne per il fatto che rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, dove viene eseguito il piano di controllo dell'amministratore. Puoi utilizzare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi FG BIG-IP.

La convalida di gkectl check-config non è riuscita: impossibile trovare le partizioni BIG-IP di F5

Sintomi

La convalida non riesce perché non è possibile trovare le partizioni BIG-IP di F5, anche se esistono.

Potenziali cause

Un problema con l'API F5 BIG-IP può causare un errore di convalida.

Risoluzione

Prova a eseguire di nuovo gkectl check-config.

gkectl prepare --validate-attestations non riuscito: impossibile convalidare l'attestazione build

Sintomi

L'esecuzione di gkectl prepare con il flag --validate-attestations facoltativo restituisce il seguente errore:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
Potenziali cause

Potrebbe non esistere un attestato per le immagini interessate.

Risoluzione

Prova a scaricare ed eseguire nuovamente il deployment della OVA della workstation di amministrazione, come indicato in Creazione di una workstation di amministrazione. Se il problema persiste, contatta Google per ricevere assistenza.

Debug tramite i log del cluster di bootstrap

Durante l'installazione, GKE On-Prem crea un cluster temporaneo di bootstrap. Dopo un'installazione riuscita, GKE On-Prem elimina il cluster di bootstrap, lasciandoti con il cluster di amministrazione e quello utente. In generale, non dovrebbe avere alcun motivo di interagire con questo cluster.

Se si è verificato un problema durante un'installazione e hai superato il passaggio --cleanup-external-cluster=false a gkectl create cluster, potresti trovare utile eseguire il debug utilizzando i log del cluster di bootstrap. Puoi trovare il pod e ottenere i relativi log:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

Passaggi successivi