Les jobs CI peuvent être très consomateurs en IOPS, notamment lors des phases de téléchargement des artifacts (maven :) ou docker par exemple...) ou lors du build. Une CI déployée sur des instances EC2 avec des volumes EBS standards (gp2) peut connaitre des temps de réponse particulièrement dégradés lorsqu'elle à dépassé sa capacité de burst et qu'elle est limité en IOPS.

Il est interessant dans ce contexte de monitorer l'EBS Burst Balance sur ces volumes.

En cas de performance limitée par les IOPS EBS, il y a 3 solutions:

• augmenter la taille des EBS pour bénéficier de d'un nombre d'IOPS plus important (nb IOPS = 3 x nb GB)
• passer sur des EBS de type io1 pour bénéficier d'un nombre d'IOPS garanti (souvent moins intéressant en terme de coûts)
• utiliser des instances disposant de SSD internes à la place des EBS (ex: c5d ou m5d instances)

Les Operators K8S permettent de déployer un produit (ex: Prometheus, ETCD out Vault...) sur K8S et de gérer toute la configuration sous forme d'objets K8S custom (CRDs). C'est selon moi un des concepts les plus prometteurs de K8S qui permet notamment de déployer le monitoring Prometheus en même temps qu'une appli dans K8S, mais aussi d'automatiser le provisioning de ressources externes cloud nécessaires au fonctionnement de l'application (bucket S3, record DNS ou base DynamoDB par exemple). L'article présente les Operators plus en détail et liste les 120 Operators existant actuellement avec le niveau de maturité de chacun.

Les prérequis a connaitre pour utiliser K8S avec le cloud provider AWS qui permet de provisionner automatiquement de ressources ELB et EBS pour les services de type Load balancer et les PersistentVolumes

Le getting started officiel Hashicorp pour déployer un cluster EKS avec Terraform.
Le code est ici: https://github.com/terraform-providers/terraform-provider-aws/tree/master/examples/eks-getting-started

EDIT:

NOTE: The usage of the specific kubernetes.io/cluster/ resource tags below are required for EKS and Kubernetes to discover and manage networking resources.
NOTE: The usage of the specific kubernetes.io/cluster/ resource tag below is required for EKS and Kubernetes to discover and manage compute resources.

voir également: https://github.com/kubernetes/cloud-provider-aws/blob/8f6e1e3d2cfa20a0deac088b9c4022d433500369/pkg/cloudprovider/providers/aws/tags.go#L30-L52

Je n'ai pas trouvé de doc officielle claire indiquant les tags à mettre en place sur les ressources AWS, mais après avoir passé 2 jours à débugguer pourquoi mes ELB ne se provisionnaient pas, puis pourquoi mes Nodes n'arrivaient pas à joindre le cluster EKS, je confirme que ces tags sont très importants à ajouter sur les ressources suivantes:

• VPC
• Subnets
• Security Groups
• Instances EC2

L'auteur propose de se passer de bastion pour accéder aux resources dans le cloud en ouvrant le port SSH uniquement lorsque l'on a besoin de se connecter à une instance grace à un script qui génère dynamiquement des Security Groups.
La démarche est interessante mais n'apporte pas de solutions pour les instances situés dans des subnets privés et ne disposant pas d'IP publiques.

Suivre à la lettre le principe DRY peut être source d'over-engineering et conduire à créer du code moins lisible/maintenable inutilement. Avec WET, la duplication de code est autorisé lorsque ce code est utilisée 2 fois, le refactoring du code pour limiter la redondance n'intervient qu'au bout de la 3ème utilisation du code.

Un catalogue de helm charts façon DockerHub

Une liste exhaustive de bonnes pratiques à mettre en place avant de déployer une infrastructure en production sur AWS

Example d'utilisation de pre-commit git pour forcer le formattage de code python avec black et flake8

12 bonnes pratiques a mettre en place quand on publie du code python en open source