Managing Microservices With Istio Service Mesh in Kubernetes
Services are at the core of modern software architecture. Deploying a series of standard, little (micro-)services instead of massive monoliths provides developers the flexibleness to figure in several languages, technologies, and unharness cadence across the system; leading to higher productivity and speed, particularly for larger groups.
With the adoption of microservices, however, new issues emerge because of the sheer variety of services that exist in a very larger system. issues that had to be resolved once a stone, like security, load equalization, monitoring, and rate-limiting have to be compelled to be handled for every service.
Moving to microservices network challenges
- Network Reliability
- Fault tolerance and resiliency
- Monitoring and Observability
The evolution of microservices frameworks: from NetFlix OSS to Istio
Microservices challenges
- Challenge 1 = N to N communications.
- Challenge 2 = Distributed software interconnection and troubleshooting are hard.
- Challenge 3 = Containers should stay thin and platform agnostic.
- Challenge4 = Upgrade of polyglot microservices is hard at scale.
Service Mesh ( buoyant.io)
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud-native application
Each service will have its own proxy service and all these proxy services along kind the “Service Mesh”. All the requests to and from each service will go through the mesh proxies. Proxies are also known as sidecars.
History of Istio
- Envoy proxy (Istio data plane) was created by Lyft and open-sourced in 2016.
- IBM and Google launch the project in May 2017
- The first major version was released in July 2018.
- Current version: 1.3
Istio goal
Develop an open technology that gives a consistent medium to connect, secure, manage and monitor a network of microservices despite the platform supply or merchant.
Solution Istio Promises
● concentrate on business logic and spent less time with common considerations.
● No change in the service code.
● Central configuration management.
● Easy to upgrade
● Security
Istio does:
- Service discovery
- Load Balancing & Intelligent Routing
- Resiliency: Circuit Breaker & Retry
- Rate Limiting
- Authentication and Authorization
- Service to Service mTLS
- Policy enforcement
- Observability
- Monitoring metrics
- Distributed tracing
Istio does not:
- Event-Driven Asynchronous communication
- Service Orchestration
Service Discovery Challenge
Kubernetes provides service discovery, why do I need an extra one?
Istio supports:
- HTTP L7 filter
- HTTP L7 routing (based on HTTP headers and cookies)
- First-class HTTP/2
- gRPC support
- Fine-grained traffic splitting
Architecture
Istio building blocks 1
- Pilot = Responsible for service discovery and for configuring the Envoy sidecar proxies
- Citadel = Automated key and certificate management
- Mixer = Istio-Policy: policy enforcement Istio-Telemetry: gather telemetry data
- Galley= Configuration ingestion for istio components
- Ingress Gateway =manages an inbound connection to the service mesh
- Egress Gateway = manages outbound connection from the service mesh
- Sidecar injector = Inside sidecar for enabled pods/namespaces
Istio building blocks 2
- Prometheus =Metrics collection
- Grafana = Monitoring dashboard
- Jaeger =Distributed tracing
- Kiali =Observability dashboard
👋 Join us today !!
If this post was helpful, please click the clap 👏 button below a few times to show your support! ⬇
