1

00:00:00,860 --> 00:00:03,320

Hello and welcome to this lecture in this lecture



2

00:00:03,320 --> 00:00:11,030

we will discuss about the Kubernetes Service -ClusterIP. A full stack web application typically has



3

00:00:11,060 --> 00:00:15,420

different kinds of pods hosting different parts of an application.



4

00:00:15,590 --> 00:00:22,040

You may have a number of pods running a front end web server another set of pods running a back end



5

00:00:22,040 --> 00:00:29,480

server, a set of PODs running a key-value store like Redis, another set of PODs running a persistent



6

00:00:29,480 --> 00:00:36,990

database like MySQL. The web front end server needs to communicate to the back end servers and



7

00:00:36,990 --> 00:00:42,420

and the backend-workers need to connect to database as well as the redis services etc..



8

00:00:42,690 --> 00:00:51,180

So what is the right way to establish connectivity between these services or tiers of my application.



9

00:00:51,390 --> 00:00:58,440

The pods all have an IP address assigned to them as we can see on the screen but these IP as we



10

00:00:58,440 --> 00:01:00,360

know are not static.



11

00:01:00,360 --> 00:01:05,580

These pods can go down any time and new pods are created all the time.



12

00:01:05,580 --> 00:01:12,060

And so you cannot rely on these IP addresses for internal communication between the application.



13

00:01:12,060 --> 00:01:21,130

Also what if the first front-end POD at 10.244.0.3 need to connect to a backend service?



14

00:01:21,330 --> 00:01:23,240

Which of the three would it go to



15

00:01:23,280 --> 00:01:25,430

and who makes that decision.



16

00:01:25,650 --> 00:01:33,540

A kubernetes service can help us group these PODs together and provide a single interface to access



17

00:01:33,540 --> 00:01:35,730

the PODs in a group.



18

00:01:35,850 --> 00:01:43,320

For example a service created for the backend PODs will help group all the backend PODs together and



19

00:01:43,320 --> 00:01:48,490

provide a single interface for other PODs to access this service.



20

00:01:48,750 --> 00:01:54,140

The requests are forwarded to one of the PODs under the service randomly.



21

00:01:54,210 --> 00:02:00,660

Similarly create additional services for Redis and allow the backend parts to access the redis systems



22

00:02:00,660 --> 00:02:02,250

through the service.



23

00:02:02,250 --> 00:02:10,830

This enables us to easily and effectively deploy a microservices based application on kubernetes cluster.



24

00:02:10,830 --> 00:02:18,810

Each layer can now scale or move as required without impacting communication between the various services.



25

00:02:18,900 --> 00:02:26,280

Each service gets an IP name assigned to it inside the cluster and that is the name that should be used



26

00:02:26,610 --> 00:02:29,680

by other pods to access the service.



27

00:02:29,700 --> 00:02:37,710

This type of service is known as cluster IP to create such a service as always use a definition file



28

00:02:38,040 --> 00:02:43,560

in the service definition file first used to default template which has API version kind.



29

00:02:43,560 --> 00:02:51,380

Metadata and spec the API version is V1 kind is a service and we will give a name to our service.



30

00:02:51,420 --> 00:03:00,240

We will call it backend under specification we have type and ports the type is cluster IP in fact cluster



31

00:03:00,240 --> 00:03:02,370

IP is the default type.



32

00:03:02,370 --> 00:03:10,430

So even if you didn't specify it it will automatically assume the type to be cluster IP under ports.



33

00:03:10,440 --> 00:03:18,370

We have a target port and port the target port is the port where the backend is exposed which in this



34

00:03:18,370 --> 00:03:24,830

case is 80 and the port is where the service is exposed which is 80 as well.



35

00:03:25,180 --> 00:03:33,040

To link the service to a set of pods we use selector we will refer to the pod definition file and



36

00:03:33,040 --> 00:03:38,530

copy the labels from it and remove it under selector and that should be it.



37

00:03:38,650 --> 00:03:45,580

We can now create the service using the kubectl create command and then check its status using the



38

00:03:45,580 --> 00:03:48,630

kubectlget services command.



39

00:03:48,640 --> 00:03:57,080

The service can be accessed by other PODs using the ClusterIP or the service name.



40

00:03:57,160 --> 00:04:00,640

That's it for this lecture and I will see you in the next lecture.