my day to day Kubernetes command line tools & apps #kubernetes

The other day, I was chatting with my friend Stathis about command line tools that I use every day, extra to kubectl, operating on different kube clusters in production.

Command line tools

1. ** kubetail** Allows you to tail logs from one or more pods simultaneously. It is really handy since you only have to specify the pod name, and then it will automatically tail all the different instances you may have already deployed. kubetail backend-api -n aNamespace

2. ** kubectx**

If you do have access to more than one Kubernetes clusters (like me) then switching from one cluster to the other, especially when you do it very often, can be a bit boring or error prone. Kubectx, will actually parse your _kube_config and it will help you make the switch faster.

1kubectx
2kubectx kube1_uk_prod
3kubectx kube1_us_prod
4kubectx -> lists all the available contexts

3. kubens

It is on the same bundle as kubectx and helps you switch easily through different namespaces that you may have within a cluster

1kubens
2kubens prod_uk
3kubeks qa_us

Apps

1. ** kube-state-metrics**

Kubernetes already uses heapster to gather stats and info about the state of the cluster, which is later fed to some of kubernetes components like autoscalers, to determine if the they need to initiate a pod up or down scale. Kube-state-metrics is an addition to what _heapster provides, and it actually exposes additional ( prometheus) metrics that can prove very handy if you are operating kube clusters in production. What I really like, is that once you spin the pod (one would suffice) then you can extract the provided metrics, through it's Prometheus Endpoint. So if you are already using prometheus to scrape metrics from you deployments, kube-state-metrics is ready for business. You can check the various metrics provided by the app here.

Deployment

1. Helm

This needs a separate blog post most probably, but I have slowly started moving away from vanilla kubernetes deployment descriptors and 80% of my deployments are now, packaged and configured as Helm charts. The main reason adopting helm was our need, to parameterize the deplooyments, and relying on bash based hacks (sed, or envsubst) was ok to start, but as soon as the number of deployments grew along with their complexity, the parameterization of all of them was really α pain. I will come back with a separate post for sure about Helm and why I think is vey good idea, to start adopting it as soon as possible.