一、开篇网关讲完了集群内的流量怎么出去前面两篇我们分别聊了 Kong 和 APISIX 两款主流 API 网关的落地实战。有读者在后台问我“小花网关我懂了可是我的服务都跑在 Kubernetes 里Pod 的 IP 是随时会变的内网地址外面用户怎么访问进来难道每个服务都挂一个 Kong”这个问题问到了点子上。我刚接手公司容器化改造那会儿团队用的是一个极其朴素的方案每个需要对外暴露的服务手动创建一个NodePort类型的 Service然后在前面挂一层 Nginx把不同端口映射成不同域名。结果就是——Nginx 配置几千行、端口表一张 A4 纸都列不下、新增一个服务要同时改三处地方运维同学每周都要因为配错端口背一次锅。那次线上故障我到现在都记得一个新来的同事把 30080 和 30081 两个 NodePort 在 Nginx 里写反了导致支付回调流量被打到了测试环境好在测试环境当时没数据不然又是一次 P0。所以今天这篇我们专门聊 Kubernetes 里对外暴露服务这件事的集大成者——Ingress。它本质上是把路由规则这件事从手工改 Nginx 配置变成了声明式、可版本管理、跟着集群一起走的资源对象。二、服务暴露的四种姿势以及为什么最终是 IngressKubernetes 把服务暴露给集群外历史上有这么几种演进1. hostNetwork / hostPort让 Pod 直接用宿主机的网络命名空间。简单粗暴但端口冲突、调度受限、没法做负载均衡生产环境基本告别。2. NodePort每个节点开一个固定端口默认 30000-32767kube-proxy 把它转发到 Pod。优点是省事缺点是端口号丑、要自己在前端再挡一层负载均衡而且端口资源是有限的。3. LoadBalancer云厂商直接给你每个 Service 分配一个外部负载均衡器SLB/ELB。爽是真爽但一个服务一个 LB几十个服务就是几十个公网 IP月底账单能让你怀疑人生。我们曾经一个月光 LB 就烧了小两万。4. Ingress一个 LB 打底后面用 Ingress 规则把不同域名、不同路径路由到不同 Service。一个入口N 个后端这才是性价比最高的解法。Ingress 的核心价值就一句话用一份 YAML 描述什么流量去哪里剩下的转发、TLS、负载均衡交给 Controller 自动处理。三、最容易搞混的概念Ingress ≠ Ingress Controller这是我带新人时必考的一道题错的人能有一半。Ingress只是一个声明式的资源对象相当于你写的一份路由需求清单。它本身不干活。Ingress Controller真正干活的进程它监听 Ingress 资源的变化动态生成底层数据面Nginx/Envoy 等的配置并 reload。打个比方Ingress 是你要装修时画的户型图Ingress Controller 是施工队。你只画图纸施工队按图施工。没有 Controller你画一百张图也不会有一面墙被砌起来。这也是为什么你光创建一个 Ingress YAML 没反应时第一反应应该是我的 Controller 装了吗跑起来了吗它监听的是哪个 IngressClass四、主流 Controller 横评含前两篇的网关既然前面聊了 Kong 和 APISIX这里正好把它们的 Ingress 形态也一并对比方便你选型时有个全局视角方案数据面配置热更新动态能力适用场景Nginx IngressNginxreload大配置有抖动中靠注解绝大多数公司首选稳Traefik自研真正热加载强原生支持灰度云原生原生、追求自动化APISIX IngressAPISIX/etcd全动态无 reload极强已用 APISIX、要插件生态Kong IngressKong动态强已用 Kong、要丰富插件我的建议很直接如果你们没有既有的网关体系直接用 Nginx Ingress Controller 起手它资料最多、坑最少、社区最活跃。等业务复杂到需要灰度、限流、插件了再考虑 APISIX/Traefik 这类更动态的方案——而且它们本质上也能复用你已有的 Ingress 声明。五、基础路由实战host、path 与 rewrite一个最小可用的 Ingress 长这样apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:shop-ingressannotations:nginx.ingress.kubernetes.io/rewrite-target:/spec:ingressClassName:nginxrules:-host:mall.example.comhttp:paths:-path:/apipathType:Prefixbackend:service:name:order-serviceport:number:8080这里有几个关键点都是我踩过坑才记住的pathType一定要显式写。Prefix是前缀匹配Exact是精确匹配ImplementationSpecific是看 Controller 心情。新版本里不写会报错老版本里不写会行为诡异。rewrite-target常常被忽略。比如你的 Service 实际路径是/但外面暴露的是/api不做 rewrite请求打到后端就变成/api/xxx后端大概率 404。这个注解就是告诉 Controller“把/api这段前缀摘掉再转发”。六、TLS 实战cert-manager 让证书自愈HTTPS 现在是标配但手工管理证书是运维噩梦申请、部署、盯着到期、续期……任何一个环节漏了就是一次全站 HTTPS 崩盘。我们吃过这个亏。一次证书过期那天正好是周日值班同学手机被打爆用户在微信里骂街。从那以后我们全面上了cert-manager它作为一个 Kubernetes 控制器自动向 Let’s Encrypt 申请证书、自动注入到 Secret、到期前自动续期全程无人值守。Ingress 里引用证书只要一行spec:tls:-hosts:-mall.example.comsecretName:mall-tls-secretrules:-host:mall.example.com证书的事就从每月一次惊魂变成了忘掉它存在。让机器管证书把人从到期焦虑里解放出来这才是云原生该有的样子。七、灰度与流量切分和前面讲的灰度发布一脉相承如果你看过我讲 Kong、APISIX 灰度的文章会发现 Ingress 层的灰度逻辑是一脉相承的——只是配置位置从网关面板搬到了 YAML 注解。Nginx Ingress 支持基于权重的金丝雀annotations:nginx.ingress.kubernetes.io/canary:truenginx.ingress.kubernetes.io/canary-weight:10这表示把 10% 的流量切到新版本。配合 CI/CD我们可以先放 10%观察监控再逐步 30%、50%、100%。灰度不是炫技是给线上的自己留一条退路。这和我在 Kong/APISIX 篇里强调的零风险上线是同一个灵魂。八、一个灵魂拷问限流、鉴权放 Ingress 还是放网关这是架构评审时经常被争论的问题。我的判断标准就两条集群边界通用的东西HTTPS 终止、基础限流、跨域 CORS、基础鉴权放 Ingress 层统一做避免每个服务重复造轮子。业务相关的精细治理按用户维度限流、复杂鉴权、协议转换、插件链放 API 网关层做那里有更丰富的插件生态和动态能力。一句话总结Ingress 是你的小区大门管进出和第一道安检API 网关是你的楼栋管家管每家每户的精细服务。职责分清各司其职。九、生产踩坑实录都是真金白银换来的坑 1path 末尾的/导致 404。path: /api/和path: /api在 Prefix 模式下行为不同配合 rewrite 时尤其容易踩。我们曾经因为一个斜杠排查了三个小时。建议团队统一规范对外路径一律不带末尾斜杠。坑 2正则路由的顺序陷阱。用pathType: ImplementationSpecific配正则时Controller 按配置顺序匹配把具体路由写前面、通配写后面否则通配比你先命中。坑 3大文件上传超时。默认proxy-body-size是 1M传个大附件直接 413。要在注解里放开nginx.ingress.kubernetes.io/proxy-body-size: 50m同时调整后端超时。坑 4Ingress Controller 成了新单点。很多人忘了 Controller 本身也要高可用。我们一开始只部署了一个副本结果一次节点故障全站入口直接挂掉。后来改成多副本 HPA 自动扩缩并把它单独调度到专用节点池才真正稳下来。坑 5注解拼写错误静默失效。Ingress 的注解写错了不会报错只是不生效。比如把canary-weight写成canary-weigh灰度就悄悄没生效你还在以为已经切了 10% 流量。建议把常用注解做成 Helm values 模板减少手抖。十、写在最后回头看Ingress 的本质不是一项多高深的技术而是一种**把路由这件事声明化、标准化、跟着集群走的工程思想**。它把我们从手工改 Nginx的泥潭里拉出来让流量入口也变成了可以版本管理、可以 Code Review、可以一键回滚的代码。从 NodePort 到 LoadBalancer 再到 Ingress从手工配置到 cert-manager 自愈从单副本到多副本 HPA——这一路踩的坑本质上都在回答同一个问题如何让流量从哪里来、到哪里去这件事既灵活又可靠。下一站我们可以聊聊 Helm 这个Kubernetes 的包管理器看看怎么把今天这些 Ingress、Service、Deployment 打包成一个可复用的应用安装包。关注我架构路上不迷路。—— 本文是《100 篇架构实战》系列第 88 篇前作可回看 Kong / APISIX 网关落地实战与灰度发布专题。
一、开篇网关讲完了集群内的流量怎么出去前面两篇我们分别聊了 Kong 和 APISIX 两款主流 API 网关的落地实战。有读者在后台问我“小花网关我懂了可是我的服务都跑在 Kubernetes 里Pod 的 IP 是随时会变的内网地址外面用户怎么访问进来难道每个服务都挂一个 Kong”这个问题问到了点子上。我刚接手公司容器化改造那会儿团队用的是一个极其朴素的方案每个需要对外暴露的服务手动创建一个NodePort类型的 Service然后在前面挂一层 Nginx把不同端口映射成不同域名。结果就是——Nginx 配置几千行、端口表一张 A4 纸都列不下、新增一个服务要同时改三处地方运维同学每周都要因为配错端口背一次锅。那次线上故障我到现在都记得一个新来的同事把 30080 和 30081 两个 NodePort 在 Nginx 里写反了导致支付回调流量被打到了测试环境好在测试环境当时没数据不然又是一次 P0。所以今天这篇我们专门聊 Kubernetes 里对外暴露服务这件事的集大成者——Ingress。它本质上是把路由规则这件事从手工改 Nginx 配置变成了声明式、可版本管理、跟着集群一起走的资源对象。二、服务暴露的四种姿势以及为什么最终是 IngressKubernetes 把服务暴露给集群外历史上有这么几种演进1. hostNetwork / hostPort让 Pod 直接用宿主机的网络命名空间。简单粗暴但端口冲突、调度受限、没法做负载均衡生产环境基本告别。2. NodePort每个节点开一个固定端口默认 30000-32767kube-proxy 把它转发到 Pod。优点是省事缺点是端口号丑、要自己在前端再挡一层负载均衡而且端口资源是有限的。3. LoadBalancer云厂商直接给你每个 Service 分配一个外部负载均衡器SLB/ELB。爽是真爽但一个服务一个 LB几十个服务就是几十个公网 IP月底账单能让你怀疑人生。我们曾经一个月光 LB 就烧了小两万。4. Ingress一个 LB 打底后面用 Ingress 规则把不同域名、不同路径路由到不同 Service。一个入口N 个后端这才是性价比最高的解法。Ingress 的核心价值就一句话用一份 YAML 描述什么流量去哪里剩下的转发、TLS、负载均衡交给 Controller 自动处理。三、最容易搞混的概念Ingress ≠ Ingress Controller这是我带新人时必考的一道题错的人能有一半。Ingress只是一个声明式的资源对象相当于你写的一份路由需求清单。它本身不干活。Ingress Controller真正干活的进程它监听 Ingress 资源的变化动态生成底层数据面Nginx/Envoy 等的配置并 reload。打个比方Ingress 是你要装修时画的户型图Ingress Controller 是施工队。你只画图纸施工队按图施工。没有 Controller你画一百张图也不会有一面墙被砌起来。这也是为什么你光创建一个 Ingress YAML 没反应时第一反应应该是我的 Controller 装了吗跑起来了吗它监听的是哪个 IngressClass四、主流 Controller 横评含前两篇的网关既然前面聊了 Kong 和 APISIX这里正好把它们的 Ingress 形态也一并对比方便你选型时有个全局视角方案数据面配置热更新动态能力适用场景Nginx IngressNginxreload大配置有抖动中靠注解绝大多数公司首选稳Traefik自研真正热加载强原生支持灰度云原生原生、追求自动化APISIX IngressAPISIX/etcd全动态无 reload极强已用 APISIX、要插件生态Kong IngressKong动态强已用 Kong、要丰富插件我的建议很直接如果你们没有既有的网关体系直接用 Nginx Ingress Controller 起手它资料最多、坑最少、社区最活跃。等业务复杂到需要灰度、限流、插件了再考虑 APISIX/Traefik 这类更动态的方案——而且它们本质上也能复用你已有的 Ingress 声明。五、基础路由实战host、path 与 rewrite一个最小可用的 Ingress 长这样apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:shop-ingressannotations:nginx.ingress.kubernetes.io/rewrite-target:/spec:ingressClassName:nginxrules:-host:mall.example.comhttp:paths:-path:/apipathType:Prefixbackend:service:name:order-serviceport:number:8080这里有几个关键点都是我踩过坑才记住的pathType一定要显式写。Prefix是前缀匹配Exact是精确匹配ImplementationSpecific是看 Controller 心情。新版本里不写会报错老版本里不写会行为诡异。rewrite-target常常被忽略。比如你的 Service 实际路径是/但外面暴露的是/api不做 rewrite请求打到后端就变成/api/xxx后端大概率 404。这个注解就是告诉 Controller“把/api这段前缀摘掉再转发”。六、TLS 实战cert-manager 让证书自愈HTTPS 现在是标配但手工管理证书是运维噩梦申请、部署、盯着到期、续期……任何一个环节漏了就是一次全站 HTTPS 崩盘。我们吃过这个亏。一次证书过期那天正好是周日值班同学手机被打爆用户在微信里骂街。从那以后我们全面上了cert-manager它作为一个 Kubernetes 控制器自动向 Let’s Encrypt 申请证书、自动注入到 Secret、到期前自动续期全程无人值守。Ingress 里引用证书只要一行spec:tls:-hosts:-mall.example.comsecretName:mall-tls-secretrules:-host:mall.example.com证书的事就从每月一次惊魂变成了忘掉它存在。让机器管证书把人从到期焦虑里解放出来这才是云原生该有的样子。七、灰度与流量切分和前面讲的灰度发布一脉相承如果你看过我讲 Kong、APISIX 灰度的文章会发现 Ingress 层的灰度逻辑是一脉相承的——只是配置位置从网关面板搬到了 YAML 注解。Nginx Ingress 支持基于权重的金丝雀annotations:nginx.ingress.kubernetes.io/canary:truenginx.ingress.kubernetes.io/canary-weight:10这表示把 10% 的流量切到新版本。配合 CI/CD我们可以先放 10%观察监控再逐步 30%、50%、100%。灰度不是炫技是给线上的自己留一条退路。这和我在 Kong/APISIX 篇里强调的零风险上线是同一个灵魂。八、一个灵魂拷问限流、鉴权放 Ingress 还是放网关这是架构评审时经常被争论的问题。我的判断标准就两条集群边界通用的东西HTTPS 终止、基础限流、跨域 CORS、基础鉴权放 Ingress 层统一做避免每个服务重复造轮子。业务相关的精细治理按用户维度限流、复杂鉴权、协议转换、插件链放 API 网关层做那里有更丰富的插件生态和动态能力。一句话总结Ingress 是你的小区大门管进出和第一道安检API 网关是你的楼栋管家管每家每户的精细服务。职责分清各司其职。九、生产踩坑实录都是真金白银换来的坑 1path 末尾的/导致 404。path: /api/和path: /api在 Prefix 模式下行为不同配合 rewrite 时尤其容易踩。我们曾经因为一个斜杠排查了三个小时。建议团队统一规范对外路径一律不带末尾斜杠。坑 2正则路由的顺序陷阱。用pathType: ImplementationSpecific配正则时Controller 按配置顺序匹配把具体路由写前面、通配写后面否则通配比你先命中。坑 3大文件上传超时。默认proxy-body-size是 1M传个大附件直接 413。要在注解里放开nginx.ingress.kubernetes.io/proxy-body-size: 50m同时调整后端超时。坑 4Ingress Controller 成了新单点。很多人忘了 Controller 本身也要高可用。我们一开始只部署了一个副本结果一次节点故障全站入口直接挂掉。后来改成多副本 HPA 自动扩缩并把它单独调度到专用节点池才真正稳下来。坑 5注解拼写错误静默失效。Ingress 的注解写错了不会报错只是不生效。比如把canary-weight写成canary-weigh灰度就悄悄没生效你还在以为已经切了 10% 流量。建议把常用注解做成 Helm values 模板减少手抖。十、写在最后回头看Ingress 的本质不是一项多高深的技术而是一种**把路由这件事声明化、标准化、跟着集群走的工程思想**。它把我们从手工改 Nginx的泥潭里拉出来让流量入口也变成了可以版本管理、可以 Code Review、可以一键回滚的代码。从 NodePort 到 LoadBalancer 再到 Ingress从手工配置到 cert-manager 自愈从单副本到多副本 HPA——这一路踩的坑本质上都在回答同一个问题如何让流量从哪里来、到哪里去这件事既灵活又可靠。下一站我们可以聊聊 Helm 这个Kubernetes 的包管理器看看怎么把今天这些 Ingress、Service、Deployment 打包成一个可复用的应用安装包。关注我架构路上不迷路。—— 本文是《100 篇架构实战》系列第 88 篇前作可回看 Kong / APISIX 网关落地实战与灰度发布专题。
)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
