当前位置：首页 > news >正文

K8S的Service

news 2026/5/12 20:01:04

原文博客：https://nosae.top

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: my-service-1 # EndpointSlice命令的最佳实践是以svc的名称作为前缀
labels:
# 这个label的值必须是svc的名称，将EndpointSlice与svc关联起来
kubernetes.io/service-name: my-service
addressType: IPv4
ports:

name: http # should match with the name of the service port defined above
appProtocol: http
protocol: TCP
port: 9376
endpoints:
注意endpoint不能是虚拟IP
addresses:
- "10.4.5.6"
addresses:
- "10.1.2.3"


Service支持多个端口到目标端口的映射：``` yaml
apiVersion: v1
kind: Service
metadata:name: my-service
spec:selector:app.kubernetes.io/name: MyAppports:- name: httpprotocol: TCPport: 80targetPort: 9376- name: httpsprotocol: TCPport: 443targetPort: 9377

Service的类型

之前我们默认使用的都是ClusterIP类型的Service，实际上Service一共有以下几种类型：

ClusterIP：为Service分配一个仅在集群内可访问的虚拟IP，如果要暴露到公网需要在接一个Ingress或者Gateway

apiVersion: v1
kind: Service
metadata:name: service-clusterip
spec:selector:app.kubernetes.io/name: MyAppports:- protocol: TCPport: 80targetPort: 8080

结果：

$ kubectl get svc service-clusterip
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service-clusterip   ClusterIP   10.96.229.241   <none>        80/TCP    2m28s

NodePort：在ClusterIP的基础上，为每个node开放一个静态端口

apiVersion: v1
kind: Service
metadata:name: service-nodeport
spec:type: NodePortselector:app.kubernetes.io/name: MyApp-nodeportports:- port: 80targetPort: 80nodePort: 30007 # nodePort也可以由控制面动态分配

结果：

$ kubectl get svc service-nodeport
NAME               TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
service-nodeport   NodePort   10.96.31.20   <none>        80:30007/TCP   2m46s

LoadBalancer：在Nodeport的基础上，自动创建一个云厂商提供的负载均衡器
ExternalName：最特殊的类型，没有backend，不涉及代理和转发，仅仅是将请求重定向到一个外部的DNS名称。比如下面的配置，当访问my-service.prod.svc.cluster.local名称时，会返回一个CNAME记录，值为my.database.example.com
```
apiVersion: v1
kind: Service
metadata:name: my-servicenamespace: prod
spec:type: ExternalNameexternalName: my.database.example.com
```

无头Service

普通的Service会分配一个ClusterIP，并负载均衡所有背后的Pod，旨在将多个无状态backend抽象为统一的入口。但无头Service，不会分配ClusterIP、kube-proxy也不会处理（不生成任何 iptables/IPVS 规则、不做负载均衡），旨在将每个Pod的IP直接暴露出去，让应用层来决定如何连接。

创建无头Service只需要将ClusterIP类型的Service的.spec.clusterIP指定为None：

spec:clusterIP: None

无头Service暴露的Pod IP方式是集群DNS。

其实对于普通Service来说，也会涉及到DNS，DNS会创建一个Service的完全限定域名（FQDN，Fully Qualified Domain Name），命令为<service-name>.<namespace>.svc.cluster.local，其有一条值为ClusterIP的A记录。

无头Service的完全限定域名下则包含了n条A记录（ n为backend Pod的数量），值分别为每个Pod的IP，并且还会为每个Pod创建单独完全限定域名，命名为<pod-name>.<service-name>.<namespace>.svc.cluster.local，每个域名下包含值为该Pod的IP的A记录。

因此，无头 Service 的核心价值在于它提供了两种粒度的 DNS 解析：Service域名（用于发现）和Pod域名（用于身份识别），前者可以用来做客户端侧负载均衡，后者用来为每个Pod提供稳定的身份，用于在有状态服务中Pod之间互相识别对等节点以稳定协同工作，即使Pod重建了，只要Pod名称没变，域名也不会变。举个MySQL主从节点的例子：

环节	动作描述	无头 Service 的作用
集群初始化	`mysql-1` 需要知道主节点 `mysql-0` 的稳定地址来进行复制配置。	`mysql-1` 通过解析 `mysql-0.mysql-headless.default.svc.cluster.local` 稳定地找到主节点的 IP，建立复制连接。
内部访问	应用客户端需要读写数据，并将连接分散到主从节点。	客户端可以查询 `mysql-headless`，获取所有 Pod IP 列表，然后根据自身的逻辑（例如，写操作连主节点 IP，读操作连从节点 IP）进行客户端侧的连接管理。
节点故障/重启	`mysql-0` Pod 发生故障，被 K8s 重新调度。	即使 Pod IP 变了，它的稳定域名 `mysql-0.mysql-headless` 仍然解析到新的 IP 地址，复制关系和配置无需手动修改。