Limitations and outlook of Robot vSwitch integration

[lukasmetzner]

After reviewing open issues and PRs we identified common issues with the Robot vSwitch integrations and propose our solutions here. This issue will be referenced in the corresponding pull requests.

IP mismatch

When a node is initialized via the HCCM, we receive the Kubernetes node object from the cloud-provider library and must return instance-specific metadata defined by cloudprovider.InstanceMetadata. One of the required fields is NodeAddresses, which should include all available addresses retrieved from the Hetzner Cloud API and the Robot Webservice. The cloud-provider library then validates these addresses against those listed in the node object. However, if a user manually sets the vSwitch IP using the --node-ip kubelet flag, the validation fails because the Robot Webservice does not provide the necessary information.

E1112 10:10:10.000000       1 node_controller.go:240] error syncing 'XXX': failed to get node modifiers from cloud provider: provided node IP for node "XXX" is not valid: failed to get node address from cloud provider that matches ip: XXX, requeuing

Solution

We forward the nodes InternalIPs by default. This behavior can be disabled via an environment variable.

Support private IPs as load balancer targets

Due to the same restrictions in the Robot Webservice, we can not support private vSwitch IPs as load balancer targets.

Solution

We can use the nodes configured InternalIP as a target, when load-balancer.hetzner.cloud/use-private-ip is set to true.

Native Routing does not work with vSwitch IPs

As stated in the Hetzner Cloud API documentation, we can not add a route to a network, where the gateway address is an IP behind a vSwitch. There is currently no solution for this.