Concetti di scalabilità

Completato

Prima di trovare una soluzione di scalabilità, è necessario comprendere qual è la scalabilità e come si applica alle applicazioni Kubernetes.

In questa unità vengono esaminati alcuni concetti di scalabilità.

Scalabilità

La scalabilità descrive la capacità di un'applicazione o di un sistema di gestire una quantità crescente di lavoro aggiungendo altre risorse.

Nello scenario di esempio, la quantità di lavoro che riscontra un aumento è il numero di richieste dei clienti. La quantità di risorse aggiunte può essere rappresentata in due modi: scalabilità verticale e scalabilità orizzontale.

Scalabilità verticale

La scalabilità verticale o la scalabilità verticale si riferisce al ridimensionamento di un sistema aggiungendo altre risorse fisiche, ad esempio memoria o potenza della CPU. Ad esempio, se il sito Web della società utilizza una quantità eccessiva di memoria, è possibile aggiornare l'istanza della macchina virtuale in modo da includere più memoria mantenendo allo stesso tempo la stessa applicazione sottostante.

Vertical scaling diagram.

In breve, il ridimensionamento verticale comporta l'aumento delle dimensioni della macchina virtuale mantenendo invariato il numero di applicazioni. Questo approccio è utile se si dispone di applicazioni monolitiche che richiedono molta potenza di calcolo, ma sono troppo costose per suddividersi in parti più piccole. Queste applicazioni sono ospitate principalmente in macchine virtuali anziché in sistemi distribuiti.

Nonostante un costo più gestibile, le macchine virtuali molto grandi possono diventare molto costose. Il costo dell'aggiunta di una maggiore potenza di calcolo è superiore al costo della duplicazione di macchine virtuali di piccole dimensioni. È previsto un limite massimo per il numero di risorse che è possibile aggiungere a una singola macchina virtuale, ovvero è necessario duplicare la macchina virtuale dopo aver raggiunto il limite superiore.

Scalabilità orizzontale

La scalabilità orizzontale, o la scalabilità orizzontale, si riferisce al ridimensionamento di un sistema duplicando l'applicazione e bilanciando il carico tra le istanze dell'applicazione.

Horizontal scaling diagram.

Il ridimensionamento orizzontale è utile per le applicazioni distribuite, ad esempio quelle distribuite nel servizio Azure Kubernetes e i sistemi senza stato, perché è possibile creare più contenitori con la stessa applicazione in una singola macchina virtuale. La scalabilità orizzontale consente di estrarre la maggior parte delle risorse pagando al tempo stesso per una singola macchina virtuale.

Nello scenario di esempio il sito aziendale è senza stato. Ciò significa che l'aumento del numero di istanze è il miglior corso di azione. Kubernetes offre una risorsa predefinita denominata HorizontalPodAutoscaler (HPA) che consente di aumentare le istanze delle distribuzioni.

Scalabilità manuale in Kubernetes

Prima di esaminare HPA, si esaminerà come ridimensionare manualmente un'applicazione Kubernetes.

Ogni distribuzione è associata a un'altra risorsa denominata ReplicaSet. Un oggetto ReplicaSet è responsabile della gestione di uno stato di replica desiderato e del ridimensionamento dell'applicazione reale in o in uscita per mantenere lo stato desiderato uguale allo stato reale. È possibile controllare il numero di repliche in una distribuzione tramite la spec.replicas chiave nella specifica di distribuzione. Questa chiave imposta il numero di repliche desiderate nel Set di repliche sottostante e forza il controller di replica a mantenere questo numero di repliche in qualsiasi momento.

È anche possibile controllare il numero di repliche in una distribuzione con il kubectl scale deploy/contoso-website --replicas <number> comando . Questo comando modificherà in modo dinamico il numero di repliche desiderate in una distribuzione e aumenterà o ridurrà il numero di istanze dell'applicazione.

HorizontalPodAutoscaler (HPA)

HPA è la risorsa nativa di Kubernetes 1.8+ che fornisce scalabilità orizzontale ai pod nel cluster. Monitora l'API Metriche ogni 30 secondi per rilevare eventuali modifiche nel numero delle repliche desiderate. Se il numero di repliche desiderato è diverso dal numero di repliche corrente, il gestore controller, che gestisce gli oggetti HPA, ridimensiona la distribuzione in o in uscita.

HorizontalPodAutoscaling design diagram.

Le risorse HPA usano il gruppo API autoscaling in Kubernetes. Esistono due versioni di questo gruppo di API: v1 e v2. La v1 versione consente la scalabilità della distribuzione in base solo alle metriche della CPU. La v2 versione consente il monitoraggio nativo della CPU e della memoria. In questo modulo viene usata la v2 versione .

Ogni HPA è associata a un riferimento alla scalabilità, definito nella chiave spec.scaleTargetRef del manifesto HPA. Questo riferimento al ridimensionamento deve avere pod sottostanti da dimensionare. In caso contrario, la risorsa HPA non funzionerà perché non è possibile applicare il ridimensionamento a oggetti che non possono essere dimensionati, ad esempio DaemonSet.

È importante che ogni pod abbia una richiesta di risorsa impostata nella specifica. L'algoritmo HPA non può calcolare correttamente le metriche e determinare l'utilizzo delle risorse senza questa impostazione. È possibile impostare questa limitazione tramite la spec.template.spec.containers[].resources chiave nel manifesto della distribuzione, come illustrato nell'esempio seguente:

spec:
  template:
    spec:
      containers:
        - resources:
            requests:
              cpu: 250m
              memory: 256M
            limits:
              cpu: 500m
              memory: 512M

Esempio di manifesto HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Verificare le conoscenze

1.

Che cos'è la scalabilità orizzontale?

2.

Perché è importante avere una richiesta di risorse impostata nei pod associati a una risorsa HPA?

3.

Perché la scalabilità verticale è meno consigliata per le applicazioni senza stato?