Gestion du cycle de vie de l'application

Utilisez des outils natifs Kubernetes et des outils tiers pour effectuer des mises à jour et des rétromigrations en continu sans générer de temps d'indisponibilité pour vos utilisateurs.

Gestion des stratégies

Pour mettre à jour votre application, vous pouvez choisir parmi différentes stratégies, telles que celles décrites ci-après. Vous pouvez commencer par un déploiement en continu ou un basculement instantané avant de passer à un déploiement cobaye plus complexe.

Déploiement en continu: Vous pouvez utiliser une fonctionnalité native Kubernetes pour créer un déploiement v2 et pour remplacer progressivement votre précédent déploiement v1. Cette approche nécessite que les applications soient compatibles à l'envers afin que les utilisateurs qui sont servis dans la version de l'application v2 ne subissent pas de modifications de rupture. Pour plus d'informations, voir Gestion des déploiements en continu pour mettre à jour vos applications.
Basculement instantané: Egalement appelé déploiement Blue-Green, un basculement instantané nécessite de doubler les ressources informatiques de sorte que deux versions d'une application s'exécutent en même temps. Avec cette approche, vous pouvez faire passer vos utilisateurs à la version plus récente quasiment en temps réel. Veillez à utiliser des sélecteurs d'étiquettes de service (tels que version: green et version: blue) pour vous assurer que les demandes sont envoyées à la bonne version de l'application. Vous pouvez créer le nouveau déploiement version: green, attendre qu'il soit prêt, puis supprimer le déploiement version: blue. Vous pouvez également effectuer une Mise à jour évolutive, mais définir le paramètre maxUnavailable sur 0% et le paramètre maxSurge sur 100%.
Déploiement A/B ou cobaye: Une stratégie de mise à jour plus complexe, un déploiement cobaye, est lorsque vous choisissez un pourcentage d'utilisateurs, par exemple, 5 % et que vous les envoyez à la nouvelle version d'application. Vous collectez dans vos outils de journalisation et de surveillance des métriques relatives aux performances de la nouvelle version d'application, vous effectuez des tests A/B, puis vous déployez la mise à jour à d'autres utilisateurs. Comme pour tous les déploiements, spécifier un libellé pour l'application (par exemple, version: stable et version: canary) est essentiel. Pour gérer les déploiements de canaris, vous pouvez installer le maillage de services Istio géré, configurer Monitoring pour votre cluster, puis utiliser le maillage de services Istio pour les tests A/B comme décrit dans cet article de blog.

Mise à l'échelle des applications

Avec Kubernetes, vous pouvez activer l'autoscaling horizontal des pods pour augmenter ou diminuer automatiquement le nombre d'instances de vos applications en fonction du CPU.

Vous voulez plutôt mettre à l'échelle vos noeuds worker à la place de vos pods ? Découvrez le programme de mise à l'échelle automatique de cluster (cluster autoscaler).

Avant de commencer

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.
Vérifiez que vous disposez d'un rôle d'accès au service qui vous octroie le rôle RBAC Kubernetes approprié pour travailler avec des ressources Kubernetes dans l'espace de noms.

Pour faire évoluer vos applications :

Déployez votre application sur un cluster à partir de l'interface de ligne de commande. Pour les déploiements plus complexes, vous devrez éventuellement créer un fichier de configuration.
```
kubectl create deployment <app_name> --image=<image>
```
Définissez les limites de ressource d'UC en millicores pour les conteneurs qui s'exécutent dans votre déploiement, par exemple, 100m. Vous pouvez également définir des limites de mémoire, mais le programme de mise à l'échelle automatique de pod horizontale ne prend en compte que les limites de ressources d'UC à des fins de mise à l'échelle. Pour plus d'informations, voir la documentation kubectl set resources
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

Créez un programme de mise à l'échelle automatique de pod horizontale et définissez votre règle. Pour plus d'informations, voir la documentation de kubectl autoscale.

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

Comprendre les options de commande
Options	Description
`--cpu-percent`	Utilisation d'UC moyenne gérée par le programme de mise à l'échelle automatique de pod horizontale, exprimée en pourcentage.
`--min`	Nombre minimal de pods déployés utilisés pour gérer le pourcentage d'utilisation d'UC spécifié.
`--max`	Nombre maximal de pods déployés utilisés pour gérer le pourcentage d'utilisation d'UC spécifié.

Gestion des déploiements en continu pour mettre à jour vos applications

Vous pouvez gérer le déploiement en continu de votre application de façon automatique et contrôlée pour les charges de travail avec un modèle de pod te type déploiements, par exemple. S'il ne correspond pas à ce que vous aviez prévu, vous pouvez rétromigrer le déploiement vers la dernière révision.

Vous voulez éviter toute indisponibilité lors de la mise à jour en continu ? Veillez à spécifier une sonde Readiness Probe dans votre déploiement pour que le déploiement passe au pod d'application suivant une fois que le pod qui vient d'être mis à jour est prêt.

Avant de commencer

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.
Créez un déploiement.
Vérifiez que vous disposez d'un rôle d'accès au service qui vous octroie le rôle RBAC Kubernetes approprié pour travailler avec des ressources Kubernetes dans l'espace de noms.

Pour gérer les mises à jour en continu de vos applications :

Pour être certain que vos déploiements sont marqués comme étant accessibles en lecture seule lorsque le conteneur est en cours d'exécution et prêt à traiter des demandes, ajoutez des sondes Liveness et Readiness à votre déploiement.
Mettez à jour votre déploiement de manière à y inclure une stratégie de mise à jour en continu dans laquelle sont spécifiés le nombre maximal de pods non disponibles ou en surcharge ou le pourcentage de pods durant la mise à jour.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

Par défaut, les déploiements attendent que le pod soit marqué ready pour poursuivre. Si vous constatez que le déploiement continue de créer des pods alors même que votre application située dans le pod le plus récent n'est pas encore prête, utilisez cette zone pour ralentir le déploiement. Par exemple, si vous spécifiez 5, le déploiement attend pendant 5 secondes une fois que le pod est ready avant de créer le pod suivant.

spec.progressDeadlineSeconds

Définissez un délai d'attente (en secondes) à observer avant de considérer qu'un déploiement a échoué. Par exemple, sans délai d'attente, si votre nouvelle version d'application a un bogue et se bloque immédiatement, le déploiement ne peut pas se poursuivre car le pod n'atteint jamais un état ready. Si vous définissez un délai d'attente de 600 secondes et si une phase du déploiement ne progresse plus pendant 10 minutes, le déploiement est marqué comme ayant échoué et s'arrête.

spec.strategy.type

Spécifiez le type de stratégie RollingUpdate.

spec.strategy.rollingUpdate.maxUnavailable

Définissez le nombre maximal de pods qui peuvent être non disponibles durant une mise à jour ; il peut s'agir d'un nombre (2) ou d'un pourcentage (50%). IL est recommandé d'utiliser un pourcentage. Ainsi, si vous modifiez le nombre de répliques ultérieurement, vous n'aurez pas à penser à mettre à jour le nombre ici, sauf si vous souhaitez limiter le déploiement afin d'autoriser l'arrêt d'un seul pod à la fois. Si vous ne voulez jamais descendre en dessous de 100 % de capacité, réglez cette valeur sur 0% et spécifiez le paramètre spec.strategy.type.rollingUpdate.maxSurge

spec.strategy.rollingUpdate.maxSurge

Définissez le nombre de ressources supplémentaires pouvant être utilisées par le déploiement. Il peut s'agir d'un nombre (2) ou d'un pourcentage (50%). Par exemple, si votre déploiement spécifie 10 répliques et que vous affectez au paramètre maxSurge la valeur 2, durant le déploiement, deux nouvelles répliques sont créées. Vous disposez à présent de 12 répliques (10 répliques existantes et 2 nouvelles répliques). Lorsque les deux nouvelles répliques sont prêtes, le déploiement réduit le nombre d'anciennes répliques à 8 afin d'être conforme aux 10 répliques spécifiées. Ce processus se poursuit jusqu'à ce que le déploiement soit terminé et que les 10 répliques exécutent la nouvelle version.

Si vous souhaitez effectuer une mise à jour instantanée de style de commutateur bleu-vert, définissez maxSurge sur 100%. Le déploiement crée toutes les nouvelles répliques requises, puis réduit les anciennes répliques à 0.
Déployez une modification. Par exemple, vous souhaiterez peut-être modifier l'image que vous avez utilisée dans votre déploiement initial.
1. Identifiez le nom du déploiement.
```
kubectl get deployments
```
2. Identifiez le nom du pod.
```
kubectl get pods
```
3. Identifiez le nom du conteneur qui s'exécute dans le pod.
```
kubectl describe pod <pod_name>
```
4. Définissez la nouvelle image à utiliser par le déploiement.
```
kubectl set image deployment/<deployment_name><container_name>=<image_name>
```
Lorsque vous exécutez les commandes, la modification est immédiatement appliquée et consignée dans l'historique de déploiement.
Vérifiez le statut de votre déploiement.
```
kubectl rollout status deployments/<deployment_name>
```
Si vous constatez qu'il se passe quelque chose au niveau du statut et souhaitez prendre le temps d'effectuer des vérifications, vous pouvez simplement interrompre et reprendre votre déploiement à l'aide des commandes suivantes :
```
kubectl rollout pause deployment <deployment_name>
```
```
kubectl rollout resume deployment <deployment_name>
```
Rétromigrez une modification.
1. Affichez l'historique des modifications en continu du déploiement et identifiez le numéro de révision de votre dernier déploiement.
```
kubectl rollout history deployment/<deployment_name>
```
  Astuce : pour afficher les détails d'une révision spécifique, incluez le numéro de la révision.
```
kubectl rollout history deployment/<deployment_name> --revision=<number>
```
2. Rétablissez la version précédente ou spécifiez la révision à rétablir. Pour rétromigrer vers la révision précédente, utilisez la commande suivante.
```
kubectl rollout undo deployment/<depoyment_name> --to-revision=<number>
```

Configuration de l'intégration et de la distribution continues

Avec IBM Cloud et d'autres outils open, vous pouvez configurer l'intégration et la distribution continues (CI/CD), le contrôle des versions, les chaînes d'outils, etc. afin de faciliter l'automatisation du développement et du déploiement d'application.

Pour obtenir une liste des intégrations prises en charge et des étapes permettant de configurer un pipeline de distribution continue, voir Configuration de l'intégration et de la distribution continues.

Copie de déploiements sur un autre cluster

Lorsque vous utilisez un système de contrôle de version tel que Git, des projets de gestion de configuration tels que kustomize, ou des outils de livraison continue tels que Razee dans votre cluster, vous pouvez déployer vos fichiers de configuration d'application rapidement d'un cluster à l'autre. Parfois, vous ne disposez que de quelques déploiements que vous avez testés dans un cluster et préférez copier ces déploiements et les redéployer dans un autre cluster.

Avant de commencer, vous avez besoin de deux clusters et du rôle d'accès au service Manager pour tous les espaces de noms dans les deux clusters afin de pouvoir copier toutes les ressources d'un cluster et les déployer dans l'autre.

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Répertoriez tous les fichiers de configuration de votre cluster et vérifiez que vous souhaitez copier ces configurations.

kubectl get all

Exemple de sortie

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d

NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

Copiez les fichiers de configuration de votre cluster dans un répertoire local. L'option --export supprime les informations spécifiques aux clusters dans les fichiers de configuration.
```
kubectl get all -o yaml --export > myconfigs.yaml
```
Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.
Facultatif : si votre cluster utilise plusieurs espaces de noms, créez les mêmes espaces de noms dans le cluster standard et copiez le secret d'extraction de l'image dans chaque espace de noms.
Déployez les fichiers de configuration copiés sur votre cluster. Si un fichier de configuration contient des informations spécifiques qui ne peuvent pas être appliquées, vous devrez peut-être mettre à jour le fichier de configuration et appliquer une nouvelle application.
```
kubectl apply -f myconfigs.yaml
```
Exemple de sortie
```
pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created
```
Vérifiez que vos fichiers de configuration sont appliqués.
```
kubectl get all
```