【Kubernetes】Ingress的理解，netstat命令使用，对比理解service和ingress

对于Kubernetes（k8s）初学者来说，网络相关的概念往往是入门的难点。Service、Ingress、端口映射等术语容易让人混淆，而netstat这类命令的输出也可能看得一头雾水。本文结合实际操作场景，从基础概念到命令使用，帮你理清Ingress、Service的核心作用及它们之间的关系。

一、先搞懂：Service到底是什么？

在学习Ingress之前，我们必须先理解Service的作用------它是Kubernetes集群内部的"稳定访问入口"。

为什么需要Service？

Kubernetes中，Pod是最小的部署单元，但Pod有个特点：会动态变化（重启、迁移、扩缩容时，IP会改变）。如果其他服务或用户直接通过Pod的IP访问，一旦Pod重建，访问就会失效。

Service的核心功能就是解决这个问题：给一组相同功能的Pod（比如多个nginx副本）分配一个固定的访问地址，无论Pod如何变化，通过Service的地址总能访问到这组Pod。

用生活化的例子理解

想象一个大型商场（k8s集群），里面有很多店铺（Pod）。店铺可能会换位置（Pod IP变化），但商场会给同一类店铺（比如所有咖啡店）分配一个固定的"店铺编号"（Service）。顾客只要记住编号，就能通过商场内部系统找到对应的店铺，不用关心店铺具体在哪。

Service的常见类型

ClusterIP：默认类型，仅在集群内部可用的固定IP，供集群内其他服务访问。
NodePort：在每个节点上开放一个端口，外部可通过"节点IP:端口"访问（适合测试，端口范围30000-32767）。
LoadBalancer：依赖云厂商提供的负载均衡器，自动分配外部IP（生产环境常用，但有成本）。
ExternalName ：将Service映射到集群外的域名（如www.example.com），无需选择Pod。

二、Ingress：集群的"外部流量总入口"

有了Service，集群内部的访问问题解决了，但外部流量（比如用户通过浏览器访问）如何进入集群呢？这就是Ingress的作用。

为什么需要Ingress？

Service虽然能通过NodePort或LoadBalancer暴露到外部，但存在局限：

NodePort端口范围固定，管理大量服务时端口难以记忆；
无法基于域名或路径转发（比如用api.example.com访问API服务，web.example.com访问Web服务）；
缺乏SSL证书配置、请求限流等高级功能。

Ingress的核心功能：作为集群的"总入口"，接收外部请求，根据规则转发到对应的Service。

用生活化的例子理解

还是那个商场：顾客从大门（集群外部）进来后，不知道怎么找到想去的店铺（比如"3楼的咖啡店"）。Service只负责内部编号，不处理外部的"导航请求"。Ingress就相当于商场的"总服务台+导航系统"------接收顾客的请求（比如"我要去咖啡店"），然后指引到对应的Service（咖啡店的编号）。

Ingress的组成

Ingress由两部分组成：

Ingress资源 ：一个YAML配置文件，定义转发规则（比如"访问k8s.wolfcode.cn时转发到nginx-svc"）。
Ingress控制器：实际执行规则的组件（通常是Nginx、Traefik等），以Pod形式运行在集群中，负责监听外部端口（80/443）并转发请求。

比如你创建的wolfcode-nginx-ingress就是一个Ingress资源，而ingress-nginx-controller就是执行规则的控制器。

三、Service和Ingress的对比：一张表讲清区别与联系

维度	Service（服务）	Ingress（入口）
作用范围	主要用于集群内部（Pod之间的访问）	用于集群外部到内部（用户/外部系统访问）
核心功能	给Pod组提供固定访问点，实现内部负载均衡	管理外部流量规则，转发到对应的Service
依赖关系	直接关联Pod（通过标签选择器）	不直接关联Pod，而是关联Service
访问方式	ClusterIP（内部）、NodePort（节点端口）等	通常绑定域名，支持HTTP/HTTPS默认端口
典型场景	集群内服务间通信（如后端API调用数据库）	外部用户通过域名访问Web服务、API服务等

工作流程：外部请求 → Ingress（按规则转发）→ Service（找到对应Pod）→ Pod（提供服务）。

四、netstat命令：查看端口监听的实用工具

在操作Kubernetes时，我们经常需要确认"某个端口是否被正确监听"（比如Ingress控制器是否开启了80端口），netstat就是常用的工具。

理解`netstat -ntlp`命令

这是查看服务器上"正在监听的TCP端口及对应进程"的命令，参数含义：

n：用数字显示IP和端口（而非域名或服务名，更直观）；
t：只显示TCP协议的连接；
l：只显示"正在监听"的端口（处于"等待连接"状态）；
p：显示占用端口的进程（哪个程序在使用该端口）。

输出结果解读

以节点上的Nginx监听为例：

复制代码

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      4548/nginx: master

各列含义：

Proto：协议类型（TCP）；
Local Address：本地监听的IP和端口（0.0.0.0:80表示所有IP的80端口都在监听）；
Foreign Address：允许连接的外部IP和端口（0.0.0.0:*表示允许任何外部IP和端口）；
State：状态（LISTEN表示正在监听）；
PID/Program name：进程ID和程序名（这里是Nginx主进程）。

实际意义

在Kubernetes中，如果你在节点上用netstat -ntlp看到nginx: master监听了80/443端口，说明Ingress控制器已正常工作------外部请求可以通过该节点的80/443端口进入集群了。

五、常见问题与排查思路

1. 为什么在master节点看不到Ingress的80端口？

Ingress控制器通常以Pod形式运行在工作节点（如node1），而非master节点。你需要登录到控制器所在的节点（通过kubectl get po -n ingress-nginx -o wide查看节点），再用netstat查看。

2. 如何验证Ingress是否生效？

确认Ingress控制器运行正常：kubectl get po -n ingress-nginx（状态为Running）；
查看Ingress规则：kubectl get ingress（确认HOSTS和PORTS正确）；
在本地电脑的C:\Windows\System32\drivers\etc\hosts文件中，将Ingress的域名（如k8s.wolfcode.cn）绑定到控制器所在节点的IP；
用浏览器访问http://k8s.wolfcode.cn，检查是否能正常访问后端服务。

ingress 是在 Kubernetes 集群网络模型中承担特定功能的 "流量入口控制器"。它的作用是在集群外部与内部服务之间建立 "桥梁"，解决外部流量如何高效访问集群内服务的问题。
Service 解决 Pod 的访问稳定性问题，Ingress 解决外部流量到 Service 的路由规则问题，二者是 "递进关系" 而非 "同一层级"。

Ingress 的出现就是为了解决这些问题，它可以：

通过一个公网 IP 和端口（通常是 80/443）暴露多个内部服务；
基于域名（如 api.example.com、web.example.com）或路径（如 /api、/web）将请求转发到不同的 Service；
配置 SSL 证书（HTTPS），加密传输；
实现负载均衡

【Kubernetes】Ingress的理解，netstat命令使用，对比理解service和ingress