Istio- Getting started

I recently wrote about service mesh and how it helps ease managing and deploying services. Istio is an open-source service mesh that layers transparently onto existing distributed applications. Istio helps to create a network of deployed services with load balancing, service-to-service authentication, monitoring with no additional coding requirements. Istio deploys a sidecar for each service which provides features like canary deployments, fault injections, and circuit breakers off the shelf.

Let’s take a look at Istio at a high level

The overall architecture of an Istio-based application.
Image source: https://istio.io/latest/docs/concepts/what-is-istio/

Data Plane: as we can see in the design above that Data Plane uses sidecars through Envoy Proxy and manage traffic for microservices.

Control Plane: Control plane helps to have centralized control over network infrastructure and implement policies and traffic rules.

Control plane functionality (https://istio.io/latest/docs/concepts/what-is-istio/)

Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.

Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.

A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.

Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.

Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.

Currently Istio is supported on

  • Service deployment on Kubernetes
  • Services registered with Consul
  • Services running on individual virtual machines

Lets take a look at core features provided by Istio

Traffic management

Istio helps us manage traffic by implementing circuit breakers, timeouts, and retries, and helps us with A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits.

Security

Another core area where Istio helps is security. It helps with authentication, authorization, and encryption off the shelf.

While Istio is platform-independent, using it with Kubernetes (or infrastructure) network policies, the benefits are even greater, including the ability to secure pod-to-pod or service-to-service communication at the network and application layers.

https://istio.io/latest/docs/concepts/what-is-istio/#security

Observability

Another important aspect that Istio helps with is observability. It helps managing tracing, monitoring, and logging. Additionally, it provides a set of dashboards like Kiali, Grafana, Jaeger, etc to help visualize the traffic patterns and manage the services.

Additional Resources –

https://platform9.com/blog/kubernetes-service-mesh-a-comparison-of-istio-linkerd-and-consul/

https://istio.io/latest/docs/

https://dzone.com/articles/metadata-management-in-big-data-systems-a-complete-1

Kubernetes

Sometime back I talked about the importance of containers in implementing Microservices-based applications. Implementing such a design comes up with its own challenges, that is, once the number of services and containers grows, it becomes difficult to manage so many container deployments, scaling, disaster recovery, availability, etc.

Container Orchestration with Kubernetes

Because of the challenges mentioned above with container-based deployment of Microservices, there is a strong need for container orchestration. There are a few Container orchestration tools available but it will not be wrong to say that Kubernetes is the most popular at this point of time.

Kubernetes or K8s as it is popularly knows, provides following features off the shelf

  • High availability – no downtime
  • Scalability – high performance
  • Disaster Recovery – backup and restore

Kubernetes Architecture

Image Source: https://kubernetes.io/docs/concepts/overview/components/

Let us take a look at how K8s achieves the features we mentioned above. At the base level, K8s nodes are divided into Master node and Worker nodes. The master node, as the name suggests is the controlling node that manages and controls the worker nodes. Master node makes sure services are available and scaled properly.

Master Node

Master node contains contains following components- API server, Scheduler, Controller and etcd.

API server: The API server exposes APIs for various operations to external users. It validates any request coming in and processes it. API can be exposed through REST calls or a command-line interface. The most popular command-line tool to access API is KubeCTL.

Scheduler: When a new pod (we will look into pods shortly when discussing worker nodes) is being created, the scheduler checks and deploys the pod on available nodes based on configuration settings like hardware and software needs.

Controller/ Control Management: As per official K8s documentation, there are four types of controllers that manage the following responsibilities.

  • Node controller: Responsible for noticing and responding when nodes go down.
  • Replication controller: Responsible for maintaining the correct number of pods for every replication controller object in the system.
  • Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
  • Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.

etcd: The etcd is a key-value database store. It stores cluster state at any point in time.

Worker Node

kubelet: It runs on each node and makes sure all the containers running in pods are in healthy state and takes any corrective actions if required.

kube-proxy: It maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.

Pods and Containers:  One can think of a Pod as a wrapper layer on top of containers. Kubernetes does not want to work directly with containers to give it flexibility so that the underlying layer does not have any dependency.

Containers vs VM

We have talked about how Virtual Machines or VMs have made life easier for development teams as one can just onboard a VM from a cloud service provider and deploy the application on it. One major challenge with Virtual machines is that they are heavyweight.

Let’s take a look at how virtual machines are designed to work

Image Source: https://www.docker.com/

Rather than directly installing an operating system, there is a layer of hypervisor that abstracts underlying hardware. This allows separation of the OS layer, and one can independently install any OS without worrying about the infrastructure layer. As we can see each VM is a completely independent system in itself where an OS is managing hardware and software resources. Now the problem here is that OS itself is a heavy piece of Software and normally needs a good amount of processing capabilities in terms of CPU, RAM, and Storage.

To understand the scope of the problem, let us say we need to deploy three services for an application, a product detail service, a search service, and a shopping cart service. To keep them independently maintainable and scalable, it makes sense for us to deploy them separately. So we can take thee different set of VMs and deploy services. As we can see, that an additional burden we need to carry is each VM has its own OS that is eating up our compute resources.

The solution here provided by containers is to move abstraction one layer above the OS. That is, instead of directly installing our services or application servers on OS, we create containers above the OS layer, which gives us the flexibility to deploy multiple containers on a single OS.

The image below should clarify the though process.

Image Source: https://www.docker.com/

The docker layer here represents the container engine. Docker is a technology, created by the namesake company which helps us implement the container-based deployments for our application. Rather than re-inventing the wheel, let’s take a look at definition provided by https://www.docker.com/

Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space. Containers take up less space than VMs (container images are typically tens of MBs in size), can handle more applications and require fewer VMs and Operating systems.

Coming back to our example of three services, now instead of creating three machines we can generate three containers on single machine helping us use our resources in optimised manner.