Application d'itinéraire et HTTP trafic avec Application Load Balancers - Amazon EKS
(Facultatif) Déployer un exemple d'application

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tous.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Application d'itinéraire et HTTP trafic avec Application Load Balancers

Lorsque vous créez un Kubernetes ingress, un AWS Application Load Balancer (ALB) est configuré 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 des équilibreurs de charge d'application et Ingress dans Kubernetes . ALBspeut être utilisé avec Pods qui sont déployés sur des nœuds ou vers AWS Fargate. Vous pouvez déployer un ALB vers des sous-réseaux publics ou privés.

Le trafic des applications est équilibré au niveau L7 du OSI modèle. Pour équilibrer la charge du trafic réseau àL4, vous déployez un Kubernetes servicedu LoadBalancer type. Ce type fournit un AWS Network Load Balancer. Pour de plus amples informations, veuillez consulter Acheminement TCP and UDP trafic avec 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 Commencez avec Amazon EKS. Si vous devez mettre à jour la version d'un cluster existant, consultez Mettre à jour le cluster existant vers la nouvelle version de Kubernetes.

  • Ayez le AWS Load Balancer Controller déployé sur votre cluster. Pour de plus amples informations, veuillez consulter Acheminez le trafic Internet avec le 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 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 AWS Load Balancer Controller version 2.1.1 ou antérieure, les sous-réseaux doivent être balisés dans le format suivant. 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 avez plusieurs clusters qui s'exécutent dans le même environnementVPC, ou vous avez plusieurs AWS services qui partagent des sous-réseaux dans unVPC. 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 : C'est le cas sauf si vous spécifiez explicitement un sous-réseau IDs sous forme d'annotation sur un service ou un objet d'entrée. Supposons que vous provisionnez des équilibreurs de charge en spécifiant explicitement le sous-réseau IDs sous forme d'annotation sur un service ou un objet d'entrée. Dans cette situation, Kubernetes et le contrôleur d'équilibreur de AWS charge utilisent directement ces sous-réseaux pour créer l'équilibreur de charge et les balises suivantes ne sont pas requises.

    • Sous-réseaux privés : doivent être étiquetés dans le format suivant. C'est pour que Kubernetes et le contrôleur d'équilibreur de AWS charge savent que les sous-réseaux peuvent être utilisés pour les équilibreurs de charge internes. Si vous utilisez eksctl un EKS AWS CloudFormation modèle Amazon pour créer le vôtre VPC après le 26 mars 2020, les sous-réseaux sont étiquetés de manière appropriée lors de leur création. Pour plus d'informations sur les EKS AWS CloudFormation VPC modèles Amazon, consultezCréez un Amazon VPC pour votre EKS cluster Amazon.

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

      • Valeur : 1

    • Sous-réseau publics : doivent être étiquetés dans le format suivant. C'est pour que Kubernetes sait utiliser uniquement les sous-réseaux spécifiés pour les équilibreurs de charge externes. De cette façon, Kubernetes ne choisit pas de sous-réseau public dans chaque zone de disponibilité (lexicographiquement en fonction de son ID de sous-réseau). Si vous utilisez eksctl un EKS AWS CloudFormation modèle Amazon pour créer le vôtre VPC après le 26 mars 2020, les sous-réseaux sont étiquetés de manière appropriée lors de leur création. Pour plus d'informations sur les EKS AWS CloudFormation VPC modèles Amazon, consultezCréez un Amazon VPC pour votre EKS cluster Amazon.

      • Clé : kubernetes.io/role/elb

      • Valeur : 1

    Si les balises de rôle de sous-réseau ne sont pas explicitement ajoutées, le Kubernetes le contrôleur de service examine la table de routage des VPC sous-réseaux 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 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.

Considérations

  • Le AWS Load Balancer Controller crée ALBs et fournit les AWS ressources de support nécessaires chaque fois qu'un Kubernetes Une ressource d'entrée est créée sur le cluster avec l'kubernetes.io/ingress.class: albannotation. La ressource d'entrée configure l'itinéraire HTTP ou le HTTPS trafic ALB vers différents Pods au sein du cluster. Pour vous assurer que vos objets d'entrée utilisent le AWS Load Balancer Controller, ajoutez l'annotation suivante à votre Kubernetes spécification d'entrée. Pour plus d'informations, voir les spécifications d'entrée sur GitHub.

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

    Si vous équilibrez la charge pour IPv6 Pods, ajoutez l'annotation suivante à vos spécifications d'entrée. 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

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

    • Instance — Enregistre les nœuds de votre cluster en tant que cibles pour leALB. Le trafic qui atteint le ALB est acheminé vers NodePort votre service, puis transmis par proxy vers votre 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 Kubernetes le service doit spécifier le type NodePort ou LoadBalancer « » pour utiliser ce mode de trafic.

    • IP — Registres Pods comme cibles pour leALB. Le trafic qui atteint le ALB est directement acheminé vers Pods pour 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 vous ciblez Pods courent sur Fargate.

  • Pour étiqueter une balise ALBs créée par le contrôleur, ajoutez l'annotation suivante au contrôleur : alb.ingress.kubernetes.io/tags Pour obtenir la liste de toutes les annotations disponibles prises en charge par le AWS Load Balancer Controller, voir les annotations d'entrée sur GitHub.

  • La mise à niveau ou la rétrogradation de la version du ALB contrôleur peut entraîner des modifications majeures pour les fonctionnalités qui en dépendent. Pour plus d'informations sur les modifications majeures introduites dans chaque version, consultez les notes de version de la ALB manette sur GitHub.

Pour partager un Application Load Balancer sur plusieurs ressources d'entrée à l'aide de IngressGroups

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

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 soutient avec un singleALB. 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 d'entrée n'appartiennent à aucun groupe d'entrée.

Avertissement

Risque de sécurité potentiel : Spécifiez un groupe d'entrée pour une entrée uniquement lorsque tous les Kubernetes les utilisateurs RBAC autorisés à créer ou à modifier des ressources d'entrée se situent dans la même limite de confiance. Si vous ajoutez l'annotation avec un nom de groupe, autre Kubernetes les utilisateurs peuvent créer ou modifier leurs entrées pour appartenir au même groupe d'entrées. 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 avoir des numéros d'ordre en double dans les ressources d'entrée.

(Facultatif) Déployer un exemple d'application

Prérequis
Pour déployer un exemple d'application

Vous pouvez exécuter l'exemple d'application sur un cluster contenant des EC2 nœuds Amazon, Fargate Pods, 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 example values par vos propres valeurs.

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

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

    1. Si vous déployez sur Pods dans un cluster que vous avez créé avec la IPv6 famille, passez à l'étape suivante.

      • Public

        kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/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.7.2/docs/examples/2048/2048_full.yaml

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

        3. Remplacez internet-facing par internal et enregistrez le fichier.

        4. Appliquez le manifeste à votre cluster.

          kubectl apply -f 2048_full.yaml

    2. Si vous déployez sur Pods dans un cluster que vous avez créé avec la IPv6famille, effectuez les étapes suivantes.

      1. Téléchargez le manifeste.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/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 équilibrez la charge en interne Pods, plutôt que face à Internet Pods, modifiez la ligne qui indique alb.ingress.kubernetes.io/scheme: internet-facing 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 entrée n'a pas été créée avec succès au bout de quelques minutes, exécutez la commande suivante pour afficher AWS Load Balancer Controller journaux. 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

  4. Si vous avez effectué le déploiement sur un sous-réseau public, ouvrez un navigateur et accédez à la sortie ADDRESS URL de commande précédente pour voir l'exemple d'application. Si vous ne voyez rien, actualisez votre navigateur et réessayez. Si vous avez effectué le déploiement sur un sous-réseau privé, vous devrez consulter la page depuis un appareil du vôtreVPC, tel qu'un hôte Bastion. Pour plus d’informations, consultez .Linux Bastion Hosts activé. AWS

    Exemple d'application 2048

  5. 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.7.2/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