Istio service mesh users tackle real-world integration
Once IT pros set up Istio in production, they face an even bigger challenge: expanding it to the rest of the IT infrastructure, from multi-cluster environments to VMs.
Early adopters of Istio service mesh have moved past early deployment concerns for the complex network tech and are now focused on the broader problem of expanding its use throughout the IT infrastructure.
Service mesh is a network design that separates the control plane from a distributed data plane made up of sidecar proxies. For those who have put this pattern into production use -- a minority of the market so far, at 27% of 1,324 respondents surveyed last year by the Cloud Native Computing Foundation -- its benefits include network management scalability and flexibility that goes beyond the capabilities of traditional API gateways. Service mesh also abstracts complex microservices network management from developers as they deploy applications.
However, hiding that complexity from developers doesn't make it disappear; someone -- usually a platform engineer or site reliability engineer -- must integrate service mesh into DevOps workflows and manage its configuration alongside application releases. The difficulty of this job is only compounded when applications are deployed to multiple Kubernetes clusters by multiple development teams.
"Istio's configuration is both too flexible and too granular for everyday human consumption," said Ryan Michela, a software architect at Salesforce, in a presentation at this week's IstioCon. "Most users don't need most features of Istio, but you still have to interact with them to write valid Istio configuration."
Multi-cluster configuration -- not for the faint of heart
Helm, a Kubernetes package manager, is among the choices platform engineers have for managing complex configurations in multi-cluster Kubernetes environments; although, Istio service mesh support for Helm version 3 remains at the alpha stage.
Most users don't need most features of Istio, but you still have to interact with them to write valid Istio configuration.
Ryan MichelaSoftware architect, Salesforce
"Helm and Istio can work together to create a seamless GitOps experience for developers," Michela said. "Helm calls itself the package manager for Kubernetes, but to me, this sells Helm really short. … With a little creativity, it can do so much more."
Publicly shared Helm charts aren't always reliable, and writing custom Helm charts for every installation is tedious work, Michela said.
Michela's team at Salesforce skirts this issue with Helm starter templates that strip away most of Istio's customization knobs. They present developers with only relevant configuration fields as they set up app deployments.
Financial services software maker Intuit created Admiral to solve a similar problem, according to IstioCon presenters this week. The open source project automates Istio service mesh configuration management for developers, including traffic routing to multiple clusters in multiple regions, without requiring those developers to have in-depth knowledge of Istio. While many functions are built into Admiral, each organization must still handle integrating it into its specific DevOps pipeline, Intuit presenters said.
From multi-cluster to multi-tenancy?
Multi-tenancy in Kubernetes environments has been an elusive goal for some DevOps teams who'd prefer to centralize management between fewer clusters than manage many separate clusters for individual tenants. But multi-tenant security for containers is inherently tricky, and a Kubernetes Common Vulnerabilities and Exposures list that affects all versions of the container management platform, revealed in December, seemed to put that goal even further out of reach.
At the same time, Istio service mesh has also been promoted as a means to establish a zero-trust architecture, if used correctly. Some enterprise IT pros still want to establish multi-tenant Kubernetes clusters using Istio -- once certain issues are addressed upstream.
T-Mobile's Istio expansion plans
"Most recently, [we] hit an issue where the Istio discovery mechanism within the control plane was overloaded by the rate of change of pods and services in a [Kubernetes] namespace that wasn't involved in the mesh," said Joe Searcy, a member of mobile carrier T-Mobile's distributed systems technical staff, in an online interview during this week's virtual event. "The Istio discovery mechanism watches all services across a cluster, regardless of if the services are participating in the mesh."
Istio maintainers acknowledged the issue this week, but it's still unclear how the project may address it. Searcy said he worked with engineers at Solo.io on a fix that would limit the scope of Istio discovery to specific Kubernetes namespaces and submitted it to the community, but he hasn't seen it included in a release.
This kind of multi-tenancy support is still the subject of debate within the Istio community, according to one project maintainer during a roadmap presentation Q&A this week.
"There, you have a coupling between expectations of what a Kubernetes distro does for multi-tenancy, and what Istio does," said Louis Ryan, principal engineer at Google. "Something like OpenShift makes this part of their experience … [versus] Kubernetes, which makes less strident assertions about this."
There are workarounds that can be used to associate hosts within Kubernetes clusters with specific services under Istio, but it's difficult to do, said Neeraj Poddar, co-founder and chief architect at Aspen Mesh and a member of the Istio steering committee, in an online interview.
"It's kind of there in upstream but quite complex in my view," Poddar said. "[Aspen Mesh] had proposed our APIs in open source Istio, but the leads went a different route around two years ago."
VM support improves, but corner cases linger
Istio service mesh was initially compatible with only Kubernetes infrastructure. It closed one of the most significant competitive gaps with service meshes such as HashiCorp's Consul Connect with significant improvements for managing virtual machine workloads in recent releases.
Versions 1.7 and 1.8 of Istio simplified the installation process for virtual machines through the istioctl command-line interface. These releases also introduced enhancements to the ways VMs connect to DNS utilities under Istio. Reps from Istio service mesh management software maker Tetrate said at a virtual event last month that some of its customers already use virtual machines with Istio in production.
Adding service mesh support to VM environments remains difficult in cases where enterprises don't want to change VM images to add the Envoy sidecar proxy, according to a presentation this week by Poddar. Such VMs can still be incorporated into the mesh via Istio gateway proxies, but the way those gateways handle SSL certificates needs more work in upstream versions of Istio, Poddar said.
"Open source Istio primarily assumes that you can add sidecar proxy to the VMs and everything flows from there," Poddar said in an interview. "Certificate management … is a use case that resonates with a lot of users, so I'm hoping we can address it in upcoming releases."
Dig Deeper on Systems automation and orchestration
