Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Kubernetes
  3. Exposition des applications sur Internet
Extrait - Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (2e édition)
Extraits du livre
Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (2e édition)
1 avis
Revenir à la page d'achat du livre

Exposition des applications sur Internet

Objectifs du chapitre et prérequis

Sur un cluster Kubernetes, le déploiement d’applications est très rapide à faire : quelques déclarations, le lancement d’une commande et le cluster se charge du reste.

En revanche, les applications sont déployées dans une bulle et elles ne sont pas accessibles directement depuis l’extérieur.

Pour exposer ces services, le lecteur a abordé une première technique basée sur l’utilisation de règles Ingress. Ces règles permettent d’associer un hôte virtuel avec un service interne. Elles sont lues par un contrôleur Ingress qui se charge de configurer un proxy inverse qui sert de point d’entrée.

Malheureusement, l’histoire ne s’arrête pas là, puisqu’en plus de la publication sur un site web, l’administrateur aura d’autres opérations à réaliser parmi lesquelles :

  • la création d’entrées DNS,

  • la configuration d’un répartiteur de charge.

Ces aspects seront abordés dans ce chapitre. Différents contrôleurs Ingress seront présentés afin que vous puissiez en choisir un ou savoir comment les faire cohabiter à l’aide d’annotations.

À noter que pour réaliser les exercices qui suivent, il est recommandé de les faire sur un cluster hébergé...

Gestion des entrées DNS

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-feux.

images/14EP01.png

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

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

  • Mécanisme de création des entrées DNS.

  • Mise en place des répartiteurs de charge.

  • Mise à jour des accès par le proxy inverse.

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 :

  • 127.0.0.1.nip.io → 127.0.0.1

  • 192.168.0.1.nip.io → 192.168.0.1

  • entree-dns;10.10.12.1.nip.io → 10.10.12.1

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

Exposition de services et répartition de charge

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.

Dans le cas d’un service managé, la création de répartiteur de charge se fait automatiquement.

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

a. Rôle d’un service

Lors du déploiement des applications MailHog et MariaDB, un service leur a été...

Le contrôleur Ingress

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 :

  • Réception des requêtes de l’extérieur (en provenance du répartiteur de charge).

  • Appel vers les services internes.

  • Envoi des résultats vers le client externe.

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 :

  • Des en-têtes indiquant le type de l’objet.

  • Des métadonnées parmi lesquelles le nom de la règle.

  • Un champ spec contenant la définition des règles Ingress.

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

Le contrôleur Ingress Google

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 

Contrairement à un contrôleur Ingress Nginx, ce contrôleur n’a pas besoin de pods pour la partie proxy inverse. Cet aspect est pris en charge directement par l’API de Google.

3. Déploiement de MailHog

a. Préparation de la règle Ingress

Les fichiers de déploiements sont présents dans les fichiers...

Le contrôleur Ingress Nginx

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 par exemple 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)

a. Détermination du chart Helm à installer

 Il existe un chart Helm pour l’installation du contrôleur Ingress Nginx dans le dépôt ingress-nginx. Ajoutez-le à l’aide de la commande suivante :

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

 Lancez la recherche du chart à l’aide de la commande suivante :

$ helm search repo nginx-ingress 

La commande renvoie alors les paquets correspondant à cette recherche. Le paquet ingress-nginx/ingress-nginx...

Le contrôleur Ingress Traefik

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.

Autre point, l’ajout de la classe Ingress nécessite l’utilisation du champ ingressClass --> enabled à la valeur true. Afin d’indiquer que Traefik est le contrôleur par défaut, utilisez le champ ingressClass --> isDefaultClass.

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.

Enfin, afin de disposer d’informations sur les requêtes arrivant sur le contrôleur Ingress, activez les traces dans le journal d’activité du container. Cette opération se fait à l’aide du booléen logs --> access --> enabled. Dans le même contexte, le champ logs --> general --> level permet de spécifier le niveau du journal d’activité de Traefik : DEBUG, PANIC, FATAL, ERROR, WARN ou INFO.

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 Ingress controller ...