Quand le DNS des conteneurs devient-il un goulot d'étranglement pour un serveur domestique ?

Le DNS des conteneurs devient un goulot d’étranglement pour un serveur domestique lorsque la latence des recherches, la multiplication des requêtes ou la défaillance du résolveur consomment plus de temps que la requête de service locale elle-même.

Les conteneurs résolvent souvent les noms de service via un proxy DNS intégré avant que les requêtes n’atteignent un résolveur hôte ou en amont. Ce chemin supplémentaire est normalement rapide. Il devient visible lorsque les applications ouvrent de nombreuses connexions courtes, que les domaines de recherche génèrent des variantes échouées, que la mise en cache est faible ou qu’un seul résolveur local dessert chaque conteneur et appareil domestique.

Le conteneur ajoute un chemin de résolveur pour la découverte de services

Sur un réseau défini par l’utilisateur, un résolveur intégré peut mapper les noms et alias des conteneurs, puis transmettre les noms inconnus en amont. Un guide du DNS intégré Docker retrace cette décision locale versus transmise. Ce design permet aux services de se déplacer sans adresses IP codées en dur, mais il fait aussi de la résolution de noms une partie de chaque configuration de connexion non mise en cache.

L’hôte et le conteneur peuvent donc afficher des résultats différents. L’hôte peut interroger son résolveur directement tandis que le conteneur passe par le proxy d’exécution, un pont et des paramètres de résolveur hérités. Tester uniquement l’hôte peut faire manquer cette couche lente.

Les domaines de recherche peuvent transformer un nom en plusieurs requêtes

Un nom court comme database peut être testé avec un ou plusieurs suffixes de recherche avant que le résolveur ne l’essaie comme un nom absolu. La règle ndots affecte cet ordre. Des paramètres de recherche incorrects ou trop larges peuvent créer plusieurs requêtes négatives pour chaque résultat réussi.

Le guide de dépannage DNS des conteneurs de Netdata identifie ndots et les domaines de recherche comme causes de démarrages lents et de recherches bloquantes. C’est un risque dépendant de la configuration, pas une raison pour imposer une valeur ndots unique à tous les environnements.

Les connexions de courte durée multiplient le coût des recherches

Une application qui réutilise une connexion base de données ou HTTP résout le nom moins souvent. Un vérificateur de santé, un worker ou un client mal poolé peut créer une nouvelle connexion pour chaque tâche. Même un délai DNS modeste se retrouve alors à plusieurs reprises sur le chemin critique.

Un cas réel DNS conteneur versus hôte montre des recherches de plusieurs secondes dans le conteneur alors que les requêtes hôtes restaient rapides. Un rapport de latence DNS intégrée distinct enregistre le même contraste diagnostique, ce qui en fait une première séparation utile avant d’accuser l’application.

La mise en cache aide seulement dans sa durée de vie et son périmètre

La mise en cache DNS stocke une réponse jusqu’à l’expiration de son TTL, réduisant le volume de requêtes et le délai de démarrage. L’explication de la mise en cache DNS décrit comment les réponses mises en cache réduisent le travail réseau, mais les environnements d’exécution de conteneurs, les applications et les résolveurs locaux peuvent chacun avoir un comportement de cache différent.

Un cache n’est pas une solution universelle. Des TTL très courts, des enregistrements de service fréquemment modifiés, des recherches négatives et un comportement de résolveur par processus peuvent maintenir un taux de requêtes élevé. Un cache local défaillant ou surchargé devient aussi une dépendance partagée pour chaque service qui y pointe.

Le DNS est le goulot d’étranglement uniquement avant le démarrage de la connexion

Mesurez le temps de recherche séparément de la connexion TCP, de la négociation TLS, du premier octet et de la réponse de l’application. Si la résolution de nom est rapide mais que la requête est lente, changer de résolveur ne corrigera pas le service. Si l’accès IP brut est rapide et que l’accès par nom marque une pause, inspectez le chemin du résolveur du conteneur et la séquence des requêtes.

Une analyse de la latence DNS sur serveur domestique établit cette limite temporelle. Son explication de la latence des ponts virtuels aide à séparer le DNS du chemin des paquets qui suit la résolution.

FAQ

Pourquoi le DNS est-il rapide sur l’hôte mais lent dans un conteneur ?

Le conteneur peut utiliser un résolveur intégré, des domaines de recherche différents, des serveurs DNS hérités ou un espace de noms réseau séparé. Comparez les fichiers de résolveur et les requêtes chronométrées depuis les deux emplacements.

Les conteneurs doivent-ils utiliser un DNS public pour les noms de services locaux ?

Non. Les résolveurs publics ne connaissent pas les alias privés des conteneurs. Utilisez la découverte de services du runtime ou un résolveur local autoritaire, avec un transfert fiable pour les noms externes.

La mise en cache DNS peut-elle perturber la découverte de services des conteneurs ?

Des réponses obsolètes peuvent retarder la reconnaissance d’une adresse de service modifiée jusqu’à l’expiration du TTL. La politique de cache doit équilibrer la réduction des requêtes avec la rapidité des changements dans l’environnement.