In Kubernetes, how do a Deployment and a Service work together to let a microservice be released and scaled without breaking the services that call it?

## What a Deployment does A Kubernetes Deployment and a Service solve two different problems that together produce zero-downtime, independently-releasable microservices, and it's worth separating what each one actually does. A `Deployment` is a controller that manages a set of identical pod replicas for one service: you declare a desired state — 'run image v2 of order-service, three replicas' — and the Deployment continuously reconciles the running pods toward that state. When you push a new image version, the Deployment doesn't replace all pods at once; by default it performs a **rolling update**: 1. creating a few new-version pods, 2. waiting for them to pass their readiness checks, 3. then terminating a corresponding number of old-version pods, 4. repeating until all replicas run the new version. If the new pods never become ready (a bad build, a missing config value, a crash loop), the rollout can be halted or automatically rolled back, so a broken release doesn't fully replace a working one. ## What a Service adds The problem this alone doesn't solve is **addressability**: pods are ephemeral by design — they get a new internal IP address every time they're created, whether from a rollout, a crash-restart, or the autoscaler adding replicas — so nothing that calls this service can hardcode a pod IP and expect it to keep working. A `Service` solves that by providing a stable virtual IP address and DNS name that sits in front of a Deployment's pods. - It **doesn't point at specific pods directly**; instead it uses a **label selector** to continuously discover which currently-running pods match the service's labels. - Critically, it **filters that set down to only pods whose readiness probe is currently passing**, so a pod that's starting up, unhealthy, or draining during termination is automatically excluded from receiving traffic even though it may still technically exist. - Callers only ever address the Service's stable name; the Service transparently load-balances across whichever real pods are healthy at that instant. | Object | What it owns | |---|---| | Deployment | desired state, replica count, the rolling update, and rolling back a broken release | | Service | a stable virtual IP and DNS name, the label selector, and traffic only to pods whose readiness probe is passing | ## Why the split decouples releases This division of labor is precisely what decouples releasing a service from breaking its callers, which is the whole point in a microservices system. A team can trigger a rolling update on their own Deployment — changing replica count, pushing a new version, tuning resource limits — at any time, on their own release schedule, without notifying or coordinating with every team whose service calls theirs, because the calling code's only dependency is the unchanging Service name, never the pod-level details underneath it. That's the mechanism that makes 'deploy this one service independently, right now, without a maintenance window' operationally real rather than aspirational. ## The trade-off The trade-off is added indirection and reliance on probes being configured correctly. - The whole safety property — 'traffic only reaches healthy pods' — depends entirely on the **readiness probe** accurately reflecting whether a pod can actually serve traffic; a probe that just checks 'is the process running' rather than 'can this instance serve a real request' will happily route traffic to a pod that's up but broken (e.g., its database connection pool hasn't initialized yet), producing errors the Kubernetes layer had every mechanism to prevent. - There's also a well-known **timing race** during termination: Kubernetes starts removing a terminating pod from the Service's endpoint list and sends it a termination signal roughly in parallel, not strictly endpoint-removal-then-signal, so without a short `preStop` hook or grace period, a pod can receive its shutdown signal and stop accepting connections microseconds before some in-flight requests have finished being routed to it, producing a small burst of connection errors during otherwise-healthy rolling updates. ## A concrete illustration A concrete illustration: an e-commerce platform running a checkout-service behind a Service, called synchronously by a cart-service. When the checkout team ships a fix, their Deployment rolls three new pods in one at a time, each one only joining the Service's routable set after passing a readiness probe that actually calls a lightweight internal health endpoint verifying its database connection is live. cart-service never sees a version number, a pod IP, or a deploy notification — it just keeps calling checkout-service's stable name throughout the rollout, and (assuming the probe and shutdown grace period are configured correctly) sees no errors. This is the pattern — Deployment for controlled rollout, Service for a stable address that only ever exposes ready instances — that lets an organization run dozens of teams' services on independent release cadences without a shared deploy freeze.