K8S Service 原理、图例——深度好文
一、理论介绍
1.1、3W 法则
1、是什么？
- Service 是一种为一组功能相同的 pod 提供单一不变的接入点的资源。当 Service 存在时，它的IP地址和端口不会改变。客户端通过IP地址和端口号与 Service 建立连接，这些连接会被路由到提供该 Service 的任意一个pod上。通过这种方式，客户端不需要知道每个单独的pod的地址，这样这些pod就可以在集群中随时被创建或移除。
2、为什么需要？
- Pod 的 IP 地址经常变化。
- Pod 的 IP 在集群外无法访问。
- Pod 实例之间的负载均衡。
3、局限性
- Service 是一种四层代理。
- 所谓四层，是针对 OSI 七层网络模型来说的。四层对应的是TCP/UDP协议，也就常说的IP+端口。
- 因此，所谓四层代理就是基于IP+端口的负载均衡；七层就是基于URL等应用层信息的负载均衡。
1.2、基础信息
kubectl explain svc
# svc 是 service 的缩写
- apiVersion：当前资源使用的 api 版本，与 VERSION 一致。
- kind：资源类型，跟 KIND 保持一致。
- metadata：元数据。定义资源名称、标签、注解等。
- spec：规范、规约。
- status：最近观察到的 Service 状态。由系统填充。只读。
1.3、ServiceSpec 规约
kubectl explain svc.spec| allocateLoadBalancerNodePorts | |
| clusterIP | |
| clusterIPs <[]string> | |
| externalIPs <[]string> | |
| externalName | |
| externalTrafficPolicy | |
| healthCheckNodePort | |
| internalTrafficPolicy | |
| ipFamilies <[]string> | |
| ipFamilyPolicy | |
| loadBalancerClass | |
| loadBalancerIP | |
| loadBalancerSourceRanges <[]string> | |
| ports <[]ServicePort> | 端口 |
| publishNotReadyAddresses | |
| selector | 标签选择器 |
| sessionAffinity | |
| sessionAffinityConfig | |
| trafficDistribution | |
| type | 类型 |
1.4、Service 类型
kubectl explain svc.spec.type
type 类型有四种：
- ClusterIP：虚拟集群IP。通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。默认类型。
- NodePort：节点端口。通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <节点 IP>:<节点端口>，你可以从集群的外部访问一个 NodePort 服务。
- ExternalName：外部命名空间。通过返回 CNAME 和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理。
- LoadBalancer：负载均衡。使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。Kubernetes 不直接提供负载均衡组件； 你必须提供一个，或者将你的 Kubernetes 集群与某个云平台集成。
其中 ClusterIP 为默认方式，只能集群内部访问。NodePort、LoadBalancer 则是向外暴露服务的同时将流量路由到 ClusterIP服务。ExternalName 则是CNAME方式进行服务映射。
1.5、Service 端口
kubectl explain svc.spec.ports| appProtocol | |
| name | |
| nodePort | service 在节点映射的端口。 type 类型是 NodePort 或 LoadBalancer 时才指定。 通常是系统分配，也可以自己指定，范围在 30000-32767。 |
| port | Service 将公开的端口。 |
| protocol | 协议。协议类型有 SCTP, TCP, UDP。默认 TCP。 |
| targetPort | pod 端口 |
二、镜像准备
2.1、镜像准备
docker pull mirrorgooglecontainers/serve_hostname:latest
docker pull kubedb/mysql-tools:8.0.14
docker pull curlimages/curl2.2、镜像导出
docker save -o serve_hostname.tar.gz mirrorgooglecontainers/serve_hostname:latest
docker save -o mysql-tools.tar.gz mysql-tools:8.0.14
docker save -o curl.tar.gz curlimages/curl2.3、镜像导入工作节点 containerd
# k8s31node1 执行
[root@k8s31node1 ~]# ctr -n=k8s.io images import serve_hostname.tar.gz
[root@k8s31node1 ~]# ctr -n=k8s.io images ls|grep serve_hostname
[root@k8s31node1 ~]# ctr -n=k8s.io images import mysql-tools.tar.gz
[root@k8s31node1 ~]# ctr -n=k8s.io images ls|grep mysql-tools
[root@k8s31node1 ~]# ctr -n=k8s.io images import curl.tar.gz
[root@k8s31node1 ~]# ctr -n=k8s.io images ls|grep curl
# k8s31node2 执行
[root@k8s31node2 ~]# ctr -n=k8s.io images import serve_hostname.tar.gz
[root@k8s31node2 ~]# ctr -n=k8s.io images ls|grep serve_hostname
[root@k8s31node2 ~]# ctr -n=k8s.io images import mysql-tools.tar.gz
[root@k8s31node2 ~]# ctr -n=k8s.io images ls|grep mysql-tools
[root@k8s31node2 ~]# ctr -n=k8s.io images import curl.tar.gz
[root@k8s31node2 ~]# ctr -n=k8s.io images ls|grep curl2.4、环境准备
假设有如下三个节点的 K8S 集群：
k8s31master 是控制节点
k8s31node1、k8s31node2 是工作节点
容器运行时是 containerd
三、实践
3.1、创建 ClusterIP 类型 Service
假设有这么一个部署：
apiVersion: apps/v1
kind: Deployment
metadata:
name: hostnames
spec:
selector:
matchLabels:
app: hostnames
replicas: 3
template:
metadata:
labels:
app: hostnames
spec:
containers:
- name: hostnames
image: mirrorgooglecontainers/serve_hostname
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9376
protocol: TCPmirrorgooglecontainers/serve_hostname 这个应用的作用，就是每次访问 9376 端口时，返回它自己的 hostname。
3.1.1、在不同的节点上访问 PodIP:port
返回了各个 pod 自己的 hostname。
可以看到，在集群内的不同节点上， Pod IP 都能访问。
3.1.2、在不同的容器内访问 PodIP:port
假设现在新起一个 pod:
apiVersion: v1
kind: Pod
metadata:
name: curl-tools
spec:
containers:
- name: curl-tools
image: curlimages/curl:latest
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "while true; do echo 'Hello from curl-tools'; sleep 30; done"]
- curlimages/curl 是一个 curl 调试工具。
- command：容器启动后执行的命令，这里使用一个无限循环，每隔 30 秒输出一次
Hello from curl-tools。- 像 Alpine 镜像，或者基于 Alpine 制作的工具镜像，容器内没有运行服务，需要启动后运行一个无限循环，防止容器被 K8S 杀掉。
进入容器访问 hostnames 服务：
kubectl exec -it curl-tools -- curl 10.244.165.57:9376
可以看到，在集群内的容器之间，Pod IP 都能访问。
3.1.3、在集群外访问 PodIP:port
我们再起一台虚拟机 docker1，IP 地址跟 K8S 集群在一个网段。
访问 hostnames 服务：
可以看到，即使 docker1 的 IP 地址跟 K8S 集群在一个网段，但 docker1 没有用类似 kubeadm join 加入过集群，Pod IP 是不能访问的。
3.1.4、误删一个 pod
kubectl delete pod hostnames-d9d7674f5-2djvf
可以看到，K8S 又帮我们重新拉起了一个新 pod：hostnames-d9d7674f5-n7mtn，以维持我们 Deployment 控制器希望的副本数 replicas: 3。但是这个新 pod 的 IP，跟原来旧 pod 的 IP 是不一样的。
倘若我们是调用这些 pod 服务的客户端，在 pod 扩缩容期间，维护这些 pod IP 的代价是非常大的。所以我们需要一个稳定的接入层，它的 IP 地址、端口不变，让它来代理后端的一组 pod，而我们程序只需要跟这个接入层打交道就可以。这个接入层，就是 Service。
3.1.5、新建一个 ClusterIP 类型 Service
apiVersion: v1
kind: Service
metadata:
name: hostnames-svc
spec:
type: ClusterIP
selector:
app: hostnames
ports:
- port: 80
protocol: TCP
targetPort: 9376
- spec.selector：Service 通过标签选择器来查找 app=hostnames 标签的 Pod。
- port: 80 表示该服务的可用端口。
- targetPort: 9376 表示服务将连接转发的 Pod 端口。
- port 跟 targetPort 配合起来表示 这个 Service 的 80 端口，代理的是 Pod 的 9376 端口。
- 查看 service
kubectl get svc
- 访问 service
连续三次不断地访问 Service 的 CLUSTER-IP 和 端口 80：
- 依次返回了三个 Pod 的 hostname。
- 请求 Service IP:port 跟直接访问 Pod IP:port 的结果一样，这说明 Service 可以把请求代理到它所关联的后端 Pod。
- 这也印证了 Service 提供的是 Round Robin (轮询) 方式的负载均衡。
- 查看 endpoints
K8S 创建 Service 的时候，如果 Service 带有 selector 选择器，则 K8S 会创建一个与 Service 同名的 Endpoints 对象。selector 选中的 Pod 的 IP 和 端口，都会记录在 Endpoints 中。当一个新的 Pod 被创建并且它的标签匹配了某个 Service 的选择器时，该 Pod 的 IP 和端口会被添加到对应的 Endpoints 对象中；同样地，当 Pod 被删除时，它也会从 Endpoints 中移除。Endpoints 通常由 Service 引用， 以定义可以将流量发送到哪些 Pod。
kubectl get ep hostnames-svc
# ep endpoints 缩写
kubectl get ep hostnames-svc -oyaml
需要注意的是，只有处于 Running 状态，且 readinessProbe 检查通过的 Pod，才会出现在 Service 的 Endpoints 列表里。并且，当某一个 Pod 出现问题时，Kubernetes 会自动把它从 Service 里摘除掉。
3.1.6、集群外访问 Service ClusterIP:port
在集群外的虚拟机 192.168.40.111 访问 10.103.168.44:80
可以看到，访问不到 Service。如果希望集群外的机器能访问，需要创建 NodePort 类型的 Service 或 LoadBalancer 类型的 Service。
3.1.7、通过 FQDN 访问服务
在 Kubernetes (K8S) 环境中，FQDN（Fully Qualified Domain Name，完全限定域名）是指集群内部服务的完整域名，它包含了服务名、命名空间以及可选的服务后缀，用于唯一标识集群中的一个服务。
当你在 Kubernetes 中创建一个服务时，Kubernetes 会为该服务分配一个 FQDN。这个 FQDN 的格式通常是：
..svc.cluster.local
- service-name 是你给服务起的名字。
- namespace 是服务所在的命名空间，默认是 default，除非你在创建服务时指定了不同的命名空间。
- svc 是固定的，代表这是一个服务。
- cluster.local 是集群的默认域，大多数情况下是这个值，但如果你的集群配置了不同的域名，则会有所不同。
例如，我们上面 hostnames-svc 服务，它的完整域名是：
hostnames-svc.default.svc.cluster.local我们在集群的其他 pod 中，就可以使用这个域名访问服务：
可以省略命名空间和 svc.cluster.local，因为已经帮我们解析了。
在节点上不能解析这个域名，Kubernetes 的 DNS 服务通常只服务于集群中的 Pod，而节点本身并不自动配置为使用它：
使用 FQDN 可以让 Kubernetes 集群中的其他服务通过 DNS 解析来找到并访问你的服务，而不需要知道服务的具体 IP 地址。这有助于实现服务发现和服务间的通信，并且提高了服务部署的灵活性和可移植性。在 Kubernetes 中，CoreDNS 通常被用来提供这种 DNS 服务发现的功能。
3.1.8、Service 原理
我们以 3.1.2 小节 curl-tools 容器（假设运行在 node2 上）访问 Service Cluster_IP : port 为例，来讲解 Service 的工作原理。
首先介绍一下几个组件：
- kube - proxy：是 Kubernetes 集群中每个节点上运行的一个组件。它负责在节点上维护网络规则，实现了 Service 的代理和负载均衡功能，确保客户端可以通过 Service 的 IP 和端口访问到对应的后端 Pod。kube-proxy 会监视 API Server 中 Service 和 Endpoints 对象的变化。当有新的 Service 或 Endpoints 对象创建、更新或删除时，kube-proxy 会收到通知，并相应地更新节点上的网络规则（iptables）。kube-proxy 有 iptables 模式跟 ipvs 模式。
- Service：是 Kubernetes 提供的一种抽象层，它定义了一组 Pod 的逻辑集合以及访问这些 Pod 的策略。Service 为 Pod 提供了一个稳定的 IP 地址（ClusterIP）和端口号，使得客户端可以通过这个稳定的地址来访问后端的 Pod，而不需要关心具体 Pod 的 IP 地址和生命周期。
- Endpoints：是 Kubernetes 中的一个资源对象，它记录了 Service 对应的所有后端 Pod 的 IP 地址和端口信息。每当 Pod 的数量或状态发生变化时，Endpoints 对象会自动更新。
curl-tools 容器内访问 Service IP : port 流程：
- node2 上的 kube-proxy 监视 API Server 中 Service 和 Endpoints 对象的变化，更新节点上的网络规则（iptables）。
- 客户端 curl-tools 请求 Service IP : port，请求包目的地 Destination 初始设置为服务的IP和端口(10.103.168.44:80)。发送到网络之前，node2 的内核会根据配置在该节点上的 iptables 规则处理数据包。内核会检查数据包是否匹配任何这些 iptables 规则。其中有个规则规定如果有任何数据包的目的地IP等于10.103.168.44、目的地端口等于80，那么数据包的目的地IP和端口应该被替换为随机选中的 hostnames pod的IP和端口。
- 本例中的数据包满足规则，故而它的IP:端口被改变了。假设 pod hostnames-d9d7674f5-tjwzp 被轮询算法随机选中了，所以数据包的目的地IP变更为 10.244.165.56，端口改为9376(Service中定义的目标端口)。就好像是客户端 curl-tools 直接发送数据包给 hostnames-d9d7674f5-tjwzp 而不是通过 Service。
3.1.9、iptables Or IPVS
kube-proxy 通过 iptables 处理 Service 的过程，其实需要在宿主机上设置相当多的 iptables 规则。而且，kube-proxy 还需要在控制循环里不断地刷新这些规则来确保它们始终是正确的。
当宿主机上有大量 Pod 的时候，成百上千条 iptables 规则不断地被刷新,很明显会影响到整体性能。
IPVS 模式的工作原理，其实跟 iptables 模式类似。区别只在于当我们创建了前面的 Service 之后，kube-proxy 首先会在宿主机上创建一个虚拟网卡（叫作：kube-ipvs0），并为它分配 Service VIP 作为 IP 地址，如下所示：
而接下来，kube-proxy 就会通过 Linux 的 IPVS 模块，为这个 IP 地址设置三个 IPVS 虚拟主机，并设置这三个虚拟主机之间使用轮询模式 (rr) 来作为负载均衡策略。我们可以通过 ipvsadm 查看到这个设置，如下所示：
ipvsadm -ln
-l：这是 ipvsadm 命令的一个选项，代表 “list”，即列出当前 IPVS 规则。使用该选项可以查看已经配置的虚拟服务器（Virtual Server）及其对应的真实服务器（Real Server）信息。
-n：同样是 ipvsadm 命令的选项，代表 “numeric”，表示以数字形式显示地址和端口，而不是将 IP 地址解析为域名、端口号解析为服务名。使用这个选项可以避免 DNS 解析和服务名查找的过程，更直观地显示规则信息。
可以看到，这三个 IPVS 虚拟主机的 IP 地址和端口，对应的正是三个被代理的 Pod。rr 表示轮询 round robin。
这时候，任何发往 10.103.168.44:80 的请求，就都会被 IPVS 模块转发到某一个后端 Pod 上了。 而相比于 iptables，IPVS 在内核中的实现其实也是基于 Netfilter 的 NAT 模式，所以在转发这一层上，理论上 IPVS 并没有显著的性能提升。但是，IPVS 并不需要在宿主机上为每个 Pod 设置 iptables 规则，而是把对这些“规则”的处理放到了内核态，从而极大地降低了维护这些规则的代价。
不过需要注意的是，IPVS 模块只负责上述的负载均衡和代理功能。而一个完整的 Service 流程正常工作所需要的包过滤、SNAT 等操作，还是要靠 iptables 来实现。
3.1.10、Endpoints 与 readinessProbe 就绪探针
- 编写服务 svc-hellok8s.yaml
apiVersion: v1
kind: Service
metadata:
name: hellok8s-svc
spec:
type: ClusterIP
selector:
app: hellok8s
ports:
- port: 80
protocol: TCP
targetPort: 8080- 执行并监控
kubectl apply -f svc-hellok8s.yaml
# -w 表示持续监控，注意这个时候不要关闭终端
kubectl get ep hellok8s-svc -w
- 编写部署 deploy-hellok8s.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: hellok8s
spec:
replicas: 3
selector:
matchLabels:
app: hellok8s
version: "1.0"
template:
metadata:
labels:
app: hellok8s
version: "1.0"
spec:
containers:
- name: hellok8s
image: hellok8s:1.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 15
periodSeconds: 10initialDelaySeconds: 表示容器启动后延迟多少秒，开始就绪探测。这里特意设置成 15 秒，为了观察就绪探针没有完成时， Endpoints 的列表里，会不会有 pod 的 IP。
- 在另一个终端运行部署
kubectl apply -f deploy-hellok8s.yaml
可以看到，在 pod 还没就绪前，endpoints 列表里面是不会有 pod IP 的。
- 删除部署
kubectl delete -f deploy-hellok8s.yaml
可以看到 pod 被删除，endpoints 列表也会移除 pod IP。
3.1.11、原理图
3.2、创建 NodePort 类型 Service
假设我们现在有如下 三个 pod:
kubectl get pod -l app=hostnames -owide
IP 分别是 10.244.9.57、10.244.9.59、10.244.165.3
3.2.1、编写服务
apiVersion: v1
kind: Service
metadata:
name: hostnames-nodeport
spec:
type: NodePort
selector:
app: hostnames
ports:
- port: 80
protocol: TCP
targetPort: 9376
nodePort: 32000
- spec.type：NodePort 通过每个节点上的 IP 和静态端口（NodePort）暴露服务。
- spec.ports.nodePort：指定节点上暴露的端口 32000。
3.2.2、访问服务
在浏览器中、或者任何能访问到集群三个节点的机器上，访问 节点IP:32000
curl 192.168.40.10:32000
curl 192.168.40.20:32000
curl 192.168.40.30:32000
3.2.3、原理
每一个节点的防火墙规则里面，都有一条 节点IP:32000 的转发规则。转发到三个 pod上。
创建 NodePort 类型的 Service 会默认帮我们创建 Cluster_IP
它的数据转发方式，跟 3.1 节讲的是一样的，走 kube-ipvs0 虚拟网桥。
如果节点上有安装 docker，NodePort 不会走节点IP端口，会默认走 docker0 网桥，然后数据再通过 docker0 转发给 pod。
3.3、创建 ExternalName 类型 Service
3.3.1、场景分析
Service，是无法代理到不同名称空间下的 Pod 的。
假设我们默认名称空间下，有三个这样的 Pod：
kubectl get pod -l app=hostnames -A --show-labels
在名称空间 external-demo 下，有这样一个 Service:
apiVersion: v1
kind: Service
metadata:
name: external-svc-a
namespace: external-demo
spec:
type: ClusterIP
selector:
app: hostnames
ports:
- port: 80
protocol: TCP
targetPort: 9376Service 在 external-demo 名称空间下，它的标签选择器选择了上面的三个 Pod。
查看 Service 详情：
kubectl describe svc external-svc-a -n=external-demo
可以看到它并没有代理到任何 Pod。
此时，不管是在节点上直接访问 Service ClusterIP 10.100.211.127:80
还是在 external-demo 名称空间下的 Pod：
apiVersion: v1
kind: Pod
metadata:
name: curl-tools
namespace: external-demo
spec:
containers:
- name: curl-tools
image: curlimages/curl:latest
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "while true; do echo 'Hello from curl-tools'; sleep 30; done"]kubectl exec -it -n=external-demo curl-tools -- /bin/sh
都访问不到任何 Pod。
那么，external-demo 名称空间下的 Pod 要如何通过 Service 访问 default 名称空间下的 Pod 呢？
3.3.2、ExternalName 类型 Service
在 external-demo 名称空间下新建一个 Service：
apiVersion: v1
kind: Service
metadata:
name: external-svc-b
namespace: external-demo
spec:
type: ExternalName
externalName: hostnames-svc.default.svc.cluster.local
selector:
app: hostnames
ports:
- port: 80
protocol: TCP
- type： ExternalName。
- externalName：指定 default 名称空间下的完全限定服务名。
相当于给 hostnames-svc 服务创建了一个软连接。
- targetPort：在这种情况下可以忽略。
kubectl get svc -n=external-demo
此时，在 external-demo 名称空间下的 curl-tools 就可以直接访问这个服务，请求会被代理到 default 名称空间下的 Pod:
3.4、使用自定义 Endpoints 连接集群外部服务
假设集群外的服务器 192.168.40.111 上运行着一个 mysql，端口 3306。
集群内的 pod 要如何使用服务名来连接这台 mysql？
3.4.1、创建没有选择器的服务
apiVersion: v1
kind: Service
metadata:
name: mysql-svc
spec:
type: ClusterIP
ports:
- port: 3306定义⼀个名为 mysql-svc 的服务，它将接收 3306 端口传入的连接。并没有为服务定义⼀个pod 选择器。
3.4.2、为没有选择器的服务创建 Endpoints 资源
Endpoints 是⼀个单独的资源并不是服务的⼀个属性。由于创建的 Service 中并不包含选择器，相关的 Endpoints 资源并没有自动创建，所以必须手动创建。
apiVersion: v1
kind: Endpoints
metadata:
name: mysql-svc
subsets:
- addresses:
- ip: 192.168.40.111
ports:
- port: 3306
Endpoints 对象需要与服务具有相同的名称 mysql-svc，并包含该服务的目标 IP 地址和端口列表。服务和 Endpoints 资源都发布到服务器后，这样服务就可以像具有 pod 选择器那样的服务正常使用。
3.4.3、启动 mysql-tools 工具
apiVersion: v1
kind: Pod
metadata:
name: mysql-tools
spec:
containers:
- name: mysql-tools
image: kubedb/mysql-tools:8.0.14
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "while true; do echo 'Hello from curl-tools'; sleep 30; done"]
3.4.4、进入 mysql-tools pod 内部连接服务
kubectl exec -it mysql-tools -- /bin/sh
mysql -h mysql-svc -uroot -p123456
3.5、CoreDNS 介绍
CoreDNS 是 Kubernetes 集群中的关键组件，负责提供 DNS 服务。
3.5.1、镜像准备
docker pull mkrishnamurthy/nslookup
docker save -o nslookup-tools.tar.gz mkrishnamurthy/nslookup:latest3.5.2、镜像导入工作节点 containerd
# k8s31node1 执行
[root@k8s31node1 ~]# ctr -n=k8s.io images import nslookup-tools.tar.gz
[root@k8s31node1 ~]# ctr -n=k8s.io images ls|grep nslookup-tools
# k8s31node2 执行
[root@k8s31node2 ~]# ctr -n=k8s.io images import nslookup-tools.tar.gz
[root@k8s31node2 ~]# ctr -n=k8s.io images ls|grep nslookup-tools
3.5.3、启动 nslookup 工具
apiVersion: v1
kind: Pod
metadata:
name: nslookup-tools
spec:
containers:
- name: nslookup-tools
image: mkrishnamurthy/nslookup:latest
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "while true; do echo 'Hello from nslookup-tools'; sleep 30; done"]
mkrishnamurthy/nslookup 镜像安装了 nslookup 命令。nslookup 是一个用于查询 DNS 记录的命令行工具，它可以帮助用户检查域名解析是否正常。
进入 pod 执行命令：
[root@k8s31master]# kubectl exec -it nslookup-tools -- /bin/bash
bash-4.2# nslookup hostnames-svc
10.103.168.44 是 hostnames-svc 服务的 ClusterIP
Server 10.96.0.10 是 K8S 集群 DNS 服务的 ClusterIP
这个 Service 后面代理着两个 Pod
这两个 Pod 就是实际提供 DNS 解析服务的 Pod
- 在 Kubernetes 集群中，CoreDNS 的服务（kube-dns）是一个 ClusterIP 类型的服务，背后由多个 CoreDNS Pod 提供支持。
- 当集群中的 Pod 发起 DNS 查询时，Kubernetes 会通过 Service 的负载均衡机制，将请求分发到后端的 CoreDNS Pod 上。多个 CoreDNS 实例可以分担查询负载，避免单个实例因流量过大而成为性能瓶颈。
四、参考资料
官网：虚拟 IP 和服务代理
Kubernetes教程(五)---Service 的几种访问方式
