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.
VPCConsidérations relatives aux sous-réseaux
L'exploitation d'un EKS cluster nécessite des connaissances en AWS VPC réseau, en plus de la mise en réseau Kubernetes.
Nous vous recommandons de comprendre les mécanismes de communication du plan de EKS contrôle avant de commencer à concevoir vos clusters VPC ou à les déployer dans des clusters existantsVPCs.
Reportez-vous aux VPCconsidérations relatives au cluster et aux considérations relatives au groupe de EKS sécurité Amazon lors de l'architecture d'un VPC et de sous-réseaux à utiliser avec. EKS
Présentation
EKSArchitecture de cluster
Un EKS cluster est composé de deux VPCs :
-
Un AWS -managed VPC qui héberge le plan de contrôle Kubernetes. Cela VPC n'apparaît pas dans le compte client.
-
Un serveur géré par le client VPC qui héberge les nœuds Kubernetes. C'est là que s'exécutent les conteneurs, ainsi que d'autres AWS infrastructures gérées par le client, telles que les équilibreurs de charge utilisés par le cluster. Cela VPC apparaît dans le compte client. Vous devez créer un cluster géré par le client VPC avant de créer un cluster. Le eksctl crée un VPC si vous n'en fournissez pas un.
Les nœuds du client VPC doivent pouvoir se connecter au point de terminaison API du serveur géré dans le AWSVPC. Cela permet aux nœuds de s'enregistrer auprès du plan de contrôle Kubernetes et de recevoir des demandes pour exécuter des pods d'applications.
Les nœuds se connectent au plan de EKS contrôle via (a) un point de terminaison EKS public ou (b) une interface réseau élastique inter-comptes (X-ENI) gérée parEKS. Lorsqu'un cluster est créé, vous devez spécifier au moins deux VPC sous-réseaux. EKSplace 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 API serveur Kubernetes utilise ces comptes croisés ENIs pour communiquer avec les nœuds déployés sur les sous-réseaux de clusters gérés par le client. VPC
Au démarrage du nœud, le script EKS bootstrap 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 point de terminaison, VPC soit avec le point de terminaison privé au sein duVPC. Kubelet reçoit des API instructions et fournit régulièrement des mises à jour de statut et des pulsations cardiaques au terminal.
EKSCommunication par plan de contrôle
EKSdispose de deux méthodes pour contrôler l'accès au point de terminaison du cluster. Le contrôle d'accès au point de terminaison vous permet de choisir si le point de terminaison est accessible depuis l'Internet public ou uniquement via votreVPC. Vous pouvez activer le point de terminaison public (qui est le point de terminaison par défaut), le point de terminaison privé ou les deux à la fois.
La configuration du point de API terminaison 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 EKS console ouAPI.
Point de terminaison public
Il s'agit du comportement par défaut pour les nouveaux EKS clusters Amazon. Lorsque seul le point de terminaison public du cluster est activé, les API requêtes Kubernetes provenant de votre cluster VPC (telles que la communication entre le nœud de travail et le plan de contrôle) quittent le réseauVPC, mais pas celui d'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 NAT passerelle où ils peuvent utiliser l'adresse IP publique de la NAT passerelle.
Point de terminaison public et privé
Lorsque les points de terminaison publics et privés sont activés, les API requêtes Kubernetes de l'intérieur VPC communiquent avec le plan de contrôle via le X- dans votre. ENIs VPC Votre API serveur de cluster est accessible depuis Internet.
Point de terminaison privé
Il n'y a pas d'accès public à votre API serveur depuis Internet lorsque seul un point de terminaison privé est activé. Tout le trafic vers votre API serveur de cluster doit provenir du réseau de votre cluster VPC ou d'un réseau connecté. Les nœuds communiquent avec le API serveur via X- ENIs au sein de votreVPC. Notez que les outils de gestion de cluster doivent avoir accès au point de terminaison privé. Découvrez comment vous connecter à un point de terminaison de EKS cluster Amazon privé depuis l'extérieur d'AmazonVPC.
Notez que le point de terminaison du API serveur du cluster est résolu par DNS les serveurs publics en une adresse IP privée provenant duVPC. Dans le passé, le point final ne pouvait être résolu que depuis leVPC.
VPCconfigurations
Amazon VPC prend en charge IPv4 et IPv6 adresse. Amazon EKS prend en charge IPv4 par défaut. A VPC doit être associé à un IPv4 CIDR bloc. Vous pouvez éventuellement associer plusieurs blocs de routage interdomaines IPv4 sans classe/16 préfixe (65 536 adresses IP) et un /28 préfixe (16 adresses IP).
Lors de la création d'un nouveau blocVPC, vous pouvez joindre un seul IPv6 CIDR bloc, et jusqu'à cinq lorsque vous modifiez un bloc existantVPC. La longueur du préfixe de la taille du IPv6 CIDR bloc peut être comprise entre /44 et /60 et pour les IPv6 sous-réseaux, elle peut être comprise entre /44/ et /64. Vous pouvez demander un IPv6 CIDR blocage à partir du pool d'IPv6adresses géré par Amazon. Reportez-vous à la section consacrée aux VPCCIDRblocs du guide de VPC l'utilisateur pour plus d'informations.
EKSLes clusters Amazon prennent en charge les deux IPv4 etIPv6. Par défaut, les EKS clusters utilisent l'IPv4adresse IP. La spécification IPv6 au moment de la création du cluster permettra d'utiliser les IPv6 clusters. IPv6les clusters nécessitent une double pile VPCs et des sous-réseaux.
Amazon vous EKS recommande d'utiliser au moins deux sous-réseaux situés dans des zones de disponibilité différentes lors de la création du cluster. Les sous-réseaux que vous transmettez lors de la création du cluster sont appelés sous-réseaux du cluster. Lorsque vous créez un cluster, Amazon EKS crée jusqu'à 4 comptes croisés (x ou x-ENIs) ENIs dans les sous-réseaux que vous spécifiez. Les x- ENIs sont toujours déployés et sont utilisés pour le trafic d'administration du cluster tel que la livraison des journaux, l'exécution et le proxy. Reportez-vous au guide de l'EKSutilisateur pour obtenir des informations complètes VPCet sur les exigences relatives aux sous-réseaux.
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, EKS Amazon fournit des ENIs ressources supplémentaires dans les sous-réseaux du cluster. Lorsque votre cluster prend de l'ampleur, les nœuds de travail et les pods peuvent consommer le contenu disponible IPs dans le sous-réseau du cluster. Par conséquent, afin de vous assurer qu'il y en a suffisamment, IPs vous pouvez envisager d'utiliser des sous-réseaux de cluster dédiés avec le masque de réseau /28.
Les nœuds de travail Kubernetes peuvent s'exécuter dans un sous-réseau public ou privé. Le caractère public ou privé d'un sous-réseau 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 provenant des nœuds et quittant le réseau est appelé « sortie ». Les nœuds dotés d'adresses IP publiques ou élastiques (EIPs) 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 NATpasserelle, qui empêche le trafic entrant vers les nœuds des sous-réseaux depuis l'extérieur VPC tout en permettant au trafic provenant des nœuds de quitter le VPC (sortie).
Dans le IPv6 monde, chaque adresse est routable sur Internet. Les IPv6 adresses 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 unVPC, autorisant le trafic sortant tout en bloquant tout le trafic entrant. Les meilleures pratiques pour implémenter IPv6 des sous-réseaux sont disponibles dans le guide de l'VPCutilisateur.
Vous pouvez configurer VPC 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 (telles que les équilibreurs de charge) sont créés. Ajoutez une balise au sous-réseau public kubernetes.io/role/elb
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 NAT passerelle ou leENI.
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
Communication à travers VPCs
Il existe de nombreux scénarios dans lesquels vous avez besoin VPCs de déployer plusieurs EKS clusters distincts sur ces clustersVPCs.
Vous pouvez utiliser Amazon VPC Lattice
Amazon VPC Lattice fonctionne dans l'espace d'adressage lien-local dans IPv4 etIPv6, fournissant une connectivité entre les services dont les adresses peuvent se chevaucher. IPv4 Pour des raisons d'efficacité opérationnelle, nous recommandons vivement de déployer des EKS clusters et des nœuds sur des plages d'adresses IP qui ne se chevauchent pas. Si votre infrastructure comprend des plages VPCs d'adresses IP qui se chevauchent, vous devez concevoir votre réseau en conséquence. Nous suggérons une NAT passerelle privée ou un mode réseau personnalisé VPC CNI en conjonction avec une passerelle de transit pour intégrer les charges de travail afin de résoudre les problèmes EKS de chevauchement tout en préservant CIDR les adresses IP routablesRFC1918.
Envisagez de l'utiliser AWS PrivateLink, également connu sous le nom de service de point de terminaison, si vous êtes le fournisseur de services et souhaitez partager votre service Kubernetes et votre entrée (ALBsoitNLB) avec votre client VPC sur des comptes distincts.
Partage VPC entre plusieurs comptes
De nombreuses entreprises ont adopté Amazon partagé VPCs afin de rationaliser l'administration du réseau, de réduire les coûts et d'améliorer la sécurité de plusieurs AWS comptes au AWS sein d'une organisation. Ils utilisent AWS Resource Access Manager (RAM) pour partager en toute sécurité les AWSressources prises en charge avec des AWS comptes individuels, des unités organisationnelles (OUs) ou AWS l'ensemble de l'organisation.
Vous pouvez déployer des EKS clusters Amazon, des groupes de nœuds gérés et d'autres AWS ressources de support (telles que des groupes de sécurité LoadBalancers, des points de terminaison, etc.) dans des VPC sous-réseaux partagés à partir d'un autre AWS compte en utilisant AWSRAM. La figure ci-dessous illustre un exemple d'architecture de haut niveau. Cela permet aux équipes réseau centrales de contrôler les structures réseau telles que les sous-réseauxVPCs, etc., tout en permettant aux équipes chargées des applications ou des plateformes de déployer des EKS clusters Amazon dans leurs comptes respectifsAWS. Une présentation complète de ce scénario est disponible dans ce dépôt github
Considérations relatives à l'utilisation de sous-réseaux partagés
-
EKSLes clusters Amazon et les nœuds de travail peuvent être créés au sein de sous-réseaux partagés faisant tous partie d'un même VPC réseau. Amazon EKS ne prend pas en charge la création de clusters sur plusieursVPCs.
-
Amazon EKS utilise des groupes AWS VPC de sécurité (SGs) 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 VPC ressources et les adresses IP externes. Vous devez créer ces groupes de sécurité dans le compte de l'application ou du participant. Assurez-vous que les groupes de sécurité que vous avez l'intention d'utiliser pour vos modules 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é afin d'autoriser le trafic nécessaire à destination et en provenance des groupes de sécurité situés dans le compte CentralVPC.
-
Créez IAM des rôles et des politiques associées dans le compte de participant sur lequel réside votre EKS cluster Amazon. Ces IAM rôles et politiques sont essentiels pour accorder les autorisations nécessaires aux clusters Kubernetes gérés par AmazonEKS, ainsi qu'aux nœuds et aux pods exécutés sur Fargate. Les autorisations permettent EKS à Amazon de passer des appels vers d'autres AWS services en votre nom.
-
Vous pouvez suivre les approches suivantes pour autoriser l'accès entre comptes à AWS des ressources telles que les compartiments Amazon S3, les tables Dynamodb, etc., à partir des pods k8s :
-
Approche politique basée sur les ressources : si le AWS service prend en charge les politiques de ressources, vous pouvez ajouter une politique basée sur les ressources appropriée pour autoriser l'accès entre comptes aux IAM rôles assignés aux pods Kubernetes. Dans ce scénario, le OIDC fournisseur, IAM les rôles et les politiques d'autorisation existent dans le compte de l'application. Pour trouver les AWS services qui prennent en charge les politiques basées sur les ressources, consultez les AWSservices qui fonctionnent avec IAM et recherchez les services dont la valeur est « Oui » dans la colonne « Basé sur les ressources ».
-
OIDCApproche du fournisseur : IAM des ressources telles que le OIDC fournisseur, IAM les rôles, les autorisations et les politiques de confiance seront créées dans le AWS compte d'un autre participant où 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 entre comptes. Consultez le blog sur IAM les rôles entre comptes 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) (ALBouNLB) pour acheminer le trafic vers les pods k8s, que ce soit via des applications ou des comptes réseau centraux. Reportez-vous à la procédure pas à pas d'Expose Amazon EKS Pods Through Cross-Account Load
Balancer pour obtenir des instructions détaillées sur ELB le déploiement des ressources dans un compte réseau central. Cette option offre une flexibilité accrue, car elle permet au compte Central Networking de contrôler totalement la configuration de sécurité des ressources Load Balancer. -
Lorsque vous utilisez
custom networking featureAmazon VPCCNI, vous devez utiliser les mappages d'ID de zone de disponibilité (AZ) répertoriés dans le compte réseau central pour créer chacunENIConfigd'eux. Cela est dû au mappage aléatoire des noms physiques AZs et des noms AZ dans chaque AWS compte.
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. EKSassocie ces groupes de sécurité aux nœuds gérés ENIs 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 définir 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
Envisagez un déploiement multi-AZ
AWSLes régions fournissent plusieurs zones de disponibilité (AZ) physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications qui basculent automatiquement entre les zones de disponibilité sans interruption. Amazon recommande EKS vivement de déployer EKS des clusters 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 de clusters si aucun sous-réseau n'est configuré. EKSla prise en charge 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 respectera
AWSLes Elastic Load Balancers sont gérés par le AWS Load Balancer Controller pour un cluster Kubernetes. Il fournit un Application Load Balancer (ALB) pour les ressources d'entrée de Kubernetes et un Network Load Balancer (NLB) pour les services Kubernetes de type Loadbalancer. Le contrôleur Elastic Load Balancer utilise des balises
Déployer des nœuds sur des sous-réseaux privés
L'inclusion VPC de 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 NAT passerelle. Les sous-réseaux privés sont pris en charge par les 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 d'entrée (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é stricte et une isolation du réseau. Dans cette configuration, trois sous-réseaux privés sont déployés dans des zones de disponibilité distinctes au sein de VPC la AWS région. 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 AWS services, vous devez configurer des PrivateLink interfaces et/ou des points de terminaison de passerelle. Vous pouvez configurer des équilibreurs de charge internes pour rediriger le trafic vers les pods à l'aide du AWS Load Balancer Controller. Les sous-réseaux privés doivent être marqués (kubernetes.io/role/internal-elb: 1
Envisagez le mode public et privé pour le point de terminaison du cluster
Amazon EKS propose des modes de point de public-and-private terminaison de cluster uniquement publics 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 API appels Kubernetes au sein de votre cluster VPC (tels que les node-to-control-plane communications) d'utiliser le point de VPC terminaison privé et le trafic pour rester dans ceux de votre cluster. VPC Votre API serveur de cluster, quant à lui, est accessible depuis Internet. Cependant, nous vous recommandons vivement de limiter les CIDR blocs pouvant utiliser le point de terminaison public. Découvrez comment configurer l'accès public et privé aux terminaux, notamment en limitant les CIDR blocages.
Nous vous suggérons d'utiliser un point de terminaison privé uniquement lorsque vous avez besoin de sécurité et d'isolation du réseau. Nous vous recommandons d'utiliser l'une des options répertoriées dans le guide de EKS l'utilisateur pour vous connecter à un API serveur en privé.
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.
EKSapplique 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 aux nœuds. Lors de la création de groupes de nœuds, il est vivement recommandé d'associer manuellement des groupes de sécurité personnalisés
Nous vous recommandons vivement de créer un groupe de sécurité pour autoriser tout le trafic de communication entre 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 des règles appropriées. Avant de mettre les modifications en production, nous vous conseillons vivement de vérifier soigneusement les connexions dans votre environnement de développement.
Déployez NAT des passerelles dans chaque zone de disponibilité
Si vous déployez des nœuds dans des sous-réseaux privés (IPv4etIPv6), envisagez de créer une NAT passerelle dans chaque zone de disponibilité (AZ) afin de garantir une architecture indépendante des zones et de réduire les dépenses entre les zones de disponibilité. Chaque NAT passerelle d'un AZ est mise en œuvre de manière redondante.
Utiliser Cloud9 pour accéder à des clusters privés
AWSCloud9 est un site Web IDE qui peut fonctionner en toute sécurité dans des sous-réseaux privés sans accès d'entrée, à l'aide de Systems Manager. AWS La sortie peut également être désactivée sur l'instance Cloud9. En savoir plus sur l'utilisation de Cloud9 pour accéder à des clusters et sous-réseaux privés.
📝 Modifiez cette page sur GitHub
