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。
• 只能在集群内部访问。

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

NodePort

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

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 地址。

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

ExternalName

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

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：

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

会话保持配置

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

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。

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（错误，多了下划线）

修正方法：

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

组件交互流程

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

常见排查步骤

检查 Service 的 Endpoints 是否为空：

kubectl get endpoints <service-name>

验证 Pod 的 labels 是否匹配：

kubectl get pods --show-labels

检查 Service 的 selector 配置：

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 模式为大规模集群提供最优性能和扩展性。

Kube-proxy userspace 模式工作原理

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

组件角色说明

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

Userspace 模式流程

1. 服务创建
   用户通过apiserver创建 Service，定义selector为app=MyApp和port: 9376。kube-proxy监听此事件。

2. 规则配置
   kube-proxy在节点上为 Service 的clusterIP创建 iptables 规则，将流量重定向到kube-proxy监听的随机端口（用户空间）。

3. 流量转发
   当客户端访问clusterIP:9376时：

   • iptables 拦截流量并转发到kube-proxy的代理端口。
   • kube-proxy在用户空间通过轮询（Round Robin）等算法选择后端 Pod（如Backend Pod 1）。
   • 代理将请求转发到目标 Pod 的9376端口。

4. 后端维护
   kube-proxy持续监听 Pod 变化（如扩缩容），动态更新代理规则。

Userspace 模式特点

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

对比其他模式

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

示例配置

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

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 服务的负载均衡和流量转发。以下是其核心机制：

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

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

3. iptables 规则生成
   kube-proxy 为每个 Service 创建两条核心链：

   • KUBE-SERVICES：作为入口链，匹配目标为 ClusterIP 的流量。
   • KUBE-SVC-XXXXX：服务专属链，通过概率跳转（probability）实现负载均衡，将流量分发到 Pod 专属链（如KUBE-SEP-YYYYY）。

4. 流量转发流程
   当客户端（Client）访问 ClusterIP 时，数据包经过以下规则处理：

   • 命中KUBE-SERVICES链，跳转到对应服务的KUBE-SVC-XXXXX链。
   • 通过随机算法选择一条KUBE-SEP-YYYYY链，将目标 IP 和端口替换为 Pod 的 IP 和端口（DNAT）。
   • 最终流量被路由到具体的 Pod（如 Backend Pod 1）。

关键 iptables 规则示例

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

-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 模式的工作流程

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

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

3. 负载均衡算法
   IPVS 支持多种负载均衡算法，例如：

   • rr（轮询）
   • lc（最少连接）
   • sh（源地址哈希）
   • dh（目标地址哈希）

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

IPVS 模式的配置示例

查看节点的 IPVS 规则：

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"：

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

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

modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh

# 此模式必须安装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资源清单

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 #外部负载均衡器的主机名

资源清单案例

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类型

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

Service中的三类IP地址

| 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，内容如下：

​ 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 ​

[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文件

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端口

# 创建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上

# 查看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

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

# 创建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

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

# 创建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

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

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

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

​ # 创建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​ ​