如何避免 coredns 解决 kubernetes 中的开销

Question

我认为标题几乎是不言自明的。我做了很多实验，可悲的事实是，这coredns确实增加了20 ms集群内所有请求的开销。起初我们认为也许通过添加更多复制并平衡更多实例之间的解析请求，我们可以提高响应时间，但这根本没有帮助。（我们从 2 个 pod 扩大到 4 个 pod）

扩展到 4 个实例后，解析时间的波动有所增强。但这并不是我们所期望的，而且20 ms开销仍然存在。

我们有一些网络服务，它们的实际响应时间是，< 30 ms并且使用coredns我们将响应时间加倍，这并不酷！

在得出这个问题的结论后，我们做了一个实验来仔细检查这不是操作系统级别的开销。结果与我们的预期并没有什么不同。

我们认为也许我们可以实现/部署一个基于hostname将每个 Pod 所需映射列表放入/etc/hosts该 Pod 内部的解决方案。所以我的最后问题如下：

• 还有其他人经历过类似的事情吗coredns？
• 您能否建议coredns在 k8s 环境中工作的替代解决方案？

任何想法或见解都值得赞赏。提前致谢。

Answer 1

在 kubernetes 集群中运行 coreDNS 时需要注意以下几点

\n\n

\n
• 记忆
\n
• 自动路径
\n
• 副本数量
\n
• 自动定标器
\n
• 其他插件
\n
• 普罗米修斯指标
\n
• 独立的服务器块
\n

\n\n

记忆

\n\n

CoreDNS 建议的副本内存量为

\n\n

MB required (default settings) = (Pods + Services) / 1000 + 54\n

\n\n

\n\n

自动路径

\n\n

Autopath是 Coredns 中的一项功能，有助于增加外部查询的响应时间

\n\n

通常 DNS 查询会经过

\n\n

\n
1. ..svc.cluster.local
\n
2. .svc.cluster.local
\n
3. 集群本地
\n
4. 然后配置转发，通常是主机搜索路径（/etc/resolv.conf
\n

\n\n

Trying "example.com.default.svc.cluster.local"\nTrying "example.com.svc.cluster.local"\nTrying "example.com.cluster.local"\nTrying "example.com"\nTrying "example.com"\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55265\n;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;example.com.           IN  A\n\n;; ANSWER SECTION:\nexample.com.        30  IN  A   93.184.216.34\n

\n\n

这需要更多内存，因此计算现在变成

\n\n

MB required (w/ autopath) = (Number of Pods + Services) / 250 + 56\n

\n\n

副本数量

\n\n

默认为 2，但启用自动缩放器应该有助于解决负载问题。

\n\n

自动定标器

\n\n

apiVersion: autoscaling/v1\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: coredns\n  namespace: default\nspec:\n  maxReplicas: 20\n  minReplicas: 2\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: coredns\n  targetCPUUtilizationPercentage: 50\n

\n\n

节点本地缓存

\n\n

Kubernetes 1.15 测试版

\n\n

\n

NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 dns 缓存代理来提高集群 DNS 性能。在今天的\xe2\x80\x99s 架构中，ClusterFirst DNS 模式下的 Pod 会联系 kube-dns serviceIP 进行 DNS 查询。这通过 kube-proxy 添加的 iptables 规则转换为 kube-dns/CoreDNS 端点。通过这种新架构，Pod 将连接到同一节点上运行的 dns 缓存代理，从而避免 iptables DNAT 规则和连接跟踪。本地缓存代理将查询 kube-dns 服务以查找集群主机名（默认为 cluster.local 后缀）的缓存未命中情况。

\n

\n\n

https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/

\n\n

其他插件

\n\n

这些也将有助于了解 CoreDNS 内部发生的情况

\n\n

错误- 查询处理期间遇到的任何错误都将打印到标准输出。

\n\n

Trace - 启用 OpenTracing 来了解请求如何流经 CoreDNS

\n\n

日志-查询日志记录

\n\n

health - CoreDNS 已启动并正在运行，这会返回 200 OK HTTP 状态代码

\n\n

就绪- 通过启用就绪，当所有能够发出就绪信号的插件都已这样做时，端口 8181 上的 HTTP 端点将返回 200 OK。

\n\n

部署中应使用 Ready 和 Health

\n\n

        livenessProbe:\n          httpGet:\n            path: /health\n            port: 8080\n            scheme: HTTP\n          initialDelaySeconds: 60\n          timeoutSeconds: 5\n          successThreshold: 1\n          failureThreshold: 5\n        readinessProbe:\n          httpGet:\n            path: /ready\n            port: 8181\n            scheme: HTTP\n

\n\n

普罗米修斯指标

\n\n

普罗米修斯插件

\n\n

coredns_health_request_duration_seconds{} - duration to process a HTTP query to the local /health endpoint. As this a local operation, it should be fast. A (large) increase in this duration indicates the CoreDNS process is having trouble keeping up with its query load.

\n\n

https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md

\n\n

独立的服务器块

\n\n

最后一点建议是将集群 DNS 服务器块与外部块分开

\n\n

    CLUSTER_DOMAIN REVERSE_CIDRS {\n        errors\n        health\n        kubernetes\n        ready\n        prometheus :9153\n        loop\n        reload\n        loadbalance\n    }\n\n    . {\n        errors\n        autopath @kubernetes\n        forward . UPSTREAMNAMESERVER\n        cache\n        loop\n    }\n

\n\n

有关 k8 插件和其他选项的更多信息，请参见此处 \n https://github.com/coredns/coredns/blob/master/plugin/kubernetes/README.md

\n