cerebrate
commented
1 year ago That's true.
I'm not certain what the best approach is. On the one hand, I'm not necessarily against making ipFamilyPolicy a configurable option in the chart, but I would still prefer the default to be PreferDualStack, since otherwise it's just Another Damn Thing to do for every future installation. Admittedly, this requires present installations upgrading to manually change it to SingleStack to avoid breakage, but in the big picture, there are less of them than all future and fixed deployments.
On the other hand, if they have to do that anyway, the best option might be the same as the one noted for mastodon/mastodon#19706 in the README.md and simply instruct people to delete the two services before they helm upgrade, something which would only have to be done once per installation.
Thoughts?
At the moment, the Helm chart does not allow clean installation on Kubernetes clusters running in dual-stack mode.
For example, on my own k3s cluster, the Mastodon services are assigned only IPv6 addresses and use only IPv6 endpoints, which fails both IPv4 clients and causes problems with the Mastodon pods which, at the moment, only bind to IPv4 addresses on a dual-stack cluster. (The related issue to fix that problem is here: https://github.com/mastodon/mastodon/issues/25371 ; at the moment I had to bypass it by hacking BIND definitions into this Helm chart, but a proper fix would obviously be preferable.)
This PR remedies the problem by setting ipFamilyPolicy: PreferDualStack on the services the chart creates, which makes dual-stack clusters operate correctly and should have no side-effects on single-stack clusters.