Stackpoint Simplifies Mastering Istio Routing Tables
StackPointCloud wants to make it easier for developers to master the networking complexities associated with deploying microservices when using the Istio service mesh running on top of a Kubernetes cluster.
Company CEO Matt Baldwin says the latest version of the Stackpoint.io platform provides a dashboard through which traffic rules can be applied and enforced on instances of Istio service meshes running on Amazon Web Services (AWS), Google Kubernetes Engine, Microsoft Azure, Google Cloud Platform, Digital Ocean and Packet clouds. Stackpoint.io is a management platform for cloud-native workloads running on-premises or in the cloud.
Baldwin says there’s a massive amount of interest in Istio as the number of microservices-based on containers deployed on top of Kubernetes clusters escalates. But, he says, most developers don’t fully appreciate all the nuances associated with networking in a Kubernetes cluster, so Stackpoint.io now provides a dashboard to visualize all those network connections.
Users also can now use Stackpoint.io to schedule when rules should be applied, or they can choose to build a custom rule or rely on Stackpoint.io’s wizards to configure Istio routing for their services. Stackpoint.io also enables users to visually manage other aspects of an Istio service, including VirtualServices and Destinations.
In addition, users can choose one or several Kubernetes services and configure Istio traffic rules around them. That capability furthers Stackpoint.io as a tool for performing canary, A/B or blue/green deployments across one or many Kubernetes clusters regardless of location or cloud service provider, says Baldwin.
Kubernetes provides a mechanism for unifying the management of compute, storage and networking within a cluster. The Istio service mesh provides a mechanism for load balancing workloads on a Kubernetes cluster. However, each cluster needs to be networked with other Kubernetes clusters and potentially a variety of other legacy networks. This requires both a physical network underlay as well as most likely a virtual network overlay. The result is a complex networking environment that most developers historically have not been inclined to navigate on their own, regardless of how programmable the overall software-defined networking environment might be.
Given that complexity, Baldwin says that logging and monitoring tools provided by platforms such as Stackpoint.io are now a requirement for building microservices-based applications—and will become more critical as organizations employ Kubernetes to unify multiple clouds into a heterogeneous hybrid cloud involving local and wide area network (WAN) connections.
In the meantime, most network administrators have little to no familiarity with Kubernetes. It may be months or even years before network administrators come to terms with how internal routing works in a local Kubernetes cluster. In the meantime, Kubernetes nodes will begin proliferating across the enterprise, which means it’s now only a matter of time before someone higher up the IT ladder starts asking network administrators to tie all those Kubernetes clusters into a larger network fabric.
