1
00:00:02,100 --> 00:00:06,830
To reach a pod and the container running in a pod,

2
00:00:06,830 --> 00:00:08,600
we need a service.

3
00:00:08,600 --> 00:00:13,440
Because a service object is another object Kubernetes knows,

4
00:00:13,440 --> 00:00:18,440
which is responsible for exposing pods to other pods

5
00:00:18,460 --> 00:00:22,360
in the cluster, or very important to us here

6
00:00:22,360 --> 00:00:25,700
to visitors outside of the cluster.

7
00:00:25,700 --> 00:00:27,683
So to the entire world.

8
00:00:28,620 --> 00:00:32,720
Now, pods actually already have an internal IP address

9
00:00:32,720 --> 00:00:36,270
by default, you can see this here in the dashboard.

10
00:00:36,270 --> 00:00:41,260
This pod, which I'm looking at here has an IP address.

11
00:00:41,260 --> 00:00:45,370
But there are two problems with this internal IP address.

12
00:00:45,370 --> 00:00:48,410
For one, we can't use that to access the pod

13
00:00:48,410 --> 00:00:51,980
from outside the cluster, which is a problem for us here.

14
00:00:51,980 --> 00:00:55,410
And the second problem is that it will change

15
00:00:55,410 --> 00:00:58,330
whenever a pod is replaced.

16
00:00:58,330 --> 00:01:01,260
And that happens more often than you might think,

17
00:01:01,260 --> 00:01:05,440
especially if you also have scaling or something like that.

18
00:01:05,440 --> 00:01:10,240
So you can't rely on a pod keeping its IP address.

19
00:01:10,240 --> 00:01:14,250
And therefore the IP address is some not really a great tool

20
00:01:14,250 --> 00:01:16,420
for communicating to the pod

21
00:01:16,420 --> 00:01:19,250
even if it would be cluster internal.

22
00:01:19,250 --> 00:01:22,580
Then you could use it because there it will be reachable,

23
00:01:22,580 --> 00:01:24,610
but it will still change.

24
00:01:24,610 --> 00:01:27,850
So finding pods therefore is pretty challenging,

25
00:01:27,850 --> 00:01:30,590
because the IP changes all the time.

26
00:01:30,590 --> 00:01:34,510
Now service, groups pods together

27
00:01:34,510 --> 00:01:38,570
and gives them a shared address a shared IP address.

28
00:01:38,570 --> 00:01:41,680
And this address then won't change.

29
00:01:41,680 --> 00:01:45,710
So you can use a service to move multiple pods

30
00:01:45,710 --> 00:01:48,770
into that service and make them reachable

31
00:01:48,770 --> 00:01:53,173
on that service unchangeable IP address.

32
00:01:54,100 --> 00:01:55,610
And even better than that,

33
00:01:55,610 --> 00:02:00,230
you can also tell the service to expose this address

34
00:02:00,230 --> 00:02:03,530
which doesn't change not just inside of the cluster,

35
00:02:03,530 --> 00:02:05,040
which you also can do,

36
00:02:05,040 --> 00:02:08,560
but also outside of the cluster.

37
00:02:08,560 --> 00:02:12,950
So that pods can be accessed from outside of the cluster.

38
00:02:12,950 --> 00:02:15,430
So from the entire world, in our case,

39
00:02:15,430 --> 00:02:18,130
so did we can have a look at our web app.

40
00:02:18,130 --> 00:02:22,203
And we can visit this containerized Node JS application.

41
00:02:23,040 --> 00:02:25,460
The default is that it's internal only

42
00:02:25,460 --> 00:02:28,520
but with a service, we can overwrite this.

43
00:02:28,520 --> 00:02:32,410
So without services, pods are very hard to reach

44
00:02:32,410 --> 00:02:35,820
even internally because of that changing IP address

45
00:02:35,820 --> 00:02:37,900
and from outside a cluster pods

46
00:02:37,900 --> 00:02:41,560
and therefore de containerized apps are not reachable at all

47
00:02:41,560 --> 00:02:43,713
without these service objects.

48
00:02:44,560 --> 00:02:47,963
So let's now understand how we create this service.