Prerequisiti delle macchine dei nodi del cluster

Google Distributed Cloud supporta un'ampia gamma di sistemi in esecuzione hardware supportato dalle distribuzioni del sistema operativo di destinazione. Una configurazione Google Distributed Cloud può essere eseguita su hardware minimo o su più macchine per offrire flessibilità, disponibilità e prestazioni.

Indipendentemente dalla configurazione di Google Distributed Cloud, i tuoi nodi e cluster Le risorse di CPU, RAM e archiviazione devono essere sufficienti per soddisfare le esigenze dei cluster e i carichi di lavoro che esegui.

Questa pagina è rivolta ad amministratori, architetti e operatori che definiscono le soluzioni IT e l'architettura di sistema in conformità con la strategia aziendale. Per apprendere Scopri di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento in Google Cloud vedi i contenuti Ruoli e attività utente comuni di GKE Enterprise.

Quando installi Google Distributed Cloud, puoi creare diversi tipi di cluster:

  • Un cluster utente che esegue carichi di lavoro.
  • Un cluster di amministrazione che crea e controlla i cluster utente per l'esecuzione dei carichi di lavoro.
  • Un cluster autonomo è un singolo cluster che può gestire ed eseguire i carichi di lavoro, ma non può creare o gestire cluster utente.
  • Un cluster ibrido può gestire ed eseguire carichi di lavoro, mentre un cluster ibrido può e gestire cluster utente aggiuntivi.

Oltre al tipo di cluster, puoi scegliere tra i seguenti profili di installazione in termini di requisiti delle risorse:

  • Predefinito: il profilo predefinito ha requisiti di risorse di sistema standard e puoi utilizzarlo per tutti i tipi di cluster.

  • Perimetrale: il profilo perimetrale ha una quantità notevolmente ridotta di risorse di sistema i tuoi requisiti. L'utilizzo di questo profilo è consigliato per i dispositivi periferici con Google Cloud. Puoi utilizzare il profilo perimetrale solo per cluster autonomi.

Requisiti delle risorse per tutti i tipi di cluster che utilizzano il profilo predefinito

La tabella seguente descrive i requisiti hardware minimi e consigliati di cui Google Distributed Cloud ha bisogno per operare e gestire cluster di amministrazione, ibridi, utente e autonomi utilizzando il profilo predefinito:

Risorsa Minimo Consigliato
CPU/vCPU* 4 core 8 core
RAM 16 GiB 32 GiB
Spazio di archiviazione 128 GiB 256 GiB

* Google Distributed Cloud supporta solo CPU e vCPU x86-64 a livello di microarchitettura della CPU v3 (x86-64-v3) e versioni successive.

Requisiti delle risorse per i cluster autonomi che utilizzano il profilo edge

La tabella seguente descrive i requisiti hardware minimi e consigliati di cui Google Distributed Cloud ha bisogno per operare e gestire i cluster autonomi utilizzando il profilo edge:

Risorsa Minimo Consigliato
CPU / vCPU* 2 core 4 core
RAM Ubuntu: 4 GiB

RHEL: 6 GiB

 Ubuntu: 8 GiB

RHEL: 12 GiB
Spazio di archiviazione 128 GiB 256 GiB

* Google Distributed Cloud supporta solo CPU e vCPU x86-64 sul Livello della microarchitettura CPU v3 (x86-64-v3) e superiore.

Per configurare cluster autonomi utilizzando il profilo perimetrale, segui queste best practice:

  • Esegui bmctl su una workstation separata. Se devi eseguire bmctl sul target di cluster, sono necessari 2 GiB di memoria per soddisfare requisiti minimi. Ad esempio, sono necessari 6 GiB per Ubuntu e 8 GiB per RHEL.

  • Imposta MaxPodsPerNode su 110. Il cluster non esegue in media più di 30 pod utente per nodo. Potresti aver bisogno di risorse aggiuntive per una configurazione MaxPodsPerNode superiore o per eseguire più di 30 pod utente per nodo.

  • Il runtime VM sui componenti GDC non è considerato in questo numero minimo configurazione delle risorse. Il runtime delle VM su GDC richiede risorse aggiuntive a seconda del numero di VM di cui è stato eseguito il deployment nel cluster.

Requisiti di archiviazione aggiuntivi

Google Distributed Cloud non fornisce risorse di archiviazione. Devi eseguire il provisioning e configurare lo spazio di archiviazione richiesto sul tuo sistema.

Per informazioni dettagliate sui requisiti di archiviazione, vedi Panoramica dei prerequisiti di installazione.

Per ulteriori informazioni su come configurare lo spazio di archiviazione richiesto, vedi Configurazione dell'archiviazione per Google Distributed Cloud.

Prerequisiti per le macchine dei nodi

Le macchine nodo hanno i seguenti prerequisiti:

  • Soddisfare i requisiti hardware minimi.
  • Il sistema operativo è una delle distribuzioni Linux supportate. Per ulteriori informazioni, inclusi i requisiti del kernel, vedi Selezionare il sistema operativo.
  • Accesso a internet.
  • Connettività di livello 3 a tutte le altre macchine nodo.
  • Accesso al VIP del control plane.
  • Accesso alle porte richieste. Per i requisiti specifici delle porte per il piano di controllo di nodi, nodi worker e nodi del bilanciatore del carico, consulta Porta di utilizzo sulla rete pagina dei requisiti.
  • Server dei nomi DNS configurati correttamente.
  • Nessun nome host duplicato.
  • Uno dei seguenti servizi NTP è abilitato e funzionante:
    • chrony
    • ntp
    • ntpdate
    • systemd-timesyncd
  • Un gestore dei pacchetti funzionante, ad esempio apt o dnf.

  • Su Ubuntu, devi disattivare Uncomplicated Firewall (UFW). Esegui systemctl stop ufw per disattivare UFW.

  • È necessario caricare uno dei seguenti moduli del kernel di networking:

    • ip_tables (è diverso dal pacchetto Debian frontend iptables, che non è obbligatorio)
    • nf_tables

    Per caricare un modulo, esegui il seguente comando:

    modprobe MODULE_NAME

  • La creazione del cluster controlla solo lo spazio libero richiesto per i componenti di sistema di Google Distributed Cloud. Questa modifica che offre un maggiore controllo sullo spazio allocato per i carichi di lavoro delle applicazioni. Ogni volta che installi Google Distributed Cloud, che i file system che supportano le seguenti directory abbiano le capacità massima e soddisfare i seguenti requisiti:

    • /: 17 GiB (18.253.611.008 byte).
    • /var/lib/containerd:
      • 30 GiB (32.212.254.720 byte) per i nodi del control plane.
      • 10 GiB (10.485.760 byte) per i nodi worker.
    • /var/lib/kubelet: 500 MiB (524.288.000 byte).
    • /var/lib/etcd: 20 GiB (21.474.836.480 byte, applicabile solo ai nodi del piano di controllo).

    • /var/lib/etcd-events: 5 GiB (5.368.709.120 byte, applicabile solo ai nodi del piano di controllo)

    Indipendentemente dalla versione del cluster, gli elenchi di directory precedenti possono trovarsi nelle stesse o in partizioni diverse. Se si trovano nella stessa partizione di base, il requisito di spazio è la somma dello spazio richiesto per ogni singola directory in quella partizione. Per tutte le versioni di release, il processo di creazione del cluster crea le directory, se necessario.

  • Le directory /var/lib/etcd e /etc/kubernetes sono inesistenti o vuoto.

  • Per macchine che eseguono RHEL 9.2 o Ubuntu 22.04, kernel Linux I limiti di inotify per il numero massimo di istanze e orologi utente devono essere maggiori o uguale ai seguenti:

    • fs.inotify.max_user_instances: 8192
    • fs.inotify.max_user_watches: 524288

    Per ulteriori informazioni, consulta la documentazione di configurazione di RHEL o Ubuntu.

Oltre ai prerequisiti per l'installazione e l'esecuzione di Google Distributed Cloud, i clienti sono tenuti a rispettare gli standard pertinenti che regolano il loro settore o un segmento di business, come i requisiti PCI DSS per le aziende che elaborano carte di credito o guide tecniche per l'implementazione della sicurezza (STIG) per le aziende nel settore della difesa.

Prerequisiti delle macchine del bilanciatore del carico

Se il tuo deployment non dispone di un pool di nodi del bilanciatore del carico specializzato, puoi chiedere ai nodi worker o ai nodi del piano di controllo di creare un pool di nodi del bilanciatore del carico. In questo caso, sono previsti prerequisiti aggiuntivi:

  • Le macchine si trovano nella stessa subnet di livello 2.
  • Tutti i VIP si trovano nella subnet dei nodi del bilanciatore del carico e sono instradabili dal gateway della subnet.
  • Il gateway della subnet del bilanciatore del carico deve ascoltare ARP gratuiti i pacchetti al bilanciatore del carico principale.

Passaggi successivi