Kubernetes has grown to be a de facto development platform for building cloud-native applications. As developers, we want to be productive from the word go, or, shall we say, from the word code. But to be productive, we must be armed with the right set of tools. In this article, I will take a look at three important tools that should become part of your Kubernetes tool chest, or armory.
Minikube
When you think of Kubernetes, several questions may come to mind, including:
- How do I set up each and every Kubernetes component?
- How do I configure Kubernetes correctly?
- Even if I set up and configure Kubernetes correctly, do I have to do this every time?
The answer is Minikube, which can help you easily set up a proper Kubernetes node suitable for your everyday development needs.
To get going, the minikube start command just brings up a single-node Kubernetes environment with 2GB RAM, 2 CPUS, and a disk of 20GB.
Running the command:
minikube ip
will let you know the IP of the Kubernetes node that is part of the virtual machine started by Kubernetes.
I was able to deploy small lightweight applications with the default config, but then one day I needed to build a bigger Kubernetes node with a memory of 8GB RAM, 4 CPUS, and a disk of size 50GB. To get this kind of configuration, you can use:
minikube start --memory=8192 --cpus=4 --disk-size=50g
As you become a more experienced Kubernetes user, you will have a Kubernetes environment for one set of applications, another for a different set of applications, and so on. This is super easy with what is called a “profile” in Minikube. Let's create a profile called sword, which will hold all our "cutting-edge" technology applications. To create your sword profile, you can just run the same minikube start but with a -p like:
minikube start -p sword --memory=8192 --cpus=4 --disk-size=50g
Minikube by default stores all files, config, and other related settings of the sword profile under $MINIKUBE_HOME/profiles/sword. $MINIKUBE_HOME is an environment variable that Minikube understands to be the place to store the Minikube virtual machine artifacts, such as configs, disks, etc.,
A good first step! Now, I will teach you a tip. Here's how to invoke a Kubernetes service, for example, a "customer" using Minikube:
minikube service customer
When learning how to use these tools; however, we need to consider other tools as well.
Kubens: Switch Kubernetes namespaces
Kubernetes by default has the many namespaces, such as default, kube-public, and kube-system. Any resource you create without a namespace is created in namespace default.
For example, executing the following command without --namespace or -n option, would create the "dagger" configmap in default namespace.
kubectl create configmap dagger --from-literal size=small
In considering application development priorities, we quite often miss this subtle behavior. That's when we start to spend sleepless nights and weekends wondering, why is this not working for me? 
By adding kubens to our armory, we can set the namespace in which we will be creating the resources. Let's say we have a namespace called vikings; we can set that to be namespace for all our resources just by running the kubens vikings command. When we then try to create any resource without the --namespace or -n option, Kubernetes will by default create it in the vikings namespace.
If you have to get back to the previous namespace, it's as simple as running the command kubens - (similar to Bash cd -).
Kail: Watching logs
Our tool chest is filling up nicely, but we still lack vital tools. As part of our everyday job, we need to analyze the logs of the pods.
Kubectl does have log commands, but that is primitive. We need a tool that can help us to filter logs based on some criteria, for example, pods that belong to Kubernetes deployment.
By adding Kail to our toolkit, we will get even more power via filters to query and analyze the logs:
- Pods by deployment — For example, get logs from pods that are part of the deployment dagger in namespace sword:
kail -n sword -d dagger
- Pods by service — Get logs of pods that are part of the service battle:
kail -n sword --svc battle
- Pods by label — Get logs of all pods with "size=large":
kail -n sword --label size=large
The filters could also be combined to filter the logs further. For example, suppose you want to view all the logs of service “battle” that do not have “size=large”:
kail -n sword --svc battle --ignore size=large
Kail has lot of other filters just run kail --help for more details. When I first started to use Kail, sometimes I didn't see the logs, but then I realized that my host time and Minikube time are different, so I had to add --since flag to my commands. For example, to query the pod logs for the last 2 hours (Kubernetes node time), use:
kail -n sword --svc battle --since=2h
That’s it for this article. Armed with these tools, we're ready to succeed in our code battle. In my next article, we will add more tools to our armory and expand our skills even more. Until then, happy coding!
Tutorials
Here are tutorials for our Kubernetes warriors:
Last updated: September 3, 2019