Kubernetes Core Concepts

What is a Pod?

A Pod is the smallest and simplest unit in Kubernetes. It represents a single instance of a running process in your cluster. A Pod can contain one or more containers that share storage, network, and specifications.

Pod Example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Common Commands:

# Create pod from YAML
kubectl apply -f pod.yaml

# Get pods
kubectl get pods

# Describe pod
kubectl describe pod nginx-pod

# Get pod logs
kubectl logs nginx-pod

# Delete pod
kubectl delete pod nginx-pod

What is a Deployment?

A Deployment provides declarative updates for Pods and ReplicaSets. It manages the lifecycle of your application, allowing you to scale, update, and rollback easily.

Deployment Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5

Deployment Operations:

# Scale deployment
kubectl scale deployment nginx-deployment --replicas=5

# Update image
kubectl set image deployment/nginx-deployment nginx=nginx:1.22

# Rollout status
kubectl rollout status deployment/nginx-deployment

# Rollback
kubectl rollout undo deployment/nginx-deployment

# View rollout history
kubectl rollout history deployment/nginx-deployment

What is a Service?

A Service is an abstraction that defines a logical set of Pods and a policy to access them. Services enable loose coupling between Pods and provide stable networking.

Service Types:

• ClusterIP - Default, internal cluster access only
• NodePort - Exposes service on each node's IP at a static port
• LoadBalancer - Exposes service externally using cloud provider's load balancer
• ExternalName - Maps service to external DNS name

Service Example:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

What is a ConfigMap?

A ConfigMap stores configuration data in key-value pairs. It allows you to decouple configuration from container images, making your application more portable.

Creating ConfigMap:

# From command line
kubectl create configmap app-config \
  --from-literal=key1=value1 \
  --from-literal=key2=value2

# From file
kubectl create configmap app-config --from-file=config.properties

# From YAML
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgresql://localhost:5432/mydb"
  log_level: "INFO"

Using ConfigMap in Pod:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: myapp:latest
    envFrom:
    - configMapRef:
        name: app-config
    # OR as volume
    volumeMounts:
    - name: config
      mountPath: /etc/config
  volumes:
  - name: config
    configMap:
      name: app-config

What is a Secret?

Secrets store sensitive data like passwords, OAuth tokens, and SSH keys. They are similar to ConfigMaps but specifically designed for sensitive information.

Creating Secrets:

# From command line
kubectl create secret generic db-secret \
  --from-literal=username=admin \
  --from-literal=password=secret123

# From file
kubectl create secret generic db-secret \
  --from-file=username.txt \
  --from-file=password.txt

# From YAML (base64 encoded)
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded
  password: c2VjcmV0MTIz

Using Secrets:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: myapp:latest
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: username
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password

What is a Volume?

Volumes provide persistent storage for Pods. Data survives container restarts and can be shared between containers in a Pod.

Volume Types:

• emptyDir - Temporary storage, deleted when Pod terminates
• hostPath - Mount directory from host node
• PersistentVolume (PV) - Cluster-level storage resource
• PersistentVolumeClaim (PVC) - User request for storage

PersistentVolumeClaim Example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

Using PVC in Pod:

apiVersion: v1
kind: Pod
metadata:
  name: db-pod
spec:
  containers:
  - name: db
    image: postgres:15
    volumeMounts:
    - name: db-storage
      mountPath: /var/lib/postgresql/data
  volumes:
  - name: db-storage
    persistentVolumeClaim:
      claimName: db-pvc

What is a Namespace?

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

Default Namespaces:

• default - Default namespace for objects
• kube-system - System components
• kube-public - Publicly accessible resources
• kube-node-lease - Node heartbeat objects

Working with Namespaces:

# Create namespace
kubectl create namespace production

# List namespaces
kubectl get namespaces

# Get resources in namespace
kubectl get pods -n production

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

# Create resource in specific namespace
kubectl apply -f deployment.yaml -n production

Namespace Resource Quota Example:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

What are Labels?

Labels are key-value pairs attached to Kubernetes objects. They are used to organize and select subsets of objects.

Label Example:

metadata:
  labels:
    app: nginx
    environment: production
    version: "1.21"
    tier: frontend

Using Selectors:

# Get pods by label
kubectl get pods -l app=nginx

# Get pods with multiple labels
kubectl get pods -l app=nginx,environment=production

# Get pods with label selector
kubectl get pods --selector='environment in (production,staging)'

What are Annotations?

Annotations are key-value pairs used to store metadata about objects. Unlike labels, annotations are not used for selection but for storing additional information.

Annotation Example:

metadata:
  annotations:
    description: "Nginx web server"
    contact: "[email protected]"
    last-modified: "2024-01-15T10:00:00Z"

Requests and Limits

Resource requests and limits help Kubernetes schedule Pods efficiently and prevent resource starvation.

Resource Example:

spec:
  containers:
  - name: app
    image: myapp:latest
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"      # 0.25 CPU
      limits:
        memory: "512Mi"
        cpu: "500m"      # 0.5 CPU

• requests - Minimum resources guaranteed
• limits - Maximum resources allowed