Several organizations are going through some sort of architectural transformation. Scratch the surface of any current digital transformation and we will find microservices. Migration to microservices is not a trivial change. You must understand if it will really solve your problem otherwise you might create a tangled entity that might kill you. Let me remind you that monoliths are not an enemy that should be killed. Turning to microservices architecture is about independent upgradation. There are some incremental change patterns that can help you to estimate and migrate to a microservices environment.
Speaking in favor of distributed applications, even a simple pod communication has three components. Every module needs to be aware of how to reach other components, must get a grasp of the security rules of establishing the connection, and a action plan to handle failures. It would be great to have centralized config to manage them independently, and that’s the function of service mesh does. Hear the service mesh abstracts the networking from application and keep it as a independent unit. Generally, such mesh provides important features as service discovery, load balancing, encryption, observability, traceability, authentication and circuit breaker pattern etc.
Istio Intro
Istio is one of the fully featured service mesh. It logically split into a data plane and a control plane. It works by taking advantage of the network setup in the operating system. The data plane consists of intelligent proxies deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic. The control plane manages and configures the proxies to route traffic.
- Easy Installation: Fewer installation steps enable developers to kick-start Istio control plane. Helm, Istioctl, Operator, etc can be used.
- Network is modeled uniformly. Microservice may have modules in different languages and different network protocols, but Istio gives you a consistent way to define all the rules.
- Observability advantages. In istio all network packets go through proxies, and they are recorded for sending live metrics. Microservice architecture gets more complex as new modules are added upon.
- Improved responsiveness: Communication between modules becomes assured.
- Reduced resource utilization: Caches can be shared safely, which decreases the resource consumption.
Traffic Routing
Istio starts traffic management with out of the box traffic routing rules offered by it. Thies routing module help the application to be more resilient to failure. Because, routing module generate some metrics data which help Istio to determining helth of the different module.
- Virtual Service
This resource helps us to manage the traffic load by decoupling the service requests with the traffic routing rules. From the same Virtual Service config we can manage behavior of multiple hostnames.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: abc-vs
spec:
hosts:
- abc.xyz.com
http:
- match:
- headers:
end-user:
exact: /api
route:
- destination:
host: /- Gateway
Gateway helps to control and monitor the ingress and egress traffic at a global level. We can specify the kind of protocol we wish to let enter the Istio service mesh for further routing to the destination. Soon after the request hits the ingress load balancer, it searches for an equivalent gateway. Then it allows the request to enter the mesh.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: abc-gtwy
spec:
selector:
app: abc
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- abc.xyz.com
tls:
mode: SIMPLE
credentialName: abc-tls-cert- Sidecars
Sidecars help us to limit /manage the traffic reaching the port of Envoy proxies associated with the Workload of the application. The Sidecar configuration provides a way to fine tune the set of ports, protocols that the proxy will accept when forwarding traffic to and from the workload. In addition, it is possible to restrict the set of services that the proxy can reach when forwarding outbound traffic from workload instances.
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: abc-eu2
spec:
egress:
- hosts:
- "abc-eu2/*"
- "abc-apis/*"
- "istio-system/*"Encrypting Traffic with Mutual TLS
Security is always a major concern, a challenge we frequently face while using micro service solution is how to secure networks between entities. Our approach would mostly be encoding authentication mechanism in application codebase itself. However, this approach is tiresome for developers and would take away the system resource and developer time. Istio provides an out of the box solution to encrypt traffic.
Istio supports mutual-TLS, it means that clients share a certificate to identify themselves, as well as servers share a certificate to use for encrypting traffic. Istio automatically configures workload sidecars to use mutual TLS when calling other workloads. By default, Istio PERMISSIVE mode is enabled, a service can accept both plain text and mutual TLS traffic. To only allow mutual TLS traffic, the configuration needs to be changed to STRICT mode.
Monitoring Communication and Performance
All of the application network passes through service mesh. Proxie sidecar inside the mesh helps to generate logs and Metrix. Istio support tools as Prometheus, Kiali, Zipkin, Jaeger etc. So you can get a detailed visibility into your cluster communication.
Grafana dashboards can be used to monitor status of modules, which helps in overlooking mesh (id 7639), services (id 7636), Performance (id 11829) etc. so you don’t need to have any code in your clients / servers to get that deep monitoring.
For distributed tracing of packets, which gives breakup of all network calls made from service inside the cluster. Jaeger could be used to tracing transactions between distributed services. It is mainly used for troubleshooting in complex microservices environments.
If the environment is simple in nature, then we could use Kiali UI, a opensource add-on for Istio, which gives us a real time traffic overview of the service mesh. The main advantage is that you need not change any set up in the running application, just install the out of the box tool. The monitoring tools will add quite a bit of computational overhead to the cluster so all these observability features are optional.
Istio Vs. Linkerd Vs. Consul Connect for Kubernetes Service Mesh
Istio is something more than their peers like Linkerd etc, the Service Mesh and Open Service Mesh Interface are establishing a standard model to describe service mesh features. Being far independent from the actual mesh technology. Traefik Mesh works in a different manner, where it utilizes a shared network proxy for every service.
Attaching a service mesh into the cluster brings a significant overhead. If you use it for traffic routing and observability, then any of the mesh could be utilized. In most cases, it will be Istio or Linkerd, because others don’t have the same community support or maturity level. Their choice boils down to complexity versus features.
Great, now try yourself :)
