Google, IBM, Lyft, Cisco, Covalent, Stripe and other contributors to Istio are celebrating a milestone this week as version 1.0 of the open source service mesh becomes generally available.
Designed to provide a mechanism to simply the management and integration of microservices-based on containers running on top of a Kubernetes cluster, the Istio service mesh is quickly evolving into a platform for plug-ins that address a variety of functions that need to reside outside a Kubernetes cluster.
Brian “Redbeard” Harrington, product manager for Istio at Red Hat, says Istio provides the glue needed to, for example, balance microservices workloads running on top of a Kubernetes cluster. The latest version of Istio adds improved handling of role based access controls (RBAC), improved transport layer security (TLS) handling, component and additional (and refactored) test suites in addition to being generally more stable, says Harrington.
Cisco Systems also revealed today that it has contributed an alpha feature that make it possible to extend an Istio service mesh control plane across multiple clusters.
Specifically, Istio provides a method of integrating services such as load balancing, service authentication, transport layer encryption and application telemetry without requiring any code changes be made to a microservice.
Istio itself doesn’t necessarily replace the need for load balancers that distribute workloads across multiple types of clusters. Rather, Harrington says an Istio service mesh is intended to provide a framework for managing workloads running within the Kubernetes cluster. It deploys proxy servers that are co-located with an application, which then uses those proxy servers to perform various functions. Istio also provides the application programming interface (API) for managing the entire service mesh, including the individual proxy containers.
Harrington notes there are two “service mesh” incubating projects: Envoy and Linkerd. Both make use of a pluggable Istio proxy system that can be employed in any number of potential projects.
Over time, Harrington says the proponents of Istio are expecting the Cloud Native Computing Foundation (CNCF) that oversees Kubernetes to create a standardized control plane for managing microservices, while the rest of the service mesh framework remains an independent project. That approach makes it easier to add plug-ins to support other platforms in addition to layering more functions on top of a control plane that can then be integrated into a Kubernetes cluster, he says.
It’s already clear that the IT vendor community intends to do battle for control over the management of container cluster at levels above the service mesh. It remains to be see who will ultimately emerge victorious. But the one thing that is clear already is there will be no shortage of options. IT operations teams will need to determine precisely when exactly microservices will reach a level of scale that requires a service mesh. But in time it’s hard to see how any instance of a Kubernetes cluster won’t need some means to manage the services deployed on it.
It’s still early days when it comes to deploying Istio in a production environment. Google last week previewed an instance of a managed Istio service it plans to make available alongside its Kubernetes-based GKE cloud container service. IBM has also announced support for Istio on IBM Cloud. Over time, a wide variety of cloud service providers are expected to follow suit. Longer term, the combination of Kubernetes and Istio is also expected to become the foundation for delivering IT services across hybrid cloud computing environments made up of a broad range of virtual and physical machines.