	In Browser
	StumbleUpon
	del.icio.us
	Google
	Google Buzz
	reddit
	LinkedIn

	Facebook
	Twitter
	Linkedin
	E-Mail

Container Management > Kubernetes > Kubernetes Deployments and Services

Kubernetes Deployments and Services

Author: Venkata Sudhakar

Kubernetes (K8s) is an open-source container orchestration platform that automates the deployment, scaling, and management of containerised applications. Where Docker runs containers on a single machine, Kubernetes runs them across a cluster of machines (nodes), handling scheduling, load balancing, self-healing, and rolling updates automatically. Kubernetes has become the standard platform for running production containerised workloads in enterprise environments.

The two most fundamental Kubernetes objects are Deployments and Services. A Deployment describes the desired state of your application - which container image to run, how many replicas (Pods) to maintain, resource limits, and health checks. Kubernetes continuously monitors the cluster and automatically creates new Pods when replicas are missing, replaces failed Pods, and rolls out new versions with zero downtime. A Service provides a stable network endpoint for accessing your Pods. Since Pod IP addresses change every time a Pod is restarted, Services provide a fixed DNS name and IP address that load-balances traffic across all healthy Pods of a Deployment.

The below example shows how to deploy a Spring Boot application to Kubernetes by creating a Deployment and a Service using YAML manifests, then managing the deployment with kubectl commands.

# myapp-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: production
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Allow 1 extra Pod during update
      maxUnavailable: 0  # Zero downtime: no Pod goes down before new one is up
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: gcr.io/my-project/myapp:v2.1.0
        ports:
        - containerPort: 8080
        env:
        - name: SPRING_DATASOURCE_URL
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: db-url
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
  namespace: production
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: LoadBalancer

Apply the manifests and check deployment status,

It gives the following output,

deployment.apps/myapp created
service/v1 myapp-service created

Waiting for deployment "myapp" rollout to finish: 1 out of 3 new replicas updated...
Waiting for deployment "myapp" rollout to finish: 2 out of 3 new replicas updated...
deployment "myapp" successfully rolled out

NAME            READY  STATUS   RESTARTS  AGE
myapp-7d9f-abc  1/1    Running  0         30s
myapp-7d9f-def  1/1    Running  0         25s
myapp-7d9f-ghi  1/1    Running  0         20s

NAME            TYPE          CLUSTER-IP   EXTERNAL-IP      PORT(S)
myapp-service   LoadBalancer  10.96.0.100  34.102.123.456   80:31234/TCP

The below example shows how to perform a rolling update to a new image version, check rollout history, and roll back if needed.

It gives the following output,

deployment.apps/myapp image updated

Waiting for rollout to finish: 1 old replicas pending termination...
deployment "myapp" successfully rolled out

DEPLOYMENT         REVISION  CHANGE-CAUSE
deployment/myapp   1         Initial deployment v2.1.0
deployment/myapp   2         Updated to v2.2.0

# After undo:
deployment.apps/myapp rolled back to revision 1

# After scale:
deployment.apps/myapp scaled to 5 replicas

readinessProbe vs livenessProbe:

readinessProbe - Kubernetes only sends traffic to a Pod once it passes the readiness probe. During startup, the Pod is Running but not Ready - Kubernetes waits until the Spring Boot app finishes loading before routing requests to it. This prevents traffic from hitting Pods that are not yet warmed up.

livenessProbe - If a running Pod starts failing the liveness probe (e.g., the app is deadlocked), Kubernetes automatically restarts the container. This is self-healing: a stuck application is automatically recovered without manual intervention.

Send your comments, suggestions or queries regarding this site to [email protected].