Sunday, June 25, 2017

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.

kubectx kube1_uk_prod
kubectx kube1_us_prod
kubectx -> 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

kubens prod_uk
kubeks qa_us



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 its 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.




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.