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.

VPC Configuration

VPC dédié pour le cluster

Par défauteksctl create cluster, un VPC dédié sera créé pour le cluster. Cela est fait afin d'éviter toute interférence avec les ressources existantes pour diverses raisons, notamment la sécurité, mais aussi parce qu'il est difficile de détecter tous les paramètres d'un VPC existant.

Modifier l'adresse CIDR du VPC

Si vous devez configurer le peering avec un autre VPC, ou si vous avez simplement besoin d'une plage IPs plus ou moins grande, vous pouvez --vpc-cidr utiliser le drapeau pour le modifier. Reportez-vous à la documentation AWS pour obtenir des guides sur le choix des blocs CIDR dont l'utilisation est autorisée dans un VPC AWS.

Si vous créez un IPv6 cluster, vous pouvez le configurer VPC.IPv6Cidr dans le fichier de configuration du cluster. Ce paramètre se trouve uniquement dans le fichier de configuration, pas dans un indicateur CLI.

Si vous possédez un bloc d'adresses IPv6 IP, vous pouvez également apporter votre propre IPv6 pool. Consultez Bring your own IP addresses (BYOIP) to Amazon EC2 pour savoir comment importer votre propre pool. Utilisez ensuite le fichier VPC.IPv6Cidr de configuration du cluster pour configurer Eksctl.

Utiliser un VPC existant : partagé avec kops

Vous pouvez utiliser le VPC d'un cluster Kubernetes existant géré par kops. Cette fonctionnalité est fournie pour faciliter le peering des and/or clusters de migration.

Si vous avez déjà créé un cluster avec kops, par exemple en utilisant des commandes similaires à celles-ci :

export KOPS_STATE_STORE=s3://kops
kops create cluster cluster-1.k8s.local --zones=us-west-2c,us-west-2b,us-west-2a --networking=weave --yes

Vous pouvez créer un cluster EKS dans le même environnement AZs en utilisant les mêmes sous-réseaux VPC (REMARQUE : au moins 2 AZs/subnets sont requis) :

eksctl create cluster --name=cluster-2 --region=us-west-2 --vpc-from-kops-cluster=cluster-1.k8s.local

Utiliser un VPC existant : autre configuration personnalisée

eksctlfournit une certaine flexibilité, mais pas complète, pour les topologies de VPC et de sous-réseaux personnalisées.

Vous pouvez utiliser un VPC existant en fournissant des sous-réseaux and/or publics privés à l'aide des --vpc-private-subnets indicateurs and. --vpc-public-subnets C'est à vous de vous assurer que les sous-réseaux que vous utilisez sont correctement catégorisés, car il n'existe aucun moyen simple de vérifier si un sous-réseau est réellement privé ou public, car les configurations varient.

À partir de ces indicateurs, il eksctl create cluster déterminera automatiquement l'ID du VPC, mais il ne créera aucune table de routage ni aucune autre ressource, telle que internet/NAT des passerelles. Il créera toutefois des groupes de sécurité dédiés pour le groupe de nœuds initial et le plan de contrôle.

Vous devez vous assurer de fournir au moins 2 sous-réseaux différents AZs et cette condition est vérifiée par EKS. Si vous utilisez un VPC existant, les exigences suivantes ne sont ni appliquées ni vérifiées par EKS ou Eksctl et EKS crée le cluster. Certaines fonctions de base du cluster fonctionnent sans ces exigences. (Par exemple, le balisage n'est pas strictement nécessaire, des tests ont montré qu'il est possible de créer un cluster fonctionnel sans qu'aucune balise ne soit définie sur les sous-réseaux, mais rien ne garantit que cela soit toujours valable et le balisage est recommandé.)

Exigences standard :

D'autres exigences peuvent être imposées par EKS ou Kubernetes, et c'est à vous de vous en tenir up-to-date à ces exigences. and/or recommendations, and implement those as needed/possible

Les paramètres de groupe de sécurité par défaut appliqués par eksctl peuvent être suffisants ou ne pas être suffisants pour partager l'accès avec les ressources d'autres groupes de sécurité. Si vous souhaitez modifier les ingress/egress règles des groupes de sécurité, vous devrez peut-être utiliser un autre outil pour automatiser les modifications, ou le faire via EC2 la console.

En cas de doute, n'utilisez pas de VPC personnalisé. L'utilisation eksctl create cluster sans aucun --vpc-* indicateur configurera toujours le cluster avec un VPC dédié entièrement fonctionnel.

Exemples

Créez un cluster à l'aide d'un VPC personnalisé avec 2 sous-réseaux privés et 2 sous-réseaux publics :

eksctl create cluster \
  --vpc-private-subnets=subnet-0ff156e0c4a6d300c,subnet-0426fb4a607393184 \
  --vpc-public-subnets=subnet-0153e560b3129a696,subnet-009fa0199ec203c37

ou utilisez le fichier de configuration équivalent suivant :

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    private:
      us-west-2a:
          id: "subnet-0ff156e0c4a6d300c"
      us-west-2c:
          id: "subnet-0426fb4a607393184"
    public:
      us-west-2a:
          id: "subnet-0153e560b3129a696"
      us-west-2c:
          id: "subnet-009fa0199ec203c37"

nodeGroups:
  - name: ng-1

Créez un cluster à l'aide d'un VPC personnalisé avec 3 sous-réseaux privés et faites en sorte que le groupe de nœuds initial utilise ces sous-réseaux :

eksctl create cluster \
  --vpc-private-subnets=subnet-0ff156e0c4a6d300c,subnet-0549cdab573695c03,subnet-0426fb4a607393184 \
  --node-private-networking

ou utilisez le fichier de configuration équivalent suivant :

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    private:
      us-west-2d:
          id: "subnet-0ff156e0c4a6d300c"
      us-west-2c:
          id: "subnet-0549cdab573695c03"
      us-west-2a:
          id: "subnet-0426fb4a607393184"

nodeGroups:
  - name: ng-1
    privateNetworking: true

Créez un cluster à l'aide d'un VPC 4x sous-réseaux publics personnalisé :

eksctl create cluster \
  --vpc-public-subnets=subnet-0153e560b3129a696,subnet-0cc9c5aebe75083fd,subnet-009fa0199ec203c37,subnet-018fa0176ba320e45

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    public:
      us-west-2d:
          id: "subnet-0153e560b3129a696"
      us-west-2c:
          id: "subnet-0cc9c5aebe75083fd"
      us-west-2a:
          id: "subnet-009fa0199ec203c37"
      us-west-2b:
          id: "subnet-018fa0176ba320e45"

nodeGroups:
  - name: ng-1

D'autres exemples peuvent être trouvés dans le examples dossier du dépôt :

Groupe de sécurité de nœuds partagés personnalisé

eksctlcréera et gérera un groupe de sécurité de nœuds partagés qui permet la communication entre les nœuds non gérés, le plan de contrôle du cluster et les nœuds gérés.

Si vous souhaitez plutôt fournir votre propre groupe de sécurité personnalisé, vous pouvez remplacer le sharedNodeSecurityGroup champ dans le fichier de configuration :

vpc:
  sharedNodeSecurityGroup: sg-0123456789

Par défaut, lors de la création du cluster, des règles eksctl seront ajoutées à ce groupe de sécurité pour autoriser les communications vers et depuis le groupe de sécurité de cluster par défaut créé par EKS. Le groupe de sécurité du cluster par défaut est utilisé à la fois par le plan de contrôle EKS et par les groupes de nœuds gérés.

Si vous souhaitez gérer vous-même les règles du groupe de sécurité, vous pouvez eksctl empêcher leur création en définissant manageSharedNodeSecurityGroupRules ce qui suit false dans le fichier de configuration :

vpc:
  sharedNodeSecurityGroup: sg-0123456789
  manageSharedNodeSecurityGroupRules: false

Passerelle NAT

La passerelle NAT d'un cluster peut être configurée comme Disable suit : Single (par défaut) ouHighlyAvailable. L'HighlyAvailableoption déploiera une passerelle NAT dans chaque zone de disponibilité de la région, de sorte que si une AZ est en panne, les nœuds de l'autre zone AZs pourront toujours communiquer avec Internet.

Il peut être spécifié via l'indicateur --vpc-nat-mode CLI ou dans le fichier de configuration du cluster, comme dans l'exemple ci-dessous :

vpc:
  nat:
    gateway: HighlyAvailable # other options: Disable, Single (default)

Consultez l'exemple complet ici.