Concept - Déployer une application

Effectué

Avant de déployer votre application sur Kubernetes, évaluons les déploiements Kubernetes et abordons leurs limitations par rapport à notre scénario.

Que sont les déploiements Kubernetes ?

Un Deployment Kubernetes est une évolution des pods. Des déploiements encapsulent des pods dans un objet intelligent leur permettant d’effectuer un scale-out. Vous pouvez facilement dupliquer et mettre à l’échelle votre application pour qu’elle exécute une charge plus importante sans devoir configurer des règles réseau complexes.

Les déploiements vous permettent de mettre à jour vos applications sans temps d’arrêt, simplement en changeant la balise de l’image. La mise à jour d’un déploiement désactive les applications en ligne une par une et les remplace par la version la plus récente, plutôt que la suppression de toutes les applications et la création de nouvelles applications. ce qui signifie que le déploiement peut mettre à jour les pods sans effet visible sur la disponibilité.

Bien qu’il existe de nombreux avantages à utiliser des déploiements sur des pods, ils ne peuvent pas correctement gérer notre scénario.

Ce scénario implique une application pilotée par les événements qui reçoit un grand nombre d’événements à différents moments. Sans objet de mise à l’échelle KEDA ou un HPA, vous devriez ajuster manuellement le nombre de réplicas pour traiter le nombre d’événements et effectuer un scale-down du déploiement lorsque la charge redevient normale.

Exemple de manifeste de déploiement

Voici un extrait de notre manifeste de déploiement :

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

Dans l’exemple de manifeste, replicas est défini sur 10. Soit le nombre le plus élevé que nous pouvons définir pour les réplicas disponibles nécessaires au traitement du nombre maximal d’événements. Cela entraîne toutefois l’utilisation par l’application d’un trop grand nombre de ressources pendant les heures creuses, ce qui peut priver d’autres déploiements au sein du cluster.

Une solution consiste à utiliser un HPA autonome pour superviser l’utilisation du processeur par des pods, ce qui est une meilleure option que la mise à l’échelle manuelle dans les deux sens. Le HPA ne se concentre toutefois pas sur le nombre d’événements reçus dans la liste Redis.

La meilleure solution consiste à utiliser KEDA et un utilitaire de mise à l’échelle Redis pour interroger la liste et déterminer s’il faut ajouter ou supprimer des pods pour traiter les événements.