Kubernetes Interview Questions and Answers

Use both: pull the right pods to the nodes, and push other pods away.

• nodeSelector: the simplest way. It matches a node label.
• Node affinity: more detailed rules (required or preferred).
• Taints and tolerations: taint the GPU nodes so only pods that tolerate the taint can run there.
• Resource requests: nvidia.com/gpu: 1 (needs the NVIDIA device plugin) makes sure the pod runs on a GPU node.

spec:
  nodeSelector:
    node-type: gpu
  tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: "NoSchedule"
  containers:
    - name: train
      image: trainer:1.0
      resources:
        limits:
          nvidia.com/gpu: 1

kubectl taint nodes gpu-1 nvidia.com/gpu=true:NoSchedule

The taint keeps normal apps off the costly nodes. The selector or GPU request sends GPU jobs to them.

What they are checking: Whether you know selectors, affinity and taints, and when to use each.

A Service gives pods a stable virtual IP and DNS name and load balances across them.

• ClusterIP (default): reachable only inside the cluster.
• NodePort: opens a port (30000-32767) on every node. Mostly for testing.
• LoadBalancer: asks the cloud to create an external load balancer (an NLB or CLB on AWS) pointing at the service.
• ExternalName: a DNS alias to an outside name.

Ingress is a web traffic routing layer on top. One ingress controller serves many services by host and path. It can be NGINX, or the AWS Load Balancer Controller that creates an ALB. It also handles TLS, and you do not pay for one load balancer per service.

rules:
  - host: api.example.com
    http:
      paths:
        - path: /
          pathType: Prefix
          backend:
            service: {name: api, port: {number: 80}}

What they are checking: Whether you know how traffic gets into a cluster and why Ingress saves load balancers.

A Pod is the smallest deployable unit in Kubernetes: one or more closely linked containers. They share one network (one IP), the same storage volumes and the same lifecycle.

• A container is a single packaged process. A Pod wraps one or more containers and is what the scheduler places on a node.
• Containers in a Pod talk to each other over localhost and can share volumes.
• Most Pods hold one main container; extra containers are helpers (sidecars, init containers).
• Pods are short-lived. If one dies, a new Pod with a new IP replaces it. This is why you use Deployments and Services instead of running bare Pods.

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

What they are checking: Whether you understand the main building block of Kubernetes.

A cluster has a control plane that decides what should run, and worker nodes that run the Pods.

Control plane

• kube-apiserver: the front door. All components and kubectl talk to it.
• etcd: a key-value store that holds the cluster state.
• kube-scheduler: picks a node for each unscheduled Pod.
• kube-controller-manager: runs controllers that move actual state toward desired state (ReplicaSet, Node, Job and others).
• cloud-controller-manager: connects Kubernetes to the cloud (load balancers, nodes, routes).

Worker node

• kubelet: makes sure the containers of assigned Pods are running and healthy.
• kube-proxy: programs Service networking rules.
• Container runtime: containerd or CRI-O.

In managed services (EKS, GKE, AKS) the provider runs and upgrades the control plane for you.

What they are checking: Whether you can describe how a request flows through the cluster.

A Deployment manages ReplicaSets, and a ReplicaSet manages Pods.

The main commands are get, describe, logs, exec, apply and delete.

Create a ConfigMap with non-sensitive settings, then inject it as environment variables or as files in a volume.

Probes let the kubelet check if a container is healthy.

Requests are what the scheduler reserves for a container; limits are the maximum it may use.

They keep apart how storage is made and how Pods ask for it.

A Service gives a stable IP and DNS name to a group of Pods that keeps changing. It shares traffic across the ready ones.

Never bake secrets into images or commit them to Git.

Docker

• docker run -e KEY=value or --env-file .env; in Compose use environment: or env_file:.
• For build-time secrets use BuildKit: RUN --mount=type=secret,id=npmrc ....

Prefer one central Argo CD (in a management cluster) that deploys to many clusters. Do not run one Argo CD per cluster.

EKS runs the control plane for you, but you still manage much of the rest.

Namespaces split one cluster into smaller virtual clusters. Teams or environments can share it without name clashes.

Labels are key-value tags on objects. Selectors find objects by those labels.

A Job runs Pods until they finish a one-time task. A CronJob creates Jobs on a schedule.

Managed services run the control plane for you. kubeadm and Minikube are for clusters you run yourself or on your laptop.

Helm is the package manager for Kubernetes. A chart is a versioned bundle of template manifests plus default settings. A release is one installed copy of a chart.

A chart contains Chart.yaml (metadata), values.yaml (defaults), and templates/ (Go-templated YAML). You override values per environment with -f values-prod.yaml or --set.

helm install web ./web -f values-prod.yaml -n prod
helm upgrade web ./web -f values-prod.yaml -n prod
helm rollback web 1 -n prod
helm list -n prod

Why it helps: one template works for dev, staging and prod. Releases have versions, history and rollback. You can install third-party software with one command.

What they are checking: Whether you have used Helm for templates and releases.

Path of a request: user -> DNS -> cloud load balancer -> ingress controller -> Service -> pod.

1. DNS resolves each domain to the same load balancer.
2. The load balancer (an ALB, or an NLB in front of NGINX) sends traffic to the ingress controller. With the AWS Load Balancer Controller, the ALB can send traffic straight to pod IPs (target-type: ip).
3. The Ingress rules send traffic to different Services by Host header and path.
4. The Service shares traffic across healthy pods (those that pass readiness probes).

spec:
  ingressClassName: alb
  tls:
    - hosts: [app.example.com, api.example.com]
      secretName: tls
  rules:
    - host: app.example.com
      http: {paths: [{path: /, pathType: Prefix, backend: {service: {name: web, port: {number: 80}}}}]}
    - host: api.example.com
      http: {paths: [{path: /, pathType: Prefix, backend: {service: {name: api, port: {number: 80}}}}]}

TLS certificates for several domains come from ACM (SNI) or cert-manager. One load balancer for many apps saves money. The ALB group.name annotation can join several Ingresses onto one ALB.

What they are checking: Whether you understand host and path routing from start to end, not only Service types.

Kubernetes is an open-source tool that runs and manages containers. You declare the state you want, for example three replicas of an image. Kubernetes keeps working to make the real state match it. It handles scheduling, scaling, self-healing and rollouts.

Key pieces:

• Control plane: API server, etcd, scheduler and controller manager.
• Nodes: run the kubelet and a container runtime.
• Objects: Pod, Deployment, Service, Ingress, ConfigMap, Secret, PersistentVolumeClaim.

What it gives you: automatic restarts of failed pods, rolling updates and rollbacks, scaling out, service discovery and load balancing. Your config is written as files that say what you want (declarative), which fits GitOps.

Managed offerings such as EKS, GKE and AKS run the control plane for you (the part that makes decisions).

What they are checking: Whether you can explain the problem Kubernetes solves and its core components.

A Deployment manages identical pods that keep no state. A StatefulSet manages pods that need identity and stable storage.

Use a StatefulSet for databases, Kafka, Elasticsearch and anything where each replica needs its own saved data or a stable hostname. Leader election and cluster membership are examples. Use a Deployment for web and API services. Apps like Airflow can use a StatefulSet for parts that keep local state, such as workers that need saved logs.

What they are checking: Whether you know when pod identity and per-pod storage matter.

Storage

• Install the EBS CSI driver for block volumes (RWO, one AZ) and the EFS CSI driver for shared storage (RWX).
• Create a StorageClass (for example gp3), then request storage with a PersistentVolumeClaim, or volumeClaimTemplates in a StatefulSet.
• Use EBS for databases and low-latency data, EFS for shared files. Set the reclaim policy, and take snapshots (VolumeSnapshot) or backups.

Secrets

• Keep secrets in AWS Secrets Manager or Parameter Store.
• Use the Secrets Store CSI driver with the AWS provider to mount them as files (or copy them into Kubernetes Secrets). You can also use External Secrets Operator.
• Grant access with IRSA or Pod Identity, limited to that one secret.

volumeClaimTemplates:
  - metadata: {name: data}
    spec:
      accessModes: [ReadWriteOnce]
      storageClassName: gp3
      resources: {requests: {storage: 20Gi}}

What they are checking: Whether you can match the right storage and the right AWS secret tool.

Access modes say how many nodes can mount a volume at the same time.

• ReadWriteOnce (RWO): read-write by a single node. Pods on that same node can still share it. It is typical for block storage such as AWS EBS, which is also tied to one availability zone.
• ReadWriteMany (RWX): read-write by many nodes at once. It needs a shared filesystem such as AWS EFS, NFS or CephFS.
• There are also ReadOnlyMany (ROX) and ReadWriteOncePod (one pod only).

Practical impact: a Deployment with several replicas on different nodes cannot all mount an RWO volume. So use RWX storage for shared uploads, or give each replica its own volume with a StatefulSet. Databases usually want RWO block storage because it is fast.

What they are checking: Whether you can match storage types to workloads and know how EBS and EFS differ.

Steps, in order:

It is possible, but often not the best choice. Managed services (RDS, Aurora) handle backups, patching, failover and upgrades for you. For most teams, a managed database is the safer default.

Use one standard chart and keep environment differences only in values.

A typical CI/CD and GitOps flow:

With the Amazon VPC CNI, every pod gets a real VPC IP address. The CNI attaches network interfaces (ENIs) to the node. It gives their extra private IPs to pods. So pods can be reached directly inside the VPC.

RBAC grants permissions to subjects (users, groups, ServiceAccounts) through roles and bindings. Permissions only add up. There are no deny rules.

Workloads on spot instances should keep no state, because AWS can take a spot instance back with a two-minute warning.

Use the same structure and automation everywhere, and make lower environments smaller.

Give each pod its own IAM role through its Kubernetes ServiceAccount. Do not use the node's role or fixed keys.

Do everything through code and reviewed pipelines, give only the access needed, and keep logs.

A DaemonSet makes sure one copy of a pod runs on every node (or on chosen nodes). When a node joins the cluster, the pod is added. When a node leaves, the pod is removed.

An operator is a custom controller that manages an application. It adds new object types to Kubernetes with a Custom Resource Definition (CRD). You write a custom object, for example kind: PostgresCluster. The operator's reconcile loop then creates and looks after the pods, volumes, backups and upgrades to match it.

Karpenter adds nodes to a Kubernetes cluster (it came from AWS). When pods are Pending, it starts EC2 instances sized to fit them, directly through the EC2 API. It removes nodes that are empty or can be merged.

They use Service DNS names. Each Service gets a name of the form <service>.<namespace>.svc.cluster.local.

• Inside the same namespace, the short name orders works.
• Across namespaces use orders.shop or the full name orders.shop.svc.cluster.local.

Use NetworkPolicies. By default every pod can talk to every other pod. So start with a rule that denies all, then allow only what is needed.

Cordon the node so nothing new is placed on it. Then drain it to move Pods away safely. A PodDisruptionBudget (PDB) limits how many replicas can be down at once.

Helm packs manifests into a chart. Each install or upgrade makes a numbered release revision that you can roll back.

By default, Secrets are only base64-encoded, not encrypted. So they are not safe on their own.

Risks: anyone with get secret rights can read them. They sit unencrypted in etcd unless encryption at rest is on. They can also leak through Git, logs or env vars.

They control how much each namespace can use, so one team cannot take everything.

Init containers run and finish before the app containers start. Sidecars run next to the app for its whole life.

etcd holds all cluster state, so back it up and run several members that vote together (a quorum).

It finds subnets by tag, unless you set them yourself.

CrashLoopBackOff means the container keeps starting, crashing and restarting, with longer waits each time. Find out why the process exits.

Pending means the Pod was accepted but not placed on a node yet (or its volumes or image are not ready). kubectl describe pod and its Events tell you which.

The kubelet cannot download the image. Read the exact message in the Pod events.

NotReady means the control plane stopped getting healthy signals (heartbeats) from the kubelet. Start at the node and work outward.

OOMKilled (exit code 137) means the container used more memory than its limit, so the kernel killed it.

Confirm:

kubectl describe pod web-abc | grep -A5 'Last State'
kubectl top pod web-abc --containers

Follow the path from the Ingress down to the Pod and find where it breaks.

Start with kubectl describe hpa and kubectl get hpa; the Conditions and metrics columns show what is wrong.

Use a rolling update together with correct health checks and a clean shutdown.

Plan, test and roll out step by step, one minor version at a time.

Scale at two levels: pods and nodes.

Roll back with the Deployment revision history:

Follow the path step by step.