云服务器K8S集群CoreDNS配置修改实战

在云服务器部署的K8S集群中，CoreDNS是核心的域名解析组件，直接影响集群内服务的通信效率。合理调整其配置，能针对性解决自定义域名解析、跨集群通信等场景需求。本文将结合实战，详细拆解从查看配置到验证生效的完整流程。

CoreDNS：K8S集群的"网络导航员"

CoreDNS作为K8S默认DNS服务器，通过插件链机制实现灵活的解析功能。简单来说，它像一条流水线：收到解析请求后，依次经过缓存、日志、转发等插件处理，最终返回结果。修改其配置文件（通常存储在ConfigMap中），就能定制解析规则——比如指定特定域名走外部DNS，或添加私有域解析记录。

前置条件：确保环境就绪

动手修改前需确认两点：

• 已在云服务器上搭建可正常运行的K8S集群（1.18及以上版本推荐）


• 本地已安装kubectl工具，且通过kubeconfig文件完成集群连接（可通过"kubectl cluster-info"验证）

实战步骤：从查看配置到验证生效

Step1 查看当前配置

CoreDNS的核心配置存储在kube-system命名空间的coredns ConfigMap中。执行以下命令获取当前配置：

kubectl get configmap coredns -n kube-system -o yaml

输出结果中重点关注"data"字段下的Corefile内容，这是实际生效的解析规则。典型配置如：

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

Step2 编辑配置文件

使用kubectl edit直接修改ConfigMap：

kubectl edit configmap coredns -n kube-system

这会调用默认文本编辑器（如vim）打开配置。假设需要将"internal.example.com"域名的解析请求转发到公司私有DNS（10.0.0.10），可在Corefile中添加：

internal.example.com {
    forward . 10.0.0.10
    cache 60
}

注意保持原有插件链结构，新增的域名段需放在主配置块（.:53）之前或之后，避免语法错误。

Step3 应用并验证修改

保存退出编辑器后，kubectl会自动更新ConfigMap。由于CoreDNS使用热加载机制，通常1-2分钟内会应用新配置。

验证可分两步：
1. 检查CoreDNS Pod状态：

kubectl get pods -n kube-system -l k8s-app=kube-dns

确保Pod处于"Running"状态，无重启异常。

2. 测试解析效果：
创建测试Pod（基于busybox镜像）：

kubectl run dns-test --image=busybox:1.35 -- sleep 3600

进入Pod执行nslookup：

kubectl exec -it dns-test -- nslookup internal.example.com

若返回的服务器地址为10.0.0.10，且解析结果符合预期，说明配置生效。

避坑指南：这些细节要注意

- 配置语法：CoreDNS使用类C语言语法，括号需成对、缩进非必需但建议保持可读性。修改前可通过[CoreDNS官网文档](https://coredns.io)核对语法。
- 缓存影响：若测试时仍返回旧结果，可能是本地Pod的DNS缓存未失效。可尝试删除测试Pod重新创建，或在Corefile中调整"cache"插件的时间（如设置为0禁用缓存）。
- 备份原配置：修改前建议执行"kubectl get configmap coredns -n kube-system -o yaml > coredns-backup.yaml"备份，避免操作失误导致解析异常。

掌握这些步骤后，你可以根据业务需求灵活调整云服务器K8S集群的CoreDNS配置，无论是添加私有域解析、优化外部DNS转发，还是解决特定域名解析延迟问题，都能快速响应。