DEV Community: Maxime Guilbert

🔮 Une nouvelle manière de vulgariser la programmation : plonge dans le monde magique de Grand Père Kernel

Maxime Guilbert — Wed, 27 Aug 2025 11:19:27 +0000

Et si apprendre l’histoire et les concepts de la programmation ne passait plus par des tutoriels austères ou des cours bourrés de jargon, mais par un récit épique, quelque part entre le conte fantastique et la chronique technologique ?

🎙️ Grand Père Kernel est un podcast qui dépoussière la vulgarisation informatique. Ici, pas de slides ennuyeuses : chaque épisode t’embarque dans un univers où les langages de programmation sont des écoles de magie et où les machines deviennent de puissants artéfacts capables d’invoquer du code. Tout est raconté avec des images fortes et un ton narratif, pour transformer les concepts techniques en histoires captivantes.

Pourquoi écouter Grand Père Kernel ?

Parce que tu découvriras l’histoire des langages sous un angle inédit, en comprenant les raisons techniques et historiques qui les ont façonnés.

Parce que tu n’as pas besoin d’être expert : les épisodes sont pensés pour être accessibles aux curieux tout en offrant des détails croustillants pour les passionnés de code.

Parce que c’est une façon ludique de se cultiver sur l’informatique, loin du côté “cours magistral”.

Parce qu’un format audio immersif, c’est idéal pour écouter dans le métro, en voiture ou en travaillant.

📚 3 épisodes déjà disponibles :

Java – Le langage qui voulait conquérir le monde

Cobol – Le langage qui refuse de mourir

Assembleur – Le pacte des octets maudits

Chaque histoire mêle réalité technique et fiction narrative, pour que tu comprennes les enjeux et les concepts tout en te laissant embarquer dans une aventure digne d’un roman.

📺 Où écouter ?

Grand Père Kernel est disponible sur YouTube et Spotify. Alors si tu veux découvrir l’informatique comme jamais auparavant, viens voyager à travers ces récits.

Et si le concept te plaît, abonne-toi et partage le podcast autour de toi : ton soutien permettra de développer cet univers et de raconter encore plus d’histoires magiques.

Vérifier les droits d'un utilisateur dans Kubernetes

Maxime Guilbert — Mon, 04 Sep 2023 14:03:00 +0000

Quand on travaille avec un cluster Kubernetes, il se peut qu'on ne se rappelle plus quels sont les droits RBAC que l'on a donné à un utilisateur ou un service account.

Du coup, si on a besoin de savoir si un utilisateur possède des droits sur une action spécifique, au lieu d'aller fouiller dans les RBAC à trouver les droits, on peut utiliser kubectl auth can-i.

Détail de la commande

Utilisateur courant

kubectl auth can-i [action] [ressource]

Présenté sous ce format, la commande va vous permettre de savoir si l'utilisateur avec lequel vous êtes actuellement connecté sur le cluster possède le droit d'effectuer l'action définie sur la ressource définie.

Exemple pour vérifier si l'utilisateur courant peut créer un pod :

kubectl auth can-i create pod

Le résultat que vous obtiendrez sera un simple yes si vous avez le droit. no si vous ne l'avez pas.

Vérifier dans un cluster particulier

La commande définie ci-dessus permet de vérifier les ressources qui ont un scope cluster, ou celles qui ont un scope namespace et qui sont dans le namespace default.

Pour pouvoir vérifier les droits dans un namespace particulier, ajouter l'option --namespace [nom du namespace].

Vérifier pour un autre utilisateur

Si jamais vous voulez vérifier les droits d'un autre utilisateur, vous pouvez ajouter à la fin l'option --as suivi du nom de l'utilisateur qui vous intéresse.

Exemple où l'on veut vérifier si toto peut lister les déploiements:

kubectl auth can-i list deployment --as toto

Vérifier pour un service account

Pour se faire passer pour un service account, il faut aussi utiliser l'option --as, sauf qu'il faut donner une valeur suivant le modèle suivant : system:serviceaccount:[namespace]:[nom service account].

Exemple où l'on veut vérifier si le service account titi dans le namespace test peut supprimer une configmap :

kubectl auth can-i delete configmap --as system:serviceaccount:test:titi

Références

Et voilà, c'est aussi simple que ça et toujours très pratique pour faire quelques validations rapides.

J'espère que ça vous aidera et si jamais vous avez des questions, quelles qu'elles soient (Il n'y a jamais de questions bêtes!) ou des points qui ne sont pas clairs pour vous, n'hésitez pas à laisser un message dans les commentaires ou à me joindre directement sur LinkedIn (même pour parler d'autres sujets!).

Check user RBAC rights

Maxime Guilbert — Mon, 04 Sep 2023 14:02:00 +0000

When we work with a Kubernetes cluster, it happends that we don't remember if a user or service account has a specific right.

So, to help us to not search in all the RBAC definition file, we can use the kubectl auth can-i command.

Command details

Current user

kubectl auth can-i [action] [resource]

With this template, you can check if the current user is able to the action noted in the command on the resource type noted in the command.

Example to check if the current user can create a pod :

kubectl auth can-i create pod

The result will be yes if you have the permissions, or no if you haven't.

Define namespace

The current command will ask for the permissions for cluster-scoped resources or for namespaced-scoped resources in the default namespace.

If you want to ask the rights in a particular namespace, you just have to add the option --namespace [name of the namespace].

Impersonnate another user

If you want to check the permissions for another user, you can impersonnate it by adding the option --as at the end of the command, followed by the name of the user.

Example to check if toto can list deployments:

kubectl auth can-i list deployment --as toto

Impersonnate a service account

To impersonnate a service account, use the same --as option but with the following template : system:serviceaccount:[namespace]:[nom service account].

Example to check if the service account titi in the test namespace can delete configmap :

kubectl auth can-i delete configmap --as system:serviceaccount:test:titi

References

And that's it! Really easy to use and can same some time!

I hope it will help you and if you have any questions (there are not dumb questions) or some points are not clear for you, don't hesitate to add your question in the comments or to contact me directly on LinkedIn.

Monitor an operator

Maxime Guilbert — Mon, 28 Aug 2023 14:01:00 +0000

Having an Kubernetes operator is quite cool, but if everything goes well. To track this and potentially adding alerts on it, we must have metrics.

And that's good, by default with the Golang Operator SDK, we already have a couple of metrics which are available.

Available metrics

The following list is an overview of all the metrics available. To see the full list, please check the Kubebuilder reference.

controller_runtime_reconcile_total : Counter - Total number of reconciliations per controller.
controller_runtime_reconcile_errors_total : Counter - Total number of reconciliation errors per controller.
controller_runtime_reconcile_time_seconds : Histogram - Length of time per reconciliation per controller.
controller_runtime_webhook_requests_total : Counter - Total number of admission requests by HTTP status code.

Add metrics

Even if the generic metrics from Kubebuilder are useful, they may not be enough for your use cases.

For this, there is something to do to easily add more metrics. With the package github.com/prometheus/client_golang/prometheus, create all the metrics you may need

import ( 
    "github.com/prometheus/client_golang/prometheus" 
)

var ( 
    goobers = prometheus.NewCounter( 
        prometheus.CounterOpts{ 
            Name: "goobers_total", 
            Help: "Number of goobers proccessed", 
        }, 
    ) 
    gooberFailures = prometheus.NewCounterVec( 
        prometheus.CounterOpts{ 
            Name: "goober_failures_total",
            Help: "Number of failed goobers", 
        }, []string{"label_1"}
    )
)

Then register them in the metric registry of the operator

import ( 
    "sigs.k8s.io/controller-runtime/pkg/metrics" 
)

func init() { 
    metrics.Registry.MustRegister(goobers, gooberFailures) 
}

Once it's done, congrats! You can use these metrics wherever you want!

goobers.Inc()
goobers.Add(2)

gooberFailures.WithLabelValues("toto").Inc()
gooberFailures.WithLabelValues("titi").Add(2)

Metrics with labels

As you can see in the previous example, if you want to create a metric with labels, you can use New...Vec. It will ask you to give a list of labels name, and then will ask you to use WithLabelValues to fill the value for each label when you will want to update a metric value. Quite useful if you always have the same labels.

Otherwise, you can use .With() to add all the labels you want when updating a metric value.

ex: .With(map[string]string{"toto": "titi"}).Inc()

At the end, an operator is a service like all the others and should be monitored to be sure that everything is going well in your stack. Like a lot of other things, Operator SDK and Kubebuilder help us a lot by simplifying all this process.

Monitorer son opérateur

Maxime Guilbert — Mon, 28 Aug 2023 14:01:00 +0000

Avoir un opérateur c'est bien sympa, mais encore faut-il que tout se passe bien. Pour surveiller ça et potentiellement mettre des alertes dessus, il faut avoir des métriques.

Ca tombe bien, par défaut avec Operator SDK en Go on va avoir un ensemble de métriques déjà présentes pour nous aider à surveiller notre opérateur.

Métriques disponibles

Voici un aperçu des métriques disponibles, pour avoir la liste complète, veuillez aller regarder la référence dans Kubebuilder.

controller_runtime_reconcile_total : Counter - Nombre total de réconciliations faites par un controller
controller_runtime_reconcile_errors_total : Counter - Nombre de réconciliations en erreur par controller
controller_runtime_reconcile_time_seconds : Histogram - Durée par réconciliation par controller
controller_runtime_webhook_requests_total : Counter - Nombre d'appels au Webhook triés par code réponse HTTP

Avoir plus de métriques

Bien que les métriques génériques de base soient très pratiques, il se peut qu'elles ne vous suffisent pas pour couvrir l'ensemble des cas d'utilisation que vous avez.

Pour cela, il existe un moyen très simple d'ajouter de nouvelles métriques. A partir du package github.com/prometheus/client_golang/prometheus, créez l'ensemble des métriques dont vous avez besoin

import ( 
    "github.com/prometheus/client_golang/prometheus" 
)

var ( 
    goobers = prometheus.NewCounter( 
        prometheus.CounterOpts{ 
            Name: "goobers_total", 
            Help: "Number of goobers proccessed", 
        }, 
    ) 
    gooberFailures = prometheus.NewCounterVec( 
        prometheus.CounterOpts{ 
            Name: "goober_failures_total",
            Help: "Number of failed goobers", 
        }, []string{"label_1"}
    )
)

Puis déclarez-les dans le registre des métriques de l'opérateur

import ( 
    "sigs.k8s.io/controller-runtime/pkg/metrics" 
)

func init() { 
    metrics.Registry.MustRegister(goobers, gooberFailures) 
}

Une fois que c'est fait, vous pouvez utiliser ces métriques dans votre code!

goobers.Inc()
goobers.Add(2)

gooberFailures.WithLabelValues("toto").Inc()
gooberFailures.WithLabelValues("titi").Add(2)

Métriques avec labels

Comme vous avez pu le constater dans l'exemple précédent, si vous voulez créer une métrique avec des labels, vous pouvez utiliser New...Vec. Cela va vous demander la liste des labels que vous voulez pour votre métrique, et ça va vous demander de remplir les valeurs de ces labels avec WithLabelValues quand vous voudrez mettre à jour une métrique. Plutôt pratique si vous avez toujours les mêmes labels sur votre métrique.

Autrement, vous pouvez utiliser .With() pour ajouter des labels comme vous le souhaitez.
ex: .With(map[string]string{"toto": "titi"}).Inc()

En dehors de ça le fonctionnement est strictement identique à une métrique sans labels.

En conclusion, un opérateur reste un service comme un autre et il doit lui aussi être surveillé pour s'assurer que tout se passe bien dans votre système. Et comme pas mal de choses avec Operator SDK et Kubebuilder, les choses nous sont pas mal simplifiées avec l'intégration de la librairie golang de Prometheus!

Les questions à se poser avant de démarrer le développement d'un projet

Maxime Guilbert — Mon, 21 Aug 2023 14:22:00 +0000

Dans un contexte où tout va très vite, beaucoup de gens, équipes et compagnies tentent d'aller le plus loin le plus rapidement possible afin d'être les premiers à proposer de nouveaux produits, services et fonctionnalités. Cependant, cette vitesse amène une certaine précipitation qui peut causer du trouble à vos projets, pouvant provoquer le redéveloppement de certaines fonctionnalités entières, des retards sur les planifications ou une instabilité en production.

Entre ce que j'ai pu vivre et tout ce que j'ai pu entendre de personnes en IT, j'ai pu constater que ça arrivait souvent, voir trop souvent. Après ça ne veut pas dire que les personnes/équipes/compagnies ont fait échouer leur projet. Une bonne partie d'entre eux ont réussi a ramener les projets dans la bonne direction et continuent à être utilisés.

Mais de là, différentes questions se posent :

A quel prix ont-ils réussi à faire cela ?
Combien de temps leur a-t-il fallu ?
Est-ce qu'ils ont réussi à conserver la confiance de leurs clients?

En effet, sans parler de l'impact financier direct vis à vis du temps à redévelopper/stabiliser la solution, cela peut aussi avoir un impact financier indirect car des services qui ne fonctionnent pas correctement peuvent influencer la confiance de vos clients envers votre produit. Peut-être qu'ils ne vont pas arrêter d'utiliser directement vos produits, mais peut être qu'ils vont se tourner ailleurs si ils trouvent d'autres alternatives.
(Bien sûr ça n'est pas mesurable facilement, et ça dépend de la criticité des services.)

Et c'est pour cela qu'on va parler de quelques questions qui vous permettront de vous assurer que vous partez dans la bonne direction avec votre projet.

Quels sont les prérequis de mon produit ?

Penser en premier à l'expérience client, puis revenir à la technologie
Citation Steve Jobs

Cette question doit être posée dans le sens où on veut penser au produit final que l'on veut offrir au client. Quelles sont les fonctionnalités? Quels critères ses fonctionnalités doivent suivre? (durée de traitement, sécurité, certifications, volumétrie...)

En effet avoir une idée précise de ce que l'on veut à la fin est important car c'est le point crucial qui fait que beaucoup de projets sont refaits. Et ça arrive partout, ça m'est aussi arrivé par le passé. J'ai eu l'occasion de voir des projets réécrit partiellement ou entièrement à cause ça. Par exemple, arriver après 1 an de dev pour dire "au fait ces traitements doivent être fait en moins d'une seconde" alors que vous n'aviez aucune contrainte jusque là.

Si jamais votre projet est très vaste et qu'il contient beaucoup de fonctionnalités, focalisez-vous en priorité sur les fonctionnalités les plus contraignantes et/ou celles qui ont des besoins particuliers. En effet si au milieu de votre projet complexe vous avez des fonctionnalités qui font des CRUD d'une table de votre base de données et que vous n'avez pas de contraintes de temps de réponse, elles peuvent clairement être mises de côté car il y a de grandes chances qu'elles rentrent dans la stack technologique que vous allez définir pour vos autres fonctionnalités.

Dans quel contexte allez-vous créer ce produit ?

Ici on veut se demander quel type d'architecture on va utiliser, quels outils et technologies on va utiliser...

Par exemple :

Faire des microservices pour une petite application pour lister les todos en local, ça n'est pas intéressant et c'est même overkill.
Avoir un système incluant des boutiques, sites de paiement... dans un monolithe alors que vous savez que vous allez devoir gérer plusieurs boutiques sur le long terme et qu'elles vont partager des fonctionnalités, pas adapté

Aussi il faut voir vis à vis du contexte de l'entreprise. Si tous les développeur connaissent java, ça n'est pas forcément utile d'aller chercher un autre langage si les performances de Java sont suffisantes pour les besoins...

MAIS il faut vérifier que ça correspond avec les besoins technologiques de votre projet. En effet il peut être plus simple que tous les projets d'une même compagnie soit avec la même stack technologique. Ca simplifie les choses et ça permet d'être sûr d'avoir des personnes qualifiées qui peuvent aider/contribuer. Sauf que certaines technologies (langage front, backend, type de base de données...) ne vont pas correspondre à vos besoins. Dans ce cas, le risque est que vous ne le voyez que trop tard car personne ne s'est posé la question avant.

Quelle est notre vision du produit sur le long terme ?

Cette question est très importante car elle peut permettre de préparer le terrain pour le futur. L'idée n'est pas d'analyser directement le futur, mais de récupérer les informations que l'on peut et voir l'impact que ça peut avoir sur le service tel qu'on le conçoit actuellement.

Par exemple :

Est-ce que certaines fonctionnalités vont être réutilisées? Si oui lesquelles? Comment seront-elles partagées? (librairie, microservice...)
Est-ce qu'on vise sur le long terme une grosse augmentation au niveau de l'utilisation du service ?
Est-ce que certains critères (comme la latence) risquent d'être plus strictes dans le futur?

Est-ce qu'on part dans la bonne direction ?

Question simple mais qui, vis à vis des points précédents, vont vous permettre de vous rechallenger sur votre projet et de valider que vous prenez la bonne voie.

Plusieurs solutions s'offrent à vous :

consulter des experts dans le domaine (qu'ils soient dans votre compagnie ou non) afin de savoir si ce que vous voulez faire est faisable
faire des POC ciblées sur vos points d'interrogation

Ces solutions sont un petit investissement en coût et en temps, mais ils peuvent être cruciaux pour vous conforter sur la direction à prendre.

Au final, on a pu voir qu'il n'y a pas de recette miracle pour trouver de quoi on a besoin ou non comme technologies pour un projet. Par contre, on a pu voir qu'avant de partir trop loin dans le développement, il faut :

Prendre un peu de temps en amont pour comprendre quels sont les prérequis indispensables du produit
Analyser le contexte de votre produit, ainsi que celui de votre entreprise
Réfléchir au long terme
S'assurer qu'on part dans la bonne direction

Questions to ask before starting to dev

Maxime Guilbert — Mon, 21 Aug 2023 13:59:00 +0000

In a world where everything goes quick, a lot of people and companies tries to go further quickly as possible to be the first one to have a new feature or product. However this speed brings a certain precipitation which can add some trouble to your project, which can bring some feature redevelopment, being late on schedules or an instability in production.

Between what I lived, everything I red and what I've learned from other people in IT, I saw that it happens frequently, too much frenquently. It doesn't mean that the people/teams/companies will fail in their project. A lot of them succeeded since and some of these products are still used.

But at this point some questions can be asked :

What was the cost of this ?
How much time did they took to redirect their solution ?
Do they keep the confidence and satisfaction from their clients?

Without talking about the direct impact of the time and money lost to redevelop the product, it can have an indirect impact from your customers because some of them will stop to use your product or will lose their confidence in your solution. May be they won't directly leave, but they may check if is there something else to replace your product.
(For sure this is not something which can be easily mesurable as a lot external things can lead to this too.)

And that's why we will talk about some questions that will help you to be sure of the direction you will take with your project.

What are the prerequisites for my product?

Start with the Customer Experience, then work back to the technology
Citation Steve Jobs

This question should be ask to think first at what we want to offer to the client. Which features? Do we want to be fast? secure? ...

Having a precise idea of this is really important, and it's a major cause of rewriting projects. And it happens everywhere. For example if you decide to add after a year of development a duration requirement to have all the processes done in less than a second and you don't have any similar requirements before.

If your project is very large and containts a lot of features, be focused on features with the most contraints and/or the one with particular needs. Indeed if you have one crucial feature and all the other are only managing data in a database without any contraints, they won't need to be a priority because they will fit any context.

In which context are you building this solution ?

Here we want to know which kind of architecture, tools, technologies we want to use.

For example :

Doing microservices for a small todo app won't be interesting
Having a huge system with multiple shops in a monolith knowing that you will have to increase and decrease the number of shops regularly won't be interesting too

Also you must check the context of your company. If all the dev masterize Java, it won't be interesting to take something else if perfomances are correct for your requirements.

BUT you must check that it matches with your requirements. Indeed it's easier to take the same technologies and architectures from all the other projects of your company. But doing this can be a huge trap as it won't fit at all your needs. In that case it can happen that you will only see it too late.

What is the long term vision for the product?

This question is really important as it can prepare the product for futur features. The idea is not to analyze the future features but thinking about what can be asked later and see if some things can be done or prepared now.

For example :

Is there some features which will be reused? If yes, which ones? How they will be shared? (package, microservice...)
Do we expect a huge usage increase in the future ?
Do some criterias will be more strict in the future? (like the latency)

Are we going into the right way ?

A simple question which can challenge you to check if everything is correctly defined and if you are sure about the architecture and the tools to use.

If you are not completly sure, you can :

ask an expert in the domain
do some Proofs of Concepts on the points you are not sure

It can take a bit of time but at the end will reassure you about your choices.

At the end, we saw that there is no miracle receipe to create a project. But we saw that we can prepare and check a lot of things to build great things without losing time by recreating thing.

Pourquoi tout le monde devrait avoir un blog ?

Maxime Guilbert — Mon, 14 Aug 2023 14:21:00 +0000

Avec l'explosion d'internet dans nos quotidiens et de plateformes permettant de partager des connaissances, beaucoup de gens publient des articles qui vont être lus par des gens aux 4 coins du monde sur des sujets plus ou moins précis. Dans l'industrie informatique au sens large, ces articles peuvent être associés à des concepts, des technologies ou autres outils. Et sans forcément s'en rendre compte, on en consomme beaucoup.

Pourquoi ces articles sont importants ?

Ces articles sont importants car ils vont permettre de comprendre plus facilement comment utiliser certains outils ou autres..., voir nous aider à résoudre un soucis que d'autres ont déjà rencontré.

Du coup ces articles sont importants car ils vont nous aider dans notre quotidien pour nous débloquer, nous aider à découvrir de nouvelles choses et à apprendre. Souvent bien plus accessibles que des documentations, il y a souvent un côté ludique qui permet de mieux comprendre certaines notions qui peuvent être complexes (notamment grâce à des exemples ou schémas).

Pourquoi tout le monde devrait avoir un blog ?

Dans le monde de l'informatique, on va souvent chercher de l'information en ligne, du coup avoir un blog permettrait de partager des découvertes, des conseils, des problèmes que vous avez rencontré, des bonnes pratiques...

Ne vous êtes-vous jamais dit : "C'est dommage, personne ne parle du problème X ou du sujet Z" ?

Si c'est le cas, vous comprendrez pourquoi c'est important de partager ces informations.

De plus, beaucoup d'outils sont dans des "niches" qui ne sont pas forcément faciles à découvrir. Le fait d'écrire des articles dessus permettra à plus de monde de découvrir certaines choses qui devraient être partagées au plus grand nombre. (Dans ce cas-là, je pense énormément aux outils open-source)

Le gain d'avoir un blog

Alors sans parler du côté monétaire, de la réputation et autres choses du genre, car ça va dépendre d'énormément de facteur externes. Avoir un blog a d'énormes gains pour vous.

Maîtrise de sujet

En effet un principe bien connu dans le monde de l'éducation dit qu'une personne souhaitant aider à retenir un sujet ou être capable de le maîtriser un minimum, doit être capable de l'expliquer à d'autres personnes. Cela peut se faire avec des termes plus simples, des exemples ou autres.

Cela ne vous rappelle pas quelque chose?

Plus tôt on disait que justement les articles postés en lignes sont souvent des explications plus simples de sujets potentiellement complexes. Il est sûr qu'il y a des personnes qui sont des vulgarisateurs et qu'ils n'ont pas besoin d'écrire ces articles pour pouvoir être capable de maîtriser un sujet. Mais je suis sûr à 100%, vu que j'en fais parti, qu'il y a des gens qui écrivent des articles pour aider à voir si ils sont capables de ressortir tout ce qu'ils ont pu apprendre sur différents sujets.

D'expérience, je peux vous garantir que ça aide à retenir plus facilement beaucoup d'informations car le processus de rédaction d'un article va vous faire travailler pour expliquer des concepts avec vos termes. Et le fait d'utiliser vos mots pour expliquer des concepts va faciliter la mémorisation car vous n'aurez pas forcément besoin de retenir des termes qui pourraient vous sembler barbare et/ou trop compliqués à retenir seuls.

Amélioration de la rédaction

Un autre point d'amélioration concerne la rédaction. En effet, être capable d'expliquer des choses demande à être un minimum structuré et clair, du coup écrire des articles va (plus sur le long terme) vous aider à améliorer dans ce domaine.

Après ça ne veut pas forcément dire que vous serez capable après d'écrire des paragraphes entiers pour expliquer des choses. Mais potentiellement vous allez être capable de capturer l'essentiel en quelques lignes.

L'amélioration dans une langue étrangère

Ce point ne concerne pas forcément tout le monde, mais est quelque chose qui m'aide pas mal : l'amélioration dans une langue étrangère.

En effet, afin d'être capable de partager mes articles aux plus grands nombre, je rédige aussi mes articles en anglais. Bien que ça soit la langue utilisée dans quasiment toutes les documentations techniques, être capable de réexpliquer certaines choses va demander de connaître d'autres mots, tournures de phrase et autres, qui vont au fil du temps aider à s'améliorer dans la communication dans une langue étrangère.

Conclusion

Voilà pourquoi, je pense, que tout le monde devrait avoir un blog. Alors on est d'accord que c'est un énorme investissement en temps qui potentiellement ne rapportera rien. Ca fait trois ans que j'écris des articles en ligne et je n'ai pas touché un centime de tout ça. Pourtant je trouve ça quand même intéressant de le faire et j'encourage les gens à s'essayer. Pas besoin d'avoir un sujet ultra pointu, les 3/4 de mes articles concerne des petites astuces ou des problèmes que j'ai rencontré.

Why everyone should have a blog ?

Maxime Guilbert — Mon, 14 Aug 2023 14:20:00 +0000

With the explosion of internet in our lifes and platforms to share informations, a lot of people are publishing posts on differents subjects. In the IT industry, these posts can be about a concept, technologies or tools. And we read a lot of them.

Why these posts are so importants?

These posts are importants because it will often help us to understand how to use something, how can we improve our skills... or resolve an issue that someone else has already encountered.

Often more accessible than documentations, they have a playful way to teach things that helps to understand complexe notions notably with examples and/or schemas.

Why everyone should have a blog ?

In this IT world, we search informations online everyday, so having a blog will let you share what you've experienced, what you've discovered, some tips, how to resolve particular issues...

Don't you ever wondering why there's no posts on a particular subject or on a particular error?

If yes, you will understand why it can be important to share this kind of informations.

Also a lot of tools are in niches which are not easy to find and/or understand. So having posts about it will help to expose it and having more informations for anyone which want to use it and understand how it works.

Winnings to have a blog

Without talking about money or other things like that, having a blog can have huge payoffs for you.

Subject mastering

A principe of education says that if someone wants to memorize easily something or to start to master a subject, they must be able to explain with their own words the subject. May be in a easier way with examples.

It doesn't make you think about something?

Earlier we said that articles that are posted online are often simple explainations about more complexe concepts. For sure some people don't need to write these posts to memorize and master the subject, but a lot of people like me are writing posts to help them to see if they are able to explain and summarize all the informations they learned about a subject.

From my experience, I garantee you that it helps me to memorize a lot of things. The work to find a way to explain the subject with your own words is really powerful. Because as you already know the words you are using, you don't have to remember the definition of a lot of new words. And naturally the information will be easier to remember.

Improve writing skills

By writing posts you will improve your writing skills. Being able to explain things requires to be a bit organized. So writing will help you with this.

Also it will help you to figure out what is the most important informations to share in a few lines.

Improve in a foreign language

It doesn't concern everyone, but it's something that help me a lot : improve my skills in another language.

To be able to share my posts to a lot of people, I write my posts in english. Even it's the language used is almost all the technical documentations, being able to explain something in english requires more vocabulary at least and helps to improve our communication skill in this language.

Conclusion

For all these reasons, that's why I think everyone should have a blog. For sure it's a huge time investment for may be nothing. (I wrote technical posts for the last 3 years and I didn't earn anything) But it's still interesting to do it and I encourage anyone to give a try.

K8s operator - Synchronize resources outside Kubernetes cluster

Maxime Guilbert — Mon, 07 Aug 2023 13:09:00 +0000

When we automate tasks/resources in a Kubernetes Cluster, we first think about managing Kubernetes resources. But we must not forget that we are not limited to what is presented to us.

Like every post since the begining of this serie, we will talk about the Operator SDK, the Go framework to create operators. And who says Go, says that we can :

read into a database
call an API
write a message in a queue
...

Indeed, everything which is possible in Go is possible in your operator.

Why it is interesting?

For a simple reason, you are not limited to your Kubernetes cluster context to automate tasks and resources management.

Here is a simple example: You manage Prometheus and/or Thanos instances in your cluster with your operator, but you have a single Grafana instance for all these Prometheus/Thanos instances and it's outside of your cluster. In this case, if you want to manage the datasource in Grafana, you must do it through the API.
And here the operator power skyrockets because you can use any API or service which manage resources. You don't need to implement something particular or migrate it into your Kubernetes cluster.

For sure, it won't be useful for everyone but think about the following example :
You are in a compagny which offer several services to your clients, including :

a metric collector with Promtheus
a Grafana instance to monitor all the metrics The issue is that each element is managed by a dedicated operator on a dedicated Kubernetes cluster. How can you automate the management of a customer stack ?

Answer : With APIs !

With dedicated APIs to manage your resources (by using the Python Kubernetes library for example) or by using the Kubernetes API, you can have an operator which can manage all the stack by calling all the other operators with these APIs.
From this, all the spread stack can be automated!

You want to support me?

Synchroniser des ressources hors cluster

Maxime Guilbert — Mon, 07 Aug 2023 13:08:00 +0000

Quand on automatise des tâches avec un opérateur Kubernetes, on va surtout penser au fait que l'on peut gérer des ressources Kubernetes. Cependant il ne faut pas oublier qu'on n'est pas forcément limité à ce qui nous est présenté.

Comme depuis le début de cette série, on va se concentrer sur le framework Go d'Operator SDK. Et qui dit projet en Go, dit que l'on peut :

lire dans une base de données
faire appel à une API
écrire un message dans une queue
...

En effet, tout ce qui est possible en Go est finalement possible à intégrer dans un opérateur.

En quoi c'est intéressant de faire ça?

Pour une raison simple, vous n'êtes plus limité au contexte de votre cluster Kubernetes pour automatiser des éléments.

Prenons un exemple simple, vous créez des instances de Prometheus ou Thanos dans votre cluster Kubernetes via votre opérateur, mais il n'y a qu'un seul Grafana qui est utilisé dans toute votre entreprise et il ne se trouve pas dans votre cluster. De ce fait, si vous voulez automatiser la gestion des datasources dans ce Grafana, vous devrez passer par son API.
Et c'est là que la puissance de l'opérateur se décuple, car vous pourrez utiliser toutes les APIs et autres services qui gèrent des ressources dans votre compagnie. Pas besoin d'avoir à réinventer la roue ou de migrer le système en question pour qu'il soit dans Kubernetes.

C'est sûr que ça ne sera pas forcément utile à tous, mais imaginez l'exemple suivant:
Vous êtes dans une compagnie qui offrent un ensemble de services pour vos clients. Cela comprend un système de récupération de métriques via Prometheus et une instance de grafana dédiée. Chacun de ces éléments sont gérés par des opérateurs distincts, sur des clusters séparés.
Comment pourriez-vous faire pour gérer automatiquement vos ressources dans tous ces clusters ?

Réponse : Grâce aux APIs !

En créant des APIs dédiées pour gérer vos ressources (en utilisant une librairie comme celle pour dédiée Python) ou en utilisant l'api kubernetes, vous pourriez avoir un opérateur qui va s'occuper d'appeler les apis sur vos différents clusters afin de s'assurer que toutes les ressources demandées sont bien créées.
A partir de là, des infrastructures divisées et potentiellement compliquées à être automatisées toutes ensemble peuvent le devenir!

Vous voulez me supporter?

Comment minimiser votre emprunte carbone avec Kube-Green?

Maxime Guilbert — Mon, 31 Jul 2023 13:00:00 +0000

On est dans une ère où le numérique est de plus en plus présent dans nos quotidiens, mais le numérique (surtout tout le matériel qui peut être derrière et l'énergie qu'il consomme) est une source de pollution.

Tout comme vous pouvez participer au tri des déchets et à la réutilisation pour limiter votre emprunte carbone, on va voir comment vous pouvez le faire avec votre cluster Kubernetes! (En plus ça peut vous sauvez des coûts si votre cluster est dans le cloud)

Kube-Green

Kube-Green est un opérateur qui vous permet de réduire le nombre de réplicas de vos déploiements à 0 et de suspendre vos CronJob en dehors de vos "journées de travail".

L'objectif est simple, couper les pods et jobs qui tourneraient pour rien la nuit et les weekends, avant de les redémarrer le matin des jours en semaine. De ce fait, l'ensemble de ces processus ne tournent pas "dans le vent", produisant du CO2 et peuvent vous permettre de scale-down votre cluster si il est sur AWS par exemple.

Dans quels cas l'utiliser?

C'est sûr que ça n'est pas à utiliser sur votre production, à moins que cette dernière ne soit utilisée que durant les heures de travail. Cet opérateur s'oriente principalement pour tous les environnements de développement ou de tests qui restent souvent démarrés en permanence pour rien.

Est-il possible d'exclure certains traitements?

En effet c'est une question que vous pouvez vous poser : "Est-il possible d'exclure certain traitement?" car en effet peut être qu'il y a certaines fonctionnalités de votre cluster de développement qui doit rester allumer en permanence. Sachez que c'est possible, on le verra au niveau de la configuration pour le détail, mais c'est possible.

Mise en place

Toutes les informations concernant l'installation proviennent de la documentation de Kube-Green. N'hésitez pas à aller y faire un tour pour avoir la dernière version de la documentation.

Prérequis

Sachez qu'à ce jour Kube-Green ne fonctionne qu'avec les versions 1.19 à 1.26 de Kubernetes et OpenShift v4.

De plus, il faut que cert-manager soit déjà installé.

Installation

Plusieurs possibilités d'installation sont offertes par Kube-Green, mais on va uniquement utiliser dans cet exemple l'installation via kubectl apply.

Si vous voulez installer la dernière version de Kube-Green, vous pouvez utiliser la commande suivante

kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml

Par contre, si vous voulez installer une version précise de Kube-Green, utilisez la commande suivante en remplaçant ${RELEASE_TAG} par le numéro de la version de la release qui vous intéresse.

kubectl apply -f https://github.com/kube-green/kube-green/releases/download/${RELEASE_TAG}/kube-green.yaml

*/!\ Attention : Si vous utilisez Kube-Green dans un cluster qui est dans le cloud /!\*
En effet la documentation mentionne que certains problèmes peuvent être rencontrés dans GKE et AWS. Par conséquent, allez faire un tour dans la documentation pour vérifier vos configurations avant d'aller plus loin.

Configuration

Une fois que l'opérateur est installé, vous pourrez créer une ressource SleepInfo qui vous permettra de définir quelles ressources doivent être arrêtées, quand, et quand est-ce qu'elles doivent être redémarrées.

Sachez que SleepInfo est une ressource qui n'agit que dans le namespace dans lequel il est déployé c'est à dire qu'il faut déployer une instance de SleepInfo dans chacun des namespaces dans lequel on veut utiliser Kube-Green. (Ce qui permet d'éviter de couper l'ensemble des déploiements essentiels au bon fonctionnement du cluster)

apiVersion: kube-green.com/v1alpha1  
kind: SleepInfo  
metadata:  
    name: working-hours  
spec:  
    weekdays: "1-5"  
    sleepAt: "20:00"  
    wakeUpAt: "08:00"  
    timeZone: "Europe/Rome"

L'exemple précédent est le cas le plus simple d'utilisation de Kube-Green où tous les déploiements vont être arrêtés à 20h (heure de Rome) tous les soirs du lundi au vendredi, et redémarrés du lundi au vendredi à 8h (heure de Rome).

Afin de mieux comprendre comment fonctionne SleepInfo, on va faire un tour de chacun de ses champs puis voir quelques exemples exposant différent cas.

SleepInfo : Champs

weekdays : Permet de définir les jours de la semaine où l'opérateur doit agir.
- 1 est pour Lundi
- 1-5 est du Lundi au Vendredi
- 2-6 est du Mardi au Samedi
- * est pour tous les jours de la semaine
sleepAt : Défini sous le format HH:mm, il permet de déterminer à quelle heure les ressources doivent être arrêtées. (ex: 19:00, 08:53: 23:45)
wakeUpAt : [Optionnel] Défini sous le format HH:mm, il permet de déterminer à quelle heure les ressources doivent être redémarrées. (ex: 19:00, 08:53: 23:45)
timeZone : [Optionnel] Permet de définir le fuseau horaire auquel les heures données correspondent.
- Cette valeur doit correspondre au nom d'un fuseau horaire défini par la spécification IANA. (Colonne TZ identifier dans Wikipedia - Fuseau Horaire)
- Par défaut cette valeur est à UTC.
suspendDeployments : [Optionnel] Booléen permettant de savoir si l'opérateur doit arrêter les déploiements du namespace.
- Par défaut cette valeur est à true.
suspendCronJobs : [Optionnel] Booléen permettant de savoir si l'opérateur doit arrêter les cron jobs du namespace
- Par défaut cette valeur est à false
excludeRef : [Optionnel] Tableau d'objets permettant de définir les références des déploiements ou cron jobs à ignorer pour la mise en sommeil.
- apiVersion : Version de la ressource à exclure. Actuellement sont supportés : apps/v1, batch/v1beta1 et batch/v1 (à ne pas définir si vous utilisez matchLabels)
- kind : Type de la ressource à exclure. Actuellement sont supportés : Deployment et CronJob (à ne pas définir si vous utilisez matchLabels)
- name : Nom de la ressource à exclure (à ne pas définir si vous utilisez matchLabels)
- matchLabels : Liste des labels pour identifier les ressources à exclure (A ne pas définir si vous utilisez name, apiVersion et kind)

Cas d'utilisations

Tout arrêter sauf api-gateway

apiVersion: kube-green.com/v1alpha1
kind: SleepInfo
metadata:
  name: working-hours
spec:
  weekdays: "1-5"
  sleepAt: "20:00"
  wakeUpAt: "08:00"
  timeZone: "Europe/Rome"
  suspendCronJobs: true
  excludeRef:
    - apiVersion: "apps/v1"
      kind:       Deployment
      name:       api-gateway

Dans cet exemple, on peut voir que l'on cherche à tout éteindre (Déploiements & CronJob) à 20h chaque soir en semaine et à les redémarrer à 8h en semaine, à l'exception du déploiement "api-gateway".

Cas utile si vous avez peu de ressources à exclure du processus.

Tout arrêter sauf les ressources avec un label particulier

apiVersion: kube-green.com/v1alpha1
kind: SleepInfo
metadata:
  name: working-hours
spec:
  weekdays: "1-5"
  sleepAt: "20:00"
  wakeUpAt: "08:00"
  timeZone: "Europe/Rome"
  suspendCronJobs: true
  excludeRef:
    - matchLabels: 
        kube-green.dev/exclude: true

Dans cet exemple on voit que cette fois-ci tout sera éteint, à l'exception de l'ensemble des ressources ayant le label kube-green.dev/exclude: true.

Ce cas est à privilégier si vous avez beaucoup de ressources dans un namespace et que nombre d'entre elles sont à exclures.

Arrêter que les CronJob

apiVersion: kube-green.com/v1alpha1
kind: SleepInfo
metadata:
  name: working-hours
spec:
  weekdays: "*"
  sleepAt: "20:00"
  wakeUpAt: "08:00"
  suspendCronJobs: true
  suspendDeployments: false

Afin d'arrêter uniquement les CronJob, il vous suffit de mettre suspendCronJobs à true et suspendDeployments à false.

Sans redémarrage

apiVersion: kube-green.com/v1alpha1
kind: SleepInfo
metadata:
  name: working-hours
spec:
  weekdays: "1-5"
  sleepAt: "20:00"
  timeZone: "Europe/Rome"
  suspendCronJobs: true
  excludeRef:
    - apiVersion: "apps/v1"
      kind:       Deployment
      name:       api-gateway

Cet exemple nous montre qu'il est possible de ne pas définir d'heure de redémarrage. Sur le coup on peut se demander en quoi ça peut être utile, et finalement il y a un cas simple : pour vos environnements de test.

Ca dépend de votre contexte, mais il se peut que vous ayez des environnements qui ne soient utilisés qu'une fois par mois pour effectuer des tests dessus. Si c'est le cas, le redémarrer tous les jours est inutile, et donc ne pas définir d'heure de démarrage est bien utile.

Liens

Conclusion

Kube-Green est un projet prometteur qui, je l'espère nous permettra d'aller plus loin dans la limitation de notre impact sur la planète. Dans l'immédiat je pense aux daemonsets qui pourraient être coupés si ils sont inutiles, le fait de scale down automatiquement à 0 une ressource non-exclue si on déploie pendant les heures de "sommeil", voir de pouvoir interagir avec d'autres opérateur pour aller couper d'autres ressources (notamment des ressources dans AWS ou GCP avec Crossplane)...

C'est peut être pas grand chose, mais comme pour tout le reste, si on fait tous un peu d'efforts par-ci et par là, toutes ces petites contributions vont nous permettre de faire quelque chose de grand!