Kubernetes 101: Part 6

Sidecars

Here you can see a small seat alongside the bike, right? That’s sidecar

In reality, within a pod, it can have a container a sidecar container which supports this main container. They both share the same storage and network

Sidecar container handles file loading, log shipping, monitoring etc.

This is a yaml file which creates nginx-container (main container), sidecar-container(supports the main container)

ENVOY

It’s one of the common proxies. But what is proxies?

Assume that this is an application which has it’s business logic ( codes etc) . Alongside that, it has to maintain a secure connection using TLS encryption or Authentication or Retry.

What if we remove these TLS, Auth and RETRY from this and developers just focus on buidling the business logic?

Yes, we can do this by keeping these functionality in a proxy.

Envoy is a open source proxy designed for modern service oriented architecture.

Envoy works as a sidecar proxy and therefore, traffic goes in and out through envoy.

Monoliths and Microservices

Assume that you are working with a big app

and once a small portion of the project is broken,the whole app is gone

But if we keep small portions of it and a small part of gets broken, the whole app is not broken

The term monolith is used to mean that all the functionality of an app needs to be deployed at the same time.Almost all of the functionalities share the same code base and has no clear boundaries between them. And they are tightly coupled.

For example, if we consider this as a “Book info App”’s code

This can be shown as this page:

All the information comes from different modules but not separately designed.

Let’s understand how it work:

A user lands on the product page and looks at the reviews which depends on ratings

Assume everything is written on java.

The application also takes care of authentication, authorization, networking etc…. and due to number of reviews, sometimes the reviews portion can’t hold them

And issue arises among everyone. Incase, we want to add campaign module or new version of reviews, we can’t do it too as the whole system is facing issues

To solve these things, we can transform all of these modules as microservices.

Each module is now an independent and separate application.

Our product page is a python app now, details app is ruby based, reviews is java based and ratings are saved in nodejs

Previously we faces issues as we had too much reviews and there was a problem. Therefore now, we have now different versions of reviews (v1, v2, v3)

Now, how do we solve the issue ?

As they are all different applications now, we can scale them easily and it makes things faster.

Also, we need to ensure authentication, authorization, networking etc and we have to deal it for each application .

In the monolith applications, these authentication, authorization etc…. were directly coded into the application but in microservices , each application has these.

So, things have become complex

To solve these issues, service mesh might help in

Service Mesh

We had this situation

And now we can keep all of these authentication, authorization etc… in a proxy (as a sidecar container)

The proxy is communicated with each other through data plane. Also they communicate to a server side component called control plane. Now control plane manages all the traffic into and out of the services via proxy.

This approach is known as service mesh.

Now, the proxy services can talk to each other and the management is done through service mesh.

It also helps in health check, observability, load balancing etc.

Istio

Istio is supported and implemented by leading cloud provides, kubernetes etc.

Earlier we saw this architecture

Istio uses Envoy as the proxy services

The control plane consists of 3 things.

1) Citadel: is a managed certificate generation

2) Pilot : helps with service discovery

3) Gallery: helps in validating configuration files.

They are combined together in a daemon called “Istiod”

Each pod has a agent called Istio agent for passing configuration secrets to Envoy proxies.

To install the istio, first install istio and go into the istio-version

Then install using this command

istioctl install --set profile=demo -y

You can verify the installation using this

istioctl verify-install

SO,how it works?Assume that you have a yaml file which gives details about these 6 pods

They are all in the default namespace

Also we need proxy service for each of the pods but they are not there

How do we know? We can see pod’s READY status and they have 1/1 which means they only have that specific pod.

Then were is the proxy service as we have installed istioctl?

You can analyze and see that, the default namespace is not enabled for Istio injection.

There might be multiple namespace in your cluster and so, it’s important to specify the label.

So, now we will delete all of the pods

Then we will specify the namespace which will have istio sidecar injection (meaning istio will have a envoy proxy which will act as a sidecar container)

NOw, if we run the yaml file , all of the pods will have proxy with them

These are envoy proxies which is enabled by Istio.