Avant de poursuivre, il est indispensable d'avoir mis en place le cluster Kubernetes en
suivant les guides Kubernetes installation et Kubernetes à haute disponibilité.
Le label node-role.kubernetes.io/db-host doit être ajouté aux 3 workers qui seront
responsables des bases de données.
Longhorn est utilisé pour mettre en place un système de stockage par bloc au sein du
cluster. Ce dernier permet la création de volume persistants, pour les applications au
sein du cluster, qui sont accessibles depuis n'importe quel nœud du cluster.
# Add the Helm repo and fetch the latest chartshelmrepoaddlonghornhttps://charts.longhorn.io
helmrepoupdate
# Install Longhornhelminstalllonghornlonghorn/longhorn--create-namespace-nlonghorn-system\--setlonghornUI.replicas=1\--setpersistence.defaultClassReplicaCount=2\--setdefaultSettings.storageMinimalAvailablePercentage=15\--setdefaultSettings.storageReservedPercentageForDefaultDisk=15\--setdefaultSettings.nodeDrainPolicy="allow-if-replica-is-stopped"
Attention, il est recommandé de protéger l'accès à l'UI de Longhorn pour protéger les
volumes des applications. Si vous ne prévoyez pas d'utiliser l'UI, vous pouvez définir
le nombre de replicas à 0.
Il n'est pas nécessaire d'utiliser le mécanisme de réplication de volumes de Longhorn
pour les composants qui gèrent déjà la réplication des données, tels que les bases de
données en cluster.
Par conséquent, une nouvelle StorageClass doit être créée afin de n'avoir qu'un seul
replica se trouvant localement sur le même noeud du pod.
# Get the usernamekubectl-nrabbitmqgetsecretrabbitmq-default-user-ojsonpath="{.data.username}"|base64--decode;echo# Get the passwordkubectl-nrabbitmqgetsecretrabbitmq-default-user-ojsonpath="{.data.password}"|base64--decode;echo
Chaque instance de Botalista est composée d'une application web et d'un service associé.
L'accès à une instance spécifique s'effectue à l'aide de plusieurs composants :
Tout d'abord via l'adressse IP virtuelle de notre load balancer. Il s'agit du point
d'entrée du cluster ;
Le load balancer redirige les requêtes sur deux services NodePort associés à Traefik
(un pour les requêtes HTTP et l'autre pour HTTPS), qui sont donc accessible depuis
l'extérieur du cluster Kubernetes.
Des objets IngressRoute du proxy Traefik sont déployés dans chaque espace de nom que
l'on souhaite accéder.
HAProxy doit être configuré pour rediriger les requêtes web sur un port spécifique des
workers du cluster. Ce port correspondra à un service NodePort de Traefik.
Les noeuds du plan de contrôle pourraient également recevoir les requêtes, étant donné
que le port est ouvert sur tous les noeuds du cluster. Il est cependant préférable de
laisser ce rôle aux worker afin d'exposer le moins que possible le plan de contrôle.
Modifier le fichier de configuration avec un nouveau backend qui redirige les requêtes
HTTP sur le port 30080 des workers et les requêtes HTTPS sur le port 30443 des
workers.
Cette section explique la mise en place de Traefik au sein de notre cluster. L'image
traefik/whoami est utilisée afin de s'assurer du bon fonctionnement de Traefik.
La mise en place de Traefik est effectuée dans l'espace de nom default.
apiVersion:v1kind:Servicemetadata:name:traefiknamespace:defaultspec:type:NodePortports:-name:webport:80nodePort:30080-name:websecureport:443nodePort:30443selector:app:traefik---kind:DeploymentapiVersion:apps/v1metadata:name:traefiknamespace:defaultlabels:app:traefikspec:replicas:3selector:matchLabels:app:traefiktemplate:metadata:labels:app:traefikspec:serviceAccountName:traefik-ingress-controller# Must match the ServiceAccount namecontainers:-name:traefikimage:traefik:v3.1.1args:---accesslog---providers.kubernetescrd---entryPoints.web.Address=:80# Must match a containerPort---entryPoints.websecure.Address=:443# Must match a containerPortports:-containerPort:80-containerPort:443resources:requests:memory:60Milimits:memory:200Miaffinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:-labelSelector:matchExpressions:-key:appoperator:Invalues:-traefiktopologyKey:kubernetes.io/hostname
Pour finir, il faut créer un objet IngressRoute qui s'occupe de rediriger les
requêtes au service approprié selon le nom de domaine de la requête. Créer le fichier
routes.yaml suivant :
cat<<EOF > routes.yamlapiVersion: traefik.io/v1alpha1kind: IngressRoutemetadata: name: traefik-ir namespace: default # must match the namespace of services to accessspec: entryPoints: - web # Defined in traefik.yaml args routes: - match: Host(\`traefik.bota-hepia.ch\`) kind: Rule services: - name: whoami port: 80EOFkubectlapply-froutes.yaml
Vérifier le fonctionnement avec la commande curl.
Note: En l'absence de DNS publique, le fichier /etc/hosts/ peut être modifié pour
valider le fonctionnement)
L'option insecureSkipVerify de Traefik doit être activé afin d'établir des connexions
TLS avec un certificat auto-signé. Un objet ServersTransport doit être créé afin
d'activer cette option pour des services spécifique.
Il est ensuite possible de créer un objet IngressRoute qui utilise ce
ServersTransport et qui active les connexions TLS. Ces deux objets doivent se trouver
dans le même espace de nom.
apiVersion:traefik.io/v1alpha1kind:IngressRoutemetadata:name:traefik-ir-sslnamespace:elastic-stack# must match the namespace of services to accessspec:entryPoints:-websecure# Defined in traefik.yaml argsroutes:-match:Host(`kibana.bota-hepia.ch`)kind:Ruleservices:-name:eck-stack-eck-kibana-kb-httpport:5601serversTransport:transportinsecure# allow self signed certificatestls:domains:-main:bota-hepia.ch