I controlli preflight sono una misura preventiva per aiutarti a identificare i problemi prima di avviare un'operazione principale del cluster, come la creazione o l'upgrade dei cluster. Quando vengono eseguiti automaticamente prima di un'operazione e non vengono apportate dei cluster, a meno che non vengano superati tutti i controlli preflight. Puoi anche eseguire il preflight e controlli on demand.
Questo documento descrive ogni controllo e indica le circostanze in cui viene eseguito automaticamente. come e quando eseguirla manualmente e come interpretare i risultati.
In Google Distributed Cloud puoi eseguire controlli preflight per diverse situazioni:
Google Distributed Cloud esegue controlli preflight quando crei o esegui l'upgrade di cluster e risorse del pool di nodi con
bmctl
. Se i controlli non vanno a buon fine, vengono apportate modifiche. Puoi anche bypassare questi controlli o eseguirli esplicitamente.Google Distributed Cloud esegue anche controlli preflight interni quando un amministratore o un cluster ibrido crea o aggiorna le risorse Kubernetes sui cluster utente. La vengono eseguiti prima che le modifiche vengano applicate ai cluster utente interessati. Se non hanno esito positivo e non vengono apportate modifiche.
PreflightCheck
risorse personalizzate
Quando viene eseguito un controllo preflight, Google Distributed Cloud crea un PreflightCheck
risorsa personalizzata. PreflightCheck
risorse personalizzate sono permanenti e forniscono un
delle attività e dei risultati dei controlli preflight.
Per recuperare PreflightCheck
risorsa personalizzata:
Ottieni un elenco di controlli preflight eseguiti per un determinato cluster:
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
Sostituisci quanto segue:
ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster.
La risposta elenca le risorse per spazio dei nomi. Puoi eseguire
kubectl get preflightchecks
in tutti gli spazi dei nomi per un elenco completo. Per ogni risorsa, la risposta mostra l'età della risorsa e se controlli preflight superati. La seguente risposta di esempio mostraPreflightCheck
risorse per lo spazio dei nomicluster-test-admin001
.NAMESPACE NAME PASS AGE cluster-test-admin001 test-admin001 true 52d cluster-test-admin001 test-admin001jkm4q true 52d cluster-test-admin001 test-admin001k79t7 true 6d20h cluster-test-admin001 upgrade-cluster-20231106-222746 true 6d20h
Recupera i dettagli per una specifica risorsa personalizzata di
PreflightCheck
:kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
Sostituisci quanto segue:
ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.CLUSTER_NAMESPACE
: lo spazio dei nomi del cluster.
La seguente risposta al comando di esempio mostra una risorsa
PreflightCheck
per un controllo preflight riuscito durante la creazione del cluster:Name: create-cluster-20230922-175006 Namespace: cluster-test-user001 Labels: <none> Annotations: <none> API Version: baremetal.cluster.gke.io/v1 Kind: PreflightCheck Metadata: Creation Timestamp: 2023-09-22T17:50:11Z Generation: 1 Resource Version: 6502800 UID: 917daf64-963d-44b4-a1f9-c54972a39191 Spec: Check Image Version: latest Config YAML: --- apiVersion: v1 kind: Namespace metadata: name: cluster-test-user --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: test-user001 namespace: cluster-test-user001 spec: type: user profile: default anthosBareMetalVersion: 1.16.0 gkeConnect: projectID: clusters-project controlPlane: nodePoolSpec: nodes: - address: 192.0.2.53 ... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: node-pool-1 namespace: cluster-test-user001 spec: clusterName: test-user001 nodes: - address: 192.0.2.54 ... Status: Checks: 192.0.2.53: Job UID: d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c Message: Pass: true 192.0.2.53-gcp: Job UID: b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8 Message: Pass: true 192.0.2.54: Job UID: b67cf195-3951-46ad-b91c-0d79025cfc0a Message: Pass: true 192.0.2.54-gcp: Job UID: aed509e2-4bf7-44c4-bfa0-8147ef8ea74e Message: Pass: true Gcp: Job UID: ac479ac4-e1c4-4681-9f2b-5773069bf6ae Message: Pass: true Node - Network: Job UID: 8a57c4ee-ad17-4560-8809-b117c871ad5d Message: Pass: true Pod - Cidr: Message: Pass: true Cluster Spec: Anthos Bare Metal Version: 1.16.0 Bypass Preflight Check: false Cluster Network: Bundled Ingress: true Pods: Cidr Blocks: 10.0.0.0/16 Services: Cidr Blocks: 10.96.0.0/20 ... Completion Time: 2023-09-22T17:51:22Z Conditions: Last Transition Time: 2023-10-02T23:59:06Z Observed Generation: 1 Reason: Reconciling Status: True Type: Reconciling Node Pool Specs: node-pool-1: Cluster Name: test-user001 Nodes: Address: 192.0.2.54 ... Pass: true Start Time: 2023-09-22T17:50:32Z Events: <none>
Nella precedente risorsa personalizzata
PreflightCheck
, la sezioneStatus
contiene le seguenti informazioni:- La sezione
Checks
elenca i singoli controlli preflight eseguiti e indipendentemente dal fatto che siano superati. In questo esempio sono stati eseguiti i seguenti controlli:192.0.2.53
e192.0.2.54
: controlli dei nodi (configurazione del sistema operativo, risorse e impostazioni software) per le macchine con indirizzi IP192.0.2.53
e192.0.2.54
.192.0.2.53-gpc
e192.0.2.54-gcp
: connettività Google Cloud (accesso a Container Registry e API di Google) per verificare la presenza di macchine con Indirizzi IP192.0.2.53
e192.0.2.54
.Gcp
: verifica della connettività di Google Cloud per il cluster.Node - Network
: controlli della rete (connettività, operazioneetcd
, accesso VIP e associazione di porte) per il cluster.Pod - Cidr
: l'indirizzo IP del pod verifica la presenza di indirizzi che si sovrappongono per nel cluster.
- La sezione
Cluster Spec
mostra la configurazione del cluster. - Il campo
Pass
mostratrue
, a indicare che i controlli preflight passati collettivamente.
Log dei controlli preflight
Quando i controlli preflight vengono eseguiti a seguito di un comando bmctl
, come bmctl check
preflight
, Google Distributed Cloud crea dei file di log. Ecco cosa viene generato
e dove:
I log dei controlli preflight vengono generati in una directory con la seguente denominazione motivo
preflight-TIMESTAMP
.Questa directory preflight viene creata nella directory
log
per il cluster nell'area di lavorobmctl
. Per impostazione predefinita, il percorso della directorylog
èbmctl-workspace/CLUSTER_NAME/log
.I log preflight sono costituiti dai seguenti file:
I file di log per i controlli delle macchine dei nodi, uno per ogni nodo del cluster. Questi log vengono denominati utilizzando l'indirizzo IP del nodo. Ad esempio, un il nome file potrebbe essere
192.0.2.53
.I file di log per i controlli di accesso a Google Cloud, uno per ogni nodo del cluster. Questi file di log vengono denominati utilizzando l'indirizzo IP del nodo. Ad esempio: un nome file potrebbe essere
192.0.2.53-gcp
.File di log per i controlli di accesso a Google Cloud del cluster, denominato
gcp
.File di log per i controlli di rete dei nodi, denominato
node-network
.
Se un controllo preflight ha esito negativo, questi file di log possono aiutarti a identificare e risolvere il problema.
Controlli preflight per la creazione del cluster
Quando creare cluster, Google Distributed Cloud esegue automaticamente i controlli preflight prima di qualsiasi modifica vengono effettuate.
Cosa viene controllato?
I controlli preflight per l'installazione controllano quanto segue:
Controlli delle macchine dei nodi:
Le macchine cluster utilizzano un sistema operativo supportato.
La versione del sistema operativo è supportata.
Il sistema operativo utilizza una versione del kernel supportata.
Per Ubuntu, il Uncomplicated Firewall (UFW) è disabilitato.
Per Ubuntu, il gestore di pacchetti
apt
è utilizzabile, mentre i pacchetti richiesti sono disponibili.Per Red Hat Enterprise Linux, il gestore di pacchetti
dnf
è utilizzabile e sono disponibili i pacchetti richiesti.Per Red Hat Enterprise Linux, Podman non è installato.
Le macchine nodo soddisfano i requisiti minimi di CPU.
Le macchine nodo soddisfano i requisiti minimi di memoria.
Le macchine nodo soddisfano i requisiti minimi di archiviazione su disco.
La sincronizzazione dell'ora è configurata sulle macchine nodo.
kubelet
è attivo e in esecuzione su macchine nodo.containerd
è attivo e in esecuzione su macchine nodo.La route predefinita per il routing dei pacchetti al gateway predefinito è presente in nodi.
Il DNS (Domain Name System) funziona correttamente. Se il cluster è configurato per l'esecuzione dietro un proxy, questo controllo viene ignorato.
I CIDR dei pod non si sovrappongono agli indirizzi IP delle macchine dei nodi.
Se il cluster è configurato in modo da utilizzare un mirror del registro, sia raggiungibile.
Google Cloud controlla ogni nodo e il cluster:
Container Registry,
gcr.io
, la raggiungibilità è verificata. Se il cluster è configurato per l'utilizzo di un mirror del registro, questo controllo viene ignorato.le API di Google sono raggiungibili.
Controlli di networking dei nodi (variano in base alla configurazione del bilanciamento del carico):
Il VIP per il server API Kubernetes è accessibile.
I VIP del bilanciatore del carico sono accessibili.
I nodi possono comunicare sulle porte richieste.
È stato eseguito il provisioning dell'istanza di eventi
etcd
e i requisiti delle porte sono soddisfatti.
Una volta superati tutti i controlli, Google Distributed Cloud crea il cluster. Per ulteriori informazioni informazioni sui requisiti per la creazione di cluster, consulta Installazione panoramica sui prerequisiti.
Esegui controlli preflight on demand per la creazione del cluster
Puoi anche eseguire controlli preflight in modo indipendente, prima di creare un cluster. Questa operazione può essere utile per le principali operazioni del cluster, ad esempio richiedono molto tempo. Identificare e risolvere separatamente i problemi prima avviare un'operazione importante del cluster può aiutarti con la pianificazione.
Cluster autogestiti
Il comando seguente convalida la configurazione del cluster specificata ma non tenta di creare il cluster stesso:
bmctl check config --cluster CLUSTER_NAME
Sostituisci
CLUSTER_NAME
con il nome del cluster associato al file di configurazione che stai controllando.Questo comando verifica se le macchine e la rete sono pronte per creazione del cluster:
bmctl check preflight --cluster CLUSTER_NAME
Sostituisci
CLUSTER_NAME
con il nome del cluster che stai controllando.
Cluster utenti
Il comando seguente convalida il file di configurazione del cluster specificato, non provi a creare il cluster stesso:
bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster utente che che stai controllando.ADMIN_KUBECONFIG
: il percorso dell'elemento associato del cluster di amministrazione kubeconfig.
Il comando seguente verifica se le macchine e la rete sono pronte per la creazione del cluster:
bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
bmctl
supporta l'utilizzo di --kubeconfig
come alias per
il flag --admin-kubeconfig
.
Controlli preflight per gli upgrade del cluster
Quando esegui l'upgrade dei cluster, Google Distributed Cloud esegue automaticamente i controlli preflight prima che vengano apportate modifiche.
Cosa viene controllato?
I controlli preflight per gli upgrade del cluster controllano quanto segue:
Controlli delle macchine dei nodi:
Le macchine cluster utilizzano un sistema operativo supportato.
La versione del sistema operativo è supportata.
Il sistema operativo utilizza una versione del kernel supportata.
Per Ubuntu, il Uncomplicated Firewall (UFW) è disabilitato.
Le macchine nodo soddisfano i requisiti minimi di CPU.
Le macchine nodo hanno più del 20% delle risorse della CPU disponibili.
Le macchine nodo soddisfano i requisiti minimi di memoria.
Le macchine nodo soddisfano i requisiti minimi di archiviazione su disco.
La sincronizzazione dell'ora è configurata sulle macchine nodo.
La route predefinita per il routing dei pacchetti al gateway predefinito è presente in nodi.
Il DNS (Domain Name System) funziona correttamente. Se il cluster è configurato per l'esecuzione dietro un proxy, questo controllo viene ignorato.
Se il cluster è configurato in modo da utilizzare un mirror del registro, sia raggiungibile.
* Nessun nodo del piano di controllo o del bilanciatore del carico è in modalità di manutenzione.
Google Cloud controlla ogni nodo e il cluster:
Container Registry,
gcr.io
, la raggiungibilità è verificata. Se il cluster è configurato per l'utilizzo di un mirror del registro, questo controllo viene ignorato.le API di Google sono raggiungibili.
Controlli delle macchine:
kubelet
è attivo e in esecuzione su macchine nodo.containerd
è attivo e in esecuzione su macchine nodo.Lo stato dell'endpoint di integrità di Container Network Interface (CNI) è integro.
I CIDR dei pod non si sovrappongono agli indirizzi IP delle macchine dei nodi.
Controlli di networking dei nodi (variano in base alla configurazione del bilanciamento del carico):
Il VIP per il server API Kubernetes è accessibile.
I VIP del bilanciatore del carico sono accessibili.
I nodi possono comunicare sulle porte richieste.
È stato eseguito il provisioning dell'istanza di eventi
etcd
e i requisiti delle porte sono soddisfatti.
Una volta superati tutti i controlli, Google Distributed Cloud esegue l'upgrade del cluster. Per ulteriori informazioni per informazioni sull'upgrade dei cluster, consulta le best practice per Cluster Google Distributed Cloud upgrade e Ciclo di vita e fasi di upgrade dei cluster.
Esegui controlli preflight on demand per gli upgrade del cluster
Il comando bmctl check preflight
ti consente di eseguire un controllo preflight prima
eseguendo l'upgrade del cluster. Puoi verificare se i cluster sono pronti per un upgrade
eseguendo questo comando di controllo preflight prima di avviare l'upgrade:
Aggiorna la versione (
anthosBareMetalVersion
) nel cluster di configurazione del deployment.Utilizza il comando seguente per verificare se i cluster sono pronti per un upgrade ed esegui un controllo preflight:
bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster di cui eseguire l'upgrade.ADMIN_KUBECONFIG
: il percorso del cluster di amministrazione kubeconfig.
Quando crei il controllo preflight con questo comando per testare un cluster upgrade, viene creata una risorsa personalizzata
PreflightCheck
nel cluster di amministrazione.
Controlli preflight interni su cluster esistenti
Google Distributed Cloud esegue automaticamente i controlli preflight interni e applicare le risorse Kubernetes a un cluster esistente. Se qualche controllo ha esito negativo, Google Distributed Cloud non modifica nessuno dei nodi correlati a meno che tu ignorare esplicitamente i controlli.
Bypassa i controlli preflight durante l'applicazione delle risorse Kubernetes
Ignorare i controlli preflight interni durante l'applicazione delle risorse a elementi esistenti
devi impostare il campo BypassPreflightCheck
su true
nel
di configurazione del cluster.
Ecco parte di un file di configurazione del cluster che mostra
Campo bypassPreflightCheck
impostato su true
:
apiVersion: v1
kind: Namespace
metadata:
name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user1
namespace: cluster-user1
spec:
type: user
bypassPreflightCheck: true
# Anthos cluster version.
anthosBareMetalVersion: 1.29.200-gke.243
...
Esegui i controlli preflight e i controlli di integrità più recenti
Quando utilizzi bmctl
per eseguire controlli preflight o di integrità, puoi aggiungere
--check-image-version latest
al comando per eseguire
controlli dell'ultima versione della patch di Google Distributed Cloud. Questo può aiutarti
identificare i problemi noti senza prima creare o eseguire l'upgrade del cluster.
Per utilizzare l'elenco più recente dei controlli al fine di determinare se le tue macchine e sono pronte per la creazione del cluster:
bmctl check preflight --cluster CLUSTER_NAME --check-image-version latest
Sostituisci
CLUSTER_NAME
con il nome del cluster che che stai controllando.
Puoi anche eseguire i più recenti controlli di integrità di un cluster in tempo reale per determinare se il cluster è integro.
Per eseguire i controlli di integrità più aggiornati su un cluster in tempo reale:
bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest
Sostituisci
CLUSTER_NAME
con il nome del cluster che che stai controllando.
Ignora i risultati dei controlli preflight automatici
Se esegui controlli preflight on demand prima di creare o eseguire l'upgrade dei cluster,
può bypassare i controlli preflight automatizzati. Per bypassare i controlli preflight automatici,
usa il flag facoltativo --force
quando esegui bmctl create cluster
o
bmctl upgrade cluster
.