Résumé des changements¶

Ce document contient la liste des changements techniques entre le déployement actuel de Botalista et la nouvelle architecture proposée.

Tableau des versions¶

Composants principaux¶

L'intégralité de l'infrastructure utilise des machines virtuelles Ubuntu 22.04.4 LTS.

Nom	Version	Note
HAProxy	`3.0.2-1ppa1~jammy`
Keepalived	`v2.3.1`	Installé avec Snap
Kubernetes	`v1.31.0`
Containerd	`1.7.19`

Déploiements Kubernetes¶

Nom	Version	Note
Calico	`v3.28.1`
Traefik	`v3.1.1`
Kubegres	`1.18`
Postgres	`16`	Déployé avec l'image `postgis:16-3.4`
Elastic Stack	`8.14.3`
RabbitMQ	`3.13.6-management`
Keycloak	`18.0.2`	Cette version n'est pas à jour

Helm charts¶

Nom	Version	Chart	Repo
Longhorn	`v1.6.2`	longhorn-1.6.2	https://charts.longhorn.io
MongoDB	`0.10.0`	community-operator-0.10.0	https://mongodb.github.io/helm-charts
Redis	`7.2.5`	redis-19.5.5	https://charts.bitnami.com/bitnami
Prometheus	`v2.53.1`	prometheus-25.24.1	https://prometheus-community.github.io/helm-charts
Grafana	`11.1.0`	grafana-8.3.7	https://grafana.github.io/helm-charts

Kubernetes¶

Version¶

Kubernetes est désormais à la version v1.31.0 (précédemment v1.21.14).

CRI¶

Les noeuds du cluster utilisent désormais containerd en tant que CRI au lieu de Docker qui n'est plus supporté.

Initialisation¶

Le plan de contrôle est désormais composé de 3 noeuds. Cela signifie que la commande d'initialisation doit être adapté :

L'ip du plan de contrôle doit correspondre à une adresse IP virtuelle qui permet d'accéder à chacun des noeuds maître
l'argument --upload-certs doit être ajouté.

Voici la nouvelle commande d'initialisation :

Bash
sudo kubeadm init \
    --control-plane-endpoint "10.136.26.70:6443" \
    --upload-certs \
    --pod-network-cidr=192.168.0.0/16 \
    --cri-socket=unix:///run/containerd/containerd.sock

La valeur du control-plane-endpoint est propre au réseau école
Le dernier argument permet de spécifier le CRI utilisé, ici containerd.

Calico¶

La version de Calico est désormais la v3.28.1 (précédemment v3.25.0). Il est également mis en place avec son operator.

Provisionneur de volume¶

Longhorn est utilisé pour gérer les demandes de volumes au sein du cluster Kubernetes. Il correspond à la StorageClass par défaut et remplace le nfs-client-provisioner.

Longhorn est installé à l'aide de Helm.

Version: v1.6.2
Chart: longhorn-1.6.2
Repo: https://charts.longhorn.io

Traefik¶

Cette section présente les changements de Traefik.

Replicas¶

Traefik est désormais déployé avec 3 replicas (qui ne sont jamais sur le même noeud).

Version¶

La version de Traefik est désormais la v3.1.1 (précédemment v2.5.7).

API¶

Les fichiers YAML pour créer les différents objets Traefik ont une nouvelle version API.

Nouvelle version API:

traefik.io/v1alpha1 (précédemment traefik.containo.us/v1alpha1)

TLS¶

N'ayant pas de nom de domaine publique pour ce projet, j'ai remplacé le certResolver

YAML
  tls:
    certResolver: letsencryptresolver

par le domaine (personnalisé) suivant

YAML
  tls:
    domains:
    - main: bota-hepia.ch

Ceci permet d'activer le TLS sans l'utilisation d'un resolver (qui provoquerait des erreurs dans ce contexte).

Dans certains contexte, tel que Kibana qui impose une connexion TLS, il est nécessaire de créer un objet ServersTransport avec l'option insecureSkipVerify à true afin d'autoriser les certificats auto-signés pour accéder à des services spécifiques.

Espaces de noms¶

Traefik peut être déployé dans son propre espace de nom, néanmoins il est important que chaque objets (IngressRoute, Middleware, ServersTransport, ...) qui sont interdépendant se trouvent dans le même espace de nom du service Kubernetes à atteindre.

Dans le cas contraire, une erreur dans le style suivant peut survenir :

Text Only

ERR Failed to create middleware keys
error="middleware traefik/ipwhitelist is not in the IngressRoute namespace default"
ingress=bota-map-web-tls
namespace=default
providerName=kubernetescrd

Amélioration possible¶

Le middleware IPWhiteList est obsolète, il est recommandé de le remplacer par IPAllowList.

Bases de données¶

Les bases de données sont désormais toutes conteneurisées et en cluster.

PostgreSQL¶

Installé avec l'opérateur Kubegres.

Operateur : Kubegres en version 1.18
Image des instances: postgis:16-3.4

MongoDB¶

Installé avec Helm.

Version: 0.10.0
Chart: community-operator-0.10.0
Repo: https://mongodb.github.io/helm-charts

Remarque: les clients utilisant MongoDB doivent modifier la configuration de leur connexion afin qu'elle puisse s'effectuer sur un Replica Set. Ceci est expliqué dans la documentation de MongoDB.

Redis¶

Installé avec Helm

Version: 7.2.5
Chart: redis-19.5.5
Repo: https://charts.bitnami.com/bitnami

Il est recommandé d'activer Sentinel pour mettre en place le mécanisme d'élection d'une nouvelle instance maître lorsque nécessaire. Néanmoins cette configuration n'expose qu'un seul service Kubernetes, ce qui empêche d'assurer une connexion à l'instance maître et peut donc provoquer des erreurs pour les requêtes en écriture.

Les requêtes en écritures nécessitent donc l'exécution de la requête suivante pour récupérer l'adresse de l'instance maître.

Bash
SENTINEL get-master-addr-by-name <name of your MasterSet. e.g: mymaster>

Ceci est expliqué dans le Bitnami package for Redis(R).

Si Sentinel n'est pas jugé pertinent, alors sa désactivation permettra d'exposer 2 services différents :

Redis Master service qui redirige sur l'instance maître et autorise les requêtes en lecture/écriture ;
Redis Replicas service qui redirige sur les instances de réplications et qui n'autorise que les requêtes en lectures seules.

NFS¶

L'architecture actuelle ne dépend désormais plus d'un serveur NFS. Sa mise en place est donc optionnel.

Surveillance de l'état de santé du cluster¶

Prometheus et Grafana¶

Ces deux outils sont des ajouts qui permettent de récupérer les métriques du cluster et visualiser l'état de santé de ce dernier.

Ils sont tous les deux installés à l'aide de Helm.

Prometheus:

Version: v2.53.1
Chart: prometheus-25.24.1
Repo: https://prometheus-community.github.io/helm-charts

Grafana:

Version: 11.1.0
Chart: grafana-8.3.7
Repo: https://grafana.github.io/helm-charts

Elastic Stack¶

Les composants d'Elastic sont désormais à la version 8.14.3 (précédemment 7.14.0).

RabbitMQ¶

RabbitMQ est désormais géré par le RabbitMQ Cluster Kubernetes Operator et déployé avec 3 replicas (qui ne sont jamais sur le même noeud).

L'image utilisée est la rabbitmq:3.13.6-management.

Keycloak¶

Keycloak est actuellement déployé en utilisant les mêmes fichiers manifestes de Botalista par soucis de temps manquant. La version utilisée (18.0.2) n'est cependant pas à jour, une mise à niveau est par conséquente recommandée.

Alfresco¶

Alfresco est composant de multiples composants, dont la majorité ne sont disponibles que via sa version enterprise (notamment pour les déploiements Kubernetes).

Par conséquent, Alfresco n'est pas déployé sur ce nouveau cluster Kubernetes.