【.com快速翻译】一旦我们增加了对托管在Kubernetes集群上的应用程序的HTTP请求，就会导致5xx错误激增。GraphQL服务器上的一个应用程序，它调用许多外部API并返回聚合响应。我们最初的对策是增加应用程序的副本数量，看看它是否提高了性能并减少了错误。随着我们进一步深入研究，我们发现大多数故障都与DNS解析有关。这就是我们开始深入研究Kubernetes上的DNS解析的原因。CoreDNS公制DNS服务器将记录存储在其数据库中，并使用该数据库来回答对域名的查询。如果DNS服务器没有此数据，它会尝试从其他DNS服务器寻找解决方案。CoreDNS在Kubernetes1.13+之后成为默认的DNS服务。今天，当使用托管Kubernetes集群或自管理集群来处理应用程序工作负载时，通常会在没有过多关注Kubernetes提供的服务或如何利用它们的情况下调整应用程序。DNS解析是任何应用程序的基本要求，即使在Kubernetes集群上也是如此，并确保CoreDNS正确配置和运行。默认情况下，集群应该始终有一个用于查看关键CoreDNS指标的仪表板。为了获得CoreDNS指标，您应该启用Prometheus插件作为CoreDNS配置的一部分。下面是使用Prometheus插件从CoreDNS实例启用指标收集的示例配置。.:53{errorshealthkubernetescluster.localin-addr.arpaip6.arpa{podsverifiedfallthroughin-addr.arpaip6.arpa}prometheus:9153forward./etc/resolv.confcache30loopreloadloadbalance}以下是我们建议您在您的dashboard的关键指标。如果您使用Prometheus、DataDog、Kibana等，您可以从社区/供应商处找到现成的仪表板模板。A。CacheHitPercentage：使用CoreDNS缓存响应的请求的百分比；b.DNS请求延迟：CoreDNS：CoreDNS处理DNS请求所花费的时间上行链路服务器：处理转发到上行链路的DNS请求所花费的时间c。Forwarding向上游服务器的请求数；d.请求的错误码：NXDomain:不存在的域FormErr:DNS请求格式错误ServFail:服务器故障NoError:没有错误，请求处理成功e.CoreDNS资源使用：服务器消耗内存、CPU、等。我们使用DataDog来监控特定的应用程序。这是一个使用DataDog构建的示例仪表板：减少DNS错误当我们开始研究应用程序如何向CoreDNS发出请求时，我们观察到大多数出站请求是由应用程序向外部API服务器发出的。这是resolv.conf在应用程序部署窗格中的典型外观：nameserver10.100.0.10searchkube-namespace.svc.cluster.localsvc.cluster.localcluster.localus-west-2.compute.internaloptionsndots:5KubernetesAttemptsto通过不同级别的DNS查找解析FQDN。考虑到上述DNS配置，当DNS解析器向CoreDNS服务器发送查询时，它会尝试根据搜索路径搜索域。如果我们正在寻找域boktube.io，它将执行以下查询以在最后一个查询中收到成功的响应：botkube.io.kube-namespace.svc.cluster.local<=NXDomainbotkube.io.svc.cluster.local<=NXDomainboktube.io.cluster.local<=NXDomainbotkube.io.us-west-2.compute.internal<=NXDomainbotkube.io<=NoERROR我们得到了很多NXDomainDNS查找，因为我们做了太多外部查找响应。为了对此进行优化，我们在Deployment对象中自定义了spec.template.spec.dnsConfig。更改如下所示：dnsPolicy:ClusterFirstdnsConfig:options:-name:ndotsvalue:"1"通过上述更改，pod上的resolve.conf也发生了更改。搜索仅在外部域上执行。这减少了对DNS服务器的查询次数，还有助于减少应用程序的5xx错误。下图可以看出NXDomain响应数量的差异：所以我们收到了很多对DNS搜索的NXDomain响应。为了对此进行优化，我们在Deployment对象中自定义了spec.template.spec.dnsConfig。以下是这些变化：一个更好的解决方案是在Kubernetes1.18+中引入的[节点级缓存](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)。根据您的需要自定义CoreDNS我们可以使用插件来自定义CoreDNS。Kubernetes支持不同类型的工作负载，标准的CoreDNS配置可能无法满足您的所有需求。CoreDNS有树内插件和外部插件。您尝试解析的FQDN类型可能会有所不同，具体取决于您在集群上运行的工作负载类型，例如应用程序是相互通信还是独立应用程序在Kubernetes集群外部进行交互。我们应该尝试相应地调整CoreDNS的旋钮。假设您在特定的公共/私有云中运行Kubernetes，并且您的大多数DNS支持的应用程序都在同一个云中。在这种情况下，CoreDNS还提供了特定的云相关或通用插件，可用于扩展DNS区域记录。您做出决定的关键因素之一是您是否在Kubernetes集群中运行了适当数量的CoreDNS实例。建议至少运行两个CoreDNS服务器实例，以更好地保证DNS请求得到服务。根据服务的请求数量、请求的性质、集群上运行的工作负载数量以及集群的大小，您可能需要向集群添加额外的CoreDNS实例或配置HPA（Horizo??ntalPodAutoscaler）。正在处理的请求数量、请求的性质、集群上运行的工作负载数量以及集群的大小等因素应该可以帮助您决定CoreDNS实例的数量。Ben强调了Kubernetes中DNS请求循环的重要性。很多时候，我们会认为这不是DNS的问题，但最后发现确实是DNS的问题，所以要小心这个坑。【翻译稿件，合作网站转载请注明原译者和出处.com】
