In the last video we laid out the solution we're going to use to address this big USL problem.
So if our code is running inside the browser what's going to let everything behave as it's currently
working.
We really only have to be concerned about the case in which we're trying to run some code inside this
Next j ust application when we need to reach out to some other service and fetch some data.
So we eventually decided to go with option number one whenever we need to fetch some data while we are
doing some server side rendering we need to somehow reach out to ingress and 10x and allow ingress engine
X to route off this request.
The only issue was how do we actually make a request to ingress engine x.
We can access ingress engine X on our local machine and the words inside of our browser.
By navigating to a local host port 80 that's how we get to ingress engine x.
If I were to open up my browser right now we're trying to make this request from a totally different
environment.
We're trying to make the request from inside of this next J.S. pod or the client pod if we tried to
access local host inside this pod then we're going to access local hosts inside the pod or snoozing
inside the container itself.
That's what's happening right now and that's what's resulting in the nasty air that we're currently
getting.
So we want to instead figure out how we can tell the pod to reach out directly to ingress engine X..
So in short what do we type right there.
What is our domain.
What do we have to type in to get this entire system routing requests over to ingress engine x.
So that's the big question we're going to try to solve in this video.
So I want to give you first a very quick reminder.
Whenever we have two pods that need to communicate with each other in a synchronized fashion we can
do so by using those cluster IP services.
So for example if we wanted our client to reach out directly to that pod we would write out the name
of the cluster I.P. service so it would be something like a GDP off dash SRB now.
Unfortunately this rule right here only works when these services are referring or assuming when we're
trying to access a service that is inside in the same namespace.
So what is a namespace.
Well a namespace is something it exists in the world of Cuban entities all the different objects we
create are created under a specific namespace.
You can think of a namespace as being like a sandbox of sorts.
We use name spaces for organizing different objects.
Right now we've been working under a namespace called default.
So if we go back over to our terminal and do a cube Seitel get namespace we'll print out all the different
name spaces that currently exist inside of our communities cluster.
You'll see.
Default is listed right there.
And again that's where all the objects we have been creating get created.
There's another namespace called Ingress engine X and that's where all of our ingress engine next related
stuff works.
Now unfortunately we can not use this style of communication to reach out to a service that exists inside
of another namespace.
So in short we really can't use this very short form right here to reach out to ingress engine X directly.
We can not just put in something like ingress engine X dash SRB.
Unfortunately the domain we have to type out is a little bit more complicated.
Let's take a look how we would get our client to communicate directly over to the ingress engine x service.
So if we want to do some cross namespace communication to a service created in a different namespace
we're still going to type out a domain but the domain is gonna be a little bit more complicated.
The domain that we're gonna type out will be the name of service then a dot then the namespace then
SBC dot cluster dot local.
Let me give you a more practical example.
So we can really understand what's going on there.
The first we need to understand is what is the name of the namespace.
We are trying to reach into.
So in this case the name is ingress engine X then the second question is what is the name of the service
inside there that we're trying to access.
Well to figure out what that is we need to list out all the services that exist inside that namespace.
Right now when we type out cutesy tail get services.
This is only listing services from the default namespace.
There are technically other services that exist in these other name spaces.
So if you want to figure out what services exist inside of ingress and connects we have to customize
the get services command and tell it to fetch services from inside of ingress and connect namespace.
So you do that by writing cubes detail get services dash n and in the name of the namespace which in
this case is ingress and connects
I'll run that and there's the name of our service.
That's the name of the service inside of this namespace that we're trying to reach out to.
It's simply ingress engine.
So in total to reach to the southern namespace and access the ingress engine x service inside there
we would write out and let me do myself a little bit of space here as you can see as very easily.
We would write out a TTP Poland slash slash the name of the service which is ingress dash engine X then
a dot to the name of the namespace ingress engine X and then SBC bluster not local and that's it.
That's how we reach from our client across the namespace over to this other one and access the service
inside their so whenever we want to follow request option number one right here and somehow make a request
over to the current user service without having to worry about reaching over to all service directly.
We would make our request to zoom in on this in just a moment.
Ingress engine X dot ingress engine X SBC bluster local and I will zoom in let's I would do it.
And we just need to make sure that we pass along the cookie as well.
All right.
So that's how we're going to communicate across name spaces.
Now very quickly having to memorize this kind of syntax right here kind of gets nasty really quickly.
So there actually is a solution to this that will allow us to make a very similar looking request to
this one right here.
So a very simple kind of just ingress dash engine X dash SRB if we wanted to be able to make a request
to something like this we can create something that's called an external name service so an external
named service essentially just remapped the domain of a request.
We can set up a external named service that will map requests from say ingress dash engine X dash SRB
to this more complicated domain like the one you see right there.
So if we did something like this we would not have to memorize this crazy syntax we would just follow
that kind of short form that we are somewhat already used to.
This is not at all necessary.
It's just a nice to have thing it's just something that makes it a little bit easier to remember.
Hey here's the url or here's a very short URL that I can make my request to.
We are not going to create the external named service just because as you come back and references code
in the future this really is a pretty big layer of indirection and I just do not want you chapter remember
that.
Oh yeah we created that external named service that's going to map this thing off.
That's just an extra thing to remember in the future.
So we are not going to go down this route but again it is an option.
It is something you could do if you did not want to memorize that longer.
Euro Oh all right.
As I've said many times yeah this stuff is pretty crazy.
That's why micro services are hard and that's why you get paid the big bucks.
Once you start to learn this stuff.
Now that we've got a good idea or these some idea of what's going on here.
I think that's pretty much it for the lecturer in the theory.
So we're gonna start to implement all the stuff in the next video.