Skip to content

AWS Paris Meetup 23 Avril 2020

Qovery - Retour sur EKS

Qovery: Startup PaaS

Il y a 3 ans: débute sur du bare metal K8S dans deux expériences différentes

Mysocial app: 15 nodes, apps stateful, Cassandra/ES à gérer

  • Traefik + TLS via letsencrypt
  • Calico network
  • local storage

Criteo: 4500 nodes (up to 500 nodes par cluster), apps stateful, Cassandra/ES à gérer

  • Machines entre 24 et 48 CPU, 256G de ram, 0 colocation
  • Full host network (car trop de charge) --> on expose directement les pods
  • Pas de load balancer mais du service mesh (les apps utilisaient Consul pour se retrouver)
  • local storage

Startup Qovery:

  • pr une startup, EKS est plus simple et plus rapide que bare metal
  • Attention: EKS en retard de 2 versions sur Kube
  • Il manque surtout l'integration third party: SAML par ex. Faisaible en IAM-SAML mais ensuite pour avoir la synchro entre les users IAM et le RBAC kube ??? Il est obligé de créer un pod utilitaire qui fait la synchro entre RBAC et IAM
  • Full terraform pour le provisioner
  • Fargate non: trop d'abstraction et s'eloigne de l'API kubernetes

Un cluster pour les manager tous

D2SI: consulting cloud + trainer AWS / Docker

Kesley Hightower says: migrer sur EKS. OK, mais:

  • logs? metrics? shipper?
  • vaulting (pour ne pas utiliser le système de Kube, déconseillé par la sécu souvent),
  • APM genre jaeger
  • CI/CD

Archi K8S en équipe

Mode self-service = chaque équipe va gérer son cluster, ses outils, et ça sera le chaos

  • Solution 1: Mutualiser tous les clusters projet sur 1 seul? oui mais si le cluster plante, tout plante!
  • Solution 2: Proposer un meilleur self service: tools déployables sur étagère, suivant la meme recette pour tous

ArgoCD et GitOPS

ArgoCD, incubé récemment sur la CNCF. (concurrent = FluxCD)

GitOps = A chaque commit, on déploie le code sur le cluster, sans intermédiaire artifact etc. Git est la seule source de vérité.

La meme recette pour tous: les outils et les apps doivent etre déployées selon la même méthode: HELM + ArgoCD

Archi K8S conseillée

  • n cluster projet et 1 cluster tools (shared). Le cluster tools contient: ArgoCD
  • Argo CD à installer direct depuis kubectl (l'oeuf et la poule)

Argo CD configuration:

  • on peut tout faire via l'UI full eye candy mais aussi via la CLI argocd.
  • rattacher les clusters de projet à ArgoCD
  • rattacher les git de helm chart à ArgoCD (rappel, helm = definition des pods)
  • créer des projets dans ArgoCD (source = git, destination = cluster autorisés)
  • autre idées: cluster de dev pour déployer immédiatement

Autres takeaways

  • évidemment on a besoin d'une CI notamment pour la validation du code et des images docker !
  • argoCD ne gère que la partie CD comme son nom l'indique (duh)
  • k9s: outil CLI pour gérer le cluster
  • kubectx: outil bash qui permet de changer de contexte de cluster à chaque fois