Kubernetes - Travaux pratiques

Déploiements et manipulations diverses

Création d’un premier pod via un fichier yaml

La bonne pratique consiste à créer un fichier manifest qui sera soumis au contrôleur afin de créer le pod.

Fichier ‘simple.yaml’ :
apiVersion: v1
kind: Pod
metadata:
name: www
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

Pour créer le pod

• kubectl apply -f simple.yaml ou kubectl create -f simple.yml

Pour examiner le pod

• kubectl get pods
• kubectl describe pod www
• kubectl logs www
• kubectl exec -it www -- sh
• kubectl delete pods www

Pour rendre l’application accessible, on utilisera les commande kubectl port-forward afin d’exposer le port
80 vers un port de la machine locale :
➔ kubectl port-forward <resource-type/resource-name> [local_port]:<pod_port>

Exemple

Exposer le port 80 du pod, sur le port 8080 de la machine locale

• kubectl port-forward pod/www 8080:80 &

On peut se connecter au service nginx uniquement depuis la machine locale,

avec :
• curl 127.1:8080

K8S- T.P. v240302 Jean GAUTIER

Mise en place de pods grâce à un ‘deployment’

Il est préférable de déployer des pods en les déclarant sous forme de ‘deployment’, ce qui permettra de
pouvoir les maintenir dans l’ état souhaité et d’agir sur le nombre de répliquas.

Anatomie d’un déploiement

kind: Deployment ← le type d’objet : ‘kind’
apiVersion: extensions/v1beta1
metadata:
name: nginx-deployment ← le nom de l’objet : ‘name’
spec: Les spécifications :
replicas: 3 ← nombre de pods
strategy: Recreate ← quelle stratégie de remise en marche

matchLabels: ← Avec ‘Selector’, on définit quels pods sont gérés par ce déploiement :
deploy: exemple (doit correspondre au label définis pour les pods) Ici, le label est
‘exemple’
template:
metadata: Imbriqué sous ‘spec’, template permet de configurer les pods

labels:
deploy: example ← définir le label des pods
spec:
containers:
- name: nginx
image: nginx:1.7.9 ← spécifie le nom et l’image du container servant à déployer les pods

Exemple de déploiement - Fichier ‘busy.yml’

apiVersion: apps/v1
kind: Deployment Le type d'objet est Deployment
metadata:
name: Mon-pod
Le label servira à faire des requêtes pour retrouver l'objet
labels:
app: Mes-pods
spec:
replicas: 2
selector:
Les spécifications contiennent :
matchLabels:
le nombre de répliquas demandés
app: busybox
le matchLabel c'est à dire le moyen pour le contrôleur de retrouver les pods créés
le template des pods à créer
template:
metadata:
labels: La partie template prend les options que peuvent prendre les spécifications de pods
app: busybox Le pods contiendra un conteneur du nom de ‘busy’, basé sur l'image docker busybox
spec:
containers: Il est important que les labels des pods (champs de .template.metadata.labels) contiennent les
- name: busy champs recherchés par le contrôleur (.selector.matchLabels)
image: busybox

K8S- T.P. v240302 Jean GAUTIER

Création d’un ‘déployment’ avec exposition du service

Il s’agit de mettre en place un déploiement appelé ‘dep1’, basé sur l’image de container ‘nginx’, puis
d’exposer le port 80 du container sur un port de la machine locale (master)
1. kubectl create deployment dep1 --image=nginx/latest
2. kubectl expose deployment dep1 --port=80 --type=NodePort
3. kubectl get deploy,svc

➔ On peut constater qu’un port (ici : 31274) est associé au port 443 du service

Mise à l’échelle du déploiement

Il s’agit d’opérer une réplication à 3, du déploiement initial

✔ La commande kubectl scale permet d'ajuster le nombre de répliquas d'un deployment:

1. kubectl scale --replicas=3 deployment dep1
2. kubectl get deploy,svc,endpoints

➔ On observe que 3 x répliquas sont déployés, auxquels correspondent, 3 x ‘endpoints’

Le trafic vers le port 80 est ‘Load-Balançé’ sur les repiquas

K8S- T.P. v240302 Jean GAUTIER

Exemple de déploiement
Création d’un déploiement nginx
Fichier ‘nginx-deploy.yaml’

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app:dev
name: nginx-deployment Soit on utilise un fichier unique , décrivant le
spec: ‘deployment’ et son port de service
replicas: 2
selector:
matchLabels:
app: dev
template:
metadata:
labels:
app: dev
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80

• kubectl -apply -f nginx-deploy.yaml

Soit on préfère définir en plusieurs fichiers, la description du ‘déployment’ et le service auquel on le fait
correspondre (par le jeu des ‘labels’)

Exemple :
1 - fichier ‘nginx-deploy.yaml’ 2 - fichier ‘nginx-service.yaml’

apiVersion: apps/v1 apiVersion: v1

kind: Deployment kind: Service
metadata: metadata:
labels : name: nginx-deploy
app : nginx spec:
name: nginx-deploy ports:
spec: - port: 80
replicas: 2 protocol: TCP
selector: selector:
matchLabels: app: nginx
app: nginx

template: On associe les deux en créant les objets

metadata: kubectl create -f nginx-deploy.yaml
labels: kubectl create -f service.yaml
app: nginx
spec:
containers: On contrôle l’existence du service
- name: nginx kubectl get svc
image: nginx:1.14.2
Pour exposer le port, il faut alors spécifier un port-forward sur le service
kubectl port-forward service/nginx-deploy 8080:80
K8S- T.P. v240302 Jean GAUTIER
Déploiement d’une application nginx avec quatre répliquas

Créer d’un fichier ‘nginx.yaml’, contenant les instructions :

---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 4
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80

Effectuer le déploiement de l’application en utilisant le fichier manifet ‘nginx.yml’

kubectl apply -f nginx.yml

Vérifier la validité du ‘deployment’

kubectl get deployments -o wide

Vérifier l’existence des pods

kubectl get pods -o wide

Exposer le port TCP/80 de l’application déployée, afin de pouvoir s’y connecter depuis l’extérieur
kubectl expose deployment nginx-deployment –type NodePort --port 80
Il en résultera un port TCP local, situé au dessus de 30000 qui sera associé au port 80 du pod de l’application

Vérification du service exposé

kubectl get services -o wide

Il est alors possible de se connecter sur l’application nginx, via http://@_IP du serveur:30511

K8S- T.P. v240302 Jean GAUTIER

 Mise à l’échelle d’une application

La mise à l’échelle consiste à faire évoluer le nombre de pods déployés pour la mise en ligne
d’applications.
➔ Les pods sont répliqués, constituant alors une ‘armée’ de machines supportant l’application
désirée.

Exemple de mise en œuvre

Création d’un ‘deployment’ (mon-serveur-1) en y associant un ‘service’ (appli-1)
kubectl create deployment mon-serveur --image nginx → Créer une instance nommée ‘mon-serveur’
kubectl expose deployment mon-serveur --name appli-1 --type NodePort --port=80

Voir l’état actuel des répliquas de déploiements

kubectl get replicaset

Définir le nombre de répliquas d’un déploiement (augmentation ou réduction)

kubectl scale deployment/mon-serveur --replicas=4 ← on indique le nombre de répliquas souhaité
kubectl get replicaset

Voir le nombre de pods (consécutif aux répliquas), avec l’option ‘wide’

kubectl get pods -o wide
=> Il y a désormais 4 répliquas de ‘mon-serveur’, chacun ayant sa propre adresse IP

Le service qui est associé au déploiement va être placé en mode ‘Load-Balancing’

=> Il aura une répartition de charges orchestrée par le gestionnaire du service ‘proxy’

Examiner l’état du service ‘appli-1’

kubectl describe services/appli-1

K8S- T.P. v240302 Jean GAUTIER

 Mode opératoire simple

1 - Création d'un 'Pod'

Fichier hello-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: helloworld
labels:
app: helloworld
Vérifiez que le pod est en marche
spec: kubectl get pods
containers:
- name: helloworld
image: particule/helloworld
ports:
- containerPort: 80
kubectl apply -f hello-pod.yaml

2 - Création d'un 'Deployment'

Fichier hello-deploy.yml.
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld
labels:
app: helloworld
spec:
replicas: 1 Supprimez le pod
selector: kuubectl delete pod helloworld
matchLabels:
app: helloworld
template:
metadata: ➔ Le pod n’est pas supprimé !
labels: Pourquoi ?
app: helloworld
spec:
containers:
- name: helloworld
image: particule/helloworld
ports:
- containerPort: 80
3 - Création d'un service
kubectl apply -f hello-deploy.yaml Fichier helloworld-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: helloworld-svc
labels:
app: helloworld
spec:
type: NodePort
ports:
- port: 80
nodePort: 30080
selector:
app: helloworld
kubectl apply -f hello-svc.yaml
K8S- T.P. v240302 Jean GAUTIER
kubectl describe svc hello-svc
Connexion aux pods
Le ‘Port Mapping’
• La notion de 'port' précise le n° de port sur lequel le trafic entrant sera reçu

• La notion de 'targetport' précise le n° de port des pods vers lesquels sera redirigé le trafic

Par défaut, le port du service est celui du port du conteneur (80).

Pour en changer, on peut définir un autre port, avec la directive 'targetPort'.

Afin de permettre aux applications déployées de communiquer en réseau, il existe plusieurs types de services

• ClusterIP
• NodePort
• ExternalIP
• LoadBalancer

ClusterIP
Chaque cluster Kubernetes dispose d'un réseau interne pour les services.
Le type de service par défaut est ClusterIP, qui fournit une adresse IP virtuelle aux Pods avec ‘Load-
Balancing’ du trafic entre les pods en mode répliquas.
Avec ce mode, les connexions ne sont possibles qu’à l’intérieur du cluster.

NodePort
Un service NodePort expose le service sur un port dans la plage '30000 – 32767', sur chaque nœud
du cluster.
Ce service est accessible aussi bien depuis l'intérieur que depuis l'extérieur, du cluster.
Le service est accessible via l'adresse IP du nœud ainsi que le port alloué.
Dans la spécification du service, le champ nodePort correspond au port de chaque nœud, le champ
port est le port du service et targetPort est le port du pod où le trafic réseau sera reçu.

K8S- T.P. v240302 Jean GAUTIER

Exemple d’utilisation

Fichier 'nodeport.yaml' :
apiVersion: v1
kind: Service
metadata:
Déploiement simple :
name: webapp1-nodeport-svc Fichier 'nginx-nodeport-service.yaml'
labels: apiVersion: v1
app: webapp1-nodeport kind: Service
spec: metadata:
type: NodePort name: nginx-nodeport-service
ports: spec:
- port: 80 type: NodePort
nodePort: 30080 selector:
selector: app: nginx
app: webapp1-nodeport ports:
--- - protocol: TCP
apiVersion: apps/v1 port: 80
kind: Deployment targetPort: 1080
metadata: nodePort: 30080
name: webapp1-nodeport-deployment
spec:
replicas: 2
selector:
matchLabels:
app: webapp1-nodeport
template:
metadata:
labels:
app: webapp1-nodeport
spec:
containers:
- name: webapp1-nodeport-pod
image: nginx:latest
ports:
- containerPort: 80

➔ L'application devient accessible depuis l’extérieur, en ciblant l'adresse IP du 'node' sur lequel
l'application est disponible et le port défini en tant que 'nodeport'

K8S- T.P. v240302 Jean GAUTIER

ExternalIP

Pour exposer le service uniquement sur une IP, il faut utiliser le service 'ExternalIP'

Fichier 'external-ip.yaml' (où 'HOSTIP' est l'IP du nœud du cluster) :

apiVersion: v1
kind: Service
metadata:
name: webapp1-externalip-svc
labels:
app: webapp1-externalip
spec:
ports:
- port: 80
externalIPs:
- HOSTIP
selector:
app: webapp1-externalip
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp1-externalip-deployment
spec:
replicas: 2
selector:
matchLabels:
app: webapp1-externalip
template:
metadata:
labels:
app: webapp1-externalip
spec:
containers:
- name: webapp1-externalip-pod
image: katacoda/docker-http-server:latest
ports:
- containerPort: 80

➔ Le service est maintenant lié à l'adresse IP du nœud du cluster.

K8S- T.P. v240302 Jean GAUTIER

Load Balancer
Un service Kubernetes de type LoadBalancer est une extension du type de service NodePort, utilisé pour
exposer un service à Internet.
Avec un service LoadBalancer, Kubernetes provisionne un équilibreur de charge réseau cloud et y associe
une adresse IP stable et fiable qui envoie le trafic vers les services créés par Kubernetes.
Le service de type 'Load Balancer' permet d'autoriser le trafic provenant de l’extérieur, tout en équilibrant la
charge, grâce à l’utilisation d’un contrôleur de flux entrant, 'l'ingress'

Exemple
apiVersion: v1
kind: Service
metadata:
name: nginx-loadbalancer-service
spec:
type: LoadBalancer
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80

• Un service de type 'load balancer' sera provisionné

• Le champ 'selector' doit correspondre au champ 'label' des pods afin de router le trafic vers les pods
concernés.
• 'port' désigne le port sur lequel le service écoute, 'targetPort' est le port des pods vers lequel sera
routé le trafic.

K8S- T.P. v240302 Jean GAUTIER

C'est l'objet 'nginx-ingress-controller' qui est le plus souvent utilisé.
Rendre un déploiement accessible grâce à l'ingress
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: sandbox
spec:
rules:
- host: srv.sandbox.io
http:
paths:
- path: /tp
backend:
serviceName: webapp1-clusterip-targetport-svc
servicePort: 80

Alors que l'URL spécifiée n'est pas réellement définie, il faudra spécifier le nom, lors de la requête de
connexion

• curl -H "Host: srv.sandbox.io" http://x.x.x.x:abcd/tp

K8S- T.P. v240302 Jean GAUTIER

L’ingress Controller

Rendre accessible les services depuis l'extérieur grâce à un service Ingress

L’objet ingress va recevoir les requêtes de l'extérieur et les dispatcher sur les services internes en fonction de ce qui est
demandé et en se basant sur le nom utilisé pour accéder au service et sur le contenu des requêtes HTTP.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: simple-fanout-example
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: srv.labo
http:

paths:
- path: /foo
backend:
serviceName: service-1
servicePort: 82

- path: /bar
backend:
serviceName: service-2
servicePort: 84

✔ les requêtes envoyées sur ‘http://srv.labo/foo’ seront dispatchées sur ‘service-1:82’

✔ les requêtes envoyées sur ‘http://srv.labo/bar’ seront dispatchées sur ‘service-2.84’

K8S- T.P. v240302 Jean GAUTIER

Exemple de configuration d’un accès à 2 x serveurs WEB distincts via un objet ‘Ingress’
On créé 2 x pods représentant les serveurs WEB ‘pomme’ et ‘banane’ ainsi qu’un objet ‘ingress’ permettant
de dispatcher les requêtes de connexion vers les deux serveurs.

Pod n°1 Pod n°2 Objet Ingress

Fichier : pomme.yaml Fichier : banane.yaml Fichier : ingress.yaml
kind: Pod kind: Pod apiVersion: extensions/v1beta1
apiVersion: v1 apiVersion: v1 kind: Ingress
metadata: metadata: metadata:
name: pomme-app name: banane-app name: example-ingress
labels: labels: annotations:
app: pomme app: banane ingress.kubernetes.io/rewrite-target: /
spec: spec: spec:
containers: containers: rules:
- name: pomme-app - name: banane-app - http:
image: hashicorp/http-echo image: hashicorp/http-echo paths:
args: args: - path: /pomme
- "-text=pomme" - "-text=banana" backend:
serviceName: pomme-service
--- --- servicePort: 5678
kind: Service kind: Service - path: /banane
apiVersion: v1 apiVersion: v1 backend:
metadata: metadata: serviceName: banane-service
name: pomme-service name: banane-service servicePort: 5678
spec: spec:
selector: selector:
app: pomme app: banane
ports: ports:
- port: 5678 - port: 5678

Mise en place
kubectl apply -f pomme.yaml
kubectl apply -f banane.yaml
kubectl create -f ingress.yaml

Tests de connexion
curl -kL http://localhost/pomme
pomme

curl -kL http://localhost/banane

banane

curl -kL http://localhost/notfound

default backend - 404

K8S- T.P. v240302 Jean GAUTIER

Installer un contrôleur ingress ‘nginx’

• kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.0/deploy/static/

provider/cloud/deploy.yaml

• helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --

namespace ingress-nginx --create-namespace

• kubectl get pods --namespace ingress-nginx

Vérifier si le service à obtenu une adresse IP

• kubectl get service ingress-nginx-controller --namespace=ingress-nginx

Créer un enregistrement DNS pointant vers le servie ngin

• kubectl create ingress demo --class=nginx --rule www.test.io/=demo:80

➔ A ce stade, on doit pouvoir se connecter sur la page d'accueil du service nginx

Créer 2 x serveurs WEB afin de les rendre accessibles, via le service nginx

Fichier ‘site-1.yaml’ Fichier ‘site-2.yaml’ Fichier ‘contenu-web.yaml ‘

apiVersion: apps/v1 apiVersion: apps/v1 apiVersion: networking.k8s.io/v1
kind: Deployment kind: Deployment kind: Ingress
metadata: metadata: metadata:
name: site-1 name: site-2 name: hello-world-ingress
spec: spec: annotations:
replicas: 1 replicas: 1 nginx.ingress.kubernetes.io/ssl-redirect: "false"
selector: selector: nginx.ingress.kubernetes.io/use-regex: "true"
matchLabels: matchLabels: nginx.ingress.kubernetes.io/rewrite-target: /$2
app: site-1 app: site-2 spec:
template: template: ingressClassName: nginx
metadata: metadata: rules:
labels: labels: - http:
app: site-1 app: site-2 paths:
spec: spec: - path: /site-1(/|$)(.*)
containers: containers: pathType: Prefix
- name: site-1 - name: site-2 backend:
image: nginx image:nginx service:
ports: ports: name: site-1
- containerPort: 80 - containerPort: 80 port:
env: env: number: 80
- name: TITLE - name: TITLE - path: /site-2(/|$)(.*)
value: "bienvenue sur le site" value: "Demo Ingress" pathType: Prefix
--- --- backend:
apiVersion: v1 apiVersion: v1 service:
kind: Service kind: Service name: site-2
metadata: metadata: port:
name: site-1 name: site-2 number: 80
spec: spec: - path: /(.*)
type: ClusterIP type: ClusterIP pathType: Prefix
ports: ports: backend:
- port: 80 - port: 80 service:
selector: selector: name: site-1
app: site-1 app: site-2 port:
number: 80

K8S- T.P. v240302 Jean GAUTIER

'Labeliser' les NODES

Spécifier un node lors des déploiements

Il faut affecter un label au node, ce qui permet ensuite de préciser sur quel node on vise le déploiement, en
spécifiant le label correspondant.

Exemple :
Affecter un label à un node :
• kubectl label nodes node1 SRV=1
• kubectl label nodes node2 SRV=2

Spécifier un node spécifique, lors d’un deployement

Fichier ‘nginx-deploy.yaml’
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
## This label is applied to the Deployment
type: dev
name: nginx-deploy
spec:
replicas: 1
selector:
matchLabels:
## This label is used to match the Pod to create replicas
type: dev
template:
metadata:
labels:
## This label is applied to the Pod
type: dev
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
nodeSelector:
SRV: 1

K8S- T.P. v240302 Jean GAUTIER

Le 'Scheduling'

Le schéduling est la planification du provisionnement de pods

Le provisionnement peut être réalisé avec stratégie, grâce à différentes options :

• NodeSelector
• Affinity/AntiAffinity
• Taints et Tolerations

L'option 'NodeSelector'
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
manager: robert
template:
metadata:
labels:
manager: robert
spec:
nodeSelector:
datacenter: alpha
containers:
- name: nginx
image: particule/helloworld
ports:
- containerPort: 80

➔ nodeSelector défini l'assignation du pod à un node possédant un label 'datacenter=alpha'.

K8S- T.P. v240302 Jean GAUTIER

L'option 'Affinity' / 'Anti Affinity'
Les règles d'affinité permettent de définir le provisionnement d'un groupe de pods en permettant de placer
des pods sur le même node ou, au contraire, de les forcer sur des nodes différents.

Exemple
Placer tous les pods sur des nodes ayant un label ‘datacenter=alpha’
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: pod-affinity-alpha
spec:
replicas: 2
selector:
matchLabels:
app: scheduling
template:
metadata:
labels:
app: scheduling
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: datacenter
operator: In
values:
- alpha
containers:
- name: alpha
image: particule/helloworld
ports:
- containerPort: 80

Exemple
Interdire de provisionner un pod sur un node possédant déjà un pod avec un label ‘app=scheduling’
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: pod-antiaff
spec:
replicas: 2
selector:
matchLabels:
app: scheduling
template:
metadata:
labels:
app: scheduling
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- scheduling
topologyKey: "kubernetes.io/hostname"
containers:
- name: alpha
image: particule/helloworld
ports:
- containerPort: 80

K8S- T.P. v240302 Jean GAUTIER

Les options 'Taints' et 'Tolerations'

Taint et Toleration permettent d’empêcher le provisionnement

Exemple :
Empêcher le provisionnement de pod sur un node.
• Les taints sont appliquées aux nodes
• Les tolerations sont appliquées aux pods

Placer un 'taint' sur des nodes :

• kubectl taint node worker region=secret:NoSchedule
• kubectl taint node master region=secret:NoSchedule

Un 'taint' est toujours de la forme key=value:effect avec value optionnelle.

Exemple
---
apiVersion: v1
kind: Pod
metadata:
name: alpha
spec:
containers:
- name: alpha
image: particule/helloworld

➔ Tant que le pod ne tolère aucun 'taint', il ne peut pas être provisionné !

Ajouter une 'Toleration' :

---
apiVersion: v1
kind: Pod
metadata:
name: alpha
spec:
containers:
- name: alpha
image: particule/helloworld
tolerations:
- key: "region"
operator: "Equal"
value: "secret"
effect: "NoSchedule"

K8S- T.P. v240302 Jean GAUTIER

Le contrôleur Ingress Traefik
Traefik est un outil de répartition de charge ainsi qu’un proxy inverse particulièrement indiqué pour la
publication d’applications de type microservices.

Fichier ‘traefik/values.yaml’
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: traefik
namespace: kube-system
spec:
valuesContent: |-
additionalArguments:
- "--api"
- "--api.dashboard=true"
- "--api.insecure=true"
- "--log.level=DEBUG"
ports:
traefik:
expose: true
providers:
kubernetesCRD:
allowCrossNamespace: true

• helm repo add traefik https://helm.traefik.io/traefik

• helm upgrade --install traefik traefik/traefik --namespace traefik --create-namespace -f traefik-config.yaml
• kubectl get svc traefik --namespace traefik
• kubectl get ingressclass

Fichier 'ingress-traefik.yaml'
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: mailhog-traefik
spec:
ingressClassName: traefik
rules:
- host: "mailhog-traefik.eni.yannig.ovh"
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: mailhog
port:
number: 8025

• kubectl apply -f ingress-traefik.yaml

Consultez l’état des règles Ingress de MailHog :

• kubectl -n kube-system logs deployment/external-dns -f
• kubectl -n kube-system logs -l app=external-dns -f
• kubectl -n traefik port-forward deployment/traefik 9000

➔ L’interface de Traefik est maintenant disponible à l’adresse http://localhost:9000/dashboard/

K8S- T.P. v240302 Jean GAUTIER