K8S的Ingress、Service、Pod理解
【摘要】 基本概念Ingress角色：集群的核心流量入口（网关）。职责：它专门负责处理集群外部进来的流量。它能看懂域名（如 foo.com）和路径（如 /api），并根据你写好的路由规则，决定把这个请求指引给哪一个 Service。级别：工作在 7 层（应用层）。kubectl get ingress -A华为云提供2种：Ingress 类型底层是否使用 Nginx流量转发路径Nginx Ingres...
基本概念
Ingress
- 角色：集群的核心流量入口（网关）。
- 职责：它专门负责处理集群外部进来的流量。它能看懂域名（如
foo.com）和路径（如/api），并根据你写好的路由规则，决定把这个请求指引给哪一个 Service。 - 级别：工作在 7 层（应用层）。
- kubectl get ingress -A
- 华为云提供2种：
Ingress 类型 底层是否使用 Nginx 流量转发路径 Nginx Ingress 是（基于开源社区的 NGINX Ingress Controller） 客户端 → 华为云 ELB → Nginx Pod (处理 7 层路由) → 业务 Pod ELB Ingress 否（完全由华为云 ELB 硬件/云原生实例承载） 客户端 → 华为云 ELB (直接处理 7 层路由) → 业务 Pod
Service
- 角色：集群内部的服务发现与负载均衡器。
- 职责：Pod 的 IP 是经常变动的（销毁重建就会变）。Service 拥有一个固定的 IP（ClusterIP），它在集群内部“死死绑定”了一组执行相同业务的 Pod，负责把请求平均分发给这组 Pod。
- 级别：工作在 4 层（传输层）。
- kubectl get service 或 svc
- 华为云提供3种
Service 类型 分配 ClusterIP 占用节点端口 触发云厂商扣费/购买 LB 谁能访问 ClusterIP 有 无 无 仅集群内部的 Pod NodePort 有 有 无 集群外部（通过任意节点IP+端口） LoadBalancer 有 有 有 全网用户（通过公网IP）
信息流
外部用户 → Ingress（解析域名和路径） → Service（找到后面健康的 Pod） → 具体的 Pod 容器
图一：标准生产流量路径 (云原生 7层 Ingress 模式)
这是最推荐的生产架构。流量通过域名进来，由华为云独享型 ELB 直接精准投递到 Pod，效率最高，也最安全。
t
[ 公网用户 (Client) ]
│
│ 访问: http://myapp.com
▼
┌──────────────────────────────────────────────┐
│ 华为云独享型 ELB 网关 │
│ (kubernetes.io/elb.class: performance) │
├──────────────────────────────────────────────┤
│ 1. 拦截公网 80/443 端口流量 │
│ 2. 执行【7层路由】: 识别域名及 /api 路径 │
│ 3. 动态读取 Service 的最新 Pod 名册 │
└──────────────────────┬───────────────────────┘
│
│【直通模式 (Direct Pod) 】
│ 绕过 Service 虚拟IP，直接物理投递
▼
┌──────────────────────────────────────────────┐
│ K8s 业务 Pod 实例集群 │
├──────────────────────────────────────────────┤
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ Pod A │ │ Pod B │ │ Pod C │ │
│ │ (10.0.1.5:80) │ │ (10.0.2.6:80) │ │ (10.0.1.9:80) │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
└──────────────────────────────────────────────┘
💡 逻辑关联：Ingress 在逻辑上绑定了 ClusterIP或NodePort 类型的 Service，
但物理流量由 ELB 直接分发给具体的 Pod 真实 IP。
图二：NodePort 流量路径 (4层 节点端口模式)
这种模式下，流量直接打在集群任何一台服务器的物理 IP 和高位端口上，依赖集群内部网络（kube-proxy）进行跨节点二次转发。
[ 外部用户 / 测试人员 ]
│
│ 访问: http://119.2.3.4:30001 (任意 Node IP)
▼
┌──────────────────────────────────────────────┐
│ 集群节点 Node B (物理机) │
├──────────────────────────────────────────────┤
│ 1. 物理网卡开放 30001 端口 │
│ 2. 哪怕该节点上没有运行该业务 Pod，也必须接收 │
│ 3. 【4层路由】: 由内核 kube-proxy 拦截流量 │
└──────────────────────┬───────────────────────┘
│
│【集群内网络转发】
│ 发现目标 Pod 不在本地，通过网络隧道
│ 将流量跨节点转发给真正运行 Pod 的机器
▼
┌──────────────────────────────────────────────┐
│ 集群节点 Node A (物理机) │
├──────────────────────────────────────────────┤
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Pod A │ │
│ │ (真实运行容器)│ │
│ └───────────────┘ │
└──────────────────────────────────────────────┘
💡 运作机制：每个节点都变成了流量中转站。无论你访问 Node A、B
还是 C，底层的 iptables/IPVS 都会把流量均摊给背后的 Pod。1. Ingress 的本质：一份交给“网关 Pod”执行的动态路由说明书
当你执行
kubectl apply -f ingress.yaml 时：- 它是什么：它只是一个逻辑规则文件。写着“如果域名是 a.com 就去 A，如果是 b.com 就去 B”。
- 谁来解析运行：集群里必须提前运行着一个真正的、有实体的 Pod，叫做 Ingress Controller（比如
ingress-nginx-controller的 Pod，或者华为云的独享型 ELB 硬件实例）。 - 生效过程：这个“网关 Pod”或硬件会一直盯着集群。一旦发现有新的 Ingress 配置文件进来，它就把里面的文本翻译成自己看得懂的配置（比如 Nginx 的
nginx.conf段落），然后动态热重载（Reload）生效。
结论：Ingress 只是“剧本”（逻辑配置），Ingress Controller 才是“演员”（真正运行的 Pod 实体）。
2. Service 的本质：一份写给操作系统内核的“交警调度表”
当你执行
kubectl apply -f service.yaml 时，情况比 Ingress 还要抽象，因为甚至连所谓的“Service Controller Pod”都不存在！- 它是什么：它完全是一个纯逻辑的虚拟概念。K8s 给它分配的
ClusterIP（比如10.96.0.1）在集群里根本不存在任何实体物理网卡。如果你去对这个 IP 物理抓包，你会发现它是虚无的。 - 谁来解析运行：集群中每一台服务器（Node）上，都运行着一个叫
kube-proxy的系统级守护进程。 - 生效过程：
- 你创建了 Service 配置文件。
- 每一台机器上的
kube-proxy看到这个文件后，会把这个 Service 虚拟 IP 和它背后绑定的真正 Pod IP 列表取出来。 kube-proxy转身直接调用 Linux 操作系统内核的 IPVS 或 iptables 模块，在操作系统内核层硬编码写下一条底层网络转发规则。- 当有流量试图访问这个虚拟 IP 时，Linux 内核在底层（4层传输层）直接把目标 IP 改成某个真实 Pod 的 IP，完成了分流。
结论：Service 只是“交通规划图”（逻辑配置），Linux 内核的 IPVS/iptables 才是底层的“交警”（真正的执行者）。
【版权声明】本文为华为云社区用户原创内容，未经允许不得转载，如需转载请自行联系原作者进行授权。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）