Cette documentation concerne la version la plus récente de GKE sur Azure, publiée en novembre 2021. Consultez les notes de version pour plus d'informations.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Présentation de la détection de services et DNS
Cet article explique comment GKE sur Azure interagit avec les services de noms de domaine (DNS).
Détection de services
La détection de services est le processus permettant aux charges de travail de découvrir des services sans connaître leur adresse IP. Cette section explique comment GKE sur Azure met en œuvre la détection de services et le service de DNS géré.
Kubernetes génère automatiquement des noms de service qui suivent la spécification ci-dessous :
service.namespace.svc.cluster.local
Où :
service : nom de votre service
namespace : espace de noms de votre service
Les charges de travail peuvent également accéder à des services externes, tels que example.net, à l'aide de noms DNS. Pour en savoir plus sur le comportement du DNS dans le cadre de Kubernetes, consultez la section DNS for Services and Pods (DNS pour les services et les pods).
CoreDNS
GKE sur Azure utilise CoreDNS pour résoudre les noms DNS au sein des clusters. CoreDNS s'exécute en tant que déploiement redondant et sujet au scaling, dans l'espace de noms kube-system. Le déploiement CoreDNS est associé à un service qui regroupe les pods CoreDNS et leur attribue une adresse IP unique. Le déploiement CoreDNS s'adapte à la taille et à l'utilisation du cluster.
NodeLocal DNSCache
GKE sur Azure utilise NodeLocal DNSCache pour améliorer les performances de la résolution DNS. NodeLocal DNSCache s'exécute en tant que DaemonSet sur chaque nœud de votre cluster. Lorsqu'un pod effectue une requête DNS, celle-ci est en premier lieu envoyée au cache DNS exécuté sur le même nœud. Si le cache ne peut pas résoudre la requête DNS, il la transfère alors soit :
à CoreDNS pour un nom interne (par exemple, foo.bar.svc.cluster.local) ;
Étape suivante
Pour obtenir une présentation de l'utilisation du DNS dans les clusters Kubernetes, consultez la page consacrée au DNS pour les services et les pods.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/07/01 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2024/07/01 (UTC)."],[],[],null,["# Service discovery and DNS overview\n==================================\n\nThis topic describes how GKE on Azure interacts with Domain\nName Services (DNS).\n\nService discovery\n-----------------\n\nService discovery is the process where workloads discover services without\nknowing the service's IP address. This section describes how\nGKE on Azure implements service discovery and managed DNS.\n\nKubernetes automatically generates service names that use the following\n[specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md):\n\n\u003cvar translate=\"no\"\u003eservice\u003c/var\u003e`.`\u003cvar translate=\"no\"\u003enamespace\u003c/var\u003e`.svc.cluster.local`\n\nWhere:\n\n- \u003cvar translate=\"no\"\u003eservice\u003c/var\u003e: your service's name\n- \u003cvar translate=\"no\"\u003enamespace\u003c/var\u003e: your service's Namespace\n\nWorkloads also access external services--- for example `example.net`---\nusing DNS names. For more information on the behavior of DNS in Kubernetes, see\n[DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/).\n\n### CoreDNS\n\nGKE on Azure uses\n[CoreDNS](https://kubernetes.io/blog/2018/07/10/coredns-ga-for-kubernetes-cluster-dns/)\nto resolve DNS names within clusters. CoreDNS runs as a redundant, scaled\n[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)\nin the `kube-system`\nnamespace. The CoreDNS deployment has a\n[Service](/kubernetes-engine/docs/concepts/service) that groups the CoreDNS Pods\nand gives them a single IP address. The CoreDNS Deployment scales with the\ncluster's size and usage.\n\n### NodeLocal DNSCache\n\nGKE on Azure uses\n[NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)\nto improve DNS lookup performance. NodeLocal DNSCache runs as a\n[DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)\non each node in your cluster. When a Pod makes a DNS request, the request first\ngoes to the DNS cache on the same node. If the cache can't resolve the DNS\nrequest, the cache forwards the request to either:\n\n- CoreDNS for an internal name--- for example `foo.bar.svc.cluster.local`\n\nWhat's next\n-----------\n\n- For an overview of how DNS is used in Kubernetes clusters, see [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)."]]
