Kubernetes Cheat Sheet

January 30, 2023
Kubernetes Cheat Sheet

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:

<code>kubectl [command] [TYPE] [NAME] [flags]</code>Code language: HTML, XML (xml)

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.


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:

<code>-o wide</code>Code language: HTML, XML (xml)

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

<code>-o yaml and -o json</code>Code language: HTML, XML (xml)

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:

<code>kubectl apply -f config.yaml</code>Code language: HTML, XML (xml)

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

<code>kubectl diff -f config.yaml</code>Code language: HTML, XML (xml)


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 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:

<code>kubectl get nodes</code>Code language: HTML, XML (xml)

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

<code>kubectl describe nodes <node_name></code>Code language: HTML, XML (xml)


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:

<code>kubectl get services</code>Code language: HTML, XML (xml)

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

<code>kubectl get pods --all-namespaces</code>Code language: HTML, XML (xml)

You can create a new namespace using the following command:

<code>kubectl create ns <new_namespace></code>Code language: HTML, XML (xml)
Join Napptive

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!


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.


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:

<code>kubectl get pods --field-selector=status.phase=Running</code>Code language: HTML, XML (xml)

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

<code>kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'</code>Code language: HTML, XML (xml)

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

<code>kubectl delete -f ./config.yaml</code>Code language: HTML, XML (xml)

And to delete a pod immediately:

<code>kubectl delete pod <unwanted_pod> -now</code>Code language: HTML, XML (xml)


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:

<code>kubectl get services --sort-by=.metadata.name</code>Code language: HTML, XML (xml)

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

<code>kubectl cluster-info<span style="background-color: initial; font-family: inherit; font-size: inherit;"> </span></code>Code language: HTML, XML (xml)


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:

<code>kubectl get deployments</code>Code language: HTML, XML (xml)

To see the deployment rollout status, run:

<code>kubectl rollout status deployment/<deployment_name></code>Code language: HTML, XML (xml)

To rollback to the previous deployment:

<code>kubectl rollout undo deployment/<deployment_name></code>Code language: HTML, XML (xml)

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

<code>kubectl scale --replicas=3 -f config.yaml</code>Code language: HTML, XML (xml)


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:

<code>kubectl get secrets</code>Code language: HTML, XML (xml)


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:

<code>kubectl logs <pod_name></code>Code language: HTML, XML (xml)

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:

<code>kubectl logs <pod_name> -c <container_name></code>Code language: HTML, XML (xml)

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

<code>kubectl logs -f <service_name></code>Code language: HTML, XML (xml)

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.

More like this

The Evolution of Platform Engineering: Past, Present, and Future

The Evolution of Platform Engineering: Past, Present, and Future

In this post, we delve into the history of platform engineering, examining how it has evolved and what the future might hold. We will explore the transition from traditional IT infrastructure to modern platform engineering practices, and predict future trends and...

How to Quantify the ROI of Platform Engineering

How to Quantify the ROI of Platform Engineering

Measuring the Impact Platform Engineering is becoming the new “it” thing in software development, and it’s no wonder why. For starters, if we use an IDP (Internal Developer Platform) we can end up having fewer silos, better reusing components, and reaching an improved...

Host your own dashboard with Metabase

Host your own dashboard with Metabase

Data analytics platform on Napptive Data is one of the most precious assets of the twenty-first century, driving innovation, informing decisions, and shaping the future of technology and business. But extracting value out of an organization's data requires strategic...