Service · XB 现场笔记

Kubernetes Service 为 Pod 提供稳定入口

Mon, 23 Aug 2027 00:00:00 +0000

既然 Pod 会重建，就很难记住它的地址。Service 在这组 Pod 前面固定一个名字，让调用方不因 Pod 更换而受影响。

一个地址，一组 Pod

普通 ClusterIP Service 在对象存续期间保持虚拟地址，集群 DNS 提供发现名称。调用方可以依赖这个名称，而后端可互换的 Pod 逐渐被替换。这把稳定的客户端契约与单个后端生命周期分开，不需要每替换一个副本就推送客户端配置。但稳定身份仍有明确范围，不能扩写成全部网络行为都不会变化。

无头和 ExternalName Service 具有不同发现行为，无选择器 Service 则可以使用单独管理的 EndpointSlice。虚拟地址稳定的结论应限于普通情形。Deployment 管理工作负载，本身不是发起网络连接的客户端；真正使用发现结果的是应用、网关和其他组件。审阅调用关系时，应区分资源控制与请求转发这两层。

选择规则决定由谁响应

带选择器的 Service 识别本命名空间里匹配的 Pod，EndpointSlice 控制器异步协调地址和条件。就绪通常决定普通流量资格，但未就绪端点可能继续存在，只是就绪条件为假，不一定从 API 对象中彻底删除。列表成员、成员条件和最终是否选择它，是需要分别观察的状态。

选择器不会授权网络访问，标签匹配也不证明 targetPort 正确或应用能返回有用响应。publishNotReadyAddresses 与终止中端点处理还会影响解释。需要先核对选中集合及条件，再检查实际数据路径；这些观察相关，却不能互相替代。未被一个 Service 选中的 Pod，也可能通过其他入口被访问，不能把发现名单当成隔离策略。

流量总给当前匹配的

扩缩容和替换可以在同一名称背后进行，但名称不保证请求连续。已经连接到某个后端的会话，可能因后端终止而失败；更新传播到代理需要时间，没有可用端点时，即使 DNS 仍能解析也不能服务。稳定地址并不负责迁移已建立连接，更不会自动补足被删掉的副本容量。

应联合规划就绪、更新容量、终止排空和客户端重试；非幂等操作还需要应用层保证重复请求安全。替换期间要实际观察可用性，不能宣称选择器足够精确就没有任何中断。下方本地模型只演示集合选择，不验证传播时间和传输行为，也不证明一次集合替换就等于完成无损发布。

稳定名字是对调用方的承诺

应把 Service 名称当成受支持的发现接口，而不是缓存某次看到的 Pod IP。使用普通 Service VIP 的调用方，不需要每次后端变化都重新解析，但永远只在启动解析一次，会在 Service 删除重建、地址变化时失败。应按客户端库的行为处理解析与连接生命周期，不能把后端稳定抽象误读成无限缓存许可。

无头服务的答案可能包含变化的端点地址，因此调用方需要自己的发现与均衡行为。要测试库如何刷新 DNS、替换连接和处理过期结果。稳定是带生命周期条件的接口契约，不是关闭刷新或忽略失败的理由；名称继续存在、地址仍有效、连接仍可用，也不是完全相同的三个判断。

坏掉的样子

最安静的故障是选择器谁也选不中。比如把 app: web 写成 app: webs,或者 Deployment 不再给 Pod 打预期标签,Service 的端点集合就会变成空。此时集群 IP 与 DNS 名字依然能解析,故障表现为连接被拒绝或超时,而不是名字不存在。当 Service 能解析却送不出流量时,先看它的端点集合:空的可用集合可能来自标签、就绪、Pod 地址或协调进度，本身也不能排除另有网络问题。

第二个常见陷阱是顺手写成的无头 Service。一旦设置 clusterIP: None,虚拟 IP 就不存在了,DNS 直接返回不断变化的 Pod 地址,每个客户端都要自己做负载均衡。为单一稳定入口编写的代码,突然要面对多个漂移地址,重试不均、连接复用失效都会跟着来。只有调用方明确想要服务发现时才用无头形式,不要把它当成默认写法。

端口配错是从另一侧打破承诺。Service 映射到错误的容器 targetPort，就无法把请求交给预期监听者;手选一个已经分配的 NodePort 会让 API 操作失败。ClientIP 亲和可能把共享来源地址的客户端集中到同一后端，但不表示永久绑定已经移除的端点，也不表示每次后端失败都会变成全局中断。应根据应用需求选择亲和，并单独验证故障切换。

快速验证

把下面程序保存到临时工作目录的 service_endpoints.py,运行 python3 service_endpoints.py。它只用字典模拟 Service 端点收敛,不修改进程之外的任何东西:一个函数根据选择器、Pod 标签与就绪状态推导端点集合,四个场景依次演练它,其中故意留空的选择器是反例,用于证明空选择器必须告警,而不是悄悄匹配到奇怪的结果。

"""用选择器加就绪状态模拟 Service 端点收敛。"""

PODS = [
 {"name": "web-1", "labels": {"app": "web"}, "ready": True},
 {"name": "web-2", "labels": {"app": "web"}, "ready": True},
 {"name": "web-3", "labels": {"app": "web"}, "ready": False},
 {"name": "worker-1", "labels": {"app": "worker"}, "ready": True},
]


def select_endpoints(pods, selector):
 """推导端点集合；空选择器告警而不是默默匹配。"""
 if not selector:
 return [], "warning: empty selector matches nothing"
 matched = sorted(
 pod["name"]
 for pod in pods
 if pod.get("ready")
 and all(pod.get("labels", {}).get(key) == value for key, value in selector.items())
 )
 return matched, ""


def check(condition, message):
 if not condition:
 raise AssertionError(message)


def main():
 endpoints, warning = select_endpoints(PODS, {"app": "web"})
 check(endpoints == ["web-1", "web-2"], "就绪的 web Pod 应组成集合")
 check(warning == "", "精确的选择器不应告警")
 print("steady state:", endpoints)

 rolling = [dict(pod, ready=True) if pod["name"] == "web-3" else pod for pod in PODS]
 rolling = [pod for pod in rolling if pod["name"] != "web-1"]
 endpoints, _ = select_endpoints(rolling, {"app": "web"})
 check(endpoints == ["web-2", "web-3"], "滚动应以新就绪 Pod 替换旧 Pod")
 print("after rollover:", endpoints)

 endpoints, _ = select_endpoints(PODS, {"app": "web", "track": "stable"})
 check(endpoints == [], "过窄的选择器应收敛为空，而不是报错")
 print("over-narrow selector:", endpoints)

 endpoints, warning = select_endpoints(PODS, {})
 check(endpoints == [] and "empty selector" in warning, "空选择器必须大声告警")
 print("empty selector:", repr(warning))

 print("PASS: four convergences; readiness-gated selection, rollover, and empty warning hold")


if __name__ == "__main__":
 main()

四个场景验证的是这个本地选择模型:稳态时两个就绪的 web Pod 在集合里,未就绪者被挡在外面;滚动时选择器不变,集合从一个就绪 Pod 换成另一个;过窄的选择器会清楚地收敛为空。空选择器是反例:它大声告警,而不是悄悄匹配全部或悄悄返回空。本轮在 Linux、Python 3.12.14 上运行两种语言模型通过。空选择器告警是程序自己的保护；Kubernetes 可以通过显式管理的 EndpointSlice 支持无选择器 Service。

这个模拟只验证标签加就绪的收敛逻辑,不实现 kube-proxy、集群 DNS 与真实探针时序,也不覆盖生产环境的端口冲突。发布前还要对照 Pod 标签与就绪状态检查真实端点集合,并用真正的 Service 名字在两个语言环境里各走一遍查询。

来源

Kubernetes：Services，Service 抽象，已核验 2026-10-15。
Kubernetes：Pods，Service 所选择的 Pod，已核验 2026-10-15。
Kubernetes：Deployments，管理 Pod 集合，已核验 2026-10-15。
Primary reference，端点条件与就绪例外，已核验 2026-10-15。
Primary reference，普通与无头 DNS 答案，已核验 2026-10-15。

NodePort 通过符合配置的节点地址开放 Service

Tue, 11 May 2027 00:00:00 +0000

NodePort 类型的 Service 分配一个集群范围的端口，并通过符合配置的节点地址转发流量。它适用于外部负载均衡、开发环境及有明确用途的服务暴露，但不保证每台机器的每个地址都能访问，也不保证每台节点都有一个普通应用监听套接字。路由、防火墙、代理实现与流量策略仍然决定真实访问路径，不能从 Service 类型推断全部网络条件。

一次分配，多种转发路径

默认分配范围为 30000–32767，管理员可以配置其他范围。请求指定 nodePort 时，只有分配与校验允许才会成功；端口冲突会拒绝 API 事务，通常不是先创建一个对象，再悄悄留下不可用端口。应分别核对命令退出状态与实际保存的对象，不能把创建失败解释成运行期网络故障。

Service port、targetPort 与 nodePort 各有职责：前者是虚拟服务入口，中间值指定后端端口，最后一个是节点侧入口。多端口 Service 可以占用多个号码。LoadBalancer 类型也可能分配 NodePort，除非配置与实现允许省略。因此，仅统计类型为 NodePort 的对象，会漏掉地址池的部分实际使用者，第一端口也不代表整份清单。

转发可能由 iptables、IPVS、nftables 或其他实现完成。规则可以引导数据包，而不需要普通用户态程序在该端口接收连接。所以，套接字列表不能证明 NodePort 数据路径健康，也不能凭列表为空宣布服务失效。节点地址筛选同样重要：主地址可达，不代表次要地址或回环地址具有相同行为，具体范围要看代理配置。

流量策略改变候选端点

externalTrafficPolicy 为 Cluster 时，可以选择其他节点上的合适端点。常见 kube-proxy 路径可能执行源地址转换，因此不能假定后端一定看到最初客户端地址。Local 则为外部流量选择本地合适端点，并在这段路径保留源地址。但上游代理或负载均衡可能已经改写过来源，Local 不会自动恢复之前丢失的信息。

没有合适本地端点的节点，无法处理普通 Local 策略流量。外部均衡必须考虑副本分布，不能长期平均发送到全部节点，再期待平台补回缺失的本地副本。终止中端点的处理和代理版本还有额外细节。单副本、三节点只能说明一种放置场景，不能替完整可用性模型，更不能省略真实数据路径测试。

暴露范围取决于实际后端

NodePort 本身提供传输层转发，不提供 HTTP 授权或 TLS 终止。如果它直接选择应用 Pod，确实可能绕过 Ingress 的认证、路由和 WAF；如果选择的就是 Ingress 控制器，那么经过该端口的流量并没有天然绕开控制器。必须先画清真实链路，再判断每项安全控制是否仍处于请求路径中。

应限制哪些调用方能到达节点地址，并记录暴露目的与责任人。NodePort 可以是长期受支持的基础设施组成部分，随意设定到期日不能代替访问控制与监控。节点具有公网地址，既不证明端口已经开放，也不证明应用已经受到保护。检查对象配置与检查外部可达性，是需要分别完成的事情。

坏掉的样子

端口分配失败、没有端点与节点不可达，是不同阶段的问题。空端点集合可能导致拒绝或丢弃，具体取决于实现与策略。仅凭超时或拒绝，不能锁定端口冲突；HTTP 200 也只有在应用明确提供该响应时才是正确预期。后端返回其他业务状态，并不自动意味着 NodePort 失效。

修改暴露方式之前，应核对选择器范围、就绪状态、targetPort、地址筛选、防火墙及流量策略。当前端点条件应优先查看 EndpointSlice；旧 Endpoints API 已弃用，而且后端很多时可能截断。Service 对象看起来正常，并不能认证从调用方到应用的整条网络路径。

快速验证

以下保留的诊断命令要求明确选择临时集群，并准备 kubectl、jq 与 Linux 网络工具。本轮没有重新执行。最后一条请求还假设终端位于目标节点，且第一个地址属于允许的 NodePort 地址，运行前必须核实。它们查看状态并发起一次 HTTP 请求，不构成完整集成测试，也不应该直接复制到未知上下文。

kubectl get svc web -o jsonpath='{.spec.type} {.spec.ports[0].nodePort}{"\n"}'
kubectl get endpoints web
kubectl get svc -A -o json | jq -r '.items[] | select(.spec.type=="NodePort") | "\(.spec.ports[0].nodePort) \(.metadata.namespace)/\(.metadata.name)"' | sort -n | uniq -D -w5
ss -lnt | grep -E ':3[0-9]{4}\b'
curl -sS -o /dev/null -w '%{http_code}\n' "http://$(hostname -I | awk '{print $1}'):$(kubectl get svc web -o jsonpath='{.spec.ports[0].nodePort}')/"

第一条只显示首个端口。重复检查只覆盖 NodePort 类型的首端口，正常 API 分配下本就应为空，不能用于完整容量审计。套接字过滤范围为 30000–39999，无法识别代理转发健康，也没有显示进程归属。需要另行比较 EndpointSlice，并在获准测试网络中对明确节点地址分别测试 Cluster 与 Local，保留响应、端点和源地址证据。

来源

Kubernetes Service，NodePort 类型、30000-32767 默认范围与集群级端口分配，已核验 2026-10-15。
Virtual IPs and Service Proxies，kube-proxy 的 iptables/IPVS 规则编程与 externalTrafficPolicy，已核验 2026-10-15。
Using Source IP，NodePort 的 SNAT 与客户端地址后果，已核验 2026-10-15。

Service 给一组 Pod 一个稳定的虚拟地址

Tue, 09 Feb 2027 00:00:00 +0000

选择器让 Service 从一段固定列表变成动态视图：新增移除都在后台完成，Pod 重启时客户端无需改任何配置。

先声明，再分配地址

普通 ClusterIP Service 在对象存续期间提供虚拟地址，并在集群 DNS 支持下提供稳定发现名称。带选择器的 Service 还声明本命名空间中哪些 Pod 是预期后端。其他形态不同：无头服务不分配虚拟 IP，ExternalName 使用 DNS 间接引用，无选择器服务可以配合单独管理的 EndpointSlice。不能把每种 Service 都套进同一种分配流程。

地址稳定仅限 Service 对象存续期间，不是某个名称出现之后永远占用同一个地址。删除重建可能得到新地址。客户端应遵守约定的发现方式，并适当重新解析，而不是把抄下来的 ClusterIP 当成永久基础设施身份。这层稳定性主要隔离后端更替，不能消除对象本身重建和发现系统变化带来的影响。

选择器就是实时成员

EndpointSlice 控制器异步协调匹配 Pod 与端点条件。未就绪 Pod 可以继续出现在对象中，只是 ready 为 false，并非一定从所有端点对象里消失。消费者根据这些条件选择路由目标。publishNotReadyAddresses 会改变普通就绪解释，终止中端点又有额外处理细节，不能仅凭列表存在地址就断言后端应接收普通流量。

标签一致也不能证明请求健康。端口错误、不适当探针或过期数据路径仍然可能导致失败。应同时检查预期选择器与实际 EndpointSlice，再验证应用行为。自动协调减少手工维护后端名单，但不承诺瞬间更新，也不会消除所有漂移。控制面对象、节点转发和客户端连接各有自己的状态及更新时序。

Pod 变了地址依旧稳定

稳定目的地允许替换后端，而不必向调用方逐个公布 Pod IP，但不保证每次请求都不中断。已有连接可能仍关联旧后端，新连接依赖已经收敛的路由状态；没有可用端点的 Service 也不能制造缺失容量。不能因为名称没有改变，就认为所有连接已经自动迁移到新进程。

就绪、优雅终止、发布期间的可用容量和客户端重试策略，仍是可用性设计的一部分。域名在发布后继续存在是一项属性，请求成功和恢复有界是另外的属性，需要分别观察。下面的分配练习刻意不测试这些行为；它解释的是地址台账，不应把输出当成真实网络已经验证的证据。

坏掉的样子

地址池是有限的，耗尽是最字面的失败。具有虚拟 IP 的 Service 按配置的地址族从服务地址池占用地址，如果网段当初划得很小，或者堆满了无人使用的旧 Service，新 Service 就会在创建时直接报分配错误。此时 Pod 本身看起来一切正常，只有 Service 始终无法就绪。看到 failed to allocate IP 要先当容量账来算：删除不用的对象前先核对归属，再按实际集群版本规划受支持的地址池扩展，不能把扩容当成随意修改网段的操作。

第二类故障是把无头与普通 Service 混用。写下 clusterIP: None 就意味着主动放弃虚拟地址，域名解析直接返回一组不断变化的 Pod 地址，而不是唯一的虚拟入口。为单一稳定入口编写的客户端，会突然面对多个漂移地址，还得自己做均衡与重试。反过来也会坏事：本来指望按域名逐个发现 Pod 的代码，在有人把 Service 重建成普通类型之后，会一直打到同一个虚拟地址上。由于 clusterIP 基本不可改，切换形态只能删除重建，而调用方所有写死的假设都会在那一刻断裂。

最后两类故障藏在接口之下。不同 kube-proxy 模式实现同一个虚拟地址的方式完全不同：iptables 靠追加规则链，IPVS 靠写入虚拟服务表，代理卡住或正在重启时，地址能解析、流量却黑洞，直到规则重新同步才会恢复。还有人喜欢把 ClusterIP 抄进配置文件或环境变量，这等于冻结了一个控制面随时可以收回重分的值：虚拟地址只在 Service 对象存续期间稳定，删掉重建就可能把旧号码发给别人。调用方必须用域名、用时再解析，且虚拟地址用于内部服务路由，外部是否可达取决于明确网络配置。

快速验证

把下面程序保存到临时工作目录的 clusterip_pool.py，运行 python3 clusterip_pool.py。它只用标准库模拟一个迷你分配器，管理 10.96.0.0/29 网段并预留首地址，进程之外什么都不改：一个分配类负责发号、拒绝重复与越界、允许无头服务绕过地址池、回收后复用，五个场景逐条断言这些规则，其中故意重复申请是反例，证明冲突必须报错而非悄悄共享。

"""用小型服务网段模拟 ClusterIP 分配。"""

import ipaddress


class ClusterIPPool:
 """分配虚拟地址；无头 Service 绕过地址池。"""

 def __init__(self, cidr, reserved=1):
 network = ipaddress.ip_network(cidr)
 hosts = list(network.hosts())
 self._all = set(hosts)
 self._reserved = set(hosts[:reserved])
 self.free = sorted(set(hosts) - self._reserved)
 self.allocated = {}

 def allocate(self, service, requested=None, headless=False):
 if headless:
 return None
 if service in self.allocated:
 raise ValueError(f"{service} 已持有 {self.allocated[service]}")
 if requested is not None:
 ip = ipaddress.ip_address(requested)
 if ip in self._reserved or ip not in self._all:
 raise ValueError(f"{requested} 超出可分配范围")
 if ip not in self.free:
 raise ValueError(f"{requested} 已被占用")
 self.free.remove(ip)
 self.allocated[service] = ip
 return str(ip)
 if not self.free:
 raise RuntimeError("服务网段耗尽：没有可用 ClusterIP")
 ip = self.free.pop(0)
 self.allocated[service] = ip
 return str(ip)

 def release(self, service):
 ip = self.allocated.pop(service, None)
 if ip is None:
 raise ValueError(f"{service} 没有可释放的地址")
 self.free.append(ip)
 self.free.sort()
 return str(ip)


def check(condition, message):
 if not condition:
 raise AssertionError(message)


def main():
 pool = ClusterIPPool("10.96.0.0/29", reserved=1)
 web = pool.allocate("web")
 api = pool.allocate("api", requested="10.96.0.5")
 check(web != api, "顺序创建的服务必须拿到不同地址")
 print("allocated:", web, api)

 try:
 pool.allocate("worker", requested="10.96.0.5")
 raise SystemExit("冲突被悄悄共享了")
 except ValueError as exc:
 print("conflict rejected:", exc)

 try:
 pool.allocate("evil", requested="10.99.0.1")
 raise SystemExit("越界申请被接受了")
 except ValueError as exc:
 print("out-of-range rejected:", exc)

 headless = pool.allocate("db-headless", headless=True)
 check(headless is None, "无头服务必须绕过地址池")
 check(len(pool.allocated) == 2, "无头服务不得占用地址池")
 print("headless bypass: None")

 freed = pool.release("web")
 worker = pool.allocate("worker")
 check(worker == freed, "释放的地址必须可复用")
 print("reused:", freed, "-> worker")

 pool.allocate("extra-1")
 pool.allocate("extra-2")
 pool.allocate("extra-3")
 try:
 pool.allocate("overflow")
 raise SystemExit("耗尽没有报错")
 except RuntimeError as exc:
 print("exhaustion reported:", exc)

 print("PASS: allocation, conflict rejection, release reuse, and exhaustion hold")


if __name__ == "__main__":
 main()

运行结果和健康分配器完全一致：顺序创建拿到不同地址，指定地址的申请会钉住想要的值，重复申请被明确拒绝而不是共享。释放一个服务后旧地址可以被后人复用，占满最后空位则证明耗尽只报错，不回收在用地址。本轮在 Linux、Python 3.12.14 上运行两种语言模型通过。首主机地址预留与分配顺序是教学选择，不是 Kubernetes 分配器的通用保证。

这个模拟只验证分配台账，不实现接口服务、持久存储与代理编程，迷你的 /29 也只是真实服务网段的缩影。发布前还要核对真实服务网段与已分配地址，到节点上检查代理规则，并用真实域名在集群内复测解析。

来源

Kubernetes Service，说明 Service 语义，已核验 2026-10-15。
Virtual IPs and Service Proxies，说明 ClusterIP 分配与 kube-proxy 模式，已核验 2026-10-15。
Primary reference，端点条件与异步发现，已核验 2026-10-15。

Service · XB 现场笔记

Kubernetes Service 为 Pod 提供稳定入口

一个地址，一组 Pod

选择规则决定由谁响应

流量总给当前匹配的

稳定名字是对调用方的承诺

坏掉的样子

快速验证

延伸阅读

来源

NodePort 通过符合配置的节点地址开放 Service

一次分配，多种转发路径

流量策略改变候选端点

暴露范围取决于实际后端

坏掉的样子

快速验证

来源

Service 给一组 Pod 一个稳定的虚拟地址

先声明，再分配地址

选择器就是实时成员

Pod 变了地址依旧稳定

坏掉的样子

快速验证

延伸阅读

来源