istio pilot discovery server

The main code that setup istio pilot discovery server are located here in istio/pilot/pkg/bootstrap/server.go where you will get to see al the magic happens.

Istio Pilot (also known as the Discovery Server or istiod in newer versions) is the control plane component in Istio responsible for service discovery, configuration management, and traffic routing. It's the central brain that coordinates all the Envoy proxies (sidecars and gateways) in your service mesh. Most importantly it converts high-level Istio API resources (VirtualService, DestinationRule, Gateway, etc.) into Envoy-specific configuration. 

It also expos the xDS API (x Discovery Service) protocols to push config to proxies such as 

LDS (Listener Discovery Service)

Purpose: Defines how Envoy accepts connections
What it configures: Listeners (ports/endpoints Envoy listens on)

Key Details:

• Each listener defines:
  • IP address and port (e.g., 0.0.0.0:15001, 0.0.0.0:15006)
  • Protocol type (HTTP, TCP, gRPC, etc.)
  • Filter chains (network filters, HTTP filters)
  • Socket options
• In Istio, common listeners:
  • 15001: Inbound listener for sidecar traffic
  • 15006: Outbound listener for application traffic
  • 15021: Health check port

Example LDS Config Snippet:

listeners:

- name: "virtualInbound"

  address: { socket_address: { port_value: 15006 } }

  filter_chains:

  - filters:

    - name: envoy.filters.network.http_connection_manager

      typed_config:

        stat_prefix: "inbound"

        route_config_name: "inbound_virtual"  # Points to RDS

RDS (Route Discovery Service)

Purpose: Defines where to route traffic for HTTP listeners
What it configures: Routes (HTTP path/headers -> backend clusters)

Key Details:

• Only applies to HTTP listeners (not TCP)
• Defines routing rules based on:
  • HTTP paths (/api/v1/*)
  • Headers (user-agent: Chrome)
  • Methods (GET, POST)
  • Query parameters
• Routes traffic to clusters (defined in CDS)

Example RDS Config Snippet:

virtual_hosts:

- name: "reviews-service"

  domains: ["reviews.default.svc.cluster.local"]

  routes:

  - match: { prefix: "/reviews/" }

    route:

      cluster: "outbound|9080||reviews.default.svc.cluster.local"  # Points to CDS

  - match: { prefix: "/" }

    route:

      cluster: "blackhole"  # Default route

CDS (Cluster Discovery Service)

Purpose: Defines where to send traffic (backend endpoints)

What it configures: Clusters (groups of upstream hosts/ports)

Key Details:

• Defines backend service endpoints:
  • Service name (e.g., reviews.default.svc.cluster.local:9080)
  • Load balancing policy (round_robin, least_conn)
  • Health checks
  • Circuit breakers
  • TLS settings
• Each cluster points to endpoints (EDS)

Example CDS Config Snippet:

clusters:

- name: "outbound|9080||reviews.default.svc.cluster.local"

  type: "EDS"  # Uses EDS for endpoints

  eds_cluster_config:

    service_name: "outbound|9080||reviews.default.svc.cluster.local"

  lb_policy: "ROUND_ROBIN"

  circuit_breakers:

    thresholds:

    - max_connections: 1000

EDS (Endpoint Discovery Service)

Bringing it together 

The flow is LDS → RDS → CDS → EDS:

1. LDS tells Envoy: "Listen on port 15006"
2. RDS tells Envoy: "When you get HTTP requests on port 15006, route /api to cluster X"
3. CDS tells Envoy: "Cluster X is reviews.default.svc.cluster.local:9080"
4. EDS (Endpoint Discovery Service) tells Envoy: "The actual pods for reviews are at [10.244.1.5:9080, 10.244.2.7:9080]"