Flashback

Le homelab k3s est prêt, propre et fonctionnel.

Si t’es arrivé sur cet article sans en comprendre le contexte, je t’invite à aller sur l’article précédent Construire son homelab avec des Rpis

Si tu lis cette phrase, j’pense que t’es OP pour lire la suite ! Let’s go.

Pourquoi, comment, où ?

Pour le moment, on n’a aucune visibilité sur le homelab, sauf si on s’y branche via k9s, ou pire, qu’on se ssh sur chaque node à la main pour voir si tout va bien niveau santé hardware.

Evidemment, on ne peut pas faire ça. Va falloir mettre en place deux trois trucs sympas pour nous rendre la vie plus simple.

Établissons déjà ce que l’on veut:

• Avoir de la visibilité sur la partie hardware (usage CPU, mémoire, disque, et réseau) -> observabilité hardware.
• Pouvoir y accéder en dehors de son réseau local, tout en gardant un certain niveau de sécurité.

Détaillons tout cela.

L’observabilité

On ne réinvente pas la roue ici. On sait déjà ce qu’on veut, vu le nombre de fois où j’ai du mettre en place cela en mission chez des clients. La stack prometheus - grafana. Grand classique, ça bouge pas.

Pour faire simple: c’est une stack classique qui permet:

• de collecter des métriques (peu importe lesquelles) -> Prometheus
• d’avoir une UI simple et efficace pour en faire ce que l’on veut (dashboards, aggrégations, etc) -> Grafana.

Encore une fois, on ne réinvente pas la roue, on va utiliser kube-prometheus-stack pour déployer tout ce beau monde.

Assez simple, on va utiliser le package manager Helm, qui permet d’installer plusieurs services simplement.

Un petit screenshot de l’interface, avec un dashboard préfait pour les métriques hardware:

Ici on peut voir une overview de ce qui se passe sur le cluster, en particulier sur un rpi (ici le control plane).

Il ne se passe pas grand chose.. pour le moment (c’est normal, calme toi).

Rien de bien compliqué, et ici on a accès aux données hardware directement.

Note: cette stack ne sert pas juste à faire remonter des métriques hardware. On peut y brancher d’autres sources de données:

• Loki -> pour faire remonter les logs de nos conteneurs sur Grafana
• Custom metrics -> on peut tout simplement définir des métriques dans du code (donc dans nos apps) et les voir sur Grafana.

On peut aussi aller plus loin avec Grafana: si on veut être alerté d’une anomalie, on peut le connecter à différents services externes (Slack, Discord, et j’en passe) afin d’être alerté.

Cela donne beaucoup de perspectives d’amélioration et de facilité de maintenance.

Je vous l’ai dit dans l’article précédent: on ne fait pas les choses à moitié.

L’accessibilité

Bon, c’est bien cool tout ca, mais si je ne suis pas chez moi, j’ai aucune visibilité et je ne peux accéder à rien.

Pas ouf le projet confiné.

Pour résoudre ce souci, on doit poser le problème proprement afin d’éviter de faire des conneries (dsl Maman).

On veut deux choses bien distinctes:

• accéder depuis l’extérieur à des outils / apps, mais nous seuls y avons accès (private network en gros)
• accéder à des apps depuis internet, totalement publique (pas de restriction spécifique au niveau réseau)

Pour la première solution, on va utiliser un outil que j’ai découvert chez Boxy (RIP…) -> Tailscale.

Tailscale, c’est quoi ca encore ?

Pour faire simple, c’est un SaaS qui permet de créer un réseau virtual privée, entre des machines qui ne sont pas physiquement au même endroit, sur le même réseau. C’est basé sur Wireguard, entre autres (tu sais, ce que tu utilises quand tu achètes ton VPN bleu pour … regarder des animés sur Netflix Japan).

En gros, Tailscale te permet de connecter tes machines entre elles, et définir à l’intérieur de ton réseau privé qui a acces à quoi. C’est exactement ce que l’on veut !

Tu crées ton compte Tailscale (gratuit), tu register tes différentes machines (iPhone, NAS, Mac personnel, etc) et on peut accéder aux services ouverts entre chaque machine. Cool.

Et comment ca se passe dans ton homelab ?

Très simple. On va setup le homelab à plusieurs niveaux.

Dans un premier temps, on veut pouvoir accéder à notre cluster, via kubectl (k9s TUI pour nous).

Solution simple -> on installe tailscale sur notre control plane, celui-ci est présent dans notre VPN et donc accessible depuis mon Mac, par exemple. Side note: il faut juste changer l’IP dans notre kubeconfig et le faire pointer vers l’adresse IP du control plane dans le VPN pour que cela puisse fonctionner.

Pour k9s, c’est fait.

Pour nos services, on va procéder autrement.

Prenons l’exemple de Grafana dashboard. Il est accessible via un cluster IP donc suffit d’être sur le réseau local pour y accéder.

Pour y accéder depuis le VPN tailscale, on doit:

• créer un Oauth tailscale
• installer le tailscale-operator avec les bons credentials de l’oauth
• définir un ingress tailscale pour servir notre app dans le VPN tailscale

Petit exemple indicatif:

Notre application exapmle:

apiVersion: v1
kind: Namespace
metadata:
  name: my-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: tiangolo/uvicorn-gunicorn-fastapi:python3.11-slim
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
  namespace: my-app
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80

Et le fameux ingress tailscale:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: my-app
spec:
  ingressClassName: tailscale
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80
  tls:
    - hosts:
        - my-app

Et là, notre app est accessible via https://my-app.ton-tailscale.ts.net

Magnifique, fonctionnel, et secured.

Note 1: Tailscale reste un SaaS, donc un tiers de confiance par définition pour le service rendu.

Tailscale se sert de technologies assez smart, comme le traversal NAT pour établir des connexions directes. Dans ce cas, rien ne transite sur leurs serveurs.

Mais, si l’envie vous prenait, d’avoir votre propre tailscale self host, vous pouvez héberger votre Headscale et vous êtes sereins. C’est une version open source et self-hostable en gros.

Note 2: Avec Tailscale, on peut désormais créer des Funnel, permettant d’exposer des apps a tout Internet. Mais c’est en version beta, la bande passante est limitées et n’est pas connue (en tout cas je ne l’ai pas trouvé). C’est donc possible de répondre au second besoin, mais pas fiable pour le moment.

C’est pourquoi nous avons donc choisi une solution plus robuste pour l’accès a Internet: Cloudfare Tunnel.

Cloudflare, encore un truc dans le cloud ?

Alors oui, encore un truc dans le cloud… mais pour la bonne cause !

Supposons que j’ai besoin d’une app qui doit etre accessible via les Internets (a tout hasard, le tracking de ce blog :)) .

Avec Tailscale on est limité, il nous faut une solution stable. Soit on ouvre des ports sur notre box, et on laisse du traffic entrant de l’exterieur vers chez nous. Ca se fait, mais on ne va pas le faire ici.

Soit on choisit de faire un tunnel entre notre homelab et le monde exterieur. C’est ce que l’on va faire ici, avec Cloudflare Edge.

Le setup

Le plus simple est d’avoir un nom de domaine sur cloudfare. Sinon c’est relou. On reste dans ce cas de figure.

Le chemin du traffic ressemble a ca:

Internet → Cloudflare Edge → [tunnel chiffré] → pod cloudflared → ton service

Je vais pas détailler la configuration pour le faire, Claude est ton ami :)

C’est gratuit, robuste, et reste sécurisé.

Conclusion

Article un peu plus technique (mais pas trop, ca va), permettant d’enclencher sur la suite: mettre des apps réelles dessus et accessibles en interne, et au public.

Mais ca, j’en parlerai dans les prochains articles.

Petit spoiler: de l’IA, des GPUs, des agents. Mais pas que.

D’ici là, porte toi bien.

Adem.