第一次看 Kubernetes 网络时，很容易被一堆 IP 名词绕进去：Pod IP、ClusterIP、Node IP、Ingress、VPC、容器网段。其实先别急着背定义，先问一个问题：这个服务是给集群内部访问，给同一个 VPC 访问，还是要暴露到公网或办公网络？
只要把访问范围分清楚，Kubernetes 里的 Pod、Service、ClusterIP、NodeIP、Ingress 就顺了。
先分清集群、节点和 Pod
可以先这样理解：
- 集群：一组由 Kubernetes 统一管理的机器和资源。
- Node：集群里的工作节点，通常可以理解成承载容器的机器。
- Pod：Kubernetes 调度的最小单元，里面跑一个或多个容器。
- Service：给一组 Pod 提供稳定访问入口和负载均衡。
原 note 里写“node 就是集群可以这么认为”，这句话更适合作为初学时的粗略印象。严格一点说，Node 不是集群本身，而是集群里的节点；多个 Node 加上控制面组件，才组成一个 Kubernetes 集群。
Pod 是会变化的。它可能重建、迁移、扩缩容，Pod IP 也可能变。所以业务之间如果直接记 Pod IP，后面很容易不稳定。Service 的价值，就是给这些变化中的 Pod 一个稳定入口。
Service 解决的是稳定入口
一个服务通常会有多个 Pod 副本，比如订单服务跑 3 个 Pod。调用方不应该关心每个 Pod 的 IP，也不应该自己维护这 3 个地址。
Service 会根据 selector 找到后面的一组 Pod，并提供一个稳定地址。调用方访问 Service，流量再被转发到具体 Pod。
可以把关系记成：
调用方 -> Service -> 多个 Pod 副本这就是 Kubernetes 里最常见的服务访问模型。Pod 负责运行，Service 负责提供稳定入口和负载均衡。
ClusterIP 只适合集群内部
ClusterIP 是 Service 最常见的类型。它是 Kubernetes 在集群内部提供的虚拟 IP，只适合集群内部访问。
典型场景：
- 同一个集群里的后端服务互相调用。
- 微服务之间通过服务名访问。
- 生产者、消费者、配置中心都部署在集群内。
比如 Dubbo 或普通 HTTP 服务都在同一个 Kubernetes 集群里，这种情况下通常不需要暴露到外部。只要服务之间可以通过内部 Service 或注册中心找到对方，就能完成通信。
ClusterIP 的重点是“内部稳定”。它不是给公网访问用的，也不是给办公网络直接访问用的。
NodeIP 是节点机器的真实地址
NodeIP 指的是 Kubernetes 节点宿主机的真实 IP。它通常属于 VPC 网络里的一台机器。
如果集群外部但同 VPC 的服务要访问 Kubernetes 内的服务，就要考虑节点网络、负载均衡或其他入口方案。这里不要混淆两件事：
- Pod IP：容器网络里的地址，跟 Pod 生命周期强相关。
- Node IP：节点机器的地址，更接近传统服务器 IP。
在云厂商环境里，节点通常在某个 VPC 里。同一个 VPC 内的资源一般可以互通，不同 VPC 或办公网络要访问，就需要 VPN、专线、公网 IP、网关或域名映射等手段。
Ingress 适合 HTTP 入口
Ingress 更适合处理 HTTP/HTTPS 入口流量，比如根据域名、路径把请求转发到不同 Service。
常见访问链路可以理解成：
浏览器或外部调用方 -> Ingress -> Service -> PodIngress 不等于 Service，它更像 HTTP 入口规则。实际落地时还需要 Ingress Controller，例如 Nginx Ingress Controller 或云厂商提供的控制器。
如果只是集群内服务互相调用，一般不需要 Ingress。如果要对外提供 Web API、管理后台、前端页面，Ingress 就比较常见。
VPC 和容器网段别混在一起
云上 Kubernetes 经常会同时出现 VPC 网段、节点网段、容器网段、Service 网段。初看很乱，但可以按层次拆开：
| 网络对象 | 作用 |
| — | — |
| VPC 网段 | 云上私有网络，节点、数据库、Redis 等资源通常在这里 |
| Node IP | Kubernetes 节点机器在 VPC 里的地址 |
| Pod IP | Pod 在容器网络里的地址 |
| Service IP | Kubernetes 虚拟出来的稳定访问地址 |
| Ingress | HTTP/HTTPS 入口规则和转发层 |
同一个 VPC 里的网络通常是可达的；不同 Kubernetes 集群的容器网段应该规划好，避免冲突。办公网络要访问 VPC 里的服务，通常需要 VPN 或把服务通过公网入口暴露出来。
不要把“容器能不能访问”只理解成 Kubernetes 问题。很多时候真正卡住的是 VPC、安全组、路由、DNS、网关或公司网络策略。
Dubbo 服务间通信怎么放
如果生产者、消费者、配置中心都在 VPC 或集群内部，且网络已经打通，通常不需要把 Dubbo 服务暴露到公网。
更稳的做法是：
- 服务注册到配置中心或注册中心。
- 消费者通过内部网络发现生产者。
- 安全组和网络策略只开放必要端口。
- 不把内部 RPC 入口直接暴露给外部网络。
这类服务要先追求内部可达和边界清楚，而不是为了“访问方便”直接做公网入口。
非 Dubbo 服务怎么互相访问
普通 HTTP 服务之间调用时，如果都在同一个集群里，优先通过 Service 访问。比如：
order-service -> user-service实际请求可以走 Kubernetes DNS 解析到 Service，再由 Service 转到后面的 Pod。
如果一个服务在集群内，另一个服务在集群外但同一个 VPC，则需要看云厂商网络、节点入口、负载均衡或私有域名怎么配置。不要简单把 Pod IP 写死到外部服务配置里。
对外访问先问三个问题
设计 Kubernetes 服务入口时，可以先问：
- 这个服务只给集群内部调用吗？
- 这个服务要给同 VPC 的其他系统调用吗？
- 这个服务要给公网、办公网络或浏览器访问吗？
对应关系大致是：
| 场景 | 常见方案 |
| — | — |
| 集群内部调用 | ClusterIP Service |
| 同 VPC 内部调用 | 私网负载均衡、Node 入口、云厂商内网方案 |
| HTTP/HTTPS 对外入口 | Ingress + Ingress Controller |
| 办公网络访问内网服务 | VPN、专线、跳板或受控公网入口 |
| 临时调试 | 端口转发或临时入口，完成后收回 |
这张表不是唯一答案，但它能帮你避免一上来就把所有服务都暴露出去。
小结
Kubernetes 网络可以先记住这几条：
- Pod 是运行单元，IP 会随生命周期变化。
- Service 给一组 Pod 提供稳定访问入口。
- ClusterIP 主要用于集群内部访问。
- NodeIP 是节点机器的真实地址，不等于 Pod IP。
- Ingress 适合 HTTP/HTTPS 的外部入口。
- VPC、容器网段、Service 网段和办公网络访问要分层看。
- 内部 RPC 服务不要随手暴露公网，先按访问范围设计入口。
真正理解 Kubernetes 网络，不是把每个 IP 名词背下来，而是能判断一次访问应该停留在集群内、VPC 内，还是需要经过受控入口对外开放。
