Red Hat Openshift recently announced a Technology Preview program for Istio on Red Hat OpenShift. This preview works with Red Hat OpenShift Platform 3.10.
Istio on @openshift is now available as a Technology Preview. https://t.co/iVKgFtxNcR
— Unix Sys Admin (@UnixSysAdmin) October 1, 2018
This annoucement was very timely given the recent release of Istio 1.0 and the Istio London meetup held on 1 October which I popped along to:
An appropriate time for the @IstioLondon meetup to learn more! https://t.co/2kRbONeUt6
— Unix Sys Admin (@UnixSysAdmin) October 1, 2018
One thing is for certain, Istio and the Service Mesh is a hot technology right now!
What is a service mesh?
In microservices, an application is reduced into a set of smaller services. These smaller services perform customised tasks which make them easier to understand and develop. However, as an application grows in complexity so do the number of such services. Rather than one big monolith where a developer knows everything around a single application, instead you have many smaller services (which can each use different technologies if needed) which can all be independent of each other. So, how do we manage this large number of services? This is where the service mesh comes in. In simple terms, a service mesh is a dedicated infrastructure layer for handling communication between services within the microservices architecture. With Istio, the most important concept to understand are the two data planes:
- The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices along with Mixer, a general-purpose policy and telemetry hub.
- The control plane manages and configures the proxies to route traffic. Additionally, the control plane configures Mixers to enforce policies and collect telemetry.
Source: https://istio.io/docs/concepts/what-is-istio/#architecture
Istio Components
Envoy – A proxy in the data plane that is deployed as a ‘sidecar’. One proxy is deployed per service and they manage all inbound and outbound traffic for all services in the service mesh
Mixer – Sits in the control plane and receives metrics from envoy
Pilot – Sits in the control plane and provides service discovery and manages traffic and routing rules (example – send 99% of traffic to Service A but 1% of traffic to a new service B, so A/B testing can be performed)
Citadel – Sits in the control plane and provided service-to-service and end-user authentication with built-in identity and credential management. This feature allows mTLS (Mutual TLS authentication) communication to occur in the data plane between services.
Fortio – Not really a core Istio component, but worth a mention. started as, and is, Istio‘s load testing tool and now graduated to be its own project.
The Istio London Meetup Group
Some links from the 1 October 2018 Istio London Meetup group:
Observability tools and patterns with Istio – Nick Joyce (Realkinetic)
First up we have @nick_joyce braving the lack of WiFi and tempting the demo gods- talking about Observability with Istio! 👏👏👏
⛵☸️🐳🔬🔍📈📊 pic.twitter.com/9b8R5FZmn5— Istio London (@IstioLondon) October 1, 2018
Video to follow.
Service Mesh Network Security – Andrew Martin (Control Plane)
Andy up next @IstioLondon meetup. Lots of starwars nudges as well. I approve. pic.twitter.com/MGNPWNkaGW
— DeathOps Doom @ Google Next (@devopsdom) October 1, 2018
Video to follow
Mutli-cluster routing: a mutli-mesh approach – Matt Turner (Tetrate)
3 impressive talks @IstioLondon 2nite @CapitalOne all w/ #live #demo on #GoogleCloud w/o wifi!@sublimino of @controlplaneio: #ServiceMesh #Network #Security@nick_joyce of @real_kinetic: #Observability #tools & patterns with #istio@mt165pro of @tetrateio: Mutli-cluster #routing pic.twitter.com/AW6J55oEsg
— Florian Rathgeber (@frathgeber) October 1, 2018
Video to follow