Kubernetes Basics

Essential Kubernetes for container orchestration

Deployment and Service Example

Download the YAML configuration files for the deployment and service examples

Create V1 Deployment

kubectl create -f hello-dep-v1.yaml

Creates the V1 deployment with 3 replicas of the hello-app:1.0 container.

Create ClusterIP Service

kubectl create -f clusterip.yaml

Creates a ClusterIP service that points to the V1 deployment pods.

Get Pods List

kubectl get pods -o wide

Displays the list of pods with additional details including IP addresses and nodes.

Port Forward to Service

kubectl port-forward service/svc-front 8080:8080

Forwards local port 8080 to the service's port 8080. Open browser to http://localhost:8080 to see V1 app.

Create V2 Deployment

kubectl create -f hello-dep-v2.yaml

Creates the V2 deployment with 3 replicas of the hello-app:2.0 container.

Get Pods List

kubectl get pods -o wide

Displays the list of pods with additional details including IP addresses and nodes.

Update ClusterIP Service

kubectl apply -f clusterip.yaml

After editing clusterip.yaml to change selector to app: hello-v2, apply the updated configuration.

Port Forward to Service

kubectl port-forward service/svc-front 8080:8080

Forwards local port 8080 to the service's port 8080. Open browser to http://localhost:8080 to see V1 app.

Cleanup V1

kubectl delete -f hello-dep-v1.yaml

Deletes the V1 deployment and its resources.

Cleanup V2

kubectl delete -f hello-dep-v2.yaml

Deletes the V2 deployment.

Cleanup Service

kubectl delete -f clusterip.yaml

Delete the ClusterIP service.

YAML Configuration Files

clusterip.yaml

apiVersion: v1
kind: Service
metadata:
  name: svc-front
spec:
  ports:
  - port: 8080
    targetPort: 8080
  selector:
    app: hello-v1

Service Configuration Explanation:

Service Structure:

  • apiVersion: v1 → Specifies the Kubernetes API version for Service
  • kind: Service → Defines this as a Service resource
  • metadata.name: svc-front → Names the service "svc-front"

Service Specification:

  • ports → Defines port mapping
  • port: 8080 → Service exposes port 8080
  • targetPort: 8080 → Pods listen on port 8080
  • selector.app: hello-v1 → Service routes traffic to pods with label app=hello-v1

How It Works:

The ClusterIP service provides internal load balancing for pods with the matching label. It creates a stable IP address that other services can use to communicate with the pods. By changing the selector to app: hello-v2, you can redirect traffic from V1 to V2 pods without changing the service endpoint.

hello-dep-v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-v1
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: hello-v1
  template:
    metadata:
      labels:
        app: hello-v1
    spec:
      containers:
      - image: guybarrette/hello-app:1.0
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 250m
            memory: 256Mi      
        imagePullPolicy: Always
        name: hello-v1
        ports:
        - containerPort: 8080

Deployment Configuration Explanation:

Deployment Structure:

  • apiVersion: apps/v1 → Specifies the Kubernetes API version for Deployment
  • kind: Deployment → Defines this as a Deployment resource
  • metadata.name: hello-v1 → Names the deployment "hello-v1"

Deployment Specification:

  • replicas: 3 → Maintains 3 pod instances
  • strategy.type: RollingUpdate → Uses rolling update for deployments
  • maxSurge: 1 → Can create 1 extra pod during updates
  • maxUnavailable: 1 → Can have 1 pod unavailable during updates
  • selector.matchLabels.app: hello-v1 → Selects pods with label app=hello-v1

Pod Template:

  • labels.app: hello-v1 → Pods get the label app=hello-v1
  • image: guybarrette/hello-app:1.0 → Uses version 1.0 of the hello-app
  • resources → Defines CPU and memory requests/limits
  • imagePullPolicy: Always → Always pull the image when starting a pod
  • containerPort: 8080 → Container exposes port 8080

How It Works:

The Deployment ensures that 3 replicas of the hello-app:1.0 container are always running. If a pod fails, the Deployment controller will create a new one. The RollingUpdate strategy ensures zero-downtime deployments by gradually replacing old pods with new ones.

hello-dep-v2.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-v2
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: hello-v2
  template:
    metadata:
      labels:
        app: hello-v2
    spec:
      containers:
      - image: guybarrette/hello-app:2.0
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 250m
            memory: 256Mi      
        imagePullPolicy: Always
        name: hello-v2
        ports:
        - containerPort: 8080

V2 Deployment Differences:

Key Changes:

  • metadata.name: hello-v2 → Different deployment name
  • selector.matchLabels.app: hello-v2 → Selects pods with label app=hello-v2
  • template.labels.app: hello-v2 → Pods get the label app=hello-v2
  • image: guybarrette/hello-app:2.0 → Uses version 2.0 of the hello-app
  • name: hello-v2 → Container name is hello-v2

Deployment Strategy:

Both V1 and V2 deployments use the same RollingUpdate strategy with maxSurge: 1 and maxUnavailable: 1. This ensures that during updates, at most one extra pod can be created and at most one pod can be unavailable at a time.

Application Versioning:

The main difference between V1 and V2 is the container image version. V1 uses guybarrette/hello-app:1.0 while V2 uses guybarrette/hello-app:2.0. This demonstrates how to deploy different versions of an application in Kubernetes.