Add config for k8s Services' ipFamilies and ipFamilyPolicy

[mike-matera]

This pull request addresses issue #3484. It updates the service template to enable users to expose their JupyterHub on an IPv6 address if their cloud allows it.

EDIT: adds [hub|proxy].service.[ipFamilies|ipFamilyPolicy] config

[manics]

What are the requirements for this to work- does the K8s cluster itself need to support IPv6? If so, would it make more sense for IPv6 or dual-stack to be set at a higher level, instead of on individual components?

[consideRatio]

I figure we can get this PR allowing the k8s Service resource to be configurable according to k8s specification, so that other pieces can be more easily worked on towards having broader support of IPv4 / IPv6 things.

I pushed a commit providing default values and updating the schema to support configuring this, and making it possible to configure all k8s Service resources this chart provides.

[consideRatio]

refactor: I moved this so it was positioned as it was in the other k8s Service templates

[consideRatio]

@manics what do you think, go for a merge of this?

[manics]

We don't have any tests for this. What do you think about merging it after the next release? That means if we find problems with how we implement IPv6 support we can make changes to these new parameters which would otherwise count as a breaking change if they're already in a release?

[consideRatio]

Thanks for the quick followup @manics, deal lets hold off until z2jh 4 is released.

[mike-matera]

@manics ... Sorry I didn't see your question earlier. There are three official requirements for IPv6 dual stack support.

1. Kubernetes >= 1.20
2. Support for IPv6 in your cloud provider or on your local host
3. A network plugin that supports dual stack (Calico does)

To test IPv6 support you don't need a host with a real IPv6 address, you just need IPv6 turned on in the cluster. Clusters get an IPv6 site local prefix which serve the same purpose of the 10.x.x.x addresses in the cluster.

Thanks for working on this! At my shcool the NAT situation is super weird and the only way to make z2jh available to students on campus is to have IPv6 turned on.

[manics]

Coming back to this.... assuming there are other areas that will require IPv4/IPv6 configuration what do you think about a top-level property that can be referenced in multiple places, e.g. ipfamily with values ipv4, ipv6, dual, and mark it as experimental in the schema?

[mike-matera]

@manics... A top level property seems like the right way to go. I think that most implementations will want to use the same IP address families on all of the services, rather than just the hub and proxy. That said, I have not tested the all dual-stack implementation. There may be surpises in DNS becuase of how dual address services are implemented.

[manics]

I've looked into this a bit more. The ideal situation is to require no configuration, and have everything work automatically on IPv4, IPv6, and dual stack.

What happens if you set the default for ipFamilyPolicy to PreferDualStack?
https://kubernetes.io/docs/concepts/services-networking/dual-stack/#services

Allocates both IPv4 and IPv6 cluster IPs for the Service when dual-stack is enabled. If dual-stack is not enabled or supported, it falls back to single-stack behavior.

What happens if ipFamilies is set to ["IPv4","IPv6"] on a single stack system with PreferDualStack- does it fail, or does it just use whatever is available?

Could you share your full Z2JH configuration? I'm trying to work through some JupyterHub IPv6 issues

• Singleuser: listen on IPv4 and IPv6 if ip=="" jupyterhub#4986
• More IPv6: Use bare IPv6 for configuration, use [ipv6] when displaying IPv6 outputs jupyterhub#4988

And it would be helpful to see what you're currently using.

[consideRatio]

@manics you have done a lot of work with this, do you have an idea on how to proceed?

I appreciate how this PR is very tightly scoped, allowing the Service resources of the chart to optionally be explicitly configured with ipFamilies and ipFamilyPolicy.

[manics]

If possible I think we should aim for a configuration that automatically works for ipv4, ipv6, and dual stack by default, e.g. PreferDualStack
#3485 (comment)

But keep the ability to override the parameters for edge cases.

[manics]

https://kubernetes.io/docs/reference/kubernetes-api/service-resources/service-v1/

ipFamilyPolicy (string)

IPFamilyPolicy represents the dual-stack-ness requested or required by this Service. If there is no value provided, then this field will be set to SingleStack. Services can be "SingleStack" (a single IP family), "PreferDualStack" (two IP families on dual-stack configured clusters or a single IP family on single-stack clusters), or "RequireDualStack" (two IP families on dual-stack configured clusters, otherwise fail). The ipFamilies and clusterIPs fields depend on the value of this field. This field will be wiped when updating a service to type ExternalName.

[manics]

Suggested change

	ipFamilyPolicy: ""
	ipFamilyPolicy: PreferDualStack

[consideRatio]

Nice!! Do you think this is safe or a breaking change?

[manics]

Based on the K8s docs it sounds safe since it only has an effect on dual-stack clusters, on single-stack clusters there's no change in behaviour.

[consideRatio]

Default value for proxy service config is missing.

Once that is in, this LGTM.

Should we put the explicit preferdualstack policy for both services in a standalone PR to make it easier to discuss, review, reference, discuss, revert etc? @manics has motivated it well in this PR already, so we can have it here also.

[consideRatio]

Thanks for working on this! At my shcool the NAT situation is super weird and the only way to make z2jh available to students on campus is to have IPv6 turned on.

Thank you for sharing this @mike-matera!!! This makes me very motivated to help drive this!

@manics I'll go for a merge here, and open a PR with the change you propose on switching to PreferDualStack as its easy to isolate these changes - I have read up a bit and saw for example https://kubernetes.io/docs/concepts/services-networking/dual-stack/#switching-services-between-single-stack-and-dual-stack indicating its fine to make such changes without trouble.