K8S中设置特定域名的静态解析的几种方法

2025-04-10 18:01:00
丁国栋
原创 78
摘要:本文介绍在Kubernetes集群内手动设置DNS静态解析的几种方法。

背景:客户离线环境部署了k8s集群,由于是专用内网所以网络上有一些特殊设置。用户客户端和业务Pod使用了两套不同的DNS,所以集群内和集群外访问同一个域名会解析到不同的IP地址。

集群外解析的是弹性IP或者外部负载均衡器IP,集群内的节点使用的DNS解析的是内部负载均衡器的外部IP,而业务Pod无法访问内部负载均衡的外部IP只能访问内部IP。

为了实现业务Pod能访问同一个集群的其他业务Pod我们需要让业务Pod解析到集群内的Ingress 的 ClusterIP,这样业务Pod既能访问其他业务Pod而且也能简化域名配置。

之所以不使用svc域名是因为业务Pod还要对用户客户端展示域名,用svc域名显然是不方便的。


在开始之前我们需要弄清楚几个事实:

  1. 网络拓扑是怎样的?拓扑图对于理解、定位问题和方案决策都非常重要,是最核心的参考依据。
  2. 目前的问题卡在那里?多问几个为什么找到问题的根本原因和最佳解决方案。

基本拓扑:

内网用户浏览器  -- 内网网关 -- 负载均衡器 -- K8S节点 -- Nginx Ingress -- 业务Pod A 、B 

注:用户客户端使用的DNS服务器和K8S节点使用的DNS服务器并不相同,因此两个DNS服务器对业务A和业务B都有不同的解析。


核心问题:

PodA无法访问PodB的业务域名。


解决方案:

为PodA和PodB设置静态域名解析,这个解析只在集群内有效。


为了添加这样的域名解析我们可以借助kubernetes实现。

方法1:在CoreDNS ConfigMap里添加NodeHosts配置

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        hosts /etc/coredns/NodeHosts {
          ttl 60
          reload 15s
          fallthrough
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
        import /etc/coredns/custom/*.override
    }
    import /etc/coredns/custom/*.server
  NodeHosts: |
    10.0.2.200 mynode
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system

方法2:使用Deployment的hostAliases配置

apiVersion: v1
kind: Pod
metadata:
  name: hostaliases-pod
spec:
  restartPolicy: Never
  hostAliases:
  - ip: "127.0.0.1"
    hostnames:
    - "foo.local"
    - "bar.local"
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
  containers:
  - name: cat-hosts
    image: busybox:1.28
    command:
    - cat
    args:
    - "/etc/hosts"

参考:

  1. https://coredns.io/plugins/hosts/
  2. https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/

后话:很多人觉得kubernetes复杂,诚然我也必须承认它确实复杂,但并没有那么可怕,因为它的能力也在不断迭代中增强。只要我们对传统的应用部署和管理方式和网络原理搞清楚就无需担心在kubernetes中如何实现,我们须知万变不离其宗,传统方式里的一些解决办法在kubernetes中一定有平替的解决办法。我们的经验和知识依然适用,只是我们有时需要将其转化,找到最佳的解决方案。


发表评论
博客分类