Carichi di lavoro con container in GDC

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

Questa pagina è rivolta agli sviluppatori del gruppo di operatori di applicazioni, responsabili della gestione dei carichi di lavoro delle applicazioni per la loro organizzazione. Per saperne di più, consulta la sezione Pubblico della documentazione di GDC con air gap.

Applicazioni Kubernetes per un ambiente disconnesso

GKE on GDC è un servizio Kubernetes gestito che incorpora per impostazione predefinita molte funzionalità di GKE nel tuo universo GDC. 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 on GDC è disponibile dalla console GDC, da gcloud CLI e da Terraform. Per saperne di più sui cluster Kubernetes di GDC, consulta la panoramica dei cluster Kubernetes. Per saperne di più sui concetti chiave di Kubernetes, consulta la documentazione di GKE per iniziare a scoprire Kubernetes.

Stato del carico di lavoro con container

I container in GDC vengono sottoposti a deployment nei cluster Kubernetes come segue:

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

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

Carichi di lavoro stateless

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

Kubernetes utilizza la Deployment risorsa per eseguire il deployment di applicazioni stateless come pod uniformi e non univoci Pods. I deployment gestiscono lo stato desiderato dell'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 Pod della risorsa Deployment.

Le applicazioni stateless sono in contrasto con i carichi di lavoro 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 stateful è 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 per l'utilizzo da parte dell'applicazione stateful.

Kubernetes uses the StatefulSet risorsa 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 dalla posizione in cui è pianificato.

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

Archiviazione permanente per i container

GDC fornisce l'archiviazione a blocchi permanente tramite PersistentVolumeClaim (PVC) oggetti. Un PVC è una richiesta di archiviazione a cui fa riferimento un oggetto Pod. Un pod è un gruppo di uno o più container, con risorse di archiviazione e di rete condivise. 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 carichi di lavoro stateful in modo che i volumi sottostanti vengano creati on demand. In GDC, configuri il provisioning dinamico creando l'oggetto StorageClass preinstallato standard-rwo. L'oggetto standard-rwo è una classe di archiviazione a blocchi ReadWriteOnce (RWO) che consente a un volume di accedere a un solo nodo alla volta.

Puoi anche creare un VolumeSnapshot oggetto per copiare il volume di archiviazione dell'applicazione containerizzata 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