DevOps & Infrastructure

1. Containerization & Orchestration

Docker vs. Kubernetes

Both Docker and Kubernetes are essential in modern containerized application development, but they serve different purposes:

Feature	Docker	Kubernetes
Purpose	Containerization platform for packaging and running applications	Orchestration system for managing containerized applications
Container Management	Manages single containers	Manages multiple containers across clusters
Scaling	Manual scaling of containers	Automatic scaling based on resource usage
Networking	Built-in networking for containers	Advanced networking with Service Discovery
Storage	Persistent storage via volumes	Persistent storage via Persistent Volumes (PVs)
Load Balancing	Limited; requires additional tools	Built-in load balancing across Pods
Fault Tolerance	Containers may stop if they fail	Auto-restarts failed containers

Docker is used for containerizing applications.
Kubernetes is used to orchestrate and manage multiple containers in production.

👉 Best Practice: Use Docker to package applications and Kubernetes to manage them in a scalable and automated environment.

2. How Do You Scale Microservices with Kubernetes?

Scaling microservices in Kubernetes can be done using Horizontal Pod Autoscaler (HPA) or Vertical Pod Autoscaler (VPA).

Horizontal Scaling (HPA)

Kubernetes automatically increases/decreases the number of running Pods based on CPU, memory, or custom metrics.
Example:

 apiVersion: autoscaling/v2beta2
 kind: HorizontalPodAutoscaler
 metadata:
   name: my-app-hpa
 spec:
   scaleTargetRef:
     apiVersion: apps/v1
     kind: Deployment
     name: my-app
   minReplicas: 2
   maxReplicas: 10
   metrics:
   - type: Resource
     resource:
       name: cpu
       targetAverageUtilization: 50

Vertical Scaling (VPA)

Kubernetes adjusts the CPU and memory of each Pod automatically.
Example:

 apiVersion: autoscaling.k8s.io/v1
 kind: VerticalPodAutoscaler
 metadata:
   name: my-app-vpa
 spec:
   targetRef:
     apiVersion: "apps/v1"
     kind: Deployment
     name: my-app
   updatePolicy:
     updateMode: "Auto"

Cluster Autoscaler
- Ensures the number of nodes in the cluster scales up/down based on demand.

👉 Best Practice: Use HPA for dynamic scaling based on traffic and Cluster Autoscaler for efficient resource utilization.

3. What is a Sidecar Pattern in Kubernetes?

The Sidecar Pattern is a design pattern where an additional helper container runs alongside the main application container to handle auxiliary tasks.

Use Cases

Logging & Monitoring: A logging sidecar forwards logs to a centralized system.
Security & Authentication: A sidecar handles authentication without modifying the main app.
Proxying & Service Mesh: Sidecars like Envoy in Istio manage service-to-service communication.

Example of a Logging Sidecar

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app-container
    image: my-app:latest
  - name: log-collector
    image: fluentd:latest
    volumeMounts:
    - name: logs
      mountPath: /var/log
  volumes:
  - name: logs
    emptyDir: {}

👉 Best Practice: Use sidecars for cross-cutting concerns like logging, monitoring, and security.

4. How Do You Handle Zero-Downtime Deployments?

Zero-downtime deployment ensures that users are not affected while new versions are deployed.

Techniques

Rolling Updates (Kubernetes Default)

Replaces old Pods with new ones gradually.
Example:

 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: my-app
 spec:
   replicas: 3
   strategy:
     type: RollingUpdate
     rollingUpdate:
       maxUnavailable: 1
       maxSurge: 1

Blue-Green Deployment
- Runs two versions (Blue = Current, Green = New).
- Traffic switches from Blue to Green after testing.
Canary Deployment
- Releases new versions to a small percentage of users before full rollout.

👉 Best Practice: Use Rolling Updates for minor changes, Blue-Green for major changes, and Canary Deployment for risk mitigation.

5. CI/CD & Monitoring

How Do You Design a CI/CD Pipeline?

A CI/CD pipeline automates code integration, testing, and deployment.

Key Stages

Code Commit (Trigger: Git push)
Build & Compile (Docker image creation)
Unit & Integration Tests (JUnit, Selenium)
Security Scanning (Snyk, Trivy)
Deployment (Kubernetes, Helm)
Monitoring & Logging (Prometheus, ELK Stack)

Example: GitHub Actions CI/CD Pipeline

name: CI/CD Pipeline
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Build Docker Image
      run: docker build -t my-app .
    - name: Run Tests
      run: ./gradlew test
    - name: Deploy to Kubernetes
      run: kubectl apply -f deployment.yaml

👉 Best Practice: Use GitHub Actions, Jenkins, GitLab CI/CD, or ArgoCD.

6. How Does Blue-Green Deployment Work?

Blue = Old Version
Green = New Version

Deploy Green alongside Blue.
Test Green in production.
Switch traffic from Blue → Green.
If issues occur, rollback to Blue.

👉 Best Practice: Use Kubernetes Service routing for seamless transitions.

7. Best Practices for Logging in Microservices

Centralized Logging using ELK Stack (Elasticsearch, Logstash, Kibana) or Loki.
Structured Logs with JSON format.
Traceability with Correlation IDs.
Log Levels (INFO, WARN, ERROR, DEBUG).

👉 Best Practice: Use Fluentd, Logstash, or Promtail for log aggregation.

8. How Do You Monitor a Distributed System?

Metrics Collection
- Prometheus + Grafana for real-time monitoring.
- Custom metrics (CPU, memory, requests per second).
Distributed Tracing
- Jaeger or Zipkin to trace requests across microservices.
Log Aggregation
- ELK Stack or Loki for full-text search on logs.
Alerting
- Prometheus Alertmanager sends alerts via Slack, Email, or PagerDuty.