DEV Community

Peter Jausovec
Peter Jausovec

Posted on • Updated on

5 Tips to Be More Productive With Kubernetes

Originally published at Learn Cloud Native Blog.

I like to read about and see how people set up their environments and any tools, tips, and tricks they use to be more productive when working with Kubernetes and Istio. What follows is a collection of 5 tips and tools that I use daily, and I think it makes me more productive with Kubernetes and Istio.

1. Switching between Kubernetes contexts

If you're working with a local Kubernetes instance and one or more cloud instances of Kubernetes, you will at some point need to switch between contexts. Kubernetes CLI (kubectl) has commands available that allow you to work with different contexts:

  • current-context
  • get-contexts
  • rename-context
  • delete-context
  • set-context – use-context

Assuming you know the name of the Kubernetes context you want to switch to, you can use the following command:

kubectl config use-context [CONTEXT-NAME]
Enter fullscreen mode Exit fullscreen mode

In case you are working with multiple clusters and you don't know the context names, you would need to list the contexts first, and then run the use-context command like this:

$ kubectl config get-contexts
*         docker-desktop  docker-desktop  docker-desktop
          minikube        minikube        minikube
          cloudc          crdambvg43d     user-crdambvg43d

$ kubectl config use-context minikube
Enter fullscreen mode Exit fullscreen mode

Luckily, there's an easier way to do this. I am using a tool called kubectx that allows you to list and switch to different Kubernetes context quickly. To list the context, you can run kubectx like this:

$ kubectx
Enter fullscreen mode Exit fullscreen mode

Switching to another context is as simple as this:

$ kubectx [CONTEXT-NAME]
Enter fullscreen mode Exit fullscreen mode

2. Switching between Kubernetes namespaces

Another quite common thing you do when working with Kubernetes is to work with resources from multiple namespaces. For example, you might want to list pods in one namespace, check on services in another etc. My workflow here is to use the --namespace flag that is supported on the Kubernetes CLI. For example, to get all pods in the namespace called test, you can run kubectl get pods -n test. By default, if you don't provide the namespace flag, the default Kubernetes namespace is used  -  which is appropriately named default.
This default value can be changed in the kubeconfig file  -  you could, for example, set the default namespace to be test or kube-system or any other namespace. That way you don't need to use --namespace flag when querying for resources. However, the command to change this is awkward:

$ kubectl config set my-namespace
Enter fullscreen mode Exit fullscreen mode

The command above modifies namespace field in the my-context context and changes it to my-namespace. This means if you switch to my-context and run kubectl get pods for example, you would only see pods from the my-namespace namespace. 

Together with the kubectx tool, you also get a tool called kubens  -  it helps you list and switch to different namespaces.


$ kubens
Enter fullscreen mode Exit fullscreen mode

Setting a default namespace for selected context is also quick and easy:

$ kubens default
Context "docker-desktop" modified.
Active namespace is "default".
Enter fullscreen mode Exit fullscreen mode

3. Alias the Kubernetes CLI 

This is a straightforward tip. If you are working with Kubernetes you will be typing kubectl a lot, and you will get tired of typing the whole name at some point. You might be thinking it's only seven characters, but it adds up.
The tip here is to alias kubectl to something shorter, k for example:


$ alias k=kubectl
$ k get po
mypod   1/1     Running   18         43h
Enter fullscreen mode Exit fullscreen mode

Ideally, you would put the alias k=kubectl in your bash_profile, so it gets set each time you open your terminal. 

4. Get a terminal inside the Kubernetes cluster

When accessing services and pods running inside the cluster, you either need to expose them, so they are accessible from the public internet or you run a kube proxy or forward ports between your local machine and services running inside the cluster.

However, sometimes you want to run plain curl command without exposing any services or forwarding ports. To do so, I use a function that gets loaded as part of my bash profile that runs a pod with radial/busyboxplus:curl image inside the cluster and gives me access to the terminal. That way, I can run curl against services and IPs inside the cluster. I call the function kbash and use it like this:

$ kbash
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$
Enter fullscreen mode Exit fullscreen mode

From the prompt, I can run curl against internal Kubernetes DNS names or IP addresses. To exit, just type exit and if you want to attach back to the pod, run kbash and it will attach to the existing pod. I have this function defined as part of my dotfiles as well.

5. Quickly open Grafana/Jaeger/Kiali (or anything else)

If you plan on working with Istio service mesh you will probably use Grafana/Jaeger/Kiali at some point. Accessing these services requires you to get the pod name first and then set up a port forward to that pod and finally open the browser to the forwarded address. The commands are quite long to type out each time:

$ kubectl get pods --namespace istio-system -l "app=grafana" -o jsonpath="{.items[0]}"
$ kubectl --namespace istio-system port-forward grafana-6fb9f8c5c7-hrcqp 3000:3000
$ open http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

The easier and faster way is to create functions or aliases for each of the services. For example, I have the following set up for Grafana/Jaeger/Kiali in one of the files that get loaded as part of my bash profile:

export GRAFANA_POD=$(kubectl get pods --namespace istio-system -l "app=grafana" -o jsonpath="{.items[0]}")
export JAEGER_POD=$(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0]}')
export KIALI_POD=$(kubectl -n istio-system get pod -l app=kiali -o jsonpath='{.items[0]}')
alias grafana="kubectl --namespace istio-system port-forward $GRAFANA_POD 3000:3000 & open http://localhost:3000"
alias jaeger="kubectl --namespace istio-system port-forward $JAEGER_POD 16686:16686 & open http://localhost:16686"
alias kiali="kubectl --namespace istio-system port-forward $KIALI_POD 20001:20001 & open http://localhost:20001"
Enter fullscreen mode Exit fullscreen mode

Now if I want to open Jaeger, I can run jaeger and it will get the pod name, create the port-forward and open the browser.

If you have other services running inside the cluster you are frequently opening, you can set up the aliases the same way.

Do you have any favorite tips/tools that make you more productive?

Top comments (9)

carehart_40 profile image
Charlie Arehart

Thanks for the tips, Peter. For fellow readers, note first that his original post (offered at the top here as a link to is now at:

And as for his first example showing:
kubectl get-contexts
while that will work with minikube, it may not work with other kub implementations, where instead one should use:
kubectl config get-contexts
(for that as well as the other args listed in his first point here). The Kub docs confirming this are here:

peterj profile image
Peter Jausovec

Thanks Charlie! I've updated the post.

carehart_40 profile image
Charlie Arehart

And thank you for the quick attention and response. :-)

weibeld profile image
Daniel Weibel

For port-forwarding to a Pod, you don't necessarily need to get the Pod name. You can specify a Service or Deployment and kubectl will select one of the backing Pods automatically.

For example:

kubectl port-forward svc/grafana 3000:3000
peterj profile image
Peter Jausovec

Good point! I think it’s time to update my scripts - I had that since before kubectl supported forwarding ports to services.

dwdraju profile image
Raju Dawadi

kubefwd is another gig !

mmr profile image
Marcio Ribeiro

Great tips.
You should check k9s:

alex_barashkov profile image
Alex Barashkov

Thanks for the tips. For port forwarding actually better to use It makes you more productive than generic CLI

peterj profile image
Peter Jausovec

Thanks Alex! I’ll check out that tool.