Quelques explications#

Si on lit ce qui est écrit sur la documentation MetalLB pour du niveau 2, on peut voir quelques avantages et inconvénients à l’utilisation de cette solution.

Son principal avantage est qu’il est simple à utiliser et s’adapte à beaucoup de cas d’usage. Lorsqu’une adresse IP est allouée, alors un des noeuds du cluster va répondre à cette adresse IP en répondant aux requêtes ARP qui sont envoyées par les clients.

Mais c’est là aussi un des points négatifs de la solution, un seul des noeuds du cluster sera en capacité de gérer le trafic pour une adresse IP donnée, ce qui entraîne 2 points négatifs :

• Bascule (failover) potentiellement lente en cas de perte de noeud : Si le noeud qui gère l’adresse IP devient indisponible, alors il faut attendre que le client envoie une requête ARP pour que le nouveau noeud prenne le relais, ou que le client soit en capacité d’interpréter les paquets que MetalLB envoie pour les informer d’un changement d’adresse MAC
• Goulot d’étranglement pour le noeud qui gère le trafic d’une adresse IP : Comme expliqué juste au dessus, dans ce mode de fonctionnement, seul un noeud élu reçoit le trafic pour une adresse IP donnée. Si le noeud arrive à sa capacité réseau limite, alors il n’y aura pas de possibilité de montée en charge supplémentaire

Trop de théorie, pas assez de pratique#

Si on suit la documentation d’installation de MetalLB, on peut se satisfaire de kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.15.2/config/manifests/metallb-native.yaml pour l’installer.

Je suis plutôt partisan d’utiliser une chart helm pour gérer ça en GitOps via ArgoCD/FluxCD, mais là on n’est pas en production 😎

1
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.15.2/config/manifests/metallb-native.yaml
2

3
namespace/metallb-system created
4
customresourcedefinition.apiextensions.k8s.io/bfdprofiles.metallb.io created
5
customresourcedefinition.apiextensions.k8s.io/bgpadvertisements.metallb.io created
6
customresourcedefinition.apiextensions.k8s.io/bgppeers.metallb.io created
7
customresourcedefinition.apiextensions.k8s.io/communities.metallb.io created
8
customresourcedefinition.apiextensions.k8s.io/ipaddresspools.metallb.io created
9
customresourcedefinition.apiextensions.k8s.io/l2advertisements.metallb.io created
10
customresourcedefinition.apiextensions.k8s.io/servicebgpstatuses.metallb.io created
11
customresourcedefinition.apiextensions.k8s.io/servicel2statuses.metallb.io created
12
serviceaccount/controller created
13
serviceaccount/speaker created
14
role.rbac.authorization.k8s.io/controller created
15
role.rbac.authorization.k8s.io/pod-lister created
16
clusterrole.rbac.authorization.k8s.io/metallb-system:controller created
17
clusterrole.rbac.authorization.k8s.io/metallb-system:speaker created
18
rolebinding.rbac.authorization.k8s.io/controller created
19
rolebinding.rbac.authorization.k8s.io/pod-lister created
20
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:controller created
21
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:speaker created
22
configmap/metallb-excludel2 created
23
secret/metallb-webhook-cert created
24
service/metallb-webhook-service created
25
deployment.apps/controller created
26
daemonset.apps/speaker created
27
validatingwebhookconfiguration.admissionregistration.k8s.io/metallb-webhook-configuration created

Et là c’est parti, on peut commencer à s’amuser !

On commencer par définir une IPAddressPool :

1
apiVersion: metallb.io/v1beta1
2
kind: IPAddressPool
3
metadata:
4
  name: main-pool
5
  namespace: metallb-system
6
spec:
7
  addresses:
8
  - 172.16.112.10-172.16.112.20

Puis un L2Advertisement afin que notre pool soit fonctionnelle :

1
apiVersion: metallb.io/v1beta1
2
kind: L2Advertisement
3
metadata:
4
  name: main-l2
5
  namespace: metallb-system
6
spec:
7
  ipAddressPools:
8
  - main-pool

Si on reprend l’application et qu’on modifie le service default/frontend pour spécifier le type: LoadBalancer, on devrait avoir une IP dans le pool qui nous est assignée.

1
kubectl get svc
2

3
NAME             TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
4
frontend         LoadBalancer   10.43.212.166   172.16.112.12   80:31393/TCP   65m

Un curl sur l’adresse ip nous confirme que tout fonctionne comme prévu :

1
curl 172.16.112.12
2

3
<html ng-app="redis">
4
  <head>
5
    <title>Guestbook</title>
6
    <link rel="stylesheet" href="//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css">
7
....

On peut même aller un peu plus loin pour savoir quel noeud gère l’adresse IP de notre Balancer :

1
kubectl get servicel2statuses -n metallb-system
2

3
NAME       ALLOCATED NODE   SERVICE NAME   SERVICE NAMESPACE
4
l2-4zfrt   test-node-02     frontend       default

Et voilà, notre service est accessible depuis l’extérieur du cluster en utilisant MetalLB

Configuration côté Cilium#

Côté Cilium, il faut s’assurer que la configuration possède bien la clé bgpControlPlane.enabled côté chart helm soit à true, comme le spécifie la documentation

Si Helm n’est pas votre ami (pourquoi ?!), vous pouvez vérifier que la clé enable-bgp-control-plane dans la configmap kube-system/cilium-config soit bien set à true

Et c’est parti ! Il faut choisir 2 numéros d’AS (Autonomous System) différents, un pour le routeur et un pour Cilium (qui représente le cluster Kubernetes). Si on vérifie la plage de wiki, on peut voir que la plage 64512-65534 est réservée pour un usage, on peut donc s’en servir pour notre cas d’usage

De mon côté je vais prendre l’AS 65000 pour mon routeur, et l’AS 65001 pour Cilium.

Côté configuration Cilium, plusieurs méthodes sont disponibles, malheureusement je ne suis pas un expert réseau, donc je vais prendre la méthode qui m’arrange en utilisant la Default Gateway Auto-Discovery

1
apiVersion: cilium.io/v2
2
kind: CiliumBGPClusterConfig
3
metadata:
4
  name: cilium-bgp
5
spec:
6
  bgpInstances:
7
  - name: "65000"
8
    localASN: 65001
9
    localPort: 179
10
    peers:
11
    - name: "peer-65001-udm"
12
      peerASN: 65000
13
      autoDiscovery:
14
        mode: "DefaultGateway"
15
        defaultGateway:
16
          addressFamily: ipv4
17
      peerConfigRef:
18
        name: "cilium-peer"

Puis on définit CiliumBGPPeerConfig :

1
apiVersion: cilium.io/v2
2
kind: CiliumBGPPeerConfig
3
metadata:
4
  name: cilium-peer
5
spec:
6
  gracefulRestart:
7
    enabled: true
8
    restartTimeSeconds: 15
9
  families:
10
    - afi: ipv4
11
      safi: unicast
12
      advertisements:
13
        matchLabels:
14
          advertise: "bgp"

Ensuite on configure le CiliumBGPAdvertisement pour qu’il n’annonce que les routes vers les service de type LoadBalancer, il y a la possibilité d’annoncer aussi les services ClusterIP, les PodCIDR, … Mais ce n’est pas forcément ce que l’on recherche ici étant donné que l’on veut uniquement accéder à nos services depuis l’extérieur du cluster.

Le selector est important, autrement aucun service ne sera annoncé par cilium

1
apiVersion: cilium.io/v2
2
kind: CiliumBGPAdvertisement
3
metadata:
4
  name: bgp-advertisements
5
  labels:
6
    advertise: bgp
7
spec:
8
  advertisements:
9
    - advertisementType: "Service"
10
      service:
11
        addresses:
12
          - LoadBalancerIP
13
      selector:             # <-- used to trigger all LB services
14
        matchExpressions:
15
         - {key: randomKey, operator: NotIn, values: ['never-used-value']}

Enfin, comme pour MetalLB, on définit une pool d’adresse IP que Cilium pourra utiliser pour nos services LoadBalancer :

1
apiVersion: "cilium.io/v2alpha1"
2
kind: CiliumLoadBalancerIPPool
3
metadata:
4
  name: main-lb-ip-pool
5
spec:
6
  blocks:
7
    - start: "172.16.112.10"
8
      stop: "172.16.112.20"

Configuration côté Unifi UDM SE#

Côté UDM SE, on doit faire une configuration FRR BGP pour la pousser sur l’interface Web.

La configuration en question en faisant attention de bien lister tous les neighbors (oui je sais, j’aurais du changer l’adresse IP de mes noeuds 😅) :

1
router bgp 65000
2
  bgp router-id 172.16.112.1
3
  neighbor main-cluster peer-group
4
  neighbor main-cluster remote-as 65001
5
  neighbor main-cluster activate
6
  neighbor main-cluster soft-reconfiguration inbound
7
  neighbor main-cluster default-originate
8
  neighbor 172.16.112.156 peer-group main-cluster
9
  neighbor 172.16.112.160 peer-group main-cluster
10
  neighbor 172.16.112.114 peer-group main-cluster
11
  address-family ipv4 unicast
12
  redistribute connected
13
  neighbor main-cluster activate
14
  neighbor main-cluster route-map ALLOW-ALL in
15
  neighbor main-cluster route-map ALLOW-ALL out
16
  neighbor main-cluster next-hop-self
17
exit-address-family
18
route-map ALLOW-ALL permit 10
19
!
20
line vty
21
!

Et maintenant, comment on vérifie si ça fonctionne ?#

Dans un mon cas, un simple curl -L http://172.16.112.12 permet de valider que les routes sont bien annoncés correctement !

Si on veut pousser le bouchon un peu plus loin, on peut aller voir les routes directement sur le routeur :

1
~# ip route
2

3
<...>
4
172.16.112.12 proto bgp metric 20
5
        nexthop via 172.16.112.114 dev br112 weight 1
6
        nexthop via 172.16.112.156 dev br112 weight 1
7
        nexthop via 172.16.112.160 dev br112 weight 1
8
<...>

Mais qu’est-ce Tailscale ?#

Tailscale c’est un outil vous servant à créer un réseau privé virtuel (VPN) mesh, basé sur Wireguard et qui est beaucoup plus simple d’utilisation qu’un VPN “traditionnel”.

En quelques points clés :

• Tailscale permet de créer un réseau privé entre vos appareils — ordinateurs, téléphones, serveurs — même s’ils sont chacun sur des réseaux différents (Wi-Fi public, maison, travail, etc.) via un réseau appelé “tailet”

• Tailscale s’appuie sur le protocole WireGuard

• Tailscale propose une configuration “zero-config” : peu ou pas de réglage de réseau, peu de ports à ouvrir, etc. L’idée c’est que ça marche sans avoir à se prendre la tête avec des règles de pare-feu, des configurations de routeur, etc.

Si certains connaissent Zerotier ou encore Netmaker, le principe est le même, mais la configuration est encore plus simple 😎

Et pourquoi c’est intéressant ?#

Et bien, principalement parce que Tailscale peut être installé dans un cluster Kubernetes !

Plusieurs options de déploiements sont disponibles :

• Déploiement via un sidecar afin de permettre de n’accéder qu’à un pod dans le cluster sans exposer le reste des pods/services
• Déploiement d’un proxy, similaire au déploiement d’un sidecar mais plutôt utilisé pour pointer vers un service plutôt qu’un pod
• Déploiement d’un routeur, permettant d’accéder à tout ce qui se trouve dans le cluster

Les déploiements via un sidecar, ou un proxy sont probablement les solutions les plus adaptées à de la production, mais ce n’est clairement pas les plus funs à utiliser. On est donc parti pour le déploiement d’un routeur afin d’accéder à tout ce qui se trouve sur notre cluster.

C’est parti pour le déploiement#

Pour nous cas d’utilisation, on déploie ça en s’inspirant de la définition du Pod présent sur la documentation de tailscale

WARNING

Je vais passer des secrets en clair afin simplifier le test pour cet article, mais pensez bien à passer vos variables dans un Secret pour gérer ça proprement !

On commence par définir les RBACs nécessaires pour que Tailscale puisse fonctionner correctement, avec les manifests présents sur la doc Tailscale:

1
---
2
# Copyright (c) Tailscale Inc & AUTHORS
3
# SPDX-License-Identifier: BSD-3-Clause
4
apiVersion: rbac.authorization.k8s.io/v1
5
kind: Role
6
metadata:
7
  name: tailscale
8
rules:
9
- apiGroups: [""] # "" indicates the core API group
10
  resources: ["secrets"]
11
  # Create can not be restricted to a resource name.
12
  verbs: ["create"]
13
- apiGroups: [""] # "" indicates the core API group
14
  resourceNames: ["tailscale-auth"]
15
  resources: ["secrets"]
16
  verbs: ["get", "update", "patch"]
17
- apiGroups: [""] # "" indicates the core API group
18
  resources: ["events"]
19
  verbs: ["get", "create", "patch"]
20
---
21
# Copyright (c) Tailscale Inc & AUTHORS
22
# SPDX-License-Identifier: BSD-3-Clause
23
apiVersion: rbac.authorization.k8s.io/v1
24
kind: RoleBinding
25
metadata:
26
  name: tailscale
27
subjects:
28
- kind: ServiceAccount
29
  name: "tailscale"
30
roleRef:
31
  kind: Role
32
  name: tailscale
33
  apiGroup: rbac.authorization.k8s.io
34
---
35
# Copyright (c) Tailscale Inc & AUTHORS
36
# SPDX-License-Identifier: BSD-3-Clause
37
apiVersion: v1
38
kind: ServiceAccount
39
metadata:
40
  name: tailscale

Puis on définit donc un Deployment avec le secret qui l’accompagne :

1
---
2
apiVersion: apps/v1
3
kind: Deployment
4
metadata:
5
  name: tailscale-subnet
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: tailscale-subnet
11
  template:
12
    metadata:
13
      labels:
14
        app: tailscale-subnet
15
    spec:
16
      serviceAccountName: tailscale
17
      containers:
18
        - name: tailscale
19
          image: ghcr.io/tailscale/tailscale:latest
20
          env:
21
            - name: TS_KUBE_SECRET
22
              value: tailscale-auth
23
            - name: TS_AUTHKEY
24
              valueFrom:
25
                secretKeyRef:
26
                  name: tailscale-auth
27
                  key: TS_AUTHKEY
28
            - name: TS_ROUTES
29
              value: "<POD_IP_RANGE>,<SERVICE_IP_RANGE>"
30
            - name: TS_USERSPACE
31
              value: "true"
32
          securityContext:
33
            # Run as a non-root user to mitigate privilege escalation attack attempts
34
            runAsUser: 1000
35
            runAsGroup: 1000
36
---
37
apiVersion: v1
38
kind: Secret
39
metadata:
40
  name: tailscale-auth
41
stringData:
42
  TS_AUTHKEY: tskey-0123456789abcdef

La valeur de TS_ROUTES est à adapter dans votre environnement en fonction des CIDR Réseau choisis pour les PODs et les Services.

La variable TS_AUTHKEY présente dans le secret se trouve sur l’interface Tailscale une fois votre réseau créé, je vous invite à consulter la documentation à ce sujet. Il suffit d’accéder à la page des clés de votre réseau, et de générer une clé d’authentication :

Une fois déployé, le noeud devrait apparaître sur l’interface Tailscale :

![tailscale node])(kubernetes-ingress/tailscale-node.png)

Il faut encore que l’on accepte les routes annoncés par le noeud qui tourne dans le cluster, pour ça on va sur l’UI Tailscale, puis sur le noeud en question on appuie sur ... et on sélectionne Edit route settings, et enfin on valide les routes :

Il ne reste plus qu’à installer Tailscale sur chacun des posts depuis lesquels vous souhaitez accéder à vos services et le tour est joué !

Y’a plus qu’à tester#

Et la dernière question, c’est comment on accède à nos services finalement, est-ce que l’on est obligé d’aller récupérer l’adresse IP de chacuns des services auxquels on veut accéder ?

Oui effectivement on peut, mais on a aussi la solution de rajouter un serveur DNS sur le réseau Tailscale, donc autant s’en servir..

On commence par récupérer l’adresse IP du service de notre serveur DNS, dans notre cas c’est coreDNS :

1
kubectl get svc -n kube-system
2

3
NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
4
rke2-coredns-rke2-coredns   ClusterIP   10.43.0.10      <none>        53/UDP,53/TCP   2d

Et on l’ajoute sur la page des DNS sur l’UI Tailscale :

Et enfin, on test que tout fonctionne bien avec un curl :

1
curl frontend.default.svc.cluster.local
2

3
<html ng-app="redis">
4
  <head>
5
    <title>Guestbook</title>
6
    <link rel="stylesheet" href="//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css">
7
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.12/angular.min.js"></script>
8
    <script src="controllers.js"></script>
9
    <script src="https://cdnjs.cloudflare.com/ajax/libs/angular-ui-bootstrap/2.5.6/ui-bootstrap-tpls.js"></script>
10
  </head>
11
....

Et voilà ! Le tour est joué 😎