k8sday11服务发现（2/2）-优快云博客

本来打算是直接进行Ingress的学习，但是考虑到昨天Service的学习只是一知半解，很多流程没有很清晰，以及部分概念没有了解的很到位，所以打算在进行Ingress的学习之前进行我的个人理解和补充

Service个人理解+补充

1、加深概念理解

①、为什么需要Service（基本原理）

在k8s集群中，我们可以通过Pod的IP进行服务的访问，但是由于Pod频繁的创建和删除，导致Pod的IP并不固定，容易变化，这就会给要使用我们服务的用户带来不方便，用户无法通过固定的IP进行我们服务的访问。k8s为了解决这个问题才引入的Service资源类型，Service会整合多个Pod，给这些Pod提供一个统一的、固定的IP地址，方便之后对这些Pod上面部署的服务的访问，而这个IP地址在Service的生命周期内是不变的，相当于给这些Pod提供了一个固定入口，用户不再需要访问Pod的IP，而是访问这个固定的入口（Service的IP）。

精简总结：为了给用户提供一个固定IP入口访问Pod内部服务

②、Service 是“虚拟入口”（核心原理）

Service只是一个概念，真正起作用的是kube-proxy进程。当我们创建了Service进程时，APIServer会向etcd存储写入刚刚你创建的Service的信息，而运行在每个Node节点上的kube-proxy，当监控到了Service和Endpoint的信息变化，就会将最新的Service信息转换为对应的访问规则。该生成的规则会在所有节点（主节点+Node副节点）生成。

精简总结：监控到了Service和Endpoint的信息变化，kube-proxy就会将最新的Service信息转换为对应的访问规则

③、Service选择器匹配

表面上看是 Service 选 Pod，实质上是 kube-proxy 根据标签选择器生成的 EndpointSlice，再把它变成内核里的负载均衡规则，最终由内核按规则加上LB算法策略进行选 Pod 转发。

精简总结：Service通过Selector和Pod标签匹配，其实是kube-proxy进行了相应规则生成

2、补充知识

①、何为访问规则（kube-proxy的工作模式）

维度	userspace（已废弃）	iptables（默认）	ipvs（推荐生产）	nftables（未来主流）
内核依赖	任意	2.4+ 默认	需加载 ip_vs* 模块	≥5.13，需 nftables
kube-proxy 担任的真实身份	用户态四层负载均衡器	内核 NAT 规则的“安装与维护者”	IPVS 调度器的“配置器 + 兜底 iptables 安装者”	nft set & nft rule 的“安装与维护者”
算法	轮询	随机	rr/wrr/lc/wlc/sh/dh…	随机（可扩展）
复杂度	O(n) 用户态	O(n) 规则链	O(1) hash 表	O(1) nft set
规模拐点	<50 服务就卡	1000 服务后 CPU↑	1 万服务仍平稳	同 ipvs 或更好
延迟/CPU	高	中	低	低
热更新	慢	全链刷新	增量更新	增量更新
与 NetworkPolicy 兼容性	差	好	需确认 CNI 支持	需确认 CNI 支持
kube-proxy 配置	无需	默认	`mode: ipvs`	`mode: nftables`
备注	仅历史兼容	1.30 仍是默认	生产>100 节点必开	1.33 起 stable

总结：

userspace：用户发送请求到Cluster IP后经过iptables规则重新定向给kube-proxy，由kube-proxy充当一个负载均衡器，经过LB算法选择一个Pod，与之建立连接将请求发给Pod。（效率低）

iptables：用户发送请求到Cluster IP后经过iptables规则选择一个Pod，与之建立连接将请求发给Pod。kube-proxy只是用来生成iptables规则。（无灵活LB算法，当指向的Pod不可以时不可重试）

ipvs：用户发送请求到Cluster IP后经过iptables规则和LB算法选择一个Pod，与之建立连接将请求发给Pod。kube-proxy只是用来生成ipvs规则。（有灵活LB算法，效率高）

要使用ipvs模式，需安装或加载并单独手动开启ipvs内核模块，否则默认是iptables模式

nftables：用户发送请求到Cluster IP后经过 nftables DNAT 规则（哈希查表）和LB算法选择一个Pod，与之建立连接将请求发给Pod。kube-proxy是用来写 nftables 规则 + set/映射。（无全局锁）

要安装特殊插件，kube-proxy版本 1.33 起默认启用 nftables 模式，通过 --proxy-mode=nftables 显式切换，Service 数量破千或节点上百时才有明显优化感觉。

②、加载ipvs内核

IPVS 已经随主流 Linux 内核主线发布，通常不需要重新编译内核，只要加载对应模块即可（99% 的现代发行版默认已编译内核带 IPVS）。如果不确定，可以跟着以下步骤加载内核：（我只提供在WSL2的内核加载哈，如果是其他版本，可以问AI看看其他的检测方法）

Ⅰ、确认当前内核到底有没有 IPVS

  # 看内核编译选项（适用于 WSL2）
  zcat /proc/config.gz | grep -i 'IP_VS'
  
  # 输出类似效果即WSL2 内核已经完整编译了 IPVS 支持
  # CONFIG_IP_VS=m
  # CONFIG_IP_VS_IPV6=y
  # CONFIG_IP_VS_DEBUG=y
  # CONFIG_IP_VS_TAB_BITS=12
  # CONFIG_IP_VS_PROTO_TCP=y等等