首页 > 解决方案 > 如何避免 coredns 解决 kubernetes 中的开销

问题描述

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

在扩展到 4 个实例后,解决时间的波动得到了一些增强。但这不是我们所期望的,而且20 ms开销仍然存在。

我们有一些 Web 服务,它们的实际响应时间是< 30 ms,使用coredns我们正在加倍响应时间,这并不酷!

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

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

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

标签: kubernetesdnscoredns

解决方案


在 kubernetes 集群中运行 coreDNS 时需要注意几件事

  • 记忆
  • 自动路径
  • 副本数
  • 自动缩放器
  • 其他插件
  • 普罗米修斯指标
  • 单独的服务器块

记忆

CoreDNS 推荐的副本内存量是

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

在此处输入图像描述

自动路径

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

通常,DNS 查询会通过

  1. ..svc.cluster.local
  2. .svc.cluster.local
  3. 集群本地
  4. 然后配置转发,一般是主机搜索路径(/etc/resolv.conf
Trying "example.com.default.svc.cluster.local"
Trying "example.com.svc.cluster.local"
Trying "example.com.cluster.local"
Trying "example.com"
Trying "example.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55265
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        30  IN  A   93.184.216.34

这需要更多内存,因此计算现在变为

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

副本数

默认为 2,但启用 Autoscaler 应该有助于解决负载问题。

自动缩放器

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns
  namespace: default
spec:
  maxReplicas: 20
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  targetCPUUtilizationPercentage: 50

节点本地缓存

Kubernetes 1.15 中的测试版

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

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

其他插件

这些也将有助于了解 CoreDNS 内部发生了什么

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

Trace - 启用请求如何通过 CoreDNS 流动的 OpenTracing

日志- 查询日志记录

健康- CoreDNS 已启动并运行,这将返回 200 OK HTTP 状态代码

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

部署中应使用 Ready 和 Health

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

普罗米修斯指标

普罗米修斯插件

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.

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

单独的服务器块

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

    CLUSTER_DOMAIN REVERSE_CIDRS {
        errors
        health
        kubernetes
        ready
        prometheus :9153
        loop
        reload
        loadbalance
    }

    . {
        errors
        autopath @kubernetes
        forward . UPSTREAMNAMESERVER
        cache
        loop
    }

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


推荐阅读