AWS + Kubernetes = AWS Elastic Kubernetes Service (EKS)

Amazon Web Services (AWS) propose un service permettant de déployer un cluster Kubernetes entièrement managé. Ce service s’appelle Amazon Elastic Kubernetes Service (EKS). Amazon EKS vous offre la flexibilité de démarrer, exécuter et faire évoluer des applications Kubernetes dans le cloud AWS ou on-premise. Amazon EKS vous aide à fournir des clusters hautement disponibles et sécurisés, et automatise des tâches clés comme le patching, le provisionnement de nœuds et les mises à jour. Amazon EKS est un service managé qui vous permet d’exécuter Kubernetes sur AWS sans avoir à installer, exploiter et maintenir votre propre control plane Kubernetes ni vos propres nœuds. AWS fournit un Control Plane complet et autonome auquel nous n’avons pas accès, car il fait tourner des nœuds en coulisse. C’est le principe d’un cluster managé.

Dans ce tutoriel, nous allons démontrer comment provisionner un cluster EKS managé fonctionnel sur Amazon Cloud. Pour être aussi efficaces que possible et respecter les bonnes pratiques DevOps, nous allons utiliser de l’Infrastructure as Code (IaC) avec AWS CloudFormation.

AWS CloudFormation est un outil très efficace pour provisionner de nombreuses ressources avec un langage déclaratif stocké dans un fichier manifeste au format YAML ou JSON.

1 - Prérequis

Compte AWS

Pour ce tutoriel, nous aurons besoin d’un compte AWS (si vous n’en avez pas, vous pouvez en créer un ici) avec des accès administrateur et programmatique pour utiliser AWS CLI (vous pouvez suivre ce tutoriel pour créer un accès programmatique et obtenir des identifiants).

Installation des outils

AWS Command Line Interface (CLI)

Ce tutoriel sera réalisé sous Linux et vous devrez installer le package AWS CLI version 2 pour interagir avec l’API AWS. Pour installer ce package sous Linux, vous pouvez suivre ce tutoriel. Pour effectuer des opérations et interagir avec AWS, vous devez configurer les paramètres de base d’AWS CLI comme les identifiants de sécurité, la région AWS ou le format de sortie par défaut. Vous pouvez configurer rapidement AWS CLI avec la documentation officielle.

GIT Source Code Management (SCM)

Vous aurez besoin du client SCM git pour récupérer le code source depuis GitHub. Pour l’installation de git, vous pouvez consulter ce tutoriel qui présente plusieurs types d’installation.

Kubectl

Pour interagir avec le cluster EKS, vous devez installer l’outil en ligne de commande Kubernetes : kubectl. Pour installer cet utilitaire, vous pouvez vous référer à la documentation officielle de Kubernetes. Pour cet article, vous aurez besoin de kubectl en version 1.18.

2 - Projet

Ce tutoriel démontre comment créer un cluster Kubernetes managé EKS avec AWS CloudFormation. Cela se fera en 3 étapes principales dans le manifeste CloudFormation :

Configuration réseau

Dans cette section, afin de suivre les recommandations et bonnes pratiques AWS pour un cluster de production, nous allons mettre en place l’environnement réseau en créant différentes ressources comme le Virtual Private Cloud (VPC), l’Internet Gateway (IGW), la Route Table, les Routes, les Subnets et les Security Groups (SG).

Cluster AWS EKS

Ensuite, dans cette section, nous allons créer : le rôle IAM du Cluster (Control Plane), provisionner le Control Plane EKS, le rôle IAM du Node Group et provisionner le Node Group (Node Group est le nom donné par AWS pour décrire un groupe de nœuds de travail).

Test du cluster

Enfin, nous allons déployer une application web simple dans le cluster EKS pour vérifier qu’il fonctionne comme attendu.

Architecture EKS pour la communication entre le Control Plane et les Worker Nodes

Architecture du projet EKS

3 - Déploiement de l’infrastructure

Le template CloudFormation est composé de 3 sections principales :

Parameters : Cette section optionnelle est utile pour personnaliser votre template (par exemple : nom du VPC, plage du bloc CIDR pour le VPC, nom du cluster EKS…) et vous permet de saisir des valeurs personnalisées pour votre template à chaque création ou mise à jour de la stack,
Resources : Cette section obligatoire est le cœur de la stack CloudFormation : c’est là que nous déclarons toutes les ressources AWS que nous souhaitons inclure dans la stack (par exemple : Virtual Private Cloud, Internet Gateway, Subnet, cluster EKS…),
Outputs : Cette section optionnelle déclare des valeurs de sortie que vous pouvez réutiliser avec d’autres stacks, retourne une réponse ou un affichage sur la console AWS CloudFormation (par exemple : ID du VPC, nom des ressources…).

Tout au long de cette section, nous allons décrire et expliquer chaque ressource déclarée dans la section Resources du manifeste CloudFormation afin de créer le cluster EKS.

3 .1. Configuration réseau

Création du VPC

Pour déployer le cluster EKS, AWS recommande de créer votre propre Virtual Private Cloud (VPC) dédié et isolé. Créez un VPC nommé eks-VPC avec la déclaration suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Resources:
  eksVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: eks-VPC
        - Key: Project
          Value: aws-eks

Type définit la ressource souhaitée, dans notre cas AWS::EC2::VPC pour créer une ressource VPC.
Properties définit les différentes caractéristiques de la ressource déclarée. Chaque ressource possède son propre ensemble de propriétés. Pour la ressource VPC, vous pouvez définir le bloc CIDR, l’allocation d’un nom d’hôte DNS public pour les ressources EC2 ou la définition des tags.

Internet Gateway

Sur AWS, une Internet Gateway (IGW) est une ressource qui permet la communication entre votre VPC et internet. Cela permettra l’accès internet pour les worker nodes. Pour plus d’informations, vous pouvez lire la documentation officielle.

Créez une Internet Gateway eks-InternetGateway avec la déclaration suivante :

1
2
3
4
5
6
7
8
9
...
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: eks-InternetGateway
        - Key: Project
          Value: aws-eks

Pour associer précédemment eks-InternetGateway au eks-VPC, nous devons rattacher les deux ressources. Rattachons l’Internet Gateway au VPC avec la déclaration suivante :

1
2
3
4
5
...
  eksVPCGatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
  Properties:       InternetGatewayId: !Ref eksInternetGateway
      VpcId: !Ref eksVPC

La fonction intrinsèque AWS !Ref retourne la valeur du paramètre ou de la ressource spécifiée. Ici, nous utilisons cette fonction pour récupérer dynamiquement l’ID de eks-InternetGateway et eks-VPC créés précédemment.

Route Table

Une route table publique est nécessaire pour déclarer toutes les routes utilisées par le VPC. Lorsque le eks-VPC est créé, une Route Table principale est également créée, mais AWS ne recommande pas d’utiliser la Route Table principale du VPC. La route table principale peut avoir des associations de subnets explicites et implicites. Les route tables personnalisées n’ont que des associations explicites. Cela garantit un contrôle explicite de la façon dont chaque subnet route le trafic. Nous devrons donc créer une eks-RouteTable personnalisée pour le eks-VPC avec la déclaration suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
...
  eksPublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref eksVPC
      Tags:
        - Key: Name
          Value: eks-RouteTable
        - Key: Project
          Value: aws-eks

Nous devons ensuite déclarer la Route publique dans la eks-RouteTable pour permettre l’accès internet depuis le eks-VPC. Créez la Route publique avec la déclaration suivante :

1
2
3
4
5
6
7
8
...
  eksPublicRoute:
    DependsOn: eksVPCGatewayAttachment
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref eksPublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref eksInternetGateway

Cette route est ajoutée à la eks-RouteTable avec le RouteTableId vers internet avec le DestinationCidrBlock 0.0.0.0/0 via le GatewayId eks-InternetGateway.

La ressource eksPublicRoute requise par l’Internet Gateway a bien été rattachée au VPC avant sa création. La directive DependsOn garantit que eksVPCGatewayAttachment a été créée avec succès avant de créer cette ressource.

Création des subnets

AWS propose le principe de zone de disponibilité (AZ) pour accroître la haute disponibilité, la tolérance aux pannes et la fiabilité. Pour déployer un cluster EKS, il est obligatoire de créer au moins deux subnets dans deux AZ différentes. Chaque worker node sera déployé dans les deux AZ différentes.

Pour répondre aux exigences, être plus proche de vos clients européens ou respecter des contraintes de conformité et légales, nous allons travailler dans la région AWS Europe (Paris). Cette région AWS correspond au nom de code eu-west-3, composée de 3 zones de disponibilité :

eu-west-3a
eu-west-3b
eu-west-3c

Dans ce tutoriel, nous utiliserons les zones de disponibilité eu-west-3a et eu-west-3b.

Le premier subnet eks-PublicSubnet01 sera créé dans la zone de disponibilité eu-west-3a. Créons un eks-PublicSubnet01 avec la déclaration suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
...
  eksPublicSubnet01:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: eu-west-3a
      MapPublicIpOnLaunch: true
      CidrBlock:
        Ref: 10.0.0.0/24
      VpcId:
        Ref: eksVPC
      Tags:
        - Key: Name
          Value: eks-PublicSubnet01
        - Key: Project
          Value: aws-eks

Le eks-PublicSubnet01 est créé dans la zone de disponibilité eu-west-3a, avec allocation automatique d’IP publique MapPublicIpOnLaunch, la plage de bloc CIDR de ce subnet est 10.0.0.0/24 et ce subnet est rattaché au eks-VPC.

Le second subnet eks-PublicSubnet02 sera créé dans la zone de disponibilité eu-west-3b. Créons un eks-PublicSubnet02 avec la déclaration suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
...
  eksPublicSubnet02:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: eu-west-3b
      MapPublicIpOnLaunch: true
      CidrBlock:
        Ref: 10.0.1.0/24
      VpcId:
        Ref: eksVPC
      Tags:
        - Key: Name
          Value: eks-PublicSubnet02
        - Key: Project
          Value: aws-eks

Le eks-PublicSubnet02 est créé dans la zone de disponibilité eu-west-3b, avec allocation automatique d’IP publique MapPublicIpOnLaunch, la plage de bloc CIDR de ce subnet est 10.0.1.0/24 et ce subnet est rattaché au eks-VPC.

Pour permettre l’accès internet aux worker nodes depuis chaque subnet, il est nécessaire d’associer chaque Public Subnet à la eks-RouteTable. Associez les subnets eksPublicSubnet01 et eksPublicSubnet02 à la eks-RouteTable avec la déclaration suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
...
  eksPublicSubnet01RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref eksPublicSubnet01
      RouteTableId: !Ref eksPublicRouteTable

  eksPublicSubnet02RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref eksPublicSubnet02
      RouteTableId: !Ref eksPublicRouteTable

Security Groups

Les Security Groups (SG) constituent un ensemble de règles à granularité fine permettant d’autoriser, de restreindre ou de refuser la communication vers une ressource. Un security group de cluster est conçu pour laisser circuler librement tout le trafic entre le control plane et les managed node groups. Enfin, créez un Security Group pour permettre la communication entre le Control Plane EKS et les worker nodes avec la déclaration suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
...
  eksSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster communication with worker nodes
      VpcId: !Ref eksVPC
      Tags:
        - Key: Name
          Value: eks-SecurityGroup
        - Key: Project
          Value: aws-eks

L’implémentation réseau est terminée. C’est une section importante car elle permet de créer votre propre réseau isolé et sécurisé pour le cluster EKS. Elle montre également comment établir la communication entre le VPC et plusieurs subnets.

Vous pouvez visualiser l’architecture réseau avec la déclaration de toutes les ressources réseau :

3.2. Cluster AWS EKS

Dans cette section, nous allons montrer et expliquer les déclarations nécessaires pour provisionner le Control Plane EKS et le Node Group (worker nodes).

Rôle IAM du cluster EKS

Les clusters Kubernetes managés par Amazon EKS ont besoin d’accéder à d’autres services AWS en votre nom pour gérer les ressources que vous utilisez avec le service. Avant de pouvoir créer des clusters Amazon EKS, vous devez créer/déclarer un rôle IAM avec la policy IAM AmazonEKSClusterPolicy :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
...
  eksIAMRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
              - eks.amazonaws.com
            Action:
            - 'sts:AssumeRole'
      RoleName: EKSClusterRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

Provisionnement du Control Plane EKS

Nous pouvons maintenant créer un Control Plane EKS, nommé EKS, avec la déclaration suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
...
  eksCluster:
    Type: AWS::EKS::Cluster
    Properties:
      Name: EKS
      Version: 1.18
      RoleArn:
        "Fn::GetAtt": ["eksIAMRole", "Arn"]
      ResourcesVpcConfig:
        SecurityGroupIds:
          - !Ref eksSecurityGroup
        SubnetIds:
          - !Ref eksPublicSubnet01
          - !Ref eksPublicSubnet02
    DependsOn: [eksIAMRole, eksPublicSubnet01, eksPublicSubnet02, eksSecurityGroup]

Le nom du cluster EKS est EKS, avec la version Kubernetes 1.18. Il utilise le rôle EKSClusterRole déclaré précédemment. Le cluster EKS utilise le eks-SecurityGroup pour autoriser la communication dans le cluster, et les ressources seront déployées dans les deux AZ différentes eksPublicSubnet01 et eksPublicSubnet02.

La dernière directive DependsOn est importante. Elle signifie que le cluster EKS ne sera déployé qu’une fois que toutes les ressources déclarées : EKSIAMRole, eksPublicSubnet01, eksPublicSubnet02, eksControlPlaneSecurityGroup auront été déployées avec succès. Cette directive de contrainte évite des erreurs lors du déploiement de la stack CloudFormation.

Rôle IAM du Node Group EKS

Le daemon kubelet d’Amazon EKS effectue des appels aux API AWS en votre nom. Les nœuds reçoivent les permissions pour ces appels API via un profil d’instance IAM et des policies associées. Avant de pouvoir créer des nœuds et les enregistrer dans un cluster, vous devez créer un rôle IAM que ces nœuds utiliseront lors de leur création. Cette exigence s’applique aux nœuds lancés avec l’AMI optimisée Amazon EKS fournie par Amazon, ou avec toute autre AMI de nœud que vous souhaitez utiliser. Avant de créer des nœuds, vous devez créer un rôle IAM avec les policies IAM suivantes :

AmazonEKSWorkerNodePolicy
AmazonEC2ContainerRegistryReadOnly

La policy AmazonEKS_CNI_Policy doit être attachée soit à ce rôle, soit à un rôle différent associé au compte de service Kubernetes aws-node. Nous recommandons d’associer la policy au rôle lié au compte de service Kubernetes plutôt qu’à ce rôle. Pour plus d’informations, consultez Walkthrough: Updating the VPC CNI plugin to use IAM roles for service accounts

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
...
  eksNodeInstanceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - !FindInMap [ServicePrincipals, !Ref "AWS::Partition", ec2]
            Action:
              - "sts:AssumeRole"
      ManagedPolicyArns:
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEKSWorkerNodePolicy"
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEKS_CNI_Policy"
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
      Path: /

Provisionnement du Node Group EKS

Enfin, pour créer un cluster EKS multi-nœuds, nous devons créer un Node Group (worker nodes) pour déployer les workloads. Créez un Node Group nommé NodeGroup01 avec la déclaration suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
...
  eksNodeGroup:
    Type: AWS::EKS::Nodegroup
    Properties:
      ClusterName: EKS
      NodeRole:
        "Fn::GetAtt": ["eksNodeInstanceRole", "Arn"]
      AmiType: AL2_x86_64
      InstanceTypes:
        - t3.medium
  NodegroupName:  NodeGroup01       RemoteAccess:
        Ec2SshKey: my-eks-key
      ScalingConfig:
        MinSize: 1
        DesiredSize: 2
        MaxSize: 7
      Labels:
        Project: aws-eks
      Subnets:
        - !Ref eksPublicSubnet01
        - !Ref eksPublicSubnet02
    DependsOn: [eksCluster, eksNodeInstanceRole]

Le nom du Node Group est NodeGroup01, ce Node Group est rattaché au cluster EKS via la directive ClusterName. Le groupe de worker nodes utilise le rôle NodeInstanceRole déclaré précédemment.

Les worker nodes sont des instances EC2 ; pour y accéder, AWS recommande une authentification par paire de clés EC2. Nous utiliserons une clé publique nommée my-eks-key (nous créerons une paire de clés SSH juste après). Pour ce hands-on, notre Node Group contiendra 2 worker nodes. Nous pouvons modifier le nombre de nœuds souhaités avec la directive ScalingConfig.DesiredSize.

AWS peut fournir une scalabilité automatisée pour notre Node Group en fonction de votre charge de travail, en augmentant ou en diminuant le nombre de worker nodes. Nous pouvons définir ces limites avec les directives suivantes : ScalingConfig.MinSize et ScalingConfig.MaxSize. Le type d’instance (InstanceTypes) offre un équilibre entre ressources de calcul, mémoire et réseau, et peut être utilisé pour une grande variété de charges de travail sur les worker nodes. Nous pouvons également définir le type d’Amazon Machine Image (AMI).

Les worker nodes de NodeGroup01 seront déployés dans deux zones de disponibilité différentes, eksPublicSubnet01 et eksPublicSubnet02.

Comme pour le cluster EKS, la dernière directive DependsOn est importante car elle signifie que le Node Group ne sera déployé qu’une fois que toutes les ressources déclarées eksCluster, eksNodeInstanceRole auront été déployées avec succès.

Toutes les ressources nécessaires à la création d’un cluster EKS ont été déclarées. Vous trouverez le manifeste CloudFormation complet sur le dépôt GitHub de SoKube.

N.B : La stack CloudFormation stockée sur GitHub est légèrement différente, car nous avons templatisé de nombreuses directives avec la section Parameter pour rester agiles et pouvoir l’utiliser dans différents environnements.

Dans la section suivante, nous allons provisionner un cluster EKS à partir de la stack CloudFormation précédente, déployer une application web simple sur le cluster et l’exposer pour tester le cluster EKS.

3.3. Provisionnement du cluster EKS

Récupérez le code source depuis le dépôt Git de SoKube :

1
2
git clone https://github.com/sokube/aws-eks.git $HOME/aws-eks
cd $HOME/aws-eks/infrastructure-as-code

Définissez toutes les variables pour votre stack CloudFormation EKS :

1
2
3
export EKS_STACK_NAME="eks"
export EKS_AWS_REGION="eu-west-3"
export EKS_KEY_PAIR_NAME="my-eks-key"

Créez une paire de clés EKS :

1
2
3
4
5
6
aws ec2 create-key-pair\
  --region $EKS_AWS_REGION\
  --key-name $EKS_KEY_PAIR_NAME\
  --tag-specifications 'ResourceType=key-pair,Tags=[{Key=Name,Value=eks-key-pair},{Key=Project,Value=aws-eks}]'\
  --output text\
  --query 'KeyMaterial' > $HOME/aws-eks/infrastructure-as-code/eks.id_rsa

Créez le cluster EKS avec la commande suivante :

1
2
3
4
aws cloudformation create-stack --stack-name $EKS_STACK_NAME\
  --region $EKS_AWS_REGION\
  --template-body file://$HOME/aws-eks/infrastructure-as-code/eks-cloudformation.yaml\
  --capabilities CAPABILITY_NAMED_IAM

Vous pouvez vérifier le statut de création du cluster EKS avec la commande suivante. Tant que cette boucle n’est pas terminée, le cluster EKS n’est pas prêt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
started_date=$(date '+%H:%M:%S')
start=`date +%s`
while true; do
  if [[ $(aws cloudformation describe-stacks --region $EKS_AWS_REGION --stack-name $EKS_STACK_NAME --query "Stacks[*].StackStatus" --output text) == CREATE_IN_PROGRESS ]]
  then
    echo -e "EKS Cluster status : CREATE IN PROGRESS \n"
    sleep 10
  elif [[ $(aws cloudformation describe-stacks --region $EKS_AWS_REGION --stack-name $EKS_STACK_NAME --query "Stacks[*].StackStatus" --output text) == CREATE_COMPLETE ]]
  then
    echo -e "EKS Cluster status : SUCCESSFULLY CREATED \n"
    end=`date +%s`
    runtime=$((end-start))
    finished_date=$(date '+%H:%M:%S')
    echo "started at :" $started_date
    echo "finished at :" $finished_date
    hours=$((runtime / 3600)); minutes=$(( (runtime % 3600) / 60 )); seconds=$(( (runtime % 3600) % 60 )); echo "Total time : $hours h $minutes min $seconds sec"
    break
  else
    echo -e "EKS Cluster status : $(aws cloudformation describe-stacks --region $EKS_AWS_REGION --stack-name $EKS_STACK_NAME --query "Stacks[*].StackStatus" --output text) \n"
    break
  fi
done

Pendant la création du cluster EKS, nous devrions voir :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
EKS Cluster status : CREATE IN PROGRESS

EKS Cluster status : CREATE IN PROGRESS

EKS Cluster status : CREATE IN PROGRESS

...

EKS Cluster status : CREATE_COMPLETE

started at : 18:32:47
finished at : 18:47:30
Total time : 0 h 14 min 43 sec

Notez que la création du cluster EKS peut prendre entre 15 et 20 minutes.

Une fois la boucle terminée, vérifiez que le statut du cluster EKS est ACTIVE :

1
2
3
4
aws eks --region $EKS_AWS_REGION describe-cluster\
  --name $EKS_CLUSTER_NAME\
  --query "cluster.status"\
  --output text

Félicitations ! Votre cluster EKS est fonctionnel et prêt à déployer des workloads. L’étape suivante consiste à vérifier que le cluster EKS fonctionne comme attendu.

3.4. Test du cluster EKS

Fichier de configuration Kubernetes

Pour tester le cluster managé, la première étape consiste à générer et récupérer le fichier de configuration Kubernetes contenant les identifiants nécessaires pour interagir avec le cluster EKS via l’API Kubernetes.

Générez et créez le fichier kubeconfig :

1
2
3
aws eks\
  --region $EKS_AWS_REGION update-kubeconfig\
  --name $EKS_CLUSTER_NAME

Nous devrions voir :

1
Added new context arn:aws:eks:eu-west-3:123456789123:cluster/EKS to /home/admin/.kube/config

Le fichier kubeconfig est automatiquement créé ou fusionné dans “$HOME/.kube/config”

Vous pouvez maintenant utiliser la commande kubectl pour opérer sur le cluster EKS. Par exemple, vous pouvez récupérer des informations sur les worker nodes avec la commande suivante :

1
kubectl get node

Le résultat doit ressembler à :

1
2
3
NAME           STATUS  ROLES   AGE    VERSION
ip-10-0-0-137  Ready   <none>  5m21s  v1.18.9-eks-d1db3c
ip-10-0-1-183  Ready   <none>  5m35s  v1.18.9-eks-d1db3c

Déploiement de l’application

Nous pouvons maintenant interagir avec le cluster EKS. Nous allons déployer un pod hébergeant une application web Node.js simple pour valider que notre cluster EKS fonctionne comme attendu. Juste après, nous exposerons ce pod grâce au service Kubernetes LoadBalancer pour permettre aux utilisateurs externes d’accéder à cette application. Sur les plateformes cloud, il est recommandé d’utiliser le service LoadBalancer cloud externe et managé, plutôt que le service de load balancer interne que vous pouvez déployer au sein du cluster Kubernetes.

Créez un pod app-shark :

1
2
3
4
5
kubectl run app-shark\
  --image=sokubedocker/shark-application:eks\
  --restart=Never

pod/app-shark created

Créez un service LoadBalancer sur le port 8080 pour exposer le pod app-shark avec la commande suivante :

1
2
3
kubectl expose pod app-shark --type=LoadBalancer --port=8080

service/app-shark exposed

Le conteneur shark-app dans le pod utilise le port 8080.

Kubernetes est un outil pleinement Cloud Native, et la commande kubectl précédente déclenche la création automatisée d’un Elastic Load Balancer (ELB) AWS. La création de l’ELB prend généralement près de 5 minutes avant de pouvoir être utilisé.

En attendant que l’ELB soit disponible, nous pouvons récupérer des informations sur les ressources créées avec la commande suivante :

1
kubectl get pod,svc -o wide

Pour afficher et accéder à shark-app, nous devrons récupérer le nom d’hôte (DNS Name) de l’ELB AWS. L’application app-shark sera disponible à cette adresse. Récupérez le nom DNS de l’ELB avec la commande suivante :

1
2
EKS_ELB_HOSTNAME=$(kubectl get svc app-shark -o jsonpath='{.status.loadBalancer.ingress[*].hostname}')\
&& echo $EKS_ELB_HOSTNAME

Nous devrions voir :

1
a92991fcaff2f4007ad28c27b27ef9e3-570659607.eu-west-3.elb.amazonaws.com

Patientez 5 minutes le temps que l’Elastic Load Balancer soit opérationnel…

Une fois l’ELB créé, nous pouvons soit utiliser :

curl (résultat moins agréable à lire) :

1
curl http://$EKS_ELB_HOSTNAME:8080

un navigateur web (meilleure solution)

Collez le nom DNS “http://a92991fcaff2f4007ad28c27b27ef9e3-570659607.eu-west-3.elb.amazonaws.com:8080” dans le navigateur web en ajoutant le port 8080 pour accéder à l’application shark.

Nous devrions voir :

L’application shark-app est bien accessible via le nom DNS de l’ELB. Le cluster EKS fonctionne correctement.

4 - Libération des ressources

Si vous utilisez régulièrement AWS, vous connaissez la célèbre formule :

“Pay only what you use”

Cependant, cela inclut aussi de payer pour ce que vous oubliez d’éteindre ou de supprimer… 😁

Gardez à l’esprit que les ressources, même inactives, restent provisionnées et facturées. Pour éviter des factures salées, veillez à nettoyer régulièrement vos clusters de test ou de démo.

À titre de référence, le coût d’un tel cluster est d’environ 5 $ par jour.

Vous trouverez sur le dépôt GitHub de SoKube toutes les commandes permettant de supprimer les ressources créées.

Conclusion

AWS fournit un cluster Kubernetes entièrement managé. Si vous souhaitez vous concentrer principalement sur le volet applicatif, concevoir et installer un cluster Kubernetes prêt pour la production peut sembler être une tâche complexe et chronophage. Avec AWS EKS, Amazon fournit un cluster Kubernetes sur une infrastructure éprouvée, scalable et hautement disponible.

Dans cet article, nous avons vu comment créer un cluster EKS hautement disponible, tolérant aux pannes, avec deux worker nodes et une isolation réseau. Vous pouvez maintenant aller plus loin et découvrir ce qui se cache sous le capot de la puissance de Kubernetes et d’AWS. Par exemple, vous pouvez tester la mise en œuvre du RBAC avec AWS IAM, ou un pipeline CI/CD AWS avec l’intégration EKS, et bien d’autres choses encore…

Pour aller plus loin, découvrez notre conseil cloud et notre formation AWS.