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
Currently it's not possible to have the announced apiserver_endpoint and actual kube-vip endpoint to differ.
With special routing and site-to-site tunnels it would be nice to have the option to override this within the configuration of this ansible-playbook.
Suggested Changes
With a simple change to the vip.yaml.j2 template overriding this would be possible and it wouldn't be an required property or breaking change to existing workflows. I can open a pull request with this change but I'm not quite familiar with the automated test tooling used just yet.
See an example for the required changes to support complex routing configurations below or in this example PR.
# interface which will be used for flannelflannel_iface: "eth0"# (optional) kube_vip_iface is an optional override for the network interface kube-vip will ARP announcekube_vip_iface: "eth0"# apiserver_endpoint is virtual ip-address which will be configured on each masterapiserver_endpoint: "10.66.10.1"# (optional) kube_vip_endpoint is an optional override for the internal listening endpoint for the kube-vip interfacekube_vip_endpoint: "10.66.1.5"
The text was updated successfully, but these errors were encountered:
Following up on the merge of #238, Is there something holding up the implementation of the example?
Having known we could already specify kube_vip_iface in the vars file would have been quite useful
Currently it's not possible to have the announced apiserver_endpoint and actual kube-vip endpoint to differ.
With special routing and site-to-site tunnels it would be nice to have the option to override this within the configuration of this ansible-playbook.
Suggested Changes
With a simple change to the vip.yaml.j2 template overriding this would be possible and it wouldn't be an required property or breaking change to existing workflows. I can open a pull request with this change but I'm not quite familiar with the automated test tooling used just yet.
See an example for the required changes to support complex routing configurations below or in this example PR.
The text was updated successfully, but these errors were encountered: