Stop scrolling search results! We bring you the ultimate Kubernetes cheat sheet so that you have all the basic info in one useful resource. Especially convenient if Kubernetes is new to you, keep it at hand and avoid having to google every single Kubernetes command you need.

Kubernetes shortcuts

In this article, we will cover basic concepts, the most common Kubernetes commands for deploying and debugging your applications, and a few tips and tricks to help you out. We are certain some special commands in the list will save you time and effort. You will find that the CLI is a truly powerful tool when dealing with cloud-native applications deployed in Kubernetes.

Kubernetes commands

First of all, let us state that you will communicate with Kubernetes via Kubectl. This CLI uses the exposed API that the master plane offers to access your cluster. The syntax of the kubectl command is as follows:

kubectl [command] [TYPE] [NAME] [flags]

The command specifies the kind of operation you want to perform, the resource type, its name, and any additional flag you may want to use. We have a whole article about Kubectl for beginners, so we will not expand on that here. Please refer to it if you need more information about Kubectl.

Output

Before we dive into the cheat sheet, we want you to know that if you use a kubectl get command, there are several output types – apart from the standard – to choose from. Two that you may find useful are these:

-o wide

adds more information, depending on the type of objects being queried

-o yaml and -o json

output the complete current state of the object in YAML or JSON format.

Kubernetes Cheatsheet

Configuration files (manifest)

You can specify your Kubernetes configuration in a manifest file and the tool will work towards reaching the state you have declared. This file can be either a JSON or a YAML file, though it is usually recommended to use the YAML syntax. To leverage a configuration file, use this command:

kubectl apply -f config.yaml

And to compare the current state of the cluster against the state that the cluster would be in if the manifest was applied:

kubectl diff -f config.yaml

Cluster

A Kubernetes cluster consists of a set of worker machines, called nodes, that run your workloads. Every cluster has a control plane that manages it all and at least one worker node.

Nodes

Nodes represent the logical machines, either physical or virtual, that compose the cluster.

This command reports each node’s name, status (running, ready, inactive), roles (master, worker, controlplane, etcd), age, and Kubernetes version:

kubectl get nodes

To get a verbose description of a specific node, use this one:

kubectl describe nodes <node_name>

Namespaces

It is a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects (e.g. Deployments, Services, etc) and not for cluster-wide objects (e.g. StorageClass, Nodes, PersistentVolumes, etc).

Use this command to list all services in the current namespace:

kubectl get services

To retrieve a list of services in all namespaces, use the –all-namespaces (or -A for short) flag:

kubectl get pods --all-namespaces

You can create a new namespace using the following command:

kubectl create ns <new_namespace>

Napptive enables developer self-service. We encourage you to try our playground and experience accelerated cloud-native development. It’s completely free*, all you need to do is simply* sign up and get started!

Context

Not to be confused with namespaces. The concept of context only exists on the client (kubectl) side. Setting a context is used to avoid specifying a series of parameters – like cluster or namespace – that are the same for all the following commands. They are defined in the ~/.kube/config file.

Pods

A pod is the smallest deployable and scalable unit in Kubernetes. It contains one or more containers that are relatively tightly coupled. Containers inside the same pod share storage and network resources. Kubernetes pods are created and destroyed to match the desired state of your cluster.

To learn which pods are running in the current namespace, use this command:

kubectl get pods --field-selector=status.phase=Running

To list all pods sorted by restart count, use this:

kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

To delete a pod using the type and name specified in config.yaml:

kubectl delete -f ./config.yaml

And to delete a pod immediately:

kubectl delete pod <unwanted_pod> -now

Services

They are a way to expose an application running on a set of pods as a network service. Kubernetes gives pods their own IP addresses and a single DNS name for a set of pods and can load-balance across them.

To list all services in the namespace sorted by name, use:

kubectl get services --sort-by=.metadata.name

Use this command to display endpoint information (name, resource type, etc.) for your services:

kubectl cluster-info

Deployments

You describe a desired state in a deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate. They are necessary in several use cases, such as rolling back to an earlier Deployment revision, scaling up to facilitate more load, or cleaning up older replicas that you do not need anymore.

You usually declare deployments in a YAML file. After you create the deployment with it, you can check the status with:

kubectl get deployments

To see the deployment rollout status, run:

kubectl rollout status deployment/<deployment_name>

To rollback to the previous deployment:

kubectl rollout undo deployment/<deployment_name>

To scale the deployment (or any other resource) specified in “config.yaml” to 3:

kubectl scale --replicas=3 -f config.yaml

Secrets

A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key so that you don’t need to include confidential data in your application code.

Caution: By default, they are stored unencrypted in the API server’s underlying data store (etcd). Anyone with API access or with access to etcd can retrieve or modify a Secret. Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any secret in that namespace; this includes indirect access such as the ability to create a Deployment. Read the Kubernetes documentation to learn about ways to safely use secrets.

Use this command to fetch a list of all Kubernetes secrets:

kubectl get secrets

Logs

Kubernetes offers the possibility to handle and store pod, container, and system component logs on nodes. However, cluster-level logging is not native to K8s and you should use a logging solution for that purpose.

To fetch the logs from a pod:

kubectl logs <pod_name>

If your pod has multiple containers, specify which container’s logs you want to access by appending a container name to the command with a -c flag:

kubectl logs <pod_name> -c <container_name>

And to retrieve the logs from a specific service, use this:

kubectl logs -f <service_name>

In case you have not yet tried Napptive, we encourage you to sign up for free and discover how we are helping propel the development of cloud-native apps.