In this release, NGINX Ingress Controller LoadBalancer Service external traffic policy has been made configurable, and the policy default has been changed from
- Enable source IP preservation, needed for IP based security access control.
- Remove unnecessary ingress traffic intra-cluster network hops, increasing concurrent connection capacity and reducing latency.
- Allow configuration to be reverted, where these defaults and associated tradeoffs are found to be inappropriate.
Management of NGINX IC LoadBalancer Service is moved from azure-operator to NGINX IC App itself to:
- Enable external traffic policy configurability, in a way consistent with other NGINX IC configuration options.
- Lay the foundation for making NGINX IC App optional and not pre-installed in a future Azure platform release.
Along with azure-operator and NGINX IC, minor improvements were also made to CoreDNS, cluster-operator, Flatcar, and Kubernetes.
When upgrading clusters, migration of LoadBalancer Service is automated but not fully automatic. Therefore, please delegate cluster upgrades to your SE.
Note for SEs:
Before cluster upgrade to 11.4.0, check if the DNS zone has a TXT DNS record called
If the record is not there, but there is another TXT one called
ingress.<clusterid>.<region>.azure.gigantic.io, please create a new TXT record using the right name
(with the cluster id at the beginning) and the value copied from the old one (the one without the cluster id at the beginning).
If you don’t do that the migration script execution (see below) will fail.
After cluster upgrade to 11.4.0, both old
ingress-loadbalancer LoadBalancer Service managed by azure-operator and new one
nginx-ingress-controller managed by NGINX IC App remain on the cluster. To switch the ingress traffic to the new LoadBalancer and remove old NGINX LoadBalancer Service without downtime please:
- Together with the customer have any firewall in front of NGINX reconfigured to allow both old and new LoadBalancer Service IPs.
- Next use the migration script to switch DNS records to the new load balancer IP. The script ensures IP is assigned to the new LB, and also that the cluster DNS records resolve to it instead of old IP.
- Now delete the old NGINX IC LoadBalancer Service (the one called
Note for future 11.4.x releases:
To prevent downtime, please persist this and the above note until all customers are in 11.4.0 and above.
Below, you can find more details on components that were changed with this release.
- Moved NGINX LoadBalancer Service management from azure-operator to nginx-ingress-controller app.
- The default egress strategy for worker nodes VMSS is now a VNET Gateway rather than the Load Balancer.
- Made forward options optional.
- Made resources (requests/limits) configurable.
- Fixed a bug in user values migration logic for apps.
- Enabled NGINX LoadBalancer Service on Azure.
- Updated from v1.16.8 -
changelog since v1.16.11,
since v1.16.9 and
- Includes a fix for CVE-2019-11253 related to json/yaml decoding where large or malformed documents could consume excessive server resources. Request bodies for normal API requests (create/delete/update/patch operations of regular resources) are now limited to 3MB.
- Changed NGINX Service type from NodePort to LoadBalancer for Azure.
- Made NGINX LoadBalancer Service external traffic policy configurable.
- Use Local as NGINX LoadBalancer Service default external traffic policy.
- Supported configuring (via
controller.service.public configuration property) whether NGINX LoadBalancer Service should be public (default) or internal.
- Upgraded to ingress-nginx 0.33.0.