Understanding Kubernetes Deployment and Service Manifest

Kubernetes manifests are YAML (or JSON) configuration files that define the desired state of applications running on a Kubernetes cluster. In this blog, we will break down the given Kubernetes manifest file, which consists of two main resources:

Deployment (Manages the lifecycle of a set of identical pods)
Service (Exposes the application and enables network access)

1. Deployment Configuration

The Deployment ensures that the specified number of pod replicas are running and manages updates efficiently.

Breaking Down the Deployment Manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configserver-deployment
  labels:
    app: configserver

apiVersion: apps/v1 → Specifies that this is a Deployment resource using the apps/v1 API version.
kind: Deployment → Defines this resource as a Deployment.
metadata → Contains metadata such as the Deployment's name (configserver-deployment) and labels (app: configserver). Labels help in grouping and managing related resources.

spec:
  replicas: 1
  selector:
    matchLabels:
      app: configserver

replicas: 1 → Specifies that only one pod should be created. This means only one instance of configserver will run.
selector → Ensures that this Deployment manages only the pods that have the label app: configserver.

  template:
    metadata:
      labels:
        app: configserver

template → Defines the pod template, meaning every pod created by this Deployment will follow this structure.
metadata → labels → Assigns the label app: configserver to the pod so that it matches the Deployment selector.

    spec:
      containers:
      - name: configserver
        image: eazybytes/configserver:s12
        ports:
        - containerPort: 8071

spec → containers → Defines the list of containers inside the pod.
name: configserver → Specifies the container name.
image: eazybytes/configserver:s12 → Uses the Docker image eazybytes/configserver:s12. The image must be available in a container registry (e.g., Docker Hub or a private registry).
ports → containerPort: 8071 → The application inside the container is running on port 8071.

2. Service Configuration

A Service in Kubernetes enables communication between different components of an application and exposes pods to external users if required.

Breaking Down the Service Manifest

apiVersion: v1
kind: Service
metadata:
  name: configserver

apiVersion: v1 → Specifies that this is a Service resource.
kind: Service → Defines this resource as a Service.
metadata → name: configserver → Names the service configserver.

spec:
  selector:
    app: configserver

selector: app: configserver → Tells Kubernetes that this Service should route traffic to pods labeled app: configserver.

  type: LoadBalancer

type: LoadBalancer → Exposes the Service externally using a cloud provider’s load balancer (useful for public-facing applications).

  ports:
    - protocol: TCP
      port: 8071
      targetPort: 8071

ports → Defines how the Service exposes the application.
protocol: TCP → Specifies the protocol (TCP).
port: 8071 → The port on which the Service is accessible.
targetPort: 8071 → Forwards traffic to port 8071 on the pods.

How This Works in Kubernetes?

Deployment Behavior
- Kubernetes creates a pod running the eazybytes/configserver:s12 container on port 8071.
- If the pod crashes, Kubernetes automatically restarts it.
Service Behavior
- The Service detects pods with the label app: configserver and routes traffic to them.
- As it is a LoadBalancer Service, it exposes an external IP (if deployed in a cloud environment like AWS, GCP, or Azure).

Deploying the Manifest

To deploy this configuration in Kubernetes, save it to a file (e.g., configserver.yaml) and run:

kubectl apply -f configserver.yaml

To verify the deployment and service:

kubectl get deployments
kubectl get pods
kubectl get services

If using minikube, you may need to run:

minikube service configserver

Conclusion

This Kubernetes manifest deploys a single-instance Config Server (configserver) and exposes it through a LoadBalancer. This setup is useful in microservices architectures, where services need centralized configuration management.

Would you like to add environment variables, readiness probes, or horizontal scaling to enhance this configuration? 🚀