Istio: the service mesh king for Kubernetes
In Kubernetes everything goes lightning fast. Every single bit could change any moment, in any container, literally. Although Kubernetes is getting more polished at each release, there still are things that are a bit rough around the edges that require a skilled engineer to address. Meet Istio, the solution to many of those problems, and the beginning of a new approach to microservices.
What is Istio? Easy: A service mesh… what’s a service mesh again?
Istio is a service mesh. Great, but what is a service mesh? In a “microservices environment” it becomes increasingly difficult to connect, monitor and enforce policies across services. In a standard environment you could easily configure a firewall or set up SSL manually for each server/service, but in a microservices environment where services can reach outrageous numbers you can’t do it by hand. To alleviate this problem configuration management tools such as Ansible or Puppet can be employed, but they were born for different purposes so they’re a tight fit. That is why service meshes were born.
So, what’s a service mesh?
A service meshes on the other hand is an abstraction layer (sometimes they are also referred to as planes) that enables the administrator to perform some or all the operations mentioned above in a systematic and transparent way. Let’s take for example TLS: imagine having 500 services that need to communicate with each other securely. Each one needs to have a proper TLS certificate and to trust the others. You can get away with an internal certificate authority, but installing 500 certificates by hand becomes tedious. Now imagine 1 billion services. You can guess what’s going to happen… Imagine something that could do this automatically without manual set up. You guessed right: service mesh. But that’s just one of the benefits you get, in particular service meshes usually:
- provide a way to perform mutual TLS authentication. (TLS is just a de-facto standard, but there may be alternatives in the future.)
- offer observability over the mesh and its services (e.g. you can monitor a particular kind of traffic).
- allow to enforce network-wide policies or even fine-grained per-service policies.
- connect the services and allow complex-operations such as blue-green deployment strategies.
- perform load balancing and traffic shaping/policing.
Istio emerged as one of the first service meshes for Kubernetes (and beyond). Backed by the likes of IBM, Google and Lyft, it is now the most powerful service mesh for Kubernetes. Although the operations Istio performs are pretty complicated, Istio itself is divided in a few components belonging to one of two planes:
- Data plane: where the actual data flows.
- Control plane: where information about the mesh flow (e.g. routing decisions).
- Envoy: is a “sidecar” service running alongside each service (in the same pod). Envoy controls the service communications and provides a handful of statistics and useful information.
- Mixer: is the “brain” of the mesh, it performs policy enforcement and collect statistics.
- Pilot: is the “autopilot” of the mesh, it performs service discovery among Envoy instances, and allows for intelligent routing (e.g. A/B testing).
- Citadel: is the “guard” of the mesh, it enables service-to-service and end-user authentication.
- Galley: is the “librarian” of the mesh, it performs configuration validation and processing.
Istio benefits and shortcomings
Istio eases DevOps teams by performing common tasks and ultimately reduces the strain on both ends (Developers, Administrators). Automating procedures such as load balancing and TLS terminations, Istio enables more consistent deployments and stricter security.
Although great in almost everything it does, Istio is pretty complex and requires careful planning before deploying. It also requires skilled administrators that can crank up the system and operate it for a prolonged period of time to achieve its fullest potential.
Latest posts by mark (see all)
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020