Équilibrage de charge des services Kubernetes avec NGINX Plus

Michael Pleshakov

Kubernetes est un système open source développé par Google pour exécuter et gérer, au sein d’un cluster, des applications basées sur des microservices conteneurisés. Les utilisateurs de Kubernetes ont souvent besoin de rendre les services qu’ils y créent accessibles depuis l’extérieur de leur cluster Kubernetes.

Bien que Kubernetes fournisse des solutions intégrées pour exposer les services, décrites dans la section Exposition des services Kubernetes à l’aide de solutions intégrées ci-dessous, ces solutions vous limitent à l’équilibrage de charge de couche 4 ou à l’équilibrage de charge HTTP de type round-robin.

Cet article explique comment utiliser NGINX Plus comme solution avancée d’équilibrage de charge de couche 7 pour exposer des services Kubernetes sur Internet, que vous exécutiez Kubernetes dans le cloud ou sur votre propre infrastructure.

Nous partons du principe que vous avez une connaissance de base de Kubernetes (pods, services, contrôleurs de réplication et étiquettes) et que vous disposez d’un cluster Kubernetes opérationnel. Pour en savoir plus sur Kubernetes, consultez le guide de l’utilisateur de Kubernetes officiel.

Exposer les services Kubernetes avec des solutions intégrées

Kubernetes propose plusieurs options pour exposer des services. Deux d’entre elles, NodePort et LoadBalancer, correspondent à un type de service spécifique. Une troisième option, l’API Ingress, est devenue disponible en version bêta avec Kubernetes 1.1.

NodePort

Le fait de définir le type de service sur « NodePort » rend le service disponible sur le même port de chaque nœud Kubernetes. Pour exposer le service à Internet, exposez un ou plusieurs nœuds sur ce port. Pour assurer une haute disponibilité, vous pouvez exposer plusieurs nœuds et utiliser un équilibrage de charge basé sur le DNS afin de répartir le trafic entre eux, ou placer les nœuds derrière l’équilibreur de charge de votre choix.

Lorsque le trafic entrant atteint un nœud sur le port, il est réparti entre les pods du service. L’équilibrage de charge effectué par le proxy réseau Kubernetes (kube-proxy) exécuté sur chaque nœud se limite à l’équilibrage de charge TCP/UDP.

Équilibreur de charge

Définir le type de service sur « LoadBalancer » alloue un équilibreur de charge cloud qui répartit le trafic entrant entre les pods du service.

La solution LoadBalancer n’est prise en charge que par certains fournisseurs de services cloud et par Google Container Engine ; elle n’est pas disponible si vous exécutez Kubernetes sur votre propre infrastructure. En outre, Kubernetes permet uniquement de configurer un équilibrage de charge TCP à tour de rôle, même si l’équilibreur de charge cloud dispose de fonctionnalités avancées telles que la persistance de session ou le routage des requêtes.

API Ingress

La création d’une ressource « Ingress » vous permet d’exposer des services sur Internet à des URL personnalisées (par exemple, le service A à l’URL /foo et le service B à l’URL /bar) et sous plusieurs noms d’hôtes virtuels (par exemple, foo.example.com pour un groupe de services et bar.example.com pour un autre groupe). Un contrôleur Ingress traite une ressource Ingress et configure un équilibreur de charge externe.

Un contrôleur Ingress ne fait pas partie d’un déploiement Kubernetes standard : vous devez choisir le contrôleur qui répond le mieux à vos besoins ou en implémenter un vous-même, puis l’ajouter à votre cluster Kubernetes. De nombreuses implémentations de contrôleurs devraient bientôt voir le jour, mais pour l’instant, la seule implémentation disponible est le contrôleur pour l’équilibreur de charge HTTP de Google Compute Engine, qui fonctionne uniquement si vous exécutez Kubernetes sur Google Compute Engine ou Google Container Engine. L’API Ingress prend uniquement en charge l’équilibrage de charge HTTP à tour de rôle (round-robin), même si l’équilibreur de charge utilisé offre des fonctionnalités avancées.

À l’heure où nous écrivons ces lignes, l’API Ingress et le contrôleur de l’équilibreur de charge HTTP de Google Compute Engine sont tous deux en version bêta.

Mise à jour – Le contrôleur Ingress NGINX pour NGINX et NGINX Plus est désormais disponible dans notre dépôt GitHub. Pour plus d’informations sur le produit, consultez Contrôleur Ingress NGINX.

Bien que les solutions mentionnées ci-dessus soient simples à configurer et fonctionnent immédiatement, elles n’offrent aucune fonctionnalité avancée, notamment en matière d’équilibrage de charge de couche 7.

Exposition des services Kubernetes avec NGINX Plus

[Note de la rédaction – Cette section a été mise à jour pour faire référence à l’API NGINX Plus, qui remplace et rend obsolète le module distinct de configuration dynamique initialement présenté ici.]

Pour intégrer NGINX Plus à Kubernetes, nous devons nous assurer que la configuration de NGINX Plus reste synchronisée avec Kubernetes et reflète les modifications apportées aux services Kubernetes, telles que l’ajout ou la suppression de pods. Avec NGINX Open Source, vous modifiez manuellement le fichier de configuration de NGINX, puis rechargez la configuration. Avec NGINX Plus, il existe deux façons de mettre à jour la configuration de manière dynamique :

• Avec les API – Cette méthode utilise l’API NGINX Plus pour ajouter et supprimer des entrées correspondant aux pods Kubernetes dans la configuration de NGINX Plus, et l’API Kubernetes pour récupérer les adresses IP des pods. Cette méthode nécessite d’écrire du code et nous ne l’aborderons pas en détail ici. Pour en savoir plus, regardez le webinaire de Kelsey Hightower, Déployer Kubernetes en périphérie avec NGINX Plus, dans lequel il explore les API et crée une application qui les utilise.
• En résolvant à nouveau les noms DNS – Cette méthode nécessite uniquement une configuration initiale appropriée de NGINX Plus, comme décrit dans la section suivante.

Utilisation de la reconfiguration basée sur DNS

Nous supposons que vous disposez déjà d’un cluster Kubernetes opérationnel et d’un hôte sur lequel l’utilitaire kubectl est disponible pour gérer le cluster. Pour obtenir des instructions, consultez le guide de prise en main de Kubernetes correspondant à votre type de cluster. Vous devez également avoir créé une image Docker NGINX Plus. Des instructions sont disponibles dans l’article Déploiement de NGINX et de NGINX Plus avec Docker sur notre blog.

Voici un aperçu de ce que nous allons faire :

1. Configurez un pod NGINX Plus afin d’exposer le service que nous créons à l’étape 2 et d’en équilibrer la charge.
2. Créez une application web simple qui fera office de service.
3. Augmentez et réduisez la capacité du service, et observez comment NGINX Plus est automatiquement reconfiguré.

Remarques : Nous avons testé la solution décrite dans cet article avec Kubernetes 1.0.6 exécuté sur Google Compute Engine ainsi qu'avec une configuration locale sous Vagrant, que nous utilisons ci-dessous.

Dans les commandes, les valeurs susceptibles de varier selon votre configuration Kubernetes apparaissent en italique.

Configuration du pod NGINX Plus

Nous plaçons NGINX Plus dans un pod Kubernetes sur un nœud que nous exposons à Internet. Notre pod est créé par un contrôleur de réplication, que nous configurons également. Notre fichier de configuration NGINX Plus propre à Kubernetes se trouve dans un dossier partagé entre le pod NGINX Plus et le nœud, ce qui en simplifie la maintenance.

Choisir un nœud pour héberger le pod NGINX Plus

Pour désigner le nœud sur lequel s’exécute le pod NGINX Plus, nous ajoutons une étiquette à ce nœud. Pour obtenir la liste de tous les nœuds, nous exécutons :

$ kubectl get nodesNAME         LABELS                              STATUS
10.245.1.3   Kubernetes.io/hostname=10.245.1.3   Ready
10.245.1.4   Kubernetes.io/hostname=10.245.1.4   Ready
10.245.1.5   Kubernetes.io/hostname=10.245.1.5   Ready

Nous choisissons le premier nœud et lui ajoutons une étiquette en exécutant :

$ kubectl label node 10.245.1.3 role=nginxplus

Configuration du contrôleur de réplication pour le pod NGINX Plus

Nous ne créons pas directement un pod NGINX Plus, mais passons par un contrôleur de réplication. Nous configurons le contrôleur de réplication du pod NGINX Plus dans un fichier de déclaration Kubernetes nommé « nginxplus-rc.yaml ».

• Nous définissons le nombre de « réplicas » sur un, ce qui signifie que Kubernetes veille à ce qu’un pod NGINX Plus soit toujours en cours d’exécution : si le pod tombe en panne, il est remplacé par un nouveau pod.
• Dans le champ nodeSelector, nous indiquons que le pod NGINX Plus est créé sur un nœud portant l’étiquette role: nginxplus.
• Notre conteneur NGINX Plus expose deux ports, 80 et 8080, que nous associons respectivement aux ports 80 et 8080 du nœud.
• Notre conteneur NGINX Plus partage également le dossier « /etc/nginx/conf.d » qui se trouve sur le nœud. Comme expliqué plus en détail dans la section « Configuration de NGINX Plus » ci-dessous, le partage de ce dossier nous permet de reconfigurer NGINX Plus sans reconstruire l’image du conteneur.

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginxplus-rc
spec:
  replicas: 1
  selector:
    app: nginxplus
  template:
    metadata:
      labels:
        app: nginxplus
    spec:
      nodeSelector:
        role: nginxplus
      containers:
      - name: nginxplus
        imagePullPolicy: IfNotPresent
        image: nginxplus
        ports:
          - name: http
            containerPort: 80
            hostPort: 80
          - name: http-alt
            containerPort: 8080
            hostPort: 8080
        volumeMounts:
          - mountPath: "/etc/nginx/conf.d"
            name: etc-nginx-confd
      volumes:
        - hostPath:
            path: "/etc/nginx/conf.d"
          name: etc-nginx-confd

Rendre l’image Docker NGINX Plus disponible sur le nœud

Comme indiqué précédemment, nous avons déjà créé une image Docker NGINX Plus. Nous allons maintenant la rendre disponible sur le nœud. Par souci de simplicité, nous n’utilisons pas de dépôt Docker privé et chargeons simplement l’image manuellement sur le nœud.

Sur l’hôte où nous avons créé l’image Docker, nous exécutons la commande suivante pour enregistrer l’image dans un fichier :

$ docker save -o nginxplus.tar nginxplus

Nous transférons nginxplus.tar vers le nœud, puis nous exécutons la commande suivante sur celui-ci afin de charger l’image à partir du fichier :

$ docker load -i nginxplus.tar

Configuration de NGINX Plus

Dans le conteneur NGINX Plus, nous conservons dans le dossier /etc/nginx le fichier de configuration principal par défaut nginx.conf fourni avec les paquets NGINX Plus. La directive include du fichier par défaut charge d’autres fichiers de configuration depuis le dossier /etc/nginx/conf.d. Comme indiqué dans le fichier de déclaration du contrôleur de réplication NGINX Plus (nginxplus-rc.yaml), nous partageons le dossier /etc/nginx/conf.d du nœud NGINX Plus avec le conteneur. Ce partage nous permet de modifier les fichiers de configuration stockés dans ce dossier (sur le nœud) sans avoir à reconstruire l’image Docker NGINX Plus, ce qui serait nécessaire si nous créions le dossier directement dans le conteneur. Nous plaçons notre fichier de configuration propre à Kubernetes (backend.conf) dans le dossier partagé.

Commençons par créer le dossier /etc/nginx/conf.d sur le nœud.

$ sudo mkdir -p /etc/nginx/conf.d

Nous y créons ensuite le fichier « backend.conf » et y ajoutons les directives suivantes :

• resolver – Définit le serveur DNS que NGINX Plus utilise pour résoudre à nouveau périodiquement le nom de domaine servant à identifier nos serveurs en amont (dans la directive server du bloc upstream, abordée au point suivant). Nous identifions ce serveur DNS par son nom de domaine, kube-dns.kube-system.svc.cluster.local. Le paramètre valid indique à NGINX Plus d’envoyer une requête de nouvelle résolution toutes les cinq secondes. (Notez que le processus de résolution de cette directive diffère de celui des serveurs en amont : ce nom de domaine est résolu uniquement au démarrage ou au rechargement de NGINX, et NGINX Plus utilise le ou les serveurs DNS système définis dans le fichier /etc/resolv.conf pour le résoudre.)
• upstream – Crée un groupe de serveurs en amont nommé backend contenant les serveurs qui fournissent le service Kubernetes que nous exposons. Au lieu de répertorier les serveurs individuellement, nous les identifions à l’aide d’un nom d’hôte complet dans une seule directive server. Le paramètre resolve indique à NGINX Plus de résoudre à nouveau le nom d’hôte lors de l’exécution, conformément aux paramètres spécifiés par la directive resolver. Comme Kubernetes DNS et NGINX Plus (R10 et versions ultérieures) prennent tous deux en charge les enregistrements de service DNS (SRV), NGINX Plus peut obtenir les numéros de port des serveurs en amont via DNS. Nous incluons le paramètre service afin que NGINX Plus demande des enregistrements SRV, en spécifiant le nom (_http) et le protocole (_tcp) des ports exposés par notre service. Nous déclarons ces valeurs dans le fichier webapp-svc.yaml présenté dans la section Création du contrôleur de réplication pour le service ci-dessous. Pour plus d’informations sur la découverte de services avec DNS, consultez l’article Utilisation de DNS pour la découverte de services avec NGINX et NGINX Plus sur notre blog.
• server (deux fois) – Définit deux serveurs virtuels :
  • Le premier serveur écoute sur le port 80 et répartit la charge des requêtes entrantes destinées à /webapp (notre service) entre les pods exécutant des instances du service. Nous configurons également des contrôles d’intégrité actifs.
  • Le deuxième serveur écoute sur le port 8080. Nous configurons ici la surveillance de l’activité en temps réel de NGINX Plus. Nous l’utiliserons plus tard pour vérifier que NGINX Plus a été correctement reconfiguré. [Note de l’éditeur – La configuration de ce deuxième serveur a été mise à jour afin d’utiliser l’API NGINX Plus, qui remplace et rend obsolète le module d’état distinct utilisé à l’origine.]

resolver kube-dns.kube-system.svc.cluster.local valid=5s;

upstream backend {
    zone upstream-backend 64k;
    server webapp-svc.default.svc.cluster.local service=_http._tcp resolve;
}

server {
    listen 80;
    status_zone backend-servers;

    location /webapp {
        proxy_pass http://backend;
        health_check;
    }
}

server {
    listen 8080;
    root /usr/share/nginx/html;

    location = /dashboard.html { }

    location = / {
        return 302 /dashboard.html;
    }

    location /api {
        api write=on;
    }
}

Création du contrôleur de réplication

Nous sommes maintenant prêts à créer le contrôleur de réplication en exécutant cette commande :

$ kubectl create -f nginxplus-rc.yaml

Pour vérifier que le pod NGINX Plus a bien été créé, nous exécutons :

$ kubectl get pods
NAME                 READY     STATUS    RESTARTS   AGE
nginxplus-rc-0ts5t   1/1       Running   0          17s

Nous exécutons Kubernetes dans un environnement Vagrant local. Nous savons donc que l’adresse IP externe de notre nœud est 10.245.1.3 et nous utiliserons cette adresse pour la suite de cet exemple. Si vous exécutez Kubernetes chez un fournisseur de services cloud, vous pouvez obtenir l’adresse IP externe de votre nœud en exécutant la commande suivante :

$ kubectl get nodes node-name -o json | grep -i externalIP -A 1                "type": "ExternalIP",
                "address": XXX.XXX.XXX.XXX

Si vous utilisez un environnement cloud, n’oubliez pas de configurer une règle de pare-feu afin d’autoriser le nœud NGINX Plus à accepter le trafic entrant. Consultez la documentation de votre fournisseur de services cloud.

Nous pouvons vérifier que notre pod NGINX Plus est opérationnel en consultant le tableau de bord de surveillance de l’activité en temps réel de NGINX Plus, accessible sur le port 8080 à l’adresse IP externe du nœud (soit http://10.245.1.3:8080/dashboard.html dans notre cas). Toutefois, à ce stade, aucun serveur n’apparaît pour notre service, car nous ne l’avons pas encore créé.

Création d’un service Kubernetes simple

Il est maintenant temps de créer un service Kubernetes. Notre service se compose de deux serveurs web, chacun proposant une page web contenant des informations sur le conteneur dans lequel il s’exécute.

Création du contrôleur de réplication pour le service

Nous créons tout d’abord un contrôleur de réplication afin que Kubernetes veille à ce que le nombre spécifié de réplicas du serveur web (pods) soit toujours en cours d’exécution dans le cluster. Voici le fichier de déclaration (webapp-rc.yaml) :

apiVersion: v1kind: ReplicationController
metadata:
  name: webapp-rc
spec:
  replicas: 2
  selector:
    app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: hello
        image: nginxdemos/hello 
        ports:
        - containerPort: 80

Notre contrôleur se compose de deux serveurs web. Nous déclarons un contrôleur composé de pods contenant un seul conteneur et exposant le port 80. L’image nginxdemos/hello sera téléchargée depuis Docker Hub.

Pour créer le contrôleur de réplication, nous exécutons la commande suivante :

$ kubectl create -f webapp-rc.yaml

Pour vérifier que nos pods ont bien été créés, nous pouvons exécuter la commande suivante. Nous utilisons le sélecteur de libellé « app=webapp » afin de récupérer uniquement les pods créés par le contrôleur de réplication à l’étape précédente :

$ kubectl get pods -l app=webapp
NAME             READY     STATUS    RESTARTS   AGE
webapp-rc-544f1   1/1       Running   0          2m
webapp-rc-uk6pm   1/1       Running   0          2m

Création du service

Nous créons ensuite un service pour les pods créés par notre contrôleur de réplication. Nous déclarons ce service à l’aide du fichier suivant (webapp-service.yaml) :

apiVersion: v1kind: Service
metadata:
  name: webapp-svc
spec:
  clusterIP: None
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: webapp

Ici, nous déclarons un service headless spécial en définissant le champ ClusterIP sur None. Avec ce type de service, aucune adresse IP de cluster n’est attribuée et le service n’est pas accessible via kube-proxy. Une requête DNS adressée au DNS de Kubernetes renvoie plusieurs enregistrements A (les adresses IP de nos pods).

Nous déclarons également le port que NGINX Plus utilisera pour se connecter aux pods. Outre les numéros de port et de port cible, nous indiquons le nom (http) et le protocole (TCP). Nous utilisons ces valeurs dans le fichier de configuration de NGINX Plus, dans lequel nous indiquons à NGINX Plus d’obtenir les numéros de port des pods via DNS à l’aide d’enregistrements SRV.

En définissant le champ « selector » sur « app: webapp », nous indiquons quels pods appartiennent au service, à savoir les pods créés par notre contrôleur de réplication NGINX (défini dans webapp-rc.yaml).

Nous exécutons la commande suivante, qui crée le service :

$ kubectl create -f webapp-service.yaml

Maintenant, si nous actualisons la page du tableau de bord et cliquons sur l’onglet « Upstreams » dans le coin supérieur droit, nous voyons les deux serveurs que nous avons ajoutés.

Nous pouvons également vérifier que NGINX Plus répartit la charge du trafic entre les pods du service. Si c’est le cas, lorsque nous accédons à l’adresse http://10.245.1.3/webapp/ dans un navigateur, la page affiche des informations sur le conteneur dans lequel s’exécute le serveur web, telles que le nom d’hôte et l’adresse IP.

Si nous actualisons cette page plusieurs fois et consultons le tableau de bord d’état, nous pouvons voir comment les requêtes sont réparties entre les deux serveurs en amont.

Mise à l’échelle du service Kubernetes

[Éditeur – Cette section a été mise à jour afin d’utiliser l’API NGINX Plus, qui remplace et rend obsolète le module d’état distinct utilisé à l’origine.]

Ajoutons maintenant deux pods supplémentaires à notre service et vérifions que la configuration de NGINX Plus est à nouveau mise à jour automatiquement. Nous exécutons cette commande pour porter le nombre de pods à quatre en mettant à l’échelle le contrôleur de réplication :

$ kubectl scale rc webapp-rc --replicas=4
scaled

Pour vérifier que NGINX Plus a bien été reconfiguré, nous pourrions à nouveau consulter le tableau de bord, mais cette fois-ci, nous utilisons plutôt l’API NGINX Plus. Nous exécutons la commande suivante, où 10.245.1.3 est l’adresse IP externe de notre nœud NGINX Plus et 3 la version de l’API NGINX Plus. Pour mettre en forme proprement la sortie JSON, nous la transmettons à jq.

$ curl -s 10.245.1.3:8080/api/3/http/upstreams/backend/servers | jq{
  "peers": [
    {
      "id": 1,
      "server": "10.0.0.1:80",
      "backup": false,
      "weight": 1,
      "state": "unhealthy",
      "active": 0,
      "requests": 1,
      "responses": {
        "1xx": 0,
        "2xx": 0,
        "3xx": 0,
        "4xx": 0,
        "5xx": 0,
        "total": 0
      },
      "sent": 0,
      "received": 0,
      "fails": 0,
      "unavail": 0,
      "health_checks": {
        "checks": 1,
        "fails": 1,
        "unhealthy": 1,
        "last_passed": false
      },
      "downtime": 33965,
      "downstart": 1445378182275,
      "selected": 1445378131000
    },
    {
      "id": 2,
      "server": "10.246.1.6:80",
      ...
    },
    {
      "id": 3,
      "server": "10.246.3.2:80",
       ...
    {
      "id": 4,
      "server": "10.0.0.2:80",
      ...
    }
  ],
  "keepalive": 0
}

Le tableau peers de la sortie JSON comporte exactement quatre éléments, un pour chaque serveur web.

Réduisons maintenant le nombre de pods de quatre à un, puis vérifions à nouveau l’état de NGINX Plus :

$ kubectl scale rc webapp-rc --replicas=1scaled

$ curl -s 10.245.1.3:8080/api/3/http/upstreams/backend/servers | jq

Désormais, le tableau peers de la sortie JSON ne contient plus qu’un seul élément (la sortie est identique à celle du pair portant l’ID 1 dans l’exemple de commande précédent).

Maintenant que NGINX Plus est opérationnel, nous pouvons commencer à tirer parti de ses fonctionnalités avancées, telles que la persistance des sessions, la terminaison SSL/TLS, le routage des requêtes, la surveillance avancée, et bien plus encore.

Résumé

Les options de reconfiguration à la volée disponibles dans NGINX Plus permettent de l’intégrer facilement à Kubernetes, soit par programmation via une API, soit entièrement au moyen du DNS. L’utilisation de NGINX Plus pour exposer les services Kubernetes sur Internet offre de nombreuses fonctionnalités dont sont dépourvues les solutions d’équilibrage de charge actuellement intégrées à Kubernetes.

Pour découvrir comment NGINX Plus fonctionne avec Kubernetes, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de votre cas d’utilisation.

À propos de l’auteur

Michael Pleshakov

Autres articles de Michael Pleshakov