Learning about Istio Service Mesh
According to the Istio team, the term Service Mesh describes the network of microservices that make up such applications and the interactions between them. As a container environment grows in size and complexity, it can become harder to understand and manage. Requirements can include discovery, load balancing, failure recovery, metrics collection, and monitoring. A Service Mesh also often has more complex operational requirements, like A/B testing, canary releases, rate limiting, access control, and end-to-end authentication. Istio leverages envoy sidecars to provide for fine-grained control of routing, ACLs and monitoring.
The de facto standard is Istio which is stable and feature-rich despite being a 1.0 release. The current version is 1.0.6 but a 1.1 preview is available as well.
- Consistent routing. A consistent way to deal with routing rules across the ecosystem, across various applications.
- Security. To make sure that only the services that are supposed to communicate with each other can communicate.
- Resiliency. The mesh includes load‑balancing functionality and works together with a service discovery protocol to detect services as they come up, and age them gracefully when they disappear.
- Monitoring. The ability to do end‑to‑end monitoring – tracking a packet as it traverses the network. If you have multiple services chained together, you’re quickly able to identify the service causing a failure.
See https://istio.io/docs for more information and an excellent how-to for installing Istio
One of the most important advantages of the Istio Service Mesh is that applications do not need to implement their own security mechanisms but can manage security ACLs (Authentication Policies and Destination Rules) at the infrastructural level. It also manages telemetry and performance information.
The best way to learn something is to do it and I have been working with this for the past couple of months. I’d like to share some thoughts and lessons learned with a walk through of some simple tasks which highlight a mesh’s value.I wanted to better understand how Istio worked so I started walking through the examples on the website istio.io. As I increased my own understanding of the service mesh works, and adapted examples to work with it, I started saving these demos to Github. You can find them here. Clone the repo and run the file demo-full.sh in an Isito-ready cluster.
We start by deploying the famous httpbin and sleep containers to three newly created (and not very imaginative) namespaces (demo1, demo2, demo3).
The gateway and virtual service are included in the yaml files but you can make sure everything is running properly
for i in 1 2 3; do kubectl get all -n demo$i; done