Carichi di lavoro con container in GDC

Questa pagina di panoramica spiega il modello operativo per i carichi di lavoro dei container in un cluster Kubernetes con air gap di Google Distributed Cloud (GDC). GDC fornisce un servizio Kubernetes gestito che supporta applicazioni containerizzate native di Kubernetes ampiamente utilizzate e supportate su Google Kubernetes Engine (GKE).

Questa pagina è rivolta agli sviluppatori all'interno del gruppo di operatori di applicazioni, che sono responsabili della gestione dei carichi di lavoro delle applicazioni per la propria organizzazione. Per saperne di più, consulta la documentazione sulle audience per GDC air-gapped.

Applicazioni Kubernetes per un ambiente disconnesso

GKE su GDC è un servizio Kubernetes gestito che incorpora molte funzionalità GKE nel tuo universo GDC per impostazione predefinita. Questo servizio elimina la necessità di installare, eseguire l'upgrade, integrare ed eseguire Kubernetes open source autonomamente. Puoi utilizzare e gestire la distribuzione Kubernetes fornita con un'API KRM standard come qualsiasi altra offerta Kubernetes dichiarativa e idempotente. Allo stesso modo, GKE su GDC viene offerto dalla console GDC, da gcloud CLI e da Terraform. Per ulteriori informazioni sui cluster Kubernetes GDC, consulta la panoramica dei cluster Kubernetes. Per ulteriori informazioni sui concetti chiave di Kubernetes, consulta la documentazione di GKE per Inizia a scoprire Kubernetes.

Stato del carico di lavoro del container

I container in GDC vengono implementati nei cluster Kubernetes come:

Puoi fare lo scale out i nodi del cluster GDC Kubernetes in base ai requisiti dei tuoi carichi di lavoro containerizzati, anche dopo il provisioning del cluster, man mano che i tuoi requisiti di calcolo si evolvono.

Kubernetes fornisce diverse risorse di carico di lavoro integrate per ottenere lo stato dell'applicazione container che preferisci. Per saperne di più, consulta la documentazione sui workload di Kubernetes.

Workload stateless

I workload stateless sono applicazioni che non archiviano lo stato dei dati o delle applicazioni nel cluster Kubernetes o in uno spazio di archiviazione permanente. Invece, i dati e lo stato dell'applicazione rimangono con il client, il che rende le applicazioni stateless più scalabili. Ad esempio, un'applicazione frontend può essere stateless: puoi eseguire il deployment di più repliche per aumentare la disponibilità e fare lo scale down quando la domanda è bassa e le repliche non hanno bisogno di identità uniche.

Kubernetes utilizza la risorsa Deployment per eseguire il deployment di applicazioni stateless come pod uniformi e non univoci. I deployment gestiscono lo stato desiderato della tua applicazione, ad esempio:

  • La quantità di pod per eseguire l'applicazione.
  • La versione dell'immagine container da eseguire.
  • Le etichette dei pod.

Puoi modificare lo stato desiderato in modo dinamico tramite gli aggiornamenti alla specifica Deployment della risorsa Pod.

Le applicazioni stateless sono in contrasto con i workload stateful, che utilizzano l'archiviazione permanente per salvare i dati e lo stato dell'applicazione.

Carichi di lavoro stateful

I carichi di lavoro stateful sono applicazioni che salvano i dati nell'archiviazione su disco permanente per l'utilizzo da parte del server, dei client e di altre applicazioni. Un esempio di applicazione con stato è un database o un archivio chiave-valore in cui i dati vengono salvati e recuperati da altre applicazioni. Devi eseguire il provisioning dell'archiviazione permanente da utilizzare per l'applicazione con stato.

Kubernetes utilizza la risorsa StatefulSet per eseguire il deployment di applicazioni stateful. I pod nelle risorse StatefulSet non sono intercambiabili: ogni pod ha un identificatore univoco che viene mantenuto indipendentemente da dove viene pianificato.

Le applicazioni stateful sono diverse dai workload stateless, in cui i dati del client non vengono salvati sul server tra le sessioni.

Archiviazione permanente per i container

GDC fornisce archiviazione a blocchi e di file persistente tramite oggetti PersistentVolumeClaim (PVC). Un PVC è una richiesta di archiviazione a cui fa riferimento un oggetto Pod. Un pod è un gruppo di uno o più container con spazio di archiviazione e risorse di rete condivisi. Un PVC ha un ciclo di vita indipendente dal pod, il che gli consente di persistere oltre un singolo pod.

Puoi eseguire il provisioning dinamico dell'archiviazione permanente per i tuoi carichi di lavoro stateful in modo che i volumi sottostanti vengano creati on demand. In GDC, configuri il provisioning dinamico creando uno dei seguenti oggetti StorageClass preinstallati:

  • standard-rwo: La classe di archiviazione a blocchi ReadWriteOnce (RWO). È possibile accedere al volume solo da un nodo alla volta. Questa classe di archiviazione offre una garanzia e un limite di operazioni di input e output al secondo (IOPS) pari a 3 IOPS per GiB.

  • system-performance-rwo: La classe di archiviazione a blocchi per le prestazioni ReadWriteOnce. Questa classe di archiviazione è una versione più performante dell'archiviazione RWO che offre una garanzia e un limite di 30 IOPS per GiB.

Puoi anche creare un oggetto VolumeSnapshot per copiare il volume di archiviazione dell'applicazione contenitore in un momento specifico senza creare un volume completamente nuovo. Ad esempio, un amministratore di database potrebbe creare uno snapshot del volume per eseguire il backup dei database prima di apportare modifiche di modifica o eliminazione.

Passaggi successivi