Top 50 kubernetes interview questions and answers for devops engineer

Introduction to Kubernetes & Core Concepts

Understanding the fundamental building blocks of Kubernetes is crucial for any interview. Interviewers will often start by testing your grasp of basic definitions and their practical implications.

Common questions might include: What is Kubernetes? What are Pods, Nodes, and Deployments? Explain the difference between a Deployment and a ReplicaSet.

Key Concepts & Explanations:

Kubernetes (K8s): An open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It provides a robust framework for running resilient workloads.
Pod: The smallest deployable unit in Kubernetes, representing a single instance of a running process in your cluster. A Pod can contain one or more containers (e.g., your app and a sidecar proxy).
Node: A worker machine (VM or physical server) in a Kubernetes cluster that runs Pods. Each node has a Kubelet for communication and a container runtime.
Deployment: A higher-level resource that manages the declarative updates to Pods and ReplicaSets. It ensures that a specified number of Pod replicas are always running.
ReplicaSet: Ensures a specified number of identical Pod replicas are running at any given time. Deployments internally use ReplicaSets to manage Pods.

Practical Action: Creating a Basic Deployment

A DevOps engineer should be able to demonstrate creating and managing resources. Here's a basic Nginx Deployment example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

To apply this, save it as nginx-deployment.yaml and run kubectl apply -f nginx-deployment.yaml.

Kubernetes Architecture & Components

Interviewers often delve into the architecture to gauge your understanding of how Kubernetes operates internally. Knowing the roles of different components is vital for effective troubleshooting and design.

Expect questions like: Describe the Kubernetes master-worker architecture. What is the function of the Kube-API-server, Kubelet, and Etcd?

Core Components:

Control Plane (Master Node):
- Kube-API-server: The front-end for the Kubernetes control plane, exposing the Kubernetes API. All communication to and from the cluster goes through it.
- Etcd: A consistent and highly available key-value store used as Kubernetes' backing store for all cluster data.
- Kube-Scheduler: Watches for newly created Pods with no assigned node and selects a node for them to run on.
- Kube-Controller-Manager: Runs controller processes, e.g., Node Controller, Job Controller, EndpointSlice Controller.
- Cloud-Controller-Manager (optional): Integrates with underlying cloud provider APIs (e.g., creating load balancers, persistent volumes).
Worker Node:
- Kubelet: An agent that runs on each node in the cluster, ensuring containers are running in a Pod. It communicates with the Kube-API-server.
- Kube-Proxy: Maintains network rules on nodes, enabling network communication to your Pods from inside or outside the cluster.
- Container Runtime (e.g., containerd, CRI-O, Docker): Responsible for running containers.

Example: Understanding Kubelet's Role

The Kubelet ensures that containers described in a PodSpec are running and healthy on its node. If a Pod fails, the Kubelet reports its status to the API server.

Networking & Services in Kubernetes

Networking is a complex but critical aspect of Kubernetes. DevOps engineers must understand how Pods communicate, how traffic enters the cluster, and different service types.

Typical questions include: Explain different types of Kubernetes Services. How does Ingress work? What is a CNI plugin?

Key Networking Concepts:

Service: An abstract way to expose an application running on a set of Pods as a network service.
- ClusterIP: Default type, exposes the Service on a cluster-internal IP. Accessible only from within the cluster.
- NodePort: Exposes the Service on each Node's IP at a static port. Makes the Service accessible from outside the cluster.
- LoadBalancer: Exposes the Service externally using a cloud provider's load balancer.
- ExternalName: Maps the Service to a CNAME record, returning its value.
Ingress: Manages external access to the services in a cluster, typically HTTP/HTTPS. Ingress can provide load balancing, SSL termination, and name-based virtual hosting.
Container Network Interface (CNI): A specification and set of libraries for writing plugins to configure network interfaces for Linux containers. Examples include Calico, Flannel, Cilium.

Practical Example: Exposing an Application with a Service

After deploying your Nginx (as shown above), you'd need a Service to expose it:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx # Selects Pods with this label
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer # Or ClusterIP, NodePort

This Service will route traffic on port 80 to the targetPort 80 of any Pods labeled app: nginx.

Storage & Persistence in Kubernetes

Stateless applications are easy, but most real-world applications require persistent storage. Interviewers will test your knowledge of how Kubernetes handles data persistence.

Expect questions like: How do you manage persistent storage in Kubernetes? What are PersistentVolumes and PersistentVolumeClaims? Explain StorageClasses.

Storage Fundamentals:

Volume: A directory accessible to the Pod's containers. Kubernetes supports many volume types (e.g., emptyDir, hostPath, cloud-provider-specific storage). Volumes are ephemeral with Pods, unless specifically configured.
PersistentVolume (PV): A piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned. It is a cluster resource.
PersistentVolumeClaim (PVC): A request for storage by a user. It consumes PV resources. PVCs are typically defined by developers in their application manifests.
StorageClass: Provides a way for administrators to describe the "classes" of storage they offer. When a PVC requests a specific StorageClass, dynamic provisioning can create a PV on demand.

Example: Requesting Persistent Storage

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard # Name of your StorageClass

This PVC requests 5GB of storage. A Pod would then mount this PVC to access the persistent storage.

Security & RBAC in Kubernetes

Security is paramount in any production environment. Understanding Kubernetes security features, especially Role-Based Access Control (RBAC), is critical for DevOps engineers.

Questions may include: How do you secure a Kubernetes cluster? What is RBAC? Explain Kubernetes Secrets and ConfigMaps.

Security Measures:

Role-Based Access Control (RBAC): Authorizes users and services to access API resources.
- Role/ClusterRole: Defines permissions (e.g., "can get Pods," "can create Deployments").
- RoleBinding/ClusterRoleBinding: Grants the defined permissions to a user, group, or service account.
Secrets: Used to store sensitive information like passwords, OAuth tokens, and SSH keys. Secrets are base64 encoded, not encrypted, by default.
ConfigMaps: Used to store non-sensitive configuration data in key-value pairs. They allow separation of configuration from application code.
Network Policies: Specifies how Pods are allowed to communicate with each other and other network endpoints.

Practical Action: A Simple Role and RoleBinding

# Role that allows reading pods
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
# RoleBinding to grant 'pod-reader' role to a ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: default # Name of the ServiceAccount to bind to
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Deployments, Scaling, & Updates

DevOps engineers are responsible for deploying applications reliably, scaling them as needed, and performing updates with minimal downtime. Kubernetes excels in these areas.

Possible questions: How do you perform a rolling update in Kubernetes? Explain Horizontal Pod Autoscaler (HPA). What is a ReplicaSet's role in scaling?

Deployment Management:

Rolling Update: The default update strategy for Deployments. It gradually replaces old Pods with new ones, ensuring no downtime during the update process.
Horizontal Pod Autoscaler (HPA): Automatically scales the number of Pod replicas in a Deployment or ReplicaSet based on observed CPU utilization or custom metrics.
ReplicaSet: As mentioned, manages the number of running Pods, crucial for scaling up or down manually or via HPA.
Rollback: Deployments keep a revision history, allowing you to easily revert to a previous working state if a new deployment introduces issues.

Example: Scaling a Deployment

To manually scale your Nginx Deployment to 5 replicas:

kubectl scale deployment/nginx-deployment --replicas=5

To update the image of your Nginx Deployment to a new version (triggering a rolling update):

kubectl set image deployment/nginx-deployment nginx=nginx:1.21.0

Monitoring, Logging, & Troubleshooting

A significant part of a DevOps engineer's job involves ensuring applications are healthy and quickly resolving issues. Kubernetes provides tools and patterns for this.

Interviewers might ask: How do you monitor applications in Kubernetes? What are Liveness and Readiness probes? How do you troubleshoot a Pod that isn't starting?

Observability & Diagnostics:

Liveness Probe: Determines if a container is running. If it fails, Kubernetes restarts the container. Prevents deadlocked applications from consuming resources.
Readiness Probe: Determines if a container is ready to serve requests. If it fails, the Pod is removed from Service endpoints, preventing traffic from being sent to it.
Logging: Kubernetes itself doesn't provide a comprehensive logging solution, but it enables easy integration with external logging tools (e.g., Fluentd, Loki, ELK stack) by writing logs to stdout/stderr.
Monitoring: Metrics are exposed via tools like Prometheus and Grafana. Kubernetes components themselves expose metrics (e.g., Kubelet).
kubectl commands: Essential for troubleshooting.
- kubectl get pod <pod-name> -o yaml: Detailed Pod configuration.
- kubectl describe pod <pod-name>: Events and status.
- kubectl logs <pod-name>: Container logs.
- kubectl exec -it <pod-name> -- /bin/bash: Shell into a container.

Example: Pod Health Probes

Adding liveness and readiness probes to your Nginx Deployment:

# ... inside your container spec ...
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

Frequently Asked Questions (FAQ)

Here are some quick answers to common Kubernetes interview questions for DevOps engineers.

Question	Answer
What is the main benefit of using Kubernetes in DevOps?	Kubernetes automates container orchestration, enabling faster deployments, consistent environments, efficient scaling, and improved application resilience, all crucial for DevOps success.
How do you ensure high availability for applications in Kubernetes?	High availability is achieved through multiple Pod replicas managed by Deployments, distributing Pods across different nodes, and using readiness/liveness probes to detect and mitigate failures.
What is the difference between a Secret and a ConfigMap?	Secrets store sensitive data (e.g., passwords), which are base64 encoded. ConfigMaps store non-sensitive configuration data. Both provide separation of configuration from application code.
Explain immutable infrastructure in the context of Kubernetes.	Immutable infrastructure means that once an environment (like a Pod) is deployed, it's never modified. Updates involve deploying new, identical environments and replacing the old ones, enhancing consistency and reliability.
How would you troubleshoot a Pod stuck in a Pending state?	Check resource availability (`kubectl describe pod <name>`, `kubectl get events`), node taints/tolerations, insufficient resources (CPU/memory), and correct image pull secrets.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the main benefit of using Kubernetes in DevOps?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Kubernetes automates container orchestration, enabling faster deployments, consistent environments, efficient scaling, and improved application resilience, all crucial for DevOps success."
      }
    },
    {
      "@type": "Question",
      "name": "How do you ensure high availability for applications in Kubernetes?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "High availability is achieved through multiple Pod replicas managed by Deployments, distributing Pods across different nodes, and using readiness/liveness probes to detect and mitigate failures."
      }
    },
    {
      "@type": "Question",
      "name": "What is the difference between a Secret and a ConfigMap?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Secrets store sensitive data (e.g., passwords), which are base64 encoded. ConfigMaps store non-sensitive configuration data. Both provide separation of configuration from application code."
      }
    },
    {
      "@type": "Question",
      "name": "Explain immutable infrastructure in the context of Kubernetes.",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Immutable infrastructure means that once an environment (like a Pod) is deployed, it's never modified. Updates involve deploying new, identical environments and replacing the old ones, enhancing consistency and reliability."
      }
    },
    {
      "@type": "Question",
      "name": "How would you troubleshoot a Pod stuck in a Pending state?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Check resource availability (kubectl describe pod <name>, kubectl get events), node taints/tolerations, insufficient resources (CPU/memory), and correct image pull secrets."
      }
    }
  ]
}

Search This Blog

Kubeify DevOps