Nœuds hybrides EKS

Introduction

AWS EKS introduit les nœuds hybrides, une nouvelle fonctionnalité qui vous permet d'exécuter des applications sur site et de périphérie sur une infrastructure gérée par le client avec les mêmes clusters, fonctionnalités et outils AWS EKS que ceux que vous utilisez dans le cloud AWS. AWS EKS Hybird Nodes apporte une expérience Kubernetes gérée par AWS aux environnements sur site afin que les clients simplifient et normalisent la façon dont vous exécutez les applications dans les environnements sur site, de périphérie et cloud. En savoir plus sur EKS Hybrid Nodes.

Pour faciliter le support de cette fonctionnalité, eksctl introduit un nouveau champ de premier niveau appelé. remoteNetworkConfig Toute configuration liée aux nœuds hybrides doit être configurée via ce champ, dans le cadre du fichier de configuration ; il n'existe aucun équivalent en termes d'indicateurs CLI. De plus, au lancement, toute configuration de réseau distant ne peut être configurée que lors de la création du cluster et ne peut pas être mise à jour par la suite. Cela signifie que vous ne pourrez pas mettre à jour les clusters existants pour utiliser des nœuds hybrides.

La remoteNetworkConfig section du fichier de configuration vous permet de configurer les deux domaines principaux lorsqu'il s'agit de joindre des nœuds distants à vos clusters EKS : le réseau et les informations d'identification.

Réseaux

EKS Hybrid Nodes s'adapte à votre méthode préférée pour connecter votre ou vos réseaux sur site à un VPC AWS. Plusieurs options documentées sont disponibles, notamment AWS Site-to-Site VPN et AWS Direct Connect, et vous pouvez choisir la méthode la mieux adaptée à votre cas d'utilisation. Dans la plupart des méthodes que vous pouvez choisir, votre VPC sera attaché à une passerelle privée virtuelle (VGW) ou à une passerelle de transit (TGW). Si vous comptez sur eksctl pour créer un VPC pour vous, eksctl configurera également, dans le cadre de votre VPC, tous les prérequis liés au réseau afin de faciliter la communication entre votre plan de contrôle EKS et les nœuds distants, c'est-à-dire

• règles SG d'entrée/de sortie

• routes dans les tables de routage des sous-réseaux privés

• l'attachement de la passerelle VPC au TGW ou VGW donné

Exemple de fichier de configuration :

remoteNetworkConfig:
  vpcGatewayID: tgw-xxxx # either VGW or TGW to be attached to your VPC
  remoteNodeNetworks:
    # eksctl will create, behind the scenes, SG rules, routes, and a VPC gateway attachment,
    # to facilitate communication between remote network(s) and EKS control plane, via the attached gateway
    - cidrs: ["10.80.146.0/24"]
  remotePodNetworks:
    - cidrs: ["10.86.30.0/23"]

Si la méthode de connectivité que vous avez choisie n'implique pas l'utilisation d'un TGW ou d'un VGW, vous ne devez pas vous fier à eksctl pour créer le VPC à votre place, mais en fournir un préexistant. Dans le même ordre d'idées, si vous utilisez un VPC préexistant, eksctl n'y apportera aucune modification, et il est de votre responsabilité de vous assurer que toutes les exigences réseau sont en place.

Note

eksctl ne configure aucune infrastructure réseau en dehors de votre VPC AWS (c'est-à-dire aucune infrastructure depuis VGW/TGW les réseaux distants)

Informations d’identification

Les nœuds hybrides EKS utilisent l'authenticator AWS IAM et les informations d'identification IAM temporaires fournies par AWS SSM ou AWS IAM Roles Anywhere pour s'authentifier auprès du cluster EKS. Semblable aux groupes de nœuds autogérés, eksctl créera pour vous un rôle IAM de nœuds hybrides à assumer par les nœuds distants, sauf indication contraire. De plus, lorsque vous utilisez IAM Roles Anywhere comme fournisseur d'informations d'identification, eksctl configurera un profil et une ancre de confiance en fonction d'un ensemble d'autorités de certification donné (), par exemple iam.caBundleCert

remoteNetworkConfig:
  iam:
    # the provider for temporary IAM credentials. Default is SSM.
    provider: IRA
    # the certificate authority bundle that serves as the root of trust,
    # used to validate the X.509 certificates provided by your nodes.
    # can only be set when provider is IAMRolesAnywhere.
    caBundleCert: xxxx

L'ARN du rôle de nœuds hybrides créé par eksctl est nécessaire plus tard dans le processus de connexion de vos nœuds distants au cluster, pour la configuration et NodeConfig pour nodeadm la création d'activations (si vous utilisez SSM). Pour le récupérer, utilisez :

aws cloudformation describe-stacks \
  --stack-name eksctl-<CLUSTER_NAME>-cluster \
  --query 'Stacks[].Outputs[?OutputKey==`RemoteNodesRoleARN`].[OutputValue]' \
  --output text

De même, si vous utilisez IAM Roles Anywhere, vous pouvez récupérer l'ARN de l'ancre de confiance et du profil anywhere créés par eksctl, en modifiant la commande précédente en la RemoteNodesRoleARN remplaçant RemoteNodesTrustAnchorARN par ou, respectivement. RemoteNodesAnywhereProfileARN

Si vous disposez d'une configuration IAM Roles Anywhere préexistante ou si vous utilisez SSM, vous pouvez fournir un rôle IAM pour les nœuds hybrides via. remoteNetworkConfig.iam.roleARN N'oubliez pas que dans ce scénario, eksctl ne créera pas pour vous l'ancre de confiance ni le profil anywhere. Par exemple

remoteNetworkConfig:
  iam:
    roleARN: arn:aws:iam::000011112222:role/HybridNodesRole

Pour associer le rôle à une identité Kubernetes et autoriser les nœuds distants à rejoindre le cluster EKS, eksctl crée une entrée d'accès avec le rôle IAM des nœuds hybrides comme ARN principal et de type. HYBRID_LINUX

eksctl get accessentry --cluster my-cluster --principal-arn arn:aws:iam::000011112222:role/eksctl-my-cluster-clust-HybridNodesSSMRole-XiIAg0d29PkO --output json
[
    {
        "principalARN": "arn:aws:iam::000011112222:role/eksctl-my-cluster-clust-HybridNodesSSMRole-XiIAg0d29PkO",
        "kubernetesGroups": [
            "system:nodes"
        ]
    }
]

Support des modules complémentaires

Interface réseau de conteneurs (CNI) : l'AWS VPC CNI ne peut pas être utilisée avec des nœuds hybrides. Les fonctionnalités de base de Cilium et Calico sont prises en charge pour une utilisation avec des nœuds hybrides. Vous pouvez gérer votre CNI avec l'outillage de votre choix, tel que Helm. Pour plus d'informations, voir Configurer un CNI pour les nœuds hybrides.

Note

Si vous installez un VPC CNI dans votre cluster pour vos groupes de nœuds autogérés ou gérés par EKS, vous devez utiliser v1.19.0-eksbuild.1 ou une version ultérieure, car cela inclut une mise à jour du daemonset du module complémentaire afin d'empêcher son installation sur les nœuds hybrides.

Autres références

• Nœuds hybrides EKS UserDocs

• Annonce de lancement