This article provides a summary of the object storage services of the three biggest cloud providers: AWS, Azure and GCP.
AWS EKS gère désormais les node groups de workers en tant que ressources managées (avant il fallait gérer soit même les ASG de workers nodes).
En plus c'est déjà géré par la nouvelle version du provider terraform-aws
For future reference.
Here are the links for getting Public IPv4 on various clouds.
Azure
curl -H Metadata:true "http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text"AWS
curl http://169.254.169.254/latest/meta-data/public-ipv4GCP
curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ipSince 169.254.169.254 is a global metadata server for these above cloud vendors, no need to use different domain names.
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)
Quelques optimisations pour utiliser EKS en production
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
Une liste exhaustive de bonnes pratiques à mettre en place avant de déployer une infrastructure en production sur AWS
Firecracker est un VMM (Virtual Machine Manager) open source light qui s'interface avec KVM pour créer des microvm qui démarrent en moins de 125ms. Le but de Firecracker est de pouvoir bénéficier de la rapidité d'instanciation d'un container avec l'isolation d'une VM. C'est développé par AWS qui l'utilise en interne pour faire tourner AWS Lambda et AWS Fargate.
L'article propose d'optimiser les coûts d'infrastructures et de bénéficier d'un pseudo chaos engineering sur les clusters k8s en utilisant des spots instances aws (ou équivalent dans les autres clouds).
Amazon permet désormais d'ouvrir un shell sur les instances EC2 sans passer par SSH via la console web ou la cli AWS.
La doc de l'API S3 avec pour chaque endpoint les permissions IAM nécessaires.
C'est super utile quand on essaie de debugger un provisionning de bucket avec terraform qui plante parce qu'il manque des droits:
TF_LOG=debug terraform apply --target aws_s3_bucket.mon_bucketpuis on cherche l'appel qui plante et on va voir dans la doc les permissions à ajouter à sa policy IAM.
Le simulateur de policy AWS IAM, url à garder sous le coude
La liste des actions possibles par ressources dans les policy IAM
Une liste des équivalences entre les services AWS et Azure
Une cli pour créer des clusters AWS EKS en une ligne de commande
Procédure pour utiliser le MFA avec la cli AWS
AWS propose désormais un gestionaire de secrets intégré avec KMS
3 méthodes différentes permettant de prendre le contrôle d'un cluster kubernetes à partir d'un pod avec une installation de kops par défaut et comment les sécuriser. Il faudrait vérifier si ces failles existent également par défaut avec les autres outils de provisioning kubernetes (kubespray...).
Topologies Terraform pour déployer la configurations IAM nécessaire pour accéder à un compte AWS depuis un autre compte (assume-role) dans une architecture AWS multi-comptes.