Création du cluster en trois commandes
1ère commande : Création du cluster EKS
J’utilise, pour la création du cluster, la commande eksctl, je suis un partisan de la ligne de commandes, qui facilite entre autres la répétabilité. Eksctl va lancer l’exécution d’une stack dans le service CloudFormation. Je signale au passage que je préfère utiliser Terraform pour créer un cluster EKS, mais cela est hors contexte pour cet article.
La commande ci-dessous crée un cluster EKS avec un VPC dédié créé par cette commande. Les trois workers nodes par défaut sont créés dans des subnets privés (option –node-private-networking). D’autres détails sont à noter, comme par exemple certains tags nécessaires pour que le load balancer AWS fonctionne automatiquement avec Kubernetes sous EKS (tag kubernetes.io/cluster/TEST-EKS = shared).
# eksctl create cluster \ --name TEST-EKS \ --version 1.13 \ --nodegroup-name TEST-EKS-workers \ --node-type m5a.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --node-ami auto \ --ssh-public-key xxx \ --node-private-networking
Le résultat de la commande est le suivant :
[ℹ] using region us-west-2
[ℹ] setting availability zones to [us-west-2b us-west-2d us-west-2a]
[ℹ] subnets for us-west-2b - public:192.168.0.0/19 private:192.168.96.0/19
[ℹ] subnets for us-west-2d - public:192.168.32.0/19 private:192.168.128.0/19
[ℹ] subnets for us-west-2a - public:192.168.64.0/19 private:192.168.160.0/19
[ℹ] nodegroup "TEST-EKS-workers" will use "ami-089d3b6350c1769a6" [AmazonLinux2/1.13]
[ℹ] using EC2 key pair "xxx"
[ℹ] creating EKS cluster "TEST-EKS" in "us-west-2" region
[ℹ] will create 2 separate CloudFormation stacks for cluster itself and the initial nodegroup
[ℹ] if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --reg ion=us-west-2 --name=TEST-EKS'
[ℹ] 2 sequential tasks: { create cluster control plane "TEST-EKS", create nodegroup "TEST-EKS-workers" }
[ℹ] building cluster stack "eksctl-TEST-EKS-cluster"
[ℹ] deploying stack "eksctl-TEST-EKS-cluster"
[ℹ] building nodegroup stack "eksctl-TEST-EKS-nodegroup-TEST-EKS-workers"
[ℹ] deploying stack "eksctl-TEST-EKS-nodegroup-TEST-EKS-workers"
[✔] all EKS cluster resource for "TEST-EKS" had been created
[✔] saved kubeconfig as "/root/.kube/config"
[ℹ] adding role "arn:aws:iam::826065621341:role/eksctl-TEST-EKS-nodegroup-TEST-EK-NodeInstanceRole-2MKGY6N7J84" to auth ConfigMap
[ℹ] nodegroup "TEST-EKS-workers" has 0 node(s)
[ℹ] waiting for at least 1 node(s) to become ready in "TEST-EKS-workers"
[ℹ] nodegroup "TEST-EKS-workers" has 3 node(s)
[ℹ] node "ip-192-168-125-195.us-west-2.compute.internal" is not ready
[ℹ] node "ip-192-168-141-208.us-west-2.compute.internal" is ready
[ℹ] node "ip-192-168-174-225.us-west-2.compute.internal" is not ready
[ℹ] kubectl command should work with "/root/.kube/config", try 'kubectl get nodes'
[✔] EKS cluster "TEST-EKS" in "us-west-2" region is ready
Globalement, la puissance d’EKS réside dans la facilité de créer un cluster Kubernetes sans effort. Pour le reste, l’interface graphique est spartiate et ne fournit que des informations globales sur le cluster créé. Il est à noter que le security group nécessaire pour la communication avec les nodes depuis un client utilisant la commande kubectl a été créé automatiquement par défaut par la commande eksctl.
2ème commande : Paramétrage de la connexion client
Nous réalisons nos manips depuis un serveur EC2. Sur le serveur EC2, il faut installer aws cli. Cf. https://docs.aws.amazon.com/fr_fr/cli/latest/userguide/cli-chap-install.html
Pour utiliser la commande client « kubectl », il faut paramétrer le fichier de configuration ~/.kube qui permet l’accès au Kubernetes Master. Pour réaliser facilement cela, lancer la commande suivante (le client AWS CLI doit avoir été installé) :
# aws eks --region us-west-2 update-kubeconfig --name TEST-EKS
3ème commande : Contrôle du cluster
Sur le serveur EC2 de manips, il faut installer kubectl. Cf. https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html
Il est possible maintenant de tester l’accès au cluster avec kubectl. La commande ci-dessus me permet de vérifier que trois nodes ont bien été créés dans le cluster TEST-EKS :
# kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-125-195.us-west-2.compute.internal Ready <none> 36m v1.13.7-eks-c57ff8 ip-192-168-141-208.us-west-2.compute.internal Ready <none> 36m v1.13.7-eks-c57ff8 ip-192-168-174-225.us-west-2.compute.internal Ready <none> 36m v1.13.7-eks-c57ff8
Les nodes sont en fait implémentés sous forme de serveur EC2 :
En résumé
Mon cluster EKS a été installé.
Il est implémenté sur trois nodes qui sont des serveurs EC2 sur lesquels les containers vont s’exécuter. Si je perds un node du cluster, les containers seront redémarrés sur un autre node du cluster.
Les nodes sont créés alternativement sur des AZ différentes.
D’autres particularités sont liées à l’utilisation d’EKS, par exemple, l’accès à notre application via un service load balancer AWS qui se paramètre automatiquement, avec juste une ligne dans un fichier de paramétrage yaml qui décrit le service attaché à ce load balancer.
Je vous donne maintenant rendez-vous sur la troisième partie de cet article qui décrit le déploiement de notre application micro-service.
Et si vous souhaitez vous former sur Amazon Web Services, découvrez notre offre de formations AWS.
