Anthos clusters on bare metal ora è Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.
Questa pagina descrive i campi supportati nel file di configurazione del cluster per Google Distributed Cloud (solo software) su bare metal. Per ogni campo, la tabella seguente indica se il campo è obbligatorio. La tabella mostra anche quali campi sono mutabili, ovvero quali possono essere modificati dopo la creazione di un cluster. Come indicato nella tabella, alcuni campi mutabili possono essere modificati solo durante un upgrade del cluster.
Generazione di un modello per il file di configurazione del cluster
Puoi creare un file di configurazione del cluster con il comando bmctl create config. Sebbene alcuni campi abbiano valori predefiniti e altri, come metadata.name, possano essere compilati automaticamente, questo file di configurazione in formato YAML è un modello per specificare informazioni sul cluster.
Per creare un nuovo file di configurazione del cluster, utilizza il seguente comando nella
/baremetal cartella:
bmctlcreateconfig-cCLUSTER_NAME
Sostituisci CLUSTER_NAME con il nome del cluster che vuoi creare. Per maggiori informazioni su bmctl, consulta lo strumento bmctl.
Per un esempio del file di configurazione del cluster generato, consulta
Esempio di file di configurazione del cluster.
Compilare il file di configurazione
Nel file di configurazione, inserisci i valori dei campi come descritto nella tabella di riferimento dei campi riportata di seguito prima di creare o eseguire l'upgrade del cluster.
Obbligatorio. Stringa. La versione del cluster. Questo valore è impostato per la creazione e gli upgrade dei cluster.
Mutabilità:questo valore non può essere modificato per i cluster esistenti.
La versione può essere aggiornata solo tramite il
processo di upgrade del cluster.
Questa sezione contiene le impostazioni necessarie per utilizzare OpenID Connect (OIDC).
OIDC ti consente di utilizzare il tuo provider di identità esistente per gestire l'autenticazione degli utenti e dei gruppi nei tuoi cluster.
Facoltativo. Un certificato con codifica base64
PEM per il provider OIDC. Per creare la
stringa, codifica il certificato, incluse le intestazioni, in
base64. Includi la stringa risultante in
certificateAuthorityData come una singola riga.
Ad esempio (esempio di testo a capo per adattarsi alla tabella):
Facoltativo. Booleano (true|false). Specifica se nel cluster è disegnato un proxy inverso per collegare la console Google Cloud a un provider di identità on-premise non accessibile pubblicamente tramite internet. Se il tuo provider di identità non è raggiungibile tramite internet pubblico, imposta questo campo su true per autenticarti con la console Google Cloud. Per impostazione predefinita, questo valore è impostato su false.
Facoltativo. Stringa. Prefisso anteposto alle attestazioni dei gruppi per evitare conflitti con i nomi esistenti. Ad esempio, dato un gruppo dev e un prefisso
oidc:, oidc:dev.
Facoltativo. Stringa URL. URL a cui vengono inviate le richieste di autorizzazione al tuo OpenID, ad esempio https://example.com/adfs. Il server API Kubernetes
utilizza questo URL per rilevare le chiavi pubbliche per la verifica dei token. L'URL deve utilizzare HTTPS.
Facoltativo. Stringa URL. L'URL di reindirizzamento utilizzato da kubectl per
l'autorizzazione. Quando attivi OIDC, devi specificare un valore
kubectlRedirectURL.
Facoltativo. Stringa URL. Server proxy da utilizzare per la connessione del cluster al provider OIDC, se applicabile. Il valore deve includere un
nome host/indirizzo IP e, facoltativamente, una porta, un nome utente e una password. Ad esempio: http://user:password@10.10.10.10:8888.
Facoltativo. Booleano (true|false). Se impostato su
true, i controlli preliminari interni vengono ignorati quando
si applicano le risorse ai cluster esistenti. Il valore predefinito è false.
Mutabilità:questo valore può essere modificato per i cluster esistenti con il comando bmctl update.
Stringa. Il percorso della chiave dell'account di servizio Operations.
Google Distributed Cloud utilizza l'account di servizio delle operazioni per eseguire l'autenticazione con Google Cloud Observability per accedere all'API Logging e all'API Monitoring. Con
l'eccezione dei cluster utente, la chiave dell'account di servizio per le operazioni è obbligatoria. I cluster utente utilizzano le credenziali specificate per il
cluster di gestione (di amministrazione o ibrido).
Non puoi disattivare Cloud Logging e Cloud Monitoring per i tuoi
cluster.
Stringa. Obbligatorio. Il nome del cluster a cui aggiungi il
pool di nodi. Crea la risorsa pool di nodi nello stesso spazio dei nomi del
cluster associato e fai riferimento al nome del cluster in questo campo. Per maggiori informazioni, consulta Aggiungere e rimuovere pool di nodi in un cluster.
Valore booleano. Imposta questo campo su true per attivare le funzionalità di networking avanzate, come il bilanciamento del carico integrato con BGP o il gateway NAT in uscita. Entrambe queste funzionalità utilizzano Network Gateway per GDC.
Network Gateway per GDC è il componente chiave per attivare le funzionalità di networking avanzate in GKE Enterprise e Google Kubernetes Engine (GKE). Uno dei principali vantaggi di Network Gateway per GDC
è che può allocare dinamicamente indirizzi IP flottanti da
un insieme di indirizzi specificati in una
NetworkGatewayGroup risorsa personalizzata.
Valore booleano. Imposta questo campo su false per disattivare le funzionalità di Ingress
fornite in bundle con il software Google Distributed Cloud. Le funzionalità di Ingress incluse nel cluster supportano solo l'ingresso. Se
esegui l'integrazione con Istio o Cloud Service Mesh per usufruire dei vantaggi aggiuntivi di un
mesh di servizi completamente funzionale, ti consigliamo di disattivare Ingress incluso. Questo campo è impostato su true per impostazione predefinita. Questo campo
non è presente nel file di configurazione del cluster generato. Puoi
disattivare Ingress incluso solo per i cluster della versione 1.13.0 e successive.
Valore booleano. Imposta questo campo su true per attivare il modello di rete del cluster in modalità piatta. In modalità flat, ogni pod ha il suo indirizzo IP univoco. I pod possono comunicare tra loro direttamente senza dover utilizzare un gateway intermedio o la Network Address Translation (NAT).
flatIPv4 è false per impostazione predefinita. Puoi attivare la modalità piatta solo durante la creazione del cluster. Una volta attivata la modalità piatta per il cluster, non puoi disattivarla.
Facoltativo. Stringa. Specifica la modalità di rete per il bilanciamento del carico di Dataplane V2. La Network Address Translation dell'origine (SNAT) è la modalità di networking predefinita. La modalità Direct Server Return (DSR) supera i problemi relativi al bilanciamento del carico SNAT. In modalità DSR (forwardMode: dsr), il
nodo del bilanciatore del carico utilizza le opzioni IP per salvare l'indirizzo di origine del client.
La modalità di rete per il bilanciamento del carico di Dataplane V2 può essere configurata
solo al momento della creazione del cluster.
Obbligatorio. Intervallo di indirizzi IPv4 in formato blocco CIDR. Specifica
l'intervallo di indirizzi IP da cui vengono assegnati gli indirizzi IP virtuali (VIP)
di servizio. Gli intervalli non devono sovrapporsi ad alcuna subnet raggiungibile dalla tua rete. Per ulteriori informazioni sull'allocazione degli indirizzi per internet privati, consulta RFC 1918.
A partire dalla release del software Google Distributed Cloud 1.15.0 per bare metal, questo campo è mutabile. Se necessario, puoi aumentare il numero di indirizzi IP allocati per i servizi dopo aver creato un cluster. Per ulteriori informazioni, consulta
Aumentare l'area di copertura della rete di servizio.
Puoi solo aumentare l'intervallo del CIDR del servizio IPv4. L'intervallo
di emittenti non può essere ridotto, il che significa che la maschera (il valore dopo "/")
non può essere aumentata.
Intervallo CIDR minimo del servizio: valore della maschera di
/24, che corrisponde a una dimensione di 8 bit (256
indirizzi).
Intervallo CIDR massimo del servizio: valore della maschera di
/12, che corrisponde a una dimensione di 20 bit (1.048.576 indirizzi IP).
Valore booleano. Cloud Audit Logs sono utili per esaminare le richieste API مشکوکe per raccogliere statistiche. Cloud Audit Logs è abilitato
(disableCloudAuditLogging: false) per impostazione predefinita. Imposta su
true per disattivare Cloud Audit Logs.
Questo campo non viene più utilizzato e non ha alcun effetto. Il monitoraggio
e il logging delle applicazioni sono abilitati nella risorsa personalizzata Stackdriver. Per
saperne di più sull'abilitazione del logging e del monitoraggio per le applicazioni, consulta
Abilitare il logging e il monitoraggio per le applicazioni.
Stringa. Una Google Cloud regione in cui vuoi instradare e archiviare
le metriche di monitoraggio. Ti consigliamo di scegliere una regione vicino al tuo data center on-premise. Durante la creazione del cluster, questo valore viene utilizzato per impostare il valore clusterLocation nella specifica della risorsa stackdriver.
Il valore specificato viene utilizzato anche da Stackdriver per etichettare le metriche
e i log. Queste etichette possono essere utilizzate per filtrare i dati in Metrics Explorer
e in Logs Explorer.
Per ulteriori informazioni sulle Google Cloud località, consulta
Località globali. Per ulteriori informazioni sul routing di log e metriche, consulta Routing di log e metriche.
Stringa. L'ID del progetto Google Cloud in cui vuoi visualizzare
i log e le metriche. Durante la creazione del cluster, questo valore viene utilizzato per impostare il valore projectID nella specifica della risorsa stackdriver.
Facoltativo. Il campo gcpAccounts specifica un elenco di
account a cui è stato concesso il ruolo clusterrole/cluster-admin del controllo dell'accesso basato su ruoli (RBAC) di Kubernetes. Gli account con questo
ruolo hanno accesso completo a tutte le risorse del cluster in tutti
gli spazi dei nomi. Questo campo configura anche i criteri RBAC che consentono agli account specificati di utilizzare Connect Gateway per eseguire comandi kubectl sul cluster. Questa operazione è utile se devi gestire più cluster, in particolare in un ambiente ibrido con cluster GKE e on-premise.
Questo campo accetta un array di nomi account. Sono supportati gli account utente e gli account di servizio. Per gli utenti, specifica i loro
Google Cloud indirizzi email dell'account. Per gli account di servizio, specifica
gli indirizzi email nel seguente formato:
SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com.
Ad esempio:
Quando aggiorni un cluster per aggiungere un account, assicurati di includere tutti
gli account nell'elenco (sia esistenti che nuovi) perché il
comando di aggiornamento sovrascrive l'elenco con quanto specificato nell'
aggiornamento.
Questo campo si applica solo ai cluster che possono eseguire i workload. Ad esempio, non puoi specificare gcpAccounts per i cluster di amministrazione.
Facoltativo. Booleano (true|false). Attiva o disattiva i container di sistema bare metal senza root. Quando questo campo è attivato, i container di sistema bare metal vengono eseguiti come utente non root con un ID utente compreso nell'intervallo 2000-5000. Se disattivati, i container di sistema bare metal vengono eseguiti come utente root. Per impostazione predefinita, questa funzionalità è attivata. La disattivazione di questa funzionalità è vivamente sconsigliata, perché l'esecuzione dei contenitori come utente root rappresenta un rischio per la sicurezza. Dopo la creazione del cluster, questo campo può essere attivato/disattivato solo durante l'upgrade. Per ulteriori informazioni, vedi Non eseguire i contenitori come utente root.
Facoltativo. Valore booleano (true|false). Attiva o disattiva seccomp a livello di cluster. Quando questo campo è disattivato,
i container senza un profilo seccomp nel file di configurazione
del cluster vengono eseguiti senza restrizioni. Quando questo campo è abilitato, gli stessi contenitori vengono protetti utilizzando il profilo seccomp predefinito del runtime del contenitore. Questa funzionalità è attiva per impostazione predefinita.
Dopo la creazione del cluster, questo campo può essere attivato/disattivato solo durante l'upgrade.
Per ulteriori informazioni, consulta
Utilizzare seccomp per limitare i contenitori.
Facoltativo. Numero intero. Valore predefinito: 2000. I contenitori di sistema
nel software Google Distributed Cloud consentono di installare e gestire i cluster.
Gli ID utente (UID) e gli ID gruppo (GID) utilizzati da questi contenitori possono essere controllati dal campo startUIDRangeRootlessContainers nella specifica del cluster. I contenitori di sistema utilizzano gli UID
e i GID nell'intervallo da startUIDRangeRootlessContainers a
startUIDRangeRootlessContainers + 2999, che fornisce un intervallo
di 2000-4999 per impostazione predefinita. Quando aggiorni
startUIDRangeRootlessContainers, seleziona un valore che garantisca
che gli spazi UID e GID utilizzati dai container di sistema non si sovrappongano
a quelli assegnati ai carichi di lavoro degli utenti. Il valore startUIDRangeRootlessContainers può essere modificato solo durante gli upgrade.
Facoltativo. Un array di stringhe (nomi di dominio e indirizzi IP). Un
nome alternativo dell'oggetto (SAN) è una funzionalità dei certificati SSL che
consente di definire i nomi di dominio e i sottodomini su cui vuoi che un
certificato sia valido. In un cluster per bare metal, per impostazione predefinita i SAN per il certificato del server API includono gli indirizzi IP e VIP dei nodi del piano di controllo e i nomi DNS di Kubernetes. Utilizza questo campo per aggiungere altri SAN al certificato del
server API per il cluster. I nomi di dominio devono essere conformi allo standard
RFC 1035.
Per saperne di più, vedi Aggiungere domini al certificato del server API.
Questa sezione specifica gli indirizzi IP del pool di nodi utilizzato dal
control plane e dai relativi componenti. La specifica del pool di nodi del piano di controllo (come la
specifica del pool di nodi del bilanciatore del carico)
è speciale. Questa specifica dichiara e controlla le risorse critiche del cluster. La fonte canonica di questa risorsa è questa sezione nel
file di configurazione del cluster. Non modificare direttamente le risorse del pool di nodi del piano di controllo di primo livello. Modifica invece le sezioni associate nel
file di configurazione del cluster.
Facoltativo. Numero intero (non negativo). Specifica la quantità massima di richieste di pull delle immagini che possono essere aggiunte alla coda di elaborazione per gestire i picchi di richieste. Non appena viene avviato un pull, è possibile aggiungere una nuova richiesta alla coda. Il valore predefinito è 10. Questo campo corrisponde all'opzione
registryBurst
di configurazione di kubelet (v1beta1).
Il valore di registryPullQPS ha la precedenza su questa
impostazione. Ad esempio, con le impostazioni predefinite, sono consentiti picchi di massimo 10
query simultanee, ma devono essere elaborate alla frequenza predefinita di cinque query al secondo. Questo comportamento di picco viene utilizzato
solo quando registryPullQPS è maggiore di 0.
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Facoltativo. Numero intero (non negativo). Specifica la frequenza di elaborazione per le query relative ai tiri delle immagini del registry dei container in query al secondo (QPS).
Quando registryPullQPS è impostato su un valore maggiore di 0, la frequenza di query è limitata a quel numero di query al secondo. Se
registryPullQPS è impostato su 0, non è prevista
alcuna limitazione alla frequenza delle query. Il valore predefinito è 5.
Questo campo corrisponde all'opzione
registryPullQPS
di configurazione di kubelet (v1beta1).
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Facoltativo. Booleano (true|false). Questo campo
specifica se i tiri del registry dei container vengono elaborati in parallelo o
uno alla volta. Il valore predefinito è true, che specifica che i pull vengono elaborati uno alla volta. Se impostato su false, kubelet
esegue il pull delle immagini in parallelo. Questo campo corrisponde all'opzione
serializeImagePulls
di configurazione di kubelet (v1beta1).
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Obbligatorio. Un array di indirizzi IP. In genere, questo array è un indirizzo IP per una singola macchina o indirizzi IP per tre macchine per un deployment ad alta disponibilità (HA).
Obbligatorio. Stringa (indirizzo IPv4). Quando specifichi un pool di nodi, utilizza il campo address per specificare l'indirizzo IPv4 predefinito
per l'accesso SSH per ogni nodo. L'accesso SSH è necessario per le operazioni amministrative del cluster, come installazioni e upgrade. Per impostazione predefinita, questo
indirizzo IP viene utilizzato anche per il traffico di dati e Kubernetes. Tuttavia, se
specifichi l'indirizzo k8sIP per un determinato nodo, il traffico viene suddiviso
tra i due indirizzi del nodo, con l'indirizzo k8sIP
utilizzato esclusivamente per il traffico di dati e Kubernetes.
Facoltativo. Stringa (indirizzo IPv4). Quando specifichi l'indirizzo facoltativo
k8sIP per un nodo, questo è dedicato alla gestione dei dati
e del traffico Kubernetes per il nodo, ad esempio richieste e risposte per
l'API Kubernetes, il kubelet e i carichi di lavoro. Quando specifichi k8sIP,
l'indirizzo IP del nodo standard nodePoolSpec.nodes.address viene
utilizzato esclusivamente per le connessioni SSH al nodo. Se non specifichi un indirizzo k8sIP, l'indirizzo IP del nodo standard gestisce tutto il traffico per il nodo.
Il file di configurazione del cluster generato da bmctl
include campi per specificare i percorsi delle credenziali e dei file di chiavi nel
file system locale. Queste credenziali e chiavi sono necessarie per collegare
i tuoi cluster tra loro e al tuo progetto Google Cloud.
Facoltativo. Stringa. Valore predefinito: global.
L'appartenenza al parco risorse per i tuoi cluster è gestita dal servizio Fleet
(gkehub.googleapis.com) e dal servizio Connect
(gkeconnect.googleapis.com). L'appartenenza al parco risorse può essere
globale o regionale. Se vuoi, puoi utilizzare gkeConnect.location
per specificare la Google Cloud regione in cui vengono eseguiti i servizi Fleet e Connect, in modo che il traffico sia limitato alla tua regione.
Per un elenco delle regioni supportate, consulta
Regioni supportate per l'API GKE On-Prem.
Se non specificato, vengono utilizzate le istanze globali dei servizi.
Tieni presente quanto segue:
I cluster creati con versioni precedenti alla 1.28 sono gestiti dai servizi globali Fleet e Connect.
I nuovi cluster creati utilizzando i client dell'API GKE On-Prem, come la console Google Cloud, Google Cloud CLI o Terraform, utilizzano la stessa regione specificata per l'API GKE On-Prem.
Per i nuovi cluster, se includi questo campo, la regione specificata deve essere la stessa configurata in gkeOnPremAPI.location. Se le regioni non sono uguali,
la creazione del cluster non riesce.
Obbligatorio: stringa. L'ID del progetto Google Cloud che vuoi
utilizzare per connettere il tuo cluster a Google Cloud. È anche chiamato progetto host del parco risorse.
Stringa. Il percorso della chiave dell'account di servizio dell'agente.
Google Distributed Cloud utilizza questo service account per mantenere una connessione tra i tuoi cluster on-premise e Google Cloud.
Stringa. Il percorso della chiave dell'account di servizio di registrazione.
Google Distributed Cloud utilizza questo account di servizio per registrare i cluster di utenti Google Cloud.
In 1.16 e versioni successive, se l'API GKE On-Prem è abilitata nel
progetto Google Cloud, tutti i cluster del progetto vengono
registrati nell'API GKE On-Prem automaticamente nella regione configurata in
clusterOperations.location.
Se vuoi registrare tutti i cluster del progetto nell'API GKE On-Prem, assicurati di seguire i passaggi descritti in Prima di iniziare per attivare e utilizzare l'API GKE On-Prem nel progetto.
Se non vuoi registrare il cluster nell'API GKE On-Prem,
includi questa sezione e imposta gkeOnPremAPI.enabled su
false.
Se non vuoi registrare cluster nel progetto, disabilita
gkeonprem.googleapis.com (il nome del servizio per
l'API GKE On-Prem) nel progetto. Per le istruzioni, vedi
Disattivare
i servizi.
Se vuoi registrare tutti i cluster del progetto nell'API GKE On-Prem, assicurati di seguire i passaggi descritti in Prima di iniziare per attivare e utilizzare l'API GKE On-Prem nel progetto.
Se non vuoi registrare il cluster nell'API GKE On-Prem,
includi questa sezione e imposta gkeOnPremAPI.enabled su
false.
Se non vuoi registrare cluster nel progetto, disabilita
gkeonprem.googleapis.com (il nome del servizio per
l'API GKE On-Prem) nel progetto. Per le istruzioni, vedi
Disattivare
i servizi.
La registrazione del cluster di amministrazione o utente nell'API GKE On-Prem ti consente di
utilizzare strumenti standard, come la console Google Cloud, Google Cloud CLI o
Terraform, per visualizzare i dettagli del cluster e gestire il suo ciclo di vita. Ad esempio, puoi eseguire comandi dell'interfaccia a riga di comando gcloud per
ottenere informazioni sul tuo cluster.
L'API GKE On-Prem archivia i metadati dello stato del cluster in Google Cloud.
Questi metadati consentono all'API di gestire il ciclo di vita del cluster. Gli strumenti standard utilizzano l'API GKE On-Prem e collettivamente sono indicati come client dell'API GKE On-Prem.
Se imposti gkeOnPremAPI.enabled su true,
prima di creare o aggiornare il cluster utilizzando bmctl,
assicurati di svolgere i passaggi descritti in
Prima di iniziare per attivare e inizializzare l'API GKE On-Prem.
Dopo aver aggiunto questa sezione e creato o aggiornato il cluster, se successivamente rimuovi la sezione e aggiorni il cluster, l'aggiornamento non andrà a buon fine.
Se preferisci creare il cluster utilizzando uno strumento standard instead of bmctl, consulta quanto segue:
Per impostazione predefinita, il cluster viene registrato nell'API GKE On-Prem se l'API GKE On-Prem è abilitata nel progetto. Imposta false
se non vuoi registrare il cluster.
Dopo aver registrato il cluster nell'API GKE On-Prem, se devi annullarne la registrazione, apporta la seguente modifica e poi aggiorna il cluster:
La Google Cloud regione in cui viene eseguita l'API GKE On-Prem e
vengono archiviati i metadati del cluster. Scegli una delle
regioni supportate. Deve essere una stringa non vuota se
gkeOnPremAPI.enabled è true. Se
gkeOnPremAPI.enabled è false, non
includere questo campo.
Se questa sezione non è inclusa nel file di configurazione, questo
campo viene impostato su clusterOperations.location.
Stringa. Imposta il blocco CIDR del nodo IPv4. I nodi possono avere un solo intervallo
per ogni famiglia. Questo blocco CIDR deve corrispondere al CIDR del pod descritto nella
risorsa Cluster.
Numero intero. Definisce la dimensione della maschera per il blocco CIDR IPv4 del nodo. Ad
esempio, il valore 24 si traduce in netmask
/24. Assicurati che la maschera di rete del blocco CIDR del nodo sia maggiore
del numero massimo di pod che kubelet può pianificare, che è
definito nel flag --max-pods di kubelet.
Numero intero. Definisce la dimensione della maschera per il blocco CIDR IPv6 del nodo. Ad
esempio, il valore 120 si traduce in netmask
/120. Assicurati che la maschera di rete del blocco CIDR del nodo sia maggiore
del numero massimo di pod che kubelet può pianificare, che è
definito nel flag --max-pods di kubelet.
Facoltativo. Numero intero (non negativo). Specifica la quantità massima di richieste di pull delle immagini che possono essere aggiunte alla coda di elaborazione per gestire i picchi di richieste. Non appena viene avviato un pull, è possibile aggiungere una nuova richiesta alla coda. Il valore predefinito è 10. Questo campo corrisponde all'opzione
registryBurst
di configurazione di kubelet (v1beta1).
Il valore di registryPullQPS ha la precedenza su questa
impostazione. Ad esempio, con le impostazioni predefinite, sono consentiti picchi di massimo 10
query simultanee, ma devono essere elaborate alla frequenza predefinita di cinque query al secondo. Questo comportamento di picco viene utilizzato
solo quando registryPullQPS è maggiore di 0.
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Facoltativo. Numero intero (non negativo). Specifica la frequenza di elaborazione per le query relative ai tiri delle immagini del registry dei container in query al secondo (QPS).
Quando registryPullQPS è impostato su un valore maggiore di 0, la frequenza di query è limitata a quel numero di query al secondo. Se
registryPullQPS è impostato su 0, non è prevista
alcuna limitazione alla frequenza delle query. Il valore predefinito è 5.
Questo campo corrisponde all'opzione
registryPullQPS
di configurazione di kubelet (v1beta1).
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Facoltativo. Booleano (true|false). Questo campo
specifica se i tiri del registry dei container vengono elaborati in parallelo o
uno alla volta. Il valore predefinito è true, che specifica che i pull vengono elaborati uno alla volta. Se impostato su false, kubelet
esegue il pull delle immagini in parallelo. Questo campo corrisponde all'opzione
serializeImagePulls
di configurazione di kubelet (v1beta1).
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Deprecato. A partire dalla release 1.11.2, puoi attivare o disattivare
il runtime VM su GDC aggiornando solo la risorsa personalizzata VMRuntime.
Valore booleano. Determina se viene utilizzata o meno l'emulazione software per eseguire
le macchine virtuali. Se il nodo supporta la virtualizzazione hardware, imposta
useEmulation su false per migliorare
le prestazioni. Se la virtualizzazione hardware non è supportata o se hai dubbi, impostala su true.
Facoltativo. Mappatura (coppie chiave-valore).
Le etichette vengono riconciliate con i nodi del pool di nodi, a meno che non venga applicata al cluster l'annotazione baremetal.cluster.gke.io/label-taint-no-sync. Per saperne di più sulle etichette, consulta
Etichette e selettori.
Oggetti Il nome e un array di indirizzi IP per il pool di bilanciatori del carico del cluster. La configurazione del pool di indirizzi è valida solo per
bundled modalità LB nei cluster non amministrativi. Puoi aggiungere nuovi
pool di indirizzi in qualsiasi momento, ma non puoi rimuovere quelli esistenti.
È possibile modificare un pool di indirizzi esistente solo per modificare i campi avoidBuggyIPs
e manualAssign.
Array di intervalli di indirizzi IP. Specifica un elenco di intervalli IP che non si sovrappongono per il bilanciatore del carico del piano dati. Tutti gli indirizzi devono trovarsi nella stessa subnet dei nodi del bilanciatore del carico.
Facoltativo. Valore booleano (true | false). Se true,
il pool omette gli indirizzi IP che terminano con .0 e .255.
Alcuni hardware di rete eliminano il traffico verso questi indirizzi speciali. Puoi ommettere questo campo, il cui valore predefinito è false.
Facoltativo. Valore booleano (true | false). Se true,
gli indirizzi in questo pool non vengono assegnati automaticamente ai servizi Kubernetes. Se true, un indirizzo IP in questo pool viene utilizzato
solo quando è specificato esplicitamente da un servizio. Puoi omettere questo
campo, il cui valore predefinito è false.
Facoltativo. Oggetto (elenco di mappature). Questa sezione specifica uno o più peer BGP (Border Gateway Protocol) della tua rete locale (esterna al cluster). Specifichi i peer BGP quando configuri il bilanciamento del carico del control plane della soluzione di bilanciamento del carico in bundle che utilizza BGP. Ogni peer è specificato con una mappatura, composta da un indirizzo IP, un numero di sistema autonomo (ASN) e, facoltativamente, un elenco di uno o più indirizzi IP per i nodi del control plane. La configurazione del peering BGP per il bilanciamento del carico del piano di controllo non può essere aggiornata dopo la creazione del cluster.
Facoltativo. Stringa. Il numero di sistema autonomo (ASN) per la rete
contenente il dispositivo peer esterno. Specifica un ASN per ogni peer BGP configurato per il bilanciamento del carico del piano di controllo quando configuri la soluzione di bilanciamento del carico in bundle che utilizza BGP.
Per ulteriori informazioni, consulta
Configurare bilanciatori del carico integrati con BGP.
Facoltativo. Array di indirizzi IP (IPv4). Uno o più indirizzi IP per
i nodi del piano di controllo che si connettono al peer BGP esterno, quando
configuri la soluzione di bilanciamento del carico in bundle che utilizza BGP. Se
non specifichi alcun nodo del control plane, tutti i nodi del control plane si collegano al peer esterno. Se specifichi uno o più indirizzi IP,
solo i nodi specificati partecipano alle sessioni di peering.
Per ulteriori informazioni, consulta
Configurare bilanciatori del carico integrati con BGP.
Facoltativo. Stringa. Specifica l'Autonomous System Number (ASN) per il
cluster in fase di creazione. Questo campo viene utilizzato per configurare la soluzione di bilanciamento del carico in dotazione che utilizza il protocollo BGP (Border Gateway Protocol).
Per ulteriori informazioni, consulta
Configurare bilanciatori del carico integrati con BGP.
Obbligatorio. Stringa. Specifica la modalità di bilanciamento del carico. In
modalità bundled, il software Google Distributed Cloud installa un
bilanciatore del carico sui nodi del bilanciatore del carico durante la creazione del cluster. In
modalità manual, il cluster si basa su un bilanciatore del carico esterno
configurato manualmente. Per ulteriori informazioni, consulta
Panoramica dei bilanciatori del carico.
Facoltativo. Utilizza questa sezione per configurare un pool di nodi del bilanciatore del carico. I
nodi specificati fanno parte del cluster Kubernetes ed eseguono workload
normali e bilanciatori del carico. Se non specifichi un pool di nodi, i nodi del piano di controllo vengono utilizzati per il bilanciamento del carico. Questa sezione
si applica solo quando la modalità di bilanciamento del carico è impostata su bundled.
Se vuoi impedire l'esecuzione dei carichi di lavoro su un nodo nel pool di nodi del bilanciatore del carico, aggiungi al nodo la seguente incompatibilità:
node-role.kubernetes.io/load-balancer:NoSchedule
Il software Google Distributed Cloud aggiunge tolleranze per questo stato ai pod necessari per il bilanciamento del carico.
Facoltativo. Numero intero (non negativo). Specifica il numero massimo di richieste di pull delle immagini che possono essere aggiunte alla coda di elaborazione per gestire i picchi di richieste. Non appena viene avviato un pull, è possibile aggiungere una nuova richiesta alla coda. Il valore predefinito è 10. Questo campo corrisponde all'opzione
registryBurst
di configurazione di kubelet (v1beta1).
Il valore di registryPullQPS ha la precedenza su questa
impostazione. Ad esempio, con le impostazioni predefinite, sono consentiti picchi di massimo 10
query simultanee, ma devono essere elaborate alla frequenza predefinita di cinque query al secondo. Questo comportamento di picco viene utilizzato
solo quando registryPullQPS è maggiore di 0.
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Facoltativo. Numero intero (non negativo). Specifica la frequenza di elaborazione per le query relative ai tiri delle immagini del registry dei container in query al secondo (QPS).
Quando registryPullQPS è impostato su un valore maggiore di 0, la frequenza di query è limitata a quel numero di query al secondo. Se
registryPullQPS è impostato su 0, non è prevista
alcuna limitazione alla frequenza delle query. Il valore predefinito è 5.
Questo campo corrisponde all'opzione
registryPullQPS
di configurazione di kubelet (v1beta1).
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Facoltativo. Booleano (true|false). Questo campo
specifica se i tiri del registry dei container vengono elaborati in parallelo o
uno alla volta. Il valore predefinito è true, che specifica che i pull vengono elaborati uno alla volta. Se impostato su false, kubelet
esegue il pull delle immagini in parallelo. Questo campo corrisponde all'opzione
serializeImagePulls
di configurazione di kubelet (v1beta1).
Questo campo può essere impostato ogni volta che crei, aggiorni o esegui l'upgrade di un
cluster e l'impostazione viene mantenuta durante gli upgrade del cluster. Per ulteriori informazioni, consulta Configurare le impostazioni di estrazione delle immagini kubelet.
Questa sezione contiene un array di indirizzi IP per i nodi del
pool di nodi del bilanciatore del carico.
Per impostazione predefinita, tutti i nodi del pool di nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2 dei VIP del bilanciatore del carico configurati nella sezione loadBalancer.addressPools del file di configurazione. Tuttavia, se specifichi un indirizzo IP Kubernetesk8sIP per un nodo, solo questo indirizzo deve trovarsi nella stessa subnet di livello 2 degli altri VIP del bilanciatore del carico.
Facoltativo. Stringa (indirizzo IPv4). Quando specifichi un pool di nodi, utilizza il campo address per specificare l'indirizzo IPv4 predefinito
per l'accesso SSH per ogni nodo. L'accesso SSH è necessario per le operazioni amministrative del cluster, come installazioni e upgrade. Per impostazione predefinita, questo
indirizzo IP viene utilizzato anche per il traffico di dati e Kubernetes. Tuttavia, se
specifichi l'indirizzo k8sIP per un determinato nodo, il traffico viene suddiviso
tra i due indirizzi del nodo, con l'indirizzo k8sIP
utilizzato esclusivamente per il traffico di dati e Kubernetes.
Sebbene i nodi del pool di nodi del bilanciatore del carico possano eseguire i carichi di lavoro,
sono separati dai nodi dei pool di nodi worker. Non puoi
includere un determinato nodo del cluster in più di un pool di nodi. Gli indirizzi IP dei nodi sovrapposti bloccano la creazione e altre operazioni del cluster.
Facoltativo. Stringa (indirizzo IPv4). Quando specifichi l'indirizzo facoltativo
k8sIP per un nodo, questo è dedicato alla gestione dei dati
e del traffico Kubernetes per il nodo, ad esempio richieste e risposte per
l'API Kubernetes, il kubelet e i carichi di lavoro. Quando specifichi k8sIP,
l'indirizzo IP del nodo standard nodePoolSpec.nodes.address viene
utilizzato esclusivamente per le connessioni SSH al nodo. Se non specifichi un indirizzo k8sIP, l'indirizzo IP del nodo standard gestisce tutto il traffico per il nodo.
Facoltativo. Stringa. Specifica il tipo di bilanciamento del carico integrato utilizzato,
livello 2 o Border Gateway Protocol (BGP). Se utilizzi il
bilanciamento del carico in bundle standard, imposta type su layer2. Se
utilizzi il bilanciamento del carico in bundle con BGP, imposta type su bgp. Se
non imposti type, il valore predefinito è layer2.
Obbligatorio. Specifica l'indirizzo IP virtuale (VIP) da connettere al
server API Kubernetes. Questo indirizzo non deve rientrare nell'intervallo di
tutti gli indirizzi IP utilizzati per i pool di indirizzi del bilanciatore del carico,
loadBalancer.addressPools.addresses.
Facoltativo. Un singolo indirizzo IPv4 o un intervallo di indirizzi IPv4. Specifica
gli indirizzi IP delle macchine dei nodi che vuoi mettere
in modalità di manutenzione. Per saperne di più, consulta
Attivare la modalità di manutenzione dei nodi.
Ad esempio:
maintenanceBlocks:cidrBlocks:-192.168.1.200# Single machine-192.168.1.100-192.168.1.109# Ten machines
Obbligatorio. Stringa. In genere, il nome dello spazio dei nomi utilizza un pattern di
cluster-CLUSTER_NAME, ma il prefisso
cluster- non è strettamente necessario dalla release 1.7.2 del software Google Distributed Cloud.
Questo valore non può essere modificato per i cluster esistenti.
Facoltativo. Stringa. Specifica il nome utente non principale che vuoi utilizzare per
l'accesso alle funzionalità SUDO senza password alle macchine dei nodi nel
tuo cluster. La tua chiave SSH,
sshPrivateKeyPath, deve essere valida per l'utente specificato. Le operazioni di creazione e aggiornamento del cluster
verificano che sia possibile accedere alle macchine dei nodi con l'utente e la chiave SSH specificati.
Deprecato. A partire dalla release 1.13.0, Google Distributed Cloud supporta
containerd solo come runtime del contenitore. Il
campo containerRuntime è deprecato ed è stato rimosso
dal file di configurazione del cluster generato. Per
le versioni software di Google Distributed Cloud 1.13.0 e successive, se il
file di configurazione del cluster contiene questo campo, il valore deve essere
containerd.
Facoltativo. Numero intero. Specifica il numero massimo di pod che possono essere eseguiti su un singolo nodo. Per i cluster autogestiti, i valori consentiti per
maxPodsPerNode sono 32-250 per
i cluster ad alta disponibilità (HA) e 64-250
per i cluster non HA. Per i cluster di utenti, i valori consentiti per maxPodsPerNode sono 32-250. Se non specificato, il valore predefinito è 110. Una volta creato il cluster, questo valore non può essere aggiornato.
Kubernetes assegna un
blocco CIDR (Classless Inter-Domain Routing)
a ogni nodo in modo che ogni pod possa avere un indirizzo IP univoco. Le dimensioni
del blocco CIDR corrispondono al numero massimo di pod per nodo.
Per ulteriori informazioni sull'impostazione del numero massimo di pod per nodo, consulta Networking dei pod.
Questa sezione specifica una configurazione del registry privato a livello di nodo per i cluster di utenti. I registry privati a livello di nodo sono destinati all'utilizzo con i carichi di lavoro per offrirti un maggiore controllo sui tiri delle immagini e sulla relativa sicurezza.
Per i cluster di amministrazione, il registry privato a livello di nodo è specificato
nella sezione Credenziali del
file di configurazione del cluster di amministrazione.
Se applicabile, utilizza questa sezione per specificare il nome e lo spazio dei nomi del segreto creato per archiviare il certificato della CA (CA radice del server) per il registry privato. Se il tuo registry locale non richiede un
certificato TLS privato, puoi omettere questo blocco.
L'elenco seguente mostra la fase di lancio per ogni versione per la configurazione
di un registry privato a livello di nodo:
Stringa. Questo campo specifica l'host e la porta per un singolo registry privato. Puoi specificare l'host con un nome di dominio o un indirizzo IP. Non includere il prefisso http o https.
Il campo host è obbligatorio quando specifichi un registry privato per un cluster di utenti.
L'elenco seguente mostra la fase di lancio per ogni versione per la configurazione
di un registry privato a livello di nodo:
Se applicabile, utilizza questa sezione per specificare il nome e lo spazio dei nomi del secret creato per memorizzare le credenziali del registry privato.
Utilizza il blocco pullCredentialSecretRef quando configuri un cluster utente per concedere ai nodi l'accesso a un registry privato che richiede l'autenticazione.
L'elenco seguente mostra la fase di lancio per ogni versione per la configurazione
di un registry privato a livello di nodo:
Facoltativo. Questa sezione contiene le impostazioni per la configurazione della strategia di upgrade per i pool di nodi worker nel cluster. Per ulteriori informazioni, consulta
Upgrade paralleli.
Facoltativo. Booleano (0 o 1). Valore predefinito: 1.
Questo campo specifica se eseguire o meno l'upgrade di tutti i pool di nodi worker
di un cluster contemporaneamente. Per impostazione predefinita (1), l'upgrade avviene
in sequenza, uno dopo l'altro. Se imposti concurrentNodePools
su 0, ogni pool di nodi worker del cluster viene aggiornato
in parallelo.
Facoltativo. Booleano (true o false). Valore predefinito:
false. Questo campo specifica se mettere in pausa o riprendere un upgrade del cluster attivo.
Facoltativo. Booleano (true | false). Specifica se utilizzare o meno il tuo server del repository dei pacchetti anziché il repository apt Docker predefinito. Per utilizzare il tuo
repository di pacchetti, imposta addPackageRepo su
false. Utilizza questa funzionalità per saltare l'aggiunta di repository di pacchetti a ogni macchina bare metal nell'implementazione. Per maggiori informazioni, consulta Utilizzare un server del repository dei pacchetti privato.
Questa sezione contiene informazioni di configurazione per i controlli di integrità periodici. Nella risorsa Cluster, l'unica impostazione disponibile per
i controlli di integrità periodici è il campo enable. Per maggiori informazioni, consulta Controlli di integrità periodici.
Facoltativo. Valore booleano (true|false). Attiva o disattiva i controlli periodici dello stato del cluster. I controlli di integrità
periodici sono abilitati per impostazione predefinita su tutti i cluster. Puoi disattivare
i controlli di integrità periodici per un cluster impostando il
campo periodicHealthCheck.enable su false.
Per ulteriori informazioni, consulta
Disattivare i controlli di integrità periodici
Facoltativo. Utilizza questa sezione per specificare un registry privato da utilizzare per le immagini dei carichi di lavoro. Questo metodo di configurazione del registry privato nella sezione delle credenziali del file di configurazione del cluster è destinato ai cluster ibridi o autonomi che hanno solo pool di nodi worker.
Facoltativo. Stringa. Percorso del file del certificato CA (autorità di certificazione principale del server) se il
server di registry utilizza un certificato TLS privato. Se il registry locale
non richiede un certificato TLS privato, puoi omettere questo campo.
Stringa. Questo campo specifica l'host e la porta per un singolo registry privato. Puoi specificare l'host con un nome di dominio o un indirizzo IP. Non includere il prefisso http o https.
Il campo host è obbligatorio quando specifichi un registry privato per un cluster ibrido o autonomo.
Facoltativo. Stringa. Percorso del
file di configurazione della CLI
Docker, config.json. Docker salva
le impostazioni di autenticazione nel file di configurazione. Questo campo si applica
solo all'utilizzo di registry privati a livello di nodo.
Utilizza il campo pullCredentialConfigPath quando
configuri un cluster ibrido o autonomo per consentire ai nodi di accedere a un
registro privato che richiede l'autenticazione.
Facoltativo. Stringa. Quando profile è impostato su edge
per un cluster autonomo, riduce al minimo il consumo di risorse del
cluster. Il profilo edge è disponibile solo per i cluster autonomi.
Il profilo edge presenta esigenze ridotte in termini di risorse di sistema ed è consigliato per i dispositivi periferici con vincoli di risorse restrittivi.
Per i requisiti hardware associati al profilo edge, consulta
Requisiti
delle risorse per i cluster autonomi che utilizzano il profilo edge.
Stringa. Un elenco di indirizzi IP, intervalli di indirizzi IP, nomi host e nomi di dominio separati da virgole che non devono passare attraverso il server proxy. Quando il cluster invia una richiesta a uno di questi indirizzi,
host o domini, la richiesta viene inviata direttamente.
Facoltativo. Utilizza questa sezione per specificare un mirror del registry da utilizzare per l'installazione dei cluster anziché Container Registry (gcr.io). Per ulteriori informazioni sull'utilizzo di un mirror del registry, consulta Utilizzare un mirror del registry per le immagini dei container.
Facoltativo. Stringa. Percorso del file del certificato CA (autorità di certificazione principale del server) se il
server di registry utilizza un certificato TLS privato. Se il registry locale
non richiede un certificato TLS privato, puoi omettere questo campo.
Stringa. L'endpoint del mirror, costituito dall'indirizzo IP e dal numero di porta del server del registry. Se vuoi, puoi utilizzare il tuo spazio dei nomi
nel server del registry anziché lo spazio dei nomi principale. Senza un
spazio dei nomi, il formato dell'endpoint è
REGISTRY_IP:PORT. Quando utilizzi un
spazio dei nomi, il formato dell'endpoint è
REGISTRY_IP:PORT/v2/NAMESPACE.
/v2 è obbligatorio quando si specifica uno spazio dei nomi.
Il campo endpoint è obbligatorio quando specifichi un
mirror del registry. Puoi specificare più mirror/endpoint.
Facoltativo. Un array di nomi di dominio per gli host sottoposti a mirroring locale per il mirror del registry specificato (endpoint). Quando il runtime del contenitore rileva richieste pull per le immagini da un host specificato, controlla prima il mirror del registry locale. Per ulteriori informazioni, consulta Creare cluster dal mirror del registry.
Facoltativo. Stringa. Percorso del
file di configurazione dell'interfaccia a riga di comando Docker, config.json. Docker salva le impostazioni di autenticazione nel
file di configurazione. Questo campo si applica solo all'utilizzo di mirror del registry. Se il server del registry non richiede un file di configurazione Docker per l'autenticazione, puoi omettere questo campo.
Questa sezione specifica la configurazione (percorso) per i volumi permanenti locali supportati da dischi montati. Devi formattare e montare questi dischi personalmente. Puoi eseguire questa operazione prima o dopo la creazione del cluster. Per maggiori informazioni, consulta Montaggi dei nodi LVP.
Obbligatorio. Stringa. Utilizza il campo path per specificare il percorso della macchina
host in cui è possibile rilevare i dischi montati. Per ogni montaggio viene creato un volume permanente (PV) locale. Il percorso predefinito è
/mnt/localpv-share. Per le istruzioni sulla configurazione dei mount dei nodi, consulta Configurare i mount dei nodi LVP.
Questa sezione specifica la configurazione per i volumi permanenti locali supportati da sottodirectory in un file system condiviso. Queste sottodirectory
vengono create automaticamente durante la creazione del cluster.
Per ulteriori informazioni, consulta la quota LVP.
Obbligatorio. Stringa. Specifica il numero di sottodirectory da creare in
lvpShare.path. Il valore predefinito è 5. Per le istruzioni su come configurare la condivisione LVP, consulta Configurare una condivisione LVP.
Obbligatorio. Stringa. Utilizza il campo path per specificare il percorso della macchina
host in cui è possibile creare sottodirectory. Per ogni sottodirectory viene creato un
volume permanente locale (PV). Per le istruzioni su come configurare la condivisione LVP, consulta Configurare una condivisione LVP.
Obbligatorio. Stringa. Specifica la classe di archiviazione da utilizzare per creare volumi permanenti. StorageClass viene creato durante la creazione del cluster. Il valore predefinito è local-shared. Per le istruzioni su come configurare la condivisione LVP, consulta Configurare una condivisione LVP.
Facoltativo. Oggetti Un'incompatibilità dei nodi ti consente di contrassegnare un nodo in modo che lo scheduler ne eviti o impedisca l'utilizzo per determinati pod. Un'incompatibilità
è composta da una coppia chiave-valore e da un effetto associato. I valori key e value sono stringhe che utilizzi per identificare l'alterazione e il valore effect specifica in che modo vengono gestiti i pod per il nodo. L'oggetto taints può avere
più contaminazioni.
Il campo effect può assumere uno dei seguenti valori:
NoSchedule: nessun pod può essere pianificato sul
node, a meno che non abbia una tolleranza corrispondente.
PreferNoSchedule: il sistema evita di posizionare un pod
che non tollera l'incompatibilità sul nodo, ma non è obbligatorio.
NoExecute: i pod che non tollerano l'incompatibilità vengono rimossi immediatamente, mentre i pod che la tollerano non vengono mai rimossi.
Per il software Google Distributed Cloud, le contaminazioni vengono riconciliate con i nodi del pool di nodi, a meno che l'annotazione baremetal.cluster.gke.io/label-taint-no-sync non venga applicata al cluster. Per ulteriori informazioni sulle
incompatibilità, consulta
Incompatibilità e tolleranze.
Obbligatorio. Stringa. Specifica il tipo di cluster. Il modello di deployment
standard è costituito da un singolo cluster di amministrazione e da uno o più
cluster utente, gestiti dal cluster di amministrazione.
Il software Google Distributed Cloud supporta i seguenti tipi di
cluster:
Amministratore: cluster utilizzato per gestire i cluster utente.
Utente: il cluster utilizzato per eseguire i carichi di lavoro.
Ibrido: un singolo cluster per l'amministrazione e i carichi di lavoro, che può anche gestire i cluster utente.
Autonomo: singolo cluster che può autogestirse e anche eseguire carichi di lavoro, ma non può creare o gestire altri cluster di utenti.
Il tipo di cluster viene specificato al momento della creazione e non può essere modificato per aggiornamenti o upgrade. Per saperne di più su come creare un
cluster, consulta
Creazione di cluster: panoramica.
Valori consentiti: admin | user | hybrid | standalone
Questo valore non può essere modificato per i cluster esistenti.
Facoltativo. Questa sezione contiene le impostazioni per la configurazione della strategia di upgrade per i nodi in un pool di nodi worker. Per ulteriori informazioni, consulta
Upgrade paralleli.
Nota: non aggiungere questa sezione per i pool di nodi del control plane o del bilanciatore del carico.
Facoltativo. Questa sezione contiene le impostazioni per la configurazione degli upgrade paralleli dei nodi per un pool di nodi worker. In un upgrade del cluster tipico e predefinito, viene eseguito l'upgrade di ciascun
nodo del cluster in sequenza, uno dopo l'altro. Puoi
configurare i pool di nodi worker in modo che l'upgrade di più nodi avvenga in parallelo
durante l'upgrade del cluster. L'upgrade dei nodi in parallelo accelera notevolmente gli upgrade dei cluster, in particolare per i cluster con centinaia di nodi.
Per un pool di nodi worker, puoi specificare il numero di nodi di cui eseguire l'upgrade contemporaneamente e puoi impostare una soglia minima per il numero di nodi in grado di eseguire i workload durante la procedura di upgrade.
Facoltativo. Numero intero (positivo). Valore predefinito: 1. Massimo: 15.
Per impostazione predefinita (1), l'upgrade dei nodi viene eseguito in sequenza, uno dopo l'altro. Quando imposti concurrentNodes su un numero maggiore di 1, questo campo
specifica il numero di nodi di cui eseguire l'upgrade in parallelo. Tieni presente i seguenti vincoli per concurrentNodes:
Il valore non può superare il valore più piccolo tra il 50% del numero di nodi nel pool di nodi o il numero fisso 15. Ad esempio, se il tuo pool di nodi ha 20 nodi, non puoi specificare un valore superiore a 10. Se il pool di nodi ha 100 nodi, 15 è il valore massimo che puoi specificare.
Quando utilizzi questo campo insieme al campo minimumAvailableNodes, i valori combinati non possono superare il numero totale di nodi
nel pool di nodi. Ad esempio, se il pool di nodi ha 20 nodi e
minimumAvailableNodes è impostato su 18,
concurrentNodes non può superare 2.
Gli upgrade paralleli non rispettano il
budget di interruzione dei pod (PDB).
Se i tuoi workload sono sensibili alle interruzioni, ti consigliamo di
specificare minimumAvailableNodes per assicurarti che un determinato numero
di nodi rimanga disponibile per l'esecuzione dei workload durante la procedura
di upgrade. Per ulteriori informazioni, consulta
Upgrade paralleli.
Facoltativo. Numero intero (non negativo). Valore predefinito: dipende da concurrentNodes. Per maggiori dettagli sui valori predefiniti per minimumAvailableNodes, consulta
Valori predefiniti per l'upgrade parallelo. minimumAvailableNodes consente di specificare
la quantità di nodi nel pool di nodi che devono rimanere disponibili
durante la procedura di upgrade. Un nodo è considerato non disponibile
quando è in corso l'upgrade. Un nodo è considerato anche
non disponibile quando una delle seguenti condizioni è vera:
Il nodo è in modalità di manutenzione
Il nodo è in fase di riconciliazione
Il nodo è bloccato nel mezzo di un upgrade
Quando utilizzi questo campo insieme al campo concurrentNodes, i valori combinati non possono superare il numero totale di nodi nel
pool di nodi. Ad esempio, se il pool di nodi ha 20 nodi e
concurrentNodes è impostato su 10,
minimumAvailableNodes non può superare 10.
Un valore elevato per minimumAvailableNodes riduce al minimo i problemi di capacità per la pianificazione dei pod e, di conseguenza, aiuta a proteggere i carichi di lavoro durante un upgrade del cluster. Tuttavia, un valore elevato per minimumAvailableNodes
aumenta il rischio che un upgrade si blocchi in attesa che i nodi diventino disponibili. Per ulteriori informazioni, consulta
Upgrade paralleli.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-02-28 UTC."],[],[]]
