Kubernetes(四):Service

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

Service解决了:

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

一、定义Service

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

XML 复制代码
apiVersion: v1
kind: Service
metadata:
  name: 
  namespace:
  labels: []
  anotations: []
spec:
  selector: []             # 标签选择器,选择满足条件的后端Pod
  type:                    # Service的公开暴露类型,type可取值(首字母大写):ClusterIP默认、NodePort、LoadBalancer、ExternalName
  clusterIP:               # 分配给该Service的IP地址列表。type=ClusterIP或NodePort时,若不手动指定IP则自动分配(在kubeadm init指定的网段范围内);若填值None则为Headless服务
  sessionAffinity:        # 可取值:ClientIP、None默认。若配置为ClientIP表示对收到同个客户端IP的访问请求每次都转发到同个后端Pod上。
  ports:                   # 端口列表。若多个端口须分别指定name
  - name:                  # 端口名。若仅有一个port,可不设置此字段
    protocol:              # 协议。可取值: TCP默认、UDP、SCTP
    port:                  # 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:

XML 复制代码
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:                # 标签选择器,选择满足条件的后端Pod
    app: nginx
  type: ClusterIP
  ports:
  - port: 55580            # Service在clusterIP上的监听端口
    targetPort: 80         # 转发至后端Pod上的端口,若未指定则等于port
bash 复制代码
kubectl apply -f nginx-service.yaml

# 以下service可简写svc
kubectl get service -o wide

kubectl 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。

XML 复制代码
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:                # 必选。标签选择器,选择满足条件的后端Pod
    app: nginx
  type: NodePort
  ports:
  - port: 55580            # Service在clusterIP上的监听端口
    nodePort: 32000        # 当type=NodePort或LoadBalancer时,在每个节点机器上的分配端口(端口允许范围30000-32767)。
    targetPort: 80         # 转发至后端Pod上的端口,若未指定则等于port
bash 复制代码
kubectl apply -f nginx-service.yaml

# 以下service可简写svc
kubectl get service -o wide

kubectl 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

XML 复制代码
---
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的公网IP
  ports:                   # 若多个端口须分别指定name,且name值须与Service中spec.ports.name字段值匹配,以与之对应
  - port: 80
相关推荐
AKAMAI14 小时前
Linebreak赋能实时化企业转型:专业系统集成商携手Akamai以实时智能革新企业运营
人工智能·云原生·云计算
博睿谷IT99_15 小时前
K8s 核心架构是什么?组件怎么协同工作的?
云原生·kubernetes·k8s·k8s pod 设计原理·容器编排与集群管理
能不能别报错16 小时前
K8s学习笔记(二十一) RBAC
笔记·学习·kubernetes
久绊A16 小时前
Kubernetes(k8s)版本查看
云原生·容器·kubernetes
007php00716 小时前
Docker 实战经验之关键文件误删恢复指南(一)
jvm·docker·云原生·容器·面试·职场和发展·eureka
Do_GH17 小时前
【Docker】06.通过WSL部署Docker Desktop
运维·docker·容器
可DRAK鸦|・ω・`)17 小时前
docker后端jar包本地构建镜像
java·docker·容器·jar
KubeSphere 云原生17 小时前
HolmesGPT 正式上线 丨 KubeSphere 助力云原生智能排障新体验
云原生
咕噜签名分发冰淇淋17 小时前
内测分发平台是否支持应用的微服务化部署
微服务·云原生·架构
G探险者18 小时前
云原生时代下的 JVM 内存管理:为什么你的服务不会“自动扩容”?
后端·云原生