NGINX Ingress Controller 5.6 implements more support for configuring NGINX through resources instead of through snippets. HTTP Strict Transport Security (HSTS) becomes a first-class policy across VirtualServer, VirtualServerRoute, and Ingress. Two new annotations close configuration gaps for teams moving off Ingress-NGINX, and the X-Forwarded base headers can now be turned off through the ConfigMap.
Operational concerns got attention too. Startup is faster on large clusters, upstream services in another namespace keep their endpoints current, the Helm chart can declare a NetworkPolicy for you, and secret rotation reloads NGINX for every secret type rather than just TLS. Five of these changes came from our community, and each contributor is credited next to their work.
This release blog focuses on the new OSS features, but NGINX Ingress Controller 5.6 also includes some significant F5 integrations! For more info on these, read through our DevCentral release article here.
What’s new: HSTS is configurable natively on VirtualServer, VirtualServerRoute, and Ingress resources (nginx/kubernetes-ingress#10111).
Why it matters: HSTS tells a browser to reach your site over HTTPS and nothing else. Enforcing it used to mean a snippet, which your Kubernetes tooling cannot validate, so nothing catches a mistake in it before it reaches production. A first-class policy is reviewable, and it behaves the same way on every resource type you attach it to, so the Ingress your team ships this week and the VirtualServer it migrates to next quarter enforce the same thing.
What’s new: Three changes give you more say over what NGINX Ingress Controller sends upstream and what it returns on an error, while improving Ingress-NGINX compatibility:
nginx.org/upstream-vhost sets the Host header sent upstream: It takes a fixed lowercase RFC 1123 subdomain and emits a warning event on the Ingress if nginx.org/proxy-set-headers also sets Host (nginx/kubernetes-ingress#10557). nginx.org/custom-http-errors serves custom error pages: Responses in the configured status codes are passed to a named default backend instead of returned as-is (nginx/kubernetes-ingress#10423). disable-forwarded-headers turns the X-Forwarded base headers off: A ConfigMap value that stops NGINX Ingress Controller setting X-Forwarded-For, -Host, -Port, and -Proto on Ingress and VirtualServer resources. It defaults to false (nginx/kubernetes-ingress#10539). Why it matters: The two annotations above help you migrate from Ingress-NGINX, and close some configuration gaps. Without upstream-vhost, a migrated application receives the controller’s internal host instead of the client-facing domain. The custom-http-errors annotation simplifies header handling and custom error pages. The ConfigMap switch answers a different question. Where a load balancer or CDN in front of NGINX Ingress Controller has already set the X-Forwarded headers, the controller was overwriting them, so your backend saw the controller rather than the original client.
What’s new: Upstream services in another namespace now receive endpoint updates (nginx/kubernetes-ingress#9676).
Why it matters: Cross-namespace backends used to go stale as pods came and went, so traffic kept being sent to endpoints that no longer existed. That surfaces as application errors, so you go looking at the application rather than at routing. If you split services across namespaces by team or tenant, this is worth the upgrade on its own.
What’s new: With -enable-config-safety active, startup writes all configuration files first and runs a single nginx -t over the whole tree, instead of validating before writing each file. If that check fails, the controller works out which resources produced the invalid configuration, drops just those, and starts with the rest — the excluded resources are logged so you can see what did not load. On a test cluster with 250 Ingresses and 250 VirtualServers, startup went from 107 seconds to 6 seconds (nginx/kubernetes-ingress#10032).
Why it matters: The old implementation revalidated the whole configuration before writing each resource’s file, so startup cost grew with the square of the resource count — the bigger your cluster, the longer you waited. Batching keeps the safety check that config safety exists for, and a bad resource still cannot take the others down with it.
What’s new: The chart takes a new controller.networkPolicy section: an enabled flag plus configurable ingress and egress rules, with schema validation and snapshot coverage. The podSelector derives from nginx-ingress.selectorLabels so it always targets the right controller pods, and policyTypes is generated from whichever rule sets you define. Developed by community contributor GabboPenna (nginx/kubernetes-ingress#8052), with a follow-up so helm upgrade --reuse-values works from a release that predates the template (nginx/kubernetes-ingress#10714).
Why it matters: Restricting what the controller pods can reach is a common requirement, and until now it meant keeping a NetworkPolicy manifest outside the chart and its selectors in step with whatever the chart rendered. Declaring it in values.yaml keeps the policy and the workload it protects together, and the selector cannot drift because the template derives it.
What’s new: The -ssl-dynamic-reload optimization is narrowed to TLS server secrets, so rotating any other kind of secret reloads NGINX the way you would expect. Developed by community contributor dkulchinsky (nginx/kubernetes-ingress#10390).
Why it matters: The optimization only ever made sense for ssl_certificate, which NGINX can pick up at request time. Every other secret type is read when the configuration loads, so rotating a CA, JWK, htpasswd, OIDC, or API key secret quietly did nothing until some unrelated event forced a reload.
resource_namespace attribute: One controller often serves many teams, and knowing which namespace an error came from saves debugging time (nginx/kubernetes-ingress#10373)./variables and /rootpage are valid. The regex matched /var and /root anywhere in a path, turning ordinary application paths away as attempts to reach sensitive directories; /root/.ssh and the rest stay blocked. Developed by community contributor hugolevino (nginx/kubernetes-ingress#10176).tls block has no secretName. That lookup can never succeed, and logged a misleading “secret doesn’t exist” warning on every sync — thousands per resync on a large multi-tenant cluster. Developed by community contributor rahulii (nginx/kubernetes-ingress#10543).authSigninURI emits error_page 401 = "..." as it should. (nginx/kubernetes-ingress#10594)499 is no longer accepted in nginx.org/custom-http-errors: NGINX rejects the code, so allowing it failed an NGINX reload (nginx/kubernetes-ingress#10507).resources block for the enforcer and configManager containers, validated against the values schema. Before this, both ran with whatever the node would give them. Developed by community contributor jxn (nginx/kubernetes-ingress#9010).From this release on, we’re crediting the community members who contribute to NGINX Ingress Controller, and naming their work where it lands. Whether you contributed code, helped shape a feature, or reported major bugs, thank you!
Five community members had work land in NGINX Ingress Controller 5.6: three bug fixes, NetworkPolicy support in the Helm chart, and resource limits for the WAF sidecars. Every one of them is credited above, next to the change they made. Thanks to dkulchinsky, GabboPenna, hugolevino, jxn, and rahulii. Your contributions in this release have helped shape NGINX Ingress Controller 5.6!
Pick up an open issue, contribute a feature you developed, or fix a bug you have run into. The contributing guide covers how to get started, from opening a discussion to sending your first pull request.
Head over to the GitHub release page for the full changelog, and the NGINX Ingress Controller docs when you’re ready to upgrade to 5.6. If you’re moving over from Ingress-NGINX, the Kubernetes NGINX landing page covers the migration. For more information on the enterprise level features included in this release, check out our DevCentral article here.
We’re proud of what the team and the community built here, and we hope it makes your clusters easier to run.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。