Service Mesh in the Real World #2 — Ingress Traffic Control
[Updated with recording and slides]
Welcome back to the second in a series of live stream videos featuring Sandeep Parikh from Google and Christian Posta from Solo.io to learn about how to apply service mesh in the real world. If you are unsure what a service mesh is, or when it makes sense to use one, then this is the right place for you — come learn and ask questions live.
Our first session focused on egress traffic (when traffic leaves the cluster to an external service) and this time we will focus on traffic entering the cluster, otherwise known as Ingress.
This session we want to focus on the use case of multi-tenancy on your Kubernetes cluster with Istio service mesh. You might be thinking “what? I thought we were supposed to have many small clusters, so why would I need to have a multi-tenant cluster?”
When you start thinking about a large scale application deployments, different teams are likely responsible for different parts of building and deploying that application code. That large application will likely be on a single Kubernetes cluster and isolated between teams using common multi-tenancy approaches. Whether you are looking to isolate different teams, domains or even certificates, you can implement multiple ingress gateways to a single cluster therefore isolating inbound request traffic at the point it enters the cluster.
We will explain how API Gateways, Ingress Controllers, and Service Mesh are different and also work together to achieve this use case.
In this session we’ll:
- Discuss the core concept
- Challenges for application developers and cluster operators
- Walk through how that problem has been solved historically
- Review how implementing a service mesh can help solve that problem differently
- Demos, demos, demos
- Recap of the latest release of Istio
Watch the video replay here:
Download and share the presentation