How do Virtual Machines and containers talk to each other? How does an Istio mesh make that process easier? Since Istio’s 1.6 release, which has helped bring VMs under control of the mesh, it becomes significantly easier. Istio’s aim as a project is to make life easier, and give organizations a single point of control.  

First, it’s best to explain how container networking works with a service mesh before we add in the complications of a hybrid set up, and what that looks like. After all, when you’re able to bring all your environments together under a single control plane, your development teams won’t need to be as concerned with the setup you’re running, just how they’re running.

Service-to-service Communications with Kubernetes 

Let’s look at our fictional company, TP Inc. We’ve got a high-level overview of what their service structure looks like in Kubernetes, and they’re running quite a lot of services and service instances that all need to talk to each other. 

What's a service? A service is a logical grouping (as opposed to a physical grouping) of Kubernetes pods that perform the same function. What’s a service instance? Each 'pod' is a service instance, which is an independent package that contains all the code to run a process or an app. There are usually multiple instances in a service, serving traffic to make sure that the service remains available.

 

In most cases, there’s more than one service instance running in most services, which ensures they can always respond to requests efficiently. If any of those service instances become unhealthy and stop responding to requests, there’s enough redundancy to keep the service running until the bad instance is healthy again.

Architecture diagram showing how TP Inc's services are arranged - there is a pod inside a service instance which is inside a service grouping

To manage their environment, TP Inc also uses an Istio service mesh, which gives them control over traffic within their environment, and how they keep it secure.  

For a deeper overview of what a service mesh can do, download our free PDF copy of Istio: Up and Running (O’Reilly) by Zack Butcher and Lee Calcote.


Shifting traffic

TP Inc is a fast-growing, modernizing company. They want to make sure that they can continue to look after their infrastructure and keep their services regularly updated, without the risk of the updates breaking their services and becoming inaccessible to users. This is why traffic shifting is a great safety mechanism for making sure that new deployments are working as expected.

Because the Envoy proxy handles all traffic requests on behalf of the service instance, it acts almost like a traditional load balancer for each request it receives. However, Istio can help the sidecars do so much more. Istio is a ‘control plane’ which means that it manages the Envoy sidecars by dictating policies that they must enforce, and enabling more granular traffic routing. A good use case for this is to test a new version of their code. If service instance 1 is running a newer version than service instance 2, developers can send 30 percent of traffic/requests to service instance 1 to verify that it’s working as expected before they push the change to all instances of that service. Alternatively, if it doesn’t work as it should, then they can change the Istio configuration, redirect traffic and the bad instance can be removed.

Securing your traffic

Keeping traffic secure is important for any business, for both internal and external traffic. TP Inc has services (e.g. order fulfilment) which will contain personal information of the people who have purchased items from them, so protecting that user information is paramount and securing the traffic is of the utmost importance. 

Let’s consider an external request that comes into TP Inc’s service. The user tries to place an order. The stock management system confirms that the item is in stock, that they can purchase that item and transfers them to the payments system where they provide their personal information. After that, the order fulfilment service receives the data for the warehouse to pack and post. That’s a lot of personal information, and a lot of connections that need to be adequately secured and encrypted.

Istio implements the concept of ‘Zero Trust Architecture’ which enforces the default that nothing is trusted automatically. Everything that attempts to access the network, or interact with it must be verified before the transaction can take place. Istiod is the central hub for that zero-trust concept. It provides the certificates and the policies that Envoy sidecars need to both prove their identity and to verify the identity of others, something that’s enabled by ‘mTLS’ (mutual Transport Layer Security). 

KEY TERMS What is a certificate authority? A certificate authority issues digital (SSL) certificates that provide devices (and services) with a verifiable identity. They are a third party that is trusted both by the owner of the certificate and the one relying on its authenticity. What are authentication policies? An authentication policy requires parties attempting to gain access to services present a valid certificate proving they are who they claim to be. What are authorization policies? Authorization policies are set by administrators, and enforced by the Envoy Proxy with a binary response of ‘allow’ or ‘deny’ to any request that they receive. If these policies are enabled, then the default response by Envoy Proxy is to ‘deny’ requests unless explicitly specified in the policy. What is an API server configuration? The API server distributes the Authentication and Authorization policies and the secure name that the Certificate Authority provides to the Envoy Proxies. What is mTLS? mTLS (mutual Transport Layer Security) is an authentication method where both the service initiating the transaction and the service responding to it, both mutually provide evidence of their identity so that the transaction can take place. Neither trusts the other until they’ve proven who they are.

All of the security measures that Istiod helps to enforce are all about minimizing risk, not about removing it all together. It’s an organizational responsibility to make sure that the policies are properly enabled, and behaving as you want them to do. Istio is the enforcer, not the author. TP Inc’s administrators need to make sure that they have appropriately detailed the policies and how they should be enforced by Istio. If there was an issue with inappropriate access to a service because the authorization policies were not strong enough, then the ramifications could be serious. 

VM to Kubernetes communications

The diagram of TP Inc earlier showed their Kubernetes setup, but imagine that the company still had some of their services running on Virtual Machines. Running entire services on straight Kubernetes is unlikely, and there’s nothing wrong with ‘legacy’ infrastructures. 

However, it’s safe to say that it hadn’t been easy to make VMs and Kubernetes communicate until recently. The Istio 1.6 release brought some substantial updates to Istio’s capabilities that gives VM and Kubernetes the same treatment by Istio. It brings the two types of infrastructure together by giving the VM a sidecar and an identity that the Istio mesh can recognize it by, and control in the same platform. For those managing hybrid environments, it’s a big deal. 

Now that VMs are under the control of the service mesh, it means that traffic can move more easily between the two, and the mesh can provide more control over the way the traffic moves. All the traffic shifting and security capabilities that came with containers are now available to VMs. 

For networking teams, this means a lot of time-saving! There’s no need to duplicate configurations, or do any manual more intervention to get things to work together. Similarly, if you’re intending to migrate services onto containers, your life just got a whole lot easier. The benefits are immense, and there’s more to come. 

Takeaways

Istio’s aim is to take many of the concerns away from the developers so that they can focus on business logic, what environment you’re running on is less of a concern. However, organizations still need to be mindful of what services can talk to one another, and what information they can share.  

Author(s)