Kubernetes Interview Questions

Nidhi Ashtikar

5 min read

·

Jun 27, 2026

--

Listen

Share

Press enter or click to view image in full size

1️⃣ A Pod is in CrashLoopBackOff. How would you troubleshoot it from start to finish?

CrashLoopBackOff means the container starts, crashes, and Kubernetes continuously restarts it with an increasing delay.

Step 1: Check Pod Status

kubectl get pods -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

Look for:

• Exit Code
• Restart Count
• Events
• OOMKilled
• Probe failures

Step 2: Check Logs

kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> --previous -n <namespace>

For multi-container Pods:

kubectl logs <pod-name> -c <container-name> --previous

Step 3: Check Events

kubectl get events -n <namespace> --sort-by=.lastTimestamp

Step 4: Verify Configuration

kubectl get pod <pod-name> -o yaml

Check:

• Environment Variables
• ConfigMaps
• Secrets
• Image Version
• Commands & Arguments
• Volume Mounts

Step 5: Check Resource Usage

kubectl top pod <pod-name>

If OOMKilled:

• Increase Memory Limits
• Fix Memory Leak

Step 6: Check Health Probes

kubectl describe pod <pod-name>

Verify:

• Liveness Probe
• Readiness Probe
• Startup Probe
• Correct Port
• Correct Path

Common Causes

• Application Crash
• Wrong Startup Command
• Missing ConfigMap/Secret
• Incorrect Environment Variables
• OOMKilled
• Failed Health Checks
• Database Connection Failure
• Volume Mount Issues
• Image Pull Issues
• Permission Errors

2️⃣ All Pods are Running, but the application is not accessible.

Running Pods do not always mean the application is healthy.

Step 1: Check Pods

kubectl get pods -o wide

Step 2: Check Service

kubectl get svc
kubectl describe svc <service-name>

Verify:

• Selector
• Port
• TargetPort

Step 3: Check Endpoints

kubectl get endpoints <service-name>

If Endpoints are empty:

• Labels don't match
• Pods aren't Ready

Step 4: Check Ingress

kubectl get ingress
kubectl describe ingress <ingress-name>

Step 5: Test From Inside Cluster

kubectl run test --rm -it --image=busybox -- sh

nslookup <service-name>

wget -qO- http://<service-name>:<port>

Step 6: Check NetworkPolicy

kubectl get networkpolicy

Step 7: Verify Application

Make sure application listens on:

0.0.0.0

Not:

127.0.0.1

3️⃣ A Deployment was updated, and users immediately started reporting issues.

Step 1: Check Rollout Status

kubectl rollout status deployment/<deployment>

Step 2: Check Rollout History

kubectl rollout history deployment/<deployment>

Step 3: Rollback

kubectl rollout undo deployment/<deployment>

Rollback to a specific revision:

kubectl rollout undo deployment/<deployment> --to-revision=3

Step 4: Verify

kubectl rollout status deployment/<deployment>

kubectl get pods -w

Production Best Practice

• Pause rollout if needed
• Rollback immediately
• Verify application health
• Check logs
• Perform RCA before redeploying

4️⃣ A Pod is stuck in the Pending state.

Step 1: Describe Pod

kubectl describe pod <pod-name>

Step 2: Check Events

kubectl get events --sort-by=.lastTimestamp

Step 3: Check Nodes

kubectl get nodes

kubectl describe node <node-name>

Common Reasons

• Insufficient CPU
• Insufficient Memory
• NodeSelector mismatch
• Taints & Tolerations
• PVC not bound
• StorageClass issue
• ImagePullSecret missing
• Pod Affinity rules
• ResourceQuota exceeded

Check PVC

kubectl get pvc

kubectl describe pvc <pvc-name>

5️⃣ A node suddenly becomes NotReady.

Step 1: Check Node

kubectl get nodes

kubectl describe node <node-name>

Step 2: Check Workloads

kubectl get pods -A -o wide | grep <node-name>

Step 3: SSH into Node

systemctl status kubelet

journalctl -u kubelet -xe

systemctl status containerd

df -h

free -m

Common Causes

• Kubelet Down
• Container Runtime Failure
• Disk Pressure
• Memory Pressure
• Network Failure
• CNI Issues
• Node Crash
• Certificate Expired

Recover

kubectl cordon <node-name>

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

After Fix:

kubectl uncordon <node-name>

6️⃣ One container inside a Pod keeps restarting while the other containers are healthy.

Check Container Logs

kubectl logs <pod-name> -c <container-name>

kubectl logs <pod-name> -c <container-name> --previous

Describe Pod

kubectl describe pod <pod-name>

Verify

• Environment Variables
• Startup Command
• Secrets
• ConfigMaps
• Volume Mounts
• Health Probes
• Sidecar Communication
• OOMKilled

Check Resources

kubectl top pod <pod-name> --containers

7️⃣ Application cannot communicate with another Service.

Step 1: Test DNS

kubectl run debug --rm -it --image=busybox -- sh

nslookup <service-name>

nslookup <service-name>.<namespace>.svc.cluster.local

Step 2: Verify Service

kubectl get svc

kubectl describe svc <service-name>

kubectl get endpoints <service-name>

Step 3: Check Labels

kubectl get pods --show-labels

Step 4: Check NetworkPolicy

kubectl get networkpolicy

kubectl describe networkpolicy <policy-name>

Step 5: Test Connectivity

kubectl exec -it <client-pod> -- curl http://<service-name>:<port>

Root Cause Decision

• DNS fails → CoreDNS Issue
• Endpoints empty → Label mismatch
• Connection refused → Service/Port Issue
• Timeout → NetworkPolicy
• HTTP 500 → Application Issue

8️⃣ How would you securely provide database passwords or API keys?

Create Secret

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

Use Secret as Environment Variable

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

Mount Secret as File

volumes:
- name: secret-volume
  secret:
    secretName: db-secret

Best Practices

• Use Kubernetes Secrets
• Enable Encryption at Rest
• Apply RBAC
• Never store Secrets in Git
• Rotate Secrets Regularly
• Use HashiCorp Vault / AWS Secrets Manager / Azure Key Vault / External Secrets Operator

9️⃣ CPU usage suddenly spikes to 100% in production.

Step 1: Identify High CPU Pods

kubectl top nodes

kubectl top pods

kubectl top pods --containers

Step 2: Check Logs

kubectl logs <pod-name> --since=10m

kubectl logs <pod-name> --previous

Step 3: Describe Pod

kubectl describe pod <pod-name>

Step 4: Check HPA

kubectl get hpa

kubectl describe hpa <hpa-name>

Step 5: Exec into Pod

kubectl exec -it <pod-name> -- top

Investigate

• Traffic Spike
• Infinite Loop
• High GC Activity
• CPU Throttling
• Resource Limits
• Database Slowness
• External API Latency

🔟 What is Custom Resource Definition.

A Custom Resource Definition (CRD) is a Kubernetes feature that allows us to extend the Kubernetes API by creating our own custom resource types. Instead of using only built-in resources like Pods, Services, and Deployments, we can define custom resources such as Database, Backup, or Application. Kubernetes stores these custom resources just like native resources, and a controller or operator watches them to perform the required actions.

Simple Example

Suppose your organization frequently deploys PostgreSQL databases.

Without a CRD, you would manually create:

• Deployment
• Service
• PersistentVolumeClaim
• Secret
• ConfigMap

With a CRD, you can simply create:

apiVersion: company.com/v1
kind: Database
metadata:
  name: customer-db
spec:
  engine: postgres
  version: "16"
  storage: 20Gi

Here:

• CRD defines the new resource type called Database.
• Database is the Custom Resource (CR).
• A controller/operator watches this resource and automatically creates the Deployment, Service, PVC, Secrets, and manages the database lifecycle.

Why do we use CRDs?

• Extend Kubernetes without changing its source code.
• Create application-specific resources.
• Automate complex deployments using operators.
• Manage custom applications in a Kubernetes-native way.

Real-world examples

Many popular Kubernetes tools use CRDs:

• cert-manager: Certificate, Issuer
• Prometheus Operator: Prometheus, ServiceMonitor
• Argo CD: Application

Interview-friendly one-liner

“A Custom Resource Definition (CRD) is a way to extend the Kubernetes API by defining your own resource types. These resources are managed by controllers or operators, allowing Kubernetes to automate application-specific tasks.”

This concise explanation is suitable for most Kubernetes interview questions and demonstrates both conceptual understanding and practical usage.