Exposition des applications sur Internet

1. Principe de fonctionnement

Exposer un service sur Internet demande certaines précautions. Une de ces précautions est de réduire au maximum la couverture d’attaque.

Ainsi, les services ne sont pas exposés directement sur l’extérieur et passent par un répartiteur de charge. De cette manière, les nœuds Kubernetes peuvent rester protégés derrière des pare-feu.

Schéma de principe d’exposition d’un service Kubernetes sur Internet

Dans la suite du chapitre, le lecteur abordera différentes étapes :

La section qui suit va présenter comment exposer les entrées DNS à l’aide de services DNS managés dans le cloud.

Les deux autres mécanismes seront également présentés un peu plus loin dans le chapitre.

2. Prérequis

Afin de réaliser ces exercices, vous devrez être administrateur d’une zone DNS ou avoir la possibilité de vous faire créer certains enregistrements.

Par la suite, le nom de domaine DNS utilisé sera yannig.ovh et la zone DNS déléguée sera eni.yannig.ovh.

Les exercices seront réalisés avec le service de nom de Google, mais les actions sont tout à fait transposables sur AWS, Azure ou un cluster Kubernetes interne.

Pour connaître les services supportés par external-dns, consultez l’adresse suivante : https://github.com/kubernetes-incubator/external-dns

3. Retour sur le fonctionnement du domaine DNS nip.io

Lors de l’utilisation d’Ingress, les entrées DNS utilisaient l’adresse IP de la machine Minikube combinée avec le mécanisme DNS de nip.io. Ce domaine DNS a pour particularité de répondre à toutes les résolutions DNS par l’adesse IP contenue derrière le préfixe .nip.io.

Quelques exemples de résolution de nom avec le domaine DNS nip.io :

Dans le cadre d’un test, ce mécanisme est suffisant. En revanche, pour un hébergement professionnel...

1. Présentation du mécanisme

L’exposition d’une application sur l’extérieur nécessite de passer par le port de service du contrôleur Ingress. À moins de n’avoir qu’un seul nœud dans le cluster Kubernetes, il est recommandé de faire passer ces accès par un répartiteur de charge.

Outre le fait d’augmenter la résilience du système, ce mécanisme permet également d’isoler les machines du cluster dans une zone inaccessible d’Internet.

À noter qu’un proxy inverse HTTP permet de mutualiser l’accès à plusieurs sites et ainsi de maximiser l’utilisation du répartiteur de charge. En revanche, ce n’est généralement pas le cas pour d’autres protocoles (SMTP, base de données). L’exposition d’un service non HTTP passera forcément par la mise en place d’un répartiteur de charge différent à chaque fois.

Ces répartiteurs de charge ont un coût qu’il ne faut pas négliger. Attention de n’exposer que les services qui en ont réellement besoin.

2. Retour sur la notion de service

1. Principe de fonctionnement

La gestion des entrées DNS et des répartiteurs de charge a été vue dans la section précédente. Reste à faire le lien avec le contrôleur Ingress.

Son principe de fonctionnement est le suivant :

Afin de mettre en place cette communication, l’utilisateur fait appel à des déclarations Ingress.

2. Le rôle du contrôleur Ingress

Le contrôleur Ingress va piloter le proxy inverse. Pour cela, il récupère les demandes de publication de service et configure automatiquement le proxy inverse.

Ce proxy recueille les requêtes externes pour les faire suivre vers les services internes à exposer.

3. Structure d’une règle Ingress

Les règles Ingress ont déjà été abordées plus tôt dans le livre. Ces dernières ont la structure suivante :

Ce champ spec doit contenir au moins un champ defaultBackend ou rules. Le champ defaultBackend désignera...

1. Prérequis

La suite de l’exercice se fera sur un cluster créé à l’aide du service managé Kubernetes de Google.

Pour plus de détails sur cette création, vous pouvez vous reporter à la section dédiée à la mise en place d’un cluster à l’aide du service managé de Google.

2. Présentation du contrôleur GLBC

Sur le service managé de Google, le choix a été fait d’intégrer un contrôleur Ingress maison. Ce contrôleur s’appuie sur le service de répartiteur de charge de Google (GLB).

Le pod associé à ce service porte le label k8s-app=glbc. La consultation des pods associés à ce label se fera à l’aide de la commande suivante :

$ kubectl -n kube-system get pods -l k8s-app=glbc 

La commande doit alors afficher le contenu suivant :

NAME                             READY   STATUS    RESTARTS   AGE 
l7-default-backend-7ff48c-ffd7   1/1     Running   0          1d 

3. Déploiement de Mailpit

1. Pourquoi changer de contrôleur Ingress ?

Le contrôleur de Google utilise un répartiteur de charge par objet Ingress. Outre le fait que ce mécanisme prend un certain temps à se lancer, la consommation de ressources cloud peut constituer une source de dépenses non négligeable. Dans ce cadre, le contrôleur Ingress Nginx est un bon choix par défaut.

En plus de Nginx, des contrôleurs existent basés sur les logiciels Haproxy et Traefik. D’autres variantes peuvent également exister comme Nginx+ offrant un support payant.

Autre aspect, il est parfois souhaitable de séparer les contrôleurs Ingress. En effet, sur de gros clusters de production, au-delà de certaines limites, les mises à jour peuvent devenir longues et sources de risques.

Pour aborder ces différents aspects, un contrôleur Ingress Nginx sera déployé en plus de celui par défaut dont disposent les clusters Google et Azure. Dans le cas d’Amazon, aucun contrôleur Ingress n’est présent par défaut.

2. Présentation du logiciel Nginx

Le logiciel Nginx est un serveur web open source qui joue le rôle d’alternative à Apache. Du fait de sa réputation, sa légèreté et sa facilité d’utilisation, il a été rapidement utilisé comme proxy inverse dans le monde de Kubernetes.

Ce logiciel est disponible en version payante afin d’offrir un support et des fonctionnalités supplémentaires (extension Nginx+).

Pour plus d’informations, consultez l’URL suivante : https://www.nginx.com/

Par la suite, seule la version open source sera présentée.

3. Installation d’Ingress Nginx sur GKE (Google)

$ helm repo add ingress-nginx \ 
     https://kubernetes.github.io/ingress-nginx 

$ helm search repo nginx-ingress 

1. Présentation de Traefik

Traefik est un outil moderne de répartition de charge ainsi qu’un proxy inverse. Il est particulièrement indiqué pour la publication d’applications de type microservices.

2. Installation du chart Helm

Le plus simple pour installer Traefik est de passer par le chart Helm.

Par défaut, le chart Helm de Traefik ne fonctionne pas correctement avec external-dns : en effet, le champ status des enregistrements n’est pas mis à jour automatiquement, empêchant le système de savoir quelle est la correspondance entre l’entrée DNS et l’adresse du répartiteur de charge. Il faut pour cela utiliser le booléen provider --> kubernetesIngress --> publishService --> enabled : ce dernier doit prendre la valeur true.

Dans le cas d’une installation multiple du contrôleur Ingress (comme expliqué précédemment pour le contrôleur Ingress Nginx), n’hésitez pas à utiliser le champ providers --> kubernetesCRD --> ingressClass afin de changer le nom de la classe Ingress du contrôleur. Ne faites pas ce changement s’il est prévu d’avoir un seul contrôleur Traefik.

Afin de simplifier le passage des paramètres au chart Helm, ces options seront stockées dans un fichier.

Ci-dessous le contenu complet de ce fichier :

# https://github.com/traefik/traefik-helm-chart/blob/master/ 
traefik/values.yaml 
ingressClass: 
  enabled: true 
  # Set this value to use Traefik as a default...