Les K3s seront livrés avec à peu près tout de préconfiguré commetraefik
.
👉🏻 Plus d’infos sur traefik : https://doc.traefik.io/traefik/
Cependant, j’aimerais avoir un LoadBalancer et, en substance, pouvoir donner aux services (pods) une adresse IP externe. Tout comme mes nœuds Kubernetes et non à partir de plages Kubernetes internes.
Normalement, il s’agit d’un composant externe et votre fournisseur de cloud devrait vous le donner par magie, mais comme nous sommes notre propre fournisseur de cloud et que nous essayons de tout conserver dans un seul cluster… en bref, MetalLB
voici la réponse.
🤔 Qu’est-ce que MetalLB#
📦 Déploiement#
Dans le chapitre précédent, nous avons installé helm
et arkade
, il est donc helms
temps de briller !
# Ajoutez le repo Metallb dans votre helm
helm repo add metallb https://metallb.github.io/metallb
# Faites une recherche dans helm
helm search repo metallb
# Installez metallb
helm upgrade --install metallb metallb/metallb --create-namespace \
--namespace metallb-system --wait
Cela devrait installer MetalLB dans votre cluster et renvoyer quelque chose comme ceci :
Release "metallb" does not exist. Installing it now.
NAME: metallb
LAST DEPLOYED: Sat Apr 1 10:49:30 2023
NAMESPACE: metallb-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
MetalLB is now running in the cluster.
Now you can configure it via its CRs. Please refer to the metallb official docs
on how to use the CRs
Voilà pour l’installation. Il faut maintenant la configurer.
⚙️ Configuration#
MetalLB doit savoir quelle plage d’adresses IP utiliser pour les adresses IP externes. Cela se fait via un Custom Resource. Vous pouvez trouver le CR dans la documentation officielle . Créons et appliquons donc un Custom Resource avec le contenu suivant :
cat << 'EOF' | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: default-pool
namespace: metallb-system
spec:
addresses:
- 192.168.1.200-192.168.1.250
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: default
namespace: metallb-system
spec:
ipAddressPools:
- default-pool
EOF
Cela devrait renvoyer quelque chose comme ceci :
ipaddresspool.metallb.io/default-pool created
l2advertisement.metallb.io/default created
Comme vous pouvez le voir, j’ai spécifié une plage allant de 192.168.1.200 à 192.168.1.250. Cela me donnera 50 adresses IP « externes » avec lesquelles travailler pour le moment.
☑️ Vérifier#
Vérifiez si tout est déployé correctement
root@control00:~/metallb# kubectl get pods -n metallb-system
NAME READY STATUS RESTARTS AGE
controller-57fd9c5bb-rdl7v 1/1 Running 0 5m42s
speaker-h7chj 1/1 Running 0 5m42s
speaker-78pdz 1/1 Running 0 5m42s
.
.
.
Vous devez en avoir autant de speaker-xxxx
que vous avez de nœuds dans le cluster, car ils exécutent un par nœud.
Désormais, les services qui utilisent le LoadBalancer doivent avoir une adresse IP externe qui leur est attribuée.
Par exemple:
oot@control00:~/metallb# kubectl get svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP,9153/TCP 3h45m
metrics-server ClusterIP 10.43.254.144 <none> 443/TCP 3h45m
traefik LoadBalancer 10.43.159.145 192.168.1.200 80:31771/TCP,443:30673/TCP 3h44m
Vous pouvez également consulter les événements du service :
root@control00:~/metallb# kubectl get events -n kube-system --field-selector involvedObject.name=traefik
LAST SEEN TYPE REASON OBJECT MESSAGE
61s Normal IPAllocated service/traefik Assigned IP ["192.168.1.200"]
60s Normal nodeAssigned service/traefik announcing from node "cube02" with protocol "layer2"
Regardez comment traefik
obtient automatiquement une adresse IP à partir de la plage externe. En fin de compte, c’est ce que vous souhaitez. Ne pas pointer vers une seule adresse IP de nœud et être redirigé en fonction du DNS, ce qui cesserait de fonctionner au moment où le nœud avec cette adresse IP mourrait. De cette façon, nous rendons le nœud IP externe indépendant. Maintenant, vous pouvez pointer le DNS vers l’adresse IP de MetalLB et être sûr qu’il sera correctement acheminé.
C’est ainsi que je préfère mes paramètres réseau et cela me semble le plus logique lors de la création de services externes. Je suis sûr qu’il existe une centaine de méthodes différentes utilisant des équilibreurs de charge externes, Nginx ingress (essentiellement un proxy inverse) et qui sait quoi en production, mais bon, il n’existe pas de aramètre standardisé officiel pour Kubernetes (ce qui peut parfois être pénible), alors qui peut dire que ce n’est pas OK ? 🙂"