Containers and Orchestration Refersher

What are Containers?

Containers are lightweight, portable, executable packages that include everything needed to run an application: code, runtime, system tools, libraries, and settings. They provide consistent environments across development, testing, and production.

Containers vs Virtual Machines

Key Benefits

• Consistency: “Works on my machine” problem solved
• Portability: Run anywhere containers are supported
• Efficiency: Better resource utilization than VMs
• Scalability: Quick startup and lightweight
• DevOps: Simplified CI/CD pipelines

Docker Fundamentals

Core Components

1. Docker Image

Read-only template used to create containers. Built using layers.

1
# Example Dockerfile
2
FROM node:18-alpine
3
WORKDIR /app
4
COPY package*.json ./
5
RUN npm install
6
COPY . .
7
EXPOSE 3000
8
CMD ["npm", "start"]

2. Docker Container

Running instance of an image.

1
# Create and run container
2
docker run -d -p 3000:3000 --name myapp my-node-app
3

4
# List running containers
5
docker ps
6

7
# Stop container
8
docker stop myapp
9

10
# Remove container
11
docker rm myapp

3. Dockerfile

Text file with instructions to build an image.

1
# Multi-stage build example
2
FROM node:18-alpine AS builder
3
WORKDIR /app
4
COPY package*.json ./
5
RUN npm ci --only=production
6

7
FROM node:18-alpine AS runtime
8
WORKDIR /app
9
COPY --from=builder /app/node_modules ./node_modules
10
COPY . .
11
EXPOSE 3000
12
USER node
13
CMD ["npm", "start"]

4. Docker Registry

Storage and distribution system for Docker images.

1
# Pull image from registry
2
docker pull nginx:latest
3

4
# Tag image
5
docker tag myapp:latest myregistry.com/myapp:v1.0
6

7
# Push image to registry
8
docker push myregistry.com/myapp:v1.0

Docker Architecture

1
Docker Client → Docker Daemon → Containers
2
                     ↓           Images
3
                Docker Registry  Volumes
4
                                Networks

Docker Commands Reference

Image Management

1
# Build image
2
docker build -t myapp:latest .
3

4
# List images
5
docker images
6

7
# Remove image
8
docker rmi myapp:latest
9

10
# Image history
11
docker history myapp:latest
12

13
# Inspect image
14
docker inspect myapp:latest

Container Management

1
# Run container
2
docker run -d --name myapp -p 8080:80 nginx
3

4
# Execute command in running container
5
docker exec -it myapp /bin/bash
6

7
# View container logs
8
docker logs myapp
9

10
# Copy files to/from container
11
docker cp file.txt myapp:/path/to/destination
12

13
# Container stats
14
docker stats myapp

Volume Management

1
# Create volume
2
docker volume create myvolume
3

4
# List volumes
5
docker volume ls
6

7
# Mount volume
8
docker run -v myvolume:/data myapp
9

10
# Remove volume
11
docker volume rm myvolume

Network Management

1
# Create network
2
docker network create mynetwork
3

4
# List networks
5
docker network ls
6

7
# Connect container to network
8
docker network connect mynetwork myapp
9

10
# Inspect network
11
docker network inspect mynetwork

Docker Compose

Multi-Container Applications

Define and run multi-container applications using YAML.

1
version: '3.8'
2

3
services:
4
  web:
5
    build: .
6
    ports:
7
      - "3000:3000"
8
    environment:
9
      - NODE_ENV=production
10
    depends_on:
11
      - db
12
      - redis
13
    volumes:
14
      - ./logs:/app/logs
15
    networks:
16
      - app-network
17

18
  db:
19
    image: postgres:13
20
    environment:
21
      - POSTGRES_DB=myapp
22
      - POSTGRES_USER=user
23
      - POSTGRES_PASSWORD=password
24
    volumes:
25
      - postgres_data:/var/lib/postgresql/data
26
    networks:
27
      - app-network
28

29
  redis:
30
    image: redis:alpine
31
    ports:
32
      - "6379:6379"
33
    networks:
34
      - app-network
35

36
volumes:
37
  postgres_data:
38

39
networks:
40
  app-network:
41
    driver: bridge

Compose Commands

1
# Start services
2
docker-compose up -d
3

4
# Stop services
5
docker-compose down
6

7
# View logs
8
docker-compose logs -f
9

10
# Scale service
11
docker-compose scale web=3
12

13
# Build services
14
docker-compose build
15

16
# Execute command
17
docker-compose exec web bash

Container Best Practices

Dockerfile Optimization

1. Use Multi-Stage Builds

1
# Build stage
2
FROM node:18 AS builder
3
WORKDIR /app
4
COPY package*.json ./
5
RUN npm ci --only=production
6

7
# Runtime stage
8
FROM node:18-alpine
9
WORKDIR /app
10
COPY --from=builder /app/node_modules ./node_modules
11
COPY . .
12
USER node
13
CMD ["npm", "start"]

2. Minimize Layers

1
# Bad - Multiple layers
2
RUN apt-get update
3
RUN apt-get install -y curl
4
RUN apt-get install -y vim
5

6
# Good - Single layer
7
RUN apt-get update && \
8
    apt-get install -y curl vim && \
9
    apt-get clean && \
10
    rm -rf /var/lib/apt/lists/*

3. Use .dockerignore

1
node_modules
2
npm-debug.log
3
.git
4
.gitignore
5
README.md
6
.env
7
coverage

4. Run as Non-Root User

1
FROM node:18-alpine
2
RUN addgroup -g 1001 -S nodejs
3
RUN adduser -S nextjs -u 1001
4
USER nextjs

Security Best Practices

1. Use Official Base Images

1
# Prefer official images
2
FROM node:18-alpine
3
# Over custom or unknown images
4
FROM some-random-user/node

2. Keep Images Updated

1
# Use specific versions, not latest
2
FROM node:18.17.0-alpine

3. Scan for Vulnerabilities

1
# Docker vulnerability scanning
2
docker scan myapp:latest
3

4
# Trivy scanning
5
trivy image myapp:latest

4. Limit Container Capabilities

1
# Run with limited capabilities
2
docker run --cap-drop=ALL --cap-add=NET_ADMIN myapp

Container Orchestration

Why Orchestration?

• Service Discovery: Find and connect services
• Load Balancing: Distribute traffic across instances
• Auto-scaling: Scale based on demand
• Health Checks: Monitor and restart failed containers
• Rolling Updates: Deploy without downtime
• Resource Management: CPU and memory allocation

Kubernetes (K8s)

Core Concepts

Cluster Architecture

1
Master Node (Control Plane)
2
├─ API Server
3
├─ etcd (Key-Value Store)
4
├─ Scheduler
5
└─ Controller Manager
6

7
Worker Nodes
8
├─ kubelet
9
├─ kube-proxy
10
└─ Container Runtime (Docker/containerd)

Key Objects

1. Pod

Smallest deployable unit, contains one or more containers.

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: my-pod
5
spec:
6
  containers:
7
  - name: web
8
    image: nginx:1.20
9
    ports:
10
    - containerPort: 80
11
  - name: sidecar
12
    image: busybox
13
    command: ['sh', '-c', 'sleep 3600']

2. Deployment

Manages ReplicaSets and provides declarative updates.

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: web-deployment
5
spec:
6
  replicas: 3
7
  selector:
8
    matchLabels:
9
      app: web
10
  template:
11
    metadata:
12
      labels:
13
        app: web
14
    spec:
15
      containers:
16
      - name: web
17
        image: nginx:1.20
18
        ports:
19
        - containerPort: 80
20
        resources:
21
          requests:
22
            memory: "64Mi"
23
            cpu: "250m"
24
          limits:
25
            memory: "128Mi"
26
            cpu: "500m"

3. Service

Exposes pods to network traffic.

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: web-service
5
spec:
6
  selector:
7
    app: web
8
  ports:
9
    - protocol: TCP
10
      port: 80
11
      targetPort: 80
12
  type: ClusterIP  # ClusterIP, NodePort, LoadBalancer

4. ConfigMap

Stores configuration data.

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: app-config
5
data:
6
  database_url: "postgresql://localhost:5432/mydb"
7
  debug: "true"

5. Secret

Stores sensitive data.

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: app-secret
5
type: Opaque
6
data:
7
  username: dXNlcm5hbWU=  # base64 encoded
8
  password: cGFzc3dvcmQ=  # base64 encoded

6. Ingress

Manages external access to services.

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: web-ingress
5
spec:
6
  rules:
7
  - host: myapp.example.com
8
    http:
9
      paths:
10
      - path: /
11
        pathType: Prefix
12
        backend:
13
          service:
14
            name: web-service
15
            port:
16
              number: 80

Kubernetes Commands

Cluster Management

1
# Cluster info
2
kubectl cluster-info
3

4
# Node status
5
kubectl get nodes
6

7
# Cluster events
8
kubectl get events

Pod Management

1
# List pods
2
kubectl get pods
3

4
# Pod details
5
kubectl describe pod my-pod
6

7
# Pod logs
8
kubectl logs my-pod
9

10
# Execute command in pod
11
kubectl exec -it my-pod -- /bin/bash
12

13
# Port forwarding
14
kubectl port-forward pod/my-pod 8080:80

Deployment Management

1
# Create deployment
2
kubectl create deployment web --image=nginx
3

4
# Apply YAML file
5
kubectl apply -f deployment.yaml
6

7
# Scale deployment
8
kubectl scale deployment web --replicas=5
9

10
# Rolling update
11
kubectl set image deployment/web web=nginx:1.21
12

13
# Rollback
14
kubectl rollout undo deployment/web
15

16
# Deployment status
17
kubectl rollout status deployment/web

Service Management

1
# Expose deployment
2
kubectl expose deployment web --port=80 --type=LoadBalancer
3

4
# List services
5
kubectl get services
6

7
# Service endpoints
8
kubectl get endpoints

Advanced Kubernetes Concepts

1. Namespaces

Logical isolation within cluster.

1
apiVersion: v1
2
kind: Namespace
3
metadata:
4
  name: production

1
# Create namespace
2
kubectl create namespace production
3

4
# List resources in namespace
5
kubectl get pods -n production
6

7
# Set default namespace
8
kubectl config set-context --current --namespace=production

2. Resource Quotas

Limit resource consumption.

1
apiVersion: v1
2
kind: ResourceQuota
3
metadata:
4
  name: compute-quota
5
  namespace: production
6
spec:
7
  hard:
8
    requests.cpu: "4"
9
    requests.memory: 8Gi
10
    limits.cpu: "8"
11
    limits.memory: 16Gi
12
    pods: "10"

3. Horizontal Pod Autoscaler (HPA)

Automatically scale pods based on metrics.

1
apiVersion: autoscaling/v2
2
kind: HorizontalPodAutoscaler
3
metadata:
4
  name: web-hpa
5
spec:
6
  scaleTargetRef:
7
    apiVersion: apps/v1
8
    kind: Deployment
9
    name: web-deployment
10
  minReplicas: 2
11
  maxReplicas: 10
12
  metrics:
13
  - type: Resource
14
    resource:
15
      name: cpu
16
      target:
17
        type: Utilization
18
        averageUtilization: 70

4. Persistent Volumes

Manage storage.

1
# Persistent Volume
2
apiVersion: v1
3
kind: PersistentVolume
4
metadata:
5
  name: my-pv
6
spec:
7
  capacity:
8
    storage: 10Gi
9
  accessModes:
10
    - ReadWriteOnce
11
  persistentVolumeReclaimPolicy: Retain
12
  storageClassName: standard
13
  hostPath:
14
    path: /data
15

16
---
17
# Persistent Volume Claim
18
apiVersion: v1
19
kind: PersistentVolumeClaim
20
metadata:
21
  name: my-pvc
22
spec:
23
  accessModes:
24
    - ReadWriteOnce
25
  resources:
26
    requests:
27
      storage: 5Gi
28
  storageClassName: standard

5. StatefulSets

For stateful applications.

1
apiVersion: apps/v1
2
kind: StatefulSet
3
metadata:
4
  name: database
5
spec:
6
  serviceName: "database"
7
  replicas: 3
8
  selector:
9
    matchLabels:
10
      app: database
11
  template:
12
    metadata:
13
      labels:
14
        app: database
15
    spec:
16
      containers:
17
      - name: postgres
18
        image: postgres:13
19
        ports:
20
        - containerPort: 5432
21
        volumeMounts:
22
        - name: data
23
          mountPath: /var/lib/postgresql/data
24
  volumeClaimTemplates:
25
  - metadata:
26
      name: data
27
    spec:
28
      accessModes: ["ReadWriteOnce"]
29
      resources:
30
        requests:
31
          storage: 10Gi

Container Security

1. Image Security

1
# Scan image for vulnerabilities
2
docker scan nginx:latest
3

4
# Use distroless images
5
FROM gcr.io/distroless/java:11
6

7
# Multi-stage builds to reduce attack surface
8
FROM maven:3.8-openjdk-11 AS build
9
# ... build steps ...
10
FROM gcr.io/distroless/java:11
11
COPY --from=build /app/target/app.jar /app.jar

2. Runtime Security

1
# Security Context
2
apiVersion: v1
3
kind: Pod
4
spec:
5
  securityContext:
6
    runAsNonRoot: true
7
    runAsUser: 1000
8
    fsGroup: 2000
9
  containers:
10
  - name: app
11
    securityContext:
12
      allowPrivilegeEscalation: false
13
      readOnlyRootFilesystem: true
14
      capabilities:
15
        drop:
16
        - ALL

3. Network Policies

1
apiVersion: networking.k8s.io/v1
2
kind: NetworkPolicy
3
metadata:
4
  name: deny-all
5
spec:
6
  podSelector: {}
7
  policyTypes:
8
  - Ingress
9
  - Egress

4. Pod Security Standards

1
apiVersion: v1
2
kind: Namespace
3
metadata:
4
  name: secure-namespace
5
  labels:
6
    pod-security.kubernetes.io/enforce: restricted
7
    pod-security.kubernetes.io/audit: restricted
8
    pod-security.kubernetes.io/warn: restricted

Container Monitoring & Logging

Monitoring Stack

1. Prometheus + Grafana

1
# Prometheus ConfigMap
2
apiVersion: v1
3
kind: ConfigMap
4
metadata:
5
  name: prometheus-config
6
data:
7
  prometheus.yml: |
8
    global:
9
      scrape_interval: 15s
10
    scrape_configs:
11
    - job_name: 'kubernetes-pods'
12
      kubernetes_sd_configs:
13
      - role: pod

2. Metrics Collection

1
# Install metrics-server
2
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
3

4
# View resource usage
5
kubectl top nodes
6
kubectl top pods

Logging

1. Centralized Logging (ELK Stack)

1
# Fluentd DaemonSet for log collection
2
apiVersion: apps/v1
3
kind: DaemonSet
4
metadata:
5
  name: fluentd
6
spec:
7
  selector:
8
    matchLabels:
9
      name: fluentd
10
  template:
11
    spec:
12
      containers:
13
      - name: fluentd
14
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch
15
        volumeMounts:
16
        - name: varlog
17
          mountPath: /var/log
18
        - name: varlibdockercontainers
19
          mountPath: /var/lib/docker/containers
20
          readOnly: true

2. Application Logging

1
# Structured logging in container
2
FROM node:18-alpine
3
COPY . .
4
# Application logs to stdout/stderr
5
CMD ["node", "app.js"]

Alternative Orchestration Platforms

1. Docker Swarm

1
# Initialize swarm
2
docker swarm init
3

4
# Create service
5
docker service create --name web --replicas 3 -p 80:80 nginx
6

7
# Scale service
8
docker service scale web=5
9

10
# Update service
11
docker service update --image nginx:1.21 web

2. Amazon ECS

1
{
2
  "family": "web-app",
3
  "networkMode": "awsvpc",
4
  "cpu": "256",
5
  "memory": "512",
6
  "containerDefinitions": [
7
    {
8
      "name": "web",
9
      "image": "nginx:latest",
10
      "portMappings": [
11
        {
12
          "containerPort": 80,
13
          "protocol": "tcp"
14
        }
15
      ]
16
    }
17
  ]
18
}

3. HashiCorp Nomad

1
job "web" {
2
  datacenters = ["dc1"]
3
  type = "service"
4

5
  group "web" {
6
    count = 3
7

8
    task "nginx" {
9
      driver = "docker"
10
      config {
11
        image = "nginx:latest"
12
        ports = ["http"]
13
      }
14

15
      resources {
16
        cpu    = 500
17
        memory = 256
18
      }
19
    }
20
  }
21
}

CI/CD with Containers

Build Pipeline

1
# GitHub Actions example
2
name: Build and Deploy
3
on:
4
  push:
5
    branches: [main]
6

7
jobs:
8
  build:
9
    runs-on: ubuntu-latest
10
    steps:
11
    - uses: actions/checkout@v2
12

13
    - name: Build Docker image
14
      run: docker build -t myapp:${{ github.sha }} .
15

16
    - name: Run tests
17
      run: docker run --rm myapp:${{ github.sha }} npm test
18

19
    - name: Push to registry
20
      run: |
21
        docker tag myapp:${{ github.sha }} myregistry.com/myapp:${{ github.sha }}
22
        docker push myregistry.com/myapp:${{ github.sha }}
23

24
    - name: Deploy to Kubernetes
25
      run: |
26
        kubectl set image deployment/myapp app=myregistry.com/myapp:${{ github.sha }}

GitOps with ArgoCD

1
apiVersion: argoproj.io/v1alpha1
2
kind: Application
3
metadata:
4
  name: myapp
5
spec:
6
  source:
7
    repoURL: https://github.com/myorg/myapp-config
8
    path: kubernetes
9
    targetRevision: HEAD
10
  destination:
11
    server: https://kubernetes.default.svc
12
    namespace: production
13
  syncPolicy:
14
    automated:
15
      prune: true
16
      selfHeal: true

Interview Questions and Answers

Q1: What is the difference between a container and a virtual machine?

A1: Containers share the host OS kernel and isolate at the process level, making them lightweight (MBs) with second-level startup times. Virtual machines include a full OS, requiring a hypervisor, making them heavy (GBs) with minute-level startup times. Containers provide process-level isolation while VMs provide hardware-level isolation. Containers are more portable and efficient but VMs offer stronger isolation.

Q2: Explain Docker architecture and its main components.

A2: Docker uses a client-server architecture:

• Docker Client: CLI that sends commands to Docker daemon
• Docker Daemon: Background service that manages containers, images, volumes, and networks
• Docker Registry: Storage for Docker images (e.g., Docker Hub)
• Docker Images: Read-only templates with layers
• Docker Containers: Running instances of images

The client communicates with the daemon via REST API, and the daemon pulls images from registries and manages container lifecycle.

Q3: What is a Dockerfile and how does layering work?

A3: A Dockerfile is a text file containing instructions to build a Docker image. Each instruction (FROM, RUN, COPY, etc.) creates a new layer. Layers are cached and reused, making builds faster. For example:

1
FROM node:18        # Layer 1
2
WORKDIR /app        # Layer 2
3
COPY package.json   # Layer 3
4
RUN npm install     # Layer 4
5
COPY . .           # Layer 5

Only changed layers and subsequent layers are rebuilt. This makes Docker builds efficient.

Q4: What is the difference between CMD and ENTRYPOINT in Dockerfile?

A4:

• CMD: Provides default arguments that can be overridden at runtime. Used for default commands.
• ENTRYPOINT: Defines the executable that always runs. Arguments are appended to it.

Example:

1
ENTRYPOINT ["python"]
2
CMD ["app.py"]

Running docker run myapp test.py executes python test.py (CMD overridden), but the ENTRYPOINT remains. Best practice: use ENTRYPOINT for the executable and CMD for default arguments.

Q5: Explain multi-stage builds and their benefits.

A5: Multi-stage builds use multiple FROM statements in a Dockerfile, allowing you to separate build and runtime environments. Benefits:

• Smaller final images: Build tools aren’t included in final image
• Better security: Fewer attack vectors
• Cleaner separation: Build stage separate from runtime

Example: Use a full Node.js image to build, then copy only the build artifacts to a smaller Alpine image.

Q6: What are Docker volumes and why are they important?

A6: Docker volumes are persistent storage mechanisms that exist outside the container filesystem. They’re important because:

• Data persistence: Data survives container deletion
• Sharing data: Multiple containers can share volumes
• Performance: Better I/O performance than bind mounts
• Backup/restore: Easier to backup and migrate

Types: Named volumes (managed by Docker), bind mounts (host filesystem path), and tmpfs (memory-only).

Q7: What is Docker Compose and when would you use it?

A7: Docker Compose is a tool for defining and running multi-container applications using YAML files. Use it when:

• Running multiple related containers (web app + database + cache)
• Need to define service dependencies
• Want reproducible development environments
• Need to manage container configuration as code

It simplifies starting/stopping entire application stacks with single commands (docker-compose up/down).

Q8: Explain the concept of a Kubernetes Pod.

A8: A Pod is the smallest deployable unit in Kubernetes, containing one or more tightly coupled containers that share:

• Network namespace: Same IP address and port space
• Storage volumes: Shared volumes
• Lifecycle: Started/stopped together

Pods are ephemeral and designed to run a single instance of an application. Multiple containers in a pod typically include a main container and helper “sidecar” containers for logging, monitoring, or proxying.

Q9: What is a Kubernetes Deployment and what advantages does it provide?

A9: A Deployment is a Kubernetes object that manages ReplicaSets and provides declarative updates for Pods. Advantages:

• Desired state management: Maintains specified number of replicas
• Rolling updates: Zero-downtime deployments
• Rollback capability: Revert to previous versions
• Scaling: Easy horizontal scaling
• Self-healing: Automatically replaces failed pods

Deployments are ideal for stateless applications.

Q10: What is the difference between a Deployment and a StatefulSet?

A10: Deployment:

• For stateless applications
• Pods are interchangeable
• Random pod names (web-7d4f8-xyz)
• No guaranteed ordering
• Shared storage

StatefulSet:

• For stateful applications (databases)
• Pods have unique identities
• Predictable names (db-0, db-1, db-2)
• Ordered creation/deletion
• Dedicated storage per pod

Use StatefulSets when pods need stable network identities or persistent storage.

Q11: Explain Kubernetes Services and their types.

A11: A Service exposes Pods to network traffic and provides stable endpoints. Types:

• ClusterIP (default): Internal-only access within cluster
• NodePort: Exposes service on each node’s IP at a static port
• LoadBalancer: Creates external load balancer (cloud providers)
• ExternalName: Maps service to external DNS name

Services use label selectors to route traffic to matching Pods, providing load balancing and service discovery.

Q12: What are ConfigMaps and Secrets? When would you use each?

A12: ConfigMap: Stores non-sensitive configuration data (database URLs, feature flags, config files) Secret: Stores sensitive data (passwords, API keys, certificates) - base64 encoded

Use ConfigMap for environment-specific settings. Use Secrets for credentials and sensitive data. Both can be injected as environment variables or mounted as volumes. Secrets offer additional protection through encryption at rest (when configured).

Q13: What is a Kubernetes Namespace and why use it?

A13: Namespaces provide logical isolation within a cluster, creating virtual clusters. Benefits:

• Resource isolation: Separate dev, staging, production
• Access control: Apply RBAC policies per namespace
• Resource quotas: Limit CPU/memory per namespace
• Organization: Group related resources

Default namespaces: default, kube-system, kube-public, kube-node-lease. Create custom namespaces for multi-tenancy and environment separation.

Q14: Explain Kubernetes Ingress and how it differs from a Service.

A14: Service: Layer 4 (TCP/UDP) load balancing, internal routing Ingress: Layer 7 (HTTP/HTTPS) routing, external access management

Ingress provides:

• Path-based routing: /api → service-a, /web → service-b
• Host-based routing: api.example.com → service-a
• TLS termination: SSL/TLS certificate management
• Single entry point: One load balancer for multiple services

Requires an Ingress Controller (nginx, traefik, etc.) to function.

Q15: What is a DaemonSet and when would you use it?

A15: A DaemonSet ensures a copy of a Pod runs on all (or selected) nodes. Use cases:

• Log collection: Fluentd/Filebeat on every node
• Monitoring agents: Prometheus node exporters
• Network plugins: CNI agents
• Storage daemons: Ceph, GlusterFS agents

When a node joins the cluster, the DaemonSet automatically schedules a Pod on it. Ideal for node-level services.

Q16: Explain Kubernetes resource requests and limits.

A16: Requests: Minimum guaranteed resources (used for scheduling) Limits: Maximum resources a container can use (enforced)

1
resources:
2
  requests:
3
    memory: "64Mi"
4
    cpu: "250m"
5
  limits:
6
    memory: "128Mi"
7
    cpu: "500m"

• Container uses requests for scheduling decisions
• Exceeding memory limit → pod killed (OOMKilled)
• Exceeding CPU limit → throttled, not killed
• Set requests based on typical usage, limits for safety

Q17: What is a Horizontal Pod Autoscaler (HPA)?

A17: HPA automatically scales the number of Pods based on observed metrics (CPU, memory, or custom metrics). It:

• Monitors metrics via Metrics Server
• Compares current vs target utilization
• Adjusts replica count within min/max bounds
• Rechecks every 15 seconds (default)

Example: Scale from 2-10 replicas when CPU exceeds 70%. HPA prevents manual scaling and handles traffic spikes automatically. Requires resource requests to be defined.

Q18: What are liveness and readiness probes in Kubernetes?

A18: Liveness Probe: Checks if container is alive. If fails, kubelet kills and restarts container. Readiness Probe: Checks if container is ready to serve traffic. If fails, removes pod from service endpoints.

Types: HTTP GET, TCP Socket, Exec command

Example use: Liveness ensures hung app restarts; Readiness ensures traffic only goes to fully initialized pods. Don’t confuse them - liveness restarts, readiness gates traffic.

Q19: What is the difference between a .dockerignore and .gitignore?

A19: .dockerignore: Excludes files from Docker build context (sent to daemon) .gitignore: Excludes files from Git repository

.dockerignore improves build performance by reducing context size. Common entries:

1
node_modules
2
.git
3
*.md
4
.env
5
coverage/

Smaller build context = faster uploads to daemon, faster builds, smaller images (if files would be COPYied).

Q20: Explain Docker networking modes.

A20: Docker networking modes:

• Bridge (default): Private network, containers communicate via internal IPs
• Host: Container shares host network namespace, no isolation
• None: No networking, isolated container
• Overlay: Multi-host networking for Swarm/Kubernetes
• Macvlan: Assigns MAC address, container appears as physical device

Use bridge for most cases, host for performance (bypasses NAT), overlay for multi-host orchestration.

Q21: What is a Kubernetes PersistentVolume (PV) and PersistentVolumeClaim (PVC)?

A21: PersistentVolume (PV): Cluster resource representing storage (admin creates) PersistentVolumeClaim (PVC): Request for storage by user (pod uses)

Workflow:

1. Admin creates PV with capacity/access modes
2. User creates PVC requesting storage
3. Kubernetes binds PVC to matching PV
4. Pod references PVC in volume mount

Decouples storage provisioning from consumption. Supports dynamic provisioning via StorageClasses.

Q22: What are Init Containers in Kubernetes?

A22: Init Containers run before app containers in a Pod, completing before app containers start. Use cases:

• Wait for dependencies: Check if database is ready
• Setup tasks: Clone git repo, download config
• Security: Fetch secrets, set permissions

Multiple init containers run sequentially. If any fails, kubelet restarts the Pod. Main containers only start after all init containers succeed.

Q23: Explain Kubernetes RBAC (Role-Based Access Control).

A23: RBAC controls who can access which resources. Components:

• Role/ClusterRole: Defines permissions (verbs: get, list, create, delete)
• RoleBinding/ClusterRoleBinding: Grants role to users/groups/service accounts
• ServiceAccount: Identity for pods

Role is namespace-scoped; ClusterRole is cluster-wide. Example: Give developer read-only access to pods in dev namespace. RBAC follows principle of least privilege.

Q24: What is a sidecar container pattern?

A24: A sidecar container runs alongside the main container in the same Pod, sharing resources. Common patterns:

• Logging: Sidecar collects and forwards logs
• Monitoring: Exports metrics from main container
• Proxy: Envoy sidecar for service mesh
• Data synchronization: Syncs files between containers

Example: Web server (main) + log shipper (sidecar). Sidecars extend functionality without modifying main application.

Q25: What is container orchestration and why is it needed?

A25: Container orchestration automates deployment, scaling, networking, and management of containerized applications. Needed for:

• High availability: Automatic restarts and failover
• Scaling: Handle increased load automatically
• Load balancing: Distribute traffic across instances
• Service discovery: Containers find each other
• Rolling updates: Zero-downtime deployments
• Resource management: Optimal container placement

Without orchestration, managing hundreds of containers manually is impractical. Kubernetes, Docker Swarm, and ECS are popular orchestrators.

Q26: What are Kubernetes labels and selectors?

A26: Labels: Key-value pairs attached to objects for organization Selectors: Query labels to identify resources

1
labels:
2
  app: web
3
  environment: production
4
  version: v1.2

Selectors filter objects: app=web,environment=production

Services use selectors to route traffic to pods. Deployments use them to manage pods. Labels enable loose coupling - change labels to redirect traffic without modifying pods.

Q27: Explain the concept of immutable infrastructure with containers.

A27: Immutable infrastructure means containers are never modified after deployment - replaced entirely with new versions. Benefits:

• Consistency: Eliminates configuration drift
• Reliability: Same image across environments
• Easy rollback: Redeploy previous image
• Security: No runtime patches, rebuild instead

Instead of SSH into container and patching, build new image with fix and deploy. Containers are cattle, not pets.

Q28: What is a Kubernetes Job and CronJob?

A28: Job: Runs pods to completion, ensures specified number of successful completions CronJob: Runs Jobs on a schedule (cron syntax)

Use cases:

• Job: Data migration, batch processing, one-time tasks
• CronJob: Scheduled backups, report generation, cleanup tasks

1
schedule: "0 2 * * *"  # Daily at 2 AM

Jobs handle retries and parallelism. CronJobs create Jobs at scheduled times.

Q29: What are Kubernetes Taints and Tolerations?

A29: Mechanism to control pod scheduling on nodes:

Taint: Applied to nodes, repels pods without matching toleration Toleration: Applied to pods, allows (but doesn’t require) scheduling on tainted nodes

Use cases:

• Dedicated nodes for specific workloads (GPU nodes)
• Isolate production from dev
• Prevent scheduling on nodes with issues

Effects: NoSchedule, PreferNoSchedule, NoExecute

Example: Taint GPU nodes, only pods with GPU toleration can schedule there.

Q30: What are the benefits of using multi-stage builds in Docker?

A30: Multi-stage builds create smaller, more secure images by separating build and runtime:

Benefits:

• Smaller images: 500MB build image → 50MB final image (10x reduction)
• Improved security: No build tools in production image
• Single Dockerfile: No need for separate build/runtime Dockerfiles
• Faster deployments: Smaller images transfer faster
• Better layer caching: Build dependencies cached separately

Example: Compile Go app in builder stage (has compiler), copy binary to scratch image (no OS). Final image is ~10MB vs ~800MB with build tools.