Activation des mises à jour automatiques

Lorsque vous activez les mises à jour automatiques, vos équilibreurs de charge d'application sont mis à jour vers la version marquée comme version par défaut. Lorsqu'une version plus récente devient la version par défaut, vos équilibreurs de charge d'application sont automatiquement mis à jour vers cette version.

S'il n'existe qu'un noeud worker dans une zone de votre cluster et que vous définissez la valeur 1 pour le nombre de répliques d'équilibreur de charge d'application, ce pod ALB unique est supprimé et un nouveau pod est créé à chaque fois que des mises à jour sont appliquées. Ce processus peut entraîner des perturbations du trafic, même si vous disposez de nœuds de travail et de répliques ALB dans d'autres zones. Pour éviter toute interruption du trafic, assurez-vous qu'il existe au moins deux nœuds de travail dans chaque zone et que chaque ALB dispose de deux répliques. Notez que lors du processus de mise à jour, seules les nouvelles connexions sont routées vers le deuxième pod d'équilibreur de charge d'application ; les connexions existantes sur le pod d'équilibreur de charge d'application de mise à jour sont arrêtées en toute sécurité. Pour les connexions existantes arrêtées lors de la mise à jour, lancez une nouvelle tentative dans les applications client.

Planification des fenêtres de maintenance des mises à jour automatiques

Vous pouvez contrôler et gérer les mises à jour automatiques de l'ALB en créant une ConfigMap personnalisée qui spécifie l'heure à laquelle vous souhaitez que les mises à jour soient effectuées.

Pour définir une heure pour les mises à jour automatiques, vous devez configurer les clés updateEndTime et updateStartTime dans l' ConfigMap de déploiement. Chaque clé représente une heure affectée dans le format de 24 heures (HH:MM). Notez que cette heure est spécifiée en temps universel coordonné (UTC) et non pas dans votre heure locale.

1. Créez un fichier YAML pour votre mappe de configuration. Spécifiez les champs updateEndTime updateStartTime, et sous forme de paires clé-valeur dans le champ data.

   L'exemple suivant ConfigMap configure la fonction de mise à jour automatique pour mettre à jour les pods ALB de votre cluster entre 20 h 34 et 23 h 59 UTC.

   apiVersion: v1
   kind: ConfigMap
   metadata:
       name: ibm-ingress-deploy-config
       namespace: kube-system
   data:
       "updateStartTime": "20:34"
       "updateEndTime": "23:59"
   

2. Déployez la mappe de configuration dans votre cluster. Les nouvelles règles s'appliquent lors de la prochaine mise à jour.

   kubectl apply -f <filename>.yaml
   

Désactivation des mises à jour automatiques

Pour recevoir des correctifs de bogue et des mises à jour de sécurité, conservez les mises à jour automatiques activées. Lorsque les mises à jour automatiques sont désactivées, vous êtes responsable de la mise à jour manuelle de vos équilibreurs de charge d'application.

Vous pouvez désactiver les mises à jour automatiques de vos équilibreurs de charge d'application en exécutant ibmcloud ks ingress alb autoupdate disable -c CLUSTER_NAME_OR_ID.

Pour vérifier si les mises à jour automatiques sont activées pour votre cluster, utilisez la commande ibmcloud ks ingress alb autoupdate get -c CLUSTER_NAME_OR_ID. Si vous décidez de réactiver les mises à jour automatiques, vous pouvez exécuter ibmcloud ks ingress alb autoupdate enable -c CLUSTER_NAME_OR_ID.

Application de mises à jour manuelles

Vous pouvez appliquer manuellement une mise à jour unique de vos pods d'équilibreur de charge d'application Ingress à l'aide de la commande ibmcloud ks ingress alb update. Cette commande applique la version d'image ALB par défaut, mais vous pouvez appliquer une version différente en incluant l'option --version. Pour plus d'informations ou pour connaître les options de commande, voir Référence de l'interface de ligne de commande.

Pour mettre à jour votre image d'équilibreur de charge d'application vers une version spécifique avec l'option --version, vous devez désactiver les mises à jour automatiques de l'équilibreur de charge d'application, puis les désactiver tant que vous souhaitez exécuter la version spécifiée. Les mises à jour automatiques appliquent toujours la version par défaut et remplacent toutes les mises à jour manuelles que vous appliquez. Si vous souhaitez utiliser une version différente, vous ne pouvez pas activer les mises à jour automatiques.

• Pour afficher la liste des versions disponibles d'ALB, exécutez la commande suivante.

  ibmcloud ks ingress alb versions --region REGION
  

• Pour mettre à jour tous les pods d'équilibreur de charge d'application du cluster, exécutez la commande suivante.

  ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID --version IMAGE_VERSION
  

• Pour mettre à jour l'équilibreur de charge d'application pour des équilibreurs de charge d'application spécifiques, exécutez la commande suivante.

  ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID --version IMAGE_VERSION --alb ALB_ID [--alb ALB_2_ID ...]
  

Affichage des versions d'image prises en charge

Pour répertorier les trois dernières versions prises en charge pour chaque type d'image, exécutez la commande suivante.

ibmcloud ks ingress alb versions

Exemple de sortie

Kubernetes Ingress versions
1.1.2_2507_iks (default)
1.2.1_2506_iks
0.35.0_1374_iks

La version de Kubernetes Ingress a le format <community_version>_<ibm_build>_iks. Le numéro de version IBM indique la compilation la plus récente de l'édition Kubernetes Ingress NGINX publiée par IBM Cloud Kubernetes Service. Par exemple, la version 1.1.2_2507_iks indique la génération la plus récente de la version 0.47.0 Ingress NGINX. IBM Cloud Kubernetes Service peut publier des générations d'édition de version de l'image communautaire pour traiter les vulnérabilités.

Pour connaître les modifications apportées à chaque version des images Ingress, consultez le journal des modifications de version d'Ingress.

Retour à une version antérieure

Si vos pods ALB ont été récemment mis à jour, mais qu'une configuration personnalisée de vos ALB est affectée par la dernière version de l'image, vous pouvez utiliser la commande ibmcloud ks ingress alb update avec l'option --version pour revenir à une version antérieure prise en charge des pods ALB. La nouvelle version d'image que vous associez à votre équilibreur de charge d'application doit être une version d'image prise en charge répertoriée dans la sortie de la commande ibmcloud ks ingress alb versions.

Notez que si vous revenez à une version antérieure, vous devez désactiver les mises à jour automatiques de l'équilibreur de charge d'application, puis les désactiver tant que vous voulez exécuter la version antérieure. Les mises à jour automatiques appliquent toujours la dernière version et remplacent toutes les mises à jour manuelles que vous appliquez. Si vous souhaitez utiliser une version antérieure, vous ne pouvez pas activer les mises à jour automatiques.

Création d'autres équilibreurs de charge d'application dans une zone

Chaque équilibreur de charge d'application d'une zone est déployé en tant que deux pods sur des noeuds worker différents. Pour augmenter vos capacités de traitement d'équilibreur de charge d'application et gérer davantage de connexions, vous pouvez créer des équilibreurs de charge d'application supplémentaires dans une zone. L'adresse IP du nouvel équilibreur de charge d'application est automatiquement ajoutée à votre sous-domaine Ingress.

Lorsque vous créez un cluster multizone, un équilibreur de charge d'application public par défaut est créé dans chaque zone dans laquelle se trouvent des noeuds worker. Si vous supprimez ultérieurement l'une de ces trois zones d'origine et ajoutez des workers dans une autre zone, aucun ALB public par défaut n'est créé dans cette nouvelle zone. Vous pouvez créer manuellement un équilibreur de charge d'application pour traiter les connexions dans cette nouvelle zone.

Lors de l'utilisation de la validation de ressource Ingress, chaque demande de création et de mise à jour est validée par tous les équilibreurs de charge d'application. Si aucun pod n'est en cours d'exécution pour une instance d'équilibreur de charge d'application particulière, vous risquez de ne pas être en mesure d'appliquer des ressources Ingress sur votre cluster. Assurez-vous d'avoir au moins un pod en cours d'exécution pour chaque équilibreur de charge d'application à l'état activé. Pour plus d'informations, voir Référence de personnalisation du déploiement Ingress.

1. Dans chaque zone comprenant des noeuds worker, créez un équilibreur de charge d'application.

   La commande suivante s'applique aux clusters classiques. Pour plus d'informations et pour connaître les options de commande, voir la référence de l'interface de ligne de commande.

   ibmcloud ks ingress alb create --cluster CLUSTER_NAME_OR_ID --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID [--ip IP_ADDRESS] [--version image_version]
   

   La commande suivante s'applique aux clusters de VPC. Pour plus d'informations et pour connaître les options de commande, voir la référence de l'interface de ligne de commande.

   ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME_OR_ID --type PUBLIC_OR_PRIVATE --zone VPC_ZONE [--version image_version]
   

2. Vérifiez que les équilibreurs de charge d'application que vous avez créés dans chaque zone ont un statut de enabled. Pour les clusters classiques, vérifiez qu'une adresse IP d'équilibreur de charge d'application est affectée. Pour les clusters de VPC, vérifiez que le nom d'hôte de l'équilibreur de charge est affecté.

   ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID
   

   Exemple de résultat pour un cluster classique.

   ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -               dal12   ingress:1.1.2_2507_iks   2294021       -
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    169.48.228.78   dal12   ingress:1.1.2_2507_iks   2294019       -
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    169.46.17.6     dal10   ingress:1.1.2_2507_iks   2234945       -
   

   Exemple de résultat pour un cluster VPC.

   ALB ID                                            Enabled   Status     Type      Load Balancer Hostname                 Zone         Build
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -                                      us-south-2   ingress:1.1.2_2507_iks
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -                                      us-south-1   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-2   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-1   ingress:1.1.2_2507_iks
   

Modification du nombre de répliques de pods ALB

Par défaut, chaque équilibreur de charge d'application comporte 2 répliques. Vous pouvez personnaliser vos capacités de traitement d'équilibreur de charge d'application en modifiant manuellement le nombre de pods d'équilibreur de charge d'application ou en activant la mise à l'échelle dynamique et automatique.

Un seul pod d'équilibreur de charge d'application peut traiter un grand nombre de demandes. Si vous rencontrez des délais d'attente, des réponses lentes ou d'autres signes de surcharge, vérifiez l'état de votre application de back end. Assurez-vous que l'équilibreur de charge d'application est le goulot d'étranglement de votre application avant de mettre à l'échelle les pods d'équilibreur de charge d'application, sinon il risque de ne pas fournir les résultats attendus.

Pour les clusters classiques: si la configuration du service d'équilibreur de charge de l'équilibreur de charge d'équilibreur de charge d'équilibreur de charge a la valeur externalTrafficPolicy définie sur Local, ne mettez pas à l'échelle plus de 2 répliques. Les équilibreurs de charge classiques s'exécutent avec une configuration fixe de 2 répliques et peuvent uniquement acheminer le trafic vers les pods d'équilibreur de charge d'application qui se trouvent sur le même noeud que les pods d'équilibreur de charge.

Par défaut, des mises à jour de version Ingress sont régulièrement et automatiquement déployées sur votre équilibreur de charge d'application. S'il n'existe qu'un noeud worker dans une zone de votre cluster et que vous définissez la valeur 1 pour le nombre de répliques d'équilibreur de charge d'application, ce pod ALB unique est supprimé et un nouveau pod est créé à chaque fois que des mises à jour sont appliquées. Ce processus peut entraîner des interruptions de trafic, même si vous disposez de noeuds worker et de répliques ALB dans d'autres zones. Pour empêcher les interruptions de trafic, assurez-vous qu'au moins deux noeuds worker existent dans chaque zone et que deux répliques existent pour chaque équilibreur de charge d'application. Notez que lors du processus de mise à jour, seules les nouvelles connexions sont routées vers le deuxième pod d'équilibreur de charge d'application ; les connexions existantes sur le pod d'équilibreur de charge d'application de mise à jour sont arrêtées en toute sécurité. Il est recommandé que les applications client lancent une nouvelle tentative pour les connexions existantes qui sont arrêtées lors de la mise à jour.

Modifiez manuellement le nombre de répliques d'équilibreur de charge d'application en créant un objet ConfigMap. Notez que vous ne pouvez pas mettre à l'échelle manuellement vos répliques d'équilibreur de charge d'application si vous avez configuré votre équilibreur de charge d'application pour utiliser la mise à l'échelle dynamique.

1. Obtenez les ID de vos équilibreurs de charge d'application.

   ibmcloud ks ingress alb ls -c CLUSTER_NAME_OR_ID
   

2. Créez un fichier YAML pour une mappe de configuration ibm-ingress-deploy-config. Pour chaque ALB, ajoutez '{"replicas":<number_of_replicas>}'. Cet exemple augmente le nombre de pods d'équilibreur de charge d'application à 4 répliques.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-ingress-deploy-config
     namespace: kube-system
   data:
     <alb1-id>: '{"replicas":4}'
     <alb2-id>: '{"replicas":4}'
     ...
   

3. Créez la mappe de configuration ibm-ingress-deploy-config dans votre cluster.

   kubectl create -f ibm-ingress-deploy-config.yaml
   

4. Pour appliquer ces modifications, mettez à jour vos ALB. Veuillez noter que l'application des modifications peut prendre jusqu'à 5 minutes.

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. Vérifiez que le nombre de pods ALB a bien été augmenté Ready pour correspondre au nombre de répliques que vous avez spécifié.

   kubectl get pods -n kube-system | grep alb
   

Exemples de commandes de configuration de la mise à l'échelle automatique d'équilibreur de charge d'application dynamique

Exemple de commande de mise à l'échelle dynamique basée sur une utilisation moyenne de l'UC de 60%.

ibmcloud ks ingress alb autoscale set -c CLUSTER_NAME_OR_ID --alb ALB_ID --min-replicas 2 --max-replicas 5 --cpu-average-utilization 60

Exemple de commande de mise à l'échelle dynamique basée sur des métriques personnalisées stockées dans un fichier nommé my-custom-metrics.yaml.

ibmcloud ks ingress alb autoscale set -c CLUSTER_NAME_OR_ID --alb ALB_ID --min-replicas 2 --max-replicas 5 --custom-metrics-file my-custom-metrics.yaml

Calcul de l'utilisation moyenne de l'UC

L'image suivante illustre un exemple de scénario permettant de déterminer l'utilisation de l'unité centrale lors de la planification de votre configuration de mise à l'échelle automatique.

Supposons que vous disposez d'un cluster inactif avec deux répliques d'équilibreur de charge d'application en cours d'exécution qui n'ont pas de trafic entrant. Dans ce cas, la demande d'UC totale est 2*20m=40m. L'une des répliques peut utiliser l'unité centrale 5m et l'autre l'unité centrale 7m. Nous pouvons calculer l'utilisation de l'unité centrale à l'aide de la formule suivante.

Désactivation de la mise à l'échelle automatique ALB

Exécutez la commande pour désactiver la mise à l'échelle automatique pour un équilibreur de charge d'application.

ibmcloud ks ingress alb autoscale unset --alb ALB --cluster CLUSTER