Déployer et exposer une application

Trois objets suffisent à mettre une application en ligne ici : ce qui la fait tourner, ce qui l’adresse dans le cluster, ce qui l’expose au dehors. Le certificat TLS, lui, s’obtient tout seul.

Prérequis

kubectl connecté au cluster et un namespace à vous. Sinon, dix minutes : se connecter au cluster. Les exemples utilisent le namespace qro-demo et le nom d’hôte qro-demo.k8s.qiminfo-lab.ch, à remplacer par les vôtres.

Le nom d’hôte se choisit librement sous *.k8s.qiminfo-lab.ch : le DNS joker le résout déjà, il n’y a aucun enregistrement à demander. Une seule contrainte, un nom pris par un collègue ne peut pas l’être deux fois. Prenez votre trigramme suivi du sujet.

Les trois objets

Le Deployment fait tourner les conteneurs, le Service leur donne une adresse stable dans le cluster, l’Ingress publie le tout sur le domaine joker. L’annotation cert-manager.io/cluster-issuer déclenche la demande de certificat.

demo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: demo
          image: nginxinc/nginx-unprivileged:stable
          ports:
            - containerPort: 8080
          # Un cluster partagé : ce que vous ne réservez pas reste disponible
          # pour les autres, et ce que vous ne bornez pas peut les gêner.
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 500m
              memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: demo
spec:
  # Ni LoadBalancer ni NodePort : l'Ingress du cluster est le chemin d'entrée.
  type: ClusterIP
  selector:
    app: demo
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - qro-demo.k8s.qiminfo-lab.ch
      secretName: qro-demo-tls
  rules:
    - host: qro-demo.k8s.qiminfo-lab.ch
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: demo
                port:
                  number: 80

Appliquer et vérifier

1. Appliquez le fichier dans votre namespace.

   kubectl apply -n qro-demo -f demo.yaml

2. Regardez les pods démarrer. Running avec READY 1/1, et le reste peut suivre.

   kubectl get pods -n qro-demo -w

3. Attendez le certificat. cert-manager le demande dès l’Ingress créé, comptez une minute avant que READY passe à True.

   kubectl get ingress,certificate -n qro-demo

4. Ouvrez l’URL. La redirection depuis HTTP est faite par l’Ingress.

   curl -I https://qro-demo.k8s.qiminfo-lab.ch

Cette URL est publique, et son nom est publié

Le domaine joker se résout depuis Internet et rien n’est authentifié devant votre application : qui connaît l’URL entre. Le nom d’hôte lui-même finit dans les journaux publics de transparence des certificats, donc les balayages automatiques le trouvent sans que vous l’ayez communiqué à personne. Aucune donnée client, personnelle ou sensible, aucun secret dans les variables d’environnement, aucun export de base dans l’image.

Ce qui surprend au premier déploiement

Le symptôme	Ce qui se passe
Le certificat reste en attente	kubectl describe certificate -n qro-demo raconte l’échec. Le plus souvent un nom d’hôte hors de *.k8s.qiminfo-lab.ch, écrit différemment dans tls et dans rules, ou un secretName déjà pris dans le namespace.
404 renvoyé par l’Ingress	La requête a atteint le cluster mais aucune règle ne correspond : nom d’hôte différent de celui du manifeste, ou ingressClassName: nginx oublié.
502 ou 503	L’Ingress a trouvé sa règle, pas l’application derrière. Le selector du Service ne correspond pas aux labels du Deployment, ou le conteneur n’écoute pas sur targetPort.
Le pod redémarre en boucle	kubectl logs puis kubectl describe pod. Classiquement une image qui veut écrire dans un système de fichiers qu’elle n’a pas, ou se lier à un port privilégié.
ImagePullBackOff	Le cluster n’a pas vos identifiants de registre. Publiez l’image sur un registre public, ou créez un secret docker-registry dans votre namespace et référencez-le dans imagePullSecrets.
Le service reste Pending en LoadBalancer	Ce type de Service n’est pas le chemin d’entrée ici. Repassez en ClusterIP et exposez par l’Ingress.
Les données ont disparu au redéploiement	Un pod est éphémère et son disque avec. Vérifiez ce que kubectl get storageclass propose avant de compter sur un volume persistant, et ne comptez sur aucune sauvegarde.

Une base de test se remplit de données inventées

Le raccourci tentant, sur un cluster où tout se déploie en trois lignes, est de charger un extrait de production pour « tester avec du vrai ». C’est exactement ce qui est interdit, y compris pour une seule requête, y compris dans un pod supprimé le soir même. Générez un jeu de données, ou anonymisez avant de charger.

Quand j’ai fini

Rien ne s’arrête et rien ne se supprime tout seul. Le namespace emporte tout ce qu’il contient.

kubectl delete namespace qro-demo

Récupérez avant ce qui compte, manifestes et images de conteneurs, puisque aucune sauvegarde n’est garantie. Vos manifestes ont leur place dans un dépôt Git, pas seulement dans le cluster.

Ce qui n’est pas en libre-service

Tout ce qui dépasse votre namespace : installer un opérateur ou des CRD, ajouter un émetteur de certificats, un nom d’hôte en dehors du domaine joker, ou une réservation de ressources plus large que les quelques pods d’un test. Écrivez à lab@qiminfo.ch en décrivant ce que vous voulez tester et pour combien de temps.