WEBVTT

00:00.470 --> 00:02.920
-Let us now look
at another type of service

00:03.080 --> 00:06.340
known as the load balancer type.

00:07.710 --> 00:11.530
We have seen the NodePort service
that helps us make

00:11.690 --> 00:16.370
an external-facing application
available on a port on the worker nodes.

00:17.270 --> 00:20.540
Let's turn our focus
to the front-end applications,

00:20.700 --> 00:22.930
which are the voting app
and the result app.

00:23.850 --> 00:28.670
We know that these pods are hosted
on the worker nodes in a cluster.

00:29.140 --> 00:32.150
Let's say we have a four-node cluster.

00:32.700 --> 00:36.610
To make the applications accessible
to external users,

00:37.060 --> 00:40.310
we create the services of type NodePort.

00:41.210 --> 00:45.320
Now, the services with type NodePort help

00:45.480 --> 00:47.740
in receiving traffic
on the ports on the nodes

00:47.950 --> 00:50.270
and routing the traffic
to the respective pods,

00:50.950 --> 00:55.040
but what URL would you give your end-users
to access the applications?

00:55.470 --> 00:59.390
You could access any
of these two applications using IP

00:59.560 --> 01:02.610
of any of the nodes and the high port

01:03.760 --> 01:05.290
with the services exposed on.

01:05.900 --> 01:10.560
That would be four IP and port combination
for the voting app and four IP

01:10.730 --> 01:12.730
and port combination for the result app.

01:13.420 --> 01:18.370
Note that even if your pods
are only hosted on two of the nodes,

01:18.670 --> 01:22.970
they will still be accessible on the IPs
of all the nodes in the cluster.

01:23.250 --> 01:26.120
Say the pods for the voting app
are only deployed on the nodes

01:26.280 --> 01:28.220
with IP 70 and 71,

01:28.560 --> 01:30.960
they would still be accessible
on the ports of all the nodes

01:31.130 --> 01:32.130
in the cluster.

01:32.470 --> 01:35.050
That's how a service is configured.

01:35.600 --> 01:40.040
You would share these URLs
to your users to access the application,

01:40.620 --> 01:42.120
but that's not what the end-users want.

01:42.290 --> 01:46.740
They need a single URL,
like example-voting-app.com,

01:46.910 --> 01:51.150
or the example-result-app.com
to access the application.

01:51.780 --> 01:53.120
How do you achieve that?

01:53.770 --> 01:59.570
One way to achieve this is to create
a new VM for load balancer purposes

01:59.980 --> 02:03.170
and install and configure
a suitable load balancer on it

02:03.340 --> 02:06.560
like HAProxy or Nginx, et cetera.

02:07.280 --> 02:12.440
Then configure the load balancer
to route traffic to the underlying nodes.

02:13.410 --> 02:16.890
Now, setting all
of that external load balancing

02:17.060 --> 02:21.430
and then maintaining and managing that
can be a tedious task.

02:22.470 --> 02:25.760
However, if we were
on a supported cloud platform

02:25.930 --> 02:29.550
like Google Cloud, or AWS, or Azure,

02:29.760 --> 02:33.770
I could leverage the native load balancer
of that cloud platform.

02:34.600 --> 02:38.620
Kubernetes has support for integrating
with the native load balancers

02:38.790 --> 02:43.640
of certain cloud providers
and configuring that for us.

02:44.500 --> 02:49.760
All you need to do is set the service type
for the front-end services

02:49.930 --> 02:52.330
to load balancer instead of NodePort.

02:53.180 --> 02:57.200
Remember that this only works
with supported cloud platforms,

02:57.450 --> 03:01.660
so GCP, AWS, and Azure
are definitely supported.

03:02.170 --> 03:04.610
If you set the type
of service to load balancer

03:06.220 --> 03:09.240
in an unsupported environment
like VirtualBox,

03:09.560 --> 03:11.890
or any other environment,

03:12.370 --> 03:16.420
then it would have
the same effect as setting it

03:16.580 --> 03:20.930
to NodePort where the services
are exposed on a high-end port

03:21.100 --> 03:22.100
on the nodes.

03:22.570 --> 03:27.920
It just won't do any kind
of external load balancer configuration.

03:28.530 --> 03:32.800
Later on, when we walk
through the demos of deploying

03:32.970 --> 03:34.720
our application on cloud platforms,

03:35.030 --> 03:37.400
we will see this in action.

03:37.830 --> 03:39.310
That's it for now.

03:39.610 --> 03:41.680
I will see you in the next lecture.