k8s集群中service的域名解析、pod的域名解析

这篇具有很好参考价值的文章主要介绍了k8s集群中service的域名解析、pod的域名解析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

在k8s集群中,service和pod都可以通过域名的形式进行相互通信,换句话说,在k8s集群内,通过service和pod的域名,可以直接访问内部应用,不必在通过service ip地址进行通信,一般的,我们创建service的时候不建议指定service的clusterIP,而是让k8s自动为service分配一个clusterIP,这样,service的IP是自动分配,但是service名字总是固定的吧,这样在集群内部就可以直接通过service的域名来连接即可,如前端pod应用直接通过service域名来连接后端pod。

service的域名

完整的service域名解析是:<servicename>.<namespace>.svc.<clusterdomain> 其中,servicename为service名称,namespace为service所处的命名空间,clusterdomain是k8s集群设计的域名后缀,默认为cluster.local。
一般的,在生产环境中,我们可以直接简写为<servicename>.<namespace>即可,后面的部分保持默认即可。如果pod与svc是在同一个命名空间,那么直接写svc即可,如 <servicename>

#查看k8s集群设置的域名后缀
cat /opt/kubernetes/config/kubelet-config.yml  | grep -i clusterDomain			#二进制安装的k8s集群,可以这样查看
cat  /etc/kubernetes/kubelet.conf 					#kubeadm安装的k8s集群,各个节点的kubelet.conf文件中的字段clusterDomain
kubectl  -n kube-system get cm coredns -oyaml		#coredns cm里面也可以看到
kubectl  exec -it deployment-busybox-567674bd67-lmrgw --  cat /etc/resolv.conf	#直接看pod里面的resolv.conf文件亦可

演示示例:
下面,我们通过创建一个deployment和service,然后创建一个测试pod,在测试pod中通过访问service域名的形式访问应用,验证service域名是否正常。如下所示:

# 创建一个deployment,有3个副本
[root@master service]# vim deployment-nginx.yaml         
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    env: dev
    tiar: front
  name: deployment-nginx
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        name: nginx-container
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
      restartPolicy: Always
#创建一个service,用于反向代理上面创建的deployment的pod
[root@master service]# vim svc-deployment-nginx.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: svc-deployment-nginx
  namespace: default
spec:
  ports:
  - name: nginx-port
    nodePort: 30080
    port: 80
    protocol: TCP
    targetPort: http
  selector:
    app: nginx
  type: NodePort
#创建一个pod用于测试
[root@master service]# cat ../pod/pod-busybox.yaml 
apiVersion: v1
kind: Pod
metadata: 
  name: pod-command
  labels: 
    env: dev
  namespace: default
spec:
  nodeName: node2
  containers:
  - image: busybox
    name: busybox-container
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt;sleep 3;done;"]
    resources:
      limits:
        cpu: 2
        memory: 2G
      requests:
        cpu: 1
        memory: 500M
[root@master service]# 
# 在测试pod中直接访问service的域名
[root@master service]# kubectl exec -it pod-command -- /bin/sh			#进入到测试pod中
/ # wget http://svc-deployment-nginx.default.svc.cluster.local:80		#这个pod没有curl命令,所以通过wget命令下载
Connecting to svc-deployment-nginx.default.svc.cluster.local:80 (10.111.193.190:80)		#下载成功
saving to 'index.html'
index.html           100% |*******************************************************************************************************************************************************************************************|   612  0:00:00 ETA
'index.html' saved
/ # cat index.html 														#下载成功,这是nginx的index文件,说明通过service域名访问是正常的
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
/ # 


wget http://svc-deployment-nginx.default.svc.cluster.local:80		#完整的写法
wget http://svc-deployment-nginx.default:80							#带命名空间写法
wget http://svc-deployment-nginx:80									#如果pod与svc在同一个命名空间,可以将命名空间省略不写

以上,说明,在pod内部通过访问service域名的形式访问其他服务,service的域名解析是正常的。

注意:不要在宿主机上curl service的域名,这样是访问不通的,因为service的域名是由k8s集群dns 这个pod解析的,不是外部宿主机的dns服务器解析的。所以,你直接在宿主机命令行curl service域名,肯定是行不通的。service的域名解析是供k8s集群内部pod应用之间进行访问的。换句话说,service域名仅供pod内使用。

pod的域名解析

pod的DNS域名格式为:<pod-ip>.<namespace>.pod.<clusterdomain> ,其中,pod-ip需要使用-将ip直接的点替换掉,namespace为pod所在的命名空间,clusterdomain是k8s集群设置的域名后缀,一般默认为 cluster.local ,如果没有改变k8s集群默认的域名后缀,则可以省略该后缀不写。除此之外,其他的均不可省略,这一点与svc域名有所不同。
演示如下:

#进入default命名空间的busybox pod里面,测试下载文件
kubectl -n default exec -it deployment-busybox-567674bd67-lmrgw -- sh
wget 10-244-166-167.helm.pod.cluster.local:80		#可以正常下载,这里下载的是helm命名空间里的IP为10.244.166.167的pod
wget 10-244-166-167.helm.pod:80						#可以正常下载,这里把k8s集群设置的域名后缀默认省略了					
wget 10-244-166-143.default.pod:80					#可以正常下载,这里下载的是default命名空间里的IP为10.244.166.143的pod
wget 10-244-166-143.default:80						#报错了,错误写法,说明不能省略pod关键字
wget 10-244-166-143:80								#报错了,错误写法,说明不能省略命名空间和pod关键字

对应deployment、deamonset等创建的pod,还可以<pod-ip>.<deployment-name>.<namespace>.svc.<clusterdomain> 访问。(这个一直测试失败,不指定是不是书中写错了,所以这点存疑)

对于StatefulSet创建的pod,statefulset.spec.serviceName字段解释如下:

[root@matser ~]# kubectl explain  statefulset.spec.serviceName
KIND:     StatefulSet
VERSION:  apps/v1
FIELD:    serviceName <string>
DESCRIPTION:
     serviceName is the name of the service that governs this StatefulSet. This
     service must exist before the StatefulSet, and is responsible for the
     network identity of the set. Pods get DNS/hostnames that follow the
     pattern: pod-specific-string.serviceName.default.svc.cluster.local where
     "pod-specific-string" is managed by the StatefulSet controller.
[root@matser ~]#

也就是说sts创建的pod,其pod的域名为:pod-specific-string.serviceName.default.svc.cluster.local,而pod-specific-string就是pod的名称。
例如:redis-sts-0.redis-svc.default.svc.cluster.local:6379,redis-sts-1.redis-svc.default.svc.cluster.local:6379,redis-sts-2.redis-svc.default.svc.cluster.local:6379,redis-sts-3.redis-svc.default.svc.cluster.local:6379,redis-sts-4.redis-svc.default.svc.cluster.local:6379,redis-sts-5.redis-svc.default.svc.cluster.local:6379,pod里面的应用程序就可以拿这串字符串去连接Redis集群了。

总结

以上,service的域名解析很重要,我们只需要在k8s集群内部的pod里面连接访问service的域名即可,因为service的名称总是固定的,既然是固定的,那么可以直接通过访问service的域名方式来访问对应的service即可。
至于普通pod的域名解析,可以不用太过在乎,了解即可,因为pod的生命周期是不固定的,随时都可能消亡,也就是说pod IP随时可能变化,所以根本不会使用pod域名访问pod应用。
对应StatefulSet 创建的有状态的pod,其pod域名解析是固定格式的,这个要记着,pod-specific-string.serviceName.default.svc.cluster.local,pod-specific-string就是pod的名称。文章来源地址https://www.toymoban.com/news/detail-790600.html

到了这里,关于k8s集群中service的域名解析、pod的域名解析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

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

    没有使用systemd-resolved的linux主机上访问外部域名一般是按照以下步骤来的: 从dns缓存里查找域名与ip的映射关系 从/etc/hosts里查找域名与ip的映射关系 从/etc/resolv.conf里查找dns server,并发起解析请求 /etc/resolv.conf的内容一般如下: nameserver 8.8.8.8 使用systemd-resolved的linux主机上访

    2024年02月04日
    浏览(35)
  • k8s1.20集群域名与集群ip解析详解及使用案例

    目录 一.k8s中的域名解析浅析 1.单机 2.k8s的容器中 二.k8s不同版本对应的dns域名服务组件

    2024年02月09日
    浏览(38)
  • 【Java】基于fabric8io库操作k8s集群实战(pod、deployment、service、volume)

    一开始了解到Java Api库操作k8s集群,有两个,分别为: kubernetes-client/java fabric8io/kubernetes-client 但个人对比使用了两个发现,还是 fabric8io更易用 ,用的人多是有道理的, fabric8io和yaml文件十分贴切 ,所以 通俗易懂 。本文前提是已配置好集群,已经熟悉了kubectl工具常用命令。

    2024年02月02日
    浏览(47)
  • 云原生 黑马Kubernetes教程(K8S教程)笔记——第一章 kubernetes介绍——Master集群控制节点、Node工作负载节点、Pod控制单元

    参考文章:kubernetes介绍 本章节主要介绍应用程序在服务器上部署方式演变以及kubernetes的概念、组件和工作原理。 在部署应用程序的方式上,主要经历了三个时代: 传统部署:互联网早期,会直接将应用程序部署在物理机上 优点:简单,不需要其它技术的参与 缺点:不能为

    2024年02月04日
    浏览(53)
  • 基于Docker的K8s(Kubernetes)集群部署

    开始搭建k8s集群 三台服务器修改主机名称 关闭对话窗口,重新连接 三台主机名称呢就修改成功了。 接下来修改每台节点的 hosts 文件 所有节点关闭 setLinux 查看是否关闭成功 为每个节点添加 k8s 数据源 如果安装docker数据源找不到yum-config 所有节点安装kubelet kubelet安装中… k

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

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

    2024年02月05日
    浏览(39)
  • 在线搭建K8S,kubernetes集群v1.23.9,docker支持的最后一个版本

    执行后的结果如下: 到这里一个K8S集群就完整的部署好了,如果有其他的node节点操作方法是一样的,如果是高可用的,多个master可以给我留言,告诉你怎么操作。

    2024年02月14日
    浏览(42)
  • 在学习k8s时候,pod services 和deployment

    在学习 Kubernetes(K8s)时,Pod、Service 和 Deployment 是三个非常重要的概念。它们是 Kubernetes 中用于管理容器化应用程序的核心组件。 Pod(Pods): Pod 是 Kubernetes 最基本的调度和管理单位,它是一个或多个紧密关联的容器的组合。Pod 提供了一个独立的运行环境,包含应用程序所

    2024年02月11日
    浏览(47)
  • k8s~ingress_service_endpoint_pod四壮士

    在Kubernetes中,Service和Endpoints是两个重要的概念,它们之间存在着密切的关系。 Ingress :Ingress是一个k8s环境的网关,正常情况下,你外部的流量应该先指向ingress所有节点的IP,ingress的端口默认是80(http)和443(https),然后再由ingress进行域名传发到具体的service或者deployment上面。在

    2024年02月04日
    浏览(64)
  • 【Kubernetes】K8s 查看 Pod 的状态

    NAME :Pod 的名称。 READY :代表 Pod 里面有几个容器,前面是启动的,后面是总数, 1 / 1 1/1 1/1 。 STATUS :就是当前 Pod 状态,最常见的就是 Running 正在运行,最期望的状态,只要不是 Running 的就说明有问题,就算是 Running 的就不一定没有问题。 状态 说明 Pending 挂起 在执行创建

    2024年01月15日
    浏览(92)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包