注意:以下文档只适用于TOP接口,请谨慎使用!

文档中心 > 聚石塔

集群DNS性能瓶颈

更新时间:2023/04/19 访问次数:3667

一、背景


集群中的容器实例,DNS解析均依赖集群内的DNS组件,云应用中业务请求的地址都需要经过集群DNS组件。例如,代码中访问RDS、REDIS、TOP api等。如果集群dns性能不足,会出现业务请求失败的问题。

集群DNS组件:

1)默认已安装的集群组件为coredns,副本数为2;

2)可选的高性能组件为localdns。


二、是否有性能瓶颈


1. 云应用有大量DNS请求的场景(比如连接rds,凡是涉及到域名地址解析的);

2. PHP等语言自身没有连接池特性的,或者应用自身没有DNS缓存的;

3. 偶尔出现域名地址无法解析错误的。


三、解决方案


1. 集群默认已安装的coredns组件,进行扩容。扩容比例为1/5的节点数(如15台ecs,那么coredns数量为3);

2. 为集群安装更高性能的localdns组件(该组件为daemonset,会在每个ECS节点起一个本地缓存)。


注:以上方案均为免费,集群组件自身占用一些计算资源,不收取其他费用。


如何评估该用哪种方案?

一般来说,如果业务量小,扩容下coredns就足够了;如果业务量大(域名地址解析QPS高,比如访问RDS),特别是php等不带连接池的开发语言,建议直接上localdns。如果是java等配置了连接池的应用,可以先扩容coredns观察,如果仍然有解析问题,再上localdns。


coredns扩容、安装localdns 答疑群联系@杭羽或@照前进行操作,提供集群id。

coredns扩容比较快,1分钟之内;localdns安装大概2-3分钟。


四、localdns缓存原理


NodeLocalDNS 是一个 DaemonSet,会在Kubernetes集群的每个节点上运行一个专门处理 DNS 查询请求的 Pod,该 Pod 会将集群内部域名查询请求发往 CoreDNS;将集群外部请求直接发往外部域名解析服务器。同时能够Cache所有请求。可以被看作是节点级别的高效DNS 缓存,能够大幅提高集群整体 DNS 查询的 QPS。NodeLocalDNS 会在集群的每个节点上创建一个专用的虚拟接口(接口绑定的 IP 需要通过 local_dns_ip 这个值来指定),节点上所有发往该 IP 的 DNS 查询请求都会被拦截到 NodeLocalDNS Pod 内进行处理;通过集群原有的 kube-dns 服务(该服务的 clusterIP 值需要通过kube_dns_ip来指定)来与CoreDNS进行通信。


image


FAQ

关于此文档暂时还没有FAQ
返回
顶部