Le contrôleur d’entrée HAProxy Kubernetes publie deux ensembles de journaux: les journaux du contrôleur d’entrée et les journaux d’accès HAProxy.
Après avoir installé le contrôleur d’entrée HAProxy Kubernetes, la journalisation est l’une des premières fonctionnalités à configurer. Les journaux peuvent vous indiquer la version du contrôleur qui est en cours d’exécution et si le contrôleur a démarré correctement. Ils peuvent vous aider à identifier les problèmes liés à l’expérience utilisateur. L’accès aux journaux d’accès détaillés de HAProxy peut rapporter de gros dividendes, mais cela nécessite un peu de configuration.
Bien que le contrôleur d’entrée puisse être déployé sous la forme d’un ou de plusieurs conteneurs sur votre cluster, soit en tant que ReplicaSet, soit en tant que DaemonSet, il s’agit d’un programme unique. Tous ses composants sont soigneusement intégrés à l’intérieur d’une image Docker. Cependant, à l’intérieur de cette image, il y a deux parties distinctes: le processus du contrôleur d’entrée et l’équilibreur de charge HAProxy.
La partie contrôleur surveille le cluster pour les modifications apportées aux pods, secrets et autres types d’objets Kubernetes. Lorsqu’il détecte une modification, il déclenche une mise à jour de la configuration de l’équilibreur de charge HAProxy adjacente. La partie HAProxy gère le routage, le cryptage TLS, la limitation de débit et d’autres tâches proxy. Comme il y a deux parties, il existe deux sources pour les messages de journal.
Dans cet article de blog, vous apprendrez à configurer les journaux de votre contrôleur et les journaux d’accès HAProxy. Nous examinerons également quelques cas particuliers, tels que la façon de capturer des informations sur les taux de requêtes et les sessions TLS.
Journaux du contrôleur d’entrée
Les journaux du contrôleur d’entrée sont les journaux qui s’affichent juste après l’installation du contrôleur d’entrée. Si vous appelez kubectl logs avec le nom de l’un des pods du contrôleur d’entrée, vous verrez des informations importantes sur le démarrage telles que la version du contrôleur, les valeurs de ConfigMap, le certificat TLS par défaut, etc.
Ensuite, lors de l’exécution, plus d’informations seront enregistrées en fonction du niveau de verbosité du journal que vous pouvez définir avec l’argument –log du contrôleur à l’un des éléments erreur, avertissement, info, debug ou trace. La valeur par défaut est info, qui, en plus de capturer les erreurs et les avertissements, signale des changements importants comme la mise à jour des options par défaut et le rechargement de HAProxy. Pour modifier le niveau de journalisation sur debug, vous devez le définir lors de l’installation, comme indiqué ci-dessous:
Les journaux de débogage fournissent des informations détaillées sur l’activité du contrôleur. Les journaux du niveau de trace consignent également tous les événements Kubernetes que le contrôleur reçoit.
Journaux HAProxy
HAProxy émet un ensemble différent de messages de journal contenant une mine d’informations, ce qui peut aider à identifier les tendances et à repérer les anomalies dans votre trafic. Les journaux d’accès HAProxy peuvent être configurés via les annotations suivantes:
| Annotation | Description |
| syslog-server | Configure un ou plusieurs serveurs Syslog pour recevoir des journaux. |
| log-format | Définit la chaîne de format de journal par défaut. |
| dontlognull | Ignore la journalisation des connexions qui n’envoient aucune donnée, ce qui peut se produire avec les systèmes de surveillance. |
| logasap | Enregistre les données de requêtes et de réponses dès que le serveur renvoie un ensemble complet d’en-têtes de réponse HTTP sans attendre que la réponse ait terminé d’envoyer de toutes les données. |
Tant que vous n’avez pas configuré l’annotation syslog-server, vous ne verrez pas les journaux d’accès. Nous allons vous montrer comment le faire dans la section suivante.
Définition de la cible du journal
Pour configurer vos journaux d’accès, créer ou mettre à jour la ConfigMap du contrôleur, assurez-vous de lui donner le même espace de noms et le même nom que ceux indiqués dans les journaux de démarrage (par exemple default / haproxy-kubernetes-ingress). Ci-dessous, nous définissons l’annotation syslog-server dans une définition ConfigMap:
Ensuite, nous l’appliquons avec kubectl:
Si vous déployez le contrôleur d’entrée à l’aide du graphique Helm, vous pouvez définir ces valeurs lors de l’installation, comme indiqué:
Pour envoyer des journaux à stdout, utilisez cette valeur:
Ensuite, vous pouvez voir les messages du journal en appelant kubectl logs -f. Ceci est utile pour les configurations rapides, les preuves de concept, le débogage et d’autres situations ad hoc. Cependant, pour un environnement de production, la rétention et la collecte des journaux sont des considérations importantes à garder à l’esprit.
Une façon de rendre cela possible consiste à configurer un pilote de journalisation qui redirige le flux de journal de stdout vers une cible, par exemple vers un fichier. Selon le Guide de l’architecture de journalisation Kubernetes, le conteneur engine (i.e. Docker) est responsable de la redirection des journaux de conteneur:
Tout ce qu’une application conteneurisée écrit dans stdout et stderr est géré et redirigé quelque part par un moteur de conteneur. Par exemple, le moteur de conteneur Docker redirige ces deux flux vers un pilote de journalisation, qui est configuré dans Kubernetes pour écrire dans un fichier au format JSON.
Dans le cas du moteur de conteneur Docker, la rétention des journaux peut être définie via le paramètre log-opt dans le fichier daemon.json de Docker. Cependant, apporter des modifications au moteur de conteneur sous-jacent sur chaque nœud d’un cluster Kubernetes n’est pas la préférence de tout le monde.
Une autre option existe. Vous pouvez envoyer les journaux d’accès de HAProxy à un serveur syslog simplement en utilisant une valeur différente pour l’annotation syslog-server. Ce serveur pourrait être un conteneur side-car qui écoute l’adresse de bouclage, auquel cas vous définiriez l’annotation comme ceci:
Ou le serveur syslog peut être déployé en tant que service Kubernetes distinct qui reçoit les journaux de plusieurs pods de contrôleur d’entrée et les agrège. Dans ce cas, définissez l’annotation comme ceci:
Le format du journal
La chaîne de format de journal de HAProxy définit ce que HAProxy consignera. La valeur par défaut est le HTTP log-format, qui génère une ligne semblable à celle-ci:
Lisez notre article de blog Introduction à HAProxy Logging pour en savoir plus sur chacun de ces champs. Pour modifier le format, définissez l’annotation log-format.
Notez que lorsque vous utilisez TLS passthrough, HAProxy n’effectue pas d’inspection de la couche 7, mais transmet le trafic TLS directement aux backends en mode TCP. Dans ce cas, le contrôleur utilise une chaîne de format de journal TCP où il enregistre également la valeur SNI d’une connexion TLS.
Informations personnalisées du journal
Outre la possibilité de modifier le format de journal par défaut pour enregistrer différentes informations, vous pouvez utiliser le request-capture dans vos définitions Ingress ou Service pour capturer une expression HAProxy. Une expression peut inclure des fetch methods et converters.
Voici quelques expressions:
-
hdr (foo), lower– renvoie le contenu de l’en-tête foo converti en minuscules. -
req.body_param (foo)– renvoie le paramètre foo à partir du corps encodé en URL d’une requête POST. -
req.ssl_sni– renvoie la valeur de l’extension SNI.
Un cas d’utilisation simple de request-capture est la journalisation des en-têtes HTTP spécifiques. Par exemple, vous souhaiteriez peut-être capturer un en-tête contenant un ID de requête utilisé pour le débogage ou le traçage. Dans AWS, il s’agirait du En-tête X-Amzn-Trace-Id . Dans ce cas, la valeur de l’annotation request-capture serait:
Cela fournira une ligne de journal comme celle-ci, où l’ID de trace est Root = 1-5e9df9d4-ca09fd0867923f2862d8504a :
Cela peut être pratique lorsque vous devez faire des références croisées avec des journaux de différents composants traversés par une trace de requête. Un autre exemple est la journalisation de l’en-tête Authorization pour voir quel type d’autorisation une requête HTTP a utilisé:
Un cas d’utilisation plus avancé pour request-capture serait de consigner le nombre de requêtes par seconde provenant d’une adresse IP source donnée après avoir activé la limitation de débit avec l’annotation rate-limit-requests. Lorsque vous activez la limitation de débit, HAProxy créé une table de persistance qui suit le taux de requêtes pour chaque client. La table de persistance reçoit toujours un nom conventionnel de RateLimit-
Dans l’exemple suivant, nous capturons le taux de requêtes en utilisant la méthode d’extraction sc0_http_req_rate avec le nom de la table de persistance comme paramètre:
Cela fournira des journaux d’accès qui ressemblent à ce qui suit, où le taux par seconde est indiqué entre accolades:
Les récupérations d’échantillons (sample fetches) couvrent plus que la couche HTTP. Par exemple, si le contrôleur d’entrée a activé TLS, vous pouvez consigner des informations TLS telles que si la session TLS est nouvelle ou reprise, si un certificat client a été utilisé et le nom du chiffrement TLS négocié pour la connexion. L’exemple suivant montre une request-capture avec ces champs:
La sortie du journal ressemble à ceci, où les valeurs respectives sont 0, aucune valeur et TLS_AES_256_GCM_SHA384 :
Conclusion
Le contrôleur d’entrée HAProxy Kubernetes possède deux sources de journaux: le contrôleur et l’équilibreur de charge HAProxy. Les deux peuvent être personnalisés. Vous pouvez définir un niveau de verbosité différent pour les journaux du contrôleur et définir un nouveau format de journal et une nouvelle cible pour les journaux HAProxy. Il existe également une prise en charge de la capture d’informations personnalisées, telles que l’enregistrement d’en-têtes HTTP spécifiques, de taux de requêtes ou de champs TLS. Avec toutes ces options en main, vous pouvez profiter des informations détaillées que seul HAProxy propose.
Vous souhaitez rester à jour sur des sujets similaires? Abonnez-vous à notre blog ! Vous pouvez également nous suivre sur Twitter et rejoindre la conversation sur Slack.
