Scalare un deployment Kubernetes

Gli ambienti Kubernetes ti consentono di scalare dinamicamente le risorse del database man mano che cambiano le richieste dei carichi di lavoro. Utilizza queste procedure di scalabilità se hai eseguito il deployment di Spanner Omni utilizzando il grafico Helm.

Prima di iniziare

Prima di scalare il deployment Kubernetes, devi:

Come best practice, consigliamo di scalare verticalmente fino ad almeno 32 GB di memoria per server prima di aggiungere altri server per scalare orizzontalmente.

Limitazioni

Lo scaling in Kubernetes presenta le seguenti limitazioni:

  • Solo server non root: lo scaling orizzontale è supportato per le istanze non root. Lo scaling del server radice non è supportato.

  • Vincoli di archiviazione StatefulSet: poiché i volumeClaimTemplates di Kubernetes sono immutabili, non puoi espandere i dischi dei pod utilizzando un singolo comando helm upgrade. Al contrario, lo scaling dello spazio di archiviazione richiede passaggi manuali di espansione del volume.

Scalabilità verticale

Per regolare le risorse di CPU o memoria per i server, aggiorna la configurazione utilizzando un upgrade di Helm:

helm upgrade spanner-omni HELM_CHART_PATH \
  --version VERSION \
  --reuse-values \
  --set resources.cpu=CPU_CORES \
  --set resources.memory=MEMORY_LIMIT \
  -n NAMESPACE

Sostituisci quanto segue:

  • HELM_CHART_PATH: il percorso del grafico Helm, ad esempio oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni.
  • VERSION: la versione del grafico Helm, ad esempio 0.2.0.
  • CPU_CORES: il numero di core vCPU da assegnare a ogni pod server, ad esempio 8.
  • MEMORY_LIMIT: il limite di RAM per ogni pod server, ad esempio 32Gi.
  • NAMESPACE: lo spazio dei nomi Kubernetes del deployment, ad esempio spanner-ns.

Scalabilità orizzontale

Per scalare orizzontalmente, aggiungi altri server al deployment. Lo scaling orizzontale è supportato per i server non root.

Aggiungere server non root

Per aggiungere server non root, aumenta il numero di repliche nella configurazione del grafico Helm. Puoi scalare tutte le zone in modo uniforme o scalare una zona specifica.

Scalabilità uniforme

Per scalare ogni zona del deployment a 15 server, esegui il seguente comando:

helm upgrade spanner-omni HELM_CHART_PATH \
  --version VERSION \
  --reuse-values \
  --set deployment.replicasPerZone=REPLICAS \
  -n NAMESPACE

Sostituisci quanto segue:

  • HELM_CHART_PATH: il percorso del grafico Helm, ad esempio oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni.
  • VERSION: la versione del grafico Helm, ad esempio 0.2.0.
  • REPLICAS: il numero di repliche del server di destinazione per zona, ad esempio 15.
  • NAMESPACE: lo spazio dei nomi Kubernetes, ad esempio spanner-ns.

Scalare una zona specifica

Se la tua implementazione iniziale ha configurato conteggi dei server diversi per le singole zone, puoi scegliere come target una sola zona. Ad esempio, per aumentare le repliche della prima zona all'interno della prima località a 15, esegui il seguente comando:

helm upgrade spanner-omni HELM_CHART_PATH \
  --version VERSION \
  --reuse-values \
  --set locations[0].zones[0].replicas=REPLICAS \
  -n NAMESPACE

Sostituisci REPLICAS con il numero di repliche della zona di destinazione, ad esempio 15.

Per verificare che i nuovi server siano stati aggiunti correttamente al deployment, esegui una query sulla CLI Spanner Omni per elencare i server di deployment o visualizzare la dashboard Grafana.

spanner deployment servers list \
  --zone=ZONE \
  --deployment-endpoint=ENDPOINT

Sostituisci quanto segue:

  • ZONE: la zona che vuoi elencare, ad esempio us-central1-a.
  • ENDPOINT: l'endpoint esterno del deployment, ad esempio ${ENDPOINT}:15000.

Rimuovere i server non root

La riduzione del numero di server richiede passaggi aggiuntivi perché il sistema deve spostare in modo sicuro le partizioni di dati dai server ritirati. Poiché i StatefulSet di Kubernetes rimuovono i pod dall'indice più alto a quello più basso, devi innanzitutto rimuovere i server non root con l'indice più alto.

Per fare lo scale down del numero di server, segui questi passaggi:

  1. Elenca i server nella tua zona per identificare i candidati alla rimozione:

    spanner deployment servers list \
      --zone=ZONE \
      --deployment-endpoint=ENDPOINT
    

    Output di esempio:

    NAME                                                          HOST                        PORT_BASE  ROOT  STATE
    zones/us-central1-a/servers/spanner-a-0.pod.spanner-ns:15000  spanner-a-0.pod.spanner-ns  15000      true  -
    zones/us-central1-a/servers/spanner-a-1.pod.spanner-ns:15000  spanner-a-1.pod.spanner-ns  15000      -     -
    

    Elimina il server non root ritirato con l'indice più alto (ad esempio spanner-a-1.pod.spanner-ns:15000):

    spanner deployment servers delete SERVER_NAME \
      --zone=ZONE \
      --deployment-endpoint=ENDPOINT
    

    Sostituisci SERVER_NAME con l'identificatore del server, ad esempio spanner-a-1.pod.spanner-ns:15000.

    Controlla l'elenco dei server finché il server di destinazione non viene rimosso dall'elenco. Dopo l'eliminazione, il server passa a uno stato non integro nel sistema e viene rimosso dal percorso di servizio attivo.

  2. Fare lo scale down del deployment Helm eseguendo un comando di upgrade di Helm in modo che corrisponda al numero di repliche target. Ad esempio, per ridurre le repliche per zona a 1 pod, esegui questo comando:

    helm upgrade spanner-omni HELM_CHART_PATH \
      --version VERSION \
      --reuse-values \
      --set deployment.replicasPerZone=REPLICAS \
      -n NAMESPACE
    

    Sostituisci REPLICAS con il conteggio repliche aggiornato, ad esempio 1.

  3. Elimina le richieste di volumi permanenti (PVC) Kubernetes associate ai pod rimossi. Per evitare la perdita accidentale di dati, Helm e Kubernetes non eliminano automaticamente i PVC durante la riduzione di un StatefulSet. Elimina manualmente i PVC per recuperare completamente lo spazio di archiviazione:

    kubectl delete pvc LOGS_PVC DATA_PVC -n NAMESPACE
    

    Ad esempio, per eliminare i volumi di log e dati per spanner-a-1 nello spazio dei nomi spanner-ns:

    kubectl delete pvc logs-volume-spanner-a-1 data-volume-spanner-a-1 -n spanner-ns
    

Aggiungi una zona

L'aggiunta di una nuova zona al deployment aumenta la disponibilità e protegge il tuo database da interruzioni di una sola zona.

Ad esempio, il seguente comando inizializza un deployment in esecuzione a zona singola su Google Kubernetes Engine (GKE) nella zona us-east1-b della regione us:

helm upgrade --install spanner-omni HELM_CHART_PATH \
  --version VERSION \
  --set resources.cpu=2 \
  --set resources.memory=8Gi \
  --set global.platform=gke \
  --set-json 'locations=[{"name":"us","zones":[{"name":"us-east1-b","shortName":"east-b"}]}]' \
  -n NAMESPACE

Aggiungi la zona us-east1-c a questa configurazione seguendo questi passaggi:

  1. Avvia i pod nella nuova zona eseguendo il comando helm upgrade e passando un blocco JSON aggiornato che include la nuova zona di località:

    helm upgrade spanner-omni HELM_CHART_PATH \
      --version VERSION \
      --reuse-values \
      --set-json 'locations=[{"name":"us","zones":[{"name":"us-east1-b","shortName":"east-b"},{"name":"us-east1-c","shortName":"east-c"}]}]' \
      -n NAMESPACE
    
  2. Aggiungi la nuova zona utilizzando la CLI Spanner Omni. Attendi che i pod del server root nella zona appena creata entrino nello stato Running e pronto. Quindi, esegui il comando di creazione della zona:

    spanner deployment zones create NEW_ZONE \
      --location=LOCATION \
      --root-servers=ROOT_SERVERS_LIST \
      --deployment-endpoint=ENDPOINT
    

    Sostituisci quanto segue:

    • NEW_ZONE: l'identificatore della zona da aggiungere, ad esempio us-east1-c.
    • LOCATION: la posizione del deployment, ad esempio us.
    • ROOT_SERVERS_LIST: un elenco separato da virgole di endpoint del server radice nella nuova zona, ad esempio spanner-east-c-0.pod.spanner-ns:15000,spanner-east-c-1.pod.spanner-ns:15000,spanner-east-c-2.pod.spanner-ns:15000.
    • ENDPOINT: l'endpoint di deployment esterno, ad esempio ${ENDPOINT}:15000.
  3. Attendi il completamento della creazione della zona. La replica di schemi e tabelle di database esistenti in una nuova zona richiede tempo. Monitora l'avanzamento della sincronizzazione delle zone elencando le zone di deployment:

    spanner deployment zones list --deployment-endpoint=ENDPOINT
    

Rimuovere una zona

Puoi dismettere una zona attiva dal deployment multizona per ridurre le risorse o allinearti alle modifiche della topologia.

Rimuovi la zona us-east1-c creata nella sezione precedente eseguendo i seguenti passaggi:

  1. Elimina la zona e avvia l'eliminazione della zona all'interno di Spanner Omni:

    spanner deployment zones delete ZONE --deployment-endpoint=ENDPOINT
    

    Sostituisci ZONE con la zona da rimuovere, ad esempio us-east1-c.

  2. Verifica che la zona sia stata rimossa. Esegui un comando di elenco e attendi finché la zona non viene più visualizzata nell'output:

    spanner deployment zones list --deployment-endpoint=ENDPOINT
    
  3. Rimuovi i server dal cluster Kubernetes eseguendo un comando helm upgrade e passando un blocco JSON delle località aggiornato che esclude la zona rimossa:

    helm upgrade spanner-omni HELM_CHART_PATH \
      --version VERSION \
      --reuse-values \
      --set-json 'locations=[{"name":"us","zones":[{"name":"us-east1-b","shortName":"east-b"}]}]' \
      -n NAMESPACE
    

Scalare lo spazio di archiviazione

Poiché i volumeClaimTemplates Kubernetes sono immutabili, non puoi fare lo scale up delle capacità di archiviazione dei pod utilizzando direttamente il comando helm upgrade. Devi invece eseguire un'espansione manuale del volume. Per maggiori informazioni, consulta la Guida all'espansione del volume StatefulSet di GKE.

Per espandere lo spazio di archiviazione del disco:

  1. Definisci i parametri per l'espansione del volume come variabili di ambiente nel terminale:

    NEW_SIZE="NEW_SIZE"
    NAMESPACE="NAMESPACE"
    RELEASE_NAME="spanner-omni"
    STATEFULSET_NAMES="STATEFULSET_NAME_1 STATEFULSET_NAME_2 STATEFULSET_NAME_3"
    HELM_CHART_PATH="HELM_CHART_PATH"
    VERSION="VERSION"
    

    Sostituisci quanto segue:

    • NEW_SIZE: la dimensione della capacità di archiviazione di destinazione, ad esempio 200Gi.
    • NAMESPACE: lo spazio dei nomi Kubernetes, ad esempio spanner-ns.
    • STATEFULSET_NAME_1, STATEFULSET_NAME_2, ...: i nomi dei StatefulSets nel tuo deployment, in genere corrispondenti ai nomi brevi delle tue zone (ad esempio, spanner-east-b spanner-east-c).
    • HELM_CHART_PATH: il percorso del grafico Helm, ad esempio oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni.
    • VERSION: la versione del grafico Helm, ad esempio 0.2.0.
  2. Esegui i comandi per applicare patch alle PVC, elimina gli StatefulSet (lasciando intatti i pod di backend) ed esegui l'upgrade del deployment Helm:

    # Patch all associated PVCs directly.
    for pvc in $(kubectl get pvc -n $NAMESPACE \
      -l app.kubernetes.io/instance=$RELEASE_NAME \
      -o name | grep "data-volume"); do
      kubectl patch $pvc -n $NAMESPACE -p "{\"spec\":{\"resources\":{\"requests\":{\"storage\":\"$NEW_SIZE\"}}}}"
    done
    
    # Delete the StatefulSet while leaving backend pods intact (orphan cascade).
    kubectl delete statefulset $STATEFULSET_NAMES -n $NAMESPACE --cascade=orphan
    
    # Run Helm upgrade to align the templates with the expanded size.
    helm upgrade $RELEASE_NAME $HELM_CHART_PATH \
      --version $VERSION \
      --reuse-values \
      --set storage.data.size=$NEW_SIZE \
      -n $NAMESPACE
    

Passaggi successivi