Kubernetes Service

Kubernetes Service 工作原理

Service 在 Kubernetes 中为 Pod 提供稳定的访问入口，通过标签选择器（Label Selector）关联一组 Pod。kube-proxy 负责实现 Service 的负载均衡和网络规则配置。

kube-proxy 的三种代理模式

userspace 模式

早期模式，kube-proxy 在用户空间监听 Service 和 Endpoint 变化。
请求经过 iptables 转发到 kube-proxy 端口，再由 kube-proxy 分发到后端 Pod。
性能较差，已被淘汰。

iptables 模式

默认模式，kube-proxy 通过 iptables 规则直接转发流量。
不经过用户空间，性能较好。
缺点是不支持动态负载均衡策略。

ipvs 模式

基于内核的 IPVS（IP Virtual Server）实现。
支持更多负载均衡算法（如 rr、wrr、lc 等）。
性能最佳，适合大规模集群。

Service 类型及使用场景

ClusterIP

默认类型，分配集群内部 IP。
只能在集群内部访问。

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

NodePort

在 ClusterIP 基础上，在每个 Node 上开放端口。
外部可通过 <NodeIP>:<NodePort> 访问。

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30007

LoadBalancer

在 NodePort 基础上，集成云提供商负载均衡器。
自动分配外部 IP 地址。

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

ExternalName

将服务映射到外部 DNS 名称。
不创建任何代理或端口转发。

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ExternalName
  externalName: my.database.example.com

服务发现机制

环境变量

每个 Service 会注入一组环境变量到 Pod 中。
格式：<SERVICE_NAME>_SERVICE_HOST 和 <SERVICE_NAME>_SERVICE_PORT。

DNS

集群内 DNS 服务（如 CoreDNS）自动为 Service 创建 DNS 记录。
访问格式：<service-name>.<namespace>.svc.cluster.local。

Headless Service

适用于需要直接访问 Pod 的场景，不分配 ClusterIP：

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  clusterIP: None
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

会话保持配置

通过 sessionAffinity 实现客户端请求固定到同一个 Pod：

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  sessionAffinity: ClientIP
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

流量策略

externalTrafficPolicy

Cluster：默认值，流量可能转发到其他节点的 Pod。
Local：只转发到本节点的 Pod，保留原始客户端 IP。

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  externalTrafficPolicy: Local
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Kubernetes 资源标签与选择器配置问题分析

从描述来看，问题可能涉及 Kubernetes 中标签（Label）和选择器（Selector）的配置不一致，导致服务（Service）无法正确关联 Pod。以下是关键点解析：

标签与选择器匹配问题

在 Kubernetes 中，Service 通过 selector 字段匹配 Pod 的 labels。示例中存在拼写错误：

Pod 的标签为 env=dev（正确）
Service 的选择器为 _env=dev（错误，多了下划线）

修正方法：

yaml 复制代码

# Service 配置示例
selector:
  env: dev  # 需与 Pod 的 label 完全一致

组件交互流程

kube-proxy 监听 API Server 的 Service 和 Endpoint 变化，生成 iptables/ipvs 规则。
Service 通过 selector 匹配 Pod 的 labels，生成 Endpoint 列表。
流量通过 Node 的 kube-proxy 规则转发到后端 Pod。

常见排查步骤

检查 Service 的 Endpoints 是否为空：

bash 复制代码

kubectl get endpoints <service-name>

验证 Pod 的 labels 是否匹配：

bash 复制代码

kubectl get pods --show-labels

检查 Service 的 selector 配置：

bash 复制代码

kubectl describe service <service-name>

其他可能原因

命名空间隔离：Service 和 Pod 需在同一命名空间。
Label 拼写错误 ：如 env=dev 与 environment=dev 不匹配。
kube-proxy 异常：检查 kube-proxy 组件日志是否正常。

通过修正选择器拼写并验证标签匹配性，通常可解决此类服务发现问题。

三、userspace 模式详解

userspace 模式是 kube-proxy 最早支持的工作模式，其核心原理是通过用户空间的代理实现服务转发。

工作原理

kube-proxy 为每个 Service 创建监听端口，通过 iptables 规则将发往 Cluster IP 的流量重定向到这些端口。kube-proxy 根据负载均衡算法（如轮询）选择一个后端 Pod，并与该 Pod 建立连接完成请求转发。

特点

稳定性高：由于运行在用户空间，对内核依赖较少，兼容性较好。
性能较低：数据需在用户空间和内核空间多次拷贝，增加了延迟和 CPU 开销。
四层负载均衡：仅支持 TCP/UDP 协议，无法解析应用层内容（如 HTTP）。

适用场景

适用于早期 Kubernetes 版本或对稳定性要求高于性能的场景，但在生产环境中已逐渐被其他模式取代。

四、iptables 模式

iptables 模式通过内核层的 iptables 规则直接实现服务转发，无需用户空间参与。

工作原理

kube-proxy 动态维护 iptables 规则，将 Service 的 Cluster IP 和端口映射到后端 Pod 的 IP 和端口。流量直接由内核处理，无需经过用户空间代理。

特点

高性能：避免了用户空间和内核空间的数据拷贝，转发效率显著提升。
无负载均衡算法：默认使用随机选择策略，不支持高级 LB 算法（如最小连接数）。
规则膨胀问题：大规模集群中 iptables 规则可能过多，影响性能。

适用场景

适用于中小规模集群，对性能要求较高的场景，但需注意规则管理复杂度。

五、IPVS 模式

IPVS（IP Virtual Server）是内核提供的 L4 负载均衡技术，kube-proxy 通过 IPVS 实现高效的流量分发。

工作原理

kube-proxy 调用 IPVS 内核模块创建虚拟服务（Virtual Service），将 Service 的 Cluster IP 绑定到 IPVS 规则，并配置后端 Pod 的真实地址。流量由内核直接转发。

特点

高性能：基于哈希表存储规则，查询效率高于 iptables，适合大规模集群。
丰富负载均衡算法：支持轮询（rr）、最小连接数（lc）、源哈希（sh）等算法。
依赖内核模块 ：需确保节点内核启用 IPVS 模块（ip_vs、ip_vs_rr 等）。

适用场景

大规模生产环境，尤其是需要高性能和灵活负载均衡策略的场景。

六、模式对比

特性	userspace	iptables	IPVS
性能	低（用户态转发）	中（内核态转发）	高（内核态优化）
LB 算法	支持简单算法	仅随机	支持多种算法
规则维护	动态监听端口	iptables 规则	IPVS 哈希表
适用规模	小规模	中小规模	大规模

总结

userspace 模式已逐渐淘汰，仅用于特定兼容场景。
iptables 模式是默认选项，适合多数中小集群。
IPVS 模式为大规模集群提供最优性能和扩展性。

Kube-proxy userspace 模式工作原理

在 Kubernetes 中，kube-proxy 的 userspace 模式是一种早期代理实现方式，通过用户空间程序处理流量转发。以下是其核心组件和交互流程：

组件角色说明

Client: 发起请求的外部或内部客户端。
apiserver: Kubernetes 控制平面的核心组件，负责接收和处理所有 REST 请求。
kube-proxy: 运行在每个节点上的网络代理，维护节点上的网络规则。
clusterIP : 服务的虚拟 IP 地址，由 kube-proxy 监听并转发到后端 Pod。
Backend Pods : 实际运行应用的 Pod，通过标签（如 app=MyApp）匹配服务选择器。

Userspace 模式流程

服务创建

用户通过 apiserver 创建 Service，定义 selector 为 app=MyApp 和 port: 9376。kube-proxy 监听此事件。
规则配置
kube-proxy 在节点上为 Service 的 clusterIP 创建 iptables 规则，将流量重定向到 kube-proxy 监听的随机端口（用户空间）。
流量转发

当客户端访问 clusterIP:9376 时：
- iptables 拦截流量并转发到 kube-proxy 的代理端口。
- kube-proxy 在用户空间通过轮询（Round Robin）等算法选择后端 Pod（如 Backend Pod 1）。
- 代理将请求转发到目标 Pod 的 9376 端口。
后端维护
kube-proxy 持续监听 Pod 变化（如扩缩容），动态更新代理规则。

Userspace 模式特点

优点：兼容性较好，适用于早期内核版本。
缺点：
- 性能较低（用户空间和内核空间频繁切换）。
- 依赖 iptables 做初步拦截，代理逻辑在用户态实现。

对比其他模式

iptables 模式：完全通过内核态 iptables 规则转发，性能更高，但规则数量可能膨胀。
IPVS 模式：基于内核的 L4 负载均衡，支持更丰富的调度算法（如最小连接数）。

示例配置

若需显式启用 userspace 模式（Kubernetes 1.2 后默认使用 iptables 模式），可在 kube-proxy 启动时指定：

bash 复制代码

kube-proxy --proxy-mode=userspace

iptables 模式工作原理

在iptables模式下，kube-proxy通过监听Kubernetes API Server获取Service和Endpoint的变化，动态更新节点上的iptables规则。当Service创建或Pod发生变化时，kube-proxy会生成相应的规则，将发往Service Cluster IP的流量直接转发到后端Pod。

核心实现机制

每个Service会生成两条核心iptables链：

KUBE-SERVICES：作为入口链，匹配目标IP为Cluster IP的包
KUBE-SVC-<hash>：服务对应的主链，包含负载均衡规则

每个Endpoint会生成：

KUBE-SEP-<hash>：端点链，包含具体Pod的DNAT规则

流量匹配过程：数据包首先进入KUBE-SERVICES链，匹配到对应服务后跳转到KUBE-SVC-<hash>链，然后通过随机概率分配跳转到某个KUBE-SEP-<hash>链，最终完成DNAT转换。

性能特征

iptables模式使用Linux内核的netfilter框架，相比userspace模式消除了内核空间和用户空间的切换开销。但存在以下限制：

规则线性匹配：iptables规则是顺序匹配的，当服务数量较多时（超过1000）会产生明显的延迟
无重试机制：如果第一个被选中的Pod不可用，连接会直接失败
负载均衡算法单一：仅支持随机均衡策略

典型规则示例

对于Cluster IP为10.96.0.10的Service，后端有两个Pod（10.244.1.2和10.244.2.2），生成的规则类似：

复制代码

-A KUBE-SERVICES -d 10.96.0.10/32 -p tcp --dport 80 -j KUBE-SVC-XPGD46QRK7WJZT7O
-A KUBE-SVC-XPGD46QRK7WJZT7O -m statistic --mode random --probability 0.5 -j KUBE-SEP-LIGYVQMCRW3E5LAF
-A KUBE-SVC-XPGD46QRK7WJZT7O -j KUBE-SEP-7XZ5YYKL5H6HJ3XW
-A KUBE-SEP-LIGYVQMCRW3E5LAF -p tcp -j DNAT --to-destination 10.244.1.2:80
-A KUBE-SEP-7XZ5YYKL5H6HJ3XW -p tcp -j DNAT --to-destination 10.244.2.2:80

适用场景

iptables模式适合中小规模集群，具有以下特征时表现最佳：

服务数量在1000个以下
不需要高级负载均衡策略
对网络性能有较高要求
可以接受无连接重试的简单故障模式

在大规模集群中，建议考虑ipvs模式以获得更好的性能。

Kube-proxy iptables 模式工作原理

Kube-proxy 在 iptables 模式下通过操作 Linux 内核的 iptables 规则来实现 Kubernetes 服务的负载均衡和流量转发。以下是其核心机制：

Service 创建与 ClusterIP 分配

当创建 Service 时，Kubernetes 控制平面（如 apiserver）会为其分配一个 ClusterIP（虚拟 IP）。此 IP 仅在集群内部可达，作为服务的访问入口。
Endpoint 与 Pod 关联

Service 通过标签选择器（如 app=MyApp）匹配后端 Pod（如 Pod 1/2/3）。kube-proxy 监控 Pod 变化，动态更新 iptables 规则以反映当前可用的 Pod IP 和端口（如 9376）。
iptables 规则生成

kube-proxy 为每个 Service 创建两条核心链：
- KUBE-SERVICES：作为入口链，匹配目标为 ClusterIP 的流量。
- KUBE-SVC-XXXXX ：服务专属链，通过概率跳转（probability）实现负载均衡，将流量分发到 Pod 专属链（如 KUBE-SEP-YYYYY）。
流量转发流程

当客户端（Client）访问 ClusterIP 时，数据包经过以下规则处理：
- 命中 KUBE-SERVICES 链，跳转到对应服务的 KUBE-SVC-XXXXX 链。
- 通过随机算法选择一条 KUBE-SEP-YYYYY 链，将目标 IP 和端口替换为 Pod 的 IP 和端口（DNAT）。
- 最终流量被路由到具体的 Pod（如 Backend Pod 1）。

关键 iptables 规则示例

以下是一个简化的规则示例，展示如何将流量从 ClusterIP 转发到 Pod：

plaintext 复制代码

-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp --dport 80 -j KUBE-SVC-ABCDEF
-A KUBE-SVC-ABCDEF -m statistic --mode random --probability 0.333 -j KUBE-SEP-123456
-A KUBE-SVC-ABCDEF -m statistic --mode random --probability 0.5 -j KUBE-SEP-789012
-A KUBE-SVC-ABCDEF -j KUBE-SEP-345678
-A KUBE-SEP-123456 -p tcp -j DNAT --to-destination 192.168.1.2:9376

特点与注意事项

无状态负载均衡：基于 iptables 的随机概率分配，不支持会话保持（Session Affinity 需额外规则）。
高性能：规则在内核态处理，但规则数量过多时可能影响性能。
动态更新：kube-proxy 监听 API Server，实时同步 Service 和 Endpoint 变化。

2.3 ipvs 模式

ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。

IPVS 模式下的 kube-proxy 工作原理

在 Kubernetes 集群中，kube-proxy 负责实现 Service 的虚拟 IP 和 Pod 之间的流量转发。IPVS（IP Virtual Server）是 kube-proxy 的一种模式，它利用内核级别的负载均衡技术，提供高性能的服务代理。

IPVS 模式的核心组件

apiserver

Kubernetes 控制平面的核心组件，负责接收和管理所有资源的创建、更新和删除操作。当 Service 或 Endpoint 发生变化时，apiserver 会通知 kube-proxy 更新规则。

Client

外部或集群内部的请求发起者，通过 Service 的 ClusterIP 或 NodePort 访问后端 Pod。

kube-proxy

运行在每个节点上的代理服务，在 IPVS 模式下通过管理内核中的 IPVS 规则来实现流量转发。

clusterIP (Virtual Server)

Service 的虚拟 IP 地址，由 kube-proxy 配置为 IPVS 的虚拟服务器（Virtual Server），作为流量的入口。

Node

集群中的工作节点，运行 kube-proxy 和后端 Pod。

Backend Pod 1/2/3 (Real Server)

实际处理请求的 Pod，IPVS 将它们配置为真实服务器（Real Server），并通过负载均衡算法分发流量。

IPVS 模式的工作流程

Service 创建

当用户通过 apiserver 创建 Service 时，kube-proxy 会监听 Service 和 Endpoint 的变化。IPVS 模式下，kube-proxy 直接在节点的内核中配置虚拟服务器（Virtual Server）和真实服务器（Real Server）的映射关系。
流量转发

客户端请求到达 Service 的 ClusterIP 时，内核的 IPVS 模块会根据配置的负载均衡算法（如轮询、最少连接等）将请求转发到后端的某个 Pod。
负载均衡算法

IPVS 支持多种负载均衡算法，例如：
- rr（轮询）
- lc（最少连接）
- sh（源地址哈希）
- dh（目标地址哈希）
规则管理

kube-proxy 通过调用 ipvsadm 工具或直接通过内核接口动态更新 IPVS 规则。例如，新增或删除 Pod 时，kube-proxy 会实时调整真实服务器列表。

IPVS 模式的配置示例

查看节点的 IPVS 规则：

bash 复制代码

ipvsadm -Ln

输出示例：

复制代码

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 192.168.1.100:6443          Masq    1      0          0
TCP  10.96.0.10:53 rr
  -> 10.244.0.5:53               Masq    1      0          0
  -> 10.244.0.6:53               Masq    1      0          0

IPVS 模式的优势

高性能：IPVS 在内核层面实现负载均衡，转发效率远高于 iptables 模式。
支持多种调度算法：可以根据需求选择不同的负载均衡策略。
大规模集群友好：规则更新和查询的效率更高，适合管理大量 Service 和 Pod。

IPVS 模式的局限性

依赖内核模块：需要节点内核支持 IPVS 模块，某些旧版本内核可能需要手动加载。
功能较基础：IPVS 本身不支持网络策略（NetworkPolicy），需依赖其他组件（如 Calico）实现。

启用 IPVS 模式的方法

在 kube-proxy 的配置中设置 mode: "ipvs"：

yaml 复制代码

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"

确保节点已加载 IPVS 内核模块：

bash 复制代码

modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr
modprobe ip_vs_sh

bash 复制代码

# 此模式必须安装ipvs内核模块（集群部署的时候已安装），否则会降级为iptables
# 开启ipvs，cm： configmap
[root@k8s-master01 ~]# kubectl edit cm kube-proxy -n kube-system
# 修改mode: "ipvs"
[root@k8s-master01 ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
[root@node1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.16.32.128:30080 rr
  -> 172.16.79.79:80              Masq    1      0          0         
TCP  172.16.32.128:32665 rr
  -> 172.16.79.82:8443            Masq    1      0          0         
TCP  172.17.0.1:30080 rr
  -> 172.16.79.79:80              Masq    1      0          0         
TCP  172.17.0.1:32665 rr
  -> 172.16.79.82:8443            Masq    1      0          0         
TCP  192.168.115.161:30080 rr
  -> 172.16.79.79:80              Masq    1      0          0         
TCP  192.168.115.161:32665 rr
  -> 172.16.79.82:8443            Masq    1      0          0         
TCP  192.168.115.166:30080 rr
  -> 172.16.79.79:80              Masq    1      0          0         
TCP  192.168.115.166:32665 rr
  -> 172.16.79.82:8443            Masq    1      0          0         
TCP  10.10.0.1:443 rr
  -> 192.168.115.161:6443         Masq    1      0          0         
  -> 192.168.115.162:6443         Masq    1      0          0         
  -> 192.168.115.163:6443         Masq    1      1          0         
TCP  10.10.0.10:53 rr
  -> 172.16.122.139:53            Masq    1      0          0         
  -> 172.16.122.140:53            Masq    1      0          0         
TCP  10.10.0.10:9153 rr
  -> 172.16.122.139:9153          Masq    1      0          0         
  -> 172.16.122.140:9153          Masq    1      0          0         
TCP  10.10.39.128:8000 rr
  -> 172.16.79.80:8000            Masq    1      0          0         
TCP  10.10.128.23:443 rr
  -> 172.16.79.81:443             Masq    1      0          0         
TCP  10.10.166.16:8000 rr
  -> 172.16.79.79:80              Masq    1      0          0         
TCP  10.10.195.192:443 rr
  -> 172.16.79.82:8443            Masq    1      0          0         
UDP  10.10.0.10:53 rr
  -> 172.16.122.139:53            Masq    1      0          0         
  -> 172.16.122.140:53            Masq    1      0          0

三、Service资源类型

常见的Service资源清单

bash 复制代码

apiVersion: v1
kind: Service
matadata:                                #元数据
  name: string                           #service的名称
  namespace: string                      #命名空间  
  labels:                                #自定义标签属性列表
    - name: string
  annotations:                           #自定义注解属性列表  
    - name: string
spec:                                    #详细描述
  selector: []                           #label selector配置，将选择具有label标签的Pod作为管理范围
  type: string                           #service的类型，指定service的访问方式，默认为clusterIp              
  clusterIP: string                      #虚拟服务地址      
  sessionAffinity: string                #是否支持session
  ports:                                 #service需要暴露的端口列表
  - name: string                         #端口名称
    protocol: string                     #端口协议，支持TCP和UDP，默认TCP
    port: int                            #服务监听的service端口号
    targetPort: int                      #需要转发到后端Pod的端口号
    nodePort: int                        #当type = NodePort时，指定映射到物理机的端口号
  status:                                #当spce.type=LoadBalancer时，设置外部负载均衡器的地址
    loadBalancer:                        #外部负载均衡器    
      ingress:                           #外部负载均衡器 
        ip: string                       #外部负载均衡器的Ip地址值
        hostname: string                 #外部负载均衡器的主机名

资源清单案例

bash 复制代码

apiVersion: v1  # 资源版本
kind: Service  # 资源类型
metadata: # 元数据
  name: service # 资源名称
  namespace: dev # 命名空间
spec: # 描述
  selector: # 标签选择器，用于确定当前service代理哪些pod
    app: nginx
  type: # Service类型，指定service的访问方式
  clusterIP:  # 虚拟服务的ip地址
  sessionAffinity: # session亲和性，支持ClientIP、None两个选项
  ports: # 端口信息
    - protocol: TCP 
      port: 3017  # service端口
      targetPort: 5003 # pod端口
      nodePort: 31122 # 主机端口

Service中的service.spec.type类型

bash 复制代码

| 类型         | 含义                                                         |
| ------------ | ------------------------------------------------------------ |
| ClusterIP    | 意味着服务仅在集群内部可用，只能通过集群IP访问。             |
| ExternalName | 意味着服务仅包含一个对外部名称的引用，Kubedns或等价物将返回作为CNAME记录，不会涉及任何容器的暴露或代理。 |
| LoadBalancer | 意味着服务将通过外部负载均衡器（如果云提供商支持的话）进行暴露，除了NodePort类型之外。 |
| NodePort     | 意味着服务将在每个节点的一个端口上进行暴露，除了ClusterIP类型之外。 |

Service中的三类IP地址

bash 复制代码

| IP类型     | 作用                                                         |
| ---------- | ------------------------------------------------------------ |
| Node IP    | 节点IP是Kubernetes集群中每个节点的唯一标识符。它代表了节点的网络接口，用于在集群内部进行通信。节点IP通常是一个私有IP地址范围，用于在集群内部进行通信。节点IP是Service在集群内部提供服务的唯一标识，用于路由流量到指定的Pod。 |
| Pod IP     | Pod IP是Kubernetes中每个Pod的唯一标识符。它代表了Pod的网络接口，用于在集群内部进行通信。Pod IP通常是一个私有IP地址范围，用于在集群内部进行通信。Pod IP是Service在集群内部提供服务的唯一标识，用于路由流量到指定的Pod。 |
| Cluster IP | Cluster IP是Kubernetes集群中Service的IP地址。它代表了Service在集群内部提供的服务，用于在集群内部进行通信。Cluster IP通常是一个私有IP地址范围，用于在集群内部进行通信。Cluster IP是Service在集群内部提供服务的唯一标识，用于路由流量到指定的Pod。 |

综上所述，Kubernetes中的三类IP地址分别是Node IP、Pod IP和Cluster IP。这些IP地址用于在不同网络之间路由流量，以便外部和内部应用程序可以访问Kubernetes集群中的服务和Pod。

四、Service实战案例

实验环境准备

在使用service之前，首先利用Deployment创建出3个pod，注意要为pod设置app=nginx-pod的标签

创建deployment.yaml，内容如下：

bash 复制代码


apiVersion: apps/v1kind: Deployment      metadata:  name: pc-deployment  namespace: devspec:   replicas: 3  selector:    matchLabels:      app: nginx-pod  template:    metadata:      labels:        app: nginx-pod    spec:      containers:      - name: nginx        image: nginx        ports:        - containerPort: 80

bash 复制代码

[root@k8s-master01 ~]# kubectl create -f deployment.yaml
deployment.apps/pc-deployment created

# 查看pod详情
[root@k8s-master01 ~]# kubectl get pods -n dev -o wide --show-labels
NAME                             READY   STATUS    RESTARTS   AGE   IP              NODE           NOMINATED NODE   READINESS GATES   LABELS
pc-deployment-59c564ffb7-8vzp5   1/1     Running   0          89s   172.16.79.83    k8s-worker01   <none>           <none>            app=nginx-pod,pod-template-hash=59c564ffb7
pc-deployment-59c564ffb7-fg2j8   1/1     Running   0          89s   172.16.69.206   k8s-worker02   <none>           <none>            app=nginx-pod,pod-template-hash=59c564ffb7
pc-deployment-59c564ffb7-sprp7   1/1     Running   0          89s   172.16.69.207   k8s-worker02   <none>           <none>            app=nginx-pod,pod-template-hash=59c564ffb7

# 为了方便后面的测试，修改下三台nginx的index.html页面（三台修改的IP地址不一致）
[root@k8s-master01 ~]# kubectl exec -it pc-deployment-59c564ffb7-8vzp5 -n dev -- /bin/sh
root@pc-deployment-59c564ffb7-8vzp5:/# echo "172.16.79.83" > /usr/share/nginx/html/index.html 
[root@k8s-master01 ~]# kubectl -n dev exec -it pc-deployment-59c564ffb7-fg2j8 -- /bin/bash
root@pc-deployment-59c564ffb7-fg2j8:/# echo "172.16.69.206" > /usr/share/nginx/html/index.html
[root@k8s-master01 ~]# kubectl -n dev exec -it pc-deployment-59c564ffb7-sprp7 -- /bin/bash
root@pc-deployment-59c564ffb7-sprp7:/# echo "172.16.69.207" > /usr/share/nginx/html/index.html 
#修改完毕之后，访问测试
[root@k8s-master01 ~]# curl 172.16.79.83
172.16.79.83
[root@k8s-master01 ~]# curl 172.16.69.206
172.16.69.206
[root@k8s-master01 ~]# curl 172.16.69.207
172.16.69.207

4.1 ClusterIP类型的Service

创建service-clusterip.yaml文件

bash 复制代码

apiVersion: v1
kind: Service
metadata:
  name: service-clusterip
  namespace: dev
spec:
  selector:
    app: nginx-pod
  clusterIP: 10.10.97.97 # service的ip地址，如果不写，默认会生成一个
  type: ClusterIP
  ports:
  - port: 80  # Service端口       
    targetPort: 80 # pod端口

bash 复制代码

# 创建service
[root@k8s-master01 ~]# kubectl create -f service-clusterip.yaml
service/service-clusterip created

# 查看service
[root@k8s-master01 ~]# kubectl get svc -n dev 
[root@k8s-master01 ~]# kubectl -n dev get svc
NAME                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service-clusterip   ClusterIP   10.10.97.97   <none>        8001/TCP   10s

# 查看service的详细信息
# 在这里有一个Endpoints列表，里面就是当前service可以负载到的服务入口
[root@k8s-master01 ~]# kubectl describe service -n dev
Name:              service-clusterip
Namespace:         dev
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.10.97.97
IPs:               10.10.97.97
Port:              <unset>  8001/TCP
TargetPort:        80/TCP
Endpoints:         172.16.69.206:80,172.16.69.207:80,172.16.79.83:80
Session Affinity:  None
Events:            <none>

# 查看ipvs的映射规则
[root@k8s-master01 ~]# ipvsadm -Ln
TCP  10.97.97.97:80 rr
  -> 10.10.1.39:80               Masq    1      0          0
  -> 10.10.1.40:80               Masq    1      0          0
  -> 10.10.2.33:80               Masq    1      0          0

# 访问10.10.97.97:8001观察效果

[root@k8s-master01 ~]# curl 10.10.97.97:8001
172.16.79.83
[root@k8s-master01 ~]# curl 10.10.97.97:8001
172.16.69.207
[root@k8s-master01 ~]# curl 10.10.97.97:8001
172.16.69.206

Endpoint解析

Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。
一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说，service和pod之间的联系是通过endpoints实现的。

**负载分发策略**

对Service的访问被分发到了后端的Pod上去，目前kubernetes提供了两种负载分发策略：

如果不定义，默认使用kube-proxy的策略，比如随机、轮询
基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都会转发到固定的一个Pod上

bash 复制代码

# 查看ipvs的映射规则【rr 轮询】
[root@k8s-master01 ~]# ipvsadm -Ln
TCP  10.97.97.97:80 rr
  -> 10.10.1.39:80               Masq    1      0          0
  -> 10.10.1.40:80               Masq    1      0          0
  -> 10.10.2.33:80               Masq    1      0          0

# 循环访问测试
[root@k8s-master01 ~]# while true;do curl 10.97.97.97:80; sleep 5; done;
10.10.1.40
10.10.1.39
10.10.2.33
10.10.1.40
10.10.1.39
10.10.2.33

# 修改分发策略----sessionAffinity:ClientIP

# 查看ipvs规则【persistent 代表持久】
[root@k8s-master01 ~]# ipvsadm -Ln
TCP  10.97.97.97:80 rr persistent 10800
  -> 10.10.1.39:80               Masq    1      0          0
  -> 10.10.1.40:80               Masq    1      0          0
  -> 10.10.2.33:80               Masq    1      0          0

# 循环访问测试
[root@k8s-master01 ~]# while true;do curl 10.97.97.97; sleep 5; done;
10.10.2.33
10.10.2.33
10.10.2.33
  
# 删除service
[root@k8s-master01 ~]# kubectl delete -f service-clusterip.yaml
service "service-clusterip" deleted
[root@k8s-master01 ~]# kubectl delete service service-clusterip -n dev
service "service-clusterip" deleted

4.2 HeadLiness类型的Service

在某些场景中，开发人员可能不想使用Service提供的负载均衡功能，而希望自己来控制负载均衡策略，针对这种情况，kubernetes提供了HeadLiness Service，这类Service不会分配Cluster IP，如果想要访问service，只能通过service的域名进行查询。

创建service-headliness.yaml

bash 复制代码

apiVersion: v1
kind: Service
metadata:
  name: service-headliness
  namespace: dev
spec:
  selector:
    app: nginx-pod
  clusterIP: None # 将clusterIP设置为None，即可创建headliness Service
  type: ClusterIP
  ports:
  - port: 80    
    targetPort: 80

bash 复制代码

# 创建service
[root@k8s-master01 ~]# kubectl apply -f deployment-nginx-headliness.yaml
service/service-headliness created

# 获取service， 发现CLUSTER-IP未分配
[root@k8s-master01 ~]# kubectl -n dev get svc
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-headliness   ClusterIP   None         <none>        80/TCP    10s

# 查看service详情
[root@k8s-master01 ~]# kubectl describe svc -n dev
Name:              service-headliness
Namespace:         dev
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                None
IPs:               None
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         172.16.69.206:80,172.16.69.207:80,172.16.79.83:80
Session Affinity:  None
Events:            <none>


# 查看域名的解析情况
[root@k8s-master01 ~]# kubectl  -n dev exec -it pc-deployment-59c564ffb7-8vzp5 -- /bin/bash 
[root@k8s-master01 ~]# kubectl  -n dev exec -it pc-deployment-59c564ffb7-8vzp5 -- /bin/bash 
root@pc-deployment-59c564ffb7-8vzp5:/#
root@pc-deployment-59c564ffb7-8vzp5:/# cat /etc/resolv.conf 
search dev.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.10.0.10
options ndots:5

[root@k8s-master01 ~]# dig @10.96.0.10 service-headliness.dev.svc.cluster.local
service-headliness.dev.svc.cluster.local. 30 IN	A 172.16.79.83
service-headliness.dev.svc.cluster.local. 30 IN	A 172.16.69.206
service-headliness.dev.svc.cluster.local. 30 IN	A 172.16.69.207

#删除service
[root@k8s-master01 ~]# kubectl delete -n dev svc service-headliness
service "service-headliness" deleted

4.3 NodePort类型的Service

在之前的样例中，创建的Service的ip地址只有集群内部才可以访问，如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是将service的端口映射到Node的一个端口上，然后就可以通过NodeIp:NodePort来访问service了。

创建service-nodeport.yaml

bash 复制代码

apiVersion: v1
kind: Service
metadata:
  name: service-nodeport
  namespace: dev
spec:
  selector:
    app: nginx-pod
  type: NodePort # service类型
  ports:
  - port: 80
    nodePort: 30002 # 指定绑定的node的端口(默认的取值范围是：30000-32767), 如果不指定，会默认分配
    targetPort: 80

bash 复制代码

# 创建service
[root@k8s-master01 ~]# kubectl apply -f deployment-nginx-nodeport.yaml 
service/service-nodeport created


# 查看service
[root@k8s-master01 ~]# kubectl -n dev get svc -o wide 
NAME               TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE   SELECTOR
service-nodeport   NodePort   10.10.25.194   <none>        80:30002/TCP   29s   app=nginx-pod

# 接下来可以通过电脑主机的浏览器去访问集群中任意一个nodeip的30002端口，即可访问到pod
#删除service
[root@k8s-master01 ~]# kubectl delete -n dev svc service-nodeport 
service "service-nodeport" deleted

bash 复制代码

### 4.4 LoadBalancer类型的Service

LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部环境支持的，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。

bash 复制代码

### 4.5 ExternalName类型的Service

ExternalName类型的Service用于引入集群外部的服务，它通过externalName属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部的服务了。

创建service-externalname.yaml

bash 复制代码

apiVersion: v1kind: Servicemetadata:  name: service-externalname  namespace: devspec:  type: ExternalName # service类型  externalName: www.baidu.com

bash 复制代码


# 创建service[root@k8s-master01 ~]# kubectl apply -f deployment-nginx-externalname.yamlservice/service-externalname created[root@k8s-master01 ~]# kubectl -n dev get svc -o wide NAME                   TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)   AGE   SELECTORservice-externalname   ExternalName   <none>       www.baidu.com   <none>    7s    <none>[root@k8s-master01 ~]# kubectl describe -n dev svcName:              service-externalnameNamespace:         devLabels:            <none>Annotations:       <none>Selector:          <none>Type:              ExternalNameIP Families:       <none>IP:                IPs:               <none>External Name:     www.baidu.comSession Affinity:  NoneEvents:            <none># 域名解析[root@k8s-master01 ~]# dig @10.10.0.10 service-externalname.dev.svc.cluster.local; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.15 <<>> @10.10.0.10 service-externalname.dev.svc.cluster.local; (1 server found);; global options: +cmd;; Got answer:;; WARNING: .local is reserved for Multicast DNS;; You are currently testing what happens when an mDNS query is leaked to DNS;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33580;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;service-externalname.dev.svc.cluster.local. IN A;; ANSWER SECTION:service-externalname.dev.svc.cluster.local. 5 IN CNAME www.baidu.com.www.baidu.com.      5   IN  CNAME   www.a.shifen.com.www.a.shifen.com.   5   IN  A   39.156.66.18www.a.shifen.com.   5   IN  A   39.156.66.14;; Query time: 127 msec;; SERVER: 10.10.0.10#53(10.10.0.10);; WHEN: 四 1月 25 15:04:37 CST 2024;; MSG SIZE  rcvd: 247