Déployez des clusters privés avec un accès Internet limité

Votre cluster doit extraire des images d'un registre de conteneurs qui se trouve dans votre VPC. Vous pouvez créer un registre de conteneurs Amazon Elastic Container Registry dans votre VPC et y copier des images de conteneurs pour que vos nœuds puissent les extraire. Pour de plus amples informations, veuillez consulter Copier une image de conteneur d'un référentiel vers un autre référentiel.

Votre cluster doit avoir un accès privé au point de terminaison activé. Ceci est nécessaire pour que les nœuds s'enregistrent auprès du point de terminaison du cluster. L'accès public au point de terminaison est facultatif. Pour de plus amples informations, veuillez consulter Contrôlez l'accès réseau au point de terminaison du serveur API du cluster.

Les nœuds Linux et Windows autogérés doivent inclure les arguments bootstrap suivants avant d'être lancés. Ces arguments contournent l'introspection d'Amazon EKS et ne nécessitent pas d'accès à l'API Amazon EKS depuis le VPC.

Votre cluster aws-auth ConfigMap doit être créé depuis votre VPC. Pour plus d'informations sur la création et l'ajout d'entrées dans la ConfigMap aws-auth, entrez eksctl create iamidentitymapping --help dans votre terminal. S'il ConfigMap n'existe pas sur votre serveur, il le eksctl créera lorsque vous utiliserez la commande pour ajouter un mappage d'identité.

Les pods configurés avec des rôles IAM pour les comptes de service obtiennent des informations d'identification à partir d'un appel d'API du AWS Security Token Service (AWS STS). S'il n'y a pas d'accès Internet sortant, vous devez créer et utiliser un point de terminaison VPC AWS STS dans votre VPC. La plupart AWS v1 SDKs utilisent le point de terminaison AWS STS global par défaut (sts.amazonaws.com), qui n'utilise pas le point de terminaison VPC AWS STS. Pour utiliser le point de terminaison VPC AWS STS, vous devrez peut-être configurer votre SDK pour utiliser le point de terminaison AWS STS régional (). sts.region-code.amazonaws.com Pour de plus amples informations, veuillez consulter Configurer le point de terminaison du service AWS Security Token pour un compte de service.

Les sous-réseaux VPC de votre cluster doivent disposer d'un point de terminaison d'interface VPC pour tous les AWS services auxquels vos pods doivent accéder. Pour plus d'informations, consultez Accéder à un AWS service à l'aide d'un point de terminaison VPC d'interface. Certains services et points de terminaison couramment utilisés sont répertoriés dans le tableau suivant. Pour une liste complète des points de terminaison, consultez Services AWS qui s'intègrent à AWS PrivateLink dans le Guide AWS PrivateLink .

Nous vous recommandons d'activer les noms DNS privés pour vos points de terminaison VPC, afin que les charges de travail puissent continuer à utiliser les points de terminaison de AWS service public sans problème.

Tous les nœuds autogérés doivent être déployés sur des sous-réseaux qui disposent des points de terminaison de l'interface VPC dont vous avez besoin. Si vous créez un groupe de nœuds gérés, le groupe de sécurité des points de terminaison de l'interface VPC doit autoriser le CIDR pour les sous-réseaux, ou vous devez ajouter le groupe de sécurité des nœuds créé au groupe de sécurité des points de terminaison de l'interface VPC.

Si vos pods utilisent des volumes Amazon EFS, avant de déployer le système de fichiers Store an Elastic avec Amazon EFS, le fichier kustomization.yaml du pilote doit être modifié pour que les images du conteneur utilisent la AWS même région que le cluster Amazon EKS.

Route53 ne prend pas en charge. AWS PrivateLink Vous ne pouvez pas gérer les enregistrements DNS Route53 à partir d'un cluster Amazon EKS privé. Cela a un impact sur le DNS externe de Kubernetes.

Si vous utilisez l'AMI optimisée EKS, vous devez activer le ec2 point de terminaison dans le tableau ci-dessus. Vous pouvez également définir manuellement le nom DNS du nœud. L'AMI optimisée permet EC2 APIs de définir automatiquement le nom DNS du nœud.

Vous pouvez utiliser le AWS Load Balancer Controller pour déployer des équilibreurs de charge AWS d'application (ALB) et des équilibreurs de charge réseau sur votre cluster privé. Lors de son déploiement, vous devez utiliser les indicateurs de ligne de commande pour définir enable-shield, enable-waf et enable-wafv2 sur false. La découverte de certificats à l'aide de noms d'hôtes provenant d'objets Ingress n'est pas prise en charge. Cela est dû au fait que le contrôleur doit atteindre AWS Certificate Manager, qui ne possède pas de point de terminaison d'interface VPC.

Le contrôleur prend en charge les Network Load Balancers avec des cibles IP, qui sont nécessaires pour une utilisation avec Fargate. Pour plus d’informations, consultez Acheminez le trafic d'applications et le trafic HTTP avec des équilibreurs de charge d'application et Créer un équilibreur de charge de réseau.

Cluster Autoscaler est pris en charge. Lorsque vous déployez des pods Cluster Autoscaler, assurez-vous que la ligne de commande inclut. --aws-use-static-instance-list=true Pour plus d'informations, consultez la section Utiliser une liste d'instances statiques sur GitHub. Le VPC du nœud de travail doit également inclure le point de terminaison VPC STS et le point de AWS terminaison VPC à mise à l'échelle automatique.

Certains logiciels de conteneur utilisent des appels d'API qui accèdent au AWS Marketplace Metering Service pour surveiller l'utilisation. Les clusters privés n'autorisent pas ces appels. Vous ne pouvez donc pas utiliser ces types de conteneurs dans des clusters privés.