Service Discovery, Configuration and Service Mesh

Finding and securing many moving services

Service instances come and go as they scale and redeploy, so their addresses change. Service discovery solves this. In Kubernetes, a Service gets a stable DNS name (checkout.shop.svc.cluster.local) and load-balances to healthy pods; outside Kubernetes, registries such as Consul play the same role. Configuration should come from the environment, config maps or a configuration service, with secrets in a secret manager, never baked into images. A service mesh (Istio, Linkerd, Cilium service mesh) moves cross-cutting network concerns into proxies or the node network layer: mutual TLS between services, retries and timeouts, traffic splitting for canaries, and uniform telemetry, without changing application code. A mesh adds operational complexity and some latency, so adopt it when you have enough services and requirements, such as zero-trust mTLS everywhere, to justify it.

Discovery through Kubernetes DNS

The client calls a stable name; Kubernetes routes to a healthy pod.

apiVersion: v1
kind: Service
metadata:
  name: checkout
  namespace: shop
spec:
  selector:
    app: checkout
  ports:
    - port: 80
      targetPort: 8080
---
# another service's configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: orders-config
  namespace: shop
data:
  CHECKOUT_URL: http://checkout.shop.svc.cluster.local
  HTTP_TIMEOUT_MS: "800"

An office directory instead of desk numbers

People change desks all the time, so you look colleagues up in the directory (service discovery) instead of memorising desk numbers. A service mesh is like the building's mailroom that checks IDs, tracks every parcel and reroutes when someone moves.

Quick check: What does a service mesh typically provide without application code changes?

• Database schema migrations
• Frontend rendering
• Business validation rules
• Mutual TLS, retries, traffic splitting and telemetry between services