6: Kubernetes Deployment and Services: A Practical Guide & Scaling and Services

When working with Kubernetes (K8s), starting with simple pod deployments is a common first step. However, managing pods manually comes with challenges like:

1. No Self-Healing: Pods don’t automatically recover when they fail.

2. No Scaling (Manual or Automatic): Scaling up or down requires manual intervention.

3. No Upgrade Without Downtime: Updating applications requires taking pods down, causing downtime.

4. No Rollbacks: Reverting to a previous version of an application is not straightforward.

To address these issues, Deployments and ReplicaSets provide a robust, declarative solution.

---

Understanding Kubernetes Deployments

Key Features of Deployments:

• Declarative Updates: Use YAML files to define the desired state of your application.

• Scaling: Supports both manual and automatic scaling through ReplicaSets.

• Self-Healing: Pods are automatically recreated if they fail.

• Upgrade and Rollback: Update applications seamlessly without downtime and revert to previous versions if needed.

Components of a Deployment YAML File:

A Deployment YAML typically has three main sections:

1. Metadata: Includes the name and labels of the deployment.

2. Replicas: Specifies the desired number of pod replicas.

3. Pod Template: Describes the pod configuration, including labels, container specifications, and ports.

Important Note:

The labels in the ReplicaSet must match the labels in the pods for the ReplicaSet to manage the pods correctly.'

---

Example: Nginx Deployment

After applying a deployment, Kubernetes creates:

1. A Deployment resource (e.g., nginx-deployment).

2. A ReplicaSet (e.g., nginx-deployment-7f98c79676).

3. Pods managed by the ReplicaSet (e.g., nginx-deployment-7f98c79676-46kz2).

Commands to Explore the Deployment:

• Get Deployment:

    kubectl get deployment
  

• Describe Deployment:

    kubectl describe deployment nginx-deployment
  

• Get ReplicaSets:

    kubectl get rs
  

• Describe ReplicaSet:

    kubectl describe rs nginx-deployment-7f98c79676
  

Observations:

The pods are created and managed by the ReplicaSet, not directly by the Deployment.

---

Introduction to Kubernetes Services

Why Use Services?

Deployments and ReplicaSets efficiently manage pods, but connecting to pods directly can be challenging because pod IPs are dynamic and can change. A Service abstracts pod communication by providing:

1. A stable IP address for accessing applications.

2. Load balancing across multiple pod replicas.

Key Features of Services:

• Selector Matching: Services use selectors to identify and route traffic to the pods with matching labels.

• Endpoints Management: Services continuously monitor and update pod IPs to ensure connectivity.

• Target Port: The port where the application is running within the pod.

Commands to Manage Services:

• Get Deployments:

    kubectl get deployment
  

• Get Services:

    kubectl get service
  

• Shortcut for Services:

    kubectl get svc
  

  

  Troubleshooting Services

  No Endpoints in Service?

  If a service does not display any endpoints, it usually indicates a label mismatch.

  • Reason: The labels defined in the service selector do not match any pods managed by a ReplicaSet.

  • Fix: Ensure the service selector labels match the pod labels managed by the ReplicaSet.

Example:

• Service Selector:

    selector:
      app: nginx
      tier: frontend
  

• Pod Labels:

    labels:
      app: nginx
      tier: frontend
  

If these labels don’t align, the service will fail to register endpoints.

---

Handling Multiple Labels in Services

When a service uses multiple selectors, a pod must match all labels for it to be added as an endpoint.

Example:

• Service Selector:

    selector:
      app: nginx
      env: production
  

• Pod Labels:

    labels:
      app: nginx
      env: production
      team: devops
  

In this case, the pod matches because it has both app: nginx and env: production. Additional labels (e.g., team: devops) do not impact the matching process.

---

Scaling Deployments

Manual Scaling

Manual scaling adjusts the number of replicas in your deployment to handle increased or decreased load.

Command-Based Scaling:

Use the following command to scale your deployment to five replicas:

    kubectl scale --replicas=5 deployment nginx-deployment

YAML-Based Scaling:

Scaling using YAML is a declarative approach and is generally preferred in production environments. Update the replicas field in your deployment YAML file:

    spec:
      replicas: 5

Apply the updated configuration:

    kubectl apply -f deployment.yaml

---

Automatic Scaling

Automatic scaling requires the Horizontal Pod Autoscaler (HPA), which adjusts replicas based on real-time metrics like CPU and memory usage.

Prerequisite: Metrics Server

Ensure a metrics server is installed in your cluster. It provides the data needed for autoscaling.

HPA Configuration

Here’s an example of an HPA configuration:

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: nginx-deployment-hpa
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: nginx-deployment
      minReplicas: 2
      maxReplicas: 10
      metrics:
        - type: Resource
          resource:
            name: cpu
            target:
              type: Utilization
              averageUtilization: 50

Add this HPA configuration to your deployment setup. You can find a detailed example in the HPA Configuration Repository.

---

Simulating Load for Autoscaling

To simulate load on your application and observe the HPA in action, use the following command:

    while true; do curl http://<service-ip-address>; done

Verify HPA Status:

Check the status of your Horizontal Pod Autoscaler:

    kubectl get hpa