Cluster entièrement privé EKS

eksctl prend en charge la création de clusters entièrement privés qui n'ont aucun accès Internet sortant et ne disposant que de sous-réseaux privés. Les points de terminaison VPC sont utilisés pour permettre un accès privé aux services AWS.

Ce guide explique comment créer un cluster privé sans accès Internet sortant.

Création d'un cluster entièrement privé

Le seul champ obligatoire pour créer un cluster entièrement privé est privateCluster.enabled le suivant :

privateCluster:
  enabled: true

Après la création du cluster, les commandes eksctl nécessitant un accès au serveur d'API Kubernetes devront être exécutées depuis le VPC du cluster, un VPC pair ou en utilisant un autre moyen tel qu'AWS Direct Connect. Les commandes eksctl nécessitant un accès à l'EKS APIs ne fonctionneront pas si elles sont exécutées depuis le VPC du cluster. Pour résoudre ce problème, créez un point de terminaison d'interface permettant à Amazon EKS d'accéder de manière privée à la gestion d'Amazon Elastic Kubernetes Service (Amazon EKS APIs ) depuis votre Amazon Virtual Private Cloud (VPC). Dans une future version, eksctl ajoutera un support pour créer ce point de terminaison afin qu'il n'ait pas besoin d'être créé manuellement. Les commandes nécessitant un accès à l'URL du fournisseur OpenID Connect devront être exécutées en dehors du VPC de votre cluster une fois que vous aurez activé AWS pour PrivateLink Amazon EKS.

La création de groupes de nœuds gérés continuera de fonctionner, et la création de groupes de nœuds autogérés fonctionnera car elle nécessite un accès au serveur d'API via le point de terminaison de l'interface EKS si la commande est exécutée depuis le VPC du cluster, un VPC pair ou en utilisant un autre moyen tel qu'AWS Direct Connect.

Note

Les terminaux VPC sont facturés à l'heure et en fonction de l'utilisation. Vous trouverez de plus amples informations sur les tarifs sur la page PrivateLink des tarifs AWS

Avertissement

Les clusters entièrement privés ne sont pas pris en charge dans. eu-south-1

Configuration de l'accès privé à des services AWS supplémentaires

Pour permettre aux nœuds de travail d'accéder aux services AWS en privé, eksctl crée des points de terminaison VPC pour les services suivants :

• Points de terminaison d'interface pour l'ECR (à la fois ecr.apiecr.dkr) afin d'extraire des images de conteneurs (plugin AWS CNI, etc.)

• Un point de terminaison passerelle permettant à S3 d'extraire les couches d'image réelles

• Un point de terminaison d'interface EC2 requis par l'aws-cloud-providerintégration

• Un point de terminaison d'interface permettant à STS de prendre en charge les rôles Fargate et IAM pour les comptes de services (IRSA)

• Un point de terminaison d'interface pour CloudWatch logging (logs) si la CloudWatch journalisation est activée

Ces points de terminaison VPC sont essentiels pour un cluster privé fonctionnel et, par conséquent, eksctl ne prend pas en charge leur configuration ou leur désactivation. Cependant, un cluster peut avoir besoin d'un accès privé à d'autres services AWS (par exemple, Autoscaling requis par le Cluster Autoscaler). Ces services peuvent être spécifiés dansprivateCluster.additionalEndpointServices, qui indique à eksctl de créer un point de terminaison VPC pour chacun d'entre eux.

Par exemple, pour autoriser un accès privé à Autoscaling et à la CloudWatch journalisation :

privateCluster:
  enabled: true
  additionalEndpointServices:
  # For Cluster Autoscaler
  - "autoscaling"
  # CloudWatch logging
  - "logs"

Les points de terminaison pris en charge dans additionalEndpointServices sontautoscaling, cloudformation et. logs

Ignorer les créations de terminaux

Si un VPC a déjà été créé avec les points de terminaison AWS nécessaires configurés et liés aux sous-réseaux décrits dans la documentation EKS, eksctl vous pouvez ignorer leur création en fournissant l'option suivante : skipEndpointCreation

privateCluster:
  enabled: true
  skipEndpointCreation: true

Ce paramètre ne peut pas être utilisé conjointement avecadditionalEndpointServices. Il ignorera toute création de point de terminaison. En outre, ce paramètre n'est recommandé que si la topologie du <→ sous-réseau du point de terminaison est correctement configurée. Si les identifiants de sous-réseau sont corrects, le vpce routage est configuré avec des adresses préfixes, tous les points de terminaison EKS nécessaires sont créés et liés au VPC fourni. eksctlne modifiera aucune de ces ressources.

Groupes de nœuds

Seuls les groupes de nœuds privés (gérés et autogérés) sont pris en charge dans un cluster entièrement privé, car le VPC du cluster est créé sans aucun sous-réseau public. Le privateNetworking champ (nodeGroup[].privateNetworking etmanagedNodeGroup[) doit être défini de manière explicite. Le fait de ne privateNetworking pas définir cette option dans un cluster entièrement privé constitue une erreur.

nodeGroups:
- name: ng1
  instanceType: m5.large
  desiredCapacity: 2
  # privateNetworking must be explicitly set for a fully-private cluster
  # Rather than defaulting this field to `true`,
  # we require users to explicitly set it to make the behaviour
  # explicit and avoid confusion.
  privateNetworking: true

managedNodeGroups:
- name: m1
  instanceType: m5.large
  desiredCapacity: 2
  privateNetworking: true

Accès au point de terminaison de cluster

Un cluster entièrement privé ne prend pas en charge les modifications clusterEndpointAccess lors de la création du cluster. Il s'agit d'une erreur lorsque vous définissez l'une clusterEndpoints.publicAccess ou l'autreclusterEndpoints.privateAccess, car un cluster entièrement privé ne peut avoir qu'un accès privé, et autoriser la modification de ces champs peut entraîner la rupture du cluster.

VPC et sous-réseaux fournis par l'utilisateur

eksctl prend en charge la création de clusters entièrement privés à l'aide d'un VPC et de sous-réseaux préexistants. Seuls les sous-réseaux privés peuvent être spécifiés et c'est une erreur de spécifier des sous-réseaux sous. vpc.subnets.public

eksctl crée des points de terminaison VPC dans le VPC fourni et modifie les tables de routage pour les sous-réseaux fournis. Chaque sous-réseau doit être associé à une table de routage explicite car eksctl ne modifie pas la table de routage principale.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: private-cluster
  region: us-west-2

privateCluster:
  enabled: true
  additionalEndpointServices:
  - "autoscaling"

vpc:
  subnets:
    private:
      us-west-2b:
        id: subnet-0818beec303f8419b
      us-west-2c:
        id: subnet-0d42ef09490805e2a
      us-west-2d:
        id: subnet-0da7418077077c5f9


nodeGroups:
- name: ng1
  instanceType: m5.large
  desiredCapacity: 2
  # privateNetworking must be explicitly set for a fully-private cluster
  # Rather than defaulting this field to true for a fully-private cluster, we require users to explicitly set it
  # to make the behaviour explicit and avoid confusion.
  privateNetworking: true

managedNodeGroups:
- name: m1
  instanceType: m5.large
  desiredCapacity: 2
  privateNetworking: true

Gestion d'un cluster entièrement privé

Pour que toutes les commandes fonctionnent après la création du cluster, eksctl aura besoin d'un accès privé au point de terminaison du serveur API EKS et d'un accès Internet sortant (pour). EKS:DescribeCluster Les commandes qui ne nécessitent pas d'accès au serveur API seront prises en charge si eksctl dispose d'un accès Internet sortant.

Supprimer de force un cluster entièrement privé

Des erreurs sont susceptibles de se produire lors de la suppression d'un cluster entièrement privé via eksctl, car eksctl n'a pas automatiquement accès à toutes les ressources du cluster. --forceexiste pour résoudre ce problème : cela forcera la suppression du cluster et continuera en cas d'erreur.

Limites

L'une des limites de l'implémentation actuelle est qu'eksctl crée initialement le cluster avec l'accès aux points de terminaison publics et privés activé, et désactive l'accès aux points de terminaison publics une fois toutes les opérations terminées. Cela est nécessaire car eksctl a besoin d'accéder au serveur d'API Kubernetes pour permettre aux nœuds autogérés de rejoindre le cluster et de prendre en charge et Fargate. GitOps Une fois ces opérations terminées, eksctl fait passer l'accès du point de terminaison du cluster à un accès privé uniquement. Cette mise à jour supplémentaire signifie que la création d'un cluster entièrement privé prendra plus de temps que pour un cluster standard. À l'avenir, eksctl pourrait passer à une fonction Lambda compatible VPC pour effectuer ces opérations d'API.

Accès sortant via des serveurs proxy HTTP

eksctl est capable de communiquer avec l'AWS APIs via un serveur proxy HTTP (S) configuré, mais vous devez vous assurer que vous avez correctement défini votre liste d'exclusion de proxy.

En règle générale, vous devez vous assurer que les demandes relatives au point de terminaison VPC de votre cluster ne sont pas acheminées via vos proxys en définissant une variable d'no_proxyenvironnement appropriée incluant la valeur. .eks.amazonaws.com

Si votre serveur proxy effectue une « interception SSL » et que vous utilisez des rôles IAM pour les comptes de service (IRSA), vous devez vous assurer de contourner explicitement le protocole SSL Man-in-the-Middle pour le domaine. oidc.<region>.amazonaws.com Dans le cas contraire, eksctl obtiendra l'empreinte numérique du certificat racine incorrecte pour le fournisseur OIDC, et le plug-in AWS VPC CNI ne démarrera pas car il ne pourra pas obtenir les informations d'identification IAM, ce qui rendra votre cluster inopérant.

Plus d'informations

• Clusters privés EKS