Concetto - Distribuire un'applicazione

Completato

Prima di distribuire l'applicazione in Kubernetes, si esamineranno le distribuzioni di Kubernetes e ne verranno illustrate le limitazioni nello scenario.

Che cosa sono le distribuzioni di Kubernetes?

Una distribuzione Kubernetes è un'evoluzione dei pod. Le distribuzioni eseguono il wrapping dei pod in un oggetto intelligente che ne consente la scalabilità orizzontale. È possibile duplicare e ridimensionare facilmente l'applicazione in modo da supportare un carico maggiore senza la necessità di configurare regole di rete complesse.

Le distribuzioni consentono di aggiornare le applicazioni senza tempi di inattività modificando semplicemente il tag immagine. L'aggiornamento di una distribuzione disattiva le app online una alla volta e le sostituisce con la versione più recente anziché eliminare tutte le app e crearne di nuove, il che significa che la distribuzione può aggiornare i pod all'interno di esso senza alcun effetto visibile sulla disponibilità.

Benché l'uso delle distribuzioni sui pod presenti molti vantaggi, non sono in grado di gestire adeguatamente lo scenario.

Questo scenario prevede un'applicazione basata su eventi che riceve un numero elevato di eventi in diversi momenti. Senza un oggetto utilità di scalabilità automatica KEDA o HPA, è necessario modificare manualmente il numero di repliche per elaborare il numero di eventi e ridurre le risorse della distribuzione quando il carico torna normale.

Manifesto della distribuzione di esempio

Ecco un frammento di codice del manifesto della distribuzione:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: contoso-microservice
spec:
  replicas: 10                      # Tells K8S the number of pods needed to process the Redis list items
  selector:                         # Define the wrapping strategy
    matchLabels:                    # Match all pods with the defined labels
      app: contoso-microservice     # Labels follow the `name: value` template
  template:                         # Template of the pod inside the deployment
    metadata:
      labels:
        app: contoso-microservice
    spec:
      containers:
        - image: mcr.microsoft.com/mslearn/samples/redis-client:latest
          name: contoso-microservice

Nel manifesto di esempio replicas è impostato su 10, ovvero il numero più alto che è possibile impostare per le repliche necessarie disponibili per l'elaborazione del numero massimo di eventi. Con questo approccio tuttavia l'applicazione utilizza troppe risorse negli orari non di punta e ciò potrebbe lasciare altre distribuzioni nel cluster senza risorse sufficienti.

Una soluzione consiste nell'usare un'utilità HPA autonoma per monitorare l'utilizzo della CPU dei pod, che è un'opzione migliore rispetto al ridimensionamento manuale in entrambe le direzioni. HPA non si concentra tuttavia sul numero di eventi ricevuti nell'elenco Redis.

La soluzione migliore consiste nell'usare KEDA e un'utilità di scalabilità automatica di Redis per eseguire query sull'elenco e stabilire se sono necessari più o meno pod per elaborare gli eventi.