2021 archive

2.0.3

28 October 2021

Breaking Changes

  • 2124 Apply -enable-snippets cli arg to Ingresses. This PR extends the existing -enable-snippets cli argument to apply to Ingress resources. If snippets are not enabled, the Ingress Controller will reject any Ingress resources with snippets annotations. Previously, the argument only applied to VirtualServer, VirtualServerRoute and TransportServer resources. Please Note: this is a breaking change. See the UPGRADE instructions below.

Fixes

  • 2132 Install libcurl on OpenTracing for NGINX Plus.

Upgrade

  • For NGINX, use the 2.0.3 image from our DockerHub: nginx/nginx-ingress:2.0.3, nginx/nginx-ingress:2.0.3-alpine or nginx/nginx-ingress:2.0.3-ubi
  • For NGINX Plus, please build your own image using the 2.0.3 source code.
  • For Helm, use version 0.11.3 of the chart.
  • We changed the behaviour of snippets in Ingress resources by extending the existing -enable-snippets cli argument to apply to Ingress resources as well as VirtualServer, VirtualServerRoute and TransportServer resources. Because the default value of -enable-snippets is false, if you are using snippets in Ingress resources, you must explicitly set the -enable-snippets to true before upgrading the Ingress Controller, so that the new version of the Ingress Controller doesn’t reject Ingresses with snippets annotations.

1.12.3

28 October 2021

Fixes

  • 2133 Use release specific repo for the App Protect packages on Debian. This fixes an error when building Debian-based images with NGINX Plus with App Protect: previously, building an image would fail with the error nginx-plus-module-appprotect : Depends: app-protect-plugin (= 3.639.0-1~buster) but 3.671.0-1~buster is to be installed. The bug first appeared when NGINX App Protect version 3.6 was released on 13 October 2021.
  • 2134 Apply -enable-snippets cli arg to Ingresses. This PR extends the existing -enable-snippets cli argument to apply to Ingress resources. If snippets are not enabled, the Ingress Controller will reject any Ingress resources with snippets annotations. Previously, the argument only applied to VirtualServer, VirtualServerRoute and TransportServer resources. Please Note: this is a breaking change. See the UPGRADE instructions below.

Upgrade

  • For NGINX, use the 1.12.3 image from our DockerHub: nginx/nginx-ingress:1.12.3, nginx/nginx-ingress:1.12.3-alpine or nginx/nginx-ingress:1.12.3-ubi
  • For NGINX Plus, please build your own image using the 1.12.3 source code.
  • For Helm, use version 0.10.3 of the chart.
  • We changed the behaviour of snippets in Ingress resources by extending the existing -enable-snippets cli argument to apply to Ingress resources as well as VirtualServer, VirtualServerRoute and TransportServer resources. Because the default value of -enable-snippets is false, if you are using snippets in Ingress resources, you must explicitly set the -enable-snippets to true before upgrading the Ingress Controller, so that the new version of the Ingress Controller doesn’t reject Ingresses with snippets annotations.

2.0.2

13 October 2021

Dependencies

  • Update NGINX App Protect version to 3.6.
  • Update NGINX Plus version to R25 in NGINX App Protect enabled images.

Features

  • 2074 Update JWT library to golang-jwt/jwt. Previously, the Ingress Controller used dgrijalva/jwt-go, which has a vulnerability CVE-2020-26160. Note that the Ingress Controller wasn’t affected by this vulnerability, and the jwt library was used only in the NGINX Plus images from AWS Marketplace for Containers.

Upgrade

  • For NGINX, use the 2.0.2 image from our DockerHub.
  • For NGINX Plus, use the 2.0.2 from the F5 Container registry or build your own image using the 2.0.2 source code.
  • For Helm, use version 0.11.2 of the chart.

2.0.1

07 October 2021

Fixes

  • 2051 Use release specific repo for NGINX Plus on Debian. This fixes an error when building the Debian-based image with NGINX Plus and App Protect: previously, building the image would fail with the error Package 'nginx-plus-r24' has no installation candidate.

Upgrade

  • For NGINX, use the 2.0.1 image from our DockerHub.
  • For NGINX Plus, use the 2.0.1 from the F5 Container registry or build your own image using the 2.0.1 source code.
  • For Helm, use version 0.11.1 of the chart.

1.12.2

7 October 2021

Fixes

  • 2048 Use release specific repo for NGINX Plus on Debian. This fixes an error when building Debian-based images with NGINX Plus: previously, building an image would fail with the error Package 'nginx-plus-r24' has no installation candidate. The bug first appeared when NGINX Plus R25 was released on 28 September 2021.

Upgrade

  • For NGINX, use the 1.12.2 image from our DockerHub: nginx/nginx-ingress:1.12.2, nginx/nginx-ingress:1.12.2-alpine or nginx/nginx-ingress:1.12.2-ubi
  • For NGINX Plus, please build your own image using the 1.12.2 source code.
  • For Helm, use version 0.10.2 of the chart.

2.0.0

28 September 2021

Overview

Release 2.0.0 includes:

  • Support for Ingress networking.k8s.io/v1. Kubernetes 1.22 removes support for networking.k8s.io/v1beta1. To support Kubernetes 1.22, NGINX Ingress Controller 2.0 is also compatible with only the networking.k8s.io/v1 version of the Ingress and IngressClass resources. This has the following implications:

    1. The minimum supported version of Kubernetes is now 1.19. For older Kubernetes versions, use the 1.12.x release of the Ingress Controller.

    2. For Kubernetes versions 1.19-1.21, you can continue using the networking.k8s.io/v1beta1 of the Ingress and IngressClass resources.

    3. For Kubernetes 1.22, you need to migrate your Ingress and IngressClass resources to networking.k8s.io/v1.

    4. If you are using the deprecated kubernetes.io/ingress.class annotation in your Ingress resources, it is recommended to switch to the ingressClassName field.

      We migrated all our documentation and examples to use networking.k8s.io/v1 and the ingressClassName field of the Ingress resource.

  • Scalability improvements. We improved the time for an Ingress Controller pod to become ready and start receiving traffic. This is especially noticeable when you have hundreds of Ingress or other configuration resources like VirtualServers: instead of several minutes or more in rare cases, a pod will become ready within a few minutes.
  • Documentation improvements We changed the look and feel of our documentation as well as the underlying publishing technology, which will allow us to bring even more improvements in the next releases.
  • Upgrade path for k8s.nginx.org/v1alpha1 Policy resource If you’re running release 1.9.0 and using the k8s.nginx.org/v1alpha1 Policy, the Ingress Controller now supports an upgrade path from v1alpha1 to v1 Policy version without downtime. See UPDATING POLICIES section below.

You will find the complete changelog for release 2.0.0, including bug fixes, improvements, and changes below.

Breaking Changes

  • 1850 Support Ingress and IngressClass v1.

Features

  • 1908 Add NTLM support to VirtualServer and VirtualServerRoute upstreams.
  • 1746 Add ingressClassName field to Policy.
  • 1956 Add v1alpha1 version back to policy CRD.
  • 1907 Remove libs compilation for OpenTracing in Dockerfile; add Zipkin and Datadog in addition to the already supported Jaeger tracer; additionally, for NGINX we now publish a Docker image with the tracers and the OpenTracing module on DockerHub: nginx-ic/nginx-plus-ingress:1.12.0-ot. Also thanks to MatyRi for upgrading OpenTracing in 1883.
  • 1788 Reload only once during the start. This significantly reduces the time it takes for an Ingress Controller pod to become ready when hundreds of Ingress or other supported resources are created in the cluster.
  • 1721 Increase default reload timeout to 60s: the Ingress Controller will wait for 60s for NGINX to start or reload. Previously, the default was 4 seconds.
  • 2009 Increase default upstream zone size for NGINX Plus. See the INCREASED UPSTREAM ZONES section below.

Fixes

  • 1926 Fix increased IC pod startup time when hundreds of VirtualServerRoutes are used
  • 1712 Allow make to build image when .git directory is missing.

Documentation

  • 1932 Add IAM instructions for NGINX Plus AWS Marketplace images.
  • 1927 Fix function name comments typo. Thanks to Sven Nebel.
  • 1898 Add instructions for configuring MyF5 JWT as a Docker registry secret for the F5 Container registry for NGINX Plus images.
  • 1851 Update docs and examples to use networking.k8s.io/v1.
  • 1765 Create documentation for pulling NGINX Plus images from the F5 Container registry.
  • 1740 Publish docs using Hugo and Netlify.
  • 1702 Add security recommendations documentation.

Helm Chart

  • Add new parameters to the Chart: controller.pod.extraLabels. Added in 1884.

Dependencies

  • 1855 Update minimum Kubernetes version to 1.19; remove the -use-ingress-class-only command-line argument, which doesn’t work with Kubernetes >= 1.19.
  • Update NGINX Plus version to R25. Note: images with NGINX App Protect will continue to use R24 until App Protect 3.6 is released.
  • Update NGINX version to 1.21.3.

Upgrade

  • For NGINX, use the 2.0.0 image from our DockerHub.
  • For NGINX Plus, use the 2.0.0 from the F5 Container registry or build your own image using the 2.0.0 source code.
  • For Helm, use version 0.11.0 of the chart.

See the complete list of supported images for NGINX and NGINX Plus on the Technical Specifications page.

INCREASED UPSTREAM ZONES

We increased the default size of an upstream zone from 256K to 512K to accommodate a change in NGINX Plus R25. The change makes NGINX Plus allocate more memory for storing upstream server (peer) data, which means upstream server zones will use more memory to account for that new data.

The increase in the zone size is to prevent NGINX Plus configuration reload failures after an upgrade to release 1.13.0. Note that If a zone becomes full, NGINX Plus will fail to reload and fail to add more upstream servers via the API.

The new 512K default value will be able to hold ~270 upstream servers per upstream, similarly to how the old 256K value was able to hold the same number of upstream servers in the previous Ingress Controller releases. You can understand the utilization of the upstream zones via NGINX Plus API and the NGINX Plus dashboard (the shared zones tab).

If you have a large number of upstream in the NGINX Plus configuration of the Ingress Controller, expect that after an upgrade NGINX Plus will consume more memory: +256K per upstream. If you don’t have upstreams with huge number of upstream serves and you’d like to reduce the memory usage of NGINX Plus, you can configure the upstream-zone-size ConfigMap key with a lower value. Additionally, the Ingress resource supports nginx.org/upstream-zone-size annotation to configure zone sizes for the upstreams of an Ingress resource rather than globally.

UPDATING POLICIES

This section is only relevant if you’re running release 1.9.0 and planning to upgrade to release 2.0.0.

Release 1.10 removed the k8s.nginx.org/v1alpha1 version of the Policy resource and introduced the k8s.nginx.org/v1 version. This means that to upgrade to release 1.10 users had to re-create v1alpha1 Policies with the v1 version, which caused downtime for their applications. Release 2.0.0 brings back the support for the v1alpha1 Policy, which makes it possible to upgrade from 1.9.0 to 2.0.0 release without causing downtime:

  • If the Policy is marked as a preview feature in the documentation, make sure the -enable-preview-policies command-line argument is set in 2.0.0 Ingress Controller.
  • During the upgrade, the existing Policies will not be removed.
  • After the upgrade, make sure to update the Policy manifests to k8s.nginx.org/v1 version.

Please also read the release 1.10 changelog for the instructions on how to update Secret resources, which is also necessary since some of the Policies reference Secrets.

Note that 2.1.0 will remove support for the v1alpha1 version of the Policy.

Supported Platforms

We will provide technical support for NGINX Ingress Controller on any Kubernetes platform that is currently supported by its provider and which passes the Kubernetes conformance tests. This release was fully tested on the following Kubernetes versions: 1.19-1.22.

1.12.1

8 September 2021

Dependencies

  • Update NGINX App Protect version to 3.5.

Upgrade

  • For NGINX, use the 1.12.1 image from our DockerHub: nginx/nginx-ingress:1.12.1, nginx/nginx-ingress:1.12.1-alpine or nginx/nginx-ingress:1.12.1-ubi
  • For NGINX Plus, use the 1.12.1 image from the F5 Container Registry - see the documentation here
  • Alternatively, you can also build your own image using the 1.12.1 source code.
  • For Helm, use version 0.10.1 of the chart.

1.12.0

30 June 2021

Overview

Release 1.12.0 includes:

  • The introduction of pre-built containers for advanced capabilities with NGINX Plus through the F5 Container Registry.
  • TransportServer supports TCP/UDP connections through the NGINX streams module adding support for matching specific health check response patterns for granular availability testing of your application, maximum connections to protect your applications from overload, supporting fine tuning of load balancing behavior, and snippets for advanced capability support as soon as you are ready to implement.
  • Availability through the AWS Container marketplace supporting Elastic Kubernetes Service.
  • NGINX App Protect capabilities have been extended to support the latest version and its capabilities.

You will find the complete changelog for release 1.12.0, including bug fixes, improvements, and changes below.

Features

  • 1633 Support match in TransportServer health checks.
  • 1619 Add AWS Marketplace Entitlement verification.
  • 1480 Add max connections to TransportServer.
  • 1479 Add load balancing method to TransportServer.
  • 1466 Support snippets in TransportServer.
  • 1578 Add support for CSRF protection in APPolicy.
  • 1513 Support multiple log security configs in Ingresses.
  • 1481 Add support for user defined browsers in APPolicy.
  • 1411 Add unary gRPC support in APPolicy.
  • 1671 Simplify Dockerfile stages for Debian.
  • 1652 Add HTTPS option to Prometheus endpoint.
  • 1646 Improve Dockerfile.
  • 1574 Add Docker image for Alpine with NGINX Plus.
  • 1512 Don’t require default server TLS secret.
  • 1500 Support ssl_reject_handshake in Ingress and VS.
  • 1494 Add logs around NGINX Plus binary/flag mismatch.
  • 1492 Update the IC so that GlobalConfiguration is not mandatory when configured.
  • 1500 Support ssl_reject_handshake in Ingress and VS. Previously, to handle missing or invalid TLS Secrets in Ingress and VirtualServer resources, the Ingress Controller would configure NGINX to break any attempts for clients to establish TLS connections to the affected hosts using ssl_ciphers NULL; in the NGINX configuration. The method didn’t work for TLS v1.3. Now the Ingress Controller uses ssl_reject_handshake on;, which works for TLS v1.3.
  • Documentation improvements: 1649.

Fixes

  • 1658 Add missing njs module to the openshift-image-nap-plus image.
  • 1654 Fix incorrect configuration and unexpected warnings about Secrets at the IC start.
  • 1501 Fix ungraceful shutdown of NGINX.
  • Documentation fixes: 1668, 1594 thanks to shaggy245, 1563, 1551.

Helm Chart

  • Add new parameters to the Chart: prometheus.scheme, prometheus.secret. Added in 1652.

Dependencies

  • 1604 Update NGINX Plus to R24. Previously, the Dockerfile had a fixed NGINX Plus version. Now the Dockerfile has a floating version that corresponds to the latest major NGINX Plus version. In the event of a patch version of NGINX Plus being released, make sure to rebuild your image to get the latest version (previously, we released a new Ingress Controller release in that case). Additionally, the AppProtect related packages are no longer fixed – the Dockerfile will always install the latest version of the packages that work with the latest NGINX Plus version.
  • Update NGINX version to 1.21.0.

Upgrade

  • For NGINX, use the 1.12.0 image from our DockerHub: nginx/nginx-ingress:1.12.0, nginx/nginx-ingress:1.12.0-alpine or nginx-ingress:1.12.0-ubi
  • For NGINX Plus, please build your own image using the 1.12.0 source code.
  • For Helm, use version 0.10.0 of the chart.

Supported Platforms

We will provide technical support for NGINX Ingress Controller on any Kubernetes platform that is currently supported by its provider and which passes the Kubernetes conformance tests. This release was fully tested on the following Kubernetes versions: 1.16-1.21.

1.11.3

25 May 2021

Dependencies

  • Update NGINX version to 1.21.0.

Upgrade

  • For NGINX, use the 1.11.3 image from our DockerHub: nginx/nginx-ingress:1.11.3, nginx/nginx-ingress:1.11.3-alpine or nginx/nginx-ingress:1.11.3-ubi
  • For NGINX Plus, please build your own image using the 1.11.3 source code.
  • For Helm, use version 0.9.3 of the chart.

1.11.2

19 May 2021

Dependencies

  • Update NGINX Plus version to R23 P1.

Upgrade

  • For NGINX, use the 1.11.2 image from our DockerHub: nginx/nginx-ingress:1.11.2, nginx/nginx-ingress:1.11.2-alpine or nginx/nginx-ingress:1.11.2-ubi
  • For NGINX Plus, please build your own image using the 1.11.2 source code.
  • For Helm, use version 0.9.2 of the chart.

1.11.1

7 April 2021

Dependencies

  • Update NGINX version to 1.19.9.
  • Update the OpenSSL libraries used in the UBI images

Upgrade

  • For NGINX, use the 1.11.1 image from our DockerHub: nginx/nginx-ingress:1.11.1, nginx/nginx-ingress:1.11.1-alpine or nginx/nginx-ingress:1.11.1-ubi
  • For NGINX Plus, please build your own image using the 1.11.1 source code.
  • For Helm, use version 0.9.1 of the chart.

1.11.0

31 March 2021

Overview

Release 1.11.0 includes:

  • Native NGINX Ingress Controller App Protect (WAF) policy
  • TransportServer improvements in terms of reliability, added features and operational aspects
  • Integration of NGINX Ingress Controller with Istio service mesh

You will find the complete changelog for release 1.11.0, including bug fixes, improvements, and changes below.

Features

  • 1317 Add status field to Policy resource.
  • 1449 Add support for ClusterIP in upstreams in VirtualServers/VirtualServerRoutes.
  • 1413 Add serverSnippets to TransportServer.
  • 1425 Add status field to TransportServer resource.
  • 1384 Add active health checks to TransportServer.
  • 1382 Add passive health checks to TransportServer.
  • 1346 Add configurable timeouts to TransportServer.
  • 1297 Support custom return in the default server. Thanks to 030.
  • 1378 Add WAF Policy.
  • 1420 Support IngressClassName in TransportServer.
  • 1415 Handle host and listener collisions for TransportServer resource.
  • 1322 Improve VirtualServer/VirtualServerRoute warnings for Policies.
  • 1288 Add stricter validation for some ingress annotations.
  • 1241 Refactor Dockerfile and Makefile.
  • Documentation improvements: 1320, 1326, and 1377.

Fixes

  • 1457 Wait for caches to sync when the Ingress Controller starts.
  • 1444 Fix setting host header in action proxy in VirtualServer/VirtualServerRoute.
  • 1396 Fix reload timeout calculation for verifying NGINX reloads.

Dependencies

Known Issues

  • 1448 When an Ingress Controller pod starts, it can report warnings about missing secrets for Ingress and other resources that reference secrets. Those warnings are intermittent - once the Ingress Controller fully processes the resources of the cluster, it will clear the warnings. Only after that, the Ingress Controller will become ready to accept client traffic - its readiness probe will succeed.

Upgrade

  • For NGINX, use the 1.11.0 image from our DockerHub: nginx/nginx-ingress:1.11.0, nginx/nginx-ingress:1.11.0-alpine or nginx-ingress:1.11.0-ubi
  • For NGINX Plus, please build your own image using the 1.11.0 source code.
  • For Helm, use version 0.9.0 of the chart.
  • 1241 improved the Makefile. As a result, the commands for building the Ingress Controller image were changed. See the updated commands here.
  • 1241 also consolidated all Dockerfiles into a single Dockerfile. If you customized any of the Dockerfiles, make sure to port the changes to the new Dockerfile.
  • 1288 further improved validation of Ingress annotations. See this document to learn more about which annotations are validated. Note that the Ingress Controller will reject resources with invalid annotations, which means clients will see 404 responses from NGINX. Before upgrading, ensure the Ingress resources don’t have annotations with invalid values. Otherwise, after the upgrade, the Ingress Controller will reject such resources.
  • 1457 fixed the bug when an Ingress Controller pod could become ready before it generated the configuration for all relevant resources in the cluster. The fix also requires that the Ingress Controller can successfully list the relevant resources from the Kubernetes API. For example, if the -enable-custom-resources cli argument is true (which is the default), the VirtualServer, VirtualServerRoute, TransportServer, and Policy CRDs must be created in the cluster, so that the Ingress Controller can list them. This is similar to other custom resources – see the list here. Thus, before upgrading, make sure that the CRDs are created in the cluster. Otherwise, the Ingress Controller pods will not become ready.

Supported Platforms

We will provide technical support for NGINX Ingress Controller on any Kubernetes platform that is currently supported by its provider and which passes the Kubernetes conformance tests. This release was fully tested on the following Kubernetes versions: 1.16-1.20.

1.10.1

16 March 2021

Dependencies

  • Update NGINX version to 1.19.8.
  • Add Kubernetes 1.20 support.

Fixes

  • 1373, 1439, 1440: Fix various issues in the Makefile. In 1.10.0, a bug was introduced that prevented building Ingress Controller images on versions of make < 4.1.

Upgrade

  • For NGINX, use the 1.10.1 image from our DockerHub: nginx/nginx-ingress:1.10.1, nginx/nginx-ingress:1.10.1-alpine or nginx/nginx-ingress:1.10.1-ubi
  • For NGINX Plus, please build your own image using the 1.10.1 source code.
  • For Helm, use version 0.8.1 of the chart.

1.10.0

26 January 2021

Overview

Release 1.10.0 includes:

  • Open ID Connect authentication policy.
  • Improved handling of Secret resources with extended validation and error reporting.
  • Improved visibility with Prometheus metrics for the configuration workqueue and the ability to annotate NGINX logs with the metadata of Kubernetes resources.
  • NGINX App Protect User-Defined signatures support.
  • Improved validation of Ingress annotations.

You will find the complete changelog for release 1.10.0, including bug fixes, improvements, and changes below.

Features

  • 1304 Add Open ID Connect policy.
  • 1281 Add support for App Protect User Defined Signatures.
  • 1266 Add workqueue metrics to Prometheus metrics.
  • 1233 Annotate tcp metrics with k8s object labels.
  • 1231 Support k8s objects variables in log format.
  • 1270 and 1277 Improve validation of Ingress annotations.
  • 1265 Report warnings for misconfigured TLS and JWK secrets.
  • 1262 Use setcap(8) only once. 1263 Use chown(8) only once. 1264 Use mkdir(1) only once. Thanks to Sergey A. Osokin.
  • 1256 and 1260 Improve handling of secret resources.
  • 1240 Validate TLS and CA secrets.
  • 1235 Use buildkit secret flag for NGINX plus images.
  • 1290 Graduate policy resource and accessControl policy to generally available.
  • 1225 Require secrets to have types.
  • 1237 Deprecate support for helm2 clients.
  • Documentation improvements: 1282, 1293, 1303, 1315.

Helm Chart

  • 1290 Add new preview policies parameter to chart. controller.enablePreviewPolicies was added.
  • 1232 Replace deprecated imagePullSecrets helm setting. controller.serviceAccount.imagePullSecrets was removed. controller.serviceAccount.imagePullSecretName was added.
  • 1228 Fix installation of ingressclass on Kubernetes versions v1.18.x-*

Dependencies

  • 1299 Update NGINX App Protect version to 2.3 and debian distribution to debian:buster-slim.
  • 1291 Update NGINX OSS to 1.19.6. Update NGINX Plus to R23.

Upgrade

  • For NGINX, use the 1.10.0 image from our DockerHub: nginx/nginx-ingress:1.10.0, nginx/nginx-ingress:1.10.0-alpine or nginx-ingress:1.10.0-ubi

  • For NGINX Plus, please build your own image using the 1.10.0 source code.

  • For Helm, use version 0.8.0 of the chart.

  • As a result of 1270 and 1277, the Ingress Controller improved validation of Ingress annotations: more annotations are validated and validation errors are reported via events for Ingress resources. Additionally, the default behavior for invalid annotation values was changed: instead of using the default values, the Ingress Controller will reject a resource with an invalid annotation value, which will make clients see 404 responses from NGINX. See this document to learn more. Before upgrading, ensure the Ingress resources don’t have annotations with invalid values. Otherwise, after the upgrade, the Ingress Controller will reject such resources.

  • In 1232 controller.serviceAccount.imagePullSecrets was removed. Use the new controller.serviceAccount.imagePullSecretName instead.

  • The Policy resource was promoted to v1. If you used the alpha1 version, the policies are needed to be recreated with the v1 version. Before upgrading the Ingress Controller, run the following command to remove the alpha1 policies CRD (that will also remove all existing alpha1 policies):

    kubectl delete crd policies.k8s.nginx.org

    As part of the upgrade, make sure to create the v1 policies CRD. See the corresponding instructions for Manifests and Helm installations.

    Also note that all policies except for accessControl are still in preview. To enable them, run the Ingress Controller with - -enable-preview-policies command-line argument (controller.enablePreviewPolicies Helm parameter).

  • It is necessary to update secret resources. See the section UPDATING SECRETS below.

UPDATING SECRETS:

In 1225, as part of improving how the Ingress Controller handles secret resources, we added a requirement for secrets to be of one of the following types:

  • kubernetes.io/tls for TLS secrets.
  • nginx.org/jwk for JWK secrets.
  • nginx.org/ca for CA secrets.

The Ingress Controller now ignores secrets that are not of a supported type. As a consequence, special upgrade steps are required.

Before upgrading, ensure that the secrets referenced in Ingress, VirtualServer or Policies resources are of a supported type, which is configured via the type field. Because that field is immutable, it is necessary to either:

  • Recreate the secrets. Note that in this case, the client traffic for the affected resources will be rejected for the period during which a secret doesn’t exist in the cluster.
  • Create copies of the secrets and update the affected resources to reference the copies. The copies need to be of a supported type. In contrast with the previous options, this will not make NGINX reject the client traffic.

It is also necessary to update the default server secret and the wildcard secret (if it was configured) in case their type is not kubernetes.io/tls. The steps depend on how you installed the Ingress Controller: via manifests or Helm. Performing the steps will not lead to a disruption of the client traffic, as the Ingress Controller retains the default and wildcard secrets if they are removed.

For manifests installation:

  1. Recreate the default server secret and the wildcard secret with the type kubernetes.io/tls.
  2. Upgrade the Ingress Controller.

For Helm installation, there two cases:

  1. If Helm created the secrets (you configured controller.defaultTLS.cert and controller.defaultTLS.key for the default secret and controller.wildcardTLS.cert and controller.wildcardTLS.key for the wildcard secret), then no special upgrade steps are required: during the upgrade, the Helm will remove the existing default and wildcard secrets and create new ones with different names with the type kubernetes.io/tls.
  2. If you created the secrets separately from Helm (you configured controller.defaultTLS.secret for the default secret and controller.wildcardTLS.secret for the wildcard secret):
    1. Recreate the secrets with the type kubernetes.io/tls.
    2. Upgrade to the new Helm release.

NOTES:

View source
Edit this page
Create a new issue