6.2. Comprendre les déploiements

A ReplicaSet est un objet API Kubernetes natif qui garantit qu’un nombre spécifié de répliques de pod s’exécute à un moment donné.

Ce qui suit est un exemple de définition de ReplicaSet:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: 
    matchLabels: 
      tier: frontend
    matchExpressions: 
      - {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

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: 

    matchLabels: 

      tier: frontend
    matchExpressions: 

      - {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

À l’instar d’un ensemble de répliques, un contrôleur de réplication s’assure qu’un nombre spécifié de répliques d’un pod s’exécute à tout moment. Lorsque les pods sortent ou sont supprimés, le contrôleur de réplication instancie davantage jusqu’au nombre défini. De même, s’il y a plus de fonctionnement que souhaité, il supprime autant que nécessaire pour correspondre au montant défini. 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 des ensembles alors qu’un contrôleur de réplication ne prend en charge que les exigences de sélecteur basées sur l’égalité.

La configuration du contrôleur de réplication consiste en:

Le sélecteur est un ensemble d’étiquettes attribuées aux pods qui sont gérées par le contrôleur de réplication. Ces étiquettes sont incluses dans la définition de Pod que le contrôleur de réplication instantanée. Le contrôleur de réplication utilise le sélecteur pour déterminer combien d’instances de la gousse sont déjà en cours d’exécution afin de s’ajuster au besoin.

Le contrôleur de réplication n’effectue pas de mise à l’échelle automatique basée sur la charge ou le trafic, car il ne suit pas non plus. Cela nécessite plutôt que son nombre de répliques soit ajusté par un auto-scaleur externe.

Ce qui suit est une définition d’un contrôleur de réplication:

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

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1  

  selector:    

    name: frontend
  template:    

    metadata:
      labels:  

        name: frontend 

    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

Les propriétés du théorème CAP que chaque conception a choisi pour le processus de déploiement constituent une différence importante entre le déploiement et le déploiement des objetsConfig. Les objets DeploymentConfig préfèrent la cohérence, tandis que les objets de déploiement prennent la disponibilité plutôt que la cohérence.

Dans le cas des objets DeploymentConfig, si un nœud exécutant un pod de déploiement diminue, il ne sera pas remplacé. Le processus attend jusqu’à ce que le nœud revienne en ligne ou soit supprimé manuellement. La suppression manuelle du nœud supprime également le pod correspondant. Cela signifie que vous ne pouvez pas supprimer la gousse pour décoller le déploiement, car le kubelet est responsable de la suppression de la gousse associée.

Cependant, les déploiements de déploiement sont conduits 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 leader pour valoriser la disponibilité par rapport à la cohérence. En cas d’échec, il est possible pour d’autres maîtres d’agir sur le même déploiement en même temps, mais ce problème sera réconcilié peu de temps après l’échec.

Le roulement

Le processus de déploiement des objets de déploiement 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 Déploiement peut avoir autant d’ensembles de répliques actives que possible, et finalement le contrôleur de déploiement réduira tous les anciens ensembles de répliques et mettra à l’échelle le plus récent.

Les objets DeploymentConfig peuvent avoir au plus un pod de déploiement en cours d’exécution, sinon plusieurs déployeurs pourraient entrer en conflit lorsqu’ils tentent de développer ce qu’ils pensent être le plus récent contrôleur de réplication. De ce fait, seuls deux contrôleurs de réplication peuvent être actifs à tout moment. En fin de compte, cela entraîne des déploiements rapides plus rapides pour les objets de déploiement.

Échelle proportionnelle

Étant donné que le contrôleur de déploiement est la seule source de vérité pour les tailles de nouveaux et anciens ensembles de répliques appartenant à un objet de déploiement, il peut faire évoluer les déploiements en cours. Des répliques supplémentaires sont distribuées proportionnellement en fonction de la taille de chaque ensemble de répliques.

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

La pause à mi-démarrage

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. Cependant, vous ne pouvez actuellement pas mettre en pause les pods de déploiement; si vous essayez de mettre un terme à un déploiement au milieu d’un déploiement, le processus de déploiement n’est pas affecté et se poursuit jusqu’à ce qu’il soit terminé.

Les retours automatiques

Actuellement, les déploiements ne prennent pas en charge le retour automatique à la dernière réplique déployée avec succès en cas d’échec.

Déclencheurs

Les déploiements ont un déclencheur de modification de configuration implicite en ce sens que chaque changement dans le modèle de pod d’un déploiement déclenche automatiquement un nouveau déploiement. Lorsque vous ne voulez pas de nouveaux déploiements sur les modifications de modèles de pod, arrêtez le déploiement:

oc rollout pause deployments/<name>

$ oc rollout pause deployments/<name>

Crochets de cycle de vie

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

Des stratégies personnalisées

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