Support IPV6

[zillani]

What would you like to be added:
Support IPV6 for imageswapper

Why is this needed:
Required for ipv6 based k8s cluster. IPV6 is popular & is necessary because it provides a vast number of unique addresses for the growing number of devices, improves security, & network efficiency.

[ilrudie]

Are you asking to be able to listen on IPv6 or for something more?

Are you interested in contributing?

[ilrudie]

https://github.com/istio/istio/blob/5a52f2867f9f1cbc20d3bd8f05376b607d178ebf/samples/helloworld/src/Dockerfile#L35

This is one possible solution

[zillani]

exactly, I had to use the flag to fix one of our ipv6 clusters. -b [::]:5000 I will contribute.

[ilrudie]

@phenixblue, would you be opposed to listening on IPv6 by default? I have no proof but my guess is 99+% of deployments of ISW would be fine with the TCP6 binding and relying on the v4->v6 behavior of the kernel in IPv4 environments.

[phenixblue]

I'll need to think on this a bit. I seem to recall some K8s distros/managed services disable ipv6 explicitly....I don't know what that would look like with. Default ipv6 listener.

[zillani]

how about creating a helm chart so that we can have a flag like this, in values.yaml

values.yaml

ipv6
 enable: true

and based on this,

deployment.yaml

  {{- if .Values.ipv6.enabled }}
  command: ["gunicorn", "imageswap:app", "--config=config.py", "-b [::]:5000"]
  {{- else }}
  command: ["gunicorn", "imageswap:app", "--config=config.py"]
  {{- end }}

[phenixblue]

I'm not against a Helm chart, a few people have raised PR's in the past for that, but none of them complete with testing. If someone wants to go all the way with a Helm chart,I'm all for it.

• The chart itself
• Tests for the chart
• Update existing Makefile targets, scripts, and tests
• Docs
• Add chart publishing

I'm sure there are other things to think about with that as well

[phenixblue]

I want to do some testing to see what settings exist for ipv4/ipv6 for K8s API/kube-proxy and read up on some gunicorn a bit more before I say one way or another what my mind leads towards

[ilrudie]

There are 2 layers to IPv6 to consider. Kubernetes support for IPv6, as in you can get/resolve IPv6 addresses for pods and services, and node support for IPv6. I'm not sure there are many node images which don't have reasonable TCP6 (I think any kernel 2.6+ should be pretty much good to go). So long as the node has TCP6 and automatically handles the IPv4 addressing on TCP6 you should be find to bind TCP6 even if Kubernetes itself isn't dual stack or IPv6.

It should be noted that in principal the behavior of automatically handling IPv4 when you listen on IPv6 in linux can be disabled, I don't recall the setting off the top of my head, but I don't think it's common practice to do so.

All this being said, another option which isn't IPv6 bind by default or helm would be just having an IPv6 kustomize overlay for the deployment which has a different command. If we do choose to bind IPv6 but we're not 1,000% sold maybe we include an overlay to get your IPv4 back easily.