View a markdown version of this page

Opérations de la passerelle Amazon EKS Hybrid Nodes - Amazon EKS
Haute disponibilité et basculementGestion des tables de routage VPCContrôleConsidérations relatives à la mise à l'échelleCycle de vie du tunnel VXLANÉtapes suivantes

Aidez à améliorer cette page

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.

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

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.

Opérations de la passerelle Amazon EKS Hybrid Nodes

Cette page décrit les opérations quotidiennes de la passerelle Amazon EKS Hybrid Nodes, notamment la haute disponibilité, le comportement de basculement, la surveillance, le dimensionnement et le cycle de vie du tunnel VXLAN. Pour obtenir des instructions d’installation, consultez Commencez avec la passerelle EKS Hybrid Nodes.

Haute disponibilité et basculement

La passerelle Hybrid Nodes utilise un modèle de veille active avec élection du leader de Kubernetes Lease-based . Deux pods de passerelle s'exécutent sur des nœuds EC2 distincts, conformément à l'anti-affinité des pods. Les deux pods créent une interface VXLAN au démarrage et exécutent un réconciliateur de nœuds qui conserve les entrées VTEP pour tous les nœuds hybrides. Seul le module leader gère les tables de routage VPC et le CiliumVTEPConfig CRD. Le module de secours est toujours prêt à transférer le trafic dans un délai de 3 à 5 secondes en cas de basculement, car il possède déjà un ensemble complet d'entrées de tunnel.

Séquence de basculement

Lorsque l'instance de passerelle active échoue, la séquence suivante se produit :

  1. Le module de secours détecte que le bail du leader a expiré.

  2. Le module de secours obtient le bail et devient le nouveau leader.

  3. Le nouveau leader exécute la séquence de configuration du leader :

    • Met à jour les entrées de la table de routage VPC pour pointer les CIDR des pods hybrides vers l'ENI principal du nouveau leader.

    • Ajoute à la ressource CiliumVTEPConfig personnalisée l'adresse IP du nœud et l'adresse MAC VXLAN du nouveau leader.

  4. Le trafic recommence à circuler via le nouveau leader.

Comme les deux pods conservent les interfaces VXLAN et les entrées VTEP à tout moment, le nouveau leader n'a pas besoin de recréer l'interface VXLAN ni de reprogrammer les entrées du tunnel lors du basculement. Seules la table de routage VPC et les CiliumVTEPConfig mises à jour sont requises.

Le temps de basculement prévu est d'environ 3 à 5 secondes. Pendant le basculement, le trafic entre le VPC et les pods hybrides est interrompu.

Recommandation de zone de disponibilité

Répartissez les nœuds de passerelle sur deux zones de disponibilité afin qu'une panne AZ ne détruise pas à la fois le leader et le serveur de secours. Lorsque vous utilisez le mode automatique d'EKS, configurez votre compte à l'NodeClassaide de sélecteurs de sous-réseau répartis sur plusieurs zones de disponibilité. Pour les groupes de nœuds gérés ou les nœuds autogérés, choisissez des nœuds dans différentes zones de disponibilité lorsque vous les étiquetez.

Note

Cross-AZ le trafic entre la passerelle et les autres ressources du VPC entraîne des frais de transfert de données AWS cross-AZ standard.

Paramètres de l'élection du chef

Les paramètres d'élection du leader par défaut sont réglés pour un basculement rapide :

Paramètre Par défaut Description

--leader-election-lease-duration

3s

Combien de temps un non-dirigeant attend avant de tenter d'acquérir le bail une fois que le dirigeant a cessé de le renouveler.

--leader-election-renew-deadline

2s

Combien de temps le dirigeant essaie de renouveler le bail avant d'y renoncer.

--leader-election-retry-period

1s

À quelle fréquence les candidats réessayent d'obtenir le bail.

La réduction de ces valeurs réduit le temps de basculement mais augmente le risque de faux basculements sous les partitions réseau. Pour la plupart des déploiements, les valeurs par défaut sont appropriées. Pour de plus amples informations, veuillez consulter Référence de configuration de la passerelle Amazon EKS Hybrid Nodes.

Gestion des tables de routage VPC

La passerelle gère les entrées de la table de routage VPC afin que le trafic destiné aux CIDR du pod hybride atteigne l'instance de passerelle active.

Comment les itinéraires sont gérés

Lorsqu'un pod de passerelle devient le leader, il crée ou remplace des routes dans chaque table de routage VPC configurée. Chaque itinéraire définit le CIDR de destination sur un CIDR de module hybride et la cible sur l'ENI principal du leader. Si un itinéraire existe déjà et pointe vers le bon ENI, la passerelle ignore la mise à jour.

Lors du basculement, le nouveau leader remplace les itinéraires existants afin qu'ils pointent vers son propre ENI. Il s'agit du mécanisme qui redirige le trafic VPC vers la nouvelle passerelle active.

Exemple d'entrée dans une table de routage

Une fois que la passerelle a configuré les itinéraires, votre table de routage VPC contient des entrées similaires aux suivantes :

Destination Cible Statut

10.0.0.0/16

local

actif

HYBRID_POD_CIDR

eni-LEADER_ENI_ID

actif

Autorisations IAM

La passerelle nécessite les actions IAM suivantes pour gérer les tables de routage :

  • ec2:DescribeRouteTables

  • ec2:CreateRoute

  • ec2:ReplaceRoute

  • ec2:DescribeInstances

Associez ces autorisations au rôle IAM associé au profil d'instance, à l'identité du pod ou à la configuration IRSA des nœuds de passerelle.

Contrôle

Points de terminaison relatifs à la santé et à la préparation

La passerelle expose les points de terminaison relatifs à l'état et à l'état de préparation au port : 8088

Endpoint Chemin Description

Surveillance de l'état

/healthz

Renvoie HTTP 200 lorsque le processus de passerelle est sain. Utilisé par la sonde Liveness de Kubernetes.

Contrôle de préparation

/readyz

Renvoie HTTP 200 lorsque la passerelle est prête à traiter le trafic. Utilisé par la sonde de préparation de Kubernetes.

Vous pouvez interroger ces points de terminaison manuellement à des fins de diagnostic en exécutant un conteneur de débogage temporaire ou en redirigeant le port :

kubectl port-forward -n eks-hybrid-nodes-gateway POD_NAME 8088:8088 &
curl -s http://localhost:8088/healthz
curl -s http://localhost:8088/readyz

Point final des métriques

La passerelle expose les Prometheus-compatible métriques relatives 10080 au port situé sur le /metrics chemin. Les métriques personnalisées suivantes sont disponibles en plus des métriques d'exécution du contrôleur standard.

Informations sur la passerelle :

Métrique Type Description

hybrid_gateway_info

Jauge

Informations statiques sur l'instance de passerelle. Toujours 1. Étiquettes :node_ip,node_name,vxlan_interface,vpc_cidr,pod_cidr.

Nœuds hybrides :

Métrique Type Description

hybrid_gateway_hybrid_nodes_configured

Jauge

Nombre actuel de nœuds hybrides avec des entrées VTEP configurées.

Opérations VTEP :

Métrique Type Description

hybrid_gateway_vtep_add_total

Compteur

Nombre total d'opérations d'ajout de VTEP réussies.

hybrid_gateway_vtep_add_errors_total

Compteur

Nombre total d'opérations d'ajout de VTEP ayant échoué.

hybrid_gateway_vtep_remove_total

Compteur

Nombre total d'opérations de suppression VTEP réussies.

hybrid_gateway_vtep_remove_errors_total

Compteur

Nombre total d'opérations de suppression VTEP ayant échoué.

Élection des leaders et tables de routage :

Métrique Type Description

hybrid_gateway_leader_is_active

Jauge

1 si ce pod est le leader actif, 0 s'il est en veille.

hybrid_gateway_leader_setup_duration_seconds

Histogramme

Durée des opérations de configuration du leader (tables de routage + CiliumVTEPConfig) en secondes.

hybrid_gateway_aws_route_table_update_total

Compteur

Nombre total d'opérations de mise à jour de table de AWS routage réussies.

hybrid_gateway_aws_route_table_update_errors_total

Compteur

Nombre total d'opérations de mise à jour de la table de AWS routage ayant échoué

hybrid_gateway_aws_route_table_update_duration_seconds

Histogramme

Durée des opérations de mise à jour de la table de AWS routage en secondes.

Statistiques du réseau (collectées à la demande par extrait) :

Métrique Type Description

hybrid_gateway_vxlan_rx_bytes_total

Jauge

Nombre total d'octets reçus sur l'interface VXLAN.

hybrid_gateway_vxlan_tx_bytes_total

Jauge

Nombre total d'octets transmis sur l'interface VXLAN.

hybrid_gateway_vxlan_rx_packets_total

Jauge

Nombre total de paquets reçus sur l'interface VXLAN.

hybrid_gateway_vxlan_tx_packets_total

Jauge

Nombre total de paquets transmis sur l'interface VXLAN.

hybrid_gateway_vxlan_rx_dropped_total

Jauge

Nombre total de paquets abandonnés à la réception par l'interface VXLAN.

hybrid_gateway_vxlan_tx_dropped_total

Jauge

Nombre total de paquets abandonnés lors de la transmission par l'interface VXLAN.

hybrid_gateway_vxlan_rx_errors_total

Jauge

Nombre total d'erreurs de réception sur l'interface VXLAN.

hybrid_gateway_vxlan_tx_errors_total

Jauge

Nombre total d'erreurs de transmission sur l'interface VXLAN.

hybrid_gateway_vxlan_interface_up

Jauge

1 si l'interface VXLAN est active, 0 dans le cas contraire.

hybrid_gateway_vxlan_fdb_entries

Jauge

Nombre actuel d'entrées FDB sur l'interface VXLAN.

hybrid_gateway_vxlan_route_count

Jauge

Nombre actuel de routes via l'interface VXLAN.

hybrid_gateway_primary_nic_rx_bytes_total

Jauge

Nombre total d'octets reçus sur l'interface réseau principale.

hybrid_gateway_primary_nic_tx_bytes_total

Jauge

Nombre total d'octets transmis sur l'interface réseau principale.

hybrid_gateway_primary_nic_rx_packets_total

Jauge

Nombre total de paquets reçus sur l'interface réseau principale.

hybrid_gateway_primary_nic_tx_packets_total

Jauge

Nombre total de paquets transmis sur l'interface réseau principale.

hybrid_gateway_primary_nic_rx_dropped_total

Jauge

Nombre total de paquets abandonnés à la réception par la carte réseau principale.

hybrid_gateway_primary_nic_tx_dropped_total

Jauge

Nombre total de paquets abandonnés lors de la transmission par la carte réseau principale.

hybrid_gateway_primary_nic_rx_errors_total

Jauge

Nombre total d'erreurs de réception sur la carte réseau principale.

hybrid_gateway_primary_nic_tx_errors_total

Jauge

Nombre total d'erreurs de transmission sur la carte réseau principale.

hybrid_gateway_primary_nic_info

Jauge

Nom de la carte réseau principale. Toujours 1. Étiquettes :interface_name.

CloudWatch Module complémentaire d'observabilité

Vous pouvez utiliser le module complémentaire Amazon CloudWatch Observability pour collecter des statistiques et des journaux de passerelle. Configurez le module complémentaire pour supprimer l'espace de noms de la passerelle (eks-hybrid-nodes-gateway) sur le port. 10080 Pour connaître le format de configuration correct, consultez la documentation complémentaire liée ci-dessus.

Considérations relatives à la mise à l'échelle

La passerelle Hybrid Nodes utilise un modèle de veille active avec élection du leader, de sorte qu'un seul module gère le trafic à la fois. Le dimensionnement horizontal de la passerelle (en augmentant le nombre de répliques) peut améliorer la disponibilité en fournissant des modules de secours supplémentaires prêts à prendre le relais lors du basculement, mais cela n'améliore ni les performances ni le débit car le trafic n'est pas réparti entre les répliques. Pour augmenter les performances, effectuez une mise à l'échelle verticale en choisissant un type d'instance EC2 doté d'une bande passante réseau suffisante pour votre volume de trafic.

Conseils relatifs aux types d'instances

Le débit de la passerelle est limité par les performances du réseau de l'instance EC2. Tenez compte des points suivants lorsque vous sélectionnez un type d'instance :

  • Bande passante réseau : la passerelle transmet tout le trafic entre le VPC et les pods hybrides. Choisissez un type d'instance dont la bande passante réseau répond à vos exigences de trafic de pointe.

  • Paquets par seconde (PPS) : l'encapsulation VXLAN augmente la charge par paquet. Les charges de travail comportant de nombreux petits paquets (par exemple, les microservices présentant des taux de requêtes élevés) bénéficient de types d'instances présentant des limites de PPS plus élevées.

  • Nombre de nœuds hybrides : chaque nœud hybride ajoute un point de terminaison de tunnel VXLAN par lequel la passerelle transmet le trafic. À mesure que le nombre de nœuds hybrides augmente, le trafic agrégé passant par la passerelle augmente. Sélectionnez un type d'instance doté d'une bande passante réseau suffisante pour gérer le pic de trafic interréseau de votre cluster.

Types d'instances recommandés

Production (10 à 100 nœuds hybrides, trafic modéré)

Convient aux charges de travail de production standard avec un trafic interréseau constant.

Type d’instance vCPUs Mémoire Réseau Remarques

c6i.xlarge

4

8 GiO

Jusqu'à 12,5 Gbps

Bon équilibre entre coût et performance

c6in.xlarge

4

8 GiO

Jusqu'à 30 Gbit/s

Network-optimized; recommandé pour la production

c7i.xlarge

4

8 GiO

Jusqu'à 12,5 Gbps

Optimisé pour le calcul de dernière génération

m6i.xlarge

4

16 GiO

Jusqu'à 12,5 Gbps

Convient si vous colocalisez d'autres charges de travail sur des nœuds de passerelle

High-throughput production (plus de 100 nœuds hybrides, trafic intense)

Pour les environnements présentant des besoins importants en bande passante inter-réseaux, tels que les charges de travail gourmandes en données ou de nombreuses connexions simultanées.

Type d’instance vCPUs Mémoire Réseau Remarques

c6in.2xlarge

8

16 GiO

Jusqu'à 40 Gbit/s

Recommandé pour la production à haut débit

c5n.2xlarge

8

21 GiB

Jusqu'à 25 Gbit/s

Previous-generation optimisé pour le réseau, rentable

c6in.4xlarge

16

32 GiO

Jusqu'à 50 Gbit/s

Débit maximal pour les charges de travail très lourdes

c5n.4xlarge

16

42 GiB

Jusqu'à 25 Gbit/s

Nombre élevé de vCPU pour des débits de paquets extrêmes

Surveillez l'utilisation du réseau à l'aide des métriques de passerelle (voirPoint final des métriques) et ajustez le type d'instance selon les besoins.

Cycle de vie du tunnel VXLAN

La passerelle gère automatiquement les tunnels VXLAN vers les nœuds hybrides lorsqu'ils rejoignent ou quittent le cluster.

Comment sont gérés les tunnels

Un contrôleur de nœud surveille CiliumNode les objets du cluster. Le contrôleur fonctionne sur chaque module de passerelle (et pas seulement sur le module principal), de sorte que l'état du tunnel entre le principal et le module de secours est à jour. Lorsqu'un CiliumNode événement se produit, le contrôleur vérifie si le nœud est un nœud hybride en recherchant l'eks.amazonaws.com/compute-type: hybridétiquette.

Lorsqu'un nœud hybride rejoint le cluster :

  1. Le contrôleur détecte le nouvel CiliumNode objet.

  2. Il extrait l'adresse IP interne du nœud et le CIDR du pod à partir de la CiliumNode spécification.

  3. Il programme les opérations suivantes sur l'interface VXLAN :

    • Une route pour le CIDR du pod du nœud via l'adresse IP du nœud via l'interface VXLAN.

    • Entrée ARP statique mappant l'adresse IP du nœud à une adresse MAC déterministe.

    • Une entrée FDB indiquant au module VXLAN d'envoyer des paquets encapsulés à l'adresse IP du nœud.

Lorsqu'un nœud hybride quitte le cluster :

  1. Le contrôleur détecte la CiliumNode suppression.

  2. Il supprime la route, l'entrée ARP et l'entrée FDB pour ce nœud de l'interface VXLAN.

Ce cycle de vie est entièrement automatique. Il n'est pas nécessaire de configurer manuellement les tunnels lors de l'ajout ou de la suppression de nœuds hybrides.

Étapes suivantes