Vincent FRICOU | Blog

Partage IP entre services avec Cilium Load Balancer

Wed, 01 Apr 2026 00:00:00 GMT

Le Contexte du pourquoi ?

J’avais un besoin relativement simple, je voulais pouvoir exposer un service Kubernetes sur une VIP en mode LoadBalancer.
VIP gérée par Cilium bien sûr. J’ai une CNI suffisamment outillé pour ne pas avoir à ajouter d’autres choses. Non mais !

Cette opération peut être quand même super pratique pour plein de raisons :

Un serveur DNS hébergé dans Kubernetes (et pourquoi pas après tout ?)
Un collecteur de logs type rsyslog
Un service Web qui serait à même de gérer du protocole QUIC (HTTP/3) et HTTP(s)
Tout ce qui peut nécessiter une double stack protocolaire…

Objectif et le but

Pour poser un exemple concret, et surtout un cadre facile à déployer pour faire mes tests, je ne suis pas allé chercher très loin. CoreDNS comme serveur DNS répond largement au besoin de ce test.

Donc l’idée est simple : je veux pouvoir depuis l’ensemble de mes assets hors de mon cluster Kubernetes, faire des requêtes DNS vers le CoreDNS que je déploie pour mes tests. (Oui, je laisse le CoreDNS interne de Kubernetes tranquille.)

Pour rappel, le DNS est assez classiquement utilisé en mode UDP, mais il est aussi possible de le faire en mode TCP, et surtout, c’est nécessaire dans certains contextes comme le cas où il y a beaucoup d’enregistrements à retourner et que ça ne rentre pas dans un paquet UDP.

Donc voilà, je veux exposer mon service DNS sur une IP externe à mon cluster, et que celle-ci soit aussi bien accessible en UDP qu’en TCP.

Et c’est là que ça se complique.

Par défaut, et sauf si j’ai raté quelque chose, il n’est pas possible de positionner un service Kubernetes de type LoadBalancer en écoute sur le même port (dans mon cas le 53) et mode UDP ET TCP.

Comment ça se passe alors ?

Je ne vais pas vous détailler l’installation de CoreDNS à coup de chart Helm, ce n’est pas le but. On considère donc que tout ce qu’il nous faut en termes de déploiement et de pod est déjà en place et que tout le monde vas bien.

La VIP pour CoreDNS

Tout d’abord, il faut créer une VIP pour pouvoir adresser le service de CoreDNS en mode LoadBalancer.

Pour faire ça, on va chercher dans les classiques CiliumLoadBalancerIPPool pour la configuration de la VIP et CiliumL2AnnouncementPolicy pour traiter l’annonce ARP afin qu’elle soit vu sur le réseau :

cdns-vip.CiliumLoadBalancerIPPool.yaml
cdns-vip.CiliumL2AnnouncementPolicy.yaml

apiVersion: "cilium.io/v2"
kind: CiliumLoadBalancerIPPool
metadata:
    name: "cdns-vip"
    namespace: coredns-external
spec:
    blocks:
        - cidr: "192.168.0.153/32"
    serviceSelector:
        matchLabels:
            "io.kubernetes.service.namespace": "coredns-external"
            "cilium.lbpool/name": "coredns-external

apiVersion: "cilium.io/v2alpha1"
kind: CiliumL2AnnouncementPolicy
metadata:
    name: cdns-vip
    namespace: coredns-external
spec:
    serviceSelector:
        matchLabels:
            "io.kubernetes.service.namespace": "coredns-external"
            "cilium.lbpool/name": "coredns-external"
    externalIPs: false
    loadBalancerIPs: true

Bon, jusqu’ici, ça reste du classique au niveau de la configuration de la VIP avec Cilium.
On indique quelle IP on veut, et quels sont les labels permettant de l’attacher au bon service.

Et le partage du coup ?

Eh bien, c’est là que ça se corse un peu (mais vraiment pas beaucoup).

En faisant mes recherches, je suis en premier lieu tombé sur la façon de faire avec MetalLB pour permettre du partage d’adresse IP via une annotation sur les services : metallb.io/allow-shared-ip

Et là, je me suis dit « attends… MetalLB sait le gérer, à quel moment Cilium n’en serait pas capable ? ».

Du coup, c’est parti, je fouille la doc… Et là… C’est la révélation, et c’est affligeant de simplicité.

Je vous mets le lien vers la doc de Cilium qui traite du sujet ici.

En fait, de façon triviale, Cilium traite la chose exactement de la même façon que ce que fait MetalLB. Soit via une simple annotation sur le service (lbipam.cilium.io/sharing-key) !

Alors quand même, il faut en parler un minimum. Parce qu’il y a plusieurs choses à prendre en comptes :

Par défaut, une même adresse ne peut pas être partagée entre plusieurs namespaces
Il est impératif que la valeur fournie dans l’annotation soit commune à l’ensemble des services qui partageront la même VIP

Bref, j’ai trouvé mon bonheur, c’est le moment de tester ça.

Je crée donc deux services pour pouvoir exposer mon fameux port 53 sur une seule et même adresse IP :

cdns-udp.Service.yaml
cdns-tcp.Service.yaml

apiVersion: v1
kind: Service
metadata:
    annotations:
        lbipam.cilium.io/sharing-key: "cdnsext1"
    labels:
        app.kubernetes.io/instance: coredns
        app.kubernetes.io/name: coredns
        cilium.lbpool/name: "coredns-external"
    name: cdns-lb-udp
    namespace: coredns-external
spec:
    type: LoadBalancer
    ports:
        - name: udp-53
          port: 53
          protocol: UDP
          targetPort: 53
    selector:
        app.kubernetes.io/instance: coredns
        app.kubernetes.io/name: coredns

apiVersion: v1
kind: Service
metadata:
    annotations:
        lbipam.cilium.io/sharing-key: "cdnsext1"
    labels:
        app.kubernetes.io/instance: coredns
        app.kubernetes.io/name: coredns
        cilium.lbpool/name: "coredns-external"
    name: cdns-lb-tcp
    namespace: coredns-external
spec:
    type: LoadBalancer
    ports:
        - name: tcp-53
          port: 53
          protocol: TCP
          targetPort: 53
    selector:
        app.kubernetes.io/instance: coredns
        app.kubernetes.io/name: coredns

Et une fois appliqué ça donne ça :

NAME           TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
...
cdns-lb-tcp    LoadBalancer   10.101.9.103   192.168.0.153   53:31251/TCP    7h37m
cdns-lb-udp    LoadBalancer   10.104.45.49   192.168.0.153   53:31716/UDP    7h37m
...

On voit bien qu’on a nos deux services qui écoutent sur la même External IP.

Bon, ce n’est pas tout ça, mais si on s’assurait que ça fonctionne bien quand même ?

On teste en mode TCP :

dig -t A +tcp blog.fricouv.eu @192.168.0.153

Et on obtient la réponse suivante :

; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> -t A +tcp blog.fricouv.eu @192.168.0.153
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51368
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 083e5e3c94d7ae61 (echoed)
;; QUESTION SECTION:
;blog.fricouv.eu.    IN  A

;; ANSWER SECTION:
blog.fricouv.eu.  30  IN  CNAME  obelix.fricouv.eu.
obelix.fricouv.eu.  30  IN  A  38.242.215.124

;; Query time: 52 msec
;; SERVER: 192.168.0.153#53(192.168.0.153) (TCP)
;; WHEN: Wed Apr 01 16:56:20 UTC 2026
;; MSG SIZE  rcvd: 135

En mode TCP, c’est OK !

En UDP maintenant :

dig -t A +udp blog.fricouv.eu @192.168.0.153

Et on obtient la réponse suivante :

; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> -t A +udp blog.fricouv.eu @192.168.0.153
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27637
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d3884161ae8965e8 (echoed)
;; QUESTION SECTION:
;blog.fricouv.eu.    IN  A

;; ANSWER SECTION:
blog.fricouv.eu.  30  IN  CNAME  obelix.fricouv.eu.
obelix.fricouv.eu.  30  IN  A  38.242.215.124

;; Query time: 0 msec
;; SERVER: 192.168.0.153#53(192.168.0.153) (UDP)
;; WHEN: Wed Apr 01 17:00:26 UTC 2026
;; MSG SIZE  rcvd: 135

Et voilà le travail ! J’ai enfin trouvé comment exposer mes services sur une même IP externe et sur le même port, quel que soit le protocole que j’utilise.

AI Manifesto

Thu, 09 Oct 2025 00:00:00 GMT

Utilisation pour le contenu

L’ensemble du contenu textuel, les configurations ou les commandes, que ce soit du blog ou de la documentation n’a pas été généré grâce à de l’intelligence artificielle.

L’usage que j’ai aujourd’hui de l’IA est relativement restreint, et je ne juge pas pertinent de produire du contenu à destination d’Humains si ce contenu est lui-même tiré d’une IA que ces mêmes personnes pourraient utiliser.

Pour ce qui est des images qui peuvent ou pourraient être présentes, il reste possible que j’intègre certaines générations faites par intelligence artificielle.
Le cas échéant, une note sera mise en place pour le signifier.

Sourcing

J’essaye au maximum de citer les sources qui m’ont fortement servies pour l’écriture du contenu.
En mettant en référence les liens des outils, ou des documentations sur lesquelles je me suis appuyé pour écrire, si ces dernières sont le fruit de travail d’autres personnes.

Mon avis sur les IA

Au moment où j’écris ces lignes, nous sommes en octobre 2025.
Je n’ai pas de position tranchée sur l’IA.

Je ne considère pas ça comme étant « le mal » comme certains peuvent le penser, je considère que c’est un outil, qui s’avère déjà dans certains cas, puissant. Mais en même temps, j’estime qu’il ne sera pas possible, au moins à courte échéance remplacer la nécessité de pensées humaines dans le travail.

Au delà de ce point, et c’est une vision très personnelle de mes différentes expériences, j’estime que les IA ne sont à date toujours pas capable de fournir « de bonnes réponses » à un problème.
De part le fait qu’il y a une volonté de satisfaire l’utilisateur, les IA ont un biais fonctionnel qui les forcent à fournir une réponse coûte que coûte, même si celle-ci n’est pas réalisable.
Comme dans une relation avec un humain, je préfère entendre ou lire un « Je ne sais pas répondre à ta question / à ton besoin » plutôt qu’on me fasse miroiter une réponse qui finira par me frustrer.

Conclusion

Je continue donc à travailler majoritairement sans IA, pour le moment, elles ne me font pas suffisamment gagner de temps pour pousser l’usage.

Je changerais peut-être d’avis dans le futur, mais je reste dans l’idée qu’elles sont des outils, et qu’il faut les utiliser et les considérer comme tels.

Ansible pull

Tue, 02 Sep 2025 00:00:00 GMT

Pull ?

Ansible est un outil de configuration en mode « push », et donc par définition se connecte aux machines pour effectuer des actions.

Il n’a pas vocation initiale à être joué de façon régulières pour effectuer ce que l’on va qualifier de gestion de conformité.

Ansible Pull permet de mettre en place ce fonctionnement tout en restant dans un environnement connu et maitrisé.
À contrario d’Ansible, il est orienté exécution locale. Bien sur celà reste possible d’aller plus loin, mais dans le cas présent, on va discuter conformité sur la machine locale.

Rappel sur les notions de conformité

La gestion de la conformité de configuration est un mode de gestion où l’on vérifie à intervales réguliers que ce qui a été défini est bien appliqué.

Celà permet d’éviter des glissements (drifts) de configuration entre l’état initial et l’état courant.

Fonctionnement

Le modèle Ansible Pull est basé sur la récupération de matériel Ansible depuis un dépot Git, et le rejeu du playbook définit lors de l’exécution de la commande.

Concrètement, il va aller interroger à intervales réguliers un dépot Git qui contient les configurations que vous souhaitez garder sous contrôle de conformité, et exécuter Ansible sur la machine locale pour valider ou réappliquer les configurations si nécessaire.

Préparation des machines

Les machines qui devront exécuter ansible-pull doivent avoir le paquet ansible-core d’installé sur le système.

Autant dans le cas d’un contrôleur Ansible, il est conseillé d’installer Ansible dans un virtualenv Python pour pouvoir récupérer les dernières versions, mais dans le cas d’Ansible Pull, je vous conseille d’utiliser les paquets système afin de ne pas avoir à gérer la création du virtualenv.

Dépot Git

Le dépot Git qui contiendra votre configuration utilisable par Ansible Pull à un modèle assez classique :

inventories/
- inventory.yaml
playbooks/
- playbook.yaml
- requirements.yaml
roles/
- …
ansible.cfg

On va retrouver les dossiers :

inventories : Dossier qui contiendra votre/vos inventaires Ansible
playbooks : Dossier qui contiendra votre/vos playbooks Ansible
roles : Dossier qui contiendra vos roles Ansible qui seront utilisé hors collections
ansible.cfg : Fichier de configuration Ansible

Contenu des différents fichiers

Inventaire Ansible

all:
  hosts:
    localhost:
      ansible_connection: local

Playbook de base

---
- name: 'Perform'
  hosts:
    - localhost
  vars:
    timer_sync_interval: '*:0/10:00' # Every 10 minutes
  handlers:
  - name: 'Enable ansible-pull.timer'
    become: true
    ansible.builtin.systemd:
      name: 'ansible-pull.timer'
      enabled: true
      daemon_reload: true
      state: restarted

  pre_tasks:
    - name: 'Deploy Ansible pull systemd unit'
      become: true
      ansible.builtin.copy:
        dest: '/etc/systemd/system/ansible-pull.service'
        content: |
          [Unit]
          Description=Runs ansible-pull to get common server configuration
          Wants=ansible-pull.timer

          [Service]
          Type=oneshot
          ExecStart=/usr/bin/ansible-pull --accept-host-key -U https://<votre_forge>/<path_of>/<ansible_repository>.git playbooks/playbook.yaml

          [Install]
          WantedBy=multi-user.target
          owner: 'root'
          group: 'root'
          seuser: system_u
          serole: object_r
          setype: systemd_unit_file_t
          selevel: s0

    - name: 'Configure systemd timer for Ansible pull'
      become: true
      notify: 'Enable ansible-pull.timer'
      ansible.builtin.copy:
        dest: '/etc/systemd/system/ansible-pull.timer'
        content: |
          [Unit]
          Description=starts ansible-pull to get common server configuration
          Requires=ansible-pull.service

          [Timer]
          Unit=ansible-pull.service
          OnCalendar={{ timer_sync_interval }}

          [Install]
          WantedBy=timers.target
          owner: 'root'
          group: 'root'
          seuser: system_u
          serole: object_r
          setype: systemd_unit_file_t
          selevel: s0

    - name: 'Install galaxy collection community.general'
      become: true
      changed_when: false
      ansible.builtin.command:
        cmd: '/usr/bin/ansible-galaxy collection install community.general'

    - name: 'Install galaxy'
      become: true
      community.general.ansible_galaxy_install:
        type: collection
        requirements_file: requirements.yaml
        state: present
        force: true

    - name: 'Ensure required packages are installed'
      become: true
      ansible.builtin.package:
        state: present
        name: python3-pip

Fichier de requirement galaxy

---
collections:
  - name: vfricou.apps
    type: git
    source: https://github.com/vfricou/vfricou.apps.git
    version: "master"
  - name: vfricou.system
    type: git
    source: https://github.com/vfricou/vfricou.system.git
    version: "master"

Configuration Ansible

[defaults]
roles_path = ./roles
playbook_dir = ./playbooks
inventory = ./inventories/inventory.yaml

Je m’attarde un peu sur le fichier playbook.yaml, parce qu’il y a plusieurs choses à dire dessus.

Tout d’abord, la déclaration de la variable de trigger pour le timer systemd à intervales de 10 minutes.

Ensuite les tâches effectuées :

Création du l’unit « timer » systemd ansible-pull.timer qui servira au déclenchement régulier d’Ansible Pull
Création de l’unit « service » systemd ansible-pull.service qui est la commande qui sera exécutée pour Ansible Pull
Installation de la collection community.general pour pouvoir effectuer l’installation de ce qui est spécifié dans le fichier requirements.yaml
Installation des requirements galaxy
Installation du package python3-pip s’il n’est pas présent sur le système

Ce que l’on souhaite faire avec ces pre_tasks c’est d’avoir tout ce qui sera nécessaire pour l’application des rôles ou des tâches qui seront contenues dans le playbook par la suite.
Il faut les voir comme des « pré-requis » à l’exécution du playbook.

Première exécution

Vu que c’est Ansible Pull lui-même qui a pour charge de gérer la configuration du timer et de l’unit systemd, vous avez deux solutions :

Soit, vous déposez vous-même vos fichiers de timer / units, mais ce n’est pas fou
Soit, vous exécutez vous-même la commande ansible-pull qui sera exécuté par l’unit systemd.

Personnellement, j’ai une très forte tendance à préférer la deuxième solution.
Tout d’abord parce que ça ne vous fait faire qu’une seule action sur la machine, mais ensuite parce que ça vous permet de valider que l’exécution de votre timer systemd va bien se faire sans erreurs.

Et après ?

Et bien après, vous pouvez ajouter des rôles ou des tâches au playbook pour configurer et valider les points que vous souhaitez faire gérer à Ansible Pull.

Vous poussez vos configurations dans le dépot qui sert de référence à Ansible Pull, et le tour est joué, à intervales réguliers, vous pourrez voir les exécutions de votre playbook sur les machines avec un simple journalctl -u ansible-pull.service.

Naissance du site

Sat, 21 Jun 2025 00:00:00 GMT

Mais… Je suis qui moi ?

Avant tout, il convient de me présenter, c’est la moindre des choses.

Je m’appelle Vincent. Mon âge ? Est-ce que par hasard ça ne serait pas inutile ? (Et en plus, il faut le mettre à jour, j’ai autre chose à penser !)
Je suis actuellement Consultant SRE, j’ai fait pas mal d’années en tant qu’Administrateur Système avant de commencer à fortement m’intéresser à travailler de façon plus reproductible, automatisée, et actuelle.

Je me dois de clarifier une chose… Je suis un peu perplexe sur la différence entre ce que l’on appelle traditionnellement « Administrateurs Système » et des SRE (Site Reliability Engineer) aujourd’hui.
Pourquoi ? Parce que pour moi, dans le fond ça reste le même métier, un écart que je n’explique pas s’est créé, ce qui a amené à ces deux termes.
Ce qui se cache derrière et qui crée cette différenciation de terminologie, c’est le côté « Reliability » (résilience / fiabilité). J’estime qu’un Administrateur Système doit être en capacité d’assurer la fiabilité et surtout la fiabilisation des systèmes qu’il opère.
C’est peut-être un biais de ma part, vous avez totalement le droit, chacun est totalement libre de ce qu’il pense et je n’en tiendrai rigueur à personne.

Donc, je suis Consultant SRE disais-je. En gros, mon boulot, c’est de conseiller, architecturer et déployer des infrastructures résilientes, en fonction des demandes qui me sont faites.

De part mon métier, mais également parce que je suis quelqu’un de curieux, je suis amené à toucher à pas mal de technologies. Mes compétences actuelles ayant été majoritairement acquise par de l’auto-formation, et surtout, des erreurs… Beaucoup d’erreurs.

La théorie de l’essai erreur

J’adore la théorie de l’essai erreur. Celui qui ne fait pas ne commet jamais d’erreurs. Celui qui n’essaie pas non plus. Celà induit qu’il ne progresse pas. (Mis à part certains cas de personnes extrêmement et particulièrement douées, parce que ça existe.)

Le conseil qui m’avait été donné il y a maintenant plusieurs longues années était le suivant : « Essaye, si tu n’y arrives pas réessaye, mais surtout, surtout, ne désespère jamais. Si tu commences à désespérer, tu vas rentrer en régression ».
J’avoue que ça m’a beaucoup marqué. Pour plein de raisons, mais notamment parce que j’étais à l’époque quelqu’un qui avait une tendance à abandonner très vite. Si ce qui devait fonctionner ne fonctionnait pas, je ne me butais pas dessus.

Aujourd’hui, je me bute, mais avec raison gardée, j’essaie, plusieurs fois. Je me trompe, plusieurs fois. Mais je n’abandonne plus aussi facilement.

Si je peux vous donner un conseil supplémentaire, il serait celui-là : « Si tu n’y arrives pas aujourd’hui, réessaye plus tard, et ainsi dessuite. »
La raison en est très simple, et elle est tout aussi justifié que les écarts de ce qu’est capable de produire une personne sur une journée : L’état d’esprit.

L’état d’esprit est quelque chose de fondamental à prendre en comptes. Certains jours, nous ne sommes pas dans les bonnes dispositions mentales pour traiter et/ou résoudre un problème. C’est normal, ça arrive, et c’est humain.
C’est dans ce genre de jour qu’il ne faut pas se buter sur quelque chose. Si on sent qu’on n’est pas dans les bonnes dispositions pour traiter le problème sur lequel on travaille, on le met de côté et on y revient plus tard.

Attention toute fois, je ne vous dis pas d’abandonner la tâche pendant des jours ou des semaines. Il est impératif d’avoir évalué la criticité de cette tâche. Si ça doit être fait le jour même, il faut s’y forcer.

Pourquoi ce site ?

Bref, tout ça pour arriver à « Mais pourquoi tu fais ce site ? ».

Comme je le laissais transparaitre un peu avant, j’ai vu, fait, testé, utilisé, résolu, … pas mal de choses au fil des années.
J’en suis arrivé aujourd’hui à me dire une chose simple : « Pourquoi ne pas partager ce que tu as dans la tête ? Tu sais faire beaucoup de choses aujourd’hui, moins que d’autre bien sûr, mais ce qui tu sais vaut quand même le coup, alors, partage-le, tu vas potentiellement et certainement toucher un public qui sera intéressé pour apprendre, comprendre, progresser, ou pourquoi pas pour les plus jeunes (ou les plus fous ?) les aider à trouver leur vocation.

J’ai eu la chance d’être dans une posture d’enseignant vacataire au sein de l’IUT qui m’a formé. Aujourd’hui ce n’est plus le cas par incompatibilité avec mon planning travail, et parce qu’également je n’arrivais pas à retrouver en tant qu’enseignant ce qui me faisait vibrer dans la transmission de savoir. (Le cadre institutionnel ou ma façon de transmettre à des étudiants peut-être ?)
J’ai toujours apprécié de vulgariser mon travail pour le faire comprendre à des plus néophites, et ce site, au travers du blog ou des documentations que j’y ajouterais au fil de l’eau (et de mon temps perso) est le moyen pour moi de retrouver ce partage-là. En amenant de nouveaux concepts à des personnes qui souhaitent apprendre, ou en complétant des connaissances déjà acquises par d’autres. Ou tout simplement en fournissant des explications « simplifiés » à des personnes qui n’ont pas cette facilité de vulgarisation que je pourrais avoir.

Rester les pieds sur terre

Je n’ai aucune volonté de devenir une personne influente dans la tech, j’aime bien la discrétion de mon bureau, et je suis également quelqu’un de plutôt discrêt au quotidien (même si je dis ce que j’ai à dire).

Comme je l’ai dit précédemment, je ne prétends nullement que l’ensemble de ce que je pourrais écrire ici est la meilleure façon de faire, ou même serait la meilleure explication à donner.
Ce sont mes avis, mes process, et ma vision des choses. Elle n’est pas parfaite, elle sera très souvent incomplète, mais elle aura le mérite d’exister.
Et comme je le précise régulièrement « La seule source de vérité, c’est la documentation officielle, pas un blog écrit par on-ne-sait pas qui sur internet, et encore moins les réseaux sociaux ».

Les blogs ou articles techniques que l’on peut trouver sur le web (y compris celui-ci) ne sont pas mauvais, mais ils sont l’expression des personnes qui les écrivent.
Avec les biais, avec les erreurs, avec les oublis, avec le manque de précision que chaque humain peut avoir.