Microservices have taken the software industry by storm. Transitioning from monolith to microservice architecture enables you to deploy your application more frequently, independently, and reliably.
In today’s world, Kubernetes and containers are the de facto standards for running microservices applications. But it brings in a whole new set of problems.
Some of the problems to solve :
- Load balancing
- Health checks
- Service discovery | Traffic management | Routing
- Circuit breaking and failover policy
- Security | Authentication | Authorization
- Metrics and telemetry
These problems need to be solved in a way that we don't code it in each service. It needs to be standardised and easy to manage. Service mesh decouples these complexities from your application and puts it in a service proxy and lets it handle it for you.
A service mesh is a software infrastructure layer for controlling and monitoring internal, service-to-service traffic in microservices applications.
A service mesh can be implemented in different ways, most popular is to deploy a proxy alongside your service. Istio deploys a proxy alongside your services, this is also known as the sidecar pattern. The sidecar abstracts the complexity away from the application and handles the functionalities like service discovery, traffic management, load balancing, circuit breaking, etc.
The ‘envoy’ from Lyft(Uber rival) is the most popular open-source proxy designed for cloud-native applications. Envoy runs alongside every service and provides the necessary features in a platform-agnostic manner. All traffic to your service flows through the Envoy proxy.
What Is Istio?
Istio is an open platform to connect, manage, and secure microservices. It provides additional capabilities in your microservices architecture.
Proxy is controlled by the control plane, from where all configuration is sent. Two main components are the proxy(deployed alongside with every service), control plane(istiod which control these proxies). Istiod provides service discovery, configuration and certificate management.
Install using istioctl
Prerequisite: Kubernetes cluster running in local/cloud.
setting profile controls which components will be installed.
Create a new namespace with istio-proxy enabled
Any pods getting deployed in the new namespace (helloworld), will have istio-proxy injected.
Running an Nginx container in namespace helloworld.
In a pod we can see 2/2 one is the service, one is istio-proxy.
Running helloworld sample with service and virtual service
Virtual service defines a set of traffic routing rules to apply to a Kubernetes service based on the matching criteria.
Inside istio download there are samples.
We will use the HelloWorld deployment and gateway.
apply both the YAML
Kubectl apply -f helloworld.yaml -n helloworld
Go to the browser at /hello
we can see 2nd result came from v2 pod. It load-balance between two pods.