Now that we've taken a look at a note port service we're going to start to take a look at cluster IP
as well.
Remember that the goal of a cluster IP service is to expose a pod to other pods inside the cluster to
better explore a cluster IP.
I want to give you a quick reminder on how parts of our application are working right now.
The president we've got that post project.
Anytime someone tries to create a post we are sending a request over to the event bus and the event
bus hopefully is going to emit that event or kind of broadcast that event to everything else inside
of rap including back over to post so let's try to create a new pod that is going to run event bus.
We're then going to setup some services to allow posts any best to communicate with each other.
Let me show you a diagram to help you understand what we're really going to do here.
All right.
So we have one node we currently have a pod running our post stuff and pretty soon we're going to set
up a second pod to run all the event bus code these two pods are going to have to somehow communicate
with each other.
Now unfortunately these pods cannot just reach out directly back and forth to each other like so they
technically can but there are a variety of reasons so we don't do so.
We never really know ahead of time what I.P. address a pod is going to be assigned.
And so we can't really just reach out to say local hosts whatever they 4000 like so because this pod
will not be accessible at local host.
Instead it gets assigned more or less a random IP address inside of our communities cluster.
And this event bus will not know ahead of time what that IP address is.
That's why we have to communicate between these pods through these cluster IP services the post pod
is going to want to reach out and send a message over to the event bus and we've discussed that many
times before.
But as I just said we can't reach out directly so instead we're going to create a cluster IP service
that's going to govern access to the event plus pod whenever posts wants to emit an event.
It's going to make a request over to that cluster I.P. service in turn the event bus is going to want
to send an event back over to post.
It technically wants to send an event to many other pods or any other programs inside of application
but we're not going to worry about creating anything to run say the comments pod or anything like that
just yet.
We're just going to set up post and event bus so event buzz is going to want to send a message back
over to the post pod.
But as I just mentioned we can't reach out directly or at least not very easily.
So instead we're going to have the event bus pod reach out to the cluster I.P. service that is governing
access to the post pod.
Like so I know these lines are now kind of overlapped but that's look somewhere bad.
There we go.
That's kind of what it is actually looking like in reality so essentially what we have to do is create
another deployment that's going to create this event plus pod.
We're then going to create one cluster I.P. service for posts and one cluster IP service for event buzz.
So with all that in mind let's take a pause right here and start making this stuff in just a moment.