You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like the ability for the zarf init process to either take input or to query the cluster to ascertain the network configuration of the cluster to determine the network stacks configured for the cluster and then have the Zarf initialization process react accordingly.
It may be appropriate to introduce an additional flag that can be provided to zarf init to specify if it Zarf should be configured for IPV6 only. As I don't know if the injector pod should have permissions to query information about the nodes to acertain the network configuration.
Describe alternatives you've considered
N/A the present code base does not consider the IPV6 only use case.
Additional context
Initial research shows a few problems where it's assumed that IPV4 stack will be available.
The injector pod that is spun up to bootstrap the cluster sets a readiness probe which does NOT specify a host field which causes the readiness probe to default to use the IPV4 host (see code).
Is your feature request related to a problem? Please describe.
Presently Zarf does not support deploying into a cluster which is configured for single stack IPV6. It does support dual stack and single stack IPV4.
There is a mandate (wayback machine link because white house site is flaky ATM for government agencys to migrate to IPV6 single stack by end of fiscal year (FY) 2025.
Describe the behavior you'd like
I would like the ability for the
zarf init
process to either take input or to query the cluster to ascertain the network configuration of the cluster to determine the network stacks configured for the cluster and then have the Zarf initialization process react accordingly.It may be appropriate to introduce an additional flag that can be provided to
zarf init
to specify if it Zarf should be configured for IPV6 only. As I don't know if the injector pod should have permissions to query information about the nodes to acertain the network configuration.Describe alternatives you've considered
N/A the present code base does not consider the IPV6 only use case.
Additional context
Initial research shows a few problems where it's assumed that IPV4 stack will be available.
The
injector
pod that is spun up to bootstrap the cluster sets a readiness probe which does NOT specify ahost
field which causes the readiness probe to default to use the IPV4 host (see code).The injector application logic is hard coded to use IPV4 stack.
The text was updated successfully, but these errors were encountered: