Chapitre 8. Déploiements

8.1. Comprendre les objets Deployment et DeploymentConfig

Les objets API Deployment et DeploymentConfig dans OpenShift Container Platform fournissent deux méthodes similaires mais différentes pour une gestion fine des applications utilisateur courantes. Ils sont composés des objets API distincts suivants :

Un objet DeploymentConfig ou Deployment, qui décrit l'état souhaité d'un composant particulier de l'application en tant que modèle de pod.
DeploymentConfig impliquent un ou plusieurs objets replication controllers, qui contiennent un enregistrement ponctuel de l'état d'un déploiement en tant que modèle de pod. De même, les objets Deployment impliquent un ou plusieurs replica sets, un successeur des contrôleurs de réplication.
Un ou plusieurs pods, qui représentent une instance d'une version particulière d'une application.

8.1.1. Les éléments constitutifs d'un déploiement

Les déploiements et les configurations de déploiement sont activés par l'utilisation d'objets API Kubernetes natifs ReplicaSet et ReplicationController, respectivement, en tant qu'éléments constitutifs.

Les utilisateurs n'ont pas à manipuler les contrôleurs de réplication, les ensembles de répliques ou les pods appartenant aux objets ou aux déploiements DeploymentConfig. Les systèmes de déploiement garantissent que les changements sont propagés de manière appropriée.

Astuce

Si les stratégies de déploiement existantes ne sont pas adaptées à votre cas d'utilisation et que vous devez exécuter des étapes manuelles pendant le cycle de vie de votre déploiement, vous devriez envisager de créer une stratégie de déploiement personnalisée.

Les sections suivantes fournissent plus de détails sur ces objets.

8.1.1.1. Contrôleurs de réplication

Un contrôleur de réplication veille à ce qu'un nombre déterminé de répliques d'un module soient en cours d'exécution à tout moment. Si des pods sortent ou sont supprimés, le contrôleur de réplication agit pour en instancier d'autres jusqu'au nombre défini. De même, s'il y a plus de pods en cours d'exécution que souhaité, il en supprime autant que nécessaire pour atteindre le nombre défini.

La configuration d'un contrôleur de réplication comprend

Le nombre de répliques souhaitées, qui peut être ajusté au moment de l'exécution.
Une définition de Pod à utiliser lors de la création d'un pod répliqué.
Un sélecteur pour identifier les modules gérés.

Un sélecteur est un ensemble d'étiquettes attribuées aux pods gérés par le contrôleur de réplication. Ces étiquettes sont incluses dans la définition de Pod que le contrôleur de réplication instancie. Le contrôleur de réplication utilise le sélecteur pour déterminer combien d'instances du pod sont déjà en cours d'exécution afin de procéder aux ajustements nécessaires.

Le contrôleur de réplication n'effectue pas de mise à l'échelle automatique en fonction de la charge ou du trafic, car il ne suit ni l'un ni l'autre. Il faut donc que le nombre de répliques soit ajusté par un système de mise à l'échelle automatique externe.

Voici un exemple de définition d'un contrôleur de réplication :

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1  1
  selector:    2
    name: frontend
  template:    3
    metadata:
      labels:  4
        name: frontend 5
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

1: Le nombre de copies du module à exécuter.
2: Le sélecteur d'étiquettes du module à exécuter.
3: Un modèle pour le module que le contrôleur crée.
4: Les étiquettes sur le pod doivent inclure celles du sélecteur d'étiquettes.
5: La longueur maximale du nom après expansion des paramètres est de 63 caractères.

8.1.1.2. Jeux de répliques

Similaire à un contrôleur de réplication, un ReplicaSet est un objet natif de l'API Kubernetes qui garantit qu'un nombre spécifié de répliques de pods est en cours d'exécution à tout moment. La différence entre un ensemble de répliques et un contrôleur de réplication est qu'un ensemble de répliques prend en charge les exigences de sélecteur basées sur l'ensemble alors qu'un contrôleur de réplication ne prend en charge que les exigences de sélecteur basées sur l'égalité.

Note

N'utilisez les ensembles de répliques que si vous avez besoin d'une orchestration personnalisée des mises à jour ou si vous n'avez pas besoin de mises à jour du tout. Dans le cas contraire, utilisez les déploiements. Les ensembles de répliques peuvent être utilisés indépendamment, mais ils sont utilisés par les déploiements pour orchestrer la création, la suppression et les mises à jour des modules. Les déploiements gèrent automatiquement leurs ensembles de répliques, fournissent des mises à jour déclaratives aux pods et n'ont pas à gérer manuellement les ensembles de répliques qu'ils créent.

Voici un exemple de définition de ReplicaSet:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: 1
    matchLabels: 2
      tier: frontend
    matchExpressions: 3
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

1: Une requête d'étiquette sur un ensemble de ressources. Les résultats de matchLabels et matchExpressions sont logiquement joints.
2: Sélecteur basé sur l'égalité pour spécifier les ressources dont les étiquettes correspondent au sélecteur.
3: Sélecteur basé sur un ensemble pour filtrer les clés. Cela permet de sélectionner toutes les ressources dont la clé est égale à tier et la valeur à frontend.

8.1.2. Objets DeploymentConfig

S'appuyant sur les contrôleurs de réplication, OpenShift Container Platform ajoute une prise en charge étendue du cycle de vie du développement et du déploiement de logiciels grâce au concept d'objets DeploymentConfig. Dans le cas le plus simple, un objet DeploymentConfig crée un nouveau contrôleur de réplication et lui permet de démarrer des pods.

Cependant, les déploiements d'OpenShift Container Platform à partir d'objets DeploymentConfig offrent également la possibilité de passer d'un déploiement existant d'une image à un nouveau déploiement et de définir des crochets à exécuter avant ou après la création du contrôleur de réplication.

Le système de déploiement DeploymentConfig offre les possibilités suivantes :

Un objet DeploymentConfig, qui est un modèle pour les applications en cours d'exécution.
Déclencheurs de déploiements automatisés en réponse à des événements.
Stratégies de déploiement personnalisables par l'utilisateur pour passer de la version précédente à la nouvelle version. Une stratégie s'exécute à l'intérieur d'un pod, communément appelé processus de déploiement.
Un ensemble de crochets (crochets de cycle de vie) pour exécuter un comportement personnalisé à différents moments du cycle de vie d'un déploiement.
Versionnement de votre application pour permettre des retours en arrière soit manuellement, soit automatiquement en cas d'échec du déploiement.
Mise à l'échelle manuelle de la réplication et mise à l'échelle automatique.

Lorsque vous créez un objet DeploymentConfig, un contrôleur de réplication est créé pour représenter le modèle de pod de l'objet DeploymentConfig. Si le déploiement change, un nouveau contrôleur de réplication est créé avec le dernier modèle de pod et un processus de déploiement s'exécute pour réduire l'ancien contrôleur de réplication et augmenter le nouveau.

Les instances de votre application sont automatiquement ajoutées et supprimées des équilibreurs de charge et des routeurs au fur et à mesure de leur création. Tant que votre application prend en charge l'arrêt progressif lorsqu'elle reçoit le signal TERM, vous pouvez vous assurer que les connexions utilisateur en cours ont une chance de se terminer normalement.

L'objet OpenShift Container Platform DeploymentConfig définit les détails suivants :

Les éléments d'une définition ReplicationController.
Déclencheurs pour la création automatique d'un nouveau déploiement.
La stratégie de transition entre les déploiements.
Crochets du cycle de vie.

Chaque fois qu'un déploiement est déclenché, que ce soit manuellement ou automatiquement, un module de déploiement gère le déploiement (y compris la réduction de l'ancien contrôleur de réplication, l'augmentation du nouveau et l'exécution des crochets). Le module de déploiement reste en place pendant une durée indéterminée après l'achèvement du déploiement afin de conserver les journaux du déploiement. Lorsqu'un déploiement est remplacé par un autre, le contrôleur de réplication précédent est conservé pour permettre un retour en arrière facile si nécessaire.

Exemple DeploymentConfig définition

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange 1
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  2
  strategy:
    type: Rolling      3

1: Un déclencheur de changement de configuration entraîne la création d'un nouveau contrôleur de réplication lorsque des changements sont détectés dans le modèle de pod de la configuration de déploiement.
2: Un déclencheur de changement d'image entraîne la création d'un nouveau déploiement chaque fois qu'une nouvelle version de l'image de référence est disponible dans le flux d'images nommé.
3: La stratégie par défaut Rolling permet une transition sans temps d'arrêt entre les déploiements.

8.1.3. Déploiements

Kubernetes fournit un type d'objet API natif de première classe dans OpenShift Container Platform appelé Deployment. Les objets Deployment sont des descendants de l'objet DeploymentConfig spécifique à OpenShift Container Platform.

Comme les objets DeploymentConfig, les objets Deployment décrivent l'état souhaité d'un composant particulier d'une application en tant que modèle de pod. Les déploiements créent des ensembles de répliques qui orchestrent les cycles de vie des pods.

Par exemple, la définition de déploiement suivante crée un ensemble de répliques pour mettre en place un pod hello-openshift:

Définition du déploiement

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
    spec:
      containers:
      - name: hello-openshift
        image: openshift/hello-openshift:latest
        ports:
        - containerPort: 80

8.1.4. Comparaison des objets Deployment et DeploymentConfig

Les objets Deployment de Kubernetes et les objets DeploymentConfig fournis par OpenShift Container Platform sont tous deux pris en charge dans OpenShift Container Platform ; cependant, il est recommandé d'utiliser les objets Deployment à moins que vous n'ayez besoin d'une fonctionnalité ou d'un comportement spécifique fourni par les objets DeploymentConfig.

Les sections suivantes décrivent plus en détail les différences entre les deux types d'objets afin de vous aider à choisir le type d'objet à utiliser.

8.1.4.1. Conception

Une différence importante entre les objets Deployment et DeploymentConfig réside dans les propriétés du théorème CAP que chaque conception a choisi pour le processus de déploiement. Les objets DeploymentConfig préfèrent la cohérence, tandis que les objets Deployments privilégient la disponibilité à la cohérence.

Pour les objets DeploymentConfig, si un nœud exécutant un pod de déploiement tombe en panne, il n'est pas remplacé. Le processus attend que le nœud revienne en ligne ou qu'il soit supprimé manuellement. La suppression manuelle du nœud supprime également le module correspondant. Cela signifie que vous ne pouvez pas supprimer le pod pour décoller le rollout, car le kubelet est responsable de la suppression du pod associé.

Cependant, les déploiements sont pilotés par un gestionnaire de contrôleur. Le gestionnaire de contrôleur fonctionne en mode haute disponibilité sur les maîtres et utilise des algorithmes d'élection de leader pour privilégier la disponibilité par rapport à la cohérence. Lors d'une panne, il est possible que d'autres maîtres agissent en même temps sur le même déploiement, mais ce problème sera résolu peu de temps après la panne.

8.1.4.2. Fonctionnalités spécifiques à l'objet DeploymentConfig

Recouvrements automatiques

Actuellement, les déploiements ne permettent pas de revenir automatiquement au dernier jeu de répliques déployé avec succès en cas d'échec.

Déclencheurs

Les déploiements ont un déclencheur implicite de changement de configuration en ce sens que chaque changement dans le modèle de pod d'un déploiement déclenche automatiquement un nouveau déploiement. Si vous ne souhaitez pas de nouveaux déploiements en cas de modification du modèle de pod, mettez le déploiement en pause :

oc rollout pause deployments/<name>

Crochets du cycle de vie

Les déploiements ne prennent pas encore en charge les crochets de cycle de vie.

Stratégies personnalisées

Les déploiements ne prennent pas encore en charge les stratégies de déploiement personnalisées spécifiées par l'utilisateur.

8.1.4.3. Fonctionnalités spécifiques au déploiement

Renversement

Le processus de déploiement des objets Deployment est piloté par une boucle de contrôleur, contrairement aux objets DeploymentConfig qui utilisent des pods de déploiement pour chaque nouveau déploiement. Cela signifie que l'objet Deployment peut avoir autant d'ensembles de répliques actives que possible, et que le contrôleur de déploiement finira par réduire tous les anciens ensembles de répliques et par augmenter le plus récent.

DeploymentConfig ne peuvent avoir qu'un seul pod de déploiement en cours d'exécution, sinon plusieurs déployeurs entrent en conflit en essayant de mettre à l'échelle ce qu'ils pensent être le contrôleur de réplication le plus récent. De ce fait, seuls deux contrôleurs de réplication peuvent être actifs à un moment donné. En fin de compte, cela se traduit par des déploiements plus rapides pour les objets Deployment.

Mise à l'échelle proportionnelle

Le contrôleur de déploiement étant la seule source de vérité concernant la taille des nouveaux et des anciens ensembles de répliques appartenant à un objet Deployment, il est en mesure d'adapter les déploiements en cours. Les répliques supplémentaires sont distribuées proportionnellement à la taille de chaque ensemble de répliques.

DeploymentConfig ne peuvent pas être mis à l'échelle lorsqu'un déploiement est en cours, car le contrôleur finira par avoir des problèmes avec le processus de déploiement concernant la taille du nouveau contrôleur de réplication.

Pause à mi-parcours

Les déploiements peuvent être mis en pause à tout moment, ce qui signifie que vous pouvez également mettre en pause les déploiements en cours. En revanche, il n'est pas possible de mettre en pause les pods de déploiement actuellement, donc si vous essayez de mettre en pause un déploiement au milieu d'un déploiement, le processus de déploiement ne sera pas affecté et continuera jusqu'à ce qu'il se termine.