Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer - Amazon EKS
PrérequisRéutilisation des ALB avec des groupes Ingress(Facultatif) Déployer un exemple d'application

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer

Note

Nouveau : le mode automatique Amazon EKS automatise les tâches courantes liées à l’équilibrage de charge. Pour plus d’informations, consultez :

Lorsque vous créez un Kubernetes ingress, un AWS Application Load Balancer (ALB) est mis en service pour équilibrer la charge du trafic des applications. Pour en savoir plus, consultez Qu'est-ce qu'un Application Load Balancer ? dans le Guide de l'utilisateur Application Load Balancers et Ingress dans la documentation Kubernetes. Les ALB peuvent être utilisés avec des pods qui sont déployés sur des nœuds ou sur AWS Fargate. Vous pouvez déployer un ALB sur des sous-réseaux publics ou privés.

Le trafic des applications est équilibré au L7 du modèle OSI. Pour équilibrer la charge du trafic réseau au L4, déployez un service Kubernetes de type LoadBalancer. Ce type fournit un AWS Network Load Balancer. Pour de plus amples informations, consultez Acheminer le trafic TCP et UDP avec des Network Load Balancers. Pour en savoir plus sur les différences entre les deux types d'équilibreurs de charge, consultez Caractéristiques Elastic Load Balancing sur le site AWS.

Prérequis

Pour pouvoir équilibrer la charge du trafic d'une application, vous devez remplir les conditions suivantes.

  • Disposer d'un cluster. Si vous n’avez pas de cluster, consultez Mise en route avec Amazon EKS. Si vous devez mettre à jour la version d'un cluster existant, consultez Mettre à jour un cluster existant vers une nouvelle version de Kubernetes.

  • Le contrôleur AWS Load Balancer Controller doit être déployé sur votre cluster. Pour de plus amples informations, consultez Routage du trafic Internet avec l’AWS Load Balancer Controller. Nous recommandons la version 2.7.2 ou ultérieure.

  • Au moins deux sous-réseaux dans des zones de disponibilité différentes. Le contrôleur d’équilibreur de charge AWS Load Balancer Controller choisit un sous-réseau dans chaque zone de disponibilité. Lorsque plusieurs sous-réseaux étiquetés sont trouvés dans une zone de disponibilité, le contrôleur choisit le sous-réseau dont l'ID vient en premier par ordre lexicographique. Chaque sous-réseau doit disposer au moins huit adresses IP disponibles.

    Si vous utilisez plusieurs groupes de sécurité attachés au composant master, un seul groupe de sécurité doit être étiqueté comme suit. Remplacez my-cluster par le nom de votre cluster.

    • Clé : kubernetes.io/cluster/<my-cluster>

    • Valeur : shared ou owned

  • Si vous utilisez le contrôleur d’équilibreur de charge AWS Load Balancer Controller en version 2.1.1 ou une version antérieure, les sous-réseaux doivent être étiquetés comme suit. Si vous utilisez la version 2.1.2 ou une version ultérieure, l’étiquetage est facultatif. Cependant, nous vous recommandons d'étiqueter un sous-réseau dans les cas suivants. Vous disposez de plusieurs clusters qui fonctionnent dans le même VPC, ou de plusieurs services AWS qui partagent des sous-réseaux dans un VPC. Sinon, vous souhaitez avoir plus de contrôle sur l'endroit où les équilibreurs de charge sont alloués pour chaque cluster. Remplacez my-cluster par le nom de votre cluster.

    • Clé : kubernetes.io/cluster/<my-cluster>

    • Valeur : shared ou owned

  • Vos sous-réseaux publics et privés doivent répondre aux critères suivants : Ceci s'applique si vous ne spécifiez pas explicitement les ID de sous-réseau en tant qu'annotation sur un objet service ou d'entrée. Supposons que vous allouiez des équilibreurs de charge en spécifiant explicitement les ID de sous-réseau en tant qu'annotation sur un objet service ou d'entrée. Dans ce cas, Kubernetes et le contrôleur d’équilibreur de charge AWS Load Balancer Controller utilisent directement ces sous-réseaux pour créer l’équilibreur de charge, et les étiquettes suivantes ne sont pas requises.

    • Sous-réseaux privés : doivent être étiquetés dans le format suivant. Ainsi, Kubernetes et l'AWS Load Balancer Controller savent que les sous-réseaux peuvent être utilisés pour les équilibreurs de charge internes. Si vous utilisez eksctl ou un modèle Amazon EKS AWS CloudFormation pour créer votre VPC après le 26 mars 2020, les sous-réseaux sont automatiquement étiquetés lors de leur création. Pour plus d’informations sur les modèles VPC AWS CloudFormation Amazon EKS, consultez Création d’un VPC Amazon pour votre cluster Amazon EKS.

      • Clé : kubernetes.io/role/internal-elb

      • Valeur : 1

    • Sous-réseau publics : doivent être étiquetés dans le format suivant. Ainsi, Kubernetes sait qu'il doit utiliser uniquement les sous-réseaux qui ont été spécifiés pour les équilibreurs de charge externes. Cela empêche Kubernetes de sélectionner un sous-réseau public dans chaque zone de disponibilité (en se basant sur l’ordre lexicographique des ID de sous-réseau). Si vous utilisez eksctl ou un modèle Amazon EKS AWS CloudFormation pour créer votre VPC après le 26 mars 2020, les sous-réseaux sont automatiquement étiquetés lors de leur création. Pour plus d’informations sur les modèles VPC AWS CloudFormation Amazon EKS, consultez Création d’un VPC Amazon pour votre cluster Amazon EKS.

      • Clé : kubernetes.io/role/elb

      • Valeur : 1

    Si les étiquettes de rôle des sous-réseaux ne sont pas ajoutées explicitement, le contrôleur de service Kubernetes examine la table de routage des sous-réseaux VPC de votre cluster. Cela permet de déterminer si le sous-réseau est privé ou public. Nous vous recommandons de ne pas vous fier à ce comportement. Ajoutez plutôt explicitement les identifications de rôle privées ou publiques. Le contrôleur d’équilibreur de charge AWS Load Balancer Controller n’examine pas les tables de routage. Il est également nécessaire que les identifications privées et publiques soient présentes pour que la découverte automatique fonctionne.

  • L'AWS Load Balancer Controller crée des ALB et les ressources de support AWS nécessaires chaque fois qu'une ressource d'entrée Kubernetes est créée dans le cluster avec l'annotation kubernetes.io/ingress.class: alb. La ressource Ingress configure l’ALB pour acheminer le trafic HTTP ou HTTPS vers différents pods du cluster. Pour que vos objets d'entrée utilisent l'AWS Load Balancer Controller, ajoutez l'annotation suivante à votre spécification d'entrée Kubernetes. Pour plus d'informations, consultez Spécification Ingress sur GitHub.

    annotations:
    kubernetes.io/ingress.class: alb
    Note

    Si vous effectuez un équilibrage de charge vers des pods IPv6, ajoutez l’annotation suivante à votre spécification Ingress. Vous ne pouvez effectuer un équilibrage de charge sur IPv6 que vers des cibles IP, pas vers des cibles d'instance. Sans cette annotation, l'équilibrage de charge passe par IPv4.

    alb.ingress.kubernetes.io/ip-address-type: dualstack

  • L'AWS Load Balancer Controller prend en charge les modes de trafic suivants :

    • Instance : enregistre les nœuds de votre cluster comme cibles de l'ALB. Le trafic atteignant l’ALB est acheminé vers le NodePort de votre service, puis transmis par proxy à vos pods. Il s'agit du mode de trafic par défaut. Vous pouvez également le spécifier explicitement avec l'annotation alb.ingress.kubernetes.io/target-type: instance.

      Note

      Votre service Kubernetes doit spécifier le type NodePort ou LoadBalancer pour utiliser ce mode de trafic.

    • IP : enregistre les pods comme cibles pour l'ALB. Le trafic atteignant l’ALB est directement acheminé vers des pods de votre service. Vous devez spécifier l'annotation alb.ingress.kubernetes.io/target-type: ip pour pouvoir utiliser ce mode de trafic. Le type de cible IP est requis lorsque les pods cibles s’exécutent sur Fargate ou sur des nœuds hybrides Amazon EKS.

  • Pour identifier les ALB créés par le contrôleur, ajoutez l'annotation suivante au contrôleur : alb.ingress.kubernetes.io/tags. Pour obtenir la liste des annotations disponibles prises en charge par l'AWS Load Balancer Controller, consultez Annotations Ingress sur GitHub.

  • La mise à niveau ou la rétrogradation de la version du contrôleur ALB peut introduire des changements de rupture pour les fonctionnalités qui en dépendent. Pour plus d'informations sur les changements importants introduits dans chaque version, consultez les notes de mise à jour du contrôleur ALB sur GitHub.

Réutilisation des ALB avec des groupes Ingress

Vous pouvez partager un équilibreur de charge Application Load Balancer sur plusieurs ressources d’entrée à l’aide des IngressGroups.

Pour joindre une ressource d'entrée à un groupe, ajoutez l'annotation suivante à une spécification de ressource d'entrée Kubernetes.

alb.ingress.kubernetes.io/group.name: my-group

Le nom du groupe doit :

  • Contenir 63 caractères maximum.

  • Contenir des minuscules, des chiffres, des - et des ..

  • Commencer et se terminer par un chiffre ou une lettre.

Le contrôleur fusionne automatiquement les règles d'entrée pour toutes les entrées du même groupe d'entrées. Il les prend en charge avec un seul ALB. La plupart des annotations qui sont définies sur une ressource d'entrée ne s'appliquent qu'aux chemins définis par cette ressource. Par défaut, les ressources Ingress n’appartiennent à aucun groupe d’entrée.

Avertissement

Risque potentiel pour la sécurité

Ne spécifiez un groupe d’entrée pour une ressource d’entrée que lorsque tous les utilisateurs Kubernetes qui ont l’autorisation RBAC de créer ou de modifier des ressources Ingress se trouvent dans la même limite d’approbation. Si vous ajoutez l'annotation avec un nom de groupe, d'autres utilisateurs Kubernetes peuvent créer ou modifier leurs ressources d'entrée pour appartenir au même groupe d'entrée. Cela peut entraîner un comportement indésirable, comme l'écrasement des règles existantes par des règles de priorité supérieure.

Vous pouvez ajouter le numéro d'ordre de votre ressource d'entrée.

alb.ingress.kubernetes.io/group.order: '10'

Le numéro peut être 1-1000. Le numéro le plus bas de toutes les ressources d'entrée d'un même groupe d'entrée est évalué en premier. Toutes les ressources d'entrée sans cette annotation sont évaluées avec la valeur zéro. Les règles dupliquées avec un numéro supérieur peuvent écraser les règles avec un numéro inférieur. Par défaut, l'ordre des règles entre les ressources d'entrée d'un même groupe d'entrée est déterminé de manière lexicographique sur la base de l'espace de noms et du nom.

Important

Assurez-vous que chaque ressource d'un groupe d'entrée dispose d'un numéro de priorité unique. Vous ne pouvez pas utiliser des numéros d’ordre dupliqués dans les ressources Ingress.

(Facultatif) Déployer un exemple d'application

Vous pouvez exécuter l'exemple d'application dans un cluster comportant des nœuds Amazon EC2, des pods Fargate ou les deux.

  1. Si vous ne déployez pas sur Fargate, ignorez cette étape. Si vous déployez sur Fargate, créez un profil Fargate. Vous pouvez créer le profil en exécutant la commande suivante ou dans la AWS Management Console en utilisant les mêmes valeurs pour name et namespace que dans la commande. Remplacez les exemples de valeurs par les vôtres.

    eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name alb-sample-app \
    --namespace game-2048

  2. Déployez le jeu 2048 comme exemple d'application pour vérifier que l'AWS Load Balancer Controller crée un AWS ALB du fait de l'objet d'entrée. Effectuez les étapes correspondant au type de sous-réseau sur lequel vous déployez.

    1. Si vous déployez des Pods dans un cluster créé avec la famille IPv6, passez à l’étape suivante.

      • public::

      kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.13.3/docs/examples/2048/2048_full.yaml

      • privé::

        1. Téléchargez le manifeste.

          curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.13.3/docs/examples/2048/2048_full.yaml

        2. Modifiez le fichier et trouvez la ligne qui contient alb.ingress.kubernetes.io/scheme: internet-facing.

        3. Modifiez la valeur internet-facing en internal et enregistrez le fichier.

        4. Appliquez le manifeste à votre cluster.

          kubectl apply -f 2048_full.yaml

    2. Si vous effectuez un déploiement sur des pods d’un cluster que vous avez créé avec la famille IPv6, effectuez les étapes suivantes.

      1. Téléchargez le manifeste.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.13.3/docs/examples/2048/2048_full.yaml

      2. Ouvrez le fichier dans un éditeur et ajoutez la ligne suivante aux annotations de la spécification d'entrée.

        alb.ingress.kubernetes.io/ip-address-type: dualstack

      3. Si vous effectuez un équilibrage de charge vers des pods internes plutôt que vers des pods accessibles depuis Internet, remplacez la valeur alb.ingress.kubernetes.io/scheme: internet-facing par alb.ingress.kubernetes.io/scheme: internal

      4. Enregistrez le fichier.

      5. Appliquez le manifeste à votre cluster.

        kubectl apply -f 2048_full.yaml

  3. Après quelques minutes, vérifiez que la ressource d'entrée a été créée en utilisant la commande suivante.

    kubectl get ingress/ingress-2048 -n game-2048

    L'exemple qui suit illustre un résultat.

    NAME           CLASS    HOSTS   ADDRESS                                                                   PORTS   AGE
ingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.region-code.elb.amazonaws.com   80      2m32s
    Note

    Si vous avez créé l'équilibreur de charge dans un sous-réseau privé, la valeur sous ADDRESS dans la sortie précédente est préfacée avec internal-.

Si votre ressource Ingress n’a pas été créé avec succès après plusieurs minutes, exécutez la commande suivante pour consulter les journaux du contrôleur d’équilibreur de charge AWS Load Balancer Controller. Ces journaux peuvent contenir des messages d'erreur que vous pouvez utiliser pour diagnostiquer les problèmes de votre déploiement.

kubectl logs -f -n kube-system -l app.kubernetes.io/instance=aws-load-balancer-controller

  1. Si vous l'avez déployé dans un sous-réseau public, ouvrez un navigateur et naviguez vers l'URL ADDRESS de la sortie de commande précédente pour voir l'exemple d'application. Si rien ne s’affiche, actualisez votre navigateur et réessayez. Si vous avez déployé sur un sous-réseau privé, vous devez afficher la page à partir d’un appareil de votre VPC, tel qu’un hôte bastion. Pour plus d'informations, consultez la section Hôtes bastions Linux sur AWS.

    Exemple d'application 2048

  2. Lorsque vous avez terminé de tester l'exemple d'application, supprimez-le avec les commandes suivantes.

    • Si vous avez appliqué le manifeste plutôt que d'appliquer une copie que vous avez téléchargée, utilisez la commande suivante.

      kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.13.3/docs/examples/2048/2048_full.yaml

    • Si vous avez téléchargé et modifié le manifeste, utilisez la commande suivante.

      kubectl delete -f 2048_full.yaml