The original Part 1 can be found here.
Let’s continue with other useful commands that may come in handy during your Kubernetes endeavors.
(As with the previous part, I’ll show and apply the commands in the default namespace).
How to create a resource, and get its YAML file without applying it?
This can be done using the –dry-run flag so it doesn’t apply the resource to the cluster, and combined with -o yaml to get its YAML output.
$ kubectl create deployment nginx --image=nginx:latest --dry-run=client -o yaml > nginx-deployment.yaml
After which we redirect the output to a file. You can edit from there and apply it routinely with:
$ kubectl apply -f nginx-deployment.yaml
This can also be done with pretty much every resource supported by the create command, kubectl create –help for more info. This also includes pod creation with kubectl run.
How to record changes done on deployments?
For example, you want to change the image tag on some deployment, but also want to have a record of it. And of course, as a fail-safe option to roll back if something goes wrong.
This is already covered by Kubernetes by default, every major change to the deployment has a history of 10 revisions back.
Let’s use the previous deployment file from above, and apply it.
Now change it’s image using the set image command.
$ kubectl set image deploy nginx nginx=nginx:1.19.2
deployment.apps/nginx image updated
The image has been successfully updated, but if you now run:
$ kubectl rollout history deployment nginx
You’ll find that the change cause section is empty:
REVISION CHANGE-CAUSE
1
2
The first option is to record the command and have it appended as a change cause automatically. This is easier and you just need to append –record to your set image command.
Try it out with a different image:
$ kubectl set image deploy nginx nginx=nginx:1.19 --record
REVISION CHANGE-CAUSE
1
2
3 kubectl set image deploy nginx nginx=nginx:1.19 --record=true
If you want to specifically check the revision config, you can do so with:
$ kubectl rollout history deployment nginx --revision=3
And there they are, both the record and the image:
Annotations: kubernetes.io/change-cause: kubectl set image deploy nginx nginx=nginx:1.19 --record=true
Containers:
nginx:
Image: nginx:1.19
The second option is to manually edit the change cause, that way you can add any info you want.
Set the image to 1.18 tag using the set image command but ommit the record flag, and instead after applying edit the annotation with:
$ kubectl annotate deployment nginx kubernetes.io/change-cause="Fixed image to run with newest config"
Running the history command again should give you the newest change with your annotation.
REVISION CHANGE-CAUSE 1 2 3 kubectl set image deploy nginx nginx=nginx:1.19 --record=true 4 Fixed image to run with newest config
Verify it’s revision info:
Annotations: kubernetes.io/change-cause: Fixed image to run with newest config Containers: nginx: Image: nginx:1.18
To complete this section, rolling back can be done with:
- For one revision back.
$ kubectl rollout undo deployment nginx
2. To specific revision back, for example to the second revision of the deployment.
$ kubectl rollout undo deployment nginx --to-revision=2
How to copy a file from or to a pod?
Same as in bash, the kubectl offers the cp command to copy any content from or to a running pod.
Create a sample pod.txt file, and write anything to it.
Now to copy it to a running pod, in my case would be:
$ kubectl cp pod.txt nginx-547579b5cd-wvkzd:/tmp
Make note of “:” and the location which is /tmp in the above example. This is the same convention used with SCP or other file transfer utilities.
To check you can do it with the exec command:
$ kubectl exec -it nginx-547579b5cd-wvkzd -- ls /tmp pod.txt
Or to list it’s contents replace the command with:
$ kubectl exec -it nginx-547579b5cd-wvkzd -- cat /tmp/pod.txt this is a pod config
Try it in reverse, copy back the file to your desktop:
$ kubectl cp nginx-547579b5cd-wvkzd:/tmp/pod.txt nginx-pod-config.txt
$ cat nginx-pod-config.txt this is a pod config
How to get custom data formatted when checking resources?
This is useful and can be done using the -o custom-column command. You can check for more output info here https://kubernetes.io/docs/reference/kubectl/overview/#output-options
You can use the following command to immediately gather the name of the pod, it’s status, image, and the node it’s running.
Instead of issuing couple of commands this can be done with only one, and aliased in ~/.bashrc for easier usage.
$ kubectl get pods -o custom-columns=NAME:.metadata.name,STATUS:status.phase,IMAGE:.spec.containers[*].image,NODE:spec.nodeName
It’s a bit intimidating, but it’s quite simple actually. First you name the columns – NAME, STATUS, IMAGE, NODE, and give their data location from where to pull the info.
Here is a image snippet of what the output looks like.
Remember you can always customize it and tune it to your needs, this is just a base example of it’s usage.
That’s all for now folks, will add more info in future parts.