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

Kubernetes（四）：Service

news 2025/9/6 10:19:17

Kubernetes 中 Service 是将运行在一个或一组 Pod 上的应用程序对外暴露出去的方法。这样多个相同功能容器可以对外提供统一的访问入口。

Service解决了：

避免直接访问Pod，因为Pod的数量和IP都可能发生变化。而通过Service可以提供稳定的统一入口。
提供了负载均衡机制（包括后端Pod自动注册和发现）

一、定义Service

定义Service的yaml常见字段含义说明如下：

apiVersion: v1
kind: Service
metadata:name: namespace:labels: []anotations: []
spec:selector: []             # 标签选择器，选择满足条件的后端Podtype:                    # Service的公开暴露类型，type可取值(首字母大写)：ClusterIP默认、NodePort、LoadBalancer、ExternalNameclusterIP:               # 分配给该Service的IP地址列表。type=ClusterIP或NodePort时，若不手动指定IP则自动分配（在kubeadm init指定的网段范围内）；若填值None则为Headless服务sessionAffinity：        # 可取值：ClientIP、None默认。若配置为ClientIP表示对收到同个客户端IP的访问请求每次都转发到同个后端Pod上。ports:                   # 端口列表。若多个端口须分别指定name- name:                  # 端口名。若仅有一个port，可不设置此字段protocol:              # 协议。可取值： TCP默认、UDP、SCTPport:                  # Service在clusterIP上的监听端口nodePort:              # 当type=NodePort或LoadBalancer时，在每个节点机器上的分配端口（端口允许范围30000-32767）。targetPort:            # 转发至后端Pod上的端口，若未指定则等于port
status:                    # 当type=LoadBalancer时设置外部负载均衡器地址，比如公有云环境loadBalancer:            # 外部负载均衡器ingress:               # 外部负载均衡器ip:                  # 外部负载均衡器的IP地址hostname:            # 外部负载均衡器的主机名

1.1 示例type=ClusterIP

在前文【Kubernetes（三）：Workload工作负载-CSDN博客】已经创建Deployment的基础上（Pod的标签是app=nginx， Pod内容器端口为80）。然后通过以下nginx-service.yaml文件，创建一个Service：

apiVersion: v1
kind: Service
metadata:name: nginx-service
spec:selector:                # 标签选择器，选择满足条件的后端Podapp: nginxtype: ClusterIPports:- port: 55580            # Service在clusterIP上的监听端口targetPort: 80         # 转发至后端Pod上的端口，若未指定则等于port

kubectl apply -f nginx-service.yaml# 以下service可简写svc
kubectl get service -o widekubectl describe service/nginx-service

其中Service的Endpoints是后端Pod的地址列表。如果Pod发生变化，Kubernetes会自动维护Service的EndPoints地址列表，自动保持最新。

可以在Kubernetes集群内（包括集群节点机器及容器内）可通过命令访问Service的虚拟IP和端口来访问后端的Pod：curl http://172.16.242.61:55580

默认情况，访问请求会被Service均衡分发给后端Pod之一。

1.2 示例type=NodePort

在上文type=ClusterIP的例子中，因为值在服务虚拟IP（clusterIP）上监听，所以只能在Kubernetes集群内（包括集群节点机器及容器内）才能访问到该Service。

若希望从Kubernetes集群外也可以访问Service，则需把改type=NodePort。NodePort是建立在type=ClusterIP的基础上，并在每个节点机器上分配一个nodePort端口。通过该nodePort端口访问的请求，Service也可以分发到与后端Pod的Endpoints。

apiVersion: v1
kind: Service
metadata:name: nginx-service
spec:selector:                # 必选。标签选择器，选择满足条件的后端Podapp: nginxtype: NodePortports:- port: 55580            # Service在clusterIP上的监听端口nodePort: 32000        # 当type=NodePort或LoadBalancer时，在每个节点机器上的分配端口（端口允许范围30000-32767）。targetPort: 80         # 转发至后端Pod上的端口，若未指定则等于port

kubectl apply -f nginx-service.yaml# 以下service可简写svc
kubectl get service -o widekubectl describe service/nginx-service

不仅可以在Kubernetes集群内（包括集群节点机器及容器内）可通过命令访问Service的虚拟IP和端口来访问后端的Pod：curl http://172.16.167.197:55580

而且还可以从Kubernetes集群外访问，访问地址为：任意一个节点机器IP:nodePort 如下图：

虽然可以通过节点机器IP访问，但在节点机器操作系统上通过netstat命令是无法看到nodePort侦听端口。这是因为没有采用通常的直接监听方式，而是kube-proxy利用操作系统的代理模式来转发。

kube-proxy的--proxy-mode选项指定转发的代理模式，当节点机器是Linux则可为ipvs或iptables模式（不手工指定时，若Linux操作系统加载启用了IPVS内核，kube-proxy会自动优先选择IPVS模式，否则切换iptables模式）；当节点机器是Windows则为kernelspace模式。

1.3 将外部服务定义为Service

普通的Service通过selector标签选择器对后端Pod的Endpoints列表进行了抽象封装，如果后端的Endpoints不是由Pod提供，而是在Kubernetes之外的其他服务提供。在Kubernetes里的一些应用也需要访问这些外部服务，典型场景为：

非Kubernetes管理的服务。例如单独部署的数据库、Redis、或者其他服务。
从一个Kubernetes集群访问另一个Kubernetes集群。

对应这类场景，在创建Service时不设置selector标签选择器（也无后端Pod可选），同时再定义一个与Service关联的Endpoints资源对象，在Endpoints中定义外部服务的IP地址和端口号。

下面for-external-service.yaml

---
apiVersion: v1
kind: Service
metadata:name: for-external-service
spec:ports:- port: 21212            # Service在clusterIP上的监听端口targetPort: 1111       # 对于此情况，因为不用targetPort，所以配成什么端口都无所谓
---
apiVersion: v1
kind: Endpoints
metadata:name: for-external-service
subsets:                   # 最终Endpoints条数是 addresses多个IP 与 ports多个端口 的笛卡尔乘积
- addresses:- ip: 180.101.190.78     # 域名www.9991.com的公网IPports:                   # 若多个端口须分别指定name，且name值须与Service中spec.ports.name字段值匹配，以与之对应- port: 80