@kubernetes/sig-openstack-bugs

@rfliam: Reiterating the mentions to trigger a notification:
@kubernetes/sig-openstack-bugs

yep, there's a plan for alpha ipv6 support in k8s for 1.9 - https://groups.google.com/d/msg/kubernetes-sig-cluster-lifecycle/D_VxCZIvbe4/-NCHNdnaCQAJ

It seems a big feature, sounds good.

/sig network

cc @danehans

/remove-sig openstack

I strongly suggest this is not a bug. If you're using the host network, and you've configured IPv6 addresses on the host (explicitly or implicitly), then you should see IPv6 addresses for host pods.

If IPv6 addresses are an issue for your infrastructure, then the solution is to not configure IPv6 addresses on the host (and file a "should support ipv6" bug with your infrastructure component).

In particular, blacklisting IPv6 addresses at the application layer (in k8s) is harmful to anyone who is using IPv6 (now or in the future) and is not an acceptable solution to the original issue.

Edit: Just to be clear, there are bugs here somewhere that we should do something to fix/improve. Any approach that just "hides" the IPv6 address is not the right fix however, since it is a legitimate host address. We need to look at (eg) surfacing multiple addresses for the node and ensure clients correctly ignore address families they are not equipped to handle; or command line flag overrides for the admin to arbitrarily choose reported addresses; etc.

There are plenty of valid reasons to blacklist IPV6 addresses being exposed to kubernetes.

First and foremost in Kube 1.8 (and 1.9) most infrastructure components use host networking. Most do not; however, support ipv6. This includes core kube components like etcd. In kube 1.8 if IPV6 addresses are exposed for pods like etcd the cluster won't start. That's a pretty serious issue. And while fixing all the places that IPV6 is broken in kube would be great, a cursory glance through the code, the linked initiatives, etc. says that's a long way off.

To be clear IPV6 works fine in my infrastructure. It does not work fine with kube. And I may want the host to have IPV6 support for other applications than kube. Or I may want IPV6 on the host so my pods can use it, but not expose that info to kube (which breaks it). We do this in many places in our infrastructure.

Having the feature to filter ipv6 addresses be flag-able is perfectly reasonable. Indeed the most sensible long term route is allowing me to specify which interface is reported to kube, because multiple IPV4 addresses can have a similar effect.

How about we add a config option to filter out ipv6 but leave the current behavior as is?

Right, so it sounds like the bugs are:

• kube is only publishing a single address for the node (rather than one for each family, or all addresses for all families)
• whatever is consuming the address information from kube should filter out whatever families are unsupported by that application
• kubelet/controller-manager should have an override flag so the admin can just arbitrarily declare which specific addresses are advertised for a node
• (ipv6 support throughout the ecosystem is not complete yet)

?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close