Tutorial Kubernetes kubectl Helm DevOps Developer Tools Cheat Sheet

Free Kubernetes Commands Cheat Sheet Online — 120+ kubectl & Helm Commands

· 22 min read

Free Kubernetes Commands Cheat Sheet Online

Kubernetes has become the operating system of the cloud. Whether you are deploying a microservice, scaling a stateful application, or debugging a failing pod, the command line is where the work gets done. kubectl, the Kubernetes command-line tool, is the primary interface between you and the cluster. It is powerful, but it is also vast. Hundreds of subcommands, dozens of resource types, and countless flags make it impossible to memorize everything. That is exactly why a well-designed Kubernetes commands cheat sheet is not a luxury. It is a necessity.

Our free interactive Kubernetes Commands Cheat Sheet covers more than 120 commands across ten categories, from basic cluster navigation to advanced RBAC and Helm operations. Every command includes a description, the exact syntax, and a working example. The interface is searchable, filterable, and copyable. No signup. No ads. No server-side data collection. It works entirely in your browser, even offline. Bookmark it and keep it open during your next deployment, incident response, or certification study session.

If you are also working with containers at the Docker level, our Docker Commands Expansion Cheat Sheet covers advanced Docker commands, multi-stage builds, Buildx, and Dockerfile instructions. For a broader DevOps reference, see our DevOps Commands Cheat Sheet which spans Docker, Kubernetes, AWS CLI, Helm, and Terraform in one place.

What is kubectl?

kubectl is the official command-line client for the Kubernetes API. It sends HTTP requests to the Kubernetes API server, which then communicates with the control plane components — etcd, the scheduler, the controller manager — to perform operations on the cluster. Everything you do with kubectl is an API call. When you run kubectl get pods, you are making a GET request to the API server's /api/v1/pods endpoint. When you run kubectl apply -f deployment.yaml, you are sending a PATCH or POST request with the resource manifest.

Understanding this API-centric design is important because it explains kubectl's behavior. Resources are identified by kind, name, and namespace. Operations are verbs: get, list, create, update, delete, patch, watch. Flags modify how the operation is performed. Output formats, field selectors, and label selectors let you control what comes back. The more you internalize this model, the faster you move from "looking up commands" to "thinking in Kubernetes."

Kubernetes Commands Cheat Sheet Overview

Our cheat sheet organizes kubectl and Helm commands into ten categories that map to real operational workflows:

  • Cluster & Context Commands — Managing multiple clusters, switching contexts, and inspecting cluster state.
  • Pod Management Commands — Creating, listing, inspecting, deleting, and executing commands inside pods.
  • Deployment & Rollout Commands — Managing deployments, rolling updates, rollbacks, and replica scaling.
  • Services & Networking Commands — Exposing applications, port forwarding, ingress, and network policies.
  • ConfigMaps & Secrets — Managing configuration data and sensitive credentials.
  • Storage (PV, PVC, StorageClass) — Persistent volumes, claims, and storage provisioning.
  • Node Management & Scheduling — Inspecting nodes, cordoning, draining, taints, and tolerations.
  • Security & RBAC Commands — Roles, role bindings, service accounts, and network policies.
  • Troubleshooting & Debugging Commands — Logs, events, describe, debug, and port-forward.
  • Helm Commands for Kubernetes — Installing, upgrading, rolling back, and managing chart releases.

Each category contains the commands you actually use, not theoretical edge cases. The examples are production-ready and copy-pasteable.

Cluster & Context Commands

Most developers interact with multiple Kubernetes clusters: a local minikube or kind cluster, a staging cluster, and one or more production clusters. kubectl uses contexts to manage these connections. A context bundles a cluster, a user credential, and a default namespace.

To list all contexts:

kubectl config get-contexts

To view the current context:

kubectl config current-context

To switch to a different context:

kubectl config use-context staging-cluster

To set the default namespace for a context:

kubectl config set-context --current --namespace=production

To view your full kubeconfig:

kubectl config view

To view the kubeconfig for a specific context:

kubectl config view --minify --context=production-cluster

To check cluster health and version:

kubectl cluster-info
kubectl version --short

To list all API resources available in the cluster:

kubectl api-resources

To see API resources with their shortnames and verbs:

kubectl api-resources -o wide

To list all namespaces:

kubectl get namespaces

To create a namespace:

kubectl create namespace my-app

To delete a namespace and all resources within it:

kubectl delete namespace my-app

Context management is the foundation of safe multi-cluster operations. Always verify your current context before running destructive commands. Many engineers add a shell prompt indicator showing the current context and namespace to prevent accidental production changes.

Pod Management Commands

Pods are the smallest deployable units in Kubernetes. A pod encapsulates one or more containers, shared storage volumes, and networking configuration. Most of your day-to-day kubectl usage involves creating, inspecting, and managing pods.

To list pods in the current namespace:

kubectl get pods

To list pods in all namespaces:

kubectl get pods --all-namespaces

To list pods with wide output showing node names:

kubectl get pods -o wide

To get detailed information about a specific pod:

kubectl describe pod my-pod

To create a pod from a YAML manifest:

kubectl apply -f pod.yaml

To create a pod imperatively:

kubectl run nginx --image=nginx:latest --restart=Never

To delete a pod:

kubectl delete pod my-pod

To delete a pod and immediately recreate it:

kubectl delete pod my-pod --now

To delete pods matching a label selector:

kubectl delete pods -l app=frontend

To execute a command inside a running pod:

kubectl exec my-pod -- ls /app

To open an interactive shell inside a pod:

kubectl exec -it my-pod -- /bin/sh

For multi-container pods, specify the container:

kubectl exec -it my-pod -c app -- /bin/bash

To copy files from a pod to your local machine:

kubectl cp my-pod:/app/logs/app.log ./local-app.log

To copy files from your local machine to a pod:

kubectl cp ./config.json my-pod:/app/config.json

To watch pods in real time:

kubectl get pods -w

To get pods with custom columns showing name, status, and restarts:

kubectl get pods -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,RESTARTS:.status.containerStatuses[0].restartCount

To get the YAML manifest of a running pod:

kubectl get pod my-pod -o yaml

To edit a pod's manifest live:

kubectl edit pod my-pod

Pod management commands form the core of Kubernetes operations. The ability to quickly inspect, exec into, and copy files from pods makes debugging application issues dramatically faster than traditional SSH-based workflows.

Deployment & Rollout Commands

Deployments are the standard way to manage stateless applications in Kubernetes. A deployment declaratively defines the desired state — which image to run, how many replicas, which ports to expose — and the deployment controller continuously works to match the actual state to that desired state.

To list deployments:

kubectl get deployments

To create a deployment imperatively:

kubectl create deployment my-app --image=my-app:v1.0 --replicas=3

To scale a deployment:

kubectl scale deployment my-app --replicas=5

To update a deployment's image:

kubectl set image deployment/my-app app=my-app:v1.1

To check rollout status:

kubectl rollout status deployment/my-app

To view rollout history:

kubectl rollout history deployment/my-app

To view details of a specific revision:

kubectl rollout history deployment/my-app --revision=3

To undo a rollout to the previous revision:

kubectl rollout undo deployment/my-app

To undo to a specific revision:

kubectl rollout undo deployment/my-app --to-revision=2

To pause a rollout:

kubectl rollout pause deployment/my-app

To resume a paused rollout:

kubectl rollout resume deployment/my-app

To restart a deployment (recreate pods with the same spec):

kubectl rollout restart deployment/my-app

To get detailed information about a deployment:

kubectl describe deployment my-app

To delete a deployment:

kubectl delete deployment my-app

To export a deployment manifest:

kubectl get deployment my-app -o yaml > deployment-backup.yaml

Rolling updates and rollbacks are where Kubernetes shines. The deployment controller creates a new ReplicaSet with the updated spec, scales it up while scaling the old one down, and monitors pod readiness to ensure zero-downtime updates. When things go wrong, a single kubectl rollout undo command reverts to the previous stable state.

Services & Networking Commands

Services provide stable networking endpoints for pods. Because pods are ephemeral — their IP addresses change when they are recreated — you need a service to maintain a consistent IP and DNS name. Kubernetes supports several service types: ClusterIP (internal only), NodePort (exposes on each node's IP), LoadBalancer (cloud provider load balancer), and ExternalName (DNS alias).

To list services:

kubectl get services

To expose a deployment as a service:

kubectl expose deployment my-app --type=ClusterIP --port=80 --target-port=8080

To expose a deployment with a LoadBalancer:

kubectl expose deployment my-app --type=LoadBalancer --port=80 --target-port=8080

To get details about a service:

kubectl describe service my-app

To delete a service:

kubectl delete service my-app

To port-forward from your local machine to a pod:

kubectl port-forward pod/my-pod 8080:80

To port-forward to a service:

kubectl port-forward service/my-app 8080:80

To port-forward to a deployment:

kubectl port-forward deployment/my-app 8080:80

To port-forward multiple ports:

kubectl port-forward pod/my-pod 8080:80 8443:443

To list ingress resources:

kubectl get ingress

To describe an ingress:

kubectl describe ingress my-ingress

To list network policies:

kubectl get networkpolicies

To get endpoints for a service:

kubectl get endpoints my-app

Port-forwarding is one of the most useful kubectl features for local development. It creates a secure tunnel from your local machine to a pod or service in the cluster, allowing you to test APIs and databases without exposing them publicly. The tunnel lasts only as long as the kubectl process runs, making it a safe temporary access mechanism.

ConfigMaps & Secrets

ConfigMaps and Secrets decouple configuration from container images. ConfigMaps store non-sensitive configuration data like environment variables, command-line arguments, and config files. Secrets store sensitive data like passwords, API keys, and TLS certificates. Both are mounted as volumes or injected as environment variables.

To create a ConfigMap from literal values:

kubectl create configmap app-config --from-literal=env=production --from-literal=port=8080

To create a ConfigMap from a file:

kubectl create configmap app-config --from-file=config.json

To create a ConfigMap from an entire directory:

kubectl create configmap app-config --from-file=./config/

To list ConfigMaps:

kubectl get configmaps

To view a ConfigMap's data:

kubectl get configmap app-config -o yaml

To describe a ConfigMap:

kubectl describe configmap app-config

To delete a ConfigMap:

kubectl delete configmap app-config

To create a Secret from literal values:

kubectl create secret generic db-password --from-literal=password=supersecret

To create a Secret from a file:

kubectl create secret generic tls-cert --from-file=tls.crt --from-file=tls.key

To create a TLS Secret from certificate files:

kubectl create secret tls my-tls --cert=cert.pem --key=key.pem

To create a docker-registry Secret for pulling private images:

kubectl create secret docker-registry regcred --docker-server=registry.example.com --docker-username=myuser --docker-password=mypass

To list Secrets:

kubectl get secrets

To view a Secret's data (base64 encoded):

kubectl get secret db-password -o yaml

To decode a Secret value:

kubectl get secret db-password -o jsonpath='{.data.password}' | base64 -d

To delete a Secret:

kubectl delete secret db-password

Secrets are base64 encoded by default, not encrypted. For production clusters, enable encryption at rest using a KMS provider. Never commit unencrypted Secrets to version control. Tools like Sealed Secrets, External Secrets Operator, or Vault integrations are the industry standard for managing sensitive configuration in GitOps workflows.

Storage (PV, PVC, StorageClass)

Kubernetes abstracts storage through PersistentVolumes (PV), PersistentVolumeClaims (PVC), and StorageClasses. A PV is a piece of storage in the cluster, provisioned by an administrator or dynamically by a StorageClass. A PVC is a request for storage by a user. StorageClasses define different tiers of storage — SSD, HDD, replicated, local — and the provisioner that creates them.

To list PersistentVolumes:

kubectl get pv

To describe a PersistentVolume:

kubectl describe pv my-volume

To list PersistentVolumeClaims:

kubectl get pvc

To describe a PVC:

kubectl describe pvc my-claim

To delete a PVC:

kubectl delete pvc my-claim

To list StorageClasses:

kubectl get storageclass

To describe a StorageClass:

kubectl describe storageclass standard

To set a default StorageClass:

kubectl patch storageclass standard -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

To view volume attachments:

kubectl get volumeattachments

Storage management in Kubernetes requires understanding your underlying infrastructure. Cloud providers offer different storage types with different performance and availability characteristics. On-premises clusters may use NFS, iSCSI, or Ceph. Always test storage performance before deploying stateful workloads to production.

Node Management & Scheduling

Nodes are the worker machines in a Kubernetes cluster. They can be virtual machines or physical machines, running the kubelet, kube-proxy, and container runtime. Understanding node management commands is essential for cluster maintenance, capacity planning, and troubleshooting scheduling issues.

To list all nodes:

kubectl get nodes

To get detailed node information:

kubectl describe node node-1

To view node resource usage:

kubectl top node

To cordon a node (prevent new pods from being scheduled):

kubectl cordon node-1

To uncordon a node:

kubectl uncordon node-1

To drain a node (evict all pods gracefully):

kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data

To drain a node with a grace period:

kubectl drain node-1 --grace-period=60 --timeout=300s

To mark a node as unschedulable without draining:

kubectl cordon node-1

To view pods running on a specific node:

kubectl get pods --all-namespaces --field-selector spec.nodeName=node-1

To add a taint to a node:

kubectl taint nodes node-1 dedicated=gpu:NoSchedule

To remove a taint:

kubectl taint nodes node-1 dedicated=gpu:NoSchedule-

To label a node:

kubectl label nodes node-1 disktype=ssd

To remove a label:

kubectl label nodes node-1 disktype-

To get node conditions:

kubectl get nodes -o json | jq '.items[].status.conditions'

Draining a node before maintenance is a critical operational procedure. The drain command respects PodDisruptionBudgets, gracefully terminates pods, and ensures your workloads remain available. Always verify that your cluster has sufficient capacity before draining a node, especially in smaller clusters.

Security & RBAC Commands

Role-Based Access Control (RBAC) is how Kubernetes manages permissions. RBAC defines who can do what to which resources. It uses Roles and ClusterRoles to define permissions, and RoleBindings and ClusterRoleBindings to assign those permissions to users, groups, or service accounts.

To list Roles:

kubectl get roles

To describe a Role:

kubectl describe role pod-reader

To list ClusterRoles:

kubectl get clusterroles

To describe a ClusterRole:

kubectl describe clusterrole view

To list RoleBindings:

kubectl get rolebindings

To list ClusterRoleBindings:

kubectl get clusterrolebindings

To create a Role from a manifest:

kubectl apply -f role.yaml

To create a RoleBinding:

kubectl apply -f rolebinding.yaml

To list service accounts:

kubectl get serviceaccounts

To create a service account:

kubectl create serviceaccount my-sa

To describe a service account:

kubectl describe serviceaccount my-sa

To check what permissions a user or service account has:

kubectl auth can-i get pods --as=system:serviceaccount:default:my-sa

To list all permissions you currently have:

kubectl auth can-i --list

To check if you can perform an action:

kubectl auth can-i create deployments

To check if you can perform an action in a specific namespace:

kubectl auth can-i delete pods --namespace=production

To list pod security policies (if enabled):

kubectl get psp

RBAC is powerful but complex. The principle of least privilege should guide every role definition. Avoid using ClusterRoleBindings when a RoleBinding scoped to a single namespace is sufficient. Regularly audit permissions with kubectl auth can-i --list and remove unused roles and bindings.

Troubleshooting & Debugging Commands

Things break. Pods crash, deployments fail to roll out, services return 503 errors. The difference between a ten-minute outage and a two-hour outage often comes down to how fast you can diagnose the problem. These commands are your diagnostic toolkit.

To view pod logs:

kubectl logs my-pod

To stream logs in real time:

kubectl logs -f my-pod

To view logs from a specific container:

kubectl logs my-pod -c app

To view previous container logs after a crash:

kubectl logs my-pod --previous

To view logs with a timestamp:

kubectl logs my-pod --timestamps

To view the last N lines:

kubectl logs my-pod --tail=100

To view logs from all containers in a pod:

kubectl logs my-pod --all-containers

To view logs from pods matching a label selector:

kubectl logs -l app=frontend --all-containers

To describe a resource for events and conditions:

kubectl describe pod my-pod
kubectl describe deployment my-app
kubectl describe node node-1

To view cluster events:

kubectl get events

To view events sorted by timestamp:

kubectl get events --sort-by='.lastTimestamp'

To view events for a specific resource:

kubectl get events --field-selector involvedObject.name=my-pod

To watch events in real time:

kubectl get events -w

To debug a pod with an ephemeral container:

kubectl debug -it my-pod --image=busybox --target=app

To debug a node:

kubectl debug node/node-1 -it --image=ubuntu

To run a temporary debug pod:

kubectl run debug --rm -it --image=nicolaka/netshoot --restart=Never -- /bin/bash

To get resource usage for pods:

kubectl top pod

To get resource usage for a specific pod:

kubectl top pod my-pod

To get resource usage for containers within a pod:

kubectl top pod my-pod --containers

To check API server health:

kubectl get --raw='/readyz'
kubectl get --raw='/livez'

To run a command and capture the exit code:

kubectl run test --rm -it --image=busybox --restart=Never -- wget -qO- http://my-service

The describe command is your first stop for troubleshooting. It aggregates events, conditions, and status information into a human-readable format. When a pod is stuck in Pending, describe tells you whether it is a resource constraint, a scheduling failure, or an image pull error. When a deployment fails to roll out, describe shows the ReplicaSet status and any scaling events.

Helm Commands for Kubernetes

Helm is the package manager for Kubernetes. It uses charts — templated Kubernetes manifests — to define, install, and upgrade complex applications. A single Helm chart can deploy a multi-service application with dependencies, configuration, and secrets in one command.

To add a chart repository:

helm repo add bitnami https://charts.bitnami.com/bitnami

To update chart repositories:

helm repo update

To list added repositories:

helm repo list

To search for charts in repositories:

helm search repo nginx

To search for charts in the Artifact Hub:

helm search hub nginx

To install a chart:

helm install my-nginx bitnami/nginx

To install a chart with custom values:

helm install my-nginx bitnami/nginx --set replicaCount=3

To install a chart with a values file:

helm install my-nginx bitnami/nginx -f custom-values.yaml

To install a chart into a specific namespace:

helm install my-nginx bitnami/nginx --namespace production --create-namespace

To list installed releases:

helm list

To list releases in all namespaces:

helm list --all-namespaces

To get release status:

helm status my-nginx

To get release history:

helm history my-nginx

To upgrade a release:

helm upgrade my-nginx bitnami/nginx

To upgrade with new values:

helm upgrade my-nginx bitnami/nginx --set replicaCount=5

To upgrade and install if not exists:

helm upgrade --install my-nginx bitnami/nginx

To rollback to a previous revision:

helm rollback my-nginx 2

To uninstall a release:

helm uninstall my-nginx

To uninstall and keep history:

helm uninstall my-nginx --keep-history

To show a chart's values:

helm show values bitnami/nginx

To show a chart's README:

helm show readme bitnami/nginx

To show a chart's manifest:

helm show manifest bitnami/nginx

To lint a chart:

helm lint ./my-chart

To template a chart locally without installing:

helm template my-release ./my-chart

To template with values:

helm template my-release ./my-chart -f values.yaml

To get release values:

helm get values my-nginx

To get all release values including defaults:

helm get values my-nginx --all

To get the manifest of an installed release:

helm get manifest my-nginx

To package a chart:

helm package ./my-chart

To create a new chart scaffold:

helm create my-chart

Helm transforms Kubernetes from a collection of YAML files into a manageable software delivery platform. Charts encapsulate best practices, provide sensible defaults, and allow customization through values files. The ability to rollback a release in seconds makes Helm an essential tool for production deployments.

kubectl Tips & Shortcuts

Speed matters when you are responding to an incident or iterating on a deployment. These tips and shortcuts will make your kubectl workflow faster and more efficient.

Set up shell aliases for common commands:

alias k='kubectl'
alias kg='kubectl get'
alias kd='kubectl describe'
alias kgp='kubectl get pods'
alias kgs='kubectl get services'
alias kgn='kubectl get nodes'
alias kdf='kubectl delete -f'
alias kaf='kubectl apply -f'

Use kubectl completion for your shell:

source <(kubectl completion bash)
source <(kubectl completion zsh)

Use the --dry-run flag to preview changes:

kubectl apply -f deployment.yaml --dry-run=client
kubectl apply -f deployment.yaml --dry-run=server

Client-side dry-run validates the manifest locally. Server-side dry-run sends the manifest to the API server for validation without persisting it.

Use --output jsonpath for precise data extraction:

kubectl get pod my-pod -o jsonpath='{.status.phase}'
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"	"}{.status.addresses[0].address}{"
"}{end}'

Use --output custom-columns for tabular views:

kubectl get pods -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,IP:.status.podIP

Use kubectl explain to understand resource fields:

kubectl explain pod.spec.containers
kubectl explain deployment.spec.strategy

Use kubectl with grep and jq for advanced filtering:

kubectl get pods --all-namespaces | grep Evicted
kubectl get pods -o json | jq '.items[] | select(.status.phase != "Running") | .metadata.name'

Use --watch to monitor resources in real time:

kubectl get pods -w
kubectl get events -w --field-selector type=Warning

Use kubectl diff to see what will change before applying:

kubectl diff -f deployment.yaml

Use kubectl patch for quick updates without editing the full manifest:

kubectl patch deployment my-app -p '{"spec":{"replicas":5}}'

These shortcuts compound over time. A developer who has internalized kubectl aliases, jsonpath queries, and dry-run validation moves through Kubernetes operations with a fluidity that separates senior engineers from beginners.

How to Use Our Interactive Kubernetes Cheat Sheet

Our Kubernetes Commands Cheat Sheet is designed for developers and DevOps engineers who need fast access to kubectl and Helm knowledge. When you open the tool, you see more than 120 commands organized into ten color-coded categories. Click any category tab to filter commands by domain. Type in the search box to find commands by name, description, or example. Click the copy icon on any card to copy the example command to your clipboard.

The interface is optimized for long reference sessions. Commands are displayed on cards with clear syntax highlighting. Destructive commands that delete or modify resources are marked with warning badges. The layout surfaces exactly what you need without scrolling through irrelevant entries. Everything runs client-side in your browser. No data is sent to any server. The tool works offline once loaded, making it perfect for air-gapped environments or working without internet access.

Whether you are studying for the CKA certification, debugging a production incident, or onboarding a new team member to Kubernetes, this cheat sheet is the fastest way to find the right command. Bookmark it, share it with your team, and keep it open during your next cluster operation.

Related Tools

DevToolkit offers a growing collection of interactive developer references. Explore these related cheat sheets and tools:

FAQ

What is kubectl and why do I need a Kubernetes commands cheat sheet?

kubectl is the official command-line interface for Kubernetes. It is the primary tool developers and DevOps engineers use to interact with Kubernetes clusters, deploy applications, inspect resources, and troubleshoot issues. A Kubernetes commands cheat sheet is essential because kubectl has hundreds of subcommands, flags, and resource types. No one memorizes them all. A well-organized cheat sheet reduces retrieval friction when you are debugging a failing pod, scaling a deployment, or configuring RBAC at 2 AM.

What is the difference between kubectl apply and kubectl create?

kubectl create creates a resource from a file or stdin. If the resource already exists, create fails with an error. kubectl apply uses a declarative approach: it creates the resource if it does not exist, or updates it if it does. apply stores the last-applied configuration in an annotation, enabling three-way merge during updates. For production workflows, apply is preferred because it is idempotent and supports GitOps workflows where the same command is run repeatedly.

How do I view logs from a Kubernetes pod using kubectl logs?

Use kubectl logs POD_NAME to view logs from a single-container pod. For multi-container pods, specify the container with -c CONTAINER_NAME. Stream logs in real time with the -f flag. View previous container logs after a crash with --previous. Limit output to the last N lines with --tail=N. For example: kubectl logs -f my-pod -c app --tail=100 streams the last 100 lines from the app container and follows new output.

How do I debug a failing pod with kubectl exec and kubectl debug?

For basic debugging, use kubectl exec -it POD_NAME -- /bin/sh to open an interactive shell inside a running container. If the container has no shell, use kubectl debug to attach an ephemeral debug container: kubectl debug -it POD_NAME --image=busybox --target=CONTAINER_NAME. For nodes, use kubectl debug node/NODE_NAME -it --image=ubuntu to launch a privileged pod on the target node with access to the host filesystem. This is invaluable for diagnosing networking, storage, or kernel-level issues.

What are the most important Helm commands for managing Kubernetes releases?

The essential Helm commands are: helm install to deploy a chart, helm upgrade to update a release, helm rollback to revert to a previous revision, helm uninstall to remove a release, helm list to view installed releases, helm repo add to add chart repositories, helm search repo to find charts, helm show values to inspect configurable values, helm lint to validate chart syntax, and helm template to render manifests locally without installing. These commands cover the full lifecycle of Helm-managed applications.

How do I perform a zero-downtime deployment rollout in Kubernetes?

Use kubectl set image deployment/DEPLOYMENT_NAME container=image:tag to update the container image, which triggers a rolling update. Monitor the rollout with kubectl rollout status deployment/DEPLOYMENT_NAME. If something goes wrong, pause the rollout with kubectl rollout pause, or undo it with kubectl rollout undo deployment/DEPLOYMENT_NAME. You can also undo to a specific revision with --to-revision=N. Kubernetes handles the rolling update by creating new pods with the updated image, waiting for them to become ready, and then terminating old pods.

How do I expose a Kubernetes deployment with kubectl expose and kubectl port-forward?

Use kubectl expose deployment DEPLOYMENT_NAME --type=LoadBalancer --port=80 to create a Service that exposes the deployment. For local development and debugging, use kubectl port-forward pod/POD_NAME 8080:80 to forward local port 8080 to the pod's port 80. You can also port-forward to a service: kubectl port-forward service/SERVICE_NAME 8080:80. Port-forward is temporary and only lasts as long as the kubectl process runs, making it perfect for local testing without modifying cluster networking.

Conclusion

Kubernetes is not a tool you learn once and forget. It is a platform that rewards depth. The difference between a developer who knows kubectl get pods and one who can debug a node with kubectl debug, rollback a deployment with kubectl rollout undo, and manage releases with Helm is the difference between someone who uses Kubernetes and someone who operates it with confidence.

Our free Kubernetes Commands Cheat Sheet is built to bridge that gap. It covers the 120-plus commands you need across ten operational categories. It is interactive, searchable, and copyable. It requires no signup and works offline. Whether you are preparing for the CKA exam, responding to a production incident, or simply tired of searching Stack Overflow for the correct kubectl syntax, this cheat sheet is the reference you keep open.

Bookmark the Kubernetes Commands Cheat Sheet today. Your future self will thank you when you need the exact kubectl debug syntax or the correct Helm rollback command at 2 AM.

Found this useful? Check out our free developer tools or browse more articles.