全部文档
当前文档
最近更新时间：2024-05-23 14:41:30
KCE集群中默认部署了CoreDNS，以 coredns 服务名暴露。集群会根据Pod内的配置，将域名请求转发至集群的DNS服务器获取结果。Pod内的DNS域名解析配置文件为/etc/resolv.conf。
容器集群支持 dnsPolicy 字段为每个 Pod 配置不同的 DNS 策略。目前容器集群支持四种策略：
ClusterFirst：通过 CoreDNS 来做域名解析，Pod 内/etc/resolv.conf配置的 DNS 服务地址是集群 DNS 服务的 KubeDNS 地址。该策略是集群工作负载的默认策略。
None：忽略集群 DNS 策略，需要您提供 dnsConfig 字段来指定 DNS 配置信息。
Default：Pod 直接继承集群节点的域名解析配置。即在容器集群直接使用云服务的/etc/resolv.conf文件（文件内配置的是金山云DNS服务）。
ClusterFirstWithHostNet：强制在 hostNetWork 网络模式下使用 ClusterFirst 策略（默认使用 Default 策略）。
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
# hosts can add hosts's item into dns, see https://coredns.io/plugins/hosts/
hosts {
198.18.96.191 hub.kce.ksyun.com
fallthrough
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}配置说明：
使用了 CoreDNS 的 Kubernetes 插件，以 *.cluster.local 结尾的域名（集群内部 service 域名）将直接走 Kubernetes 插件。
还使用了 hosts 插件，将金山云镜像仓库域名直接解析到198.18.96.191。
其他域名（金山云内部域名以及其他各种域名），将转发到 CoreDNS Pod 的/etc/resolv.conf上去。
由于KCE默认的 CoreDNS Deployment 中，将 CoreDNS 的 Pod 中的 dnsPolicy 设置成了 default，Pod 直接继承集群节点的域名解析配置。即在容器集群直接使用云服务的
/etc/resolv.conf文件（文件内配置的是金山云DNS服务）。
如果业务 Pod 采用的 dnsPolicy 为 ClusterFirst 。那么按照这个默认配置情况下，业务 Pod 访问 dns 的请求流程如下：
client pod 根据/etc/resolv.conf中的配置，将 dns 请求转发到 coreDNS clusterIP 上去。
请求到达 coreDNS Pod 后，根据 dns 配置进行域名的分发：
cluster.local 类型后缀的域名直接经过 coreDNS kubernetes 插件处理。
hub.kce.ksyun.com 域名直接经过 coreDNS hosts 插件处理。
其余的域名直接发送给 coreDNS Pod 中的/etc/resolv.conf继续处理，文件内默认配置的是金山云DNS服务（无法解析业务方内部域名以及其他友商的内部域名）。
返回域名正确的 IP 地址。
基于上述原理，此处列举一种场景介绍如何进行相关配置。
在使用KCE时，可能会出现有解析自定义内部域名的需求，例如：
在集群外自建了集中存储服务，需要将集群中的监控或日志数据通过固定域名发送到存储服务。
传统业务在进行容器化改造过程中，部分服务的代码配置了固定域名调用内部其他服务，且无法修改配置，即无法使用 Kubernetes 的 service 名称进行调用。
1.执行以下命令，修改 CoreDNS 的 configmap。
$ kubectl edit configmap coredns -n kube-system2.修改 hosts 配置，将域名加入到 hosts，示例如下：
hosts {
198.18.96.191 hub.kce.ksyun.com
# 新增 hosts 域名
172.2.1.33 nfs-prod.example.com
172.2.2.133 oa-prod.example.com
fallthrough
} 3.完整配置如下
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
# hosts can add hosts's item into dns, see https://coredns.io/plugins/hosts/
hosts {
198.18.96.191 hub.kce.ksyun.com
# 新增 hosts 域名
172.2.1.33 nfs-prod.example.com
172.2.2.133 oa-prod.example.com
fallthrough
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}修改完成后，等待 coreDNS pod 自动加载配置即可。
可以在 coreDNS 中单独配置一个服务块，示例完整配置如下：
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
# hosts can add hosts's item into dns, see https://coredns.io/plugins/hosts/
hosts {
198.18.96.191 hub.kce.ksyun.com
fallthrough
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
# 新增服务块
example.com:53 {
errors
cache 30
forward . 10.10.0.10
}修改完成后，等待 coreDNS pod 自动加载配置即可。
上述两个解决办法的好处：
只需修改 coreDNS 的配置，如果有多种特定域名使用自定义域名服务器的话，添加多个服务块即可。
coreDNS 支持配置的热加载，无需重启 coreDNS Pod。
也有潜在问题：
节点上无法访问特定域名，因为云服务的/etc/resolv.conf文件（文件内配置的是金山云DNS服务）未同步修改。
直接修改集群所有节点的/etc/resolv.conf，将其 nameserver 改成一个分发域名的 DNS 服务，具体分发策略如下：
业务方内部特定域名转发给业务方自己的 DNS 服务器。
其他域名（包括金山云内部域名以及其他）转发给金山云 DNS 服务。
其他域名分发策略。
修改完节点上的/etc/resolv.conf配置后，需要重启一下 coreDNS Pod才能生效。
这种方法的好处：
节点上也可以正常解析业务方内部域名或者友商的内部域名。
相应问题：
需要改所有节点的/etc/resolv.conf配置，新增节点时，也需要有这个操作。
新增一个专门分发域名的 DNS 服务。
纯净模式