Acheminement TCP and UDP trafic avec Network Load Balancers - Amazon EKS
Créer un équilibreur de charge de réseau(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.

Acheminement TCP and UDP trafic avec Network Load Balancers

Le trafic réseau est équilibré en charge au niveau L4 du OSI modèle. Pour équilibrer la charge du trafic des applications surL7, vous déployez un Kubernetes ingress, qui fournit un AWS Application Load Balancer. Pour de plus amples informations, veuillez consulter Application d'itinéraire et HTTP trafic avec Application Load Balancers. 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 Servicede typeLoadBalancer, 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 AWS réseau. Ce contrôleur ne recevra que des corrections de bugs critiques à l'avenir. Pour plus d'informations sur l'utilisation de l' AWS équilibreur de charge du fournisseur de AWS cloud, voir le contrôleur d'équilibrage de charge du fournisseur de cloud dans le 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 Controllerau 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 ne crée pas d'é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 pour Pods déployé sur des cibles EC2 IP et d'instance Amazon ou sur des cibles AWS Fargate IP. Pour plus d'informations, consultez AWS Load Balancer Controller sur 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, 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 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 le AWS Load Balancer Controller version 2.1.1 ou 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 cluster ou si plusieurs AWS services partagent des sous-réseaux au sein d'un même sous-réseauVPC, et si vous souhaitez mieux contrôler l'emplacement des équilibreurs de charge pour chaque cluster. Si vous spécifiez explicitement un sous-réseau IDs sous forme d'annotation sur un objet de service, alors Kubernetes et le AWS Load Balancer Controller utilisez ces sous-réseaux directement pour créer l'équilibreur de charge. L'identification de sous-réseau n'est pas nécessaire si vous choisissez d'utiliser cette méthode pour approvisionner les équilibreurs de charge, et vous pouvez ignorer les exigences suivantes d'identification de sous-réseau privé et public. 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, alors Kubernetes et le AWS Load Balancer Controller utilisez 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. C'est pour que Kubernetes et le AWS Load Balancer Controller savent que les sous-réseaux peuvent être utilisés pour les équilibreurs de charge internes. Si vous utilisez eksctl un EKS AWS 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 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 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 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 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 identifications 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 par rapport à ce qu'ils sont lors de l'utilisation du contrôleur d'équilibrage de charge du fournisseur de AWS cloud. Assurez-vous de consulter les annotations pour le AWS Load Balancer Controller avant de déployer des services.

  • Lorsque vous utilisez le Amazon VPC CNI plugin for Kubernetes, le AWS Load Balancer Controller peut équilibrer la charge entre Amazon EC2 IP ou les cibles d'instance et les cibles IP Fargate. Lorsque vous utilisez des CNIplug-ins compatibles avec Alternate, le contrôleur peut uniquement équilibrer la charge par rapport aux cibles de l'instance. 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, ajoutez l'annotation suivante dans votre spécification de service. Pour plus d'informations, consultez la section Balises de AWS ressources dans le 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 le exemples de valeurs avec l'Allocation IDsune de vos adresses IP Elastic. Le nombre de Allocation IDs doit correspondre au nombre de sous-réseaux utilisés pour l'équilibreur de charge. Pour de plus amples informations, veuillez consulter le .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 dans le cadre des contrôles de santé VPC de chaque Network Load Balancer que vous créez. Le déploiement d'un type de service LoadBalancer peut échouer si Amazon EKS tente de créer des règles dépassant le quota du nombre maximum de règles autorisé pour un groupe de sécurité. Pour plus d'informations, consultez la section Groupes de sécurité dans VPC les quotas Amazon dans le guide de VPC l'utilisateur Amazon. 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, voir 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 le partager ALB entre plusieurs entrées. Pour de plus amples informations, veuillez consulter Application d'itinéraire et HTTP trafic avec Application Load Balancers. Vous ne pouvez pas partager un Network Load Balancer entre plusieurs services.

    • Déployez vos clusters dans plusieurs comptes.

  • Si vos recettes Pods continuer à courir Windows dans un EKS cluster Amazon, un seul service doté d'un équilibreur de charge peut prendre en charge jusqu'à 1 024 back-end Pods. Chaque Pod possède sa propre adresse IP unique.

  • Nous recommandons de créer uniquement de nouveaux équilibreurs de charge réseau avec le 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.

IP targets

Vous pouvez utiliser des cibles IP avec Pods déployé sur les EC2 nœuds Amazon ou Fargate. Votre Kubernetes le service doit être créé en tant que typeLoadBalancer. Pour plus d'informations, voir Tapez LoadBalancer dans le 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 pour aws-load-balancer-type est ce qui cause le AWS Load Balancer Controller, plutôt que le contrôleur d'équilibrage de charge du fournisseur de AWS cloud, pour 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 pour 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 de votre clusterVPC, 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 de déterminer 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.

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. Les versions 2.2.0 et ultérieures de l' 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 les cibles d'instance Network Load Balancer avec Pods déployé sur les EC2 nœuds Amazon, mais pas sur Fargate. Pour équilibrer la charge du trafic réseau entre Pods déployé 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 équilibreurs de charge réseau internes, votre EKS cluster Amazon 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 de déterminer 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 afin d'é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

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

  1. Si vous effectuez un déploiement sur Fargate, assurez-vous de disposer d'un sous-réseau privé disponible dans votre profil Fargate 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 fichier nommé sample-service.yaml sur votre ordinateur. Si vous déployez vers 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érents de ceux de l'exemple de sortie (ils seront uniques à votre équilibreur de charge) et us-west-2 peut être différent pour vous, en fonction de l'endroit dans Région AWS lequel 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 Name (Nom), sélectionnez le nom du groupe cible où la valeur de la colonne Load balancer (Équilibreur de charge) correspond à une partie du nom dans la colonne EXTERNAL-IP de la sortie à l'étape précédente. Par exemple, vous sélectionneriez le groupe cible nommé k8s-default-samplese-xxxxxxxxxx si votre sortie était la même que celle de l'étape 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 devrez consulter la page depuis un appareil de votre choixVPC, tel qu'un hôte Bastion. Pour plus d’informations, consultez .Linux Bastion Hosts activé. 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 le déploiement, le service et l'espace de noms de l'exemple, supprimez-les.

    kubectl delete namespace nlb-sample-app