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.
Considérations relatives au VPC et aux sous-réseaux
Astuce
Découvrez les
L'exploitation d'un cluster EKS nécessite une connaissance du réseau AWS VPC, en plus de la mise en réseau Kubernetes.
Nous vous recommandons de comprendre les mécanismes de communication du plan de contrôle EKS avant de commencer à concevoir votre VPC ou à déployer des clusters dans des VPC existants.
Reportez-vous aux rubriques Considérations relatives au cluster VPC et aux considérations relatives aux groupes de sécurité Amazon EKS lors de l'architecture d'un VPC et de sous-réseaux à utiliser avec EKS.
Présentation de
Architecture du cluster EKS
Un cluster EKS est composé de deux VPC :
-
Un AWS-managed VPC qui héberge le plan de contrôle Kubernetes. Ce VPC n'apparaît pas dans le compte client.
-
Un VPC géré par le client qui héberge les nœuds Kubernetes. C'est là que s'exécutent les conteneurs, ainsi que les autres infrastructures AWS gérées par le client, telles que les équilibreurs de charge utilisés par le cluster. Ce VPC apparaît dans le compte client. Vous devez créer un VPC géré par le client avant de créer un cluster. L'eksctl crée un VPC si vous n'en fournissez pas.
Les nœuds du VPC client doivent pouvoir se connecter au point de terminaison du serveur d'API géré dans le VPC AWS. Cela permet aux nœuds de s'enregistrer auprès du plan de contrôle de Kubernetes et de recevoir des demandes pour exécuter des pods d'application.
Les nœuds se connectent au plan de contrôle EKS via (a) un point de terminaison public EKS ou (b) une interface réseau Cross-Account élastique (X-ENI) gérée par EKS. Lorsqu'un cluster est créé, vous devez spécifier au moins deux sous-réseaux VPC. EKS place un X-ENI dans chaque sous-réseau spécifié lors de la création du cluster (également appelé sous-réseaux du cluster). Le serveur API Kubernetes utilise ces Cross-Account ENI pour communiquer avec les nœuds déployés sur les sous-réseaux VPC du cluster gérés par le client.
Lorsque le nœud démarre, le script d'amorçage EKS est exécuté et les fichiers de configuration du nœud Kubernetes sont installés. Dans le cadre du processus de démarrage de chaque instance, les agents d'exécution du conteneur, Kubelet et les agents de nœud Kubernetes sont lancés.
Pour enregistrer un nœud, Kubelet contacte le point de terminaison du cluster Kubernetes. Il établit une connexion soit avec le point de terminaison public extérieur au VPC, soit avec le point de terminaison privé au sein du VPC. Kubelet reçoit des instructions d'API et fournit régulièrement des mises à jour de statut et des battements de cœur au terminal.
Communication sur le plan de contrôle EKS
EKS dispose de deux méthodes pour contrôler l'accès au point de terminaison du cluster. Le contrôle d'accès aux terminaux vous permet de choisir si le terminal est accessible depuis l'Internet public ou uniquement via votre VPC. Vous pouvez activer le terminal public (qui est le terminal par défaut), le terminal privé ou les deux à la fois.
La configuration du point de terminaison de l'API du cluster détermine le chemin emprunté par les nœuds pour communiquer avec le plan de contrôle. Notez que ces paramètres de point de terminaison peuvent être modifiés à tout moment via la console ou l'API EKS.
Point de terminaison public
Il s'agit du comportement par défaut pour les nouveaux clusters Amazon EKS. Lorsque seul le point de terminaison public du cluster est activé, les demandes d'API Kubernetes provenant du VPC de votre cluster (telles que la communication entre le nœud de travail et le plan de contrôle) quittent le VPC, mais pas le réseau Amazon. Pour que les nœuds puissent se connecter au plan de contrôle, ils doivent disposer d'une adresse IP publique et d'une route vers une passerelle Internet ou d'une route vers une passerelle NAT où ils peuvent utiliser l'adresse IP publique de la passerelle NAT.
Endpoint public et privé
Lorsque les points de terminaison publics et privés sont activés, les demandes d'API Kubernetes provenant du VPC communiquent avec le plan de contrôle via l'interface interne de votre VPC. X-ENIs Le serveur d'API de votre cluster est accessible depuis internet.
Endpoint privé
Il n'y a pas d'accès public à votre serveur API depuis Internet lorsque seul le point de terminaison privé est activé. Tout le trafic vers le serveur d’API du cluster doit provenir de votre VPC ou d’un réseau connecté. Les nœuds communiquent avec le serveur API via X-ENIs votre VPC. Notez que les outils de gestion de cluster doivent avoir accès au terminal privé. Découvrez comment vous connecter à un point de terminaison de cluster Amazon EKS privé depuis l'extérieur d'Amazon VPC.
Notez que le point de terminaison du serveur API du cluster est résolu par les serveurs DNS publics en une adresse IP privée provenant du VPC. Dans le passé, le point de terminaison ne pouvait être résolu qu'à partir du VPC.
Configurations VPC
Amazon VPC prend en charge l'adressage IPv4 et IPv6. Amazon EKS prend en charge IPv4 par défaut. Un VPC doit être associé à un bloc d'adresse CIDR IPv4. Vous pouvez éventuellement associer plusieurs blocs CIDR (/16 préfixe (65 536 adresses IP) et un /28 préfixe (16 adresses IP).
Lors de la création d'un nouveau VPC, vous pouvez joindre un seul bloc d'adresse CIDR IPv6 et jusqu'à cinq lors de la modification d'un VPC existant. La longueur du préfixe de la taille de bloc d'adresse CIDR IPv6 peut être comprise entre /44 et /60 et pour les sous-réseaux IPv6, elle peut être comprise entre /44/ et /64. Vous pouvez demander un bloc d'adresse CIDR IPv6 à partir du pool d'adresses IPv6 géré par Amazon. Reportez-vous à la section Blocs d'adresse CIDR des VPC du Guide de l'utilisateur du VPC pour plus d'informations.
Les clusters Amazon EKS prennent en charge IPv4 et IPv6. Par défaut, les clusters EKS utilisent le protocole IP IPv4. La spécification d'IPv6 au moment de la création du cluster permettra d'utiliser des clusters IPv6. Les clusters IPv6 nécessitent des VPC et des sous-réseaux à double pile.
Amazon EKS exige que vous spécifiiez au moins deux sous-réseaux dans deux zones de disponibilité différentes lorsque vous créez un cluster. Les sous-réseaux que vous spécifiez sont appelés sous-réseaux de cluster. Amazon EKS fournit deux ENI intercomptes (X-ENI) dans différentes zones de disponibilité afin de permettre la communication avec vos nœuds de travail. Lorsque vous créez un cluster, Amazon EKS crée 2 à 4 X-ENI dans les sous-réseaux que vous avez spécifiés. Amazon EKS déploie toujours les X-ENIS et les utilise pour le trafic d'administration du cluster, tel que la livraison des journaux, l'exécution et le proxy. Pour plus d'informations sur les exigences relatives aux VPC et aux sous-réseaux, consultez la section Exigences relatives aux VPC et aux sous-réseaux dans le guide de l'utilisateur Amazon EKS.
Les nœuds de travail Kubernetes peuvent s'exécuter dans les sous-réseaux du cluster, mais cela n'est pas recommandé. Lors des mises à niveau du cluster, Amazon EKS fournit des ENI supplémentaires dans les sous-réseaux du cluster. Lorsque votre cluster évolue, les nœuds de travail et les pods peuvent consommer les adresses IP disponibles dans le sous-réseau du cluster. Par conséquent, afin de vous assurer qu'il y a suffisamment d'adresses IP disponibles, vous pouvez envisager d'utiliser des sous-réseaux de cluster dédiés avec un masque de réseau /28.
Les nœuds de travail Kubernetes peuvent s'exécuter dans un sous-réseau public ou privé. Le fait qu'un sous-réseau soit public ou privé indique si le trafic au sein du sous-réseau est acheminé via une passerelle Internet. Les sous-réseaux publics disposent d'une entrée de table de routage vers Internet via la passerelle Internet, mais pas les sous-réseaux privés.
Le trafic qui provient d'un autre endroit et atteint vos nœuds est appelé entrée. Le trafic qui provient des nœuds et quitte le réseau est appelé sortie. Les nœuds dotés d'adresses IP publiques ou élastiques (EIP) au sein d'un sous-réseau configuré avec une passerelle Internet autorisent l'entrée depuis l'extérieur du VPC. Les sous-réseaux privés ont généralement un routage vers une passerelle NAT, qui n'autorise pas le trafic entrant vers les nœuds des sous-réseaux depuis l'extérieur du VPC tout en permettant au trafic en provenance des nœuds de quitter le VPC (sortie).
Dans le monde IPv6, chaque adresse est routable sur Internet. Les adresses IPv6 associées aux nœuds et aux pods sont publiques. Les sous-réseaux privés sont pris en charge en implémentant une passerelle Internet de sortie uniquement (EIGW) dans un VPC, permettant le trafic sortant tout en bloquant tout le trafic entrant. Les meilleures pratiques pour la mise en œuvre de sous-réseaux IPv6 sont disponibles dans le guide de l'utilisateur du VPC.
Vous pouvez configurer le VPC et les sous-réseaux de trois manières différentes :
Utiliser uniquement des sous-réseaux publics
Dans les mêmes sous-réseaux publics, les nœuds et les ressources d'entrée (tels que les équilibreurs de charge) sont créés. Marquez le sous-réseau public kubernetes.io/role/elb pour créer des équilibreurs de charge orientés vers Internet. Dans cette configuration, le point de terminaison du cluster peut être configuré pour être public, privé ou les deux (public et privé).
Utilisation de sous-réseaux privés et publics
Les nœuds sont créés sur des sous-réseaux privés, tandis que les ressources d'entrée sont instanciées dans des sous-réseaux publics. Vous pouvez activer l'accès public, privé ou les deux (public et privé) au point de terminaison du cluster. Selon la configuration du point de terminaison du cluster, le trafic du nœud entrera via la passerelle NAT ou l'ENI.
Utiliser uniquement des sous-réseaux privés
Les nœuds et les entrées sont créés dans des sous-réseaux privés. Utilisation de la balise de kubernetes.io/role/internal-elb sous-réseau pour créer des équilibreurs de charge internes. L'accès au point de terminaison de votre cluster nécessite une connexion VPN. Vous devez activer AWS PrivateLink pour EC2 et tous les référentiels Amazon ECR et S3. Seul le point de terminaison privé du cluster doit être activé. Nous vous suggérons de passer en revue les exigences relatives aux clusters privés EKS avant de provisionner des clusters privés.
Communication entre les VPC
Il existe de nombreux scénarios dans lesquels vous avez besoin de plusieurs VPC et de clusters EKS distincts déployés sur ces VPC.
Vous pouvez utiliser Amazon VPC Lattice
Amazon VPC Lattice fonctionne dans l'espace d'adressage lien-local en IPv4 et IPv6, fournissant une connectivité entre des services dont les adresses IPv4 peuvent se chevaucher. Pour des raisons d'efficacité opérationnelle, nous vous recommandons vivement de déployer des clusters et des nœuds EKS sur des plages IP qui ne se chevauchent pas. Si votre infrastructure comprend des VPC dont les plages IP se chevauchent, vous devez concevoir votre réseau en conséquence. Nous suggérons une passerelle NAT privée, ou VPC CNI, en mode réseau personnalisé en conjonction avec une passerelle de transit pour intégrer les charges de travail sur EKS afin de résoudre les problèmes de CIDR qui se chevauchent tout en préservant les adresses IP RFC1918 routables.
Envisagez d'utiliser AWS PrivateLink, également connu sous le nom de service de point de terminaison, si vous êtes le fournisseur de services et que vous souhaitez partager votre service Kubernetes et vos entrées (ALB ou NLB) avec le VPC de votre client sur des comptes distincts.
Partage d'un VPC sur plusieurs comptes
De nombreuses entreprises ont adopté les VPC Amazon partagés afin de rationaliser l'administration du réseau, de réduire les coûts et d'améliorer la sécurité de plusieurs comptes AWS au sein d'une organisation AWS. Ils utilisent AWS Resource Access Manager (RAM) pour partager en toute sécurité les ressources AWS prises en charge avec des comptes AWS individuels, des unités organisationnelles (OU) ou l'ensemble de l'organisation AWS.
Vous pouvez déployer des clusters Amazon EKS, des groupes de nœuds gérés et d'autres ressources AWS de support (telles que des groupes de sécurité LoadBalancers, des points de terminaison, etc.) dans des sous-réseaux VPC partagés à partir d'un autre compte AWS à l'aide de la RAM AWS. La figure ci-dessous illustre un exemple d'architecture de haut niveau. Cela permet aux équipes réseau centralisées de contrôler les structures réseau telles que les VPC, les sous-réseaux, etc., tout en permettant aux équipes chargées des applications ou des plateformes de déployer des clusters Amazon EKS dans leurs comptes AWS respectifs. Une présentation complète de ce scénario est disponible sur ce référentiel github.
Considérations relatives à l'utilisation de sous-réseaux partagés
-
Les clusters et nœuds de travail Amazon EKS peuvent être créés dans des sous-réseaux partagés qui font tous partie du même VPC. Amazon EKS ne prend pas en charge la création de clusters sur plusieurs VPC.
-
Amazon EKS utilise les groupes de sécurité (SG) AWS VPC pour contrôler le trafic entre le plan de contrôle Kubernetes et les nœuds de travail du cluster. Les groupes de sécurité sont également utilisés pour contrôler le trafic entre les nœuds de travail, les autres ressources VPC et les adresses IP externes. Vous devez créer ces groupes de sécurité dans le application/participant compte. Assurez-vous que les groupes de sécurité que vous souhaitez utiliser pour vos pods se trouvent également dans le compte du participant. Vous pouvez configurer les règles entrantes et sortantes au sein de vos groupes de sécurité pour autoriser le trafic nécessaire à destination et en provenance des groupes de sécurité situés dans le compte Central VPC.
-
Créez des rôles IAM et des politiques associées dans le compte du participant sur lequel réside votre cluster Amazon EKS. Ces rôles et politiques IAM sont essentiels pour accorder les autorisations nécessaires aux clusters Kubernetes gérés par Amazon EKS, ainsi qu'aux nœuds et aux pods exécutés sur Fargate. Les autorisations permettent à Amazon EKS de passer des appels vers d'autres services AWS en votre nom.
-
Vous pouvez suivre les approches suivantes pour autoriser l'accès entre comptes aux ressources AWS telles que les compartiments Amazon S3, les tables Dynamodb, etc., à partir des pods k8s :
-
Approche stratégique basée sur les ressources : si le service AWS prend en charge les politiques relatives aux ressources, vous pouvez ajouter une politique appropriée basée sur les ressources pour autoriser l'accès entre comptes aux rôles IAM attribués aux pods Kubernetes. Dans ce scénario, le fournisseur OIDC, les rôles IAM et les politiques d'autorisation existent dans le compte d'application. Pour trouver les services AWS qui prennent en charge les politiques basées sur les ressources, consultez la section Services AWS qui fonctionnent avec IAM et recherchez les services dont la valeur est Oui dans la colonne Basée sur les ressources.
-
Approche du fournisseur OIDC : les ressources IAM telles que le fournisseur OIDC, les rôles IAM, les autorisations et les politiques de confiance seront créées sur le compte AWS d'un autre participant sur lequel les ressources existent. Ces rôles seront attribués aux pods Kubernetes dans le compte de l'application, afin qu'ils puissent accéder aux ressources intercomptes. Consultez le blog sur les rôles IAM
intercomptes pour les comptes de service Kubernetes pour une présentation complète de cette approche.
-
-
Vous pouvez déployer les ressources Amazon Elastic Loadbalancer (ELB) (ALB ou NLB) pour acheminer le trafic vers les pods k8s, soit dans des applications, soit dans des comptes réseau centraux. Reportez-vous à la procédure pas à pas d'
Exposer les modules Amazon EKS via Cross-Account Load Balancer pour obtenir des instructions détaillées sur le déploiement des ressources ELB dans un compte réseau central. Cette option offre une flexibilité accrue, car elle confère au compte réseau central le contrôle total de la configuration de sécurité des ressources de l'équilibreur de charge. -
Lorsque vous utilisez
custom networking featureAmazon VPC CNI, vous devez utiliser les mappages d'ID de zone de disponibilité (AZ) répertoriés dans le compte réseau central pour créer chacun d'eux.ENIConfigCela est dû au mappage aléatoire des AZ physiques avec les noms des AZ de chaque compte AWS.
Groupes de sécurité
Un groupe de sécurité contrôle le trafic autorisé à atteindre et à quitter les ressources auxquelles il est associé. Amazon EKS utilise des groupes de sécurité pour gérer la communication entre le plan de contrôle et les nœuds. Lorsque vous créez un cluster, Amazon EKS crée un groupe de sécurité nommé eks-cluster-sg-my-cluster-uniqueID. EKS associe ces groupes de sécurité aux ENI gérés et aux nœuds. Les règles par défaut permettent à tout le trafic de circuler librement entre votre cluster et vos nœuds, et autorise tout le trafic sortant vers n'importe quelle destination.
Lorsque vous créez un cluster, vous pouvez spécifier vos propres groupes de sécurité. Consultez les recommandations relatives aux groupes de sécurité lorsque vous spécifiez vos propres groupes de sécurité.
Recommandations
Pensez Multi-AZ au déploiement
Les régions AWS fournissent plusieurs zones de disponibilité (AZ) physiquement séparées et isolées, qui sont connectées à un réseau à faible latence, haut débit et hautement redondant. Grâce aux zones de disponibilité, vous pouvez concevoir et exploiter des applications qui basculent automatiquement entre les zones de disponibilité sans interruption. Amazon EKS recommande vivement de déployer des clusters EKS dans plusieurs zones de disponibilité. Pensez à spécifier des sous-réseaux dans au moins deux zones de disponibilité lorsque vous créez le cluster.
Kubelet exécuté sur les nœuds ajoute automatiquement des étiquettes à l'objet du nœud, telles que. topology.kubernetes.io/region=us-west-2
Vous pouvez définir les sous-réseaux ou les zones de disponibilité lorsque vous créez des nœuds. Les nœuds sont placés dans des sous-réseaux du cluster si aucun sous-réseau n'est configuré. La prise en charge par EKS des groupes de nœuds gérés répartit automatiquement les nœuds sur plusieurs zones de disponibilité en fonction de la capacité disponible. Karpenter
Les AWS Elastic Load Balancers sont gérés par le contrôleur AWS Load Balancer pour un cluster Kubernetes. Il fournit un équilibreur de charge d'application (ALB) pour les ressources entrantes de Kubernetes et un équilibreur de charge réseau (NLB) pour les services Kubernetes de type Loadbalancer. Le contrôleur Elastic Load Balancer utilise des balises
Déploiement de nœuds sur des sous-réseaux privés
Un VPC comprenant des sous-réseaux privés et publics est la méthode idéale pour déployer des charges de travail Kubernetes sur EKS. Envisagez de définir au moins deux sous-réseaux publics et deux sous-réseaux privés dans deux zones de disponibilité distinctes. La table de routage associée d'un sous-réseau public contient une route vers une passerelle Internet. Les pods peuvent interagir avec Internet via une passerelle NAT. Les sous-réseaux privés sont pris en charge par des passerelles Internet de sortie uniquement dans l'environnement IPv6 (EIGW).
L'instanciation de nœuds dans des sous-réseaux privés offre un contrôle maximal du trafic vers les nœuds et est efficace pour la grande majorité des applications Kubernetes. Les ressources entrantes (comme les équilibreurs de charge) sont instanciées dans des sous-réseaux publics et acheminent le trafic vers des pods fonctionnant sur des sous-réseaux privés.
Envisagez le mode privé uniquement si vous exigez une sécurité et une isolation réseau strictes. Dans cette configuration, trois sous-réseaux privés sont déployés dans des zones de disponibilité distinctes au sein du VPC de la région AWS. Les ressources déployées sur les sous-réseaux ne peuvent pas accéder à Internet, pas plus qu'Internet ne peut accéder aux ressources des sous-réseaux. Pour que votre application Kubernetes puisse accéder à d'autres services AWS, vous devez configurer les points de terminaison des PrivateLink interfaces and/or et des passerelles. Vous pouvez configurer des équilibreurs de charge internes pour rediriger le trafic vers les pods à l'aide d'AWS Load Balancer Controller. Les sous-réseaux privés doivent être balisés (kubernetes.io/role/internal-elb: 1) pour que le contrôleur puisse provisionner des équilibreurs de charge. Pour que les nœuds puissent s'enregistrer auprès du cluster, le point de terminaison du cluster doit être configuré en mode privé. Veuillez consulter le guide des clusters privés pour connaître toutes les exigences et considérations.
Envisagez les modes public et privé pour Cluster Endpoint
Amazon EKS propose des modes de point de terminaison de cluster uniquement publics, publics et privés et privés uniquement. Le mode par défaut est public uniquement, mais nous vous recommandons de configurer le point de terminaison du cluster en mode public et privé. Cette option permet aux appels d'API Kubernetes au sein du VPC de votre cluster (tels que la communication node-plan de contrôle) d'utiliser le point de terminaison privé du VPC et le trafic de rester dans le VPC de votre cluster. En revanche, votre serveur API de cluster est accessible depuis Internet. Cependant, nous vous recommandons vivement de limiter les blocs CIDR qui peuvent utiliser le point de terminaison public. Apprenez à configurer l'accès aux terminaux publics et privés, notamment en limitant les blocs CIDR.
Nous vous suggérons d'utiliser un terminal exclusivement privé lorsque vous avez besoin de sécurité et d'isolation réseau. Nous vous recommandons d'utiliser l'une des options répertoriées dans le guide de l'utilisateur d'EKS pour vous connecter à un serveur API de manière privée.
Configurez les groupes de sécurité avec soin
Amazon EKS prend en charge l'utilisation de groupes de sécurité personnalisés. Tous les groupes de sécurité personnalisés doivent autoriser la communication entre les nœuds et le plan de contrôle Kubernetes. Vérifiez les exigences en matière de ports et configurez les règles manuellement lorsque votre organisation n'autorise pas les communications ouvertes.
EKS applique les groupes de sécurité personnalisés que vous fournissez lors de la création du cluster aux interfaces gérées (X-ENIs). Cependant, il ne les associe pas immédiatement à des nœuds. Lors de la création de groupes de nœuds, il est fortement recommandé d'associer
Nous vous recommandons vivement de créer un groupe de sécurité pour autoriser tout le trafic de communication inter-nœuds. Pendant le processus d'amorçage, les nœuds ont besoin d'une connectivité Internet sortante pour accéder au point de terminaison du cluster. Évaluez les exigences en matière d'accès sortant, telles que la connexion sur site et l'accès au registre des conteneurs, et définissez les règles de manière appropriée. Avant de mettre des modifications en production, nous vous recommandons vivement de vérifier attentivement les connexions dans votre environnement de développement.
Déployez des passerelles NAT dans chaque zone de disponibilité
Si vous déployez des nœuds dans des sous-réseaux privés (IPv4 et IPv6), envisagez de créer une passerelle NAT dans chaque zone de disponibilité (AZ) afin de garantir une architecture indépendante de la zone et de réduire les dépenses entre les zones de disponibilité. Chaque passerelle NAT d'une zone de disponibilité est implémentée avec redondance.
