Ingress on Zwindler's Reflection

Je déconseille nginx en tant qu'ingressController en production

Mon, 14 Nov 2022 06:30:00 +0200

Disclaimer

Je n’utilise plus nginx comme IngressController Kubernetes depuis 2020 (même si j’ai écris quelques articles dessus, notamment Exposer des applications containerisées Kubernetes (nginx Ingress Controller)). Aussi, il se peut que les informations contenues ici soient périmées.

Cependant, des issues récentes faisant état du même problème que le miens sont régulièrement ouvertes donc je pense que c’est toujours le cas.

• github.com/kubernetes/ingress-nginx/issues/2461 • github.com/kubernetes/ingress-nginx/issues/7115

Contexte

Pour qu’on mette tout de suite d’accord sur ce dont on parle, je ne déconseille évidemment pas l’usage de nginx en production. nginx est un soft robuste qui a fait ses preuves pendant des années et que j’utilise encore dans certains contextes pros et perso.

Cependant, quand j’ai commencé à travailler avec Kubernetes, j’ai (comme beaucoup) lu la documentation.

Et à l’époque, pour ce qui est de l’utilisation des Ingress, la documentation officielle mettait en avant l’implémentation de l’IngressController nginx disponible sur le Github de Kubernetes github.com/kubernetes/ingress-nginx.

Point intéressant, il existe un autre dépôt mis à disposition par la société nginx inc, que je n’ai jamais utilisé github.com/nginxinc/kubernetes-ingress. qui n’est peut être pas affecté. Cependant quand on parle de “l’IngressController nginx” la plupart des gens parle du repo sur le Github de Kubernetes (source : moi, tkt)

Et donc quel est le problème ?

Maintenant qu’on est bien d’accord que ce dont on parle, je peux vous raconter une petite histoire.

A l’époque je travaillais pour une entreprise industrielle qui hébergeait “dans le cloud” un logiciel vendu en SaaS.

Chaque client avait sa propre instance, hébergée sur un Kubernetes hébergé sur Azure.

Au début nous avions peu de clients, tout allait bien. Mais au fur et à mesure que le nombre de clients grossissait, on commençait à avoir des retours de la part des équipes métiers et support comme quoi, de temps en temps, l’application perdait temporairement la connexion au serveur.

En bon sysadmin et après avoir vérifié l’absence d’alertes de notre côté, on a d’abord blâmé l’utilisateur, le réseau et l’application elle même (dans cet ordre). #Trollface

Blague à part, la réalité, c’est que nous ne savions pas trop par où prendre le problème car nous n’avions aucun log, aucun incident et le coupures étaient au début très rares et surtout aléatoires en apparence.

Jusqu’au jour où…

Jusqu’au jour où, pour des histoires de CVEs à patcher, nous avons redéployé un très grand nombre d’applications dans un créneau horaire assez court.

A ce moment là, le nombre de plaintes a fortement augmenté et nous a permis de valider que le problème n’était pas aléatoire et était bien de notre côté.

Nous avons deviné qu’il y avait une corrélation entre le déploiement d’applications dans Kubernetes et la coupure des connexions (websockets) côté client.

On est pas seul

Une fois qu’on savait ça, on a trouvé le coupable assez vite. Une rapide recherche Google nous a permis de tomber sur plusieurs issues sur le repository de l’IngressController, décrivant les mêmes symptômes.

En creusant un peu, on a également trouvé un article très complet qui détaille bien mieux que ce que j’aurais pu faire le problème.

DanielFM - pain(less) NGINX Ingress

C’est quoi le problème ???

TL;DR tel que l’IngressController est implémenté par défaut, la configuration de nginx est rechargée à chaque fois qu’une modification a lieu sur les backends des Services Kubernetes.

Pour ceux qui ne sont pas encore bien familier avec ces concepts, à chaque fois qu’un Pod (votre app containerisée) est créé ou détruit, nginx est rechargé.

Théoriquement, ça se fait à chaud car nginx supporte les rechargements de configuration à chaud. Sauf que, tel que l’IngressController est implémenté, les Websockets ouvertes doivent être coupées…

Pour limiter la casse, à chaque rechargement de configuration, un processus nginx avec la nouvelle configuration est généré en parallèle de l’ancien qui est gardé au maximum 10 secondes pour donner une chance à toutes les connexions en cours de se fermer proprement.

Solutions ?

Dans son post, Daniel fait le tour des workarounds à votre disposition pour limiter la casse.

La première chose qu’on peut faire et qui marche bien est d’ajouter l’option --enable-dynamic-configuration qui fait que la configuration n’est plus rechargée à chaque changement de backends sur les services (événements hyper fréquent) mais uniquement lors des créations/suppression de services (le déploiement d’une nouvelle app).

Ça limite drastiquement le nombre de reloads mais n’est évidemment pas une solution.

Le deuxième levier mis en avant par Daniel est d’augmenter le timeout de 10s (--worker-shutdown-timeout) et de mettre quelque chose de très grand. Cependant, il met en garde contre cette solution car on se retrouve vite avec un duplication des processus nginx avec X versions de la conf, ce qui peut faire saturer la RAM de votre ingressController ou votre node…

Dernière idée, pour limiter la disruption causée par un changement, nous avions envisagé de segmenter en ayant un ingressController par namespaces. Ainsi en cas de redéploiement, seul les applications du namespace en cours de déploiement seraient concernées par la coupure (des « workarounds » plutôt) :

Limiter les reloads (pénible)
Augmenter sensiblement (24h ?) les timeout sur les connexions actives
Segmenter les namespaces (1 Ingress Controller par namespace, on limite l’impact d’un redéploiement à un client)

Mais alors on fait quoi ?

Comme il n’y a pas vraiment de solution à date, le plus simple reste de ne tout simplement pas utiliser l’IngressController nginx de Kubernetes 😉 et de lui préférer une implémentation gérant ce genre de cas à chaud.

Même si je n’ai pas retravaillé avec depuis un moment, nous avions eu à l’époque de bons résultats avec Traefik.

Et si vous en connaissez d’autres qui gèrent bien ce genre de cas, n’hésitez pas à me l’indiquer :).

Exposer des applications containerisées Kubernetes (nginx Ingress Controller)

Tue, 06 Mar 2018 12:45:47 +0000

Ingress et Ingress Controller versus Baremetal

Autant le dire tout de suite, cet article s’adresse surtout aux admins qui font du Kubernetes (K8s pour les intimes) et en plus qui font tout eux même. Mais comme je suis sympa j’explique tout et j’ai mis des schémas si vous êtes curieux ;-).

Je vous plante le décors : vous avez suivi un de mes tutos sur Kubernetes et vous avez maintenant un cluster opérationnel en dehors des gros cloud providers (Amazon, Google, …) et de leurs solutions clés en main (sur vos propres VMs et/ou serveurs physiques). Vous êtes super contents et il y a de quoi.

Seulement voilà, maintenant que vous pouvez spawner des containers à tire larigot, vous voulez pouvoir y accéder depuis l’Internet.

Mais là, comment faire ?

Le premier problème que vous risquez d’avoir est que les applications que vous déployez dans Kubernetes ne sont de base accessibles que DANS Kubernetes.

On va être très très vite limité, niveau usecases.

Pour accéder à un container (ou faire discuter 2 containers comme un serveur web et une base de données), on passe par l’intermédiaire d’un objet appelé Service. C’est cet objet qui permet le service discovery, le scaling aisé de nos applications et la résolution de nom au sein du cluster.

Cependant, hors du cluster, pas de résolution de nom et/ou d’accès aux ressources par ce biais. Vous allez donc devoir passer par un DNS externe pour spécifier aux clients où sont vos applications et trouver un moyen de différencier quelle requête externe doit aboutir dans quelle container.

Accéder aux ressources

Le premier problème est donc de réussir à accéder à notre service. S’il est possible de créer des Services (les points d’entrées de nos containers) de type LoadBalancer sur AWS, Azure et GCP, qui ont l’avantage de permettre un accès direct au service depuis Internet (magie !), le mieux que l’on puisse faire par défaut sur un cluster Baremetal, c’est un Service de type NodePort.

Si vous n’êtes pas chez un cloud provider comme nous l’avons dit au départ, vous allez vite vous rendre compte qu’il n’est pas trivial de présenter un container sur HTTP:80 ou HTTPS:443. Car par défaut, les Services NodePort exposent nos container sur un port aléatoire compris entre 30000 et 3X000-je-sais-pas-combien (mate la précision) sur tous les nœuds du clusters.

Il y a deux choses importantes dans cette dernière phrase :

D’abord, on va se retrouver avec des URLs du type : http://@IP_node:32251 pour accéder à un serveur web depuis l’extérieur. Pas glop.
Ensuite, pour un Service de type NodePort donné, le port alloué l’est sur TOUS les membres du cluster, que le container tourne dessus ou pas. Ça veut dire que peu importe quel nœud Kubernetes on interroge, le 32251 répondra TOUJOURS sur le même container (les requêtes sont forwardé au bon nœud de manière transparente). Ça veut aussi dire qu’il n’y aura qu’un seul service qui aura le privilège d’utiliser le 32251 et aucun autre Service ne pourra le réserver.

Clairement, c’est tout sauf idéal. On se retrouve donc à différencier les applications simplement avec les numéros des ports qu’on accède.

Le DNS

Et c’est pas fini…

Si on prend un cas simple : un site web à exposer sur Internet, on va souvent vouloir relier une URL humainement compréhensible au container qui gère ce site. Cependant cette notion n’a pas vraiment de sens avec Kubernetes.

Vous ne savez pas a priori où va être instancié votre container dans le cluster (i.e. sur quelle machine et donc sur quelle IP). Ça sera un des nœuds du cluster, mais lequel ? D’autant que le Pod bouge d’un nœud à l’autre au gré de la vie de l’application (drain du node pour maintenance ou incident). Difficile donc de donner avec certitude un enregistrement DNS fiable dans le temps.

Alors bien sûr, vous pouvez toujours fixer en dur l’adresse IP d’un des nœuds Kubernetes dans un enregistrement DNS mais cette méthode trouve très vite sa limite : le moindre arrêt du serveur cause la perte de l’accès à l’application, qui pourtant a probablement été redémarrée sur un nœud du cluster.

Vous me pardonnerez ce « comic » en mode Draw.io. On s’amuse comme on peut ;-)

A quoi ça sert d’avoir un cluster dans ce cas là ?

Vous aurez peut être alors l’idée d’utiliser un moyen automatique (genre ce script qui utilise Dynhost, au hasard) pour mettre à jour le DNS dès que l’application change de nœud. Mais c’est clairement de la bidouille et on se retrouvera avec pleins d’utilisateurs dont les caches DNS ne sont pas à jour.

La méthode simple

On peut quand même bosser avec ce qu’on a et présenter à nos gentils utilisateurs des URLs user-friendly sans trop de difficultés, dans la majorité des cas.

La première chose qu’on peut faire c’est simplement mettre en face de notre cluster Kubernetes un bête reverse proxy et/ou répartiteur de charge. Après tout, c’est ni plus ni moins ce que font AWS et autre avec leur implémentation du Service de type Loadbalancer.

L’ensemble des requêtes HTTP(S) sont donc dirigées vers le reverse proxy, qui se charge de masquer la complexité de l’URL (l’aiguillage via des ports chelous et le maintiens à jour de l’ensemble des nœud du cluster qu’on arrive à contacter) à l’utilisateur final.

Personnellement, pour mes projets perso, ça m’ennuie d’avoir un composant externe au cluster K8s pour faire ça. J’ai déjà investi dans un cluster pour rendre mes applications hautement disponibles (ce qui est déjà overkill), je ne vais pas en plus :

soit ajouter un SPOF en ajoutant une seule machine pour faire mon reverse proxy
soit ajouter un cluster de machines rien que pour le reverse proxy

Et les Ingress dans tout ça ?

Donc on l’a vu, tout ça c’est pas super propre et on ajoute potentiellement un SPOF, mais ça « marche ». Mais on peut faire mieux :)

Si vous manipulez un peu Kubernetes, vous avez donc peut être vu qu’il existe un autre type d’objet qui s’appelle les Ingress et les Ingress Controllers.

Pour ceux qui n’ont pas eu le temps de potasser, un Ingress est une règle qui permet de relier une URL à un Service et un Ingress Controller est un composant qui permet de piloter un reverse-proxy pour implémenter cette règle. C’est LA méthode propre pour traduire une URL provenant d’un client en requête interne dans le cluster K8s pour atteindre le bon service.

L’Ingress Controller le plus utilisé est probablement celui pour nginx, mais il existe des Ingress Controllers pour traefik ou ha-proxy (ou autre) qui ont été développés et qui sont plus ou moins aboutis.

Helm

Helm c’est super. J’en ai parlé dans un autre article il n’y a pas longtemps, c’est un genre de gestionnaire d’application pour Kubernetes et ça simplifie grandement son utilisation. Mais il faut être honnête, ce n’est pas toujours une super idée…

Déjà, la documentation sur la page d’accueil du Chart est super light. Si vous ne trouvez pas d’infos sur comment le déployer, c’est normal, c’est parce qu’il faut aller dans le dossier « deploy » du dépôt pour trouver la doc d’installation.

Du coup, confiant, j’y suis allé avant d’avoir trouvé cette page, et je me suis pris ma première claque ;-)

helm install stable/nginx-ingress --name nginx-ingress
NAME: nginx-ingress
LAST DEPLOYED: Sun Feb 25 16:24:11 2018
NAMESPACE: default
STATUS: DEPLOYED
[...]
NOTES:
The nginx-ingress controller has been installed.

Oh cool, ça marché déjà ?

kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-7c6f79d45c-jwqkp 0/1 CrashLoopBackOff 14 47m
nginx-ingress-default-backend-6664bc64c9-2zpg4 1/1 Running 0 47m

Ah ben non en fait parce que je suis en RBAC (K8s > 1.7.0) ! Il faut créer des autorisations et un compte de service pour l’Ingress Controller.

kubectl logs nginx-ingress-controller-7c6f79d45c-jwqkp
-------------------------------------------------------------------------------
NGINX Ingress controller
Release: 0.10.2
Build: git-fd7253a
Repository: https://github.com/kubernetes/ingress-nginx
-------------------------------------------------------------------------------
I0225 16:11:13.374547 7 flags.go:159] Watching for ingress class: nginx
I0225 16:11:13.376659 7 main.go:181] Creating API client for https://10.233.0.1:443
I0225 16:11:13.438774 7 main.go:193] Running in Kubernetes Cluster version v. (v1.9.0+coreos.0) - git (clean) commit 1b69a2a6c01194421b0aa17747a8c1a81738a8dd - platform linux/amd64
F0225 16:11:13.442654 7 main.go:80] &#x2716; It seems the cluster it is running with Authorization enabled (like RBAC) and there is no permissions for the ingress controller. Please check the configuration

Ok, pas grave… On supprime et on recommence !

helm list
NAME REVISION UPDATED STATUS CHART NAMESPACE
nginx-ingress 1 Sun Feb 25 16:24:11 2018 DEPLOYED nginx-ingress-0.9.1 default
helm delete nginx-ingress
release "nginx-ingress" deleted
helm install stable/nginx-ingress --name nginx-ingress --set rbac.create=true
[...]

Bon, ne vous fatiguez pas. Ça aura l’air de marcher mais en fait, le nginx-ingress-controller se base sur un Service de type… Loadbalancer ! Si vous n’êtes pas sur AWS, GCE ou Azure, votre Service restera indéfiniment à l’état Pending en attente d’une IP publique ;-)

kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-ingress-controller LoadBalancer 10.233.52.122 80:30215/TCP,443:31438/TCP 41m
nginx-ingress-default-backend ClusterIP 10.233.29.8 80/TCP 41m

Donc on laisse tomber Helm pour cette fois

En réalité, le mieux c’est de repartir sur le projet nginx Ingress Controller, qui donne (pour qui trouve la documentation) la bonne marche à suivre pour instancier rapidement son Ingress Controller.

github.com/kubernetes/ingress-nginx
github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md#bare-metal (lien mis à jour le 08/10/2018)

Partie à exécuter dans tous les cas

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/namespace.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/default-backend.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/tcp-services-configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/udp-services-configmap.yaml \
| kubectl apply -f -

Partie spécifique à ajouter pour déployer l’Ingress Controller dans un environnement de type RBAC (K8s >= 1.7)

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/rbac.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/with-rbac.yaml \
| kubectl apply -f -

Partie spécifique à ajouter en dernier, dans le cas où on est sur un cluster baremetal (i.e. en dehors des cloud providers).

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/provider/baremetal/service-nodeport.yaml \
| kubectl apply -f -

OK, on a quoi maintenant ?

Et bien, c’est pas encore fini malheureusement… En fait, tel quel, le dernier fichier YAML qu’on a créé nous créé un service de type NodePort…

Oui vous l’avez compris : retour à la case départ ! Nous avons un composant reverse proxy intégré à K8s, mais qui est en écoute sur un port 3XXXX au lieu du 80, et 3YYYY au lieu du 443. Là encore, on aurait pas du tout ce problème si on était chez AWS, car un service de type Loadbalancer (avec une IP publique) aurait été créé pour nous.

Rassurez vous, il y a des solutions, moyennant un peu de bidouille. J’en ai trouvé 2 dans notre cas.

Pour faire simple, la première nécessite juste de modifier unfichier de configuration de Kubernetes pour autoriser le composant NodePort à utiliser des ports en dessous de la limite arbitraire des 30000. Je ne suis pas fan du tout de cette solution mais elle « fonctionne » donc je vous laisse juger.

En revanche, je trouve la seconde bien plus élégante quoique peut être un peu moins flexible. On peut modifier le Service de l’Ingress Controller en y listant toutes les adresses IPs de tous vos serveurs K8s. Ce n’est pas super confortable dans le cas où ils changent souvent, mais ça à l’effet qu’on recherche, à savoir ouvrir les ports 80 et 443 et rediriger l’ensemble des requêtes HTTP vers les Ingress.

La modification à réaliser se situe au niveau du champ externalIPs :

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/provider/baremetal/service-nodeport.yaml -o ingress-nginx-service-nodeport.yaml
vi ingress-nginx-service-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
name: ingress-nginx
namespace: ingress-nginx
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
- name: https
port: 443
targetPort: 443
protocol: TCP
externalIPs:
- 10.0.0.1
- 10.0.0.2
- 10.0.0.3
selector:
app: ingress-nginx
kubectl apply -f ingress-nginx-service-nodeport.yaml

Normalement après application de la modification vous devriez avoir la joie (oui oui, carrément) de voir apparaitre sur tous les serveurs (que vous aurez listés) les ports 80 et 443 en écoute !!

ss -lnt
LISTEN 0 128 8.8.8.8:80 *:*
LISTEN 0 128 8.8.8.8:443 *:*

Super, et maintenant c’est bon, mon container nginx est accessible ?

Ah ben non, toujours pas. On a configuré l’Ingress Controller, mais ça fait un moment qu’on parle plus des Ingress…

Comme je l’ai dis plus haut, les Ingress sont donc les règles de notre reverse proxy, permettant de mapper les URLs entrant dans le cluster sur les ports 80 et 443 (ou autre si on en définit d’autres) vers les Services définis dans le K8s.

Heureusement c’est partie est assez simple à configurer. Voici l’exemple minimaliste d’une application dont le Service toto-app-svc écoute sur le port 8080 à l’intérieur du cluster Kubernetes. Ce service est maintenant accessible pour toute requête HTTP aboutissant sur un des noeuds du cluster et accédé avec l’URL toto.zwindler.fr.

cat nginx-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
name: nginx-ingress
spec:
rules:
- host: toto.zwindler.fr
http:
paths:
- path: /
backend:
serviceName: toto-app-svc
servicePort: 8080

Point intéressant à noter, il n’est plus nécessaire de faire du NodePort maintenant, on peut se contenter des ClusterIP par défaut. En effet, l’Ingress Controller étant interne au cluster K8s, il sait résoudre les Services sans passer par un port crado en 30000. Autant ne plus les exposer donc et bannir les NodePorts à présent !

Bon vous avez vu ? Cette dernière étape n’est pas la plus dure qu’on ait fait !

Et maintenant, à vos Ingress !