Kubernetes Ingress vs Service Mesh

Networking in Kubernetes is no easy task. Whether you’re on the application side or the operations side, you need to think about networking. Whether it’s connectivity between clusters, control planes, and worker nodes, or connectivity between Kubernetes Services and Pods, it all becomes a task that needs a large amount of focus and effort.

In this blog post, you’ll learn about what a service mesh is, what ingress is, and why you need both.

What’s A Service Mesh

When you deploy applications inside of Kubernetes, there are two primary ways that the apps are talking to each other:

• Services
• Pod-to-Pod communication

Pod-to-Pod communication isn’t exactly recommended because Pods are ephemeral, which means they aren’t permanent. They are designed to go down at any time and only if they’re part of a StatefulSet would they keep any type of unique identifier. However, Pods still need to be able to communicate with each other because microservices need to talk. Backends need to talk to frontends, middleware needs to talk to backends and frontends, etc…

The next primary communication is Services. Services are the preferred method because a Service isn’t ephemeral and only gets deleted if specified by an engineer. Pods are able to connect to Services with Selectors (sometimes called Tags), so if a Pod goes down but the Selector in the Kubernetes Manifest that deployed the Pod doesn’t change, the new Pod will be connected to the Service.

Here’s the problem; all of this traffic is unencrypted. Pod-to-Pod communication, or as some people like to call it, East-West Traffic, is completely unencrypted. That means if for any reason a Pod is compromised or you have some segregation concerns, there’s nothing out-of-the-box that you can do.

A Service Mesh handles a lot of that for you. A Service Mesh:

• Encrypts traffic between microservices
• Helps with network latency troubleshooting
• Securely connects Kubernetes Services
• Observability for tracing and alerting

What’s Ingress

Outside of the need for secure communication between microservices, you need a way to interact with frontend apps. The typical way is with a load balancer that’s connected to a Service. You can also use a NodePort, but in the cloud world, you’ll mostly see load balancers being used.

Here’s the problem; cloud load balancers are expensive literally and figuratively. You have to pay money for each cloud load balancer that you have. Having a few applications may not be a big deal, but what about if you have 50 or 100? Not to mention that you have to manage all of those cloud load balancers. If a Kubernetes Service disconnects from the load balancer for whatever reason, it’s your job to go in and fix it.

With Kubernetes Ingress Controllers, the management and cost nightmare is abstracted from you. An Ingress Controller allows you to have:

• One load balancer
• Multiple applications (Kubernetes Services) pointing to it

You can create one load balancer and have every Kubernetes Service point to it. Then, you can access each Kubernetes Service on a different path.

For example, below is an Ingress Spec that points to a Kubernetes Service called nginxservice and outputs it on the path called /nginxappa

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-nginxservice-a
spec:
  ingressClassName: nginx-servicea
  rules:
  - host: localhost
    http:
      paths:
      - path: /nginxappa
        pathType: Prefix
        backend:
          service:
            name: nginxservice
            port:
              number: 8080

Ingress Controllers are like an Nginx Reverse Proxy.

Do You Need Both?

There’s a lot of talk between engineers around the idea of not needing both a Service Mesh and an Ingress Controller. My take on it is that you need both. Here’s why.

They’re both doing two different jobs. I always like to use the hammer analogy. If I need to hammer a nail, I can use the handle to slam the nail in and eventually it’ll work, but why would I do that if I can use the proper end of the hammer?

An Ingress Controller is used to:

• Make load balancing apps easier

A Service Mesh is used to:

• Secure communication between apps
• Help out with Kubernetes networking

Now, here’s the kicker; there are tools that do both. For example, Istio Ingress is an Ingress Controller, but also has the capability of secure gateways using TLS or mTLS. If you’re using one of those tools, great. Just make sure that it handles both communication and security for you in the way that you’re expecting. The recommendation still is to use the proper tool for the job.

Both Service Mesh and Ingress are incredibly important, especially as your microservice environment grows.

Popular Ingress Controllers and Service Mesh Platforms

Below is a list of Ingress Controllers and Service Mesh that are popular in today’s cloud-native world.

For Service Mesh:

• https://www.consul.io/
• https://istio.io/latest/about/service-mesh/
• https://linkerd.io/2.11/getting-started/

For Ingress Controllers:

• https://kubernetes.github.io/ingress-nginx/
• https://doc.traefik.io/traefik/providers/kubernetes-ingress/
• https://github.com/Kong/kubernetes-ingress-controller#readme
• https://istio.io/latest/docs/tasks/traffic-management/ingress/

If you want to check out how to get started with the Istio, check out my blog post on it here.

Comments

[trylvis]

Nice summary!

[Michael Levan]

Thank you! I'm happy that you enjoyed it.

[heroes1412]

Your article is very good and easy to understand. But how about API Gateway, i see ingress controller can handle API gateway task. what diffenrent?

[Michael Levan]

I would say the biggest two differences are 1) Ingress Controllers are a Kubernetes Controller in itself, so it's handled in a declarative fashion 2) (correct me if I'm wrong here about API Gateways please) API Gateways are typically an intermediary to route traffic between services. Sort of like a "middle ground". Where-as the ingress controllers are more about handling frontend app traffic.