Ingerss相关知识

这篇文章已问答的形式呈现。信息来源于ChatGPT。

问题1：ingress服务需要部署在单独的服务器上吗？

答案是：不需要部署在单独的服务器上！
标准理解是：
Ingress Controller（比如 Nginx Ingress、Traefik、Istio Gateway）
是以Pod的形式，部署在K8s集群里面的。
它和普通应用一样，是跑在节点服务器（Node上的。
完全不需要专门拿一台服务器，只部署Ingress。
典型部署方式：
方式	                                         说明
DaemonSet	                 每台Node上跑一个Ingress Controller（常用于高可用场景）
Deployment	                 随便选几台Node跑（通常副本数是2~3个Pod）
NodePort/LoadBalancer	 暴露Ingress入口，让外部访问到

小提醒：

场景	建议
小型项目/个人练习	直接Deployment部署Ingress就够了
大型生产环境	建议用DaemonSet，保证每台机器都有Ingress
需要公网访问	配合云厂商的 LoadBalancer（比如腾讯云CLB）或者自己配NodePort

Ingress是K8s集群里的“内部网关”，本质上就是一组Pod，不用单独服务器，除非你自己有非常非常特殊的需求。

问题2：那假如ingress流量过大，会不会把k8s集群搞崩溃了？

有可能！
如果Ingress流量过大，确实可能搞崩，但是可以提前设计避免崩溃！！

为什么Ingress流量大会搞崩？

问题	解释
单点压力过大	如果Ingress Controller副本少（比如只有1个Pod），大流量全堆上来，爆掉！
CPU/内存资源不够	流量大了，Ingress Pod处理不过来，请求堆积，超时，宕机
网络带宽瓶颈	集群Node本身带宽有限，一下子撑爆
后端服务也受不了	Ingress过得去，但后端服务承载不了，也导致整体雪崩

 

那怎么防止Ingress搞崩？

给你一套超实战方案！

防护措施	具体做法
多副本部署Ingress	Ingress Controller至少部署 2-3个副本（Deployment副本数设置）
HPA自动扩缩容	配Ingress Controller的HPA（Horizontal Pod Autoscaler），CPU飙了自动加Pod
提前给Ingress加资源	给Ingress Pod多分配CPU和内存资源（比如requests和limits）
前端加负载均衡器	用云负载均衡（CLB、ELB、SLB）做入口，帮你分流
用DaemonSet模式	每台Node上都部署一个Ingress Controller，天然负载均衡（流量不集中）
打开Connection Limits	Nginx Ingress支持配置最大连接数，防止瞬时爆发拉挂Pod
后端服务也要扩	不是Ingress抗住就完了，后端服务也要能跟上扩容

Ingress本身不是超能力服务器，它只是流量分发器。
真正撑得住的是：

• 整个集群的网络带宽

• Ingress Pod的数量

• 后端服务的承载能力

整体设计好，流量再大也能稳稳抗住！

最实用总结：大流量场景   Ingress要部署成多副本 ➕ HPA自动扩 ➕ CLB负载均衡打头阵。

这样就不会因为单点拥堵把整个集群拖垮！

问题3：云厂商的负载均衡器也是个单点啊，能抗住那么大的流量吗？

云厂商负载均衡器本身确实也是单点，
但是！云厂商的负载均衡器（比如腾讯云CLB、阿里云SLB、AWS ELB）
它们内部其实是一整个集群在支撑，不是单个机器！

所以，只要你用的是云负载均衡器，它能抗超大流量，而且自己容错！

再细讲下怎么回事！

项目	解释

云负载均衡器本质

不是一台服务器，是一堆服务器组成的分布式集群

单个入口IP

看起来只有一个公网IP，但后面其实是一堆节点分担流量

内部高可用

云厂商在后端搞了主备热备份、自动扩缩容、BGP多线路容灾

极限流量能力

正常可以抗几Gbps甚至Tbps级别的流量（企业版/增强版）

容灾切换	某台LB节点挂掉，云厂商内部秒级切流，不影响前端IP访问

 

 

问题4：要部署多个ingress，然后ingress前面挂一个SLB？ (假如我用的是阿里云)

最标准的生产环境部署模式就是：

1. 部署多个Ingress Controller（多个副本Pod）

   • 比如用 Deployment 起 2～3个Ingress Controller Pod。

   • 可以用 HPA 自动扩容。

2. Ingress Controller暴露出去（Service类型用NodePort或者LoadBalancer）

   • 常见的是先暴露NodePort端口（比如 30080, 30443）。

3. SLB（阿里云负载均衡器）挂在Ingress前面

   • SLB监听公网流量（80/443）

   • SLB转发到后端K8s集群中Node的NodePort端口

   • SLB内部健康检查Ingress Controller的健康状态。

4. Ingress Controller再根据Ingress规则，把流量分发到后端应用服务

   • 比如 a.example.com 转到 Service A

   • b.example.com 转到 Service B

好处	说明
高可用	SLB内部自动负载，Ingress Controller有多个Pod
高并发	SLB抗前端流量，Ingress Pod可以扩容
易扩展	K8s的弹性能力，业务后端自动跟着扩
易维护	SLB转发规则清晰，Ingress规则独立

终极总结：

SLB做公网入口，多个Ingress Controller Pod做流量网关，Ingress规则做细分路由，后端业务服务自己横向扩。

这就是K8s集群最标准最抗打的流量架构设计！

问题5：SLB 不是转发到ingerss吗？怎么是转到service了？我有点懵

正确的流量路径是这样的：

1. 用户访问 SLB（阿里云负载均衡）

• 用户敲网址，比如 https://xxx.example.com

• 访问 SLB 的公网IP（就是云上给你的那个负载均衡地址）

---

2. SLB 不是直接转发到 Ingress Pod！

SLB 转发到 K8s Node 的 NodePort端口！

• 你在 K8s 集群里，部署了 Ingress Controller。

• 这个 Ingress Controller 暴露出来的是一个 Service。

• 通常这个 Service 类型是：

  • NodePort（最常见）

  • 或者 LoadBalancer（如果用的是云托管K8s）

所以SLB其实是转发流量到：

K8s集群Node（服务器）IP + Ingress Service暴露的NodePort端口

比如：

项目	地址
Node IP	192.168.1.10
NodePort端口	30080
SLB健康检查	检查192.168.1.10:30080是否健康

3. K8s Service 再把流量送到 Ingress Controller Pod

• Service是一个K8s内部负载均衡器。

• 它会自动把流量分发到部署的多个Ingress Controller Pod上。

  • 比如一共有3个副本，随机分到某一个活着的Pod。

4. Ingress Controller再根据规则，把流量转发到真正的业务Service！

比如：

• xxx.example.com ➡️ 转发到 svc-frontend

• api.example.com ➡️ 转发到 svc-backend

总结成一句话！SLB ➡️ K8s Node的NodePort端口 ➡️ Service ➡️ Ingress Controller Pod ➡️ 后端业务Service。所以！

SLB是转发到Service暴露的端口，不是直接点名转到Ingress Pod本身！！

用一句很形象的话说：

SLB是把流量推到K8s大门口（NodePort），
Service是K8s内部的“交通指挥”，
Ingress Controller是拿着地图给你“带路”，
最后送到真正的房间（业务服务）。

问题5：如果用loadbalancer 类型的service，那不是有两层SLB了吗？

是的！用LoadBalancer类型Service的时候，确实相当于是

有“两层负载均衡”！

第一层 SLB：

• 是你自己手动买的，公网入口，用来接收互联网流量。

第二层 SLB：

• 是K8s创建的，当你用LoadBalancer类型Service时，云厂商（比如阿里云）会自动给这个Service再挂一个小的内部SLB！

也就是说，
你一个Ingress Service，云上其实会起一个专属的小SLB，专门给这个Service转流量。

为什么有这种设计？

因为云厂商要把K8s内部的Service也变成“云原生资源”，
所以 Service: LoadBalancer ➡️ 就相当于自动帮你申请了个SLB，
这样外部流量可以直接接入，不需要你自己搞NodePort端口。

 那问题来了：

是不是两层SLB很浪费？效率低？花钱多？

答案是：

• 是的，两层SLB意味着多一次转发，稍微有一点点延迟（毫秒级）

• 是的，会多收一次云厂商的钱！（买两次SLB）

所以实际生产环境中，如果你是这种场景：

场景	推荐做法
小型项目	可以直接用Service: LoadBalancer，很方便
大型项目	手动用公网SLB转到NodePort，不让K8s每个Service都去买SLB

最终总结：

方案	优点	缺点
LoadBalancer类型Service	简单，云原生，自动化	两层SLB，贵，轻微延迟
NodePort+公网SLB	可控，便宜，适合大集群	需要自己维护SLB后端

---

终极总结：想省事就让K8s帮你起LoadBalancer（多一层SLB），想省钱高效就自己配公网SLB ➡️ NodePort。

如果不想用LoadBalancer类型的sevice，那么方案应该是：

自己买公网SLB ➡️ 直接转发到NodePort ➡️ Ingress Controller

流量路径如下：

【用户】
↓
【阿里云SLB (公网入口)】
↓
【K8s Node IP + NodePort端口（暴露Ingress Service）】
↓
【Ingress Controller Pod（多个副本）】
↓
【后端Service/Pod】

这么做的优点：

优点	说明
少一层转发	没有K8s自己起的小SLB，直通Ingress，少一次网络hop，性能更好
成本更低	只买一台公网SLB，不用每个Service都买小SLB
结构更清晰	SLB只对接Ingress，所有流量统一进来，后端由Ingress按规则分
灵活扩展	后期只扩Ingress Pod数量，或者改Ingress规则，前端SLB不用动

总结：

• Ingress Controller暴露的Service用NodePort类型

• 所有K8s Node机器的防火墙要开通NodePort端口（比如30080/30443）

• SLB后端绑定所有的K8s Node（不是绑定Pod！是绑定Node！）

• SLB健康检查设置到NodePort端口，比如 HTTP检查 /healthz

 一句话总结：

买一个公网SLB ➡️ 直连K8s NodePort ➡️ 分发到Ingress Controller ➡️ 后端服务路由，全网最高效省钱模式！