SPEAKER 1: We got a brief overview of service objects
last season.
But it's time to take a deeper dive into services.
[MUSIC PLAYING]
Hiya, Kaslin.
It's good to see you.
I was just getting ready to learn more about services.
Maybe you could help me out?
SPEAKER 2: Sure.
I remember how we covered how services
were used to abstract away pod lifecycle events last season.
SPEAKER 1: Right.
Because pods are made to be started,
stopped, terminated, and created.
But oftentimes, applications need
to have a long-lived or permanent address
to reach for interacting with services.
SPEAKER 2: Yes.
So if you had a server back end for storing images,
it might not matter which pod serves the data back
to your front end.
But the front end would always need
to know where to find your back end to request pictures.
SPEAKER 1: And since each pod gets its own IP address, that
would be a lot to manage, storing an IP address whenever
a pod gets started or stopped.
So services exist to store them for us,
making app development much easier and more scalable.
But I remember we created a special type of service
last time called a LoadBalancer.
What was that about?
SPEAKER 2: Well, see, there's more than
just one type of service.
Depending on what you're trying to do,
one may be more suited to your needs.
But before that, let's go into how to define services.
SPEAKER 1: If I had a set of pods
that each listen on TCP port 9376
and carry a label app equals MyApp,
the YAML manifest file would look like this.
This specification creates a new service object
called my-service, which targets TCP port
9376 on any pod with the app equals MyApp label.
This is taking traffic from port 9376
and routing it to the pod's default port, port 80, which
greatly simplifies app development.
Wait a minute.
What IP address does a service have?
When I say it's getting traffic from port 9376, that
must mean the service itself gets an IP address, right?
SPEAKER 2: Right.
Kubernetes assigns this service an IP address,
which is sometimes called the ClusterIP.
And this brings us to the first type of service,
the default ClusterIP type.
The ClusterIP service type is only
reachable from other points within the cluster.
We actually used these before, last season,
to connect our front-end service to the auth
and back-end services.
All of those were running in Kubernetes.
So they just needed a cluster IP to talk to each other.
SPEAKER 1: So then the next type must be the LoadBalancer type
that we also used in the last episode.
SPEAKER 2: Well, actually, no.
See, when you create a LoadBalancer-type service,
you can see that it actually has an internal ClusterIP address.
The LoadBalancer service type also
uses what's called a NodePort service underneath the hood.
SPEAKER 1: The documentation says
a NodePort service exposes a service on each node's
IP at a static point.
This type of service also has a ClusterIP.
And to access it, you reference the node IP NodePort address.
Um, please help me make sense of why we'd want to do this?
SPEAKER 2: Great question.
You see, the LoadBalancer type actually
uses NodePorts under the hood.
At some level, pods are running on nodes.
So the only way to access them is
by actually talking to the machine they're on.
The difference is that the LoadBalancer types
are pre-configured to use a Cloud provider's load
balancer for you.
So if you're using GKE on Google Cloud,
you'll be using Google Cloud's load balancer
to distribute requests from your service to your pod instances.
But what happens if you're running on-prem,
and don't have a Cloud-provided load balancer?
Or what about when you want to roll your own load balancer?
SPEAKER 1: Oh.
In that case, I'd need to access the NodePort myself, I guess.
SPEAKER 2: Exactly.
So we have ClusterIP services for routing internal traffic,
NodePorts for allowing external access to a specific port
on a specific machine, and load balancers
for using Cloud-provided LoadBalancer to route traffic
between the service's Pods.
SPEAKER 1: That's pretty robust.
Are there any other types?
SPEAKER 2: Well, there are more advanced types of services,
like external name services or headless services.
And there's even a higher-level object
called ingress objects that are used
to expose multiple services.
But I think we can save those for another day.
SPEAKER 1: Many thanks to Kaslin again
for continuing to drop Kubernetes knowledge my way.
I'm excited to go play with services more
and see what I can create for myself.
For more information about services,
please check out the links in the description.