Exposer vos pods sur Internet (HTTPS)
Cette documentation vous guidera à travers le déploiement d'une application très simple dans un cluster KUMBA.
Ressources
Pod
Un Pod est une ressource Kubernetes considérée comme éphémère. Elle peut être créée sur un autre nœud à tout moment. Son adresse IP est elle aussi éphémère.
Après avoir été recréé, un Pod aura une adresse IP différente.
Service
Pour éviter les soucis de changement d'IP Kubernetes propose la notion de Service.
Un Service agit comme un équilibreur de charge capable de répartir les requêtes entre toutes les replicas d’un Pod.
Le cycle de vie d’un Service est plus long, son adresse IP restant active tant que le Service existe.
Un Service possède également un nom DNS dans le cluster, construit comme suit :
nom-du-service.nom-du-namespace.svc.
Les autres Pods du cluster peuvent interagir avec ce Service et donc avec les Pods qui lui sont associés via ce nom.
Kubernetes utilise un mécanisme de selectors et labels pour relier un Service à toutes les instances de Pods avec lesquelles il doit interagir (le nombre d’instances pouvant varier dans le temps).
Deployment
Le Deployment est un type de workload Kubernetes conçu pour gérer des applications comme des services Web ou TCP.
Ces applications doivent pouvoir être lancées, mises à l’échelle (vers le haut ou le bas), et redémarrées en cas d’échec.
Un Pod déployé directement (sans passer par un Deployment) ne pourra pas être recréé sur un autre nœud en cas de surcharge ou de défaillance du nœud initial.
Sans Deployment, le Pod restera sur le nœud où il a été démarré au départ.
Il est généralement nécessaire de créer un Service correspondant afin de répartir les requêtes entrantes vers les Pods déployés.
La plupart du temps, ce Service sera de type ClusterIP, son adresse IP étant locale et privée au réseau du cluster.
IngressRoute
Pour qu'un service soit accessible depuis l’extérieur du cluster, il faut le connecter aux requêtes HTTP/HTTPS provenant d’Internet ou du réseau environnant.
C’est là qu’intervient le Ingress Controller. Il s’agit d’un composant optionnel dans un cluster Kubernetes qui joue le rôle de reverse proxy.
Il analyse les requêtes HTTP/HTTPS entrantes à la recherche de FQDN ou d’URI spécifiques, puis les redirige vers le service correspondant.
Les règles de reverse proxy prennent généralement la forme d’une ressource Ingress.
La définition de base de cette ressource est commune à tous les Ingress Controllers.
Le cluster Kubernetes Kumba utilise Traefik comme Ingress Controller, qui propose une ressource spécifique appelée IngressRoute.
C’est cette ressource que nous illustrerons à la fin du document.
Avec Traefik, une règle de reverse proxy prend la forme d’une ressource IngressRoute qui définit la partie filtre de la règle,
un ensemble optionnel de middlewares de transformation, ainsi que le service cible et son namespace.
C’est également l’IngressRoute qui introduit le secret contenant le certificat (dans le cas d’un service HTTPS).
L’Ingress Controller doit lui-même recevoir du trafic TCP externe. Pour cela, il crée une ressource Kubernetes de type LoadBalancer.
Ce type de ressource est intercepté par MetalLB afin de lui attribuer une adresse IP externe.
MetalLB
MetalLB intercepte la création et la modification des services de type LoadBalancer et les associe à des adresses IP virtuelles préalablement définies via la ressource Kubernetes IPAddressPool (spécifique à MetalLB).
Cette adresse IP virtuelle sera liée à un nœud (worker) du cluster.
Si ce nœud échoue, l’adresse IP sera automatiquement réassignée à un autre nœud.
Les services de type LoadBalancer agissent comme des portes d’entrée vers le réseau interne de Kubernetes.
Pare-feu & IP publique
Si le cluster Kumba est privé, la VIP associée au Ingress Controller recevra directement le trafic entrant.
Dans le cas où le cluster Kumba est exposé à Internet, une adresse IP publique sera fournie et associée à un pare-feu.
Il portera l’adresse IP publique et une règle de NAT redirigera le trafic entrant vers la VIP associée au Ingress Controller.
KumbaMenuItem
Le dernier type de ressource n’est pas une ressource standard de Kubernetes, mais plutôt une spécificité propre à Kumba.
Kumba permet de créer un élément de menu (une carte) sur la page d’accueil de l’interface d’administration via une ressource KumbaMenuItem.
Cet élément de menu facilite l’accès à l’application et évite à l’utilisateur d’avoir à mémoriser les différentes URLs des versions ou branches de son application lorsqu’il les publie sur un même cluster.
Manifests
apiVersion: v1
kind: Namespace
metadata:
name: podtato
namespace: podtato
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: podtato-head-entry
namespace: podtato
labels:
app: podtato-head
spec:
selector:
matchLabels:
component: podtato-head-entry
template:
metadata:
labels:
component: podtato-head-entry
spec:
terminationGracePeriodSeconds: 5
containers:
- name: server
image: ghcr.io/podtato-head/entry:latest
imagePullPolicy: Always
ports:
- containerPort: 9000
env:
- name: PODTATO_PORT
value: "9000"
---
apiVersion: v1
kind: Service
metadata:
name: podtato-head-entry
namespace: podtato
labels:
app: podtato-head
spec:
selector:
component: podtato-head-entry
ports:
- name: http
port: 9000
protocol: TCP
targetPort: 9000
type: ClusterIP
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: podtato-8
namespace: kumba
spec:
entryPoints:
- websecure
routes:
- match: Host(`podtato.example.com`) && PathPrefix(`/`)
kind: Rule
services:
- name: podtato-head-entry
namespace: podtato
scheme: http
port: 9000
tls:
secretName: kumba-wildcard-certificate-secret
domains:
- main: "example.com"
sans:
- "*.example.com"
---
apiVersion: "kumba.adista.fr/v1"
kind: KumbaMenuItem
metadata:
name: podtato
namespace: podtato
spec:
name: 'PodTato'
description: "PodTato demo app."
tool: 'PodTato'
url: ''
path: 'podtato'
color: '#fff'
visible: true
order: 0