Kubernetes部署Ingress控制器教程-Golang-PHP中文网

helm 部署 ingress-nginx 是首选，因其内置版本校验、rbac 自动配置、admission webhook 证书生成及 --dry-run 预览能力，避免手动部署时镜像拉取失败、证书 job 卡住、crashloopbackoff 等高频问题；traefik 适合动态路由验证，但默认 ingressclass 名与 ingress-nginx 不兼容，混用易致流量丢失。

kubernetes部署ingress控制器教程

直接说结论：别从零写 YAML 部署 ingress-nginx，Helm 是当前最稳、最易维护的生产路径；Traefik 适合快速验证或微服务动态路由场景，但它的 ingressClass 默认名和行为与社区版 ingress-nginx 不兼容，混用会丢流量。

为什么 Helm 部署 ingress-nginx 是首选

手动 apply 官方 deploy.yaml 看似简单，实际踩坑密集：镜像拉取失败（尤其国内）、ValidatingWebhook 证书生成 Job 卡住、controller Pod 启动后反复 CrashLoopBackOff（常因 ServiceAccount 权限或 RBAC 缺失）、NodePort 端口冲突未提示。Helm chart 内置了版本校验、依赖管理、默认安全上下文、自动生成 admission webhook 证书等逻辑，且支持 --dry-run 预览生成内容。

必须用 https://kubernetes.github.io/ingress-nginx 这个 Helm 仓库，不是 nginx-stable（后者是旧版 Nginx Inc. 维护的商业分支，已归档）
务必加 --create-namespace，否则 namespace 不存在时命令静默失败
若集群启用了 PodSecurityPolicy 或 PodSecurity，需显式设置 controller.podSecurityContext.enabled=false 和 controller.securityContext.capabilities.drop

ingressClass 名称不匹配会导致 Ingress 资源完全不生效

这是最隐蔽的故障点——kubectl get ingress 显示正常，kubectl describe ingress 里却看不到任何 Events，ingress-nginx-controller 日志里也没有对应日志。根本原因是：Ingress 资源没声明 ingressClassName，或声明的名称和控制器启动参数里的 --ingress-class 不一致。

Kubernetes Network Policy Generator

使用加权评分卡在12项标准上评估和比较隐私解决方案供应商。适用于选择隐私管理软件、比较数据保护方案等场景。

下载

使用 Helm 部署时，--set controller.ingressClass.name=nginx 会同时创建 ingressclass.networking.k8s.io/nginx 资源，并让控制器只处理该类 Ingress

你的 Ingress YAML 必须包含：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
spec:
  ingressClassName: nginx  # ← 必须和 Helm 设置的 name 严格一致
  rules: ...

旧版 YAML 部署方式常漏掉这步，或误设为 nginx-ingress，导致控制器直接忽略该资源

Traefik 和 ingress-nginx 混用时的路由冲突风险

两者可以共存，但不能共享同一个 ingressClass 名。若你用 Helm 同时部署了 traefik（默认 ingressClass.name=traefik）和 ingress-nginx（默认 ingressClass.name=nginx），看似隔离，但问题出在全局默认行为上：

Kubernetes 1.22+ 默认禁用无 ingressClassName 的 Ingress；低于此版本则可能被任一控制器“抢走”处理权
Traefik 的 providers.kubernetesIngress.ingressClass 参数若未显式设为空字符串，它会监听所有 Ingress（包括没设 ingressClassName 的）
ingress-nginx 默认只处理明确指定 ingressClassName: nginx 的资源，更守规矩；Traefik 更“主动”，容易造成非预期接管
验证方法：kubectl get ingressclass 看是否多于一个，再检查每个 Ingress 的 ingressClassName 字段是否唯一指向某一个