ingress-nginx与K8s版本兼容升级集群前怎么选对tag【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx如果你最近把集群升到 K8s 1.33随后又做了 ingress-nginx 升级很可能碰见过这两种现象控制器 Pod 运行正常但新 Ingress 规则不再生效或者请求全部返回 404。这些问题大多指向版本兼容而不是应用本身。本文以项目 README 的 supported versions 表格为基准讲清楚 tag 怎么选、升级怎么执行、升级完怎么验证。集群升级后的三个典型故障现场K8s 小版本升级后最先出问题的通常是控制器与 API Server 的配合。三种高频症状值得先认脸症状一新 Ingress 规则不生效创建了新 Ingress 后规则始终没写进 Pod 内的 nginx.conf。先确认 Ingress 上的ingressClassName指向的类确实存在且由当前控制器负责kubectl get ingressclass kubectl get ing -AK8s 1.24 起extensions/v1beta1.Ingress旧 API 已被移除未迁移到networking.k8s.io/v1的资源会被对应版本的控制器直接忽略这是旧集群升级时最常见的隐性失配。症状二控制器日志里刷 forbidden日志中出现下面这行说明 ServiceAccount 的权限缺失或 Role 过期ingresses.networking.k8s.io is forbidden: User system:serviceaccount:ingress-nginx:ingress-nginx-controller cannot list resource ingresses需要核对的权限清单见 docs/deploy/rbac.md。重新应用 chart 或 manifest 里的 RBAC 资源通常就能消除这条错误。症状三配置同步了流量却全部 404控制器在跑、配置也同步了但访问全是 404。此时重点看 default-backend 是否 Ready、Service 的 selector 与 targetPort 是否还与控制器约定一致以及 ConfigMap 中是否有新版本已不识别的残留项。读懂 supported versions 表1.33 集群该选哪个 tagREADME 中的 Supported Versions table 有一句话值得留意表内版本表示该组合已通过 E2E 测试表外版本可能能用但项目不做保证。选 tag 的动作因此很直接——看集群版本落在哪一行的覆盖区间里。控制器版本K8s 支持区间Nginx 版本Alpine 版本对应 Helm Chartv1.15.11.31–1.351.27.13.23.34.15.1v1.14.51.30–1.341.27.13.23.34.14.5v1.13.91.29–1.331.27.13.23.34.13.9v1.12.81.28–1.321.25.53.22.24.12.8完整版本对照见 README。集群已到 1.34、1.35 时只剩 v1.14.x 与 v1.15.x 两条线可选v1.13.x 及更早的版本覆盖不到。如果你的集群还在 1.28–1.32 且希望保守升级v1.12.8 这条线区间合适但要留意它内置 Nginx 1.25.5与 v1.13 的 1.27.1 不是同一分支依赖自定义指令或 Lua 行为的配置要先行验证。节点横跨 1.29–1.33 的混合集群v1.13.9 的覆盖区间恰好整段包住是天然的折中选择。升级前核对三件事执行任何升级命令之前先把这三项落纸面能省一轮回滚节点版本kubectl get nodes -o wide确认每个节点的实际 Kubelet 版本避免某个节点落后大版本。当前安装方式与版本Helm 安装用helm list -n ingress-nginx记录 chart 版本manifest 安装用kubectl get deployment ingress-nginx-controller -n ingress-nginx -o jsonpath{.spec.template.spec.containers[0].image}记下镜像 tag。模板覆盖检查官方升级文档明确提示若安装时覆盖过默认模板必须确认该模板与新版本兼容否则控制器会用旧模板生成 nginx.conf轻则 reload 失败重则无法启动。说明见 docs/deploy/upgrade.md。升级执行Helm 与裸 manifest 两条路径裸 manifest改一个镜像 tag非 Helm 安装的官方建议就是直接替换 Deployment 里的控制器镜像升级前先记下现值再替换 tagkubectl set image deployment/ingress-nginx-controller \ controllerregistry.k8s.io/ingress-nginx/controller:v1.13.9 \ -n ingress-nginx需要同时调整其他字段时可改用kubectl edit deployment ingress-nginx-controller -n ingress-nginx交互式编辑。Helm复用现有 values 并锁定版本Helm 安装用--reuse-values带上当前 values再用--version把 chart 固定到与控制器匹配的版本号helm upgrade --reuse-values --version 4.13.9 \ ingress-nginx ingress-nginx/ingress-nginx -n ingress-nginx从旧 stable/nginx-ingress 迁移的用户资源名与标签都有变化chart 的 README 中有专门的迁移小节charts/ingress-nginx/README.md。升级后验证从 rollout 到配置重载指标滚动完成后用下面命令确认新 Pod 全部 Readykubectl rollout status deployment/ingress-nginx-controller -n ingress-nginxPod 就绪之后挑一条业务 Ingress 看 Events 与访问日志确认规则真实生效kubectl describe ing ingress-name -n namespace最硬的信号是配置重载指标nginx_ingress_controller_config_last_reload_successful应为 1且nginx_ingress_controller_config_last_reload_timestamp_seconds落在升级时间之后指标定义见 docs/user-guide/monitoring.md。已有 Prometheus Grafana 的环境可以直接看面板若重载指标为 0说明生成的 nginx.conf 没通过nginx -t控制器会停留在旧配置。此时对照对应版本的变更清单定位是哪个配置项或注解触发了校验失败changelog/ 目录按 release 逐份记录了变更。延伸阅读docs/deploy/upgrade.md官方升级步骤与模板兼容警告docs/deploy/rbac.mdServiceAccount 所需权限清单docs/troubleshooting.md完整排障流程docs/faq.md多实例、IngressClass 等常见问题deploy/prometheus/、deploy/grafana/监控栈参考清单版本矩阵随每个 release 滚动更新动手前先以 README 的 supported versions 表格为准把 tag 对齐到集群当前的 K8s 版本区间。【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ingress-nginx与K8s版本兼容：升级集群前怎么选对tag
ingress-nginx与K8s版本兼容升级集群前怎么选对tag【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx如果你最近把集群升到 K8s 1.33随后又做了 ingress-nginx 升级很可能碰见过这两种现象控制器 Pod 运行正常但新 Ingress 规则不再生效或者请求全部返回 404。这些问题大多指向版本兼容而不是应用本身。本文以项目 README 的 supported versions 表格为基准讲清楚 tag 怎么选、升级怎么执行、升级完怎么验证。集群升级后的三个典型故障现场K8s 小版本升级后最先出问题的通常是控制器与 API Server 的配合。三种高频症状值得先认脸症状一新 Ingress 规则不生效创建了新 Ingress 后规则始终没写进 Pod 内的 nginx.conf。先确认 Ingress 上的ingressClassName指向的类确实存在且由当前控制器负责kubectl get ingressclass kubectl get ing -AK8s 1.24 起extensions/v1beta1.Ingress旧 API 已被移除未迁移到networking.k8s.io/v1的资源会被对应版本的控制器直接忽略这是旧集群升级时最常见的隐性失配。症状二控制器日志里刷 forbidden日志中出现下面这行说明 ServiceAccount 的权限缺失或 Role 过期ingresses.networking.k8s.io is forbidden: User system:serviceaccount:ingress-nginx:ingress-nginx-controller cannot list resource ingresses需要核对的权限清单见 docs/deploy/rbac.md。重新应用 chart 或 manifest 里的 RBAC 资源通常就能消除这条错误。症状三配置同步了流量却全部 404控制器在跑、配置也同步了但访问全是 404。此时重点看 default-backend 是否 Ready、Service 的 selector 与 targetPort 是否还与控制器约定一致以及 ConfigMap 中是否有新版本已不识别的残留项。读懂 supported versions 表1.33 集群该选哪个 tagREADME 中的 Supported Versions table 有一句话值得留意表内版本表示该组合已通过 E2E 测试表外版本可能能用但项目不做保证。选 tag 的动作因此很直接——看集群版本落在哪一行的覆盖区间里。控制器版本K8s 支持区间Nginx 版本Alpine 版本对应 Helm Chartv1.15.11.31–1.351.27.13.23.34.15.1v1.14.51.30–1.341.27.13.23.34.14.5v1.13.91.29–1.331.27.13.23.34.13.9v1.12.81.28–1.321.25.53.22.24.12.8完整版本对照见 README。集群已到 1.34、1.35 时只剩 v1.14.x 与 v1.15.x 两条线可选v1.13.x 及更早的版本覆盖不到。如果你的集群还在 1.28–1.32 且希望保守升级v1.12.8 这条线区间合适但要留意它内置 Nginx 1.25.5与 v1.13 的 1.27.1 不是同一分支依赖自定义指令或 Lua 行为的配置要先行验证。节点横跨 1.29–1.33 的混合集群v1.13.9 的覆盖区间恰好整段包住是天然的折中选择。升级前核对三件事执行任何升级命令之前先把这三项落纸面能省一轮回滚节点版本kubectl get nodes -o wide确认每个节点的实际 Kubelet 版本避免某个节点落后大版本。当前安装方式与版本Helm 安装用helm list -n ingress-nginx记录 chart 版本manifest 安装用kubectl get deployment ingress-nginx-controller -n ingress-nginx -o jsonpath{.spec.template.spec.containers[0].image}记下镜像 tag。模板覆盖检查官方升级文档明确提示若安装时覆盖过默认模板必须确认该模板与新版本兼容否则控制器会用旧模板生成 nginx.conf轻则 reload 失败重则无法启动。说明见 docs/deploy/upgrade.md。升级执行Helm 与裸 manifest 两条路径裸 manifest改一个镜像 tag非 Helm 安装的官方建议就是直接替换 Deployment 里的控制器镜像升级前先记下现值再替换 tagkubectl set image deployment/ingress-nginx-controller \ controllerregistry.k8s.io/ingress-nginx/controller:v1.13.9 \ -n ingress-nginx需要同时调整其他字段时可改用kubectl edit deployment ingress-nginx-controller -n ingress-nginx交互式编辑。Helm复用现有 values 并锁定版本Helm 安装用--reuse-values带上当前 values再用--version把 chart 固定到与控制器匹配的版本号helm upgrade --reuse-values --version 4.13.9 \ ingress-nginx ingress-nginx/ingress-nginx -n ingress-nginx从旧 stable/nginx-ingress 迁移的用户资源名与标签都有变化chart 的 README 中有专门的迁移小节charts/ingress-nginx/README.md。升级后验证从 rollout 到配置重载指标滚动完成后用下面命令确认新 Pod 全部 Readykubectl rollout status deployment/ingress-nginx-controller -n ingress-nginxPod 就绪之后挑一条业务 Ingress 看 Events 与访问日志确认规则真实生效kubectl describe ing ingress-name -n namespace最硬的信号是配置重载指标nginx_ingress_controller_config_last_reload_successful应为 1且nginx_ingress_controller_config_last_reload_timestamp_seconds落在升级时间之后指标定义见 docs/user-guide/monitoring.md。已有 Prometheus Grafana 的环境可以直接看面板若重载指标为 0说明生成的 nginx.conf 没通过nginx -t控制器会停留在旧配置。此时对照对应版本的变更清单定位是哪个配置项或注解触发了校验失败changelog/ 目录按 release 逐份记录了变更。延伸阅读docs/deploy/upgrade.md官方升级步骤与模板兼容警告docs/deploy/rbac.mdServiceAccount 所需权限清单docs/troubleshooting.md完整排障流程docs/faq.md多实例、IngressClass 等常见问题deploy/prometheus/、deploy/grafana/监控栈参考清单版本矩阵随每个 release 滚动更新动手前先以 README 的 supported versions 表格为准把 tag 对齐到集群当前的 K8s 版本区间。【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
