The primary objective of my team is to empower other engineering teams in our company to take ownership of their services. Like many companies we chose Kubernetes as the platform to help us achieve our goals.

For our architecture it was clear that the benefits of Kubernetes far outweigh the complexity overhead—an easy justification for a team of devops pros.

I mean seriously, it does so many things. But there are some pain points. With the understanding that there are numerous approaches to using Kubernetes and that your workflow is not the same as my workflow I would like to introduce a small CLI tool which has helped alleviate some of the pain points encountered when using Kubernetes everyday.

ckube is a small utility to simplify and streamline working with Kubernetes from the cli. kubectl is extremely powerful but I find that I generally use a very small subset of its features, namely logs and exec. Let's use my-app as an example.

my-app is a very cool web application (not really, it is actually just nginx).

Getting logs for my-app is easy enough with kubectl

$ kubectl logs my-app-775df4f94b-l2kqc

The problem is that I don't think of my-app as a pod but rather a service. Even more concerning, my-app is super popular so I have scaled up my deployment to 5 replicas. In reality when I want to see the logs for my-app I want to see the logs for all 5 of these pods.

ckube was created to run common kubectl commands concurrently against multiple pods. Using ckube should feel familiar if you have used kubectl. Here is ckube in action.
ckube logs also accepts the -f flag to follow the logs in all of the containers.

Similar functionality exists for exec. If I need an interactive prompt to poke around in a single pod ckube will choose one for me.

Non interactive commands can easily be run against all my-app pods with -a. ckube also supports more complex commands just like kubectl.

I work in a shared Git repository with an engineer who insists on committing his .idea/ folder so the team can share run and build configurations. Initially I assumed it was a mistake so I added the folder to the .gitignore just like I have done in virtually every .gitignore that I have ever checked in to a repo. Problem solved.

Before long I noticed that Git was tracking these files again as he had removed the rule from the .gitignore. The ensuing conversation revealed his well intentioned motivations and convinced me that it was fine.

Running git checkout -- .idea before adding files had become second nature but after several months I had finally had enough. Fortunately Git has a solution for teammates with differing .gitignore philosophies. Every repo contains a file .git/info/exclude. It is essentially a .gitignore that isn't committed to the repo so the rules you set will only apply to you.

# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~
.idea

Since Git was already tracking some of these files I also had to run this from the .idea/ directory: