Preparazione di un ambiente Google Kubernetes Engine per la produzione

Questo documento descrive come eseguire l'onboarding dei carichi di lavoro containerizzati in modo più sicuro, affidabile ed economico in Google Kubernetes Engine (GKE). Fornisce indicazioni per la configurazione dell'accesso amministrativo e di rete ai cluster. Questo articolo presuppone una conoscenza approfondita delle risorse Kubernetes e dell'amministrazione dei cluster, nonché la familiarità con le funzionalità di rete di Google Cloud.

Architettura di esempio

Il diagramma seguente mostra un esempio di struttura flessibile e ad alta disponibilità per il deployment di un cluster GKE.

Struttura di progetto, rete e cluster.

Progetti

Google Cloud crea tutte le proprie risorse all'interno di un'entità progetto.

Puoi utilizzare i progetti per rappresentare i vari ambienti operativi. Ad esempio, puoi avere progetti production e staging per i team operativi, nonché un progetto development per gli sviluppatori. Puoi applicare criteri più granulari e rigorosi ai progetti che includono i dati e i carichi di lavoro più mission critical e sensibili. Puoi quindi applicare criteri più permissivi e flessibili per gli sviluppatori nell'ambiente development da sperimentare.

Cluster

Un progetto può contenere più cluster. Se devi eseguire il deployment di più carichi di lavoro, puoi scegliere di utilizzare un cluster condiviso singolo o un cluster separato per questi carichi di lavoro.

Reti e subnet

All'interno di ogni progetto, puoi avere una o più reti VPC, che sono versioni virtuali delle reti fisiche. Ogni rete VPC è una risorsa globale che contiene altre risorse relative al networking, come subnet, indirizzi IP esterni, regole firewall, route, VPN e router Cloud. All'interno di una rete VPC, puoi utilizzare le subnet, che sono risorse a livello di area geografica, per isolare e controllare il traffico all'interno o all'esterno di ogni area geografica tra i cluster GKE.

Ogni progetto è dotato di una singola rete predefinita. Puoi creare e configurare una rete aggiuntiva per mappare la convenzione di gestione degli indirizzi IP (IPAM) esistente. Puoi quindi applicare regole firewall a questa rete per filtrare il traffico da e verso i tuoi nodi GKE. Per impostazione predefinita, tutto il traffico esterno ai nodi GKE è negato.

Per controllare la comunicazione tra le subnet, devi creare regole firewall che consentano il passaggio del traffico tra le subnet. Utilizza il flag --tags durante la creazione del cluster o del pool di nodi per codificare correttamente i nodi GKE affinché le regole firewall abbiano effetto. Se necessario, puoi anche utilizzare tag per creare route tra le tue subnet.

Cluster di zona e a livello di area geografica

Puoi creare cluster Standard e Autopilot. I cluster Autopilot sono cluster a livello di area geografica. I cluster standard sono cluster a livello di area geografica o a livello di zona. I cluster di zona possono trovarsi in una zona singola o in più zone. I cluster multizona e a livello di area geografica distribuiscono risorse in più zone all'interno di un'area geografica, migliorando la disponibilità e la resilienza dei cluster.

I cluster di zona hanno le seguenti proprietà:

  • Crea una singola replica del piano di controllo in esecuzione in una singola zona.
  • Se sono in più zone, esegui i nodi in più zone.

I cluster a livello di area geografica hanno le proprietà seguenti:

  • Replica i piani di controllo in tre zone.
  • Può eseguire nodi in più zone o in una singola zona, a seconda delle località dei nodi configurate.

Puoi scegliere di creare cluster di zona o a livello di area geografica al momento della creazione del cluster. Puoi aggiungere nuove zone a un cluster esistente per renderlo multi-zona. Tuttavia, non puoi cambiare un cluster di zona esistente in area geografica e non puoi farlo a livello di zona.

La disponibilità del servizio nei nodi nei cluster gestiti da GKE è regolata dall'accordo sul livello del servizio (SLA) di Compute Engine.

Per saperne di più sui cluster di zona e a livello di area geografica, consulta la documentazione di GKE.

Gestione di identità e accessi

Ruoli e gruppi IAM (Gestione di identità e accessi)

Oltre a concedere ruoli IAM a singoli utenti, puoi anche utilizzare Gruppi per semplificare l'applicazione dei ruoli.

La seguente illustrazione di un layout di criteri IAM mostra il principio del privilegio minimo per un progetto dev configurato per gli sviluppatori per sviluppare e testare le prossime funzionalità e correzioni di bug, nonché un progetto prod per il traffico di produzione:

Gestione di identità e accessi.

Come mostra la tabella seguente, all'interno dell'organizzazione sono presenti quattro gruppi di utenti con diversi livelli di autorizzazioni, concessi tramite i ruoli IAM nei due progetti:

Team Ruolo IAM Progetto Autorizzazioni
Sviluppatori roles/container.developer dev Puoi creare risorse Kubernetes per i cluster esistenti all'interno del progetto e non è consentito creare o eliminare cluster.
Suite operativa roles/container.admin prod Accesso amministrativo completo ai cluster e alle risorse Kubernetes in esecuzione all'interno del progetto.
Sicurezza roles/container.viewer
roles/compute.securityAdmin
prod Crea, modifica ed elimina regole firewall e certificati SSL, oltre a visualizzare le risorse create all'interno di ogni cluster, inclusi i log dei pod in esecuzione.
Rete roles/compute.networkAdmin prod Creare, modificare ed eliminare le risorse di networking, ad eccezione delle regole firewall e dei certificati SSL.

Oltre ai tre team con accesso al progetto prod, a un ulteriore account di servizio viene assegnato il ruolo container.developer per prod, che consente di creare, elencare ed eliminare risorse all'interno del cluster. Gli account di servizio possono essere utilizzati per concedere agli script di automazione o ai framework di deployment la possibilità di agire per tuo conto. I deployment per il tuo progetto di produzione e i tuoi cluster devono essere sottoposti a una pipeline automatizzata.

Nel progetto dev più sviluppatori lavorano sulla stessa applicazione all'interno dello stesso cluster. Ciò è reso possibile dagli spazi dei nomi, che l'utente del cluster può creare. Ogni sviluppatore può creare risorse all'interno del proprio spazio dei nomi, evitando conflitti di denominazione. Possono anche riutilizzare gli stessi file di configurazione YAML per i loro deployment, in modo che le configurazioni rimangano il più simili possibile durante le iterazioni di sviluppo.

Gli spazi dei nomi possono essere utilizzati anche per creare quote su utilizzo di CPU, memoria e archiviazione all'interno del cluster, garantendo che uno sviluppatore non utilizzi troppe risorse all'interno del cluster. Per saperne di più sull'utilizzo degli spazi dei nomi, consulta le best practice per Kubernetes: specificare gli spazi dei nomi in YAML.

La sezione successiva illustra come limitare il funzionamento degli utenti all'interno di determinati spazi dei nomi.

Controllo dell'accesso basato sui ruoli

I cluster GKE che eseguono Kubernetes 1.6 e versioni successive possono sfruttare ulteriori limitazioni rispetto a ciò che gli utenti sono autorizzati a fare nei singoli cluster. IAM può fornire agli utenti l'accesso ai cluster e alle relative risorse, ma il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes ti consente di utilizzare l'API Kubernetes per limitare ulteriormente le azioni che gli utenti possono eseguire all'interno dei loro cluster.

Con RBAC, gli amministratori del cluster applicano criteri granulari ai singoli spazi dei nomi all'interno dei rispettivi cluster o all'intero cluster. Lo strumento kubectl di Kubernetes utilizza le credenziali attive dell'interfaccia a riga di comando gcloud, consentendo agli amministratori dei cluster di mappare i ruoli alle identità di Google Cloud (utenti, account di servizio e Google Gruppi) come soggetti in RoleBindings.

Google Gruppi per RBAC ti consente di utilizzare Gruppi con Kubernetes RBAC. Per utilizzare questa funzionalità, devi configurare Google Gruppi in Google Workspace, creare un cluster con la funzionalità abilitata e utilizzare i RoleBinding per associare i gruppi ai ruoli a cui vuoi associarli. Per saperne di più, vedi Controllo degli accessi basato sui ruoli.

Ad esempio, nella figura che segue sono presenti due utenti, user-a e user-b, ai quali sono stati concessi i ruoli config-reader e pod-reader nello spazio dei nomi app-a.

Autorizzazione RBAC.

Un altro esempio sono i ruoli IAM a livello di progetto Google Cloud che consentono a determinati utenti di accedere a tutti i cluster di un progetto. Inoltre, le associazioni dei ruoli di singoli spazi e cluster a livello di cluster vengono aggiunte tramite RBAC per fornire un accesso granulare alle risorse all'interno di determinati cluster o spazi dei nomi.

RoleBinding IAM.

Kubernetes include alcuni ruoli predefiniti, ma in qualità di amministratore del cluster puoi crearne uno personalizzato che meglio si adatta alle tue esigenze organizzative. Il seguente ruolo di esempio consente agli utenti solo di visualizzare, modificare e aggiornare oggetti ConfigMap, ma non di eliminarli, perché il verbo delete non è incluso:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Dopo aver definito i ruoli, puoi applicarli al cluster o allo spazio dei nomi tramite le associazioni. Le associazioni associano i ruoli agli utenti, ai gruppi o agli account di servizio. L'esempio seguente mostra come associare un ruolo creato in precedenza (config-editor) all'utente bob@example.org e allo spazio dei nomi development.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

Per saperne di più su RBAC, consulta la documentazione di GKE.

Accesso all'immagine e condivisione

Le immagini in Container Registry o Artifact Registry vengono archiviate in Cloud Storage.

Questa sezione illustra i seguenti modi per condividere le immagini:

  • Rendi pubbliche le immagini.
  • Condividi immagini tra progetti.

L'utilizzo di Artifact Registry è importante se abiliti i cluster privati. Nei cluster privati, il runtime del container per il tuo cluster non può estrarre direttamente le immagini container da un Container Registry esterno, a meno che non configuri un Cloud NAT. Il runtime del container può estrarre immagini da Artifact Registry in un cluster privato senza Cloud NAT o accesso privato Google. Devi inserire i nodi in una subnet in cui è abilitato l'accesso privato Google se i nodi devono comunicare direttamente con Artifact Registry (ad esempio, i nodi devono creare nuovi artefatti e archiviarli in Artifact Registry). Per saperne di più, vedi Estrai immagini container da un registro di immagini.

Rendere pubbliche le immagini in Artifact Registry

Puoi rendere pubbliche le immagini rendendo pubblici oggetti e bucket in Artifact Registry. Per istruzioni più dettagliate, consulta la documentazione sul controllo dell'accesso di Artifact Registry.

Se devi utilizzare immagini pubbliche, valuta la possibilità di convalidare l'insieme di immagini pubbliche per cui è possibile eseguire il deployment nei tuoi cluster. Per ulteriori informazioni, consulta la sezione Autorizzazione binaria.

Accesso alle immagini tra progetti in Artifact Registry

Puoi condividere le immagini container tra progetti assicurandoti che i nodi Kubernetes utilizzino un account di servizio. Puoi concedere all'account di servizio l'accesso come Astorage.viewer nei progetti in cui vuoi utilizzare Artifact Registry. Utilizza un account di servizio personalizzato che dispone di autorizzazioni limitate perché l'account di servizio predefinito dispone dell'accesso come editor all'intero progetto.

Per utilizzare un account di servizio diverso per i cluster, fornisci l'account di servizio quando crei il cluster o il pool di nodi tramite il flag --service- account.

Per ulteriori informazioni, consulta la sezione Configurare il controllo dell'accesso.

Determinazione del criterio di pull dell'immagine corretto

La proprietà imagePullPolicy in Kubernetes determina se il kubelet tenta di estrarre un'immagine mentre è in corso l'avvio di un pod. Configura un'impostazione imagePullPolicy appropriata da specificare per le immagini container. Ad esempio, potresti specificare le seguenti norme pull di immagine:

imagePullPolicy: IfNotPresent

In questo caso, il kubelet recupera una copia dell'immagine solo se l'immagine non è disponibile nella cache del nodo.

Per ulteriori informazioni sui possibili criteri di pull delle immagini che puoi specificare, consulta la sezione relativa alle immagini container nella documentazione di Kubernetes.

Utilizzare i controller di ammissione dinamici per applicare i criteri

I controller di ammissione dinamici fanno parte del piano di controllo di Kubernetes. Possono intercettare le richieste in arrivo inviate al server API. I controller di ammissione sono uno strumento potente che può aiutarti ad applicare criteri personalizzati specifici per l'azienda nei tuoi cluster GKE.

Kubernetes supporta due tipi di controller di ammissione: mutazione dei controller di ammissione e convalida dei controller di ammissione.

I controller di ammissione mutanti intercettano le richieste di ammissione e possono mutare (modificare). La richiesta viene quindi trasmessa al server API.

La convalida dei controller di ammissione esamina una richiesta e determina se è valida in base alle regole che hai specificato. Se i controller di ammissione di convalida sono configurati nel cluster, vengono richiamati dopo che la richiesta è stata convalidata dal server API. La convalida dei controller di ammissione può rifiutare le richieste per assicurare la conformità ai criteri definiti nel controller.

Ad esempio, puoi applicare un criterio di pull dell'immagine utilizzando un controller di ammissione mutante per assicurarti che il criterio sia impostato su Always indipendentemente dall'impostazione imagePullPolicy specificata dagli sviluppatori che hanno inviato richieste di creazione dei pod.

Utilizzo delle app predefinite di Google Cloud Marketplace

Puoi anche prendere in considerazione il deployment di app Kubernetes predefinite da Google Cloud Marketplace. Le app Kubernetes elencate su Google Cloud Marketplace vengono testate e verificate da Google, inclusi analisi delle vulnerabilità e contratti con i partner per la manutenzione e l'assistenza.

Utilizzo di Workload Identity per interagire con le API dei servizi Google Cloud

Spesso le architetture aziendali prevedono componenti architettonici che riguardano servizi cloud, come servizi gestiti su cloud e servizi ospitati. Si tratta di un modello comune per cui le applicazioni o i servizi GKE devono comunicare con i servizi gestiti Google Cloud come Cloud Storage e BigQuery. Ad esempio, potresti dover archiviare i record dei clienti dopo che sono stati elaborati dai job batch in GKE in BigQuery per analisi successive.

Workload Identity consente a un account di servizio Kubernetes nel cluster GKE di agire come account di servizio IAM. I pod che utilizzano l'account di servizio Kubernetes configurato autenticano automaticamente come account di servizio IAM quando accedono alle API Google Cloud. Tieni presente che si presume che tu abbia concesso il livello di accesso richiesto per il servizio all'account di servizio Google Cloud.

Gestione della sicurezza del cluster

La sicurezza è una disciplina poliedrica che è di fondamentale importanza nei deployment aziendali dei cluster GKE. In questa sezione vengono trattati diversi fattori che puoi usare per proteggere la sicurezza del tuo cluster.

Analisi delle vulnerabilità per le immagini

Artifact Registry può analizzare le immagini per individuare vulnerabilità note di sicurezza. Le immagini supportate includono Ubuntu, Debian, RedHat e altre (vedi Origini di vulnerabilità per l'elenco completo). Ti consigliamo di eseguire la scansione delle immagini che prevedi di utilizzare nei cluster GKE.

Se possibile, attiva Container Analysis per ridurre ulteriormente i rischi per la sicurezza.

Per visualizzare le vulnerabilità per un'immagine, vedi Scansione automatica delle immagini.

La tua organizzazione può trarre vantaggio dall'automazione del monitoraggio e della ricezione delle notifiche quando vengono apportate modifiche al tuo repository Artifact Registry. Ad esempio, puoi ricevere una notifica quando viene creata una nuova immagine o ne viene eliminata una. Puoi creare una pipeline in cui i listener di applicazioni sono iscritti a un argomento Pub/Sub in cui vengono pubblicati gli eventi Artifact Registry. Puoi quindi utilizzare questi eventi per attivare build o deployment automatici. Per ulteriori informazioni, consulta la documentazione di Artifact Registry.

Autorizzazione binaria

Con Kubernetes, devi determinare se e quando un'immagine deve essere considerata valida per il deployment nel tuo cluster. Per questa attività puoi utilizzare Autorizzazione binaria. Si tratta di un costrutto al momento del deployment che ti consente di definire un flusso di lavoro che applica le firme (atteser) che un'immagine deve avere per poter essere sottoposta a deployment nel tuo cluster.

Il flusso di lavoro è definito in termini di criteri. Quando sposti il codice e pertanto l'immagine container tramite una pipeline CI/CD, Autorizzazione binaria registra le attestazioni per ciascuna di queste fasi come definito nel tuo criterio Autorizzazione binaria. Le attestazioni attestano che l'immagine ha superato i traguardi definiti.

Autorizzazione binaria si integra con l'API GKE e può garantire che il deployment di un'immagine sia soggetto all'immagine con tutte le attestazioni richieste. I tentativi di deployment non riusciti vengono registrati automaticamente e gli amministratori del cluster possono esaminarli e controllarli.

Per un tutorial su come implementare Autorizzazione binaria per GKE mediante Cloud Build, consulta Implementare Autorizzazione binaria mediante Cloud Build e GKE.

Proteggi l'accesso con gVisor in GKE Sandbox

Un container fornisce un livello di isolamento dei livelli di sicurezza e kernel, ma potrebbe comunque essere suscettibile di violazioni che portano utenti malintenzionati ad accedere al sistema operativo dell'host. Un approccio più resiliente all'isolamento della sicurezza tra un container e il sistema operativo host consiste nel creare un altro livello di separazione. Uno degli approcci consiste nell'utilizzare GKE Sandbox.

GKE Sandbox utilizza gVisor, un runtime di container open source rilasciato da Google. Internamente, gVisor crea un kernel virtuale con cui interagiscono i container, che astraggono la copertura di un container al kernel host. Applica inoltre il controllo delle operazioni su file e rete che il container può eseguire.

Poiché la sandbox di GKE crea un ulteriore livello di isolamento, potrebbe comportare un carico aggiuntivo di memoria e CPU. Prima di utilizzare GKE Sandbox, valuta i carichi di lavoro che richiedono questo livello elevato di sicurezza. In genere, i candidati sono servizi basati su immagini esterne.

Per informazioni su come creare un pool di nodi con GKE abilitato, consulta l'articolo relativo all'isolamento dei carichi di lavoro con GKE Sandbox.

Audit logging

L'audit logging di Kubernetes registra tutte le richieste API inviate al server API Kubernetes. Questo logging è utile per rilevare le anomalie e i pattern insoliti di accesso e configurazione della configurazione. Ecco alcuni esempi di ciò che potresti voler controllare e per i quali dovresti ricevere avvisi:

  • Eliminazione di un deployment.
  • Collegamento a exec o utilizzo per accedere a un contenitore con accesso con privilegi.
  • modifica di oggetti ClusterRole o creazione di associazioni di ruoli per i ruoli cluster.
  • Creazione di account di servizio nello spazio dei nomi kube-system.

GKE integra l'audit logging di Kubernetes con Cloud Logging. Puoi accedere a questi log nello stesso modo in cui accedi ai log per le risorse in esecuzione nel tuo progetto Cloud. Le richieste API effettuate al server API Kubernetes possono essere registrate e puoi utilizzarle per esaminare i pattern delle attività API.

Ogni richiesta (evento) acquisita dal server API Kubernetes viene elaborata utilizzando uno o più criteri da te definiti. Può trattarsi di criteri di controllo di Kubernetes che determinano quali eventi vengono registrati o di criteri di controllo di Google Kubernetes Engine che determinano se gli eventi vengono registrati nel log attività dell'amministratore o di dati. I log delle attività di amministrazione sono abilitati per impostazione predefinita. Puoi anche abilitare il logging dell'accesso ai dati se devi registrare i dettagli relativi ai metadati e ai dati letti o scritti all'interno dei cluster. L'abilitazione del logging dell'accesso ai dati può comportare costi aggiuntivi. Per ulteriori informazioni, consulta la documentazione sui prezzi.

Criteri di sicurezza dei pod

Un Vettore di attacco comune consiste nel eseguire il deployment di pod che hanno privilegi inoltrati nel tentativo di ottenere l'accesso a un cluster Kubernetes. Gatekeeper è un controller di ammissione che utilizza criteri che descrivono i contenuti di un pod. Puoi utilizzarlo per limitare l'accesso all'utilizzo degli spazi dei nomi, al tipo di volume e alle funzionalità del sistema operativo sottostante.

Considerazioni sulla sicurezza dei container

Il componente fondamentale per i servizi Kubernetes è il container. La sicurezza dei container è quindi un fattore chiave quando pianifichi i criteri e la sicurezza del cluster. Considera con attenzione quanto segue:

  • Le immagini da cui crei i container.
  • I privilegi che assegni ai contenitori.
  • Interazioni tra container e sistema operativo host.
  • Modalità di accesso e registrazione delle informazioni sensibili da parte dei container.
  • Come gestisci il ciclo di vita dei container nei cluster.

Per ulteriori informazioni e best practice, consulta la documentazione per la creazione e l'utilizzo dei container.

Configurazione delle reti

Kubernetes fornisce un'astrazione di servizio che include il bilanciamento del carico e il rilevamento dei servizi in insiemi di pod all'interno di un cluster, nonché nei sistemi legacy in esecuzione all'esterno del cluster. Le seguenti sezioni descrivono le best practice per la comunicazione tra pod di Kubernetes e altri sistemi, inclusi altri cluster Kubernetes.

Cluster nativi VPC rispetto ai cluster basati su route

In base al modo in cui i cluster GKE instradano il traffico da un pod all'altro, possono essere categorizzati in due tipi.

  • Un cluster che utilizza intervalli IP alias per il routing del traffico, denominato cluster VPC-native.
  • Un cluster che utilizza le route Google Cloud; questo è chiamato cluster basato su route.

I cluster nativi di VPC utilizzano intervalli IP alias per il networking di pod. Ciò significa che il piano di controllo gestisce automaticamente la configurazione del routing per i pod invece di configurare e mantenere route statiche per ogni nodo nel cluster GKE. Utilizzando gli intervalli IP alias, puoi configurare più indirizzi IP interni che rappresentano container o applicazioni ospitate in una VM, senza dover definire un'interfaccia di rete separata. Google Cloud installa automaticamente le route di rete VPC per gli intervalli IP principali e alias per la subnet dell'interfaccia di rete principale. Questo semplifica notevolmente il routing del traffico pod-to-pod.

Inoltre, i cluster nativi di VPC non sono soggetti a quote per le route. Utilizzando gli intervalli IP alias nel tessuto del cluster, consenti l'accesso diretto ai servizi Google come Cloud Storage e BigQuery; questo accesso sarebbe possibile solo con un gateway NAT.

È un pattern comune per consentire alle aziende di far comunicare i propri cluster GKE in modo sicuro con il loro ecosistema di applicazioni e servizi on-premise. Gli intervalli IP alias permettono questa operazione, perché gli indirizzi IP alias sono rilevabili su Cloud VPN o Cloud Interconnect. In questo modo puoi proteggere la connettività tra l'infrastruttura on-premise e l'infrastruttura Google Cloud.

Devi decidere quale tipo di cluster sia più adatto alla tua topologia di rete. I fattori chiave sono la disponibilità degli indirizzi IP nella tua rete, i piani di espansione del cluster (nodi) nella tua azienda e la connettività ad altre applicazioni nell'ecosistema. I cluster nativi di VPC tendono a utilizzare più indirizzi IP nella rete, quindi dovresti tenerne conto. Tieni presente che non puoi eseguire la migrazione di un cluster nativo di VPC a un cluster basato su route dopo la creazione e un cluster basato su route a un cluster nativo di VPC, quindi è importante comprendere le implicazioni della scelta prima di implementarla.

Reti autorizzate per l'accesso al piano di controllo

L'opzione Reti autorizzate limita l'accesso all'endpoint del piano di controllo (il server API) dagli intervalli CIDR specificati e garantisce che solo i team all'interno della rete possano amministrare il cluster.

Questa funzionalità prevede i seguenti requisiti:

  • Sono consentiti solo 50 intervalli CIDR.
  • Se utilizzi una pipeline CI/CD per consentire agli strumenti CI/CD di accedere al server API del cluster, devi aggiungere i relativi indirizzi IP o intervallo CIDR alla lista consentita (consulta la panoramica delle regole firewall VPC).

Cluster privati

Per impostazione predefinita, tutti i nodi in un cluster GKE hanno indirizzi IP pubblici. Una buona prassi è creare cluster privati, che forniscono a tutti i nodi worker solo gli indirizzi IP RFC 1918 privati. I cluster privati impongono l'isolamento delle reti, riducendo la superficie di esposizione al rischio dei tuoi cluster. Se utilizzi cluster privati, per impostazione predefinita, solo i client all'interno della tua rete possono accedere ai servizi nel cluster. Per consentire ai servizi esterni di raggiungere i servizi nel cluster, puoi utilizzare un bilanciatore del carico HTTP(S) o un bilanciatore del carico di rete.

Se vuoi aprire l'accesso al piano di controllo all'esterno della tua rete VPC, puoi utilizzare cluster privati con reti autorizzate. Quando abiliti le reti autorizzate, l'endpoint del piano di controllo del cluster riceve due indirizzi IP, uno interno (privato) e uno pubblico. L'indirizzo IP interno può essere utilizzato da qualsiasi elemento interno alla tua rete che si trova all'interno della stessa area geografica. L'indirizzo IP pubblico del piano di controllo può essere utilizzato da qualsiasi utente o processo esterno alla tua rete e da un intervallo CIDR o indirizzo IP consentito. Puoi utilizzare questa funzionalità anche in combinazione con Cloud Interconnect o Cloud VPN per consentire l'accesso al nodo del piano di controllo solo dal tuo data center privato.

Protezione per l'esfiltrazione di dati

Inoltre, puoi utilizzare i controlli di servizio VPC per ridurre il rischio di esfiltrazione di dati. I Controlli di servizio VPC consentono di proteggere i servizi gestiti di Google Cloud in uno o più progetti mediante la definizione di un perimetro di servizio per l'accesso a tali servizi. Puoi concedere alle applicazioni in esecuzione nei tuoi cluster GKE l'accesso per raggiungere questi servizi gestiti configurando i livelli di accesso appropriati. Puoi anche utilizzare i Controlli di servizio VPC per proteggere il piano di controllo della creazione del cluster GKE.

Comunicare all'interno dello stesso cluster

Service Discovery

Kubernetes ti permette di definire servizi che raggruppano i pod in esecuzione nel cluster in base a un set di etichette. Questo gruppo di pod può essere individuato nel cluster tramite DNS. Per ulteriori informazioni su Service Discovery in Kubernetes, consulta la documentazione Connecting Applications with Services.

DNS

In ogni cluster GKE viene eseguito il deployment di un server DNS locale del cluster, kube-dns, che gestisce la mappatura dei nomi dei servizi agli IP dei pod integri. Per impostazione predefinita, il server DNS Kubernetes restituisce l'indirizzo IP del cluster del servizio. Questo indirizzo IP è statico per tutta la durata del servizio. Quando invii il traffico a questo IP, le istanze iptable sul pacchetto del bilanciamento del carico del nodo attraverso i pod pronti che corrispondono ai selettori del servizio. Questi iptables sono programmati automaticamente dal servizio kube-proxy in esecuzione su ogni nodo.

Per ulteriori informazioni su kube-dns, vedi Rilevamento dei servizi e DNS. Per informazioni sulla scalabilità, consulta Scalabilità DNS.

Flusso pacchetto: ClusterIP

Il seguente diagramma mostra la risposta DNS e il flusso di pacchetti di un servizio Kubernetes standard. Mentre gli indirizzi IP dei pod sono instradabili dall'esterno del cluster, l'indirizzo IP del cluster di un servizio è accessibile solo all'interno del cluster. Questi indirizzi IP virtuali vengono implementati eseguendo la traduzione degli indirizzi di rete (DNAT) in ogni nodo Kubernetes. Il servizio kube-proxy in esecuzione su ogni nodo mantiene aggiornate le regole di forwarding su ogni nodo che mappa l'indirizzo IP del cluster agli indirizzi IP dei pod integri nel cluster. Se esiste un pod del servizio in esecuzione sul nodo locale, viene utilizzato quel pod, altrimenti viene scelto un pod casuale nel cluster.

Servizio ClusterIP.

Per ulteriori informazioni su come viene implementato ClusterIP, consulta la documentazione di Kubernetes.

Servizi headless

Se vuoi rilevare il servizio e monitorarne l'integrità, ma preferisci che il servizio DNS ti restituisca gli indirizzi IP dei pod anziché un indirizzo IP virtuale, puoi eseguire il provisioning del servizio con il campo ClusterIP impostato su None, che rende il servizio headless.

In questo caso, il server DNS restituisce un elenco di record A che mappano il nome DNS del tuo servizio ai record A dei pod pronti corrispondenti ai selettori di etichette definiti dal servizio. I record nella risposta ruotano per facilitare la distribuzione del carico tra i vari pod. Alcuni resolver DNS lato client potrebbero memorizzare nella cache le risposte DNS, rendendo inefficace la rotazione del record A. I vantaggi dell'utilizzo del ClusterIP sono elencati nella documentazione di Kubernetes. Per ulteriori informazioni sull'utilizzo di ClusterIP in GKE, vedi Esposizione di applicazioni utilizzando i servizi.

Un tipico caso d'uso per i servizi headless è con StatefulSet. Gli StatefulSet sono ideali per eseguire applicazioni stateful che richiedono spazio di archiviazione e networking stabili tra le loro repliche. Questo tipo di deployment esegue il provisioning dei pod che hanno un'identità di rete stabile, pertanto i relativi nomi host possono essere risolti nel cluster. Anche se l'indirizzo IP del pod può cambiare, la voce DNS del nome host viene mantenuta aggiornata e risolvibile.

Di seguito è riportato un esempio di risposta DNS e pattern di traffico per un servizio headless. Gli indirizzi IP dei pod sono instradabili tramite le tabelle di route di subnet predefinite di Google Cloud e sono accessibili direttamente dalla tua applicazione.

Esempio di risposta DNS e pattern di traffico per un servizio headless.

Criteri di rete

Puoi utilizzare l'applicazione dei criteri di rete di GKE per controllare la comunicazione tra i pod e i servizi del cluster. Per definire un criterio di rete su GKE, puoi utilizzare l'API Kubernetes Network Policy per creare regole firewall a livello di pod. Queste regole firewall determinano quali pod e servizi possono accedere uno all'altro all'interno del cluster.

I criteri di rete migliorano la sicurezza dei carichi di lavoro in esecuzione nel cluster. Ad esempio, puoi creare un criterio di rete per assicurarti che un servizio front-end compromesso nella tua applicazione non possa comunicare direttamente con un servizio di fatturazione o di contabilità a diversi livelli.

Puoi anche utilizzare i criteri di rete per isolare i carichi di lavoro appartenenti a tenant diversi. Ad esempio, puoi fornire una multi-tenancy sicura definendo un modello in cui è presente un tenant per ogni spazio dei nomi. In un modello di questo tipo, le regole dei criteri di rete possono garantire che pod e servizi in un determinato spazio dei nomi non possano accedere ad altri pod o servizi in uno spazio dei nomi diverso.

Connessione a un cluster GKE dall'interno di Google Cloud

Per connetterti ai servizi dall'esterno del cluster, ma all'interno dello spazio di indirizzi IP privati della rete Google Cloud, utilizza il bilanciamento del carico interno. Quando crei un servizio con type: Load Balancer e un'annotazione cloud.google.com/load-balancer-type: Internal in Kubernetes, nel tuo progetto Google viene creato un bilanciatore del carico di rete interno configurato per distribuire il traffico TCP e UDP tra i pod.

Connessione dall'interno di un cluster a servizi esterni

In molti casi è necessario connettere le applicazioni in esecuzione all'interno di Kubernetes a un servizio, un database o un'applicazione che risiedono all'esterno del cluster. Sono disponibili tre opzioni, come spiegato nelle sezioni seguenti.

OpzioneDescrizione
Domini StubIn Kubernetes 1.6 e versioni successive, puoi configurare il servizio DNS interno del cluster ("kube-dns") per inoltrare le query DNS per un determinato dominio a un server DNS esterno. Ciò è utile quando hai server DNS autorevoli su cui eseguire query per un dominio che i pod Kubernetes devono utilizzare.
Servizi per nomi esterniI servizi dei nomi esterni consentono di mappare un record DNS a un nome di servizio all'interno del cluster. In questo caso, le ricerche DNS per il servizio in-cluster restituiscono un record CNAME di tua scelta. Utilizza questa opzione se hai solo alcuni record che vuoi mappare di nuovo a servizi DNS esistenti.
Servizi senza selettoriPuoi creare servizi senza un selettore e quindi aggiungervi manualmente gli endpoint per completare il rilevamento dei servizi con i valori corretti. Ciò consente di utilizzare lo stesso meccanismo di Service Discovery per i servizi in-cluster, garantendo al contempo che i sistemi senza Service Discovery tramite DNS siano comunque raggiungibili. Sebbene questo approccio sia il più flessibile, richiede anche la massima configurazione e manutenzione a lungo termine.

Per ulteriori informazioni sul DNS, consulta la pagina relativa alla documentazione sui pod e servizi DNS di Kubernetes.

Configurazione dei servizi in Kubernetes per la ricezione del traffico Internet

I servizi Kubernetes possono essere esposti utilizzando NodePort, ClusterIP e LoadBalancer.

Tuttavia, quando disponi di molti servizi rivolti all'esterno, puoi utilizzare le risorse Kubernetes in entrata. Ingress fornisce un punto di ingresso per il cluster e ti consente di definire regole di routing che instradano le richieste in entrata a uno o più servizi di backend nel tuo cluster. In GKE, il controller GKE Ingress implementa una risorsa Ingress come bilanciatore del carico HTTP(S) di Google Cloud e la configura in base alle informazioni nella risorsa Ingress e nei servizi associati. Per ulteriori informazioni, consulta Configurazione di Ingress per il bilanciamento del carico esterno.

Una risorsa Ingress di Kubernetes può essere utilizzata solo quando le applicazioni gestiscono il traffico su HTTP(S). Se i tuoi servizi di backend utilizzano protocolli TCP o UDP, devi utilizzare un bilanciatore del carico di rete. Questo potrebbe essere necessario, ad esempio, se hai bisogno di esporre il tuo database come servizio.

Configurazione backend

Un BackendConfig è una definizione di risorsa personalizzata che può fornire una configurazione prescrittiva aggiuntiva utilizzata dal controller Kubernetes Ingress. Quando esegui il deployment di un oggetto Ingress nel tuo cluster GKE, il controller Kubernetes Kubernetes configura un bilanciatore del carico HTTP(S) che instrada le richieste in entrata ai servizi di backend come specificato nel manifest Ingress.

Puoi integrare la configurazione del bilanciatore del carico con specifiche come le seguenti:

  • Abilitazione della memorizzazione nella cache con Cloud CDN.
  • Aggiunta di indirizzi IP o liste consentite CIDR con Google Cloud Armor.
  • Controllo dell'accesso a livello di applicazione con Identity-Aware Proxy (IAP).
  • Configurazione dei timeout dei servizi e di timeout dei pool di connessioni per i servizi regolati dall'oggetto Ingress in un cluster.

Per ulteriori informazioni sulla configurazione della risorsa personalizzata BackendConfig in GKE, vedi Funzionalità in entrata.

Utilizzo di un mesh di servizi

Un mesh di servizi offre un modo uniforme per connettere, proteggere e gestire i microservizi in esecuzione nei cluster Kubernetes. Ad esempio, il mesh di servizi Istio che puoi aggiungere come componente aggiuntivo di GKE può gestire l'autenticazione e la comunicazione da servizio a servizio, applicare i criteri di accesso e raccogliere punti dati di telemetria avanzati da utilizzare per controllare e amministrare i tuoi cluster GKE.

Le funzionalità principali offerte da un mesh di servizi sono le seguenti:

  • Gestione del traffico. Il mesh di servizi consente di definire regole granulari che determinano il modo in cui il traffico viene instradato e suddiviso tra i servizi o tra diverse versioni dello stesso servizio. In questo modo è più semplice implementare i deployment canary e blu/verde.

  • Osservabilità integrata. Il mesh registra le metriche relative al traffico di rete (Livello 4 e 7) in modo uniforme senza richiedere la scrittura del codice per strumentare i servizi.

  • Sicurezza. Il mesh abilita TLS reciproco (mTLS) tra i servizi. Non solo fornisce canali sicuri per i dati in transito, ma ti aiuta anche a gestire l'autenticazione e l'autorizzazione dei servizi all'interno del mesh.

In breve, i mesh di servizi come Istio consentono di delegare le attività a livello di sistema all'infrastruttura mesh. Ciò migliora l'agilità complessiva, la robustezza e l'accoppiamento flessibile dei servizi in esecuzione nei cluster Kubernetes.

Per informazioni sull'utilizzo di un mesh di servizi con Anthos, vedi Informazioni su Anthos Service Mesh.

Firewall

Viene eseguito il provisioning dei nodi GKE come istanze in Compute Engine. Pertanto, rispettano lo stesso meccanismo firewall stateful di altre istanze. Queste regole firewall vengono applicate alle istanze nella tua rete utilizzando i tag. Ogni pool di nodi riceve un proprio set di tag che puoi utilizzare nelle regole. Per impostazione predefinita, ogni istanza appartenente a un pool di nodi riceve un tag che identifica un cluster Kubernetes Engine specifico di cui fa parte questo pool di nodi. Questo tag viene utilizzato nelle regole firewall che Kubernetes Engine crea automaticamente per te. Puoi aggiungere i tuoi tag personalizzati al momento della creazione del cluster o del pool di nodi utilizzando il flag --tags nell'interfaccia a riga di comando gcloud.

Ad esempio, per consentire a un bilanciatore del carico interno di accedere alla porta 8080 su tutti i nodi, devi utilizzare i seguenti comandi:

gcloud compute firewall-rules create allow-8080-fwr \
    --target-tags allow-8080 \
    --allow tcp:8080 \
    --network gke \
    --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

L'esempio seguente mostra come codificare un cluster in modo che il traffico Internet possa accedere ai nodi sulla porta 30000 mentre l'altro cluster è codificato per consentire il traffico dalla VPN alla porta 40000. Questo è utile quando si espone un servizio tramite un NoNoPort, che dovrebbe essere accessibile solo tramite reti con privilegi, come una VPN, a un data center aziendale o da un altro cluster all'interno del progetto.

Codificare due cluster in modo diverso.

Connessione a un data center on-premise

Puoi utilizzare Cloud Interconnect o Cloud VPN per connetterti ai data center on-premise. Queste opzioni non si escludono a vicenda, pertanto potresti utilizzare una combinazione basata sul carico di lavoro e sui requisiti. Le opzioni sono le seguenti:

  • Utilizza interconnessione dedicata per trasferire grandi quantità di dati tra le reti con bassa latenza.

  • Utilizza Partner Interconnect se il tuo data center non si trova in una struttura di colocation di Dedicated Interconnect. Google ha più di 100 punti di presenza (PoP) che si connettono a fornitori di servizi in tutto il mondo.

  • Utilizza il peering diretto per i carichi di lavoro che richiedono larghezza di banda dedicata, che sono sensibili alla latenza e richiedono l'accesso a Google Workspace e alle API di Google supportate. Il peering diretto è una connessione di livello 3, eseguita scambiando route BGP, e quindi richiede un ASN registrato.

  • Utilizza il peering con operatori se non hai un ASN registrato o hai relazioni esistenti con un provider di servizi preferito. Il peering con operatori è uguale al peering diretto, ma viene eseguito tramite un provider di servizi.

  • Utilizza Cloud VPN se è richiesta la crittografia IPSec o se vuoi estendere la tua rete privata nella rete Compute Engine privata. Cloud VPN è configurato su opzioni di interconnessione e Internet di livello 3 (1, 2 e 3).

Gestione dell'operabilità dei cluster

In questa sezione vengono descritti i fattori chiave da considerare quando si amministra e si utilizzano i cluster GKE.

Quote delle risorse

le quote delle risorse Kubernetes) forniscono vincoli che limitano il consumo consentito delle risorse aggregate per ogni spazio dei nomi in un cluster. Se hai cluster con spazi dei nomi Kubernetes che isolano le funzioni aziendali o le fasi di sviluppo, puoi utilizzare le quote per limitare un'ampia gamma di risorse, ad esempio l'utilizzo della CPU, la memoria o il numero di pod e servizi che possono essere creati all'interno di uno spazio dei nomi. Per garantire la stabilità del piano di controllo dei tuoi cluster GKE, Kubernetes applica automaticamente quote di risorse predefinite, non sostituibili a ogni spazio dei nomi in qualsiasi cluster GKE con un massimo di cinque nodi.

Limiti delle risorse

Puoi utilizzare l'oggetto Kubernetes LimitRange per applicare vincoli granulari ai limiti minimo e massimo di risorse con cui è possibile creare container e pod. L'esempio seguente mostra come utilizzare LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: sample-limits
spec:
  limits:
    - max:
        cpu: "400m"
        memory: "1Gi"
      defaultRequest:
        cpu: "200m"
        memory: "500Mi"
      type: Container

Budget per l'interruzione dei pod

I budget per l'interruzione dei pod (PDB) contribuiscono a proteggerti dall'eliminazione volontaria o accidentale dei pod o dei deployment da parte del tuo team. I PDB non possono impedire interruzioni involontarie che possono essere causate da un arresto o un riavvio di un nodo. In genere un operatore crea un PDB per un'applicazione che definisce il numero minimo di repliche dei pod per l'applicazione.

In un'azienda in cui gli sviluppatori lavorano su più applicazioni, si verificano degli errori e uno sviluppatore o un amministratore potrebbero eseguire accidentalmente uno script che elimina pod o deployment, ovvero le risorse Kubernetes che vengono eliminate. Quando definisci un PDB, puoi assicurarti di mantenere sempre un set di risorse minimo efficiente per le tue applicazioni Kubernetes.

I PDB che configuri per i tuoi cluster GKE vengono rispettati durante gli upgrade di GKE. In questo modo puoi controllare la disponibilità delle tue applicazioni durante un upgrade. L'esempio seguente mostra come configurare un PDB.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
  spec:
    minAvailable: 4
    selector:
      matchLabels:
        app: nginx

Gestione degli upgrade di Kubernetes

Mantieni aggiornati i tuoi cluster Kubernetes su GKE all'ultima versione di Kubernetes adatta ai tuoi requisiti. Puoi scegliere di eseguire automaticamente l'upgrade del tuo piano di controllo o dei tuoi nodi oppure puoi controllare personalmente gli upgrade.

Puoi esaminare le notifiche di upgrade nella console, nei bollettini di sicurezza di Anthos e dalle notifiche di upgrade del cluster. Se esegui l'upgrade dei nodi manualmente, ti consigliamo di attivare l'upgrade della versione dopo aver controllato i contenuti rilasciati e di aver testato le applicazioni in un cluster con sandbox che è in esecuzione sulla versione a cui vuoi eseguire l'upgrade.

Quando il piano di controllo di un cluster di zona è in fase di upgrade, non è disponibile. Questo significa che non puoi interagire con il server API per aggiungere o rimuovere risorse nel tuo cluster. Se non puoi usufruire dei tempi di inattività per l'upgrade di un piano di controllo, puoi renderlo ad alta disponibilità eseguendo il deployment di cluster GKE a livello di area geografica. Con questo approccio, puoi avere più piani di controllo distribuiti tra le zone. Quando è in corso l'upgrade di un piano di controllo, tutte le richieste del piano di controllo al server API vengono indirizzate agli altri piani di controllo.

Quando viene applicato un upgrade, GKE applica un aggiornamento in sequenza ai nodi worker, svuotando sistematicamente, eseguendo il downgrade e eseguendo l'upgrade di un nodo alla volta, quando un nuovo nodo sostitutivo diventa disponibile per rispondere alle richieste in entrata.

Riparazione automatica dei nodi

La funzionalità di riparazione automatica dei nodi GKE gestisce i controlli di integrità dei nodi GKE. Se uno o più nodi risultano in stato non integro, GKE avvia il processo di riparazione dei nodi.

Se il tuo cluster GKE ha più pool di nodi, la funzionalità di riparazione automatica ti offre un controllo granulare sui pool di nodi per i quali vuoi abilitare la riparazione automatica dei nodi.

Scalabilità automatica dei cluster GKE

Le aziende riscontrano spesso un carico diverso sulle applicazioni in esecuzione nei cluster Kubernetes. Per rispondere a questi cambiamenti basati sul business, puoi consentire ai tuoi cluster GKE di rispondere automaticamente e di fare lo scale up e lo scale down in base alle metriche.

La scalabilità automatica include più dimensioni, come illustrato nelle sezioni seguenti.

Gestore della scalabilità automatica dei cluster

Il scalatore automatico del cluster GKE aggiunge e rimuove automaticamente i nodi dal cluster in base alla domanda dei tuoi carichi di lavoro. Il gestore della scalabilità automatica dei cluster è abilitato per i singoli pool di nodi. Per ogni pool di nodi, GKE controlla se sono presenti pod in attesa di pianificazione per mancanza di capacità. In questo caso, il gestore della scalabilità automatica dei cluster aggiunge nodi al pool di nodi in questione.

Il gestore della scalabilità automatica dei cluster esegue lo scale down o lo scale up in base alle richieste di risorse. se un nodo è sottoutilizzato e se i pod in esecuzione possono essere pianificati su altri nodi che hanno capacità, il nodo sottoutilizzato viene svuotato e terminato.

Puoi impostare i limiti per un pool di nodi specificando i nodi minimo e massimo in cui il gestore della scalabilità automatica dei cluster può scalare.

Provisioning automatico dei nodi

Il provisioning automatico dei nodi consente al gestore della scalabilità automatica dei cluster GKE di eseguire automaticamente il provisioning di pool di nodi aggiuntivi quando il gestore della scalabilità automatica determina che sono richiesti. Il gestore della scalabilità automatica dei cluster può anche eliminare i pool di nodi di cui è stato eseguito il provisioning automatico quando non sono presenti nodi nei pool di nodi.

Le decisioni relative al provisioning automatico dei nodi vengono prese dal gestore della scalabilità automatica del cluster GKE in base a una serie di fattori. Includono la quantità di risorse richieste dai pod, le affinità dei pod che hai specificato e le incompatibilità e tolleranze dei nodi definite nel tuo cluster GKE.

Il provisioning automatico dei nodi è utile se hai diversi carichi di lavoro in esecuzione nei cluster GKE. Ad esempio, se il tuo cluster GKE ha un carico di lavoro dipendente dalla GPU, puoi eseguirlo in un pool di nodi dedicato di cui è stato eseguito il provisioning con nodi che supportano GPU. Puoi definire i limiti di scalabilità del pool di nodi specificando una dimensione minima e massima del pool di nodi.

Per scoprire di più sul provisioning automatico dei nodi e su quando abilitarlo, consulta Utilizzo del provisioning automatico dei nodi.

Scalabilità automatica pod orizzontale

Kubernetes ti permette di creare un Horizontal Pod Autoscaler che ti consente di configurare la modalità di scalabilità dei deployment o del ReplicaSet Kubernetes, nonché le metriche su cui deve essere basata la decisione di scalabilità. Per impostazione predefinita, il controller Horizontal Pod Autoscaler basa le decisioni sulla scalabilità automatica sull'utilizzo della CPU, Tuttavia, il controller Scalabilità automatica pod orizzontale può calcolare in che modo scalare i pod in base a metriche personalizzate, ad esempio il conteggio di una richiesta HTTP. Affinché un gestore della scalabilità automatica orizzontale dei pod risponda alle metriche personalizzate, è solitamente necessaria una strumentazione di monitoraggio aggiuntiva.

Per ulteriori informazioni, consulta la documentazione di Kubernetes e GKE.

Scalabilità automatica pod verticale

La funzionalità Scalabilità automatica pod verticale nei cluster GKE ti consente di ridurre il carico di lavoro di specificare richieste ottimali di CPU e memoria per i container. Se necessario, la scalabilità automatica pod verticale regola le allocazioni delle risorse effettuate ai container nel cluster. La scalabilità automatica pod verticale consente di ottimizzare l'utilizzo delle risorse per i cluster ottimizzandola a livello di container su ciascun nodo. Inoltre, ti consente di risparmiare tempo amministrativo che altrimenti dovresti investire nella gestione delle tue risorse.

La scalabilità automatica pod verticale funziona in tandem con la funzionalità di provisioning automatico dei nodi descritta nella sezione successiva.

A causa di limitazioni di Kubernetes, le richieste di risorse su un pod possono essere modificate solo al riavvio di un pod. Pertanto, per apportare modifiche, la scalabilità automatica del pod verticale rimuove il pod. Per ulteriori informazioni, consulta la documentazione di GKE e Kubernetes.

Autopilot

Autopilot significa che GKE esegue il provisioning e la gestione dell'infrastruttura sottostante del cluster per tuo conto. Con Autopilot, vengono gestiti elementi come i seguenti:

  • Nodi e pool di nodi

  • Provisioning delle risorse

  • Tipi di immagini nodo

  • Funzionalità di rete come tipo di cluster e intervalli CIDR

  • Funzionalità di sicurezza come Workload Identity o Shielded VM

Autopilot è utile se vuoi ridurre il carico operativo e non è necessario configurare elementi specifici per carichi di lavoro più complessi.

Passaggi successivi