IPv6 support for Ingress controller

[kunalekawde]

Hello Folks,

1. Does ingress controller support dual stack in a way that external IPv4 or IPv6 traffic is processed and forwarded to application ?
2. Based on 1 above, if it receives IPv6 traffic can it then originate IPv4 traffic towards application by specifying the IPv4 kubernetes service in kind:ingress/ingress-rule ?

Thanks

[brianehlert]

First of all, I will always suggest that folks consider the CRDs this project offers. As it gives you much better controls, more options, and will introduce you to a pattern that is very similar to the evolving Gateway API efforts of the K8s community.

Dual stack is fully supported.
This applies to both the NGINX listener configuration and the assumptions we have around the container image. We assume that both stacks are present in the container image.

The means the following combinations are possible:
client side <-> backend
IPv4 <-> IPv4
IPv6 <-> IPv6
IPv4 <-> IPv6
IPv6 <-> IPv4

The pattern we see today is that IPv6 is becoming popular / common for the client connection in regions such as Asia where they might not also be operating IPv6 internal to the cluster (for the backend services).

We included an option to disable IPv6 due to discovering that there are systems out there that disable IPv6 through disabling it within the kernel of the cluster nodes which creates some downstream impacts within the container.

[brianehlert]

Yes. ExternalName support requires the upstream DNS resolver feature which is currently available with NGINX Plus only. That is correct.

Dual Stack is both free or paid.

[kunalekawde]

In case we dont need DNS resolver because we have external IP addresses, does the solution path still remains same ?

[brianehlert]

I am honestly not entirely sure.
If for the externalname you set an IP instead of a DNS... The business logic might still be looking for a resolver to set up.
I am honestly not entirely sure.
The best I can do is encourage you to try and see what happens.

[kunalekawde]

If I can squeeze in another clarification:
If our external servers (for egress traffic) are learnt dynamically over period of time, is it possible to program the ingress controller at runtime to make it aware of this new external server? Per reading, NGINX supports graceful reload but NGINX Plus is via API without any restart. If true, can application pass this new config and trigger reload of NGINX ?

Thanks again for all clarifications @brianehlert, that helps.

[brianehlert]

The NGINX Ingress implementation has a controller layer and configuration management system under the hood.
While you could interact with the NGINX Plus API directly, the controller processes would overwrite anything you did on the next update.
Essentially you would be introducing a two source of truth problem into a system that is not designed to support that.

If you are using NGINX Plus, simply using a DNS Name and the ExternalName capability - NGINX uses a second resolver function to resolve the targets for this particular upstream group. This second resolver is unique from the base OS DNS resolver and updates the upstream group in a way that remains compatible with the controller processes.

NGINX does a few things when reloading a configuration. Changes to nginx.conf generally require a reload is triggered by the modifying system. There are 'hard' and 'soft' ways of doing this. The 'soft' way keeps existing sessions running on existing worker processes and starts up new worker processes with the new configuration. The 'old' worker processes are allowed to close naturally.
If there are repeated reloads, eventually the oldest worker processes are force killed. Because it gets to be too much to maintain efficiently or it is assumed that the session is so long lived there is no natural close.

The N+ API introduces a different method that does not reload at all. No new worker processes.

This NGINX Ingress Controller takes advantage of all that behavior and also has additional optimizations to take into account the more dynamic nature of a K8s environment (continuously changing upstreams).