TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
How to Use Kubernetes Deployments and Services to Manage Pods
As soon as you move from running a single container to operating a real application in a cluster, complexity increases. Pods are dynamic by design. They can be recreated, rescheduled, scaled horizontally, or terminated at any time based on desired state and cluster conditions.
You immediately face two practical challenges: how to keep the right number of Pods running, and how to make them consistently reachable despite restarts, rescheduling, or scaling events.
Understanding how Kubernetes Deployments and Services work is critical in this aspect.
What is a Kubernetes Deployment
A Kubernetes Deployment is a way to tell the cluster how your application Pods should run and how many of them should exist.
Instead of manually creating Pods one by one, you define a Deployment with a desired number of replicas and a Pod template. Kubernetes then ensures that the specified number of identical Pods are always running.
If a Pod crashes, it is automatically recreated.
If you scale the Deployment, more Pods are added or removed.
If you update the container image, Kubernetes updates the Pods in a controlled way.
So practically, a Deployment is responsible for maintaining the desired state of your application Pods over time.
How a Deployment Becomes Running Pods
When you apply a Deployment, the manifest is sent to the API server, validated, and stored in etcd as part of the cluster’s desired state.
The Deployment controller watches the API server, detects the new Deployment object, and creates a ReplicaSet based on the defined Pod template and replica count.
The ReplicaSet controller compares desired replicas with the current state and creates the required Pod objects, which are stored in the API server. At this stage, Pods exist only as definitions in the control plane.
The Scheduler watches for Pods without a
nodeName, evaluates worker nodes based on resource availability and constraints, and assigns each Pod to the most suitable node.The kubelet on the selected worker node detects the assigned Pod, reads its specification, and instructs the container runtime to pull the image and start the containers inside the Pod.
Once the containers start successfully, the Pod transitions to the Running state, and Kubernetes continues reconciling actual state with the declared configuration to maintain health and replica count.
With this basic understanding, let us now see how Kubernetes Services are used in two different ways in production environments and which one to pick when.
Kubernetes Service - Application Layer (ClusterIP with Ingress)
Once your Pods are running through a Deployment, they are still not directly reachable in a stable way. Pods can restart, scale, or get new IP addresses. This is where a Service becomes essential.
In this model, a ClusterIP Service is created for each application component. The Service provides:
A stable virtual IP inside the cluster
A consistent DNS name
Automatic load balancing across matching Pods
The Service selects Pods using labels defined in the Deployment. As Pods scale up or down, the Service dynamically updates its endpoints. No manual reconfiguration is required.
In production environments, applications are rarely exposed directly through Services alone. Instead, an Ingress sits in front of them.
The typical flow looks like this:
Client → Ingress → Service → Pods
The Ingress handles:
External HTTP or HTTPS entry
Host and path-based routing
TLS termination
The Service handles:
Internal load balancing
Stable networking to Pods
This approach is commonly used for:
Web applications
Microservices behind an API gateway
Production environments requiring controlled routing and TLS
Here, the Service operates at the application networking layer inside the cluster, while Ingress manages external traffic entry.
Kubernetes Service – NodePort
In this model, the Service is exposed outside the cluster using NodePort.
When you create a Service of type NodePort, Kubernetes opens a specific port from the range 30000-32767 on every worker node in the cluster. That port is mapped to the internal ClusterIP Service.
The traffic flow becomes:
Client → Node IP : NodePort → Service → Pods
Here is what happens in practice:
The client sends a request to the DNS name or public IP of any worker node along with the NodePort.
kube-proxy running on that node captures the traffic.
It forwards the request to the underlying Service.
The Service load balances the traffic across the matching Pods.
Important characteristics of NodePort:
The same port is opened on all nodes, even if Pods are running on only some of them.
You can reach the application using any node’s IP address.
Internally, Kubernetes still uses the Service abstraction to route traffic to Pods.
NodePort is typically used for:
Bare metal clusters without a cloud LoadBalancer
Development or testing environments
Simple external exposure scenarios
As a base layer for external load balancers
It does not provide:
Built-in TLS termination
Advanced routing
Automatic public load balancing
In those cases, NodePort is usually combined with a cloud LoadBalancer or replaced with an Ingress-based architecture.
In production, you do not choose between Deployment and Service. You use both together. Deployment keeps your workload healthy. Service keeps it reachable.
I hope this was an insightful edition. See you in the next edition on Saturday.
Take care and have a nice day.
