StatefulSet

Autopilot Standard

In questa pagina viene descritto l'utilizzo degli oggetti StatefulSet in Google Kubernetes Engine (GKE). Puoi anche scoprire come eseguire il deployment di un'applicazione stateful.

Perché utilizzare gli StatefulSet

Puoi utilizzare gli StatefulSet per eseguire il deployment di applicazioni stateful e di cluster in cui vengono salvati i dati nell'archiviazione permanente, come i dischi permanenti di Compute Engine. Gli StatefulSet sono adatti per il deployment di Kafka, MySQL, Redis, ZooKeeper e altre applicazioni che richiedono identità univoche e permanenti e nomi host stabili.

Gli StatefulSet rappresentano un insieme di pod con identità univoche e permanenti e nomi host stabili che GKE mantiene, indipendentemente da dove sono pianificati. Gli StatefulSet utilizzano un modello di pod, che contiene una specifica per i relativi pod. Le informazioni sullo stato e altri dati resilienti per un determinato pod StatefulSet vengono conservati in volumi permanenti associati a ogni pod nello StatefulSet. I pod StatefulSet possono essere riavviati in qualsiasi momento.

Per le applicazioni stateless, utilizza i deployment.

Indicizzazione dello StatefulSet

Gli StatefulSet utilizzano un indice ordinale per l'identità e l'ordine dei pod. Per impostazione predefinita, il deployment dei pod StatefulSet viene eseguito in ordine sequenziale e vengono terminati in ordine ordinale. Ad esempio, uno StatefulSet denominato web ha i relativi pod denominati web-0, web-1 e web-2. Quando le specifiche del pod web vengono modificate, i relativi pod vengono arrestati e ricreati in modo ordinato, in questo esempio web-2 viene terminato per primo, poi web-1 e così via. In alternativa, puoi specificare il campo podManagementPolicy: Parallel in modo che un oggetto StatefulSet venga lanciato o termini tutti i suoi pod in parallelo, invece di attendere che i pod diventino in esecuzione e pronti o vengano terminati prima dell'avvio o della terminazione di un altro pod.

Pianifica il networking per gli StatefulSet

Gli StatefulSet offrono l'archiviazione permanente sotto forma di volume permanente e di un'identità di rete univoca (nome host). La seguente tabella include le avvertenze di cui gli operatori di applicazioni devono essere a conoscenza quando configurano uno StatefulSet:

Avvertenze sul networking	Descrizione	Best practice
Servizi GKE anziché indirizzi IP fissi	Sebbene le repliche dei pod abbiano un indice ordinale univoco, supporti volumi per replica e identità di rete (nome host), gli indirizzi IP assegnati a una replica possono cambiare se un pod viene riprogrammato o rimosso da GKE.	Per mitigare i problemi di networking, l'architettura deve utilizzare le risorse del servizio Kubernetes. Per saperne di più, vedi Tipi di servizi Kubernetes. Nota: le applicazioni su Kubernetes possono memorizzare nella cache gli indirizzi IP se sono installati altri componenti. Ad esempio, JVM memorizza nella cache le ricerche dei nomi a tempo indeterminato se è installato un gestore di sicurezza. Come sviluppatore di applicazioni, dovresti controllare la tua applicazione per assicurarti che non memorizzi nella cache gli indirizzi IP risolti da questi servizi.
Servizi headless	Quando è inizializzato, uno StatefulSet viene associato a un servizio headless corrispondente.	Assicurati che `metadata.name` nel servizio corrisponda al campo `serviceName` nel tuo StatefulSet. In questo modo, ogni pod nell'applicazione può essere indirizzato a un indirizzo di rete univoco e ben definito. Inoltre, il servizio headless fornisce un record multi-IP per ogni replica nello StatefulSet, consentendo il rilevamento completo dei peer.
Rilevamento peer	Le applicazioni stateful richiedono un numero minimo (quorum) di repliche per funzionare con la disponibilità completa.	Poiché i pod possono arrestarsi in modo anomalo, essere ripianificati o rimossi, ogni replica in uno StatefulSet dovrebbe essere in grado di uscire e rientrare nel quorum. Le applicazioni che richiedono il peering dovrebbero avere la capacità di rilevare altri peer tramite i servizi headless in Kubernetes.
Controllo di integrità basato su probe di idoneità e probe di attività	La tua applicazione deve avere configurato correttamente i probe di idoneità, di attività e di avvio, ove applicabile. La selezione dei timeout per ciascun probe dipende dai requisiti della tua applicazione.	Per i probe di idoneità, segui queste best practice per configurare la tua applicazione in modo che contrassegni l'idoneità quando è pronta a gestire il traffico: probe di attività: puoi utilizzarli per segnalare se un container è integro. Ad esempio, una replica di database può utilizzare un probe di attività per indicare che GKE deve riavviare la replica, ad esempio la condizione deadlock probe di idoneità: puoi utilizzare i probe di idoneità per rimuovere temporaneamente una replica dal traffico del traffico. Ad esempio, se hai una replica di database che deve eseguire un backup, potresti utilizzare un probe di idoneità per interrompere temporaneamente la ricezione delle richieste. Probe di avvio: puoi utilizzare i probe di avvio per ritardare i controlli di integrità finché non vengono completate le inizializzazioni a lunga esecuzione. Ad esempio, se hai una replica di database, potresti utilizzare un probe di avvio per attendere l'inizializzazione dei dati archiviati dal disco.

Per scoprire di più sui probe, consulta Configura probe di attività, idoneità e avvio.

Creazione dell'esempio degli StatefulSet

Puoi creare uno StatefulSet utilizzando kubectl apply.

Una volta creato, lo StatefulSet garantisce che il numero desiderato di pod sia in esecuzione e disponibile in ogni momento. Lo StatefulSet sostituisce automaticamente i pod che hanno esito negativo o vengono rimossi dai relativi nodi e associa automaticamente i nuovi pod alle risorse di archiviazione, alle richieste e ai limiti di risorse e ad altre configurazioni definite nella specifica dei pod dello StatefulSet.

Nell'esempio seguente è riportato un file manifest Service e StatefulSet:

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # Label selector that determines which Pods belong to the StatefulSet
                 # Must match spec: template: metadata: labels
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx # Pod template's label selector
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

In questo esempio:

Viene creato un oggetto Service denominato nginx, indicato dal campo metadata: name. Il servizio ha come target un'app chiamata nginx, indicata da labels: app: nginx e selector: app: nginx. Il servizio espone la porta 80 e la chiama web. Questo servizio controlla il dominio di rete e il routing del traffico Internet all'applicazione containerizzata di cui è stato eseguito il deployment da StatefulSet.
Viene creato uno StatefulSet denominato web con tre pod replicati (replicas: 3).
Il modello di pod (spec: template) indica che i suoi pod sono etichettati app: nginx.
Le specifiche del pod (template: spec) indicano che i pod dello StatefulSet eseguono un container, nginx, che esegue l'immagine nginx-slim alla versione 0.8. L'immagine container è ospitata da Container Registry.
Le specifiche del pod utilizzano la porta web aperta dal servizio.
template: spec: volumeMounts specifica un mountPath, denominato www. mountPath è il percorso all'interno del container in cui deve essere montato un volume di archiviazione.
Lo StatefulSet esegue il provisioning di un oggetto PersistentVolumeClaim, www, con 1 GB di spazio di archiviazione di cui è stato eseguito il provisioning.

Per riassumere, la specifica pod contiene le seguenti istruzioni:

Assegna l'etichetta app: nginx a ogni pod.
In ogni pod, esegui un container denominato nginx.
Esegui l'immagine nginx-slim alla versione 0.8.
Fai in modo che i pod utilizzino la porta 80.
Salva i dati nel percorso di montaggio.

Per ulteriori informazioni sulle configurazioni StatefulSet, consulta la documentazione di riferimento sull'API StatefulSet.

Aggiornamento degli StatefulSet

Puoi aggiornare uno StatefulSet modificando la specifica dei pod, compresi i container e le immagini container. Puoi anche aggiornare le richieste, i limiti, le etichette e le annotazioni dell'oggetto. Per aggiornare uno StatefulSet, puoi utilizzare kubectl, l'API Kubernetes o il menu dei carichi di lavoro GKE nella console Google Cloud.

Per decidere come gestire gli aggiornamenti, gli StatefulSet utilizzano una strategia di aggiornamento definita in spec: updateStrategy. Esistono due strategie, OnDelete e RollingUpdate:

OnDelete non elimina e ricrea automaticamente i pod quando viene modificata la configurazione dell'oggetto. Devi eliminare manualmente i vecchi pod per far sì che il controller crei pod aggiornati.
RollingUpdate elimina e ricrea automaticamente i pod quando viene modificata la configurazione dell'oggetto. I nuovi pod devono essere in stato In esecuzione e Pronto prima che i loro predecessori vengano eliminati. Con questa strategia, la modifica della specifica del pod attiva automaticamente un'implementazione. Questa è la strategia di aggiornamento predefinita per gli StatefulSet.

Gli StatefulSet aggiornano i pod in ordine ordinale inverso. Puoi monitorare le implementazioni degli aggiornamenti eseguendo questo comando:

kubectl rollout status statefulset STATEFULSET_NAME

Esegui il partizionamento degli aggiornamenti in sequenza

Puoi partizionare gli aggiornamenti in sequenza. Il partizionamento è utile se vuoi aggiungere un aggiornamento graduale, implementare una versione canary o eseguire un'implementazione graduale.

Quando esegui il partizionamento di un aggiornamento, tutti i pod con un valore ordinale maggiore o uguale al valore della partizione vengono aggiornati quando aggiorni la specifica dei pod dello StatefulSet. I pod con un valore inferiore al valore di partizione non vengono aggiornati e, anche se vengono eliminati, vengono ricreati utilizzando la versione precedente della specifica. Se il valore della partizione è maggiore del numero di repliche, gli aggiornamenti non vengono propagati ai pod.