Kubectl Commands Cheat Sheet

When it comes to interacting with Kubernetes clusters on a daily basis, you’re going to need to turn to kubectl, the command line tool for K8s. You can use it to deploy your container workloads into production clusters, but it can also help you achieve a whole lot more. It’s the swiss army knife of container orchestration and management (according to Kubernetes). This article aims to outline how to interact with kubectl and provide you with a cheat sheet of handy shortcut commands to make your workflow quicker and smoother.

There are three types of management techniques most commonly used in kubectl; these are known as Imperative Commands, Imperative Object Configuration, and Declarative Object Configuration. Each management technique has its advantages and disadvantages, but it is highly recommended that a Kubernetes object is managed by a single method only. The use of multiple techniques on a single object at the same time will cause undefined behavior.

• Imperative Commands refers to "easier to use" commands that are easily remembered. They also require only one step to make a change to a cluster. Imperative commands are recommended for use in development projects, but they do also have downsides. These commands do not provide a great option for keeping records or integrating commands into change review processes, as the user is operating directly on live clusters. They also won’t provide a template for new objects.
• Imperative Object Configuration are kubectl configurations which specify operations or actions, i.e., replace, create, etc. This type of kubectl command will also specify optional flags and a file name. Each file must contain a complete definition of each object in the appropriate format to use imperative object configuration format. Imperative object configuration can be stored in a source control system and can also be integrated into change review processes. Additionally, these configurations will provide you with a template for new objects. This technique is simpler and more mature than declarative object configuration, but it is not great for working on directories.
• Declarative Object Configuration: Users can adapt the live configuration values of a Kubernetes object, as part of a Kubernetes cluster. These are held in local Kubernetes cluster storage, usually etcd. The operations of create, update, and delete will be detected per-object by kubectl, enabling the ability to work on directories that may require different operations for different objects. Declarative object configuration uses kubectl applyonly to repetitively create and update objects as necessary. This technique is preferred to imperative object configuration due to the fact that changes are retained, even when they are not merged with the configuration files. One disadvantage of this technique would be that it is harder to debug and understand results if they don’t come out as expected.

As you move through the different technique types, the learning curve for handling and using them increases. This article is going to concentrate on imperative commands for those looking to get started quickly and speedily.

The best examples of kubectl imperative codes we can look at are those you’ll no doubt use a lot in your daily work:

kubectl run
kubectl create
kubectl get
kubectl describe

There are a few notes to remember about using each of these commands, whether you use the singular form of an object (e.g., ‘pod’), the plural form (e.g., ‘pods’), or the shorthand code for an object (e.g., ‘po’), the system will gather information about all the matching objects available. To narrow the search down you need to follow the object with name <name>.

For example;

kubectl run pod
kubectl run pods
kubectl run po

These three commands will all generate the same outcome. To specify one pod, use the command structure:

kubectl run po <name>

Find the most useful commands grouped in terms of purpose and a full list of the objects you can adapt with kubectl in our attached Kubectl Commands Cheat Sheet here. An all in one PDF to keep at hand.

Caylent offers DevOps-as-a-Service to high growth companies looking for help with microservices, containers, cloud infrastructure, and CI/CD deployments. Our managed and consulting services are a more cost-effective option than hiring in-house and we scale as your team and company grow. Check out some of the use cases and learn how we work with clients by visiting our DevOps-as-a-Service offering.