A Comparative Study between Service Mesh and

standalone Kubernetes
Ameya Deshpande, Shuddhatm Choudhary, B. R. Chandavarkar

Department of Computer Science and Engineering

National Institute of Technology Karnataka
Surathkal, Mangalore, India
ameyanrd@gmail.com, choudhary.shuddhatm@gmail.com, brcnitk@gmail.com

Abstract—Kubernetes and Service Mesh are platforms
for automating, scaling, and managing complex application
deployments and workloads. One can face many issues
during application deployment like scaling the instances,
rolling out new updates, health monitoring of every in-
stance, and so on. Along the continuous process of develop-
ment, the application grows more complex and even harder
to manage. Kubernetes and Service Mesh Kubernetes
are some of the container orchestration platforms which
help with such issues and provide a better controlling
interface. In this paper, we present a study on the use
of Service Mesh Architecture and compare its advantages
and disadvantages with Kubernetes. The paper begins
by explaining Microservices and their benefits. Then it
mentions the operational issues with Microservices and
suggests Orchestrators like Kubernetes as a solution. Fur-
thermore, we see Kubernetes architecture, the limitations
of Kubernetes, the role of Service Mesh and Service Mesh
architecture. The paper also focuses on additional features
provided by Service Mesh. Finally, we study Istio Service
Mesh and conclude the circumstances under which an
operations team should go for Kubernetes or Service Mesh
Kubernetes.
I. I NTRODUCTION
During the past decade, the software industry has
witnessed a rapid migration towards the cloud. Cloud
computing makes it easier for businesses and enterprises
to focus on their application logic while taking care
of all the infrastructure and platform necessities. One
of the main reasons is that the cloud providers give a
wide range of services on their infrastructure, making
the job easier for the customers. One of the problems
that customers face is regarding the deployment of their
applications. Cloud platforms provide various solutions
to this problem, enabling them to have a highly avail-
able and geographically distributed cluster of application
instances.
Kubernetes cluster is one of the services provided by
cloud vendors. Kubernetes handles problems arising due
to a trendy architectural style called Microservices [1].
As opposed to the old monolithic style, Microservices
delivers the ability to develop large software by breaking
into smaller services that can be deployed, scaled, and
maintained independently by fully automated deploy-
ment machinery. Microservices address the drawbacks
of monolithic architecture and thus make scaling and
deployment more flexible and efficient.
The issue with Microservices was to handle the de-
ployment of many smaller services [2]. Some prob-
lems were port collision among the services, unexpected
service crashes, or the server machine’s security. The
virtualization technique can solve these problems. The
services can run in isolated environments like Virtual
Machines or Containers, allowing the service to have
its networking stack, so no port collision, unexpected
crash analysis and easy restarting of the application, and
enhanced security due to its isolated environment.
One of the other problems while adopting the Mi-
croservices pattern is the management of multiple mi-
croservices. This management can be in the form of elas-
ticity, health checks, and software updates. Here comes
the significant role of Kubernetes as an orchestrator.
Kubernetes handles microservices in the form of contain-
ers. Containers are light-weight and easily manageable
via Docker tools, making them an obvious choice over
Virtual Machines. Kubernetes is a popular container
orchestration tool that enables automated deployment,
scaling, and containerized applications [3].
Service Mesh is an infrastructure solution used on the
top of Kubernetes to ensure reliability, enhance security,
and monitor containerized microservices [4]. We’ll see
how Kubernetes and Service Mesh Kubernetes work and
conclude the best-suited solution for a microservices
application.
In this paper, we start by looking into Microservices
and their benefits. Further, we explore the operational
issues with Microservices and suggest Orchestrators like
Kubernetes as a solution. Furthermore, we see Kuber-
netes architecture, the limitations of Kubernetes, the role
of Service Mesh and Service Mesh architecture. Finally,
we consider a case study on Istio Service Mesh and con-
clude the circumstances under which an operations team
should go for Kubernetes or Service Mesh Kubernetes.
II. M ICROSERVICES
Microservices is one of the popular architectural
styles, developed a few years back. In general, it over-
comes the problem faced with the development and
deployment of a monolithic application. A monolithic
application refers to an application having multiple large
and small components deployed in the same instance.
This monolithic development seems plausible for small
scale and basic applications. However, as the number of
functionality increases and the people working on them
increase, it is best to divide and conquer independently.
A. Microservices Architecture
According to [1] and [5], Microservices is an architec-
tural style that structures an application as a collection
of services that are:
• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team
B. Microservices Example
Fig. 1. Microservices Example Application [6]
Figure 1 shows one example of how the service-side
application is broken down into different independent
components. The application is broadly divided into
frontend, backend and database. There are two types
of frontend, one is via the API gateway and other is
web frontend. The backend functionality is divided into
Account, Inventory and shipping services. Each service
is connected to a database service of the respective type.
Note that this is a small scale division into microser-
vices. In large-scale deployments, there are thousands
of microservices and thousands of instances of these
microservices.
C. Achieving Balance
Organizations and Enterprises generally work on large
and complex applications. Microservices architecture can
help them to write high-quality code, easy development,
and independent deployment. While this sounds feasible,
many issues arise when the number of Microservices
increases. Each microservice has several instances. Some
microservices depend on other microservices; the ge-
ographical distribution of the microservices should be
uniform, abruptly closed instances should be checked,
application load should be monitored to scale up and
down the number of instances, etc.
III. U NDERSTANDING K UBERNETES
Kubernetes is an open-source platform that helps in
managing multiple container instances. According to
[3], ”Kubernetes is a portable, extensible, open-source
platform for managing containerized workloads and ser-
vices, that facilitates both declarative configuration and
automation.” Here, the declarative configuration refers
to using a manifest file that stores the configuration of
the deployment. Kubernetes allows for automation in the
form of CI/CD, i.e. writing builds and tests
A. Kubernetes Architecture
Kubernetes works on a cluster of machines configured
according to the Kubernetes architecture. Many cloud
providers provide an automated Kubernetes cluster, but
it can be bootstrapped from scratch. Following is a brief
on Kubernetes cluster architecture and its elements.
Figure 2 shows a glance at the components of the
Kubernetes cluster. A pod consists of containerized ap-
plications. The Control Plane of Kubernetes manages the
worker nodes and pods in turn.
• Cluster: A Kubernetes cluster consists of a set of
worker nodes that host pods of application workload
and a Control Plane.
 Fig. 2. Kubernetes Components [3]
• Pod: A pod is a way of representing the running
process in a cluster. A pod encapsulates one or more
containers. It provides a unique network IP, attaches
storage resources, and also decides how containers
should run. Everything in a Pod is tightly coupled.
• Node: A node is nothing but a single host, which is
used to run virtual or physical machines. A node in
the Kubernetes cluster is also known as a minion.
• Service: A logical set of pods, which works to-
gether. With the help of services, users can easily
manage load balancing configurations.
• ReplicaSet: identifies the particular number of pod
replicas are running at a given time. It replaces the
replication controller because it is more powerful
and allows users to use the ”set-based” label selec-
tor.
Control Plane Components [3] (Refer Figure 1):
• kube-apiserver: Front end for the Kubernetes Con-
trol Plane. It is the central component of a Kuber-
netes cluster and it runs on the master node.All
other components interact with API server and
keep watch for changes. Most of the coordination
in Kubernetes consists of a component writing to
the API Server resource that another component is
watching. The second component will then react to
changes almost immediately.
• etcd: A distributed, consistent and highly available
key-value store which stores the desired state of the
cluster and kube-dns information.
• kube-scheduler: Watches the changes for newly
created pods with no assigned nodes, and selects a
node for them to run on. It assigns unassigned pods
to the node which has available resources (CPU and
memory) marching Pod requiremnets.
• kube-controller-manager: Manages the controller
processes within the Control Plane. Control plane
controller is a single program logically divided into
separate processes to reduce the complexity.
Node Components [3] (Refer Figure 1):
• kubelet: An agent that runs on each node of the
cluster and makes sure that containers are running
on its pods. It checks whether the assigned pods
are running on the node or not. If a new Pod is
assigned to the node Kubelet is running on, it will
pull the Pod definition and use it to create containers
through Docker or any other supported container
engine.
• kube-proxy: Kube-proxy maintains the network
rules on the nodes. These rules allow for internal
communication from pod to pod and pod to service,
and external communication (outside the cluster).
• Container Runtime: Responsible for running con-
tainers within the pods.
 IV. S ERVICE M ESH : K UBERNETES AND BEYOND
A. Limitations of Kubernetes
Although Kubernetes is one of the best orchestrator
tools to add reliability and observability, it is helpful only
up to one point. Once the number of microservices in
an application reach a limit, the Kubernetes approach of
management becomes non-sustainable [7]. This is where
Service Mesh comes in.
With Kubernetes, as the number of microservices be-
comes large, it becomes difficult to monitor the deploy-
ments, trace, and diagnose any possible issues. There is
no metric system to monitor the cluster. Along with this,
Kubernetes internal communication unencrypted, and
there are no authorization policies for communication
and data access.
B. Service Mesh Introduction
Service Mesh is a dedicated infrastructure layer built
on top of container orchestrators like Kubernetes to add
more reliability, security and, most importantly, observ-
ability. Service Mesh has been around before Kubernetes
and has developed over the years with the development
of Kubernetes.
Service Mesh was designed for microservices systems
which heavily reliant on the network. Service mesh
manages the traffic between different services. The ar-
chitecture allows for a graceful and scalable way of
introducing various services and monitoring them.
Service Mesh features [7]:
• Service Discovery: Discovering how to connect to
a particular service. This feature is leveraged from
Kubernetes. An additional cache is added in the
sidecars to store the results of the Service Discovery
• Load Balancing: Load balancing the incoming re-
quests over different pods based on several kinds of
metrics.
• Communication Resiliency: This enables retrying
for timeout requests, circuit braking and rate limit-
ing.
• Security: It provides end-to-end encryption between
different microservices and authorization policies,
to say the database, etc.
• Observability: Get Layer 7 metrics like HTTP 500
or 404, tracing and alerting based on layer 7 metrics.
• Routing Control: Traffic shifting at the application
level and mirroring.
In a Service Mesh model, application updates work
similarly in incase of standalone Kubernetes. An updated
version of the application microservice is released as a
Canary deployment keeping the older version container
applications intact. Gradually, the deployment instances
of the new version are increased, and older version
instances are decreased. Finally, the newer version de-
ployment takes place.
C. Service Mesh Architecture
There are several Service Mesh implementations out
there like Istio, Linkerd, etc., all of which share some
core features. Service Mesh architectural features are
designed to fulfil their goal of improving resiliency,
observability and discoverability across the large number
of microservices.
Service Mesh comprises of two logical planes [7], [8]:
the Control Plane and the Data Plane.
The Data Plane consists of sidecars that run alongside
the containers. The sidecars form a gateway or proxy
for all communications from and to the application
containers. This allows the Service Mesh to control
and monitor traffic for different microservices without
knowing the application functionality explicitly.
The Control Plane is an out-of-band functionality layer
as opposed to in-band sidecars of the Service Mesh. It
issues TLS certificates, responsible for configuring the
proxy configurations, and enforces policies to collect
telemetry and expose metrics. The Control Plane pro-
vides tools for controlling the Data Plane elements, often
using GUI, API and CLI.
Figure 3 shows a general traffic overview of a produc-
tion application. Blue arrows represent the North-South
traffic that comes inside via the Ingress Gateway and
goes via an Egress Gateway. Red arrows represent the
East-West traffic which describes the inter-service com-
munication traffic. The application consists of a Frontend
that contacts the Backend for a particular operation. Now,
the Backend refers to some external APIs via the Egress
Controller and the Database. This can be considered a
general overview of a deployment and traffic overflow.
Let’s consider using Kubernetes to manage traffic
overview in Figure 3. One of the issues here will be
that the Backend and Database connection will not
be encrypted, making it available for the adversary to
sniff data. One way to avoid this would be for your
operations team to issue those certificates and integrate
them into the application and database. Service Mesh
helps to automate the whole process and provide end-
to-end encryption for all the services.
Another issue using Kubernetes in Figure 3 is that,
say there is some latency at the Frontend than expected,
 Fig. 3. Traffic Overflow [4]

Fig. 4. Service Mesh Traffic Overflow [4]

finding the pod or service causing the problem is diffi-
cult. Service Mesh helps to solve this issue by enabling
to trace the problematic service or pod.
In Figure 3, say we to load balance the traffic from
Frontend to Backend. Here, we want the new request to
hit the instance having less number of requests currently.
In general, the Kubernetes HPA controller will help
in load balancing based on CPU usage or memory
usage. Still, unfortunately, Kubernetes cannot perform
load balancing based on the number of HTTP requests.
Service Mesh helps with this kind of load balancing.
The same metric can be used to scale the application
pods. Service Mesh implementation also helps in scaling
according to the HTTP requests per second per pod.
Figure 4 shows the Service Mesh traffic overflow.
Here, a sidecar proxy like Nginx or Envoy is injected
into the Frontend, Backend and Database pods. These
sidecars will be configured with TLS certificates to have
end-to-end encryption. The advantage here is that the
application doesn’t have to know about TLS, and the
sidecars handle everything.
Sidecars help in tracing problematic regions as well.
All traffic is routed in and out of the pod via its in-band
sidecar. This allows the sidecars to attach tracing headers
to find time-consuming places. The frontend pod sidecar
can attach the tracing label to the request and route to
the backend, and the backend pod can attach its label
after the processing to the response message.
D. Case Study – Istio
Istio is a popular open platform Service Mesh technol-
ogy that is experiencing dynamic growth. It is an open
platform to connect, manage and secure microservices.
It was founded in 2017 in association with Google,
IBM and Lyft, and is widely adopted in the Kubernetes
community.
Istio is considered to be one of the best implementa-
tions of Service Mesh at this point. It enables the deploy-
ment of complex microservices and provides behavioural
insights and operational control over the Service Mesh.
Some of the complex operational tasks Istio helps with
are A/B testing, Canary rollouts, rate limiting, access
control and end-to-end authentication.
Istio provides additional capabilities to the microser-
vices implementation like intelligent routing, load bal-
ancing, service discovery, policy enforcement, in-depth
telemetry, circuit breaking and retry functionalities, log-
ging, monitoring, and more.
1) Istio Architecture: Istio Service Mesh consists of
a Data Plane and Control Plane. The Data Plane consists
of Envoy deployed as the in-band sidecars [10]. These
proxies control all network communications between
different microservices. They also collect and report
telemetry on the mesh traffic.
Figure 5 shows different components of Istio Service
Mesh. Following is a brief on the components of Istio’s
core [3]:
• Envoy: Envoy is a high-performance proxy devel-
oped to mediate all inbound and outbound traffic for
Service Mesh services. Envoy proxies are deployed
as sidecars to services. The sidecar deployment
allows Istio to enforce policy decisions and extract
telemetry to monitor and generate alerts.
• Istiod: Istiod provides service discovery, configu-
ration and certificate management. Istiod converts
high-level routing rules into Envoy-specific con-
figurations and propagates them to the sidecars at
runtime. Istiod security enables strong service-to-
service and end-user authentication with built-in
identity and credential management.
V. C ONCLUSION : K UBERNETES OR S ERVICE M ESH
K UBERNETES
Kubernetes is one of the most popular solutions used
by enterprises for their applications. We have seen that
Service Mesh provides a solution to the problems leading
to the increased number of microservices. Using Service
Mesh Kubernetes solves the issue of whether the number
of microservices is high or low. However, customers
tend to use Kubernetes more often than Service Mesh
Kubernetes. This is true even for a reasonably high
number of microservices as well.
One of the main reasons for using Kubernetes over
Service Mesh Kubernetes is the complexity involved
in implementing a Service Mesh. The operations team
needs to understand and take care of the additional
components and deal with all the related issues. So, im-
plementing Service Mesh requires adding new elements
that add new functionality and complexity issues.
Service Mesh implementations like Istio and Linkerd
try to reduce the complexity of these deployments and
eases the operations teams’ strain. Also, these implemen-
tations help Kubernetes users to migrate to Service Mesh
Kubernetes with ease.
It is best to identify the application’s scale in terms
of the microservices and their deployments and decide
which solution to pick. If the number of microservices
is very high, one can go for standard Service Mesh
implementations to ease out control and management.
However, the additional benefits of Service Mesh like
load balancing, service discovery, policy enforcement,
in-depth telemetry and retry functionalities, logging,
monitoring, etc., make the adoption more likely provided
they pick standard implementations, and the operations
team is qualified to understand any complexity arising
out of it.
[1]–[17]
R EFERENCES
[1] A. Sill, The Design and Architecture of Microservices, https:
//ieeexplore.ieee.org/abstract/document/7742259/ (2016).
[2] A. L. L. M. M. F. M. R. M. L. S. Nicola Dragoni, Save-
rio Giallorenzo, Microservices: Yesterday, Today, and To-
morrow, https://link.springer.com/chapter/10.1007/978-3-319-
67425-4 12 (2017).
[3] K. Hightower, Kubernetes Documentation, https:
//kubernetes.io/docs/home (2020).
 Fig. 5. Istio Architecture [9]
[4] S. Prodan, T. Nakahara, Intro to Service Meshes and Progressive
Delivery, https://www.weaveworks.works (2019).
[5] N. A. Nuha Alshuqayran, R. Evans, A Systematic Map-
ping Study in Microservice Architecture, https://core.ac.uk/
download/pdf/188256155.pdf (2014).
[6] C. Richardson, Microservice Architecture, https:
//microservices.io (2020).
[7] J. G. Z. Z. Wubin Li, Yves Lemieux, Y. Han, Service Mesh:
Challenges, State of the Art, and Future Research Opportunities,
https://ieeexplore.ieee.org/document/8705911 (2019).
[8] K. Indrasiri, P. Siriwardena, Service Mesh: Designing,
Developing, and Deploying, https://www.researchgate.net/
publication/328946942 Service Mesh Designing
Developing and Deploying (2018).
[9] M. T. F. K. Leila Abdollahi Vayghan, Mohamed Aymen Saied,
Deploying Microservice Based Applications with Kubernetes:
Experiments and Lessons Learned, https://ieeexplore.ieee.org/
abstract/document/8457916 (2018).
[10] M. Jösch, Ronja, Managing Microservices with a Service Mesh:
An implementation of a service mesh with Kubernetes and
Istio, https://www.diva-portal.org/smash/record.jsf?pid=diva2%
3A1464891&dswid=3240 (2020).
[11] C. . A. U. . T.-C. R. . B. J. . R. O. Medel, Vı́ctor Tolón,
Client-side scheduling based on application characterization
on kubernetes, https://www.researchgate.net/figure/Kubernetes-
architecture fig1 320248964 (2018).
[12] D. M. D. P. C. F. Ozair Sheikh, Serjik G Dikaleh, Mod-
ernize digital applications with microservices management us-
ing the istio service mesh, https://dl.acm.org/doi/abs/10.5555/
3291291.3291339 (2018).
[13] Z. B. Ramaswamy Chandramouli, Building Secure
Microservices-based Applications Using Service-Mesh
Architecture, https://doi.org/10.6028/NIST.SP.800-204A
(2020).
[14] U. Z. Amine El Malki, Guiding Architectural Deci-
sion Making on Service Mesh Based Microservice Archi-
tectures, https://link.springer.com/chapter/10.1007/978-3-030-
29983-5 1 (2019).
[15] Z. B. Lee Calcote, Istio: Up and Running: Using
a Service Mesh to Connect, Secure, Control, and
Observe, https://www.oreilly.com/library/view/istio-up-
and/9781492043775/ch01.html (2020).
[16] N. C. M. J. L. S. T. Pooyan Jamshidi, Claus Pahl, Mi-
croservices: The Journey So Far and Challenges Ahead, https:
//ieeexplore.ieee.org/abstract/document/8354433/ (2018).
[17] J. B. U. A. Vı́ctor Medel, Omer F Rana, Modelling perfor-
mance resource management in kubernetes, https://dl.acm.org/
doi/abs/10.1145/2996890.3007869 (2016).