【博客628】k8s pod访问集群外域名原理以及主机开启了systemd-resolved的不同情况

这篇具有很好参考价值的文章主要介绍了【博客628】k8s pod访问集群外域名原理以及主机开启了systemd-resolved的不同情况。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

k8s pod访问集群外域名原理以及使用了systemd-resolved的不同情况

1、不同情况下的linux主机访问外部域名原理

没有使用systemd-resolved的linux主机上访问外部域名一般是按照以下步骤来的:

  • 从dns缓存里查找域名与ip的映射关系

  • 从/etc/hosts里查找域名与ip的映射关系

  • 从/etc/resolv.conf里查找dns server,并发起解析请求

    /etc/resolv.conf的内容一般如下:
    nameserver 8.8.8.8

使用systemd-resolved的linux主机上访问外部域名一般是按照以下步骤来的:

  • 从dns缓存里查找域名与ip的映射关系

  • 从/etc/hosts里查找域名与ip的映射关系

  • 将dns解析请求发给本地systemd-resolved,由其去代理处理,因为systemd-resolved修改了 /etc/resolv.conf,使得本地解析请求全部发到127.0.0.1:53

    此时/etc/resolv.conf的内容一般如下:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
  • 然后systemd-resolved再根据/run/systemd/resolve/resolv.conf里面的dns server去发起请求

    /run/systemd/resolve/resolv.conf记录的就是真正的后端dns server

cat /run/systemd/resolve/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 8.8.8.8
nameserver 4.4.4.4

2、pod内访问集群内service域名

当pod启动的时候,一般用的是dnsPolicy: ClusterFirst,此时就会将pod的/etc/resolv.conf改为集群内coredns的地址,此时将解析请求发给coredns,由其代理处理:

集群内coredns的service ip:

kubectl get svc -n kube-system

NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   14d

pod内的/etc/resolv.conf在启动的时候被指定dns server为coredns service ip:

# cat /etc/resolv.conf in pod
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

3、pod内访问集群外service域名

  • 使用dnsPolicy: ClusterFirst时:

    pod内的/etc/resolv.conf在启动的时候被指定dns server为coredns service ip。
    coredns的默认配置如下,此时如果用在集群内找不到这个service域名,就会用forward去转发请求,此时默认配置的是使用coredns内的 /etc/resolv.conf文件里的dns server

coredns default config:

    .:53 {
        log
        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 {
           max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
    }
  • 使用dnsPolicy: Default时:

    这种方式其实是让 kubelet 来决定使用何种 DNS 策略。而 kubelet 默认的方式,就是使用宿主机的 /etc/resolv.conf

    简述: pod将dns代理到coredns,coredns使用kubelet的resolv指定的conf里面的内容来解析集群外的ip

4、coredns pod内的/etc/resolv.conf为什么有时跟主机/etc/resolv.conf不一致

场景:

当主机使用systemd-resolved来代理dns解析请求的时候,此时coredns pod内的/etc/resolv.conf跟主机/etc/resolv.conf不一致。

coredns pod内的/etc/resolv.conf:

cat /run/systemd/resolve/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 8.8.8.8
nameserver 4.4.4.4

主机/etc/resolv.conf:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad

coredns pod内的/etc/resolv.conf为什么有时跟主机/etc/resolv.conf不一致的原因:

coredns的pod使用的是dnsPolicy: Default,此时就会使用kubelet指定的resolvConf的地址,默认是/etc/resolv.conf,但是当主机使用了systemd-resolved,则kubelet的的resolvConf变成了:resolvConf: /run/systemd/resolve/resolv.conf,也就是systemd-resolved存放真实后端dns server的文件路径,所以其实coredns的pod使用的是/run/systemd/resolve/resolv.conf里的真实后端dns server

使用了systemd-resolved的主机,kubelet使用/run/systemd/resolve/resolv.conf,而不用/etc/resolv.conf的原因:

  • 如果coredns也是用/etc/resolv.conf,则集群里的dns解析请求都要代理到systemd-resolved,如果systemd-resolved挂了或者更新,那上层k8s集群里的dns解析也全部受到影响

  • 这里面会有循环依赖的问题,参考coredns的官方文档解析:

    Troubleshooting Loops In Kubernetes Clusters

    A common cause of forwarding loops in Kubernetes clusters is an interaction with a local DNS cache on the host node (e.g. systemd-resolved). For example, in certain configurations systemd-resolved will put the loopback address 127.0.0.53 as a nameserver into /etc/resolv.conf. Kubernetes (via kubelet) by default will pass this /etc/resolv.conf file to all Pods using the default dnsPolicy rendering them unable to make DNS lookups (this includes CoreDNS Pods). CoreDNS uses this /etc/resolv.conf as a list of upstreams to forward requests to. Since it contains a loopback address, CoreDNS ends up forwarding requests to itself.

    简述: coredns转到127.0.0.53,此时源目ip都是自己,自己在给自己转,就会有循环问题

5、在node上如何访问集群内的service域名

  • 通用方法:直接修改网卡interface的配置文件,在里面配上DNS的解析server

  • 不通用方法:linux没有使用systemd-resolved时:

    在/etc/resolv.conf里加入coredns的service ip

  • 不通用方法:linux使用systemd-resolved时:

    • 在/etc/systemd/resolved.conf里加入coredns的service ip
      [Resolve]
      DNS=10.96.0.10
      #FallbackDNS=
      #Domains=
      #LLMNR=no
      #MulticastDNS=no
      #DNSSEC=no
      #DNSOverTLS=no
      #Cache=no-negative
      #DNSStubListener=yes
      #ReadEtcHosts=yes
    • systemctl restart systemd-resolved.service
    • systemd-resolve --status查看结果
      Global
      LLMNR setting: no
      MulticastDNS setting: no
      DNSOverTLS setting: no
      DNSSEC setting: no
      DNSSEC supported: no
      DNS Servers: 10.96.0.10
      DNSSEC NTA: 10.in-addr.arpa
      16.172.in-addr.arpa
      168.192.in-addr.arpa
      17.172.in-addr.arpa
      18.172.in-addr.arpa
      19.172.in-addr.arpa
      20.172.in-addr.arpa
      21.172.in-addr.arpa

  • 注意:不可以直接改/etc/resolv.conf,否则重启后丢失配置,因为此时/etc/resolv.conf被systemd-resolved接管,每次重启由其来生成其中的内容

example:

# 指定使用coredns来解析集群内service:
root@:/home/ubuntu# nslookup vmselect-example-vmcluster-persistent.default.svc.cluster.local 10.96.0.10
Server:        10.96.0.10
Address:    10.96.0.10#53

Name:    vmselect-example-vmcluster-persistent.default.svc.cluster.local
Address: 10.244.0.5
Name:    vmselect-example-vmcluster-persistent.default.svc.cluster.local
Address: 10.244.1.3
Name:    vmselect-example-vmcluster-persistent.default.svc.cluster.local
Address: 10.244.1.4

# /etc/resolv.conf加入:
nameserver 10.96.0.10

# node上直接访问集群内service域名,此时会转到coredns去解析
root@:/home/ubuntu# curl vmselect-example-vmcluster-persistent.default.svc.cluster.local:8481/metrics
...
flag{name="promscrape.suppressScrapeErrors", value="false", is_set="false"} 1
flag{name="promscrape.suppressScrapeErrorsDelay", value="0s", is_set="false"} 1
flag{name="promscrape.yandexcloudSDCheckInterval", value="30s", is_set="false"} 1
flag{name="pushmetrics.extraLabel", value="", is_set="false"} 1
flag{name="pushmetrics.interval", value="10s", is_set="false"} 1
flag{name="pushmetrics.url", value="secret", is_set="false"} 1
flag{name="replicationFactor", value="1", is_set="false"} 1
flag{name="search.cacheTimestampOffset", value="5m0s", is_set="false"} 1
flag{name="search.denyPartialResponse", value="false", is_set="false"} 1
...
...

6、使用了systemd-resolved的主机,如果关闭systemd-resolved则机器的dns解析都会不同,即使主机能通后端dns server

ubuntu@:~$ sudo systemctl stop systemd-resolved.service
ubuntu@:~$ nslookup www.baidu.com
^C
ubuntu@:~$ dig www.baidu.com
^C
ubuntu@:~$ host www.baidu.com
^C

7、主机如何修改dns server

  • 没有systemd-resolved,直接修改/etc/resolv.conf
  • 如果机器装了systemd-resolved,那么就不可以直接改/etc/resolv.conf,则改法如下:

以加上8.8.8.8为例文章来源地址https://www.toymoban.com/news/detail-767544.html

root@:/home/ubuntu# cat /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
DNS=8.8.8.8
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=no-negative
#DNSStubListener=yes
#ReadEtcHosts=yes

systemctl restart systemd-resolved.service

root@:/home/ubuntu# systemd-resolve --status
Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 8.8.8.8
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      ...
                      ...

到了这里,关于【博客628】k8s pod访问集群外域名原理以及主机开启了systemd-resolved的不同情况的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • k8s如何访问 pod 元数据

    **我们在 pod 中运行容器的时候,是否也会有想要获取当前 pod 的环境信息呢?**咱们写的 yaml 清单写的很简单,实际上部署之后, k8s 会给我们补充在 yaml 清单中没有写的字段,那么我们的 pod 环境信息和容器的元数据如何传递到容器中呢?是不是也是通过获取这些 k8s 默认给

    2024年02月16日
    浏览(44)
  • K8S集群中Pod与Pod之间网络故障排查思路

    在K8S集群中,可能会出现Pod与Pod之间无法通信的现象,也就是说Pod无法跨Node主机进行通信,Pod与Pod之间网络不通讯会导致无法请求Pod中的服务,Apiserver也可能会无法获取Pod的运行状态,产生一系列问题。 Pod与Pod之间网络不通讯,很有可能是网络组件产生了异常导致的。 排查

    2024年01月16日
    浏览(36)
  • k8s集群pod和node状态监控

    curl -L -O https://raw.githubusercontent.com/gjeanmart/kauri-content/master/spring-boot-simple/k8s/kube-state-metrics.yml 修改namespace为dev(default也行,但是后面的metricbeat安装也需要修改namespace为default)。 kubectl create -f kube-state-metrics.yml curl -L -O https://raw.githubusercontent.com/elastic/beats/7.6/deploy/kubernetes/metr

    2024年04月09日
    浏览(40)
  • k8s集群pod中文件导出到本地

    首先在k8s集群中先找到pod主机;  确定pod容器主机ip为192.168.1.113;等到113主机查看docker ps;发现113上没有docker命令; rpm -qa |grep contain; top; ps  aux |grep docker ; 查询主机上实现docker的方式;    crictl ps;查询pod容器;  容器中没有tar命令的话可以尝试:在主机上 crictl  cp  容器

    2024年02月11日
    浏览(28)
  • 清理k8s集群Evicted,Failed的Pod!

    简介:不知知道各位是如何清理的,我尝试过用阿里的任何一个面板清理,但是还要换页就很烦,所以自己就写了一个小脚本,更GOOD!的是你还可以把他放到你的定时任务里面去,为啥要这么做,不得不说,咱的集群有点小垃圾,不过那也没办法,集群也不敢动,谁知道啥时

    2024年02月20日
    浏览(34)
  • k8s(Kubernetes)设置 pod,Deployment 域名自定义映射ip,hosts 解析 HostAliases

    直接 编辑修改 Deployment 最后内容如下,如需保存 按 esc 键,最后输入 :wq 保存退出,容器会自动重新生成新的

    2024年02月12日
    浏览(43)
  • 玩转k8s(四)—— 通过Service访问Pod

            我们不应该期望k8s Pod是健壮的,而是要假设Pod中的容器很可能因为各种原因发生故障而死掉。Deployment等Controller会通过动态的创建和销毁Pod来保证应用整体的健壮性。换句话说, Pod是脆弱的,但应用是健壮的 。         每个Pod都有自己的IP地址,当Controller用新的

    2024年02月05日
    浏览(35)
  • K8S集群中Pod资源处于CrashLoopBackOff状态排查思路

    CrashLoopBackOff状态一般都是Pod资源中的容器出现了问题,可以有以下几点原因: 容器中部署的程序存在Bug,无法正常启动,就会出现此状态,可以查询容器的启动日志,从日志中获取重要线索,逐个进行排查。 定义Pod资源时,对于Pod中的容器进行了资源限额,可能限额的资源

    2024年01月21日
    浏览(40)
  • K8S集群中Pod资源处于ImagePullBackOff状态排查思路

    ImagePullBackOff状态表示容器的镜像拉取失败,可能存在以下几点原因: 拉取镜像时间较长导致超时,从而导致镜像拉取失败,部署完Docker后,一定要添加上阿里云的镜像加速器,否则拉取镜像是非常慢的,很容易就会导致镜像拉取失败。 镜像配置有误,指定的镜像在公有仓库

    2024年02月14日
    浏览(41)
  • k8s外部访问pod内部容器的端口-NodePort

    Kubernetes的Pod IP和Cluster IP都只能在集群内部访问,而我们通常需要从外部网络上访问集群中的某些服务,Kubernetes提供了下述几种方式来为集群提供外部流量入口。 有一pod,里面有rabbitmq服务,先想从外部通过ip:15672访问MQ的管理员界面查看队列消费情况。 方法1(pod会重启): 方法

    2023年04月23日
    浏览(27)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包