Top 10 Kubernetes Commands Every DevOps Engineer Should Know for Efficient Cluster Management

Advanced Kubernetes Usage

Digging into advanced Kubernetes commands lets DevOps engineers manage complex clusters more efficiently. These techniques help keep resources organized, protect sensitive data, and make deployment updates way smoother across your setup.

Operating with Namespaces

Namespaces carve out virtual clusters inside your physical Kubernetes cluster. They keep resources isolated and logically organized, which is a huge win when multiple teams share a cluster.

To spin up a namespace, run:

kubectl create namespace my-application

If you want to work with resources in a specific namespace, just add the -n flag:

kubectl get pods -n my-application

This approach helps you avoid touching stuff in other namespaces by accident. If you’re tired of typing -n all the time, set a default namespace for your context:

kubectl config set-context --current --namespace=my-application

Need to see everything, everywhere? Use this:

kubectl get pods --all-namespaces

You can also apply quotas and limits per namespace, which adds another layer of control over resources.

Effective Labeling and Selectors

Labels and selectors are the backbone of how Kubernetes organizes stuff. They let you filter and group resources in powerful ways.

Want to add labels to something?

kubectl label pods my-pod environment=production team=backend

You can slap labels on resources when you create them or anytime after. Some typical labeling schemes:

• Environment: dev, test, prod
• Team: frontend, backend, data
• Application: app-name, version

If you need to filter resources by label, try:

kubectl get pods -l 'environment=production,team=backend'

This combo lets you perform actions on specific groups of resources:

kubectl delete pods -l 'environment=test'

For more advanced filtering, set-based selectors come in handy:

kubectl get pods -l 'environment in (dev,test)'

Secrets and Configurations

Kubernetes gives you special resources to keep config data and secrets safe and separate.

ConfigMaps hold non-sensitive config data:

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

Secrets are for sensitive stuff like passwords and tokens:

kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=supersecret

You can mount both as files in pods:

volumes:
  - name: config-volume
    configMap:
      name: app-config

Or expose them as environment variables:

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password

It’s always smart to follow best practices for managing secrets. In production, think about using sealed secrets or an external vault.

Rolling Updates and Rollbacks

Kubernetes shines at updating apps with barely any downtime, thanks to rolling updates.

To update a deployment, run:

kubectl set image deployment/frontend frontend=app:v2

Kubernetes will swap out old pods for new ones, gradually. To keep an eye on the process:

kubectl rollout status deployment/frontend

If things go south, roll back instantly:

kubectl rollout undo deployment/frontend

Want to hit a specific revision?

kubectl rollout undo deployment/frontend --to-revision=2

Check your revision history here:

kubectl rollout history deployment/frontend

You can tweak update behavior with deployment settings like:

• maxSurge: Number of extra pods allowed above the desired count
• maxUnavailable: Number of pods that can be offline during the update
• minReadySeconds: How long a pod needs to be ready before it counts as available

These rollout commands help you move smoothly between app versions—no drama.