Known limitations
Before trying to attach a virtual machine to the mesh, make sure that you understand the following limitations of the solution:
-
Because of the way Istio operates, the VM is only able to resolve services and DNS names from the same Kubernetes namespace as it’s attached to. This means that communication from the VM to other Kubernetes namespaces is not possible.
- When you are installing Istio on the node for the first time, network connections might be disrupted (TCP reconnections will happen) as Istio initializes the iptables. Prepare for such a micro-outage when first provisioning Istio on a production node.
-
You can attach VMs only to active Istio cluster that’s running the Service Mesh Manager controlplane.
VMs in active-active scenarios
If you are running Service Mesh Manager in a multi-cluster scenario with multiple active Istio controlplanes, note that:
-
You can attach VMs only to active Istio cluster that’s running the Service Mesh Manager controlplane.
-
The VMs can’t automatically reconnect to the mesh expansion gateway when there is an outage on the cluster to which the VM is connected.
After the outage, outdated IP addresses remain in the /etc/hosts file of the VM, so the VM can’t connect to any of the mesh expansion gateways. Update the IP addresses manually in /etc/hosts file of the VM to the current IPs of a mesh expansion gateway to restore traffic to the VM. You can get the Ingress IP address of an IstioMeshGateway by running the following command:
kubectl get istiomeshgateways.servicemesh.cisco.com -n <namespace-of-the-meshgateway> <name-of-the-meshgateway> -o jsonpath='{.status.GatewayAddress[0]}'