CKAD

Kubernetes: CLI options that simplify your work

Approaches to improve your speed and accuracy in the CKAD exam

Photo by Clément Hélardot on Unsplash

There are many ways to create Kubernetes objects.

Sometimes, it is more convenient to create a Kubernetes object imperatively. That means you use the CLI command kubectl to create the object. At other times, you will create and execute a YAML file. You will often copy a sample file from the online documentation and adapt it to your purpose before running it.

A third option is to dry run a kubectl command, create a YAML file, and execute it.

% kubectl run -f myfile.yaml

This story will compare these approaches and discuss best practices to improve accuracy and speed.

Imperative vs YAML

The imperative kubectl command on CLI (command line) is quicker and easier - when you can do so to solve a problem, particularly from an examination point of view. It is more concise, faster, and less prone to typos as we use autocompletion. When you autocomplete a namespace, only a correct and existing namespace is autocomplete, for instance. Using this method, we do not have to deal with YAML indentations or other file editing issues.

However, we cannot do everything using imperative commands. For example, we cannot provide the container name. So, a problem involving naming a container requires editing a YAML file. We do have multiple options. You can edit the pod immediately after you create it. Or use the—dry-run option to write a file, modify it, and then run it to create the Kubernetes object.

The kubectl flag —dry-run=client will validate the command and show you what would be sent to the Kubernetes cluster, but it will not change the cluster objects. Using -oyaml and then writing to a file as shown below, we have a YAML file to edit and make further changes.

% k -n myns run mypod --image=nginx:1.17 --dry-run=client -oyaml > my-containers-pod.yaml 

The bottom line is that the imperative method is faster and less error-prone when used with autocompletion; however, it does not support all our required tasks. Therefore, — dry-run=client comes to your rescue.

Online documentation vs. dry-run

So, we need to work on YAML files to solve many problems. We have two options: copy a sample from the online documentation or dry-run.

Both have pros and cons. Using the online documentation is easy and repeatable: go to the online documentation, find the appropriate YAML, copy it, and edit it to suit your problem-solving. The online sample version usually has most of the options you need.

The — dry-run=client is quicker; you do not have to switch your context(you do not leave your terminal), and using autocompletion ensures more accuracy and less editing overall. However, the — dry-run generated YAML does not have all the options. It has what you provide.

Can we have both?

By using additional flags, you can often use the dry-run option to get additional configuration values. Let's see that in action with a few examples.

We have seen that we need a baseline YAML file to answer many questions and edit it to suit the needs. However, using command-line options for adding labels, env, and port as kubectl options is straightforward. Commands will save us unnecessary edits to your YAML files. We can also create the object directly if the flags cover all requirements.

Even when we need to create a YAML file using dry-run, we can still use these options, so we do not have to make edits for these parameters.

Remember to use autocompletion for these options also.

Labels

% k -n myns run ckad-nginx-eg-1 --image=nginx:1.17 --labels=CLASS=MEDIUM

Of course, we can create the YAML without labels, edit it, and add it. However, this method does not require generating and editing a file, which takes time. Using the CLI reduces the possibility of errors due to the YAML format and indentation.

Environment variables

% k -n   myns run ckad-nginx-eg-2 --image=nginx:1.17 --env=CLASS=MEDIUM

We can create and edit a YAML using the dry-run flag for this problem. However, this method (using a flag for labels) is faster and less prone to error.

Setting Port

% k -n myns run ckad-nginx-eg-3 --image=nginx:1.17 --port=8080

We can add the ports section to a generated YAML file from a dry run. Although you may remember the syntax, you often have to refer to the online documentation. The—port option in the CLI can save you time.

Privileged Pods

k -n myns run privileged-pod - image=nginx:1.17 --privileged=true

Sometimes, command lines are easier to try. Even if you do not remember the specific command, just remembering it exists and trying it out will save time. Just type — pri(->) for autocompletion even if you do not remember the flag, it might be there.

You can complete the whole problem in CLI and do not have to create and edit a YAML file.

A combination problem that requires both

In a question that asks to use a specific container name and a label, we can also use CLI for the label. We then edit the YAML file only to change the container name. We save the editing time on the label, but we do not have another option for the container name. So, we edit the YAML file.

% k -n myns run my-labeled-pod --image=nginx:1.17 --labels=CLASS=MEDIUM --dry-run=client -oyaml > my-labeled-pod.yaml

% vi my-labeled-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    CLASS: MEDIUM
  name: my-labeled-pod
  namespace: myns
spec:
  containers:
  - image: nginx:1.17
    name: my-labeled-pod-1
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Change the container name in the file. Now run the YAML file.

k create -f my-labeled-pod.yaml

There you go. These are some of the options and ideas for improving the accuracy and speed of your Kubernetes work. Let me know what you think.

If you like my work, follow me and click here to subscribe by email.