Tetrate Service Bridge & Mirantis Kubernetes Engine

While it’s easy to think about applications as individual entities, the reality of enterprise architecture is much more messy. An enterprise of any size is going to have dozens, even hundreds of applications – particularly if it has adopted a microservices-based architecture.

All of that means that communication between applications, services, clusters, and even hardware resources can be a complex undertaking. With the right tools, however, it’s entirely possible to manage an application with a high degree of internal connectivity, and even to thrive and produce software and innovation faster than your competitors.

This is the spirit in which Mirantis has teamed up with Tetrate to provide a situation in which Mirantis Kubernetes Engine provides infrastructure management, and Tetrate Service Bridge provides network traffic management – in many ways, an ideal arrangement.

Managing application service traffic

Beyond very simple applications, there is a non-trivial amount of network traffic, both within and flowing into and out of a Kubernetes cluster, particularly for microservices-based platforms, and all of this traffic must be managed.

Part of that management is for observability and troubleshooting, but perhaps the most noteworthy issue is security. Gone are the days when you could just stick a firewall in front of your web server and all would be well. Now all traffic must be monitored, because the threats can come from anywhere – even inside your network.

A tool like Istio that provides a service mesh offers not just security, but also policy management. An API gateway that handles networking can provide an extra layer of security, but unfortunately a service mesh and an API gateway alone aren’t enough.

Think about it this way. If you were going to secure a house, you’d put a security sensor on every entry point, and each would report into a central control point, logging when doors or windows are opened and deciding whether to sound the alarm. In this case, the sensors are represented by Envoy sitting in sidecars next to pods and determining ingress/egress from that point, and the control plane is represented by Istio, providing policies that determine what is and is not allowed and observing all that goes on.

Where Tetrate Service Bridge comes into play is if you have a lot of control points; managing and controlling such an environment would be overly cumbersome with Istio alone. To carry the building security analogy a little farther, for example, the Empire State Building houses multiple businesses, each with all of its own entry points to manage, but the building management wants to manage security across all of those businesses.

Or picturing an even larger environment, perhaps you want to manage control points across a whole city for something a utility, or for fire or police service.

Tetrate Service Bridge looks at the enterprise as a city, with individual departments and profit centers (the buildings) each of which have their own applications (windows and doors). It sits one level above Istio, which provides several advantages. First, it manages deploying Istio to the various clusters, so you don’t have to do that individually. It’s part of a “holistic” approach that also means Tetrate Service Bridge enables you to create global policies that apply to the entire enterprise (city) as well as to observe the enterprise as a whole.

At the other end of the spectrum, Tetrate Service Bridge enables you to create a granular level of policies for both applications and users. So all citizens have ID cards (that is, users have entries in your LDAP store) and you can control what they do by their roles, so janitors have access to places others don’t need (like janitor closets) and meter readers can get at the meters, and so on. Similarly, residents of a community can go to their local park (that is, use their department’s applications), but residents of other communities can’t.

Tetrate Service Bridge also enables you to provide monitoring for each user based on what they’re allowed to monitor rather than providing blanket observability to anyone who wants it.

All of this matters because no enterprise has only one instance of Istio; they all have multiple instances, and policies for all of them must match or you’re opening up security holes.

Also, when setting up your infrastructure, you don’t want a huge blast radius; you want to control your own fate, and you don’t want to be impacted by bad decisions in other teams. To prevent this, if a user puts in a bad configuration, Tetrate Service Bridge controls where those configurations can apply. It also controls how to failover, and how to reroute traffic, ensuring that issues only apply to a single application.

Managing the Kubernetes infrastructure

Of course, all of these services need to run on infrastructure, and the same concerns apply. That’s where Mirantis Kubernetes Engine and Mirantis Container Cloud come in.

Sticking with our “city” analogy, Mirantis Kubernetes Engine creates a Kubernetes cluster, which we can liken to a building, with Kubernetes managing the individual pods and applications (entry points).

But just as most enterprises have more than one Istio installation, they are also likely to have multiple Kubernetes clusters running on dozens (or in some cases hundreds or thousands) of physical nodes. To manage that overall architecture (city) there’s Mirantis Container Cloud, which manages not only the physical infrastructure but also the creation, lifecycle management, and monitoring of all of the clusters created by Mirantis Kubernetes Engine, allowing your application to gracefully scale to meet increased workloads. It also enables you to create a Mirantis Kubernetes Engine cluster with the Stacklight LMA component pre-deployed.

Having this kind of unified management of Kubernetes is just as important at the infrastructure level as it is at the application services level; an enterprise must have full control of and visibility into what’s happening over its entire infrastructure.

Putting Tetrate and Mirantis together

While both Tetrate Service Bridge and Mirantis Kubernetes Engine and Mirantis Container Cloud provide excellent foundations on which to build your Kubernetes infrastructure, there is one more benefit that stems from the partnership between the two companies: if and when something goes wrong, you need only contact Mirantis support and we will help solve your problem. When you’re working at enterprise scale, not having to bounce between vendors, with each insisting it’s the other’s responsibility, can be a lifesaver!

For more information on the Mirantis – Tetrate joint solution, be sure to check out the solution brief.