Welcome to part three of our four-part Istio series, introducing a leading solution to microservices challenges. Earlier instalments covered an executive introduction to the technology and a technical deep dive. Here, we consider comparative analysis of the platform.
Istio is a leading service mesh solution with a proven track record of successful use cases in production. The Istio community is prolific, dynamic, and continues to introduce new features very frequently. Istio is possibly the most feature-rich solution on the market and has a mature ecosystem of tools and vendors.
Service Mesh Comparison
With several service mesh solutions on the market, it’s important to conduct a thorough analysis of the available options. While many solutions are similar in concept and functionality, key aspects to be considered and compared during selection are:
- Features supported (further reading)
- Feature roadmap
- Production readiness
- Number of actual production deployments or Go-Lives
- Governance, licensing, and commercial support vendor ecosystem
- Community activity around new features and support
- Out-of-the-box support of current business use cases
Our detailed analysis of these factors has determined that Istio service mesh is the best option. This article explains the Istio architecture, the Envoy proxy providing computational power, and the feature set that Istio supports. Our goal is to help you understand Istio and how it works, so you can feel confident in its use.
Istio Architecture
Like any modern architecture, Istio is composed of two component types: the control plane and the data plane.
The control plane is made up of multiple internal modules that implement specific functionality and work in parallel. It is responsible for service discovery, configuration management and propagation, certification use and management, and policy propagation in the mesh.
The data plane is primarily a proxy/sidecar container based on Envoy. It is deployed transparently, in parallel with the application container.
From the sidecar, all requests coming into or going out of the application container are intercepted by Envoy (see Figure 1). Proxies communicate with a control plane, which discovers the target service based on business communication implemented to complete the business transaction.
Proxies also ensure that communication exhibits the configuration and policy defined and declared in the mesh by different Istio Custom Resource Definitions (CRDs). Based on the security configuration, a proxy also ensures that necessary certificates are applied so that communication is secure. In addition, proxies regularly provide metrics to control planes about the health and behaviour of applications in the mesh.
Heart of Istio – Envoy (sidecar)
Most of Istio’s magic is driven by a data plane component in the form of a network proxy transparently deployed as a sidecar alongside each application container. The proxy implementation used by Istio is Envoy, the Cloud Native Computing Foundation (CNCF) graduate project. It’s a very powerful sidecar project, very well tested at Uber for its production use cases, and ultimately open-sourced to the community.
Some important aspects/characteristics of Envoy include:
- A C++ based L4/L7 proxy
- Low-memory footprint
- Battle-tested @ Lyft
- 100+ services
- 10,000+ VMs
- 2M req/s
- Key Features
- API-driven configuration updates (no reloads)
- Zone-aware load balancing with failover
- Traffic routing and splitting
- Health checks, circuit breakers, timeouts, retry, fault injection
- HTTP/2 and gRPC
- Transparent proxying
- Designed for observability
Istio Features
Compared to other service mesh solutions, Istio has the most advanced features that cater to modern architecture use cases. Those features are categorised in the following sections.
Intelligent Routing and Load Balancing
- Controlling ingress and egress
- Load balancing: round-robin, random, weighted least request
- Dynamic routing based on control header, geo, os, identity
- Gradual rollouts
- A/B testing by dynamic routing or service promotion (experimental, community, Beta, Prod, internal, etc.)
- Service virtualisation (mock tests)
- Canary release
- Mirroring
Resilience Across Languages and Platforms
- Circuit breakers
- Timeouts
- Retries
- Rate limits
- Health checks
- Fault injection
- Differentia for detecting regressions
Service Identity and Security
- End-user authentication with JWT
- Key and certificate generation, distribution, rotation and revocation, termination
- mTLS authentication
- Role-based access control
- Control access using simple denials, attribute-based, or IP-based black/white listing
In-Depth Telemetry and Reporting
- Service logs
- Distributed tracing
- Service metrics
- Istio dashboard in Grafana
- Service mesh graph visualisation
Enable Istio in the Mesh
Istio can be enabled while setting up the cluster, as well as in the active working cluster. Enablement is a transparent process and does not require any change in the application operation.
Istio enablement functions are based on an Admission Controller webhook in the Kubernetes API. The Kubernetes Admission Controller functions either by validating or mutating the request. Istio is enabled by way of mutating the new object creation/updating request in Kubernetes. As part of mutating, the Istio control plane injects a block of code in the form of the definition of two additional containers to be created as part of creating the application pod. These two containers are:
- Init which initialises iptables rules to ensure in-out traffic through a proxy.
- Proxy which processes proxying requests and responses with custom handling pre/post request/response.
Istio can be enabled in the mesh using manual or auto injection.
Manual Injection
The Istio-provided utility istioctl updates the required deployments one by one and applies them in the cluster.
kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n tutorial
Auto Injection
If Istio needs to be enabled throughout the mesh, an automated mechanism should be used. Auto injection can be configured at:
- Cluster/Mesh Level – a default policy (configured in the ConfigMap istio-sidecar-injector). It is applicable to the entire cluster/mesh.
- Namespace Level – webhooks are based on the namespaceSelector (istio-injection=enabled). This allows the Istio feature to be enabled selectively per namespace.
- Per-pod Level – override annotation (sidecar.istio.io/inject=true). This mechanism enables Istio features at the pod level by overriding annotation. The annotation takes precedence over namespace or cluster level setting.
Innovation Drives Progress
Comparing service mesh to existing systems identifies the clear benefits of new designs. It describes new applications of existing architectures, and highlights effective new configurations to evolve future development and productivity.
You can try your hand with Istio by referring to its getting started documents. Or you can contact us to help kick-start your journey with Istio service mesh implementation.
Either way, check out the rest of the articles in our Istio series:
Kamesh is seasoned technology professional focused on solving real world problems of enterprises using modern, innovative architecture having high emphasis on zero-trust security. He has led some of the largest digital transformation projects end-to-end from solution to delivery. He keeps a high focus on customer orientation, security, innovation & quality.
