IStio & Service Discovery

.

🎯 First, the Context: Service Discovery Problem

In a microservices architecture, services are dynamic — pods get created/destroyed, IPs change.We need:

• A way to register services (so they are discoverable).

• A way for clients to discover them reliably (even if pods move).

• A way to secure & observe that communication.

Traditionally, we’d use Eureka, Consul, or API Gateway for this.With Istio service mesh, this is handled differently.

✅ Solution with Istio

1️⃣ Service Registration

Istio relies on Kubernetes service registry (or VM registration if hybrid).Here’s how it works in production:

• Every microservice is deployed as a Kubernetes Service + Deployment (or StatefulSet).

  apiVersion: v1 kind: Service metadata: name: loan-service namespace: lending spec: selector: app: loan-service ports: - port: 8080 targetPort: 8080

• When this Service is created, Kubernetes automatically registers it in the kube-apiserver as a service endpoint.

• Istio’s Pilot component watches the Kubernetes API and updates the service registry inside Istio’s control plane (xDS).This registry is then pushed to all Envoy sidecars.

✅ So, you don’t manually register services with Istio.You just deploy them as K8s Services — Istio auto-discovers them.

2️⃣ Service Discovery (how other services find it)

When another microservice (say, kyc-service) wants to call loan-service:

• It resolves loan-service.lending.svc.cluster.local using Kubernetes DNS.

• The request is intercepted by the Envoy sidecar injected by Istio.

• Envoy consults its config (pushed by Istio Pilot) to know:

  • Service endpoints (load-balanced).

  • Policies (mTLS, retries, timeouts).

  • Routing rules (canary, traffic split).

Envoy then:

• Establishes mTLS connection (service identity via Istio Citadel certs).

• Routes to the correct pod (load balanced).

• Collects telemetry (metrics, tracing).

3️⃣ Service-to-Service Security (mTLS)

• Istio issues SPIFFE identities to each service (spiffe://cluster.local/ns/lending/sa/loan-sa).

• Envoy uses these to encrypt and authenticate traffic → no need to handle TLS inside microservice code.

4️⃣ Advanced Discovery & Routing (Istio Features)

You can create Istio VirtualServices & DestinationRules for:

• Canary deployments (route 10% to v2, 90% to v1).

• Failover (if region A is down, route to region B).

• Timeouts/retries/circuit breakers.

• Fault injection for chaos testing.

Example VirtualService for loan-service:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: loan-service
spec:
  hosts:
  - loan-service.lending.svc.cluster.local
  http:
  - route:
    - destination:
        host: loan-service.lending.svc.cluster.local
        subset: v1
      weight: 90
    - destination:
        host: loan-service.lending.svc.cluster.local
        subset: v2
      weight: 10

🏦 BFSI Production Considerations

• Zero-trust network: Istio + mTLS ensures even internal service calls are encrypted — critical for SEBI/RBI compliance.

• Audit: Envoy sidecars produce logs for every request → integrate with ELK/Prometheus for compliance evidence.

• Service discovery across regions: If multi-cluster, use Istio multi-cluster or service mesh federation (shared root CA).

💡 Interview-ready Answer

“With Istio, we don’t manually register services — registration is automatic via Kubernetes service registry. Istio Pilot keeps a dynamic service registry and pushes it to Envoy sidecars.For discovery, services simply call each other by DNS name (<service>.<namespace>.svc.cluster.local), Envoy sidecar resolves endpoints, applies load balancing, security (mTLS), and routing policies.This gives us zero-trust communication, observability, retries, and advanced traffic management out-of-the-box — which is critical in BFSI workloads for compliance and resilience.”