avatarMunish Goyal

Summary

The web content discusses enhancements and simplifications for the Kubernetes command-line interface (kubectl) to streamline everyday usage and debugging in a multi-namespaced Kubernetes cluster.

Abstract

The article "Kubernetes CLI (kubectl) Made Easier" introduces methods to improve the user experience of kubectl by defining functions, aliases, and JSON templates that serve as defaults for common operations. It provides examples of frequently used kubectl commands with their options and introduces a Docker image, goyalmunish/devenv, which comes pre-configured with helper scripts and aliases to facilitate easier interaction with Kubernetes resources. The article also addresses the non-uniform output formats of kubectl commands and offers solutions to standardize them using jq for JSON processing. It highlights the limitations of kubectl get all and suggests using kubectl api-resources combined with kubectl get to list all instances of every resource type in a namespace. Additionally, the article explains the output of various kubectl commands, such as kubectl get pod and kubectl get deployment, and introduces the new kubectl debug command available in Kubernetes v1.18, which allows for the creation of ephemeral containers for interactive troubleshooting. The piece concludes with recommendations for further reading on related Kubernetes and Docker topics and promotes an AI service as a cost-effective alternative to ChatGPT Plus.

Opinions

  • The author believes that the default kubectl commands are not user-friendly and require too much explicitness for everyday tasks.
  • There is an emphasis on the practicality of using pre-defined scripts and aliases to simplify kubectl usage, as evidenced by the goyalmunish/devenv Docker image.
  • The article suggests that standardizing the output format of kubectl commands is crucial for ease of use, particularly when dealing with JSON outputs.
  • The author points out that the kubectl get all command is misleading as it does not actually list all resources, implying a need for better conventions or documentation.
  • The introduction of kubectl debug is seen as a significant enhancement for developers, providing an efficient way to debug Pods within the cluster.
  • The author endorses additional resources and articles for readers seeking to deepen their understanding of Kubernetes and Docker, indicating a commitment to community knowledge sharing.
  • A cost-effective AI service, ZAI.chat, is recommended, suggesting the author's view that it is a valuable tool for those working with Kubernetes and Docker.

Kubernetes CLI (kubectl) Made Easier

Similar to Docker CLI, the kubectl is also not very user-friendly, you have to be explicit about lots of options that actually make sense as defaults in everyday usage and debugging when we are working on multi-namespaced Kubernetes cluster(s). The aim of this post is to define some functions, aliases, and JSON templates to make the CLI easier for us.

The below screenshot shows a glimpse of what it would enable you to do:

Let’s first look at most frequent kubectl commands and their frequently used options (make sure to pay attention to comments):

Below shortcuts can make your life damn easier. You can source these scripts in your profile or rc file. But, to get everything pre-setup, you can use goyalmunish/devenv Docker image as your development environment.

It uses below helper file (goyalmunish/devenv image takes care of all setup for you):

Note that output of kubectl get pod <pod_name> -o json is a JSON object representing pod with name <pod_name>. But, the output of kubectl get pod -o json is in the format {"apiVersion": "v1", items: POD_MANIFESTS_ARRAY}. Check de>kc_plural alias which makes both the outputs uniform. So, when dealing with kubectl, unless you are using kc_plural:

  • Use jq '. | {foo: bar}' on single JSON input.
  • Use jq '.items[] | {foo: bar}' on multiple JSON inputs.

Note that kubectl get all does not list everything. Refer Rules for extending special resource alias - all to know these rules. Use kubectl api-resources for a complete list of supported resources.

The kubectl api-resources enumerates the resource types available in your cluster. This means that you can combine it with kubectl get to actually list every instance of every resource type in a namespace:

kubectl api-resources --verbs=list --namespaced -o name \
  | xargs -n 1 kubectl get --show-kind --ignore-not-found -l <label>=<value> -n <namespace>

Output of kubectl:

Output of kubectl get pod looks similar to:

NAME                                                       READY   STATUS      RESTARTS   AGE
guide-graph-app-server-7c98655497-gp4hx                    2/2     Running     0          5h22m
help-center-migrations                                     0/2     Completed   0          5h21m
api-tests-tksd9-3094769849                                 0/2     Error       0          5h10m

Here,

  • 2/2 in READY status for guide-graph-app-server-7c98655497-gp4hx means that two containers (doesn’t say anything about initContainers, but they would have already completed as then only containers can run) and both are in running status.
  • 0/2 in READY status for help-center-migrations means that it has two containers and non-of them is running. Further status is Completed, which means that both the containers have finished there (and so ended) successfully.
  • 0/2 in READY status for api-tests-tksd9-3094769849 means none of the containers is running and the STATUS status Error suggests that something went wrong.

Output of kubectl get deployment looks similar to:

NAME                                                  READY   UP-TO-DATE   AVAILABLE   AGE
zendesk-worker                                        4/4     4            4           5h56m

Here,

  • 4/4 in READY status should be read as status.readyReplicas/status.replicas, as 4 as AVAILABLE status is availableReplicas (number of available pods (ready for at least minReadySeconds) targeted by this deployment).

Output of kubectl get job looks similar to:

NAME                         COMPLETIONS   DURATION   AGE
account-service-migrations   1/1           3m25s      6h8m
kafka-bootstrap              1/1           41s        6h8m

Here,

  • 1/1 in COMPLETIONS status for account-service-migrations should be read as spec.completions/status.succeeded.

The kubectl debug:

The addition of kubectl debug command to v1.18 allows developers to easily debug their Pods inside the cluster. This command allows one to create an ephemeral container that runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.

Check sig-clie/20190805-kubectl-debug.md for details.

Here are some related interesting stories that you might find helpful:

Kubernetes
Cli
Scripting
Docker
Recommended from ReadMedium