REX Kubernetes - Iguane Solutions

Iguane Solutions ©2023 - ig1.com
REX Kubernetes @ IG1

Iguane Solutions ©2023 - tous droits réservés - ig1.com
IG1
REX Kubernetes
2
REX EASYBOURSE
1. Qui est EasyBourse
2. Enjeux du secteur
3. Pourquoi
Kubernetes
4. Pourquoi IG1
5. Accompagnement
IG1
6. Résultats
PREMIÈRES
EXPÉRIENCES
1. Blackpills
2. Périmètre
3. Artisanal
4. Monitoring
5. Bilan
EASYBOURSE
1. Amélioration
continue
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
KUBE BY IG1
1. Automatisation
2. Logging
3. StorageClass
4. CI/CD
5. Backups
6. Monitoring
2016 2021 2023…
@ IG1

IG1
3
1. REX EasyBourse

IG1
REX EasyBourse
Intervenants
4
REX EasyBourse
3. Pourquoi Kubernetes
4. Pourquoi IG1
5. Accompagnement IG1
6. Résultats
EasyBourse
CTO
Cyril Janssens
CRO
Iguane Solutions
Cédric Le Moan
Créé en 2006, EasyBourse est une plateforme de
courtage en ligne, ﬁliale à 100% de La Banque
Postale.
Créé en 2000, Iguane Solutions déploie l’ensemble
de son expertise dans le design, la création et le
management d'infrastructures complexes.

IG1
REX EasyBourse
Qui est EasyBourse ?
5
REX EasyBourse
4. Pourquoi IG1
6. Résultats
EasyBourse en quelques chiffres :
1,3
Millions d’ordres de bourse
2 Milliards €
d’encours
105 000
Visiteurs Uniques par mois
2 Millions
Visites par mois

IG1
REX EasyBourse
Quels sont les enjeux du secteur ?
6
REX EasyBourse
4. Pourquoi IG1
6. Résultats
De forts enjeux réglementaires et économiques liés à :
● Image de marque;
● Disponibilité et performance de la plateforme;
● Sécurité des données.

IG1
REX EasyBourse
Pourquoi Kubernetes ?
7
REX EasyBourse
4. Pourquoi IG1
6. Résultats
● Performance grâce l’utilisation d’une plateforme Bare-Metal;
● Capacité d’Auto healing via le redéploiement automatique de Pods;
● Auto scaling des différents micro-services;
● Management simpliﬁé d’un grand nombre de conteneurs.

IG1
REX EasyBourse
Pourquoi avoir choisi Iguane Solutions ?
8
REX EasyBourse
4. Pourquoi IG1
6. Résultats
● Expertise en gestion de clusters Kubernetes à grande échelle;
● Expertise sur du Kubernetes Bare Metal;
● Garanties sur le niveau de disponibilité à travers des SLAs et support 24/7.

IG1
REX EasyBourse
Quel a été l’accompagnement d’Iguane Solutions ?
9
REX EasyBourse
4. Pourquoi IG1
6. Résultats
Plateforme et services entièrement certiﬁés ISO 27001
Déploiement custom et maintien d’un cluster
Kubernetes au sein d’un environnement Bare Metal
Accompagnement dans la conteneurisation de
l’application et de l’orchestration de la plateforme
Kubernetes
Déploiement d’une plateforme dédiée multi-datacenters
(3 sites)
SLA
99,99%

IG1
REX EasyBourse
Quels sont les résultats ?
10
REX EasyBourse
4. Pourquoi IG1
6. Résultats
Capacité d’accueil de la
plateforme en pic de charge
x4
Temps nécessaire
à la migration
÷2
100% uptime depuis le
passage en production
100%
“J’ai trouvé chez Iguane Solutions une concentration de talents qui nous a permis de
construire une plateforme technologique puissante, agile et qui répond aux normes de
sécurité que notre métier impose.”
Cyril Janssens - CTO EasyBourse

Iguane Solutions ©2023 - tous droits réservés
IG1
Deep Dive
IG1
11

IG1
REX Kubernetes
Intervenant
12
Senior Kubernetes Architect
Iguane Solutions
Jonathan Marsaud

IG1
REX Kubernetes
13
REX EASYBOURSE
3. Pourquoi
Kubernetes
4. Pourquoi IG1
5. Accompagnement
IG1
6. Résultats
PREMIÈRES
EXPÉRIENCES
1. Blackpills
2. Périmètre
3. Artisanal
4. Monitoring
5. Bilan
EASYBOURSE
1. Amélioration
continue
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
KUBE BY IG1
1. Automatisation
2. Logging
3. StorageClass
4. CI/CD
5. Backups
6. Monitoring
2016 2021 2023…
@ IG1

IG1
2. Premières expériences : REX Kubernetes
14

IG1
15
Premières expériences
1. Blackpills
2. Périmètre
3. Artisanal
4. Monitoring
5. Bilan
2016
2. REX Kubernetes
Blackpills
● Premiers pas d’IG1 sur Kubernetes en production avec son client Blackpills en
2016
● Habitué à travailler en containers avec des solutions comme docker-compose
○ mais sur une densité de containers bien plus faible
● Mesos (DC/OS) : agrégation de ressources
○ pivot sur Kubernetes (1.2) rapidement

IG1
16
1. Blackpills
2. Périmètre
3. Artisanal
4. Monitoring
5. Bilan
2016
2. REX Kubernetes
Périmètre
● Free for All : tout le monde est root / admin du cluster et chacun compte sur la
pleine coopération et responsabilités partagées (client / IG1)
○ possible car Blackpills regroupe des personnes proches d’IG1 et dignes de
conﬁance
○ n’est pas applicable dans un autre environnement
● Périmètre de responsabilité et de conﬁance établi au sein d’un RACI
○ machines, réseau, stockage
○ core-components & Pods système (CNI, coredns, …)

IG1
17
1. Blackpills
2. Périmètre
3. Artisanal
4. Monitoring
5. Bilan
2016
2. REX Kubernetes
Artisanal
● Utilisation de la CDK : Canonical Distribution of Kubernetes avec Juju
○ seule distribution HA & on-prem à l’époque
○ basée sur la technologie que Canonical utilisait pour des stacks toutes aussi
complexes (OpenStack, Mesos)
● Construit le périmètre core-components de Kubernetes, mais beaucoup d’artisanat
pour parvenir à un cluster utilisable

IG1
18
1. Blackpills
2. Périmètre
3. Artisanal
4. Monitoring
5. Bilan
2016
2. REX Kubernetes
Monitoring
● IG1 utilise pour l’intégralité de ses infrastructures son propre agent de monitoring
nommé Sismograf, qui fait partie de sa suite Sismology
● Plugin Kubernetes sur Sismograf
● Cardinalité
● Long Term Storage
● Lourd à maintenir au ﬁl de l’eau pour Kubernetes

IG1
19
1. Blackpills
2. Périmètre
3. Artisanal
4. Monitoring
5. Bilan
2016
2. REX Kubernetes
Bilan
● Un RACI n’est pas sufﬁsant pour exprimer la responsabilité et le périmètre de
chacun sur Kubernetes
● Différence d’attentes entre un cluster sur cloud-public out-of-the-box vs. cluster
on-prem
● IG1 s’est servi de ces premières expériences pour revoir sa façon d’opérer
Kubernetes

IG1
3. EasyBourse
20

IG1
21
EasyBourse
1. Amélioration continue
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
3. EasyBourse
Amélioration continue
● IG1 n’a pas été le seul à se heurter aux problèmes de Périmètre et Responsabilité
ainsi qu’aux limitations liées à l’on-prem
● Des technologies ont émergé dans les deux domaines entre temps
● Modernisation du périmètre d’IG1

IG1
22
EasyBourse
1. Un nouveau départ
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
3. EasyBourse
Contrainte de l’on-premise : LoadBalancer
● Kubernetes dispose de concepts pré-intégrés pour les fournisseurs de Cloud Public
● Ces concepts nécessitent des adaptations particulières, développées en tant que
logiciels tiers
● L’un deux est MetalLB

IG1
23
EasyBourse
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
● Un autre concept à adapter sur le on-premise est le stockage
● LifeCycle d’un PersistentVolume à gérer
● NSEP : nfs-subdir-external-provisioner
● Pas de gestion de quotas
● Volumes iSCSI gérés manuellement…
3. EasyBourse
Contrainte de l’on-premise : StorageClass

IG1
24
EasyBourse
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
3. EasyBourse
Bonnes pratiques : Role-Based Access Control
● RBAC comme garde-fou du RACI
● EasyBourse est maître des NameSpaces qui lui sont dédiés (applicatifs)
○ IG1 reste maître des NameSpaces qui lui sont dédiés (core-components)
● (Cluster)Role + (Cluster)RoleBinding
● Limitations des Pods privilégiés

IG1
25
EasyBourse
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
3. EasyBourse
Bonnes pratiques : Logging
● FluentBit
○ Collecte depuis n’importe quelle source (logs, metrics)
○ Applique des tags pour enrichir / filtre selon la configuration
○ Envoie à n’importe quelle destination
● Dans le cas d’EasyBourse
○ Collecte depuis la stdout/stderr des Pods (kubectl logs)
○ Applique automatiquement des tags / filtre sur les NameSpaces d’EasyBourse
○ Envoie vers leur stack ELK

IG1
26
EasyBourse
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
3. EasyBourse
Bonnes pratiques : CI/CD
● GitLab dédié
● En dehors du cluster (le registry pose un problème de dépendance circulaire)
● gitlab-runner

IG1
27
EasyBourse
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
3. EasyBourse
Backups
● etcd dumps (topologie du cluster)
● NetApp snapmirror (PersistentVolumes)
● Pas de selfservice

IG1
28
EasyBourse
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
3. EasyBourse
Monitoring
● Sismograf est toujours utilisé pour monitorer la base des systèmes
● Pour les clusters Kubernetes et l’auto-discover de services clients, IG1 s’est appuyé
sur un partenaire : Sysdig for Kubernetes

IG1
29
EasyBourse
2. LoadBalancer
3. StorageClass
4. RBAC
5. Logging
6. CI/CD
7. Backups
8. Monitoring
9. Bilan
2021
3. EasyBourse
Bilan
● Meilleure intégration de Kubernetes on-prem
○ LoadBalancer à la demande
○ StorageClass avec PersistentVolumes à la demande
● Bonnes pratiques
○ RBAC : modèle de responsabilité par restriction des accès
○ Logging : avec FluentBit vers un grand nombre de destinations
● Intégrations IG1
○ Backups sur NetApp
○ Monitoring via Sismology

IG1
4. Kube by IG1
30

IG1
31
Kube by IG1
1. Automatisation
2. Logging
3. StorageClass
4. CI/CD
5. Backups
6. Monitoring
2023
Kube by IG1
Automatisation
● Industrialisation du déploiement et des mises à jour
● Changement de technologie de déploiement : kubeadm
● Passage sur un outil maison qui repose désormais sur k3s

IG1
32
Kube by IG1
1. Automatisation
2. Logging
3. StorageClass
4. CI/CD
5. Backups
6. Monitoring
2023
Kube by IG1
Logging
● FluentBit est reconduit dans Kube by IG1, l’agent a donné entière satisfaction
● IG1 permettra au client de fournir la stack de son choix s’il le souhaite, mais
aimerait également proposer une option par défaut le cas échéant
● IG1 possède déjà un produit interne nommé Journalogy qui fonctionne sur une
base Loki

IG1
33
Kube by IG1
1. Automatisation
2. Logging
3. StorageClass
4. CI/CD
5. Backups
6. Monitoring
2023
Kube by IG1
StorageClass
● Trident by NetApp
● LifeCycle de PersistentVolume
● Création à la demande à partir d’un PersistentVolumeClaim
● Respect des quotas
● iSCSI + NFS

IG1
34
Kube by IG1
1. Automatisation
2. Logging
3. StorageClass
4. CI/CD
5. Backups
6. Monitoring
2023
Kube by IG1
CI/CD
● Tous les nouveaux produits IG1 sont livrés avec une Forge et une CI/CD par défaut
● GitLab
● ArgoCD

IG1
35
Kube by IG1
1. Automatisation
2. Logging
3. StorageClass
4. CI/CD
5. Backups
6. Monitoring
2023
Kube by IG1
Backups
● Velero, backup de topologie + données clientes
● Exploration de chronologie et restauration self-service : rollback simpliﬁé
● Disaster Recovery
● Migration de cluster

IG1
36
Kube by IG1
1. Automatisation
2. Logging
3. StorageClass
4. CI/CD
5. Backups
6. Monitoring
2023
Kube by IG1
Monitoring
● Réinternalisation du service dans Sismology
● prometheus-exporters tiers
● Filtering de metrics

IG1
37
Support 24 / 7 via slack
Multi-regions / datacenters
On-prem self-service
PersistentVolumes
Gestion avancée de
Backup
Gestion avancée des Logs
On-prem hybride :
cloud mutualisé/privé,
bare-metal
Déploiements et mises à jours automatisées
Monitoring avec
Sismology
DevSecOps by design
Forge et CI/CD livrés par défaut
LoadBalancer
Accompagnement
Conseil K8s

IG1
Conclusion
38

IG1
From Future
39
Platform
Management
Kube by
IG1
DevEx GenAI
dev & tech
writer
AIOps
Proteus

IG1
40
Support 24 / 7 via slack
Multi-regions / datacenters
PersistentVolumes
Gestion avancée de
Backup
Gestion avancée des Logs
On-prem hybride :
cloud mutualisé/privé,
bare-metal
Déploiements et mises à jours automatisées
Monitoring avec
Sismology
DevSecOps by design
LoadBalancer
Accompagnement
Conseil K8s

IG1
Questions
41

IG1
Questions
Témoignage EasyBourse
42
Quel a été le plus gros challenge lors de la mise en place de votre plateforme ?
Le passage de Docker à Kubernetes a été un beau challenge car Docker, c’est très embarqué, très tout en un.
Kubernetes c’est l’inverse. C’est extrêmement pointu, extrêmement diffus. Tout est pluggable, on peut même utiliser plusieurs
gestionnaires de réseaux, plusieurs gestionnaires de stockage, ce qui n’est pas forcément évident avec Docker.
Pour tout le reste, tout s’est fait rapidement et facilement dès le début malgré le fait d’avoir un seul cluster réparti sur plusieurs sites
physiques.
Comment faites-vous pour savoir si l’ordre qui n’a pas réussi à être passé vient d’un problème de votre côté ou d’autre chose dans la
chaîne ou du client ?
On peut repérer si le client a essayé de se connecter dans la période pendant laquelle on était HS par exemple, si il n'y a pas eu de
tentative, on peut dire qu’il n’y a pas eu d’impact pour le client.
En revanche, si il a essayé de se connecter, nous avons l’obligation de rembourser le client quelque soit la panne. Cela est très
contraignant, la haute disponibilité est primordiale pour nous, nous avons donc mis en place avec Iguane Solutions les systèmes pour ne
pas tomber.

IG1
Questions
Deep Dive Kubernetes
43
Sur la partie back up, vous gérez tout ce qui est chiffrement de données ?
Nous utilisons en plus du chiffrement par clé commune que permet Velero, le chiffrement intégré à la solution à nos volumes NetApp qui
permettent du NVE.
Vous avez parlé d’utiliser K3s, en gros vous remplacez les binaires kubelet par K3s ?
K3s est une distribution de Kubernetes 100% conforme et placée sous le giron de la Cloud Native Computing Fondation (CNCF).
Celle-ci a la particularité de contenir au sein d’un seul et même binaire k3s l’intégralité des briques nécessaires au déploiement d’un
cluster Kubernetes, et contient donc également le binaire kubelet. Cependant, il ne s’agit pas d’un remplacement total de kubelet, k3s
contient juste celui-ci, tout comme k3s contient aussi le binaire kubelet, crictl, etc.
Vous parlez “d’annule et remplace” des mises à jour, est-ce que K3s pilote également les montées de versions des autres composants
tels qu’etcd, et qu’advient-il lors de changements profonds à leur niveau ?
Tout ce qui est binaire lancé directement sur les machines est contenu au sein du même du binaire K3s. Pour les composants lancés en
tant que Pod, car c’est l’approche que choisit K3s pour héberger les etcds contenant la topologie du cluster (comme le faisait également
kubeadm), celui-ci pilote automatiquement les Pods liés lors d’une mise à jour.
En de très rares occasions, des actions particulières peuvent être indiquées dans les Release Notes d’une version de k3s, actions qui
seront pilotées par l’industrialisation que procure Kube by IG1.

IG1
Questions
44
Comment faites-vous pour la gestion des quotas et le contrôle des quotas ? ?
Trident gère nativement les “requests capacity” sur les PersistentVolumes qu’il crée à partir des informations du
PersistentVolumeClaim. Un Claim de 3Go auto-créera un Volume de la taille correspondante, forçant ainsi un hard-quota.
Et pour Velero, comment faites-vous pour la gestion des backs up, est-ce que vous les mettez sur S3 ou sur des NetApp ?
Le backend de Velero reste le même que pour Trident : une baie de stockage NetApp, offsite du cluster principal afin d’assurer la
conservation des données en cas d’incident. Pour nos clients qui n’ont aucune limitation sur l’usage des GAFAM, nous pouvons aussi
configurer un bucket S3 distant sur la zone AWS de votre choix.
Est-ce que vous avez un plugin Terraform pour provisionner les instances ?
Nous disposons d’un provider Terraform développé et officiel dans Terraform pour OpenNebula, cependant, nous utilisons ce provider
en coulisse de Kube by IG1, le frontend de création de cluster étant pour le moment réservé aux équipes internes, et dans le futur sous
forme d’une WebUI plutôt que d’Infrastructure-as-Code pour le moment.

IG1
Questions
45
Est-ce que les clients d’Iguane ont la possibilité de créer leur cluster ou est-ce qu’ils doivent passer par Iguane ou est-ce que c’est
Iguane qui les crée puis le client manage la partie applicative ?
Dans le cadre de la version 1.0 de Kube by IG1, ce sont des SREs IG1 qui créent les clusters. Le scope limité de la 1.0 étant de donner de
l’autonomie à nos équipes techniques, pour que n’importe qui puisse déployer facilement, rapidement, et de façon conforme un cluster
Kubernetes hautement disponible, sans avoir de connaissances particulières sur Kubernetes.
Dans de futures versions, il est prévu d’avoir un parcours client complet où un utilisateur pourrait simplement, depuis l’Espace Client
Iguane Solutions, déployer un cluster de façon autonome.
De même, une solution de “NameSpace à la demande” avec facturation à la consommation, sans nécessité de déployer un cluster
Kubernetes dédié est actuellement à l’étude.
Comment vous gérez les ressources niveau CPU / RAM quand vous prévoyez de faire du quota et est-ce que vous faites du
provisionning automatique un peu à la Cloud provider GCP et autres ?
Kube by IG1 1.0 répond à la typologie de client que possède actuellement Iguane dans son portfolio : des clusters où le control-plane est
hébergé sur des machines virtuelles, et des workers bare metal, où le nombre de machine est “ﬁni et limité”, nous n’avons donc pas
d’autoscale dans cette version 1.0, mais cela est prévu au ﬁl des versions à venir. Malgré cela, les workers peuvent dores et déjà être
déployés sous forme de Machines Virtuelles, et l’ajout manuel de nouveaux nœuds ne prend que quelques instants.

46
contact@iguanesolutions.com
+33 (0) 7 89 28 57 35

REX Kubernetes - Iguane Solutions

Recommandé

Recommandé

Contenu connexe

Similaire à REX Kubernetes - Iguane Solutions

Similaire à REX Kubernetes - Iguane Solutions (20)

REX Kubernetes - Iguane Solutions