[No Audio]
All right, huge disclaimer. Since all of you have
already studied Docker Swarm, Service will be a
term which you are already familiar with. But both
of these Services are different. In case of Swarm,
Service acted like a deployment, where you can
declare all of the desired objects and manager
will convert them into tasks.
But here in Kubernetes, Services are merely networking objects
for Pods. Since both of the forms chose to have
different interpretation for the same term,
it becomes our job not to get confused around it.
With that out of the way, let's dig deep into
Kubernetes Services. Firstly, Services are also
objects just like Pods or Controllers, but they
fall under the category of connectivity.
To understand how Services work, let's take two dummy Pods
Blue Dark and Pink Dark.
We want these Pods to be able to talk, talk to external world
or simply to each other. Then Services are
connectivity objects, which serve as a stack of
network configurations, which can allow Pods to
be able to communicate. Just like deployments or
ReplicaSets, Services also use labels and
selectors to determine which pods will be connected to them.
Our pods have label DB and DP.
Whereas our Service has a selector looking for DB.
So Dark Pink won't affiliate with the Service.
Dark Blue's connectivity will now be handled by
this Service, and it can potentially talk to the
outside world as well. Remember the word,
potentially talk, not necessarily. Let's brief up
the Services. First two points are already
familiar to you, but they are important to list out.
You might be surprised that Kubernetes itself
uses these Services to perform all sorts of in-cluster
and global communications. Services
generally provide cluster IP to each Pod, which
allows it to talk within cluster. But if we choose
to abstain from such a practice, we can create a
headless Service. And finally, Kubernetes also
provides native support for multi-port Services
and cloud load balancers. We recently mentioned
that Services can make Pods potentially talk to
outside world. But why potentially? Well, because
Services also have types. First of them is ClusterIP,
which only exposes the Service within the cluster.
It means that outside world can't access it,
but Pods within the cluster connected to this
Service can talk to each other. Second type is
NodePort, which exposes the Service on the
external IPs of all of the nodes of the cluster,
including Master. This will by default also create
a Cluster IP, where the NodePort will be routed
eventually. If we have defined a cloud provided
LoadBalancer, we can use LoadBalancer type
Service, which doesn't only expose it to all
nodes, but also provides dedicated external IPs to
the Pods connected to the Service. And finally,
we have ExternalName, which allows us to use DNS
address to communicate to ports connected to the Service.
In next lecture, we will take a look at
ClusterIP and NodePort Services.
Whereas we will visit Load Balancers
when we run Kubernetes on a managed cloud provision.