redis的端口号是多少（redis client 端口）



KubeDNS 由三部分构成：

• kube-dns：核心组件

• KubeDNS：依赖 中的 informer 机制，监听 Service 和 Endpoint 的变化情况，并将相关信息更新到 SkyDNS 中
• SkyDNS：负责 DNS 解析，监听在 10053 端口，同时也监听在 10055 端口提供 metrics 服务

• dnsmasq：区分 Domain 是集群内部还是外部，给外部域名提供上游解析，内部域名发往10053端口，并将解析结构缓存，提高解析效率

• dnsmasq-nanny：容器里的1号进程，不负责处理 DNS LookUp 请求，只负责管理 dnsmasq
• dnsmasq：负责处理 DNS LookUp 请求，并缓存结果

• sidecar: 对 kube-dns和dnsmasq进行监控检查和收集监控指标

查询请求首先会被发送到 kube-dns 的 DNS 缓存层 (Dnsmasq 服务器)。Dnsmasq 服务器会先检查请求的后缀，带有集群后缀（例如：”.cluster.local”）的请求会被发往 kube-dns，拥有存根域后缀的名称（例如：”.acme.local”）将会被发送到配置的私有 DNS 服务器 [“1.2.3.4”]。最后，不满足任何这些后缀的请求将会被发送到上游 DNS [“8.8.8.8”, “8.8.4.4”] 里。

优点：依赖 dnsmasq ，性能有保障

缺点：

• dnsmasq-nanny 通过kill 来重启 dnsmasq，简单粗暴，可能导致这段时间内大量的 DNS 请求失败
• dnsmasq-nanny 检测文件的方式，可能会导致以下问题：

• 每次遍历目录下的所有文件，然后用 ioutil.ReadFile 读取文件内容。如果目录下文件数量过多，可能出现在遍历的同时文件也在被修改，遍历的速度跟不上修改的速度。 这样可能导致遍历完了，某个配置文件才更新完。那么此时，你读取的一部分文件数据并不是和当前目录下文件数据完全一致，本次会重启 dnsmasq。进而，下次检测，还认为有文件变化，到时候，又重启一次 dnsmasq。
• 文件的检测，直接使用 ioutil.ReadFile 读取文件内容，也存在问题。如果文件变化，和文件读取同时发生，很可能你读取完，文件的更新都没完成，那么你读取的并非一个完整的文件，而是坏的文件，这种文件，dnsmasq-nanny 无法做解析，不过官方代码中有数据校验，解析失败也问题不大，大不了下个周期的时候，再取到完整数据，再解析一次。

CoreDNS 使用Caddy作为底层的 Web Server，它是一个轻量易用的Web服务器，支持 HTTP、HTTPS、HTTP/2、GRPC 等多种连接方式

与 KubeDNS 相比，CoreDNS 的效率更高，资源占用更小

• Service

• A record：

• 普通 Service 解析为 Cluster IP
• Headless Service 解析为指定的 Pod IP 列表

• SRV record:

• Pod

• A record:
• 指定 hostname 和 subdomain:

• hostname: pod-name
• subdomain: same as service.name

示例：

验证：

CoreDNS 插件：

• errors：错误记录输出到标准输出
• health：健康报告 http://localhost:8080/health
• ready：就绪检测，HTTP访问端口 :8181，返回 200 代表OK
• kubernetes：将基于 Kubernetes 的服务和 Pod 的 IP 答复 DNS 查询

• ：兼容kube-dns，该选项仅当在相同的命名空间中存在与IP匹配的pod时才返回A记录。如果不使用pod记录，可以使用选项。
• ttl：响应的TTL时间，默认5s，范围 0~3600

• prometheus：度量指标值以 Prometheus 格式在 http://localhost:9153/metrics 上提供
• forward: 不在 Kubernetes 集群域内的任何查询都将转发到 预定义的解析器 (/etc/resolv.conf)
• cache：启用前端缓存
• loop：检测到简单的转发环，如果发现死循环，则中止 CoreDNS 进程
• reload：允许自动重新加载已更改的 Corefile。 编辑 ConfigMap 配置后，请等待两分钟，以使更改生效。
• loadbalance：这是一个轮转式 DNS 负载均衡器， 它在应答中随机分配 A、AAAA 和 MX 记录的顺序。

2.5.1 配置存根域

如果集群操作员在 10.150.0.1 处运行了 Consul 域服务器， 且所有 Consul 名称都带有后缀

2.5.2 Hosts，自定义域名

修改配置文件，将自定义域名添加到hosts中，可以添加任意解析记录，类似在本地/etc/hosts中添加解析记录。

2.5.3 Rewrite，服务别名

将指定域名解析到某个 Service 的域名，即给Service取了个别名，指向域名到集群内服务

2.5.4 Forward，级联DNS

修改配置文件，将forward后面的/etc/resolv.conf，改成外部DNS的地址，将自建 DNS 设为上游 DNS

• CoreDNS 每个实例只有一个容器，而 Kube-DNS 有三个
• Kube-DNS 使用 dnsmasq 进行缓存，它是一个 C 线程。Core-DNS 使用 Go 开发，
• CoreDNS 默认使用 negative caching，它的缓存的效率不如 dnsmasq，对集群内部域名解析的速度不如 kube-dns

DNS 解析会依赖 、 和 这个三个文件

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/hd-yjs/62113.html