当前位置:   article > 正文

Kubernetes(K8s)的Service解析_kubernetes中service的作用

kubernetes中service的作用

目录

  • 一、核心特性
  • 二、YAML配置示例
  • 三、使用kubectl操作Service
  • 四、Service的工作原理
  • 五、最佳实践

Kubernetes(简称K8s)中的Service是一种核心资源对象,它为一组提供相同功能的Pod提供了稳定、统一的网络入口点,并负责服务发现、负载均衡以及网络路由。

一、核心特性

  1. 服务发现Service为一组具有相同功能的Pod定义了一个固定的、逻辑上的DNS名称和IP地址(即ClusterIP),这些信息在Kubernetes命名空间内唯一。无论Pod如何动态变化(如增删、迁移、重启),只要它们的标签匹配Service的标签选择器,客户端就能通过Service的DNS名或IP地址访问这些Pod,而无需关心Pod的实际IP和端口。

  2. 负载均衡Service内置了负载均衡机制,能够将来自外部或内部的请求按照预定义策略(如轮询、会话亲和性等)分发到其后端关联的多个Pod实例上。这有助于提高服务的可用性和响应速度,确保请求在多个实例间均匀分布。

  3. 网络模式

    • ClusterIP(默认):为Service分配一个仅在集群内部可访问的虚拟IP。集群内部的Pod和其他Service可以通过此IP与Service通信。
    • NodePort:在ClusterIP基础上,为Service在每个节点上开放一个静态端口(NodePort),使得外部可以通过 <节点IP>:<NodePort> 访问Service
    • LoadBalancer(在支持的云环境):在NodePort基础上,进一步创建一个云提供商的负载均衡器,为Service提供一个公网IP。外部可以直接通过这个公网IP访问Service
    • ExternalName:不分配ClusterIP,而是返回一个CNAME记录指向一个外部DNS名称。这种模式常用于将Kubernetes内的服务映射到外部服务。
  4. 端口映射Service可以定义一个或多个端口,每个端口对应后端Pod的一个或多个端口。Service通过标签选择器(Label Selector)来确定哪些Pod是其后端。

  5. 会话亲和性(Session Affinity)Service支持设置会话亲和性,确保来自同一客户端的连续请求被转发到同一后端Pod,这对于需要维持会话状态的应用至关重要。

  6. 健康检查Service能利用Pod的健康检查(Liveness Probe和Readiness Probe)信息,只将请求转发到健康就绪的Pod,避免将流量导向存在问题的实例。

  7. Endpoint Slice(从v1.16开始引入):对于大规模Pod场景,Service使用Endpoint Slice资源替代传统的Endpoint资源,以更高效的方式管理后端Pod列表。

二、YAML配置示例

下面是一个简单的Service YAML配置示例,创建了一个名为my-web-serviceClusterIP类型Service,其目标Pod通过标签app=web选择,暴露了80端口,并将流量转发到Pod的8080端口:

apiVersion: v1
kind: Service
metadata:
  name: my-web-service
spec:
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

三、使用kubectl操作Service

  • 创建Servicekubectl apply -f service.yaml
  • 查看Service详情:kubectl describe service my-web-service
  • 获取Service IP:kubectl get service my-web-service -o jsonpath='{.spec.clusterIP}'
  • 删除Servicekubectl delete service my-web-service

四、Service的工作原理

  1. kube-proxy:每个Kubernetes节点上运行着一个kube-proxy组件,它是Service功能在节点层面的具体实现者。kube-proxy监听API服务器,获取并更新Service和Endpoints信息,然后通过iptables规则或其他网络代理(如IPVS)实现网络流量的重定向和负载均衡。

  2. EndpointsService与其后端Pod之间的关系由Endpoints资源表示。kube-controller-manager中的endpoints-controller监控Service和Pod的变化,动态维护对应的Endpoints列表。

五、最佳实践

  • 清晰的标签策略:确保Pod具有清晰、一致的标签,以便Service通过标签选择器精确地识别后端Pod。
  • 使用Headless Service:对于需要直接连接到Pod(如StatefulSet中的成员)而不经过负载均衡的场景,可以创建没有ClusterIP的“Headless”Service,它将返回Pod的IP列表作为DNS A记录。
  • 网络模式选择:根据应用需求和环境条件选择合适的网络模式(ClusterIP、NodePort、LoadBalancer或ExternalName),考虑因素包括网络隔离、外部访问需求、性能、成本等。
  • 健康检查与会话亲和性:针对应用特点启用适当的健康检查和会话亲和性设置,以确保服务的稳定性和用户体验。
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Monodyee/article/detail/685012
推荐阅读
相关标签
  

闽ICP备14008679号