Acheminez le trafic TCP et UDP avec des équilibreurs de charge réseau

Note

Nouveau : le mode automatique d'Amazon EKS automatise les tâches de routine pour l'équilibrage de charge. Pour plus d’informations, consultez :

• Déployer un exemple de charge de travail Load Balancer en mode EKS Auto

• Utiliser les annotations de service pour configurer les équilibreurs de charge réseau

Le trafic réseau est équilibré en charge au niveau L4 du modèle OSI. Pour équilibrer la charge du trafic des applications surL7, vous déployez un Kubernetesingress, qui fournit un Application AWS Load Balancer. Pour de plus amples informations, veuillez consulter Acheminez le trafic d'applications et le trafic HTTP avec des équilibreurs de charge d'application. Pour en savoir plus sur les différences entre les deux types d'équilibrage de charge, consultez les fonctionnalités d'Elastic Load Balancing sur le AWS site Web.

Lorsque vous créez un Kubernetes Service de type KubernetesLoadBalancer, le contrôleur d'équilibrage de charge du fournisseur de AWS cloud crée des équilibreurs de charge AWS classiques par défaut, mais peut également créer des équilibreurs de charge réseau. AWS Ce contrôleur ne recevra que des corrections de bugs critiques à l'avenir. Pour plus d'informations sur l'utilisation de l'équilibreur de charge du fournisseur de AWS cloud, consultez le contrôleur d'équilibrage de charge du fournisseur de AWS cloud dans la documentation de Kubernetes. Son utilisation n'est pas abordée dans cette rubrique.

Nous vous recommandons d'utiliser la version 2.7.2 ou une version ultérieure du AWS Load Balancer Controller au lieu du contrôleur d'équilibrage de charge du fournisseur de AWS cloud. Le AWS Load Balancer Controller crée des équilibreurs de charge AWS réseau, mais pas des équilibreurs de charge AWS classiques. Le reste de cette rubrique traite de l'utilisation du AWS Load Balancer Controller.

Un AWS Network Load Balancer peut équilibrer la charge du trafic réseau vers les pods déployés sur Amazon EC2 IP et les cibles d'instance, vers les cibles IP Fargate ou vers AWS les nœuds hybrides Amazon EKS en tant que cibles IP. Pour plus d'informations, consultez AWS Load Balancer Controller activé. GitHub

Prérequis

Avant de pouvoir équilibrer la charge du trafic réseau à l'aide du AWS Load Balancer Controller, vous devez satisfaire aux exigences suivantes.

• Disposer d'un cluster. Si vous n'avez pas de cluster existant, consultezMise en route 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.

• Déployez le AWS Load Balancer Controller 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 un sous-réseau. Si plusieurs sous-réseaux identifiés sont trouvés dans une zone de disponibilité, le contrôleur choisit le sous-réseau dont l'ID vient en premier dans l'ordre lexicographique. Le sous-réseau doit disposer au moins huit adresses IP disponibles.

• Si vous utilisez la version du AWS Load Balancer Controller 2.1.1 ou une version antérieure, les sous-réseaux doivent être balisés comme suit. Si vous utilisez la version 2.1.2 ou une version ultérieure, cette identification est facultative. Vous souhaiterez peut-être baliser un sous-réseau si plusieurs clusters s'exécutent dans le même VPC, ou si AWS plusieurs services partagent des sous-réseaux dans un VPC, et si vous souhaitez mieux contrôler l'endroit où les équilibreurs de charge sont fournis pour chaque cluster. Si vous spécifiez explicitement un sous-réseau IDs sous forme d'annotation sur un objet de service, Kubernetes et le Load Balancer Controller utilisent directement ces sous-réseaux pour créer l'équilibreur de AWS charge. Le balisage des sous-réseaux n'est pas nécessaire si vous choisissez d'utiliser cette méthode pour configurer des équilibreurs de charge et vous pouvez ignorer les exigences de balisage des sous-réseaux privés et publics suivantes. 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 exigences suivantes, sauf si vous le spécifiez explicitement sous IDs forme d'annotation sur un service ou un objet d'entrée. Si vous configurez des équilibreurs de charge en spécifiant explicitement un sous-réseau IDs sous forme d'annotation sur un service ou un objet d'entrée, Kubernetes et le Load AWS Balancer Controller utilisent ces sous-réseaux directement 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. Cela permet à Kubernetes et au Load Balancer Controller de savoir que les sous-réseaux peuvent être utilisés pour les équilibreurs de AWS charge internes. Si vous utilisez eksctl un AWS AWS CloudFormation modèle Amazon EKS pour créer votre VPC après le 26 mars 2020, les sous-réseaux sont balisés de manière appropriée lors de leur création. Pour plus d'informations sur les modèles de VPC Amazon EKS AWS AWS CloudFormation , consultez Créez un Amazon VPC 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. Kubernetes sait ainsi qu'il ne faut utiliser que ces sous-réseaux pour les équilibreurs de charge externes au lieu de choisir un sous-réseau public dans chaque zone de disponibilité (en fonction de l'ordre lexicographique du sous-réseau). IDs Si vous utilisez eksctl un AWS CloudFormation modèle Amazon EKS pour créer votre VPC après le 26 mars 2020, les sous-réseaux sont balisés de manière appropriée lors de leur création. Pour plus d'informations sur les modèles de AWS CloudFormation VPC Amazon EKS, consultez. Créez un Amazon VPC pour votre cluster Amazon EKS

    • Clé : kubernetes.io/role/elb

    • Valeur : 1

  Si les balises de rôle de sous-réseau ne sont pas explicitement ajoutées, le contrôleur de service Kubernetes examine la table de routage des sous-réseaux VPC de votre cluster pour déterminer s'il s'agit d'un sous-réseau privé ou public. Nous vous recommandons de ne pas vous fier à ce comportement et d'ajouter explicitement les balises de rôle privées ou publiques. Le AWS Load Balancer Controller n'examine pas les tables de routage et nécessite la présence des balises privées et publiques pour une détection automatique réussie.

Considérations

• La configuration de votre équilibreur de charge est contrôlée par des annotations qui sont ajoutées au manifeste de votre service. Les annotations de service sont différentes lorsque vous utilisez le AWS Load Balancer Controller et lorsque vous utilisez AWS le contrôleur d'équilibrage de charge du fournisseur de cloud. Assurez-vous de consulter les annotations relatives au AWS Load Balancer Controller avant de déployer des services.

• Lorsque vous utilisez le plug-in Amazon VPC CNI pour Kubernetes, le Load AWS Balancer Controller peut équilibrer la charge entre EC2 Amazon IP ou les cibles d'instance et les cibles IP Fargate. Lorsque vous utilisez des plug-ins CNI compatibles avec Alternate, le contrôleur peut uniquement équilibrer la charge par rapport aux cibles des instances, sauf si vous équilibrez la charge par rapport aux nœuds hybrides Amazon EKS. Pour les nœuds hybrides, le contrôleur peut équilibrer la charge des cibles IP. Pour plus d'informations sur les types de cibles de Network Load Balancer, veuillez consulter la section Type de cible dans le guide de l'utilisateur de Network Load Balancer

• Si vous souhaitez ajouter des balises à l'équilibreur de charge lors de sa création ou après sa création, ajoutez l'annotation suivante dans votre spécification de service. Pour plus d'informations, consultez AWS Resource Tags dans la documentation du AWS Load Balancer Controller.

  service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags

• Vous pouvez affecter des adresses IP Elastic au Network Load Balancer en ajoutant l'annotation suivante. Remplacez les example values par les Allocation IDs de vos adresses IP élastiques. Le nombre de Allocation IDs doit correspondre au nombre de sous-réseaux utilisés pour l'équilibreur de charge. Pour plus d'informations, consultez la documentation du contrôleur AWS Load Balancer Controller.

  service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-xxxxxxxxxxxxxxxxx,eipalloc-yyyyyyyyyyyyyyyyy

• Amazon EKS ajoute une règle entrante au groupe de sécurité du nœud pour le trafic client et une règle pour chaque sous-réseau d'équilibreur de charge du VPC afin de vérifier l'état de chaque Network Load Balancer que vous créez. Le déploiement d'un service de type LoadBalancer peut échouer si Amazon EKS tente de créer des règles qui dépassent le quota du nombre maximal de règles autorisées pour un groupe de sécurité. Pour plus d'informations, consultez Groupes de sécurité dans Quotas de VPC Amazon dans le guide de l'utilisateur d'Amazon VPC. Tenez compte des options suivantes pour réduire les possibilités de dépassement du nombre maximum de règles pour un groupe de sécurité :

  • Demandez une augmentation dans vos règles par quota de groupe de sécurité. Pour plus d'informations, consultez Demande d'une augmentation de quota dans le Guide de l'utilisateur de Service Quotas.

  • Utilisez des cibles IP plutôt que des cibles d'instance. Avec les cibles IP, vous pouvez partager des règles pour les mêmes ports cibles. Vous pouvez spécifier manuellement les sous-réseaux des équilibreurs de charge avec une annotation. Pour plus d'informations, consultez la section Annotations sur GitHub.

  • Utilisez une entrée (ingress), au lieu d'un service de type LoadBalancer, pour envoyer le trafic vers votre service. L' AWS Application Load Balancer nécessite moins de règles que les Network Load Balancer. Vous pouvez partager un ALB sur plusieurs entrées. Pour de plus amples informations, veuillez consulter Acheminez le trafic d'applications et le trafic HTTP avec des équilibreurs de charge d'application. Vous ne pouvez pas partager un Network Load Balancer entre plusieurs services.

  • Déployez vos clusters dans plusieurs comptes.

• Si vos pods s'exécutent sous Windows dans un cluster Amazon EKS, un seul service doté d'un équilibreur de charge peut prendre en charge jusqu'à 1 024 pods principaux. Chaque pod a sa propre adresse IP.

• Nous recommandons de créer uniquement de nouveaux Network Load Balancers à l'aide du AWS Load Balancer Controller. Toute tentative de remplacement des équilibreurs de charge réseau existants créés à l'aide du contrôleur d'équilibrage de charge du fournisseur de AWS cloud peut entraîner la création de plusieurs équilibreurs de charge réseau susceptibles de provoquer des interruptions de service des applications.

Créer un équilibreur de charge de réseau

Vous pouvez créer un équilibreur de charge de réseau avec des cibles IP ou d'instance.

Création d'un équilibreur de charge réseau — IP Targets

• Vous pouvez utiliser des cibles IP avec des pods déployés sur des EC2 nœuds Amazon, Fargate ou Amazon EKS Hybrid Nodes. Votre service Kubernetes doit être créé en tant que type LoadBalancer. Pour plus d'informations, consultez la section Type LoadBalancer dans la documentation de Kubernetes.

  Pour créer un équilibreur de charge qui utilise des cibles IP, ajoutez l'annotation suivante à un manifeste du service et déployez votre service. La external valeur de aws-load-balancer-type est ce qui pousse le AWS Load Balancer Controller, plutôt que le contrôleur d'équilibrage de charge du fournisseur de AWS cloud, à créer le Network Load Balancer. Vous pouvez visualiser un exemple de manifeste de service avec les annotations.

  service.beta.kubernetes.io/aws-load-balancer-type: "external"
  service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"

  Note

  Si vous équilibrez la charge dans IPv6 Pods, ajoutez l'annotation suivante. 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.

  service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack

  Les Network Load Balancer sont créés avec le internal aws-load-balancer-scheme, par défaut. Vous pouvez lancer des équilibreurs de charge réseau dans n'importe quel sous-réseau du VPC de votre cluster, y compris les sous-réseaux qui n'ont pas été spécifiés lors de la création de votre cluster.

  Kubernetes examine la table de routage de vos sous-réseaux afin d'identifier s'ils sont publics ou privés. Les sous-réseaux publics dispose d'un acheminement direct vers Internet en utilisant une passerelle Internet. Ce n'est pas le cas des sous-réseaux privés.

  Si vous souhaitez créer un Network Load Balancer dans un sous-réseau public pour équilibrer la charge des nœuds Amazon EC2 (Fargate ne peut être que privé), spécifiez-le avec l'annotation suivante : internet-facing

  service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"

  Note

  Pour des raisons de rétrocompatibilité, l'annotation service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" est toujours prise en charge. Cependant, nous vous recommandons d'utiliser les annotations précédentes pour les nouveaux équilibreurs de charge au lieu de service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip".

  Important

  Ne modifiez pas les annotations après la création de votre service. Si vous devez le modifier, supprimez l'objet de service et créez-le à nouveau avec la valeur souhaitée pour cette annotation.

Créer un équilibreur de charge réseau — Instance Targets

• Le contrôleur d'équilibrage de charge du fournisseur de AWS cloud crée des équilibreurs de charge réseau avec des cibles d'instance uniquement. La version 2.2.0 et les versions ultérieures du AWS Load Balancer Controller créent également des Network Load Balancers avec des cibles d'instance. Nous vous recommandons de l'utiliser, plutôt que le contrôleur d'équilibrage de charge du fournisseur de AWS cloud, pour créer de nouveaux équilibreurs de charge réseau. Vous pouvez utiliser des cibles d'instance Network Load Balancer avec des pods déployés sur des EC2 nœuds Amazon, mais pas sur Fargate. Pour équilibrer la charge du trafic réseau entre les pods déployés sur Fargate, vous devez utiliser des cibles IP.

  Pour déployer un Network Load Balancer sur un sous-réseau privé, votre spécification de service doit comporter les annotations suivantes. Vous pouvez visualiser un exemple de manifeste de service avec les annotations. La external valeur de aws-load-balancer-type est ce qui pousse le AWS Load Balancer Controller, plutôt que le contrôleur d'équilibrage de charge du fournisseur de AWS cloud, à créer le Network Load Balancer.

  service.beta.kubernetes.io/aws-load-balancer-type: "external"
  service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"

  Les Network Load Balancer sont créés avec le internal aws-load-balancer-scheme, par défaut. Pour les Network Load Balancer internes, votre cluster Amazon EKS doit être configuré pour utiliser au moins un sous-réseau privé dans votre VPC. Kubernetes examine la table de routage de vos sous-réseaux afin d'identifier s'ils sont publics ou privés. Les sous-réseaux publics dispose d'un acheminement direct vers Internet en utilisant une passerelle Internet. Ce n'est pas le cas des sous-réseaux privés.

  Si vous souhaitez créer un Network Load Balancer dans un sous-réseau public pour équilibrer la charge des EC2 nœuds Amazon, spécifiez-le à l'internet-facingaide de l'annotation suivante :

  service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"

  Important

  Ne modifiez pas les annotations après la création de votre service. Si vous devez le modifier, supprimez l'objet de service et créez-le à nouveau avec la valeur souhaitée pour cette annotation.

(Facultatif) Déployer un exemple d'application

• Au moins un sous-réseau public ou privé dans votre VPC de cluster.

• Déployez le AWS Load Balancer Controller 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.

  1. Si vous effectuez un déploiement sur Fargate, assurez-vous qu'un sous-réseau privé est disponible dans votre VPC et créez un profil Fargate. Si vous ne déployez pas sur Fargate, ignorez cette étape. 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 nlb-sample-app \
         --namespace nlb-sample-app

  2. Déployez un exemple d'application.

     1. Créez un espace de nom pour l'application.

        kubectl create namespace nlb-sample-app

     2. Enregistrez le contenu suivant dans un fichier nommé sample-deployment.yaml sur votre ordinateur.

        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: nlb-sample-app
          namespace: nlb-sample-app
        spec:
          replicas: 3
          selector:
            matchLabels:
              app: nginx
          template:
            metadata:
              labels:
                app: nginx
            spec:
              containers:
                - name: nginx
                  image: public.ecr.aws/nginx/nginx:1.23
                  ports:
                    - name: tcp
                      containerPort: 80

     3. Appliquez le fichier manifeste à votre cluster.

        kubectl apply -f sample-deployment.yaml

  3. Créez un service avec un Network Load Balancer interne qui équilibre la charge vers les cibles IP.

     1. Enregistrez le contenu suivant dans un sample-service.yaml fichier nommé file sur votre ordinateur. Si vous effectuez un déploiement sur des nœuds Fargate, supprimez la ligne. service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing

        apiVersion: v1
        kind: Service
        metadata:
          name: nlb-sample-service
          namespace: nlb-sample-app
          annotations:
            service.beta.kubernetes.io/aws-load-balancer-type: external
            service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
            service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
        spec:
          ports:
            - port: 80
              targetPort: 80
              protocol: TCP
          type: LoadBalancer
          selector:
            app: nginx

     2. Appliquez le fichier manifeste à votre cluster.

        kubectl apply -f sample-service.yaml

  4. Vérifiez que le service a été déployé.

     kubectl get svc nlb-sample-service -n nlb-sample-app

     L'exemple qui suit illustre un résultat.

     NAME            TYPE           CLUSTER-IP         EXTERNAL-IP                                                                    PORT(S)        AGE
     sample-service  LoadBalancer   10.100.240.137   k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com  80:32400/TCP   16h

     Note

     Les valeurs pour 10.100.240.137 et xxxxxxxxxx - xxxxxxxxxxxxxxxx seront différentes de celles de l'exemple de sortie (elles seront propres à votre équilibreur de charge) et us-west-2 peuvent être différentes pour vous, selon AWS la région dans laquelle se trouve votre cluster.

  5. Ouvrez l'Amazon EC2 AWS Management Console. Sélectionnez Target Groups (Groupes cibles) (sous Load Balancing [Équilibrage de charge]) dans le panneau de navigation de gauche. Dans la colonne Nom, sélectionnez le nom du groupe cible dont la valeur de la colonne de l'équilibreur de charge correspond à une partie du nom de la EXTERNAL-IP colonne de sortie de l'étape précédente. Par exemple, vous devez sélectionner le groupe cible nommé k8s-default-samplese-xxxxxxxxxx si votre sortie est identique à la sortie précédente. Le Type de cible est IP, car cela a été spécifié dans l'exemple de manifeste de service.

  6. Sélectionnez votre Target group (Groupe cible), puis cliquez sur l'onglet Targets (Cibles). Sous Cibles enregistrées, vous devez voir trois adresses IP des trois réplicas déployés à une étape précédente. Attendez que le statut de toutes les cibles soit sain avant de continuer. L'affichage du statut healthy pour toutes les cibles peut prendre plusieurs minutes. Les cibles peuvent avoir l'état unhealthy avant qu'il soit remplacé par healthy.

  7. Envoyer le trafic vers le service en remplaçant xxxxxxxxxx-xxxxxxxxxxxxxxxx et us-west-2 par les valeurs renvoyées dans la sortie de l'étape précédente pour EXTERNAL-IP. Si vous avez effectué le déploiement sur un sous-réseau privé, vous devez afficher la page depuis un appareil au sein de votre VPC, tel qu'un hôte bastion. Pour plus d'informations, consultez la section Hôtes bastions Linux sur AWS.

     curl k8s-default-samplese-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com

     L'exemple qui suit illustre un résultat.

     <!DOCTYPE html>
     <html>
     <head>
     <title>Welcome to nginx!</title>
     [...]

  8. Lorsque vous avez terminé avec les exemples de déploiement, de service et d'espace de noms, supprimez-les.

     kubectl delete namespace nlb-sample-app