A Quick and Dirty way to Run Pods
Learn to create Pods using through the imperative method.
We'll cover the following
Creating a pod with Mongo#
Just as we can execute docker run
to create containers, kubectl
allows us to create Pods with a single command.
For example, if we’d like to create a Pod with a Mongo database, the command is as follows.
You’ll notice that the output says that pod/db
was created
. We created our first Pod. We can confirm that by listing all the Pods in the cluster.
The output should be something like this.
In the output, we can see:
- The name of the Pod
- Its readiness
- The status
- The number of times it restarted
- For how long it has existed (its age)
If you were fast enough, or your network is slow, none of the pods might be ready. We expect to have one Pod, but there’s zero running at the moment.
Since the mongo
image is relatively big, it might take a while until it is pulled from Docker Hub. After a while, we can retrieve the Pods one more time to confirm that the Pod with the Mongo database is running. The output this time is as follows.
We can see that, this time, the Pod is ready and we can start using the Mongo database.
We can confirm that a container based on the mongo
image is indeed running inside the cluster by listing all the containers based on the mongo
image.
The output of the above command is as follows (IDs are removed for brevity):
As you can see, the container defined in the Pod is running.
That was not the best way to run Pods so we’ll delete it.
The output is as follows.
For ease of use, a list of all the commands used in this lesson is also given below:
Run the above commands in the Terminal below. Make sure to connect the Terminal by pressing Click to Connect before executing any commands.
Why this is a dirty way?#
The above approach used to run Pods is not the best one. We used the imperative way to tell Kubernetes what to do. Even though there are cases when that might be useful, most of the time we want to leverage the declarative approach.
We want to have a way to define what we need in a file and pass that information to Kubernetes. That way, we can have a documented and repeatable process, that can (and should) be version controlled as well.
Moreover, the kubectl run was reasonably simple. In real life, we need to declare much more than the name of the deployment and the image. Commands like kubectl
can quickly become too long and, in many cases, very complicated. Instead, we’ll write specifications in YAML format.
Troubleshooting tips for minikube
#
If you are following along locally with the help of minikube, you will need to execute the following command to get the containers running inside docker:
The output of the latter command is as follows (IDs are removed for brevity)