**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.
# Déployer des clusters privés avec un accès Internet limité
Cette rubrique décrit comment déployer un cluster Amazon EKS déployé sur le AWS cloud, mais ne disposant pas d'un accès Internet sortant. Si vous avez un cluster local sur AWS Outposts, consultez[Créez des nœuds Amazon Linux sur AWS Outposts](eks-outposts-self-managed-nodes.md), au lieu de cette rubrique.
Si vous n’êtes pas familier avec la mise en réseau Amazon EKS, consultez [Démystifier la mise en réseau des clusters pour les composants master Amazon EKS](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Si votre cluster ne dispose pas d’un accès Internet sortant, il doit répondre aux exigences suivantes :
## Exigences en matière d’architecture de cluster
+ Votre cluster doit extraire les images d’un registre de conteneurs situé 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](copy-image-to-repository.md).
+ 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 [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md).
## Exigences relatives aux nœuds
+ Les nœuds Linux et Windows autogérés doivent inclure les arguments de démarrage suivants avant leur lancement. Ces arguments contournent l’introspection Amazon EKS et ne nécessitent pas d’accès à l’API Amazon EKS depuis le VPC.
1. Déterminez la valeur du point de terminaison de votre cluster à l’aide de la commande suivante. Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
L'exemple qui suit illustre un résultat.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. Déterminez la valeur de l’autorité de certification de votre cluster à l’aide de la commande suivante. Remplacez *my-cluster* par le nom de votre cluster.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
La sortie renvoyée est une longue chaîne.
1. Remplacez les valeurs de `apiServerEndpoint` et contenues `certificateAuthority` dans l' NodeConfig objet par les valeurs renvoyées dans le résultat des commandes précédentes. Pour plus d'informations sur la spécification des arguments bootstrap lors du lancement de nœuds Amazon Linux 2023 autogérés, consultez [Créer des nœuds Amazon Linux autogérés](launch-workers.md) et. [Créer des nœuds Microsoft Windows autogérés](launch-windows-workers.md)
+ Pour les nœuds Linux :
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
Pour des arguments supplémentaires, consultez le [script bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) sur GitHub.
+ Pour les nœuds Windows :
**Note**
Si vous utilisez un CIDR de service personnalisé, vous devez le spécifier à l’aide du paramètre `-ServiceCIDR`. Sinon, la résolution DNS pour les pods dans le cluster échouera.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Pour des arguments supplémentaires, consultez [Paramètres de configuration du script d'amorçage](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ Le `aws-auth` `ConfigMap` de votre cluster doit être créé à partir de 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. Si le `ConfigMap` n’existe pas sur votre serveur, `eksctl` le créera lorsque vous utiliserez la commande pour ajouter un mappage d’identité.
## Exigences relatives aux pods
+ **Identité du pod** : les pods configurés avec l’identité du pod EKS obtiennent leurs informations d’identification à partir de l’API EKS Auth. S’il n’y a pas d’accès Internet sortant, vous devez créer et utiliser un point de terminaison d’un VPC pour l’API EKS Auth : `com.amazonaws.region-code.eks-auth`. Pour plus d’informations sur les points de terminaison d’un VPC EKS et EKS Auth, consultez [Accéder à Amazon EKS à l’aide d’AWS PrivateLink](vpc-interface-endpoints.md).
+ **IRSA** - Les pods configurés avec des [rôles IAM pour les comptes de service obtiennent des](iam-roles-for-service-accounts.md) 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 de jetons de sécurité AWS pour un compte de service](configure-sts-endpoint.md).
+ 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](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). 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](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) dans le [Guide AWS PrivateLink ](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Nous vous recommandons d'[activer les noms DNS privés](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) 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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/private-clusters.html)
+ 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.
+ **Stockage EFS** : si vos pods utilisent des volumes Amazon EFS, avant de déployer le [système de fichiers élastique Store avec Amazon EFS, le fichier](efs-csi.md) [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/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és. Cela a un impact sur Kubernetes [external-dns](https://github.com/kubernetes-sigs/external-dns).
+ Si vous utilisez l’AMI optimisée EKS, vous devez activer le point de terminaison `ec2` 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](aws-load-balancer-controller.md) 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](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) pour définir `enable-shield`, `enable-waf` et `enable-wafv2` sur false. La [détection de certificats](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) avec des noms d’hôte 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 [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md) et [Créer un équilibreur de charge de réseau](network-load-balancing.md#network-load-balancer).
+ [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) est pris en charge. Lors du déploiement de 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](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list) 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 les clusters privés.