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:
A new ReplicaSet is created with the updated pod template
Pods are gradually scaled up in the new ReplicaSet
Pods are gradually scaled down in the old ReplicaSet
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
One-time Operation: It's designed for initial resource creation only
No Update Support: Cannot update existing resources
Strict Existence Check: Fails immediately if the resource already exists
Simple and Direct: Good for quick testing or initial setup
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:
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)
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
GitOps Friendly:
Works well with version-controlled configuration files
Supports infrastructure as code practices
Enables declarative configuration management
Update Capabilities:
Can modify existing resources
Handles complex updates with multiple fields
Preserves fields not specified in the configuration
Error Handling:
More forgiving than create
Will attempt to merge changes when possible
Provides detailed information about what changes were made
Best Practices:
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
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.