Operator on Zwindler's Reflection

Et si on testait le Clever Operator pour Kubernetes ?

Tue, 17 May 2022 10:00:00 +0000

Clever Operator

Il y a quelques mois, je suis tombé sur cet article de Clever Cloud qui disait avoir annonçait la sortie de l’Operator pour Kubernetes.

Nous avons commencé à travailler sur le Clever Operator suite aux retours de certains de nos clients utilisant k8s ou Openshift qui n’étaient pas vraiment satisfaits des solutions de gestion de base de données fournies par ces plateformes.

C’est pas un secret, j’ai beaucoup râlé sur les gens qui disent que Kubernetes c’est compliqué et/ou que ça apporte plus de problèmes que ça n’en résout (cf https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/). On en a notamment parle avec Quentin ADAM ;-).

Mais ce que je ne disais pas clairement à cette époque, c’est que Kubernetes, c’est quand même plus simple quand il s’agit d’autonomiser les devs sur des workloads stateless.

Ou alors du stateful, mais pas trop violent : genre stockage de fichiers (Prometheus par exemple), voire fichiers partagés (avec un FS distribué, partagé entre plusieurs apps ou instances d’une même app).

Par contre, les bases de données, là, on rigole tout de suite beaucoup moins…

Attention, je ne dis pas que c’est impossible. Plein de gens le font, en prod (moi compris). Mais c’est tout de suite un autre niveau de complexité, car il faut gérer le cycle de vie de la base de données, les mises à jours, les pertes de noeuds proprement, etc.

Pour faciliter ça, il existe les “Opérateurs” dans Kubernetes, qui ont pour but d’ajouter toute une logique fonctionnelle pour gérer ça (comme celui pour MongoDB dont je parle dans cet article), mais c’est pas encore parfait.

Ajoutez à cela le fait que DBA, c’est un job “à part”, avec des compétences bien spécifiques et qui nécessite vraiment de savoir ce qu’on fait.

Du coup… j’aurais pu dire (en moins classe) :

Les DBs dans Kube, c’est ch**nt. Ca serait cool si quelqu’un dont c’est l’expertise pouvait gérer ça pour moi, en dehors de Kube.

Qui a dit “Clever Cloud” ?

Clever Operator

Ok, admettons qu’on ait un Kubernetes fonctionnel. On va plugger Clever Cloud dessus pour voir ce qu’on peut faire. Le billet sur le blog de Clever indique 2 manières de déployer l’operator (plot twist, il y en a une 3ème qui est mieux).

La première consiste à utiliser operatorhub.io, un site communautaire pour partager des opérateurs Kubernetes.

Pour utiliser cette méthode, il faut déployer le operator-lifecycle-manager, lui-même un opérateur, dans notre kubernetes. J’ai essayé et j’ai plein de critiques à faire sur ce tool.

Déjà, la doc nous demande de faire un curl | bash (déjà une hérésie en soit), ensuite, il se déploie sans prévenir sur mon contexte Kubernetes par défaut. Enfin, c’est pas bien clair ce qu’il faut faire pour le customiser (notamment pour ajouter nos credentials).

J’ai essayé 1h, j’ai laissé tomber, mais si vous avez l’habitude d’utiliser Operatorhub.io vous aurez peut être des infos que je n’ai pas.

La seconde méthode proposée est de déployer (ou de builder) soit même le container Docker dans notre cluster Kubernetes.

Vous pouvez le built à partir du code source sur Github ou utiliser notre image docker sur Docker Hub. Puis, configurez le. Ça se résume à paramétrer les variables d’environnement CLEVER_OPERATOR_*. Par exemple, vous devez créer un token pour vous connecter à l’API.

Je suis un poil sceptique sur le “ça se résume à” 😏.

Quand on va voir le code du clever operator (ici), on se rend tout de suite compte qu’il va falloir déployer beaucoup de ressources Kube et pas juste un container (~650 lignes de YAML).

En même temps c’est logique, il y a le fichier du Deployment, des Roles, plusieurs définitions de CRDs, bref…

DIY

Edit du 24/05 : depuis la rédaction de l’article, j’ai proposé une PR à Florentin (le dev de la feature chez Clever) pour ajouter une Helm Chart. Le principe est le même, on va devoir renseigner des valeurs dans values.yaml donc vous pouvez quand même dérouler l’article.

cd deployments/kubernetes/helm
helm install clever-operator -n clever-operator --create-namespace -f values.yaml .

Du coup, j’ai déjà spoilé la solution (qui est d’ailleurs mise en avant dans le README.md du dépot Github.com). On va déployer le YAML à la main.

On installe les CRDs :

kubectl apply -f https://raw.githubusercontent.com/CleverCloud/clever-operator/main/deployments/kubernetes/v1.21.0/10-custom-resource-definition.yaml
customresourcedefinition.apiextensions.k8s.io/postgresqls.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/redis.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/mysqls.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/mongodbs.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/pulsars.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/configproviders.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/elasticsearches.api.clever-cloud.com configured

kubectl api-resources --api-group=api.clever-cloud.com
 NAME SHORTNAMES APIVERSION NAMESPACED KIND
 mongodbs mo api.clever-cloud.com/v1 true MongoDb
 mysqls my api.clever-cloud.com/v1 true MySql
 postgresqls pg api.clever-cloud.com/v1 true PostgreSql
 pulsars pulse,pul api.clever-cloud.com/v1beta1 true Pulsar
 redis r api.clever-cloud.com/v1 true Redis

Si je peux me permettre ce commentaire, je trouve ça audacieux, ces shortnames 😱… Attention aux collisions avec d’autres CRDs 🤔.

Et ensuite on récupère et on va modifier le fichier du Deployment

curl -LO https://raw.githubusercontent.com/CleverCloud/clever-operator/main/deployments/kubernetes/v1.21.0/20-deployment.yaml

Préparer la configuration

Bon, à un moment donné, il va bien falloir que je connecte l’API clever cloud avec mon operator, notamment en renseignant les fameuses variables d’environnement CLEVER_OPERATOR_* dont parle l’article.

Si on regarde la tête de notre fichier 20-deployment.yaml, on remarque qu’il existe une ressource ConfigMap prévue pour renseigner les credentials (ligne 100).

---
apiVersion: v1
kind: ConfigMap
metadata:
namespace: clever-operator-system
name: clever-operator-configuration
data:
config.toml: |
[api]
token = ""
secret = ""
consumerKey = ""
consumerSecret = ""

Si vous êtes curieux (c’est mon cas), ce volume est ensuite appelé dans le Deployment

 volumes:
- name: config
configMap:
name: clever-operator-configuration
items:
- key: "config.toml"
path: "config.toml"

Puis monté dans la spec du template de container

 volumeMounts:
- name: config
mountPath: "/etc/clever-operator"
readOnly: true

Note : Idéalement, on voudra éviter de faire ça, dans la vraie vie. Les ConfigMaps (comme les Secrets) dans Kubernetes sont lisibles par beaucoup de monde (la seule différence pour les Secrets, c’est que les chaines de caractères sont base64ifiée. Si si, c’est dans le dico, “base64ifier”) et donc absolument pas adaptés pour la gestion de secrets. On pourrait aussi ajouter ces secrets comme variables d’environnement dans le Deployment (comme proposé dans la méthode 2 par l’article), mais c’est pire (on peut en débattre) encore niveau sécu. Idéalement, il faudra injecter ces valeurs avec un gestionnaire de secret tier, comme Vault par exemple.

Mais où on les trouve, ces valeurs à renseigner ?

Alors je n’avais jamais utilisé Clever Cloud avant, donc ça n’était pas super évident pour moi 😅.

On va d’abord devoir créer une organisation et récupérer son ID (en haut à droite de l’interface). Elle a la forme orga_xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx

Pour la partie consumerKey et consumerSecret, j’ai trouvé avec la documentation officielle. Dans mon organisation côté UI de Clever Cloud, on peut cliquer sur “Create… / an oauth consumer”

Pour la partie token et secret, je n’ai pas trouvé comment en créer un en console web et je n’ai pas trouvé dans la doc.

En bidouillant un peu (monkey testing), j’ai trouvé qu’on pouvait en récupérer en utilisant la CLI de clever cloud

curl -fsSL https://clever-tools.clever-cloud.com/gpg/cc-nexus-deb.public.gpg.key | gpg --dearmor -o /usr/share/keyrings/cc-nexus-deb.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/cc-nexus-deb.gpg] https://nexus.clever-cloud.com/repository/deb stable main" | tee -a /etc/apt/sources.list
sudo apt-get update
sudo apt-get install clever-tools

clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=2.9.1&cli_token=... in your browser to log you in…
We're still waiting for the login process (in your browser) to be completed…
Login successful as Denis GERMAIN <...>

Une fenêtre de navigateur s’ouvre pour se loguer et magie magie, on a un token et un secret

CLEVER_TOKEN=aaa
CLEVER_SECRET=aaa

Tadaa !

Deployer l’opérateur

Tout est prêt, allons-y.

On peut apply le manifest et déployer le deployment

kubectl apply -f 20-deployment.yaml
namespace/clever-operator-system created
serviceaccount/clever-operator created
clusterrole.rbac.authorization.k8s.io/system:clever-operator created
clusterrolebinding.rbac.authorization.k8s.io/system:clever-operator created
poddisruptionbudget.policy/clever-operator created
networkpolicy.networking.k8s.io/clever-operator created
configmap/clever-operator-configuration created
deployment.apps/clever-operator created

Note: la dernière version de l’image Docker du Clever Operator a “un bug” du à une version trop ancienne de la GLIBC. Florentin de chez Clever est en discussion avec Redhat pour fix ça (`GLIBC_2.29’ not found).

~~Il “suffit” de prendre une version plus ancienne de l’image et ça remarche, en attendant un fix définitif.~~ (FIXED)

On teste tout ça

Normalement, là on est bons.

Dans la liste des bases (des add-ons dans la terminology Clever Cloud) supportées par ce operator, il y a donc :

ElasticSearch
MongoDb
MySql
PostgreSql
Pulsar
Redis

La documentation des CRDs est disponible ici et elle est bien faite.

Je ferai des tests plus poussés (déployer une vraie application) plus tard, mais déjà pour tester, j’ai pu lancer un mysql managée;

cat mysql.yml
---
apiVersion: api.clever-cloud.com/v1
kind: MySql
metadata:
namespace: default
name: mysql
spec:
organisation: orga_xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx
options:
version: 80
encryption: false
instance:
region: par
plan: dev
kubectl apply -f mysql.yml
mysql.api.clever-cloud.com/mysql created
kubectl get my
NAME AGE
mysql 14s

L’opérateur a également la gentillesse de nous créer un Secret avec les variables de connexion. C’est donc hyper simple de relier notre app à notre nouvelle DB :

kubectl get secret mysql-secrets -o yaml
apiVersion: v1
data:
 MYSQL_ADDON_DB: aaa=
 MYSQL_ADDON_HOST: aaa==
 MYSQL_ADDON_PASSWORD: aaa=
 MYSQL_ADDON_PORT: aaa==
 MYSQL_ADDON_URI: aaa==
 MYSQL_ADDON_USER: aaa==
 MYSQL_ADDON_VERSION: aaa
kind: Secret

kubectl run -it mysqlclient --image mysql /bin/bash
root@mysqlclient:/# mysql aaa --host aaa-mysql.services.clever-cloud.com --user aaa -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
[...]
mysql>

Conclusion

J’ai été très content de tester cet operator, et surtout de pouvoir échanger avec son développeur, Florentin DUBOIS, qui m’a aidé et à qui j’ai pu remonter quelques petits défauts de jeunesse de l’outil.

L’intégration entre Clever et Kubernetes marche vraiment bien, c’est fluide. La documentation des CRDs est bien faite, on est pas perdus. Enfin, la génération à la volée du Secret contenant les informations de connexion directement dans Kubernetes est vraiment une fonctionnalité bien pratique, puisqu’on voudra souvent monter directement les informations qu’il contient dans un Pod du même namespace.

~~De mon point de vue, il manque une Chart Helm, pour rentre le déploiement simple et flexible de l’opérateur, et sans trop spoiler ça devrait arriver bientôt ;-).~~ (FIXED)

A moi le pouvoir tout puissant des bases de données que je n’ai pas à gérer !

Mes bases MongoDB dans Kubernetes

Mon, 28 Sep 2020 06:15:00 +0000

Introduction

NON MAIS T’ES MALADE OÙ QUOI ? Une base de données (MongoDB en plus, du NoSQL) dans Kubernetes… N’importe quoi ! Les containers c’est pour du Stateless seulement.

Si j’avais écris cet article en 2017, c’est probablement 98% des commentaires que j’aurai reçu ;)

Vous l’avez compris, aujourd’hui, je vais vous présenter le MongoDB Kubernetes Operator, l’outil officiel de chez Mongo qui permet de déployer à tour de bras des bases de données NoSQL dans vos clusters Kubernetes.

Note: Pour ceux qui ne l’ont pas, on parle d’Operator dans Kubernetes pour désigner un ensemble composé d’objets logiques (les CRD, aka Custom Resource Definitions) et d’un (ou plusieurs) Controller pour étendre les possibilités offertes nativement par Kubernetes. C’est très pratique et il y en a plein qui existent, comme par exemple celui pour déployer Prometheus qui est un premiers…

MongoDB Community Kubernetes Operator

Depuis tout à l’heure, je vous parle de MongoDB Kubernetes Operator, mais c’est un abus de langage, car il existe en fait 2 versions différentes de l’Operator : Entreprise et Community.

Vous vous en doutez, la version Community, gratuite, est bien moins complète que la version Entreprise, qui nécessite elle une souscription… Le projet est disponible sur Github : MongoDB Community Kubernetes Operator.

This is a Kubernetes Operator which deploys MongoDB Community into Kubernetes clusters.

If you are a MongoDB Enterprise customer, or need Enterprise features such as Backup, you can use the MongoDB Enterprise Operator for Kubernetes.

Pour ceux qui auraient déjà des bases MongoDB licenciées, sachez donc que la version Entreprise (dispo ici), est plus complète avec des features comme les sauvegardes, ainsi que de plus nombreuses options de déploiements et un Chart Helm.

Prérequis

Allez, on y va.

Pour ce tutoriel, je suis parti d’un cluster AKS vierge, et je partirai du principe que vous avez fait de même, avec un Kubernetes 1.18 (ou mieux) et les VMSS d’activés.

az aks create --resource-group zwindlerk8s_rg --name zwindlerk8s --node-count 3 --node-vm-size Standard_DS2_v2 --kubernetes-version 1.18.2 --ssh-key-value ~/.ssh/mypublicsshkey.pub

Normalement, par défaut, le cluster AKS est configuré avec des StorageClass par défaut. Si vous ne travaillez pas sur AKS (ou un autre cloud provider car ils en ont tous), il vous faudra nécessairement configurer une StorageClass par défaut car nous allons provisionner des volumes (bah oui, c’est pas du Stateless on a dit ;-p).

kubectl --context=zwindlerk8s get StorageClass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
azurefile kubernetes.io/azure-file Delete Immediate true 47m
azurefile-premium kubernetes.io/azure-file Delete Immediate true 47m
default (default) kubernetes.io/azure-disk Delete Immediate true 47m
managed-premium kubernetes.io/azure-disk Delete Immediate true 47m

Si vous avez un cluster on premise par exemple, vous pouvez vous baser sur ces tutoriels que j’ai écris il y a quelques années pour déployer un cluster GlusterFS extérieur et l’intégrer à Kubernetes ou bien encore celui là qui utilise Rook (un autre operator) pour déployer un cluster de stockage Ceph dans Kubernetes.

Installation

OK, on peut commencer !

La première chose à faire est évidemment de récupérer les sources de l’opérateur.

git clone https://github.com/mongodb/mongodb-kubernetes-operator.git
cd mongodb-kubernetes-operator/

Les CRDs

Une fois que c’est fait, on va pouvoir déployer les CRDs (mongodb.mongodb.com`) :

kubectl --context=zwindlerk8s create -f deploy/crds/mongodb.com_mongodb_crd.yaml
customresourcedefinition.apiextensions.k8s.io/mongodb.mongodb.com created
kubectl --context=zwindlerk8s get crd/mongodb.mongodb.com
NAME CREATED AT
mongodb.mongodb.com 2020-06-16T09:29:26Z

L’opérateur (contrôleur)

Pour faire propre, je met toujours les services techniques (ingress controllers, controllers, …) dans un namespace séparé.

Cependant ici, il faut savoir que le contrôleur a besoin d’être dans le même namespace que les bases qu’il est censé déployer.

On créé donc un namespace qui va contenir notre contrôleur et les bases qui iront avec. Je choisi donc un nom très original :

kubectl --context=zwindlerk8s create ns mongodb
namespace/mongodb created
kubectl --context=zwindlerk8s get ns mongodb
NAME STATUS AGE
mongodb Active 13s

Et enfin je le déploie :

kubectl --context=zwindlerk8s create -f deploy/ --namespace mongodb
deployment.apps/mongodb-kubernetes-operator created
role.rbac.authorization.k8s.io/mongodb-kubernetes-operator created
rolebinding.rbac.authorization.k8s.io/mongodb-kubernetes-operator created
serviceaccount/mongodb-kubernetes-operator created

Comme vous pouvez le constater, le retour de la commande nous permet de voir que l’on a créé les objets suivants :

Un Deployment mongodb-kubernetes-operator, qui contient l’intelligence de l’opérateur
Un ServiceAccount mongodb-kubernetes-operator, un Role mongodb-kubernetes-operator et le RoleBinding associé mongodb-kubernetes-operator pour les intéractions entre l’opérateur et Kubernetes.

Au passage, le fait qu’il s’agisse d’un RoleBinding et non par d’un ClusterRoleBinding confirme bien qu’on soit ici sur un opérateur qui n’a pas de droits sur tout le cluster, mais que sur une division de celui ci.

Déployer des bases MongoDB

Maintenant qu’on a configuré notre Operator dans son Namespace, on peut se pencher sur la création d’une base.

En réalité, on ne va que rarement vouloir déployer qu’une seule base. Si vous connaissez MongoDB, vous savez que la base propose nativement une fonctionnalité de haute disponibilité via les ReplicaSets (à ne pas confondre avec les ReplicaSets de Kubernetes, qui sont un autre concept).

Grosso modo, on va avoir 3 instances de la même base, contenant les mêmes données. L’une d’entre elle sera élue PRIMARY, les deux autres seront SECONDARY et la PRIMARY streamera toutes les modifs en écriture au SECONDARY. Basique.

Comme on a maintenant un CRD mongodb dans notre Kubernetes, on peut donc définir avec ces quelques lignes de YAML qu’on veut un nouveau cluster zwindler-mongodb, composé de 3 noeuds dans un même ReplicaSet (mongodb) en version 4.2.6 dans le Namespace mongodb.

cat > zwindler-mongodb.yaml << EOF
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
name: zwindler-mongodb
namespace: mongodb
spec:
members: 3
type: ReplicaSet
version: "4.2.6"
EOF
kubectl --context=zwindlerk8s apply -f zwindler-mongodb.yaml
mongodb.mongodb.com/zwindler-mongodb created
kubectl --context=zwindlerk8s --namespace mongodb get mongodb
NAME PHASE VERSION
zwindler-mongodb

Et PAF ! En deux coups de cuillère à pot, on a un cluster MongoDB (bon en vrai il faut attendre quelques minutes qu’il s’initialise) :

kubectl --context=zwindlerk8s --namespace=mongodb get all
NAME READY STATUS RESTARTS AGE
pod/mongodb-kubernetes-operator-6cfbf85479-bcj85 1/1 Running 0 92m
pod/zwindler-mongodb-0 2/2 Running 0 8m8s
pod/zwindler-mongodb-1 2/2 Running 0 5m55s
pod/zwindler-mongodb-2 2/2 Running 0 3m33s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/zwindler-mongodb-svc ClusterIP None <none> 27017/TCP 8m8s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/mongodb-kubernetes-operator 1/1 1 1 92m
NAME DESIRED CURRENT READY AGE
replicaset.apps/mongodb-kubernetes-operator-6cfbf85479 1 1 1 92m
NAME READY AGE
statefulset.apps/zwindler-mongodb 3/3 8m8s

Tester notre cluster

Vous pouvez me croire sur parole, mais c’est quand même mieux de pouvoir vérifier que le cluster est bel et bien fonctionnel

La confiance n’exclue pas le contrôle

(Vinz, si tu me lis ;-p)

Si vous avez un client mongoDB d’installé sur votre machine, alors le plus simple est de simplement faire du port forward entre vos Pods et votre machine avec kubectl :

kubectl port-forward --context=zwindlerk8s --namespace=mongodb service/zwindler-mongodb-svc 27018:27017
Forwarding from 127.0.0.1:27018 -> 27017
Forwarding from [::1]:27018 -> 27017

A partir de là, je peux utiliser mon client mongoDB pour me connecter et vérifier le status du ReplicaSet :

mongo 127.0.0.1:27018
MongoDB shell version v3.6.3
connecting to: mongodb://127.0.0.1:27018/test
MongoDB server version: 4.2.6
[...]
zwindler-mongodb:PRIMARY> rs.status().members
[
{
"_id" : 0,
"name" : "zwindler-mongodb-0.zwindler-mongodb-svc.mongodb.svc.cluster.local:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
[...]

Je vous passe les détails, mais on voit bien que je me suis connecté ici sur le PRIMARY et si je lis toute la tartine de JSON que me renvoie MongoDB, j’ai bien mes 3 noeuds actifs.

Tester la résilience

Ce qu’il y a de bien avec Kubernetes, c’est que si une application, ou même un serveur complet tombe en panne, tout ce qui a besoin d’être redémarrer/déplacé va l’être, de manière automatique. La base MongoDB sera redémarrée sur un autre serveur et son disque détaché de l’ancien serveur puis rattaché sur le nouveau.

C’est particulièrement pratique si vous êtes chez un cloud provider dont la stabilité des machines virtuelles est contestable (cough cough azure cough), que vous n’aimez pas particulièrement être réveillé la nuit en astreinte et que vous n’avez pas le temps ou les moyens de mettre en place de coûteux mécanismes de redondance.

Note : si vous voulez troller sur ce point précis, sachez que j’ai écris un billet d’humeur à ce sujet il y a 2 ans, je vous invite à venir m’en parler là bas

Concerning Kubernetes : « combien de problèmes ces stacks ont générés ? »

Dans ce test de résilience, je vais donc partir du cas le plus défavorable dans un ReplicaSet MongoDB, à savoir la perte du serveur Kubernetes qui héberge le MongoDB actuellement PRIMARY.

Dans le cas présent, les connexions des applications clients seront coupées environ une seconde, le temps que l’élection se fasse, qu’un SECONDARY devienne le nouveau PRIMARY et que les applications s’y reconnecte. Côté applications, la coupure sera donc assez courte.

Pour autant, côté MongoDB, il manquera un noeud dans le ReplicaSet. Et il faut que ce noeud revienne de lui même à la vie, sinon, la prochaine panne nous sera fatale (on dépassera largement cette “1 seconde” d’indisponibilité).

J’ai donc, depuis ma console Azure, complètement supprimé le noeud aks-nodepool1-42601413-vmss000000. Kubernetes ayant été configuré pour contenir 3 noeuds et qu’il fonctionne avec un VMSS, un aks-nodepool1-42601413-vmss000003 prend donc sa place.

Au bout de quelque minutes, on remarque que zwindler-mongodb-0, la base MongoDB qui a été supprimée, a été Rescheduled par Kubernetes sur aks-nodepool1-42601413-vmss000003 et fonctionne à nouveau.

zwindler-mongodb-0 2/2 Running 0 28m 10.244.3.4 aks-nodepool1-42601413-vmss000003 <none> <none>
zwindler-mongodb-1 2/2 Running 0 89m 10.244.0.5 aks-nodepool1-42601413-vmss000001 <none> <none>
zwindler-mongodb-2 2/2 Running 0 87m 10.244.2.4 aks-nodepool1-42601413-vmss000002 <none> <none>

So far, so good

Et en se connectant une nouvelle fois via le mongo client, on remarque que le nouveau PRIMARY est mongo-1 et que mongo-0 a rejoins le cluster en tant que SECONDARY.

[...]
"name" : "zwindler-mongodb-0.zwindler-mongodb-svc.mongodb.svc.cluster.local:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
[...]
"name" : "zwindler-mongodb-1.zwindler-mongodb-svc.mongodb.svc.cluster.local:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
[...]

CQFD :)

Récap du deuxième jour de Kubecon Europe 2018

Mon, 07 May 2018 14:00:58 +0000

Deuxième jour de Kubecon

Depuis mardi soir, j’étais à Copenhague pour assister à la KubeCon + CloudNativeCon Europe 2018. Si vous n’avez pas lu mon résumé de la journée de mercredi, je vous propose d’aller le lire ici !

Comme la veille, la journée a commencée par des Keynotes animées par Liz Rice & Kelsey Hightower.

Attention : j’ai trouvé qu’il y avait un peu de bourrage de crâne de la part des sponsors, vous risquez de me voir râler un peu ;-)

Kubernetes Project Update

Keynote: Kubernetes Project Update - Aparna Sinha, Group Product Manager, Kubernetes and Google Kubernetes Engine, Google

Dans le même style de la keynote de Liz Rice sur les évolutions dans les projets de la CNCF, cette Keynote a été l’occasion de revenir sur les fonctionnalités qui sont apparues dans les versions 1.8, 1.9 et plus récemment 1.10.

Forcément, en 3 releases, le nombre de fonctionnalités sur un projet de cette ampleur est forcément impressionnant. On peut noter l’ajout des Cronjobs, du support du Machine Learning, du fait Kubernetes peut agir en tant qu’orchestrateur pour des workload Spark et l’operator Spark (ceci à d’ailleurs fait l’objet d’une démo en live dans laquelle ont été comptés les mots dans l’oeuvre de shakespeare).

Sur l’aspect sécurité, Aparna Sinha a lourdement insisté sur gvisor que Google a open sourcé dans le cadre de la conférence (micro kernel en userland permettant de ne pas exécuter les containers directement sur le kernel de l’hôte). On en a déjà eu une couche hier, et des confs étaient prévues dans la journée…

Des progrès ont également été fait avec l’introduction de la CSI (container storage interface), qui, comme la CNI a pour but d’uniformiser la gestion du stockage via des extensions dans Kubernetes.

Et Mme Google d’en remettre une couche pour dire à quel point ils sont sympa d’avoir open sourcé un bout de code dans Prometheus pour permettre à vos Prometheus on premise de streamer les data vers le cloud (Google Cloud au hasard ?). Pour vous faciliter la vie et avoir tout dans un même endroit bien sûr ;).

Accelerating Kubernetes Native Applications

Keynote: Accelerating Kubernetes Native Applications - Brandon Philips, CTO of CoreOS, Red Hat

Brandon Philips de CoreOS (racheté depuis peu par RedHat) est venu nous parler des Operators, ou comment étendre Kubernetes de manière propre. CoreOS est depuis longtemps impliquée dans le développement d’extensions de Kubernetes, notamment parce Tectonic en proposait 2 (les operators etcd & prometheus).

Concrètement, on étend l’API de Kubernetes en créant de nouveaux objets logiques, ce qui nous permet de piloter des logiciels tiers comme s’ils faisaient partie du cluster.

Pour continuer dans cette veine, CoreOS a mis à disposition un Framework, « l’Operator framework », dont le but est de faciliter la création des operators par des sociétés/projets tiers.

Bel effort, il faudra voir si ça prend ou pas.

REX du Financial times

Keynote: Switching Horses Midstream: The Challenges of Migrating 150+ Microservices to Kubernetes - Sarah Wells, Technical Director for Operations and Reliability, Financial Times

Un REX très agréable et très bien présenté par Sarah Wells. Le Financial Times, comme beaucoup de compagnies, fait de l’IT de pointe, non pas parce que c’est son coeur de métier, mais par nécessité.

Quand ils sont passés sous Docker en 2015, le moins que l’on puisse dire c’est que la peinture n’était pas encore complètement fraîche, et une solution maison a du être montée pour répondre aux besoins. Et quand courant 2016, l’ensemble de la core-team qui a passé la production sous Docker est partie d’un coup, il a fallu faire face et trouver une solution.

Choose boring technology

Fin 2016, les équipes en places ont donc considérés les alternatives, ont décidés que Kubernetes étaient le leader émergents avec le plus de chances de devenir le standard de facto (bien vu) et banco.

Enfin, banco, c’est vite dit !

Une grosse partie de la Keynote a justement gravité autour du fait qu’il n’est pas si facile de migrer des centaines de microservices en production d’une solution maison basée sur Docker à un orchestrator comme Kubernetes !

Quelques questions/réflexions qu’ils ont du se poser. J’en ai noté quelques unes :

How do you work in parallel (separate branches or if/else in code) ?
Separate deployment mechanisms vs a single one ?
On which branch must I do the testing ?
Making sure a service will recover if k8s moves it elsewhere
It’s easy to get sucked into making things better

Shaping the cloud native future

Keynote: Shaping the Cloud Native Future - Abby Kearns, Executive Director, Cloud Foundry Foundation

Sincèrement, je n’ai pas compris le message. J’ai juste noté ça :

Cloud native
Cloud everything
Interoperability & Velocity & Innovation
On peut faire tout ça avec Cloud Foundry et l’armée de l’air des états unis économise plein d’argent grâce à nous

Next.

Skip the Anxiety Attack - Build Secure Apps with Kubernetes

Keynote: Skip the Anxiety Attack - Build Secure Apps with Kubernetes - Jason McGee, Fellow, IBM

Kubernetes est un composant majeur pour vos cloud native apps, qui s’intègre nativement dans les processus de types CI/CD, offre une infrastructure flexible, permet de gérer la sécurité…

En plus de ça dans notre super cloud on peut ajouter traquer les vulnérabilités de vos containers, on a du TXT intel et du istio.io, blablabla

Next.

Software’s community

Keynote: Software’s Community - Dave Zolotusky, Software Engineer, Spotify

On sort un peu du marketing mal déguisé et on repasse sur un REX, celui de Spotify !

Plutôt que de faire encore un talk sur leur migration vers K8s et les problèmes qu’ils ont rencontrés, Dave Zolotusky a préféré faire un talk sur ce que leur a apporté la communauté open source et pourquoi il faut contribuer.

Concrètement, Dave venait du monde closed source, avec des supports payant pour chacun des progiciels en production.

Depuis qu’il est chez Spotify et leur migration vers K8s et l’écosystèmes opensource qui gravite autour, à chaque fois qu’ils ont rencontrés un problème complexe, ils se sont tournés vers la communauté et à leur plus grande surprise, ont trouvé rapidement quelqu’un pour les aider.

Que ce soit faire des Ingress cross namespaces ou les problèmes qu’ils ont pu rencontrer en les configurant, ou encore quand ils ont configurés leurs Prometheus, il y avait toujours un dev sur Slack ou un pair de la CNCF pour leur répondre.

Certes, ce talk est un peu bateau dans une conf autour de projets open sources, mais ça fait toujours du bien à entendre, surtout venant d’une société (1) relativement connue, (2) dont ce n’est pas le cœur de métier.

We are all facing the same problems. And even if you’re THAT guy that has a problem no one else has, please share it. Others may look up to you when they’ll face the same problem later.

Et c’est reparti pour le multi-track

Applying least privileges through Kubernetes admission controllers

Applying Least Privileges through Kubernetes Admission Controllers - Benjy Portnoy, Aqua Security

Benjy Portnoy a fait quelques rappels de sécurités sur tout bon cluster Kubernetes.

Même si les recommandation sont un peu « obvious », ça fait toujours du bien de rappeler pourquoi il faut le faire (et le faire ;p).

Privilèges minimum pour tous les utilisateurs, autant sur les objets (limiter à des types d’objets, mais limiter aussi les actions qui peuvent être faites sur cet objet). Ça permet de limiter l’impact de l’erreur humaine ou de l’attaque de type social engineering du type :

curl | bash // kubectl create -f http://fakeapp.example.org.yaml

Benjy a rapidement rappelé qu’il existe un certain nombre de bonnes pratiques qui sont tout simplement décrites dans la documentation officielle de Kubernetes : authentification RBAC, segmentation des réseaux, PodSecurityPolicy, chiffrement des Secrets, enregistrement de tout ce qui se passe sur le cluster à des fins d’audit, …

Mais le focus du talk a surtout été l’utilisation des AdmissionControllers, avec plusieurs exemples :

Allways pull images
Deny escalating exec
Pod security policy
Node restriction
Resource quota

Les possibilités de sécurisations sont infinies et ça nécessite d’y passer du temps car ce n’est pas « built-in » ;-).

Pour finir, Benjy a listé quelques outils permettant d’auditer soit même son cluster ou ses pods. A tester !

Kube-bench
kubehunter (pas encore public)
kubesec.io
Microscanner (ajouter 2 lignes dans tous les Dockerfiles pour avoir un retour sur la sécurité des images sous-jacentes)

Kubevisor

J’avais prévu d’aller voir « Understanding Distributed Consensus in etcd and Kubernetes« , mais, joie des confs multitrack, il n’y avait plus de place dans l’amphi et je me suis fait refouler ! Dommage, j’avais vraiment envie de mieux comprendre etcd, qui pour beaucoup est une bonne grosse boite noire, ce qui est gênant vu le rôle central qu’il joue dans K8s… Je suis donc allé dans l’amphi d’à côté pour voir :

Pod Anomaly Detection and Eviction using Prometheus Metrics - David Benque & Cedric Lamoriniere, Amadeus

Deux personnes de chez Amadeus (avec un accent bien Français ;p) nous ont présentés les problématiques posées par le loadbalancing d’applications fortement dépendantes les unes des autres.

Le pitch du talk était qu’un loadbalancing basique ne permet pas, dans ce genre de cas, d’éviter un effet papillon (un noeud défectueux provoque une panne en cascade). Pour améliorer leur stabilité, les ingénieurs chez Amadeus ont donc recours aux techniques suivantes :

Pour toutes les commnucations inter-microservices, l’utilisation d’un service mesh (Linkerd, istio.io), permettant un loadbalancing plus intelligent, avec des circuit breaker avec du routage intelligent et des fonctionnalités de type open/close/half-open en cas de défaillance.

Pour limiter l’impact d’une panne, ce service mesh leur permet aussi de prendre des décisions en fonction de signaux techniques (consommation mémoire, nombre de connexions).

Cependant, les produits existants ne répondaient toujours pas à l’ensemble de leur problématiques, et ils ont donc présenté Kubevisor, une solution de détection d’anomalies dans les Pods, qui permet entre autre de gérer directement dans Kubernetes des notions de « circuit breaking » par application et avec des règles complet (une partie breaker, une partie activator) via des CRD (custom resources definitions).

101 ways to Break and Recover Kubernetes Clusters

101 Ways to “Break and Recover” Kubernetes Cluster - Suresh Visvanathan & Nandhakumar Venkatachalam, Oath (Yahoo)

Deux personnes de chez Oath (Ex Yahoo) nous ont fait une liste à la Prévert de tous les problèmes qu’ils ont rencontré en production, et les mécanismes qu’ils ont mis en place pour éviter que ça se reproduise.

Si l’intention était bonne, la présentation était très rapide et un peu décousue (trop de cas, on passait trop rapidement d’une slide à l’autre).

Quelques cas qui ont retenu mon attention :

Un ingénieur qui exécute « kubectl delete -f /dir » et qui supprime par erreur un namespace. Un des méthoes pour éviter ça est d’utiliser un Admission controller pour interdire la suppression d’un namespace s’il reste des objets dedans.
Deux Ingress déclarent le même alias (on se retrouve donc avec un genre de loadbalancing chelou qui bascule une requête sur deux sur des services qui n’ont rien à voir). Là encore, le plus simple est d’utiliser un Admission controller pour éviter que ça n’arrive.
Suite à un bug sur les cgroup, tous les nœuds sont passés « Not ready » (alors que les pods fonctionnaient toujours) et ont supprimé tous les pods (eviction queue). Il existe un « Partial Disruption mode », qui permet d’éviter de tout supprimer alors que les nodes ?

Digital ocean

_Global Container Networks on Kubernetes at DigitalOcean - Andrew Sy Kim, DigitalOcean _

Un talk bien costaud sur la façon dont Digital Ocean utilise **BGP **comme couche d’abstraction réseau pour Kubernetes.

Wait… what ?

Au début, j’étais un peu sceptique aussi. Leur problème initial était que dans leur cas, les abstractions de réseau existantes étaient :

trop lentes pour certaines applications (overhead, latence)
Le NAT/masquerading des IPs des pods empêche les développeurs de connaitre
- dans le pod, l’adresse de la source
- depuis un client, l’adresse IP du pod qui a répondu

Au final, l’utilisation de BGP (pas détourné, mais peu commun on va dire) pour fournir un plan d’adressage global, aussi bien pour leurs serveurs physiques que pour leurs pods dans tous leurs DCs permet à Digital Océan d’avoir un réseau virtuel performance et d’avoir une IP accessible de manière globale pour chaque pod.

Au delà de la partie peering des équipements et des serveurs dans le DC (intéressant), il existe une implémentation de BGP pour Kuernetes (Kube-router) qui support eBGP/iBGP, le peering automatique BGP pour les services et les pods.

Cerise sur le gâteau, ils se sont rendu compte après coup qu’avec cette implémentation du réseau ils pouvaient (via des External IPs) rendre directement accessible sur Internet des pods, en fonction de l’endroit où vous êtes sur le globe et via la même IP.

2ème cerise sur le gâteau, ils ont simplifié grandement leur gestion du DNS, en ajoutant une délégation pour que tous les services Kubernetes (de type monservice.monnamespace.cluster.local) puissent être résolus et accessibles depuis le réseau Digital Ocean, même en dehors de Kubernetes.

Linkerd

Linkerd Intro – Andrew Siegner & George Miranda, Buoyant.io

Un démonstaction en live de Linkerd (service mesh), focalisée sur la partie loadbalancing / circuit breaker.

C’est simple, ça marche super bien, mais j’ai été vachement refroidi par le présentateur quand quelqu’un lui a demandé quels étaient les avantages de Linkerd par rapport aux autres solutions a dit :

Linkerd, c’est puissant et stable, mais ça consomme beaucoup de ressources (1Go de RAM). On est en train de réécrire complètement le produit (Conduit). Si vous avez besoin d’un service mesh vraiment aujourd’hui et en production, Linkerd est super. Mais sinon, dans 2 mois on sort une version stable de Conduit. Le mieux, c’est d’attendre Conduit.

J’étais un peu sidéré… mais mes collègues m’ont confirmé que je n’avais pas rêvé.

Reveal your deepes metrics

Reveal Your Deepest Kubernetes Metrics - Bob Cotton, Freshtracks.io

Un talk très sympa par Bob Cotton de Freshtracks.io. Je ne sais pas si c’était volontaire ou pas, mais il n’a pas du tout parlé de sa société (startup dans le monitoring K8s et prometheus, co-fondateur) et est rentré directement dans le vif du sujet : les métriques. On a vraiment senti que c’était un passionné par ce sujet, c’était très fluide malgré une masse d’information conséquente.

Comment déterminer quelles métriques sont importantes ?

Je ne savais pas que ça existait, mais il existe des méthodes pour classifier les métriques pour mesurer l’état de santé d’un service ou d’un cluster :

Four golden signals (Latency / Errors / Traffic / Saturation)
USE method (Utilization / Saturation / Errors) réservée aux composants physiques (machine virtuelle) ou fonctionnels (serveur Apache)
RED method (Rate / Errors / Duration) pour les applications

USE is for Resources
RED is for Services

Je ne vais pas tout détailler ici car c’était très dense, mais le support est à lire si vous devez mettre en place une solution de supervision pour votre application (quelle soit hébergée sur Kubernetes ou pas d’ailleurs).

Et pour finir la journée ?

Pour ne pas nous assommer de Keynotes à nouveau, les organisateurs de la Kubecon avaient prévu une « soirée » à Tivoli Gardens. C’est un genre de parc d’attractions / fête foraine permanente en plein centre de Copenhague.

L’occasion de réseauter pour les plus studieux, ou juste de faire quelques manèges. C’était très sympa ;)

Et vendredi ?

Il ne vous aura pas échappé que la Kubecon dure 3 jours. Malheureusement pour moi… mes amis gréviste de chez Air France ont décidé pour moi que je ne participerai pas au vendredi, en annulant mon Copenhague Paris et en me proposant comme seule et unique solution de passer ma journée de les aéroports (Zurich et Charles de Gaulle notamment).

Un peu dégoûté mais bon… C’est la vie ;-)