So we're going to take a look at deploying our NGINX web server as
a container through to our Kubernetes system.
A deployment itself exists as one or more Pods running on
one or more nodes within our cluster.
A Pod itself is representative, if you like, of our ordinary containers.
A deployment becomes a microservice when a cluster IP
is assigned via exposing our Pod.
So let's take a look at what we need to do to get this up and running.
We can go through and run our kubectl create deployment.
We're going to give the name web.
We're using the NGINX image, and that's going to create a single Pod.
Once we've got that up and running, we can go through and scale our deployment.
Here we're saying let's have two replicas.
Now often this will then be placed on multiple nodes,
one replica on node one, another replica on node two,
giving me a little bit of high availability and fault tolerance.
But obviously,
they will be both running on the same system as we're a single‑node cluster.
The final part of this is to go through and expose the deployment,
and we can specify that we want to use a NodePort using port 80,
and we're assigning the name to our service of nginx‑web.
Once we've exposed it,
we're able to go through and see the IP address that's been assigned
to our service through the kubectl and get service.
Now, again,
this seems to me about time that we had a little bit of hands‑on practice,
so we can go out and take a look at the demonstration here
where we're deploying our NGINX microservice.
So here we are on our command line,
and this is where our learning really is going to start,
where we start looking at how we can create a clustered
resource inside of our Kubernetes cluster.
We can go through and use the microk8s command and then the subcommand kubectl.
And with this, if we go through and use the get,
we can return information, so get deployments.
Let's see if we've got any deployments at the moment.
We won't,
but we can see just for clarification that we don't have any deployments,
and we're going to create our deployment.
When we go through and create a deployment,
instead of get deployment, you've guessed it,
it's going to be create deployment, so it really is as simple as this.
Our deployment though then can be later scaled.
So if I go through, create a deployment,
we can call the deployment web,
and we can go through and say that we want the deployment to
be based upon the image and then nginx.
So just as before,
it's going to look at finding the NGINX image in our
registries and then downloading it.
So it takes a little while to get it up and running in the first instance,
but if I go back now and take a look at my get deployment again,
we should see that one out of one replicas is up and running,
so we're good to go with this.
Now we just up arrow key,
and if we take a look at what we mean by one out of one replicas,
we can use get pods, and we can see that we've got one Pod.
And that's what we mean by one out of one.
Our deployment has one Pod.
The name of the Pod is based on the deployment plus a generated identifier.
We can also go through and take a look at our get services.
Because we haven't assigned a Pod or exposed a Pod on this,
we no longer, or we don't at the moment,
have a service representing this or a cluster IP address.
But we can go through and start scaling out our deployment.
So we can go back and change the create subcommand to scale,
and we can do this very dynamically whilst the system is running.
We might determine that we need more resources on our web server,
so we can then go through and specify that we need two replicas.
Now this should be up and running very quickly because
the image is already downloaded,
so we can see now straightaway we have two out of two Pods up and running.
If I go back now and look at my Pods,
we can see that both Pods now are up and running.
Now this could be really useful.
Especially if we're running across multiple nodes,
one Pod could fail or one node could fail,
but we're still able to access our resources.
However, of course, to be able to access the resources,
we have to go ahead and expose those Pods.
So we can start looking at how we do this,
and this is going to create what's commonly known then as our
microservices or a service that we will see as in Kubernetes.
But if I go through now and expose my deployment,
we need to change this a little bit, and instead of using our replicas,
we're going to use the type, and we're going to use NodePort,
but we could also have LoadBalancer.
So if we just wanted to load balance between this, we could use a LoadBalancer.
NodePort is then just saying, okay, well,
we're going to be listening on port 80, and as we go through,
we can specify the name of our service.
As we look at this, all of our containers will be listening on port 80,
but they're also going to have a high numbered port assigned to
them so we can monitor the service through that.
As I go through and take a look now at the get service,
we're able to see that we've got port 80 exposed and the cluster IP address.
But that port 80 is exposed to the cluster IP address,
but will be communicating through to our services on 31573 to each of our Pods.
So there's a little bit of internal mechanism that goes on behind this.
But we connect to our cluster IP on the standard port 80,
so I can go through just using curl 10.152.183.50.
As we go through then and connect in,
we can see that we've got our standard NGINX welcome page,
but it's now available through high availability
because any of these Pods could fail,
and we'd still be able to access it as we access it
through the cluster IP address.
But just in the same ways that we can create our services,
once we're finished with our services,
we can use the kubectl and delete service nginx‑web,
and we can delete the deployment, which is going to delete all of the replicas.
So delete deployment and then web.
So that's all now tidied up.
And if we go through and take a look at our get,
let's say get all so we can see everything that we've got,
we're left now just with our Kubernetes cluster service.
So there you go.
We're up and running with Kubernetes. But let's summarize a little of what we've looked at.