Mastering Kubernetes : Essential Interview Questions

Mastering Kubernetes : Essential Interview Questions

1. What is Kubernetes and why is it important?

Kubernetes is an open-source container orchestration platform originally developed by Google and now maintained by the Cloud Native Computing Foundation (CNCF). It automates the deployment, scaling, and management of containerized applications across clusters of hosts.

The importance of Kubernetes can be understood through several key aspects:

Container Orchestration: Kubernetes excels at managing containerized applications at scale. It can handle hundreds or thousands of containers, ensuring they run as expected and maintaining their desired state.

High Availability: The platform automatically detects and responds to failures. If a container crashes or a node goes down, Kubernetes automatically reschedules the affected containers on healthy nodes, ensuring continuous application availability.

Scalability: Kubernetes provides both manual and automatic scaling capabilities. It can automatically adjust the number of running containers based on CPU utilization, memory usage, or custom metrics, ensuring optimal resource utilization and performance.

Declarative Configuration: You define the desired state of your applications using YAML files, and Kubernetes continuously works to maintain that state. This "declarative" approach simplifies application management and provides version control for your infrastructure.

Rich Ecosystem: The Kubernetes ecosystem includes numerous tools and plugins for networking, storage, security, and monitoring, making it extremely versatile for different use cases.

2. What is the difference between Docker Swarm and Kubernetes?

These container orchestration platforms differ in several significant ways:

Complexity and Setup:

Docker Swarm is designed for simplicity. It integrates natively with Docker and requires minimal additional configuration. Kubernetes, while more powerful, has a steeper learning curve and requires more initial setup and understanding.

Architecture:

Docker Swarm follows a simpler architecture with managers and workers. Kubernetes has a more complex architecture with components like the API server, scheduler, controller manager, and etcd, offering more fine-grained control but requiring more management overhead.

Scalability:

Kubernetes excels at managing large, complex deployments across thousands of containers and hundreds of nodes. Docker Swarm performs well for smaller deployments but may struggle with very large-scale operations.

Load Balancing:

Docker Swarm includes built-in load balancing that's easy to use out of the box. Kubernetes offers more sophisticated load balancing options, including integration with cloud providers and support for custom implementations.

Service Discovery:

Both platforms handle service discovery differently. Docker Swarm uses a built-in DNS component for service discovery. Kubernetes uses its Services abstraction and CoreDNS for more advanced service discovery and load balancing capabilities.

Updates and Rollbacks:

Kubernetes provides more sophisticated rolling update and rollback capabilities, with features like rolling updates, canary deployments, and automatic rollbacks. Docker Swarm offers basic rolling updates but with fewer configuration options.

3. How does Kubernetes handle network communication between containers?

Kubernetes implements a sophisticated networking model based on several key principles:

Pod Networking:

Every pod in a Kubernetes cluster receives its own unique IP address. This creates a flat networking space where pods can communicate directly with each other, regardless of their physical location in the cluster. This is implemented through Container Network Interface (CNI) plugins like Calico, Flannel, or Weave.

Service Networking:

Services in Kubernetes provide stable endpoints for pod-to-pod communication. Each service gets a stable IP address and DNS name, allowing pods to communicate reliably even as individual pods are created or destroyed. Services come in several types:

  • ClusterIP: For internal cluster communication

  • NodePort: For external access through node ports

  • LoadBalancer: For cloud provider load balancing

  • ExternalName: For DNS-based service discovery

Network Policies:

Kubernetes allows you to define Network Policies that act as a firewall, controlling which pods can communicate with each other and external endpoints. For example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

DNS Resolution:

CoreDNS runs within the cluster, providing DNS resolution for services and pods. This allows containers to find and communicate with each other using DNS names instead of IP addresses.

4. How does Kubernetes handle scaling of applications?

Kubernetes provides multiple sophisticated mechanisms for scaling applications:

Horizontal Pod Autoscaling (HPA):

HPA automatically adjusts the number of pod replicas based on observed metrics like CPU utilization, memory usage, or custom metrics. Here's an example HPA configuration:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Vertical Pod Autoscaling (VPA):

VPA automatically adjusts the CPU and memory resource requests and limits for containers in pods. This is useful when you want to automatically right-size your pods based on actual resource usage.

Cluster Autoscaling:

This mechanism works at the node level, automatically adding or removing nodes from your cluster based on resource demands. When pods can't be scheduled due to insufficient resources, the cluster autoscaler can provision new nodes.

Manual Scaling:

You can manually scale applications using kubectl commands:

kubectl scale deployment example-deployment --replicas=5

5. What is a Kubernetes Deployment and how does it differ from a ReplicaSet?

A Deployment is a higher-level abstraction that manages ReplicaSets and provides declarative updates to pods along with many other features. Here's how they differ:

Deployment Capabilities:

  • Manages ReplicaSets and provides declarative updates

  • Supports rolling updates and rollbacks

  • Maintains revision history

  • Allows pause and resume of updates

  • Provides status monitoring during updates

Example Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

ReplicaSet Capabilities:

  • Ensures a specified number of pod replicas are running

  • Provides pod template-based replication

  • Lacks update strategies and revision tracking

  • Typically managed by Deployments rather than directly

6. Can you explain the concept of rolling updates in Kubernetes?

Rolling updates allow you to update your application with zero downtime by gradually replacing old pods with new ones. Here's how they work:

Process:

  1. A new ReplicaSet is created with the updated pod template

  2. Pods are gradually scaled up in the new ReplicaSet

  3. Pods are gradually scaled down in the old ReplicaSet

  4. The process continues until all old pods are replaced

Configuration Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Maximum number of pods above desired count
      maxUnavailable: 1  # Maximum number of pods that can be unavailable

Control and Monitoring:

You can monitor the update progress using:

kubectl rollout status deployment/frontend

Rollback Capabilities:

If issues are detected, you can rollback:

kubectl rollout undo deployment/frontend

7. How does Kubernetes handle network security and access control?

Kubernetes provides multiple layers of security:

Network Policies:

These define how pods can communicate with each other and external endpoints. Example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

Role-Based Access Control (RBAC):

RBAC controls who can access what in your cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Service Accounts:

These provide identities for pods:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-service-account

8. Can you give an example of how Kubernetes can be used to deploy a highly available application?

Here's an example of a highly available application deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ha-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: webapp
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfied: DoNotSchedule
        labelSelector:
          matchLabels:
            app: webapp
      containers:
      - name: webapp
        image: webapp:1.0
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080

This configuration provides:

  • Multiple replicas across nodes

  • Health checking

  • Anti-affinity rules

  • Rolling updates

  • Auto-healing capabilities

9. What is namespace in Kubernetes? Which namespace does a pod take if we don't specify any namespace?

Namespaces are virtual clusters within a physical Kubernetes cluster. They provide a way to divide cluster resources between multiple users or projects.

Default Namespaces:

  • default: The default namespace for resources when none is specified

  • kube-system: For system components

  • kube-public: Publicly accessible data

  • kube-node-lease: For node lease information

Creating a Namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: development

When no namespace is specified, pods are created in the "default" namespace.

10. How does ingress help in Kubernetes?

Ingress manages external access to services in a cluster, typically HTTP/HTTPS traffic. It provides:

Features:

  • Load balancing

  • SSL termination

  • Name-based virtual hosting

  • Path-based routing

Example Ingress Configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

11. Explain different types of services in Kubernetes?

Kubernetes provides four types of services:

ClusterIP:

  • Default service type

  • Internal cluster communication only

  • Static cluster-internal IP

NodePort:

  • Exposes the service on each node's IP at a static port

  • Automatically creates ClusterIP service

  • Port range: 30000-32767

LoadBalancer:

  • Exposes service externally using cloud provider's load balancer

  • Automatically creates NodePort and ClusterIP services

ExternalName:

  • Maps service to external DNS name

  • No proxying, just DNS CNAME record

Example Service Configurations:

# ClusterIP
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: backend

# NodePort
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30080
  selector:
    app: web

# LoadBalancer
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: frontend

12. Can you explain the concept of self-healing in Kubernetes and give examples of how it works?

Self-healing in Kubernetes operates through several mechanisms:

Liveness Probes:

Detect if a container is running but unresponsive:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

Readiness Probes:

Determine if a container is ready to receive traffic:

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

ReplicaSet Controller:

Maintains desired number of pod replicas:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend

13. How does Kubernetes handle storage management for containers?

Kubernetes provides several abstractions for storage:

Persistent Volumes (PV):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-volume
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Persistent Volume Claims (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Storage Classes:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

14. How does the NodePort service work?

NodePort services expose applications on a static port on each node:

Configuration:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: NodePort
  ports:
  - port: 80        # Service port
    targetPort: 8080 # Container port
    nodePort: 30080 # External port
  selector:
    app: web

Features:

  • Accessible through :

  • Automatically creates ClusterIP service

  • Default port range: 30000-32767

  • Can specify custom nodePort

15. What is a multinode cluster and single-node cluster in Kubernetes?

Single-Node Cluster:

  • All components run on one machine

  • Suitable for development and testing

  • Example: Minikube, Docker Desktop Kubernetes

Multi-Node Cluster:

  • Distributed across multiple machines

  • Separate control plane and worker nodes

  • Suitable for production workloads

  • Better availability and scalability

Control Plane Components:

  • API Server

  • Scheduler

  • Controller Manager

  • etcd

Worker Node Components:

  • kubelet

  • kube-proxy

  • Container Runtime

16. Difference between create and apply in Kubernetes?

kubectl create and kubectl apply represent two fundamentally different approaches to resource management in Kubernetes:

kubectl create:

This is an imperative command that explicitly tells Kubernetes to create a new resource. Think of it like giving a direct order: "Create this specific thing right now."

Key characteristics:

# Example of create command
kubectl create deployment nginx --image=nginx

# Will fail if deployment already exists with error:
# Error from server (AlreadyExists): deployments.apps "nginx" already exists
  1. One-time Operation: It's designed for initial resource creation only

  2. No Update Support: Cannot update existing resources

  3. Strict Existence Check: Fails immediately if the resource already exists

  4. Simple and Direct: Good for quick testing or initial setup

  5. No Configuration Tracking: Doesn't store configuration details in resource annotations

kubectl apply:

This is a declarative command that tells Kubernetes: "Make sure this resource exists and looks exactly like this." It's more sophisticated and commonly used in production environments.

Example:

# deployment.yaml
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:1.14.2
# Apply the configuration
kubectl apply -f deployment.yaml

# Can be applied multiple times - will update if changes are made

Key characteristics:

  1. Configuration Management:

    • Stores the last-applied configuration in a resource annotation

    • Uses this to track changes and make updates

    • Enables three-way diffing (live state vs. file vs. last applied)

  2. Idempotent Operations:

    • Can be run multiple times safely

    • Will create resources if they don't exist

    • Will update resources if they exist and differ from the specification

  3. GitOps Friendly:

    • Works well with version-controlled configuration files

    • Supports infrastructure as code practices

    • Enables declarative configuration management

  4. Update Capabilities:

    • Can modify existing resources

    • Handles complex updates with multiple fields

    • Preserves fields not specified in the configuration

  5. Error Handling:

    • More forgiving than create

    • Will attempt to merge changes when possible

    • Provides detailed information about what changes were made

Best Practices:

  1. Use create for:

    • Quick testing and experimentation

    • One-time resource creation

    • Simple scenarios where you don't need to track changes

    • Interactive learning and demonstrations

  2. Use apply for:

    • Production environments

    • Configuration management through version control

    • Continuous deployment pipelines

    • Long-term resource management

    • When you need to maintain resource state over time

Example of the difference in practice:

# Using create - this will fail if the deployment exists
kubectl create deployment web --image=nginx

# Using apply - this will create or update as needed
kubectl apply -f deployment.yaml

# Making changes with apply
# Edit deployment.yaml to change replicas to 5

kubectl apply -f deployment.yaml  # Updates existing deployment smoothly

The key takeaway is that apply is more suitable for production environments and ongoing maintenance, while create is better for initial setup and testing scenarios. The choice between them often depends on your workflow and whether you need to manage resources over time or just create them once.

In modern Kubernetes operations, apply is generally preferred because it:

  • Supports GitOps workflows

  • Provides better tracking of changes

  • Enables declarative configuration

  • Offers more predictable and manageable updates

  • Works better with configuration files and version control

This makes it the recommended choice for most production scenarios and professional Kubernetes operations.