Tip:
Highlight text to annotate it
X
Here in the menu for creating Kubernetes Clusters
which we can access form Google Console, through Compute and Kubernetes Engine and Kubernetes Clusters
We can add a new Cluster
a unique name, choose the zone/region where the cluster will run
a type of virtual machine. Here choose up to 96 CPU and 360GB for memory for one machine
we can add 30 or 300 of these machines, whichever number we require
It will be a beautiful cluster with 108TB of RAM
plus other options such as auto scaling
minimal and maximum size of the cluster
which are the parameters for auto scaling
but I prefer to create these things from the terminal
So let's create a cluster with three nodes with a small virtual machine
It will take a while to create a whole cluster, so let's speed it up a bit
Ok, it's done.
Workload is a dashboard on which we can see what is running on the cluster
At the moment there is nothing running here
so let's fix it.
When we look here, into the triggers, we can set a trigger for GitHub repo
So here I have prepared a repo that will deploy automatically after pushing to the branch.
Here you can already see a repo and a simple php index in it.
This is an application in php.
Further on we can demonstrate that push to the master branch
the build will launch
And now we can already see our application
Our two docker images for enginex and php
Apart from building docker images, we have also launched
Kubernetes deployment manifest, which explains how should the application run
Here we can already see something appearing in the workload
You can see the enginex application
you can see two running pods, two replicas of the application
they have deployed here from the repo
Here you can see URL for where the application is running
and down here, if you notice the IP address it shows the IP address of the container,
private IP address of the container where the application is running
so if we have three replicas here
it will find a different IP address each time
one out of three
you can click on the particular one and see how much CPU, how much memory they require
how much disc space they are taking
if you delete them, or someone else deletes them
or the application crushes
the deployment assures that the three replicas will run
so even if we kill one, another one will launch automatically
But let me show you
here you can see the revision of the deployment running at the moment
which is an assembly of different images, versions of the application that is running at the moment
so I can deploy a new application. I will just change the code with one click
Here you can see the number of the commit
and the app looks like this, you've seen this already
I am going to re-write it. I will change "Hello World" to "Hello Cloud Do You Do?"
and push
Now it will start to build automatically
you can see the number of the commit here
Meanwhile it is deploying, but the old version of the app is still running
so we don't have any downtime.
The application is still responding.
You can see how through the load balancer, the two versions that run on the same cluster simultaneously are mixing up
Because we have already deployed a new version the old one has been killed.
only the new one is runnig at the moment.
Here you can see that the revision, 21, it is mixed
but if I decide that I do not like this application I don't like this version
and I need to roll back quickly
I can whether recreate the old build from before
but if I don't want to wait
or my application is more complex and with the deployment it will last for an hour or more
then I can use a rolling update here
and I will deploy the old revision
I will deploy the old image that was in the previous version
Meanwhile new pods are being deployed, and the old ones are being killed
If it has been deployed correctly, you can see here how the two versions are mixing
And now, we will only have the new version here
or the old one which has been rolled back
If I refresh it here, I will see the revision number 22 at the bottom
Again, a new revision.
I have two replicas that are running at the moment
I will take each replica and the whole deployment at the same time
and I can scale it to higher or lower number of replicas
You can scale it up, or scale it down
Now you can see that we have three replicas running here
The last one has been launched twelve seconds ago
I can also set up an auto-scaling here.
For example 1 - 5 replicas and a CPU according to metrics
If the CPU of any particular replica is loaded more than 50%
I can launch another replica
so that I can handle different load.
It is still working, we still have three replicas here, with three IP addresses
Now, let's try scaling to one replica
I am going to try the application first.
We still have one replica running, so it keeps returning the same IP address
What I am going to do now is, I am going to scale it down to zero
so none of these application will be available
When I open the application again it will show me an ERROR
You should get an email and then a notification on Slack
There it is. After a moment I got a notification on Slack
with a link that will lead me to the problem
and the same in my email
An exact report of what happened and when
and other information with a link to the problem
And now, if by any chance someone deletes the whole cluster,
or I decide to deploy it somewhere else, in a different project
in another zone, another region whatsoever...
a sort of disaster recovery.
We can take the whole configuration file from when we created the cluster
we will create it not on west 1D but on west 1B, in a different zone
in Belgium
Now we can see the cluster being created in a different zone.
The exact same cluster.
And now I have a new cluster created. In a different zone, different continent for example