Istio Architecture and Building Blocks

Istio goals: develop an open technology that provides a uniform way to connect, secure, manage and monitor a network of microservices regardless of the platform source or vendor.


Istio service mesh provides a modular architecture similar to kubernetes logically splitted into a control plane and a data plane:

The control plane: is the brain of the main network who manage, control, and supervise the network of microservies.

The control plane manages and configures the proxies to route traffic. Additionally, the control plane configures Mixers to enforce policies and collect telemetry.

The data plane: The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars.

These proxies mediate and control all network communication between microservices along with Mixer, a general-purpose policy and telemetry hub.

The sidecars deployed within the services and acting as proxy form the service mesh network.

The following diagram illustrates the basic architecture:

Service Mesh Architecture

Building blocks

Control planePilotResponsible for service discovery and configuring envoy sidecar proxies
Control planeGalleyConfiguration ingestion for istio components
Control planeSidecar injectorInside envoy sidecar for enabled namespaces
Control planeCitadelAutomated key and certificate management
Control planePolicyPolicy enforcement
Control planeTelemetryGather telemetry data
Control planeIngresss GatewayManage inbound connection to the service mesh
Control planeEgress GatewayManage outbound connection from the service mesh
Control planeIstio CNINetwork initialisation
Control planePrometheusMetrics collections
Control planeCore DNSDNS resolution in a multicluster gateways deployment
Control planeCert ManagerIssuance and renewal of TLS certificates
DashboardGrafanaMonitoring dashboard
DashboardJaegerDistributed tracing
DashboardKialiObservability dashboard
DashboardService graphService dependencyDeprecated in favor of Kiali
Data planeEnvoy proxyProxy injected as a sidecar

Istio Building Blocks

  • The ingress controller is responsible for allowing and redirecting the inbound traffic to the services running inside the service mesh.
  • The egress controller is responsible for allowing outbound traffic from the service mesh. If an application should connect, for example, to an external database or service, such configuration should be explicitly defined for the egress controller.
  • Pilot and Galley are responsible for the mesh configuration: they pull data from Kubernetes API Server and mix it with the local configuration defined within the mesh then push the configuration to different proxies forming the mesh.

As a long term goal, Galley will the only be responsible for configuration ingestion from Kubernetes API and Pilot for configuration within the mesh.

  • Citadel push tls certificate to services enabling mutual TLS.

  • Mixer has two roles: gather metrics from the different components and enforce policy by double check each request. In a high level deployment scenario Telemetry and Policy check should be deployed separately.

  • Dashboards gather metrics from the telemetry service and display it in a user friendly format.

If you want to check the list of list of mandatory components, check istio minimal profile.

Upstream vs Downstream

Upstream connections are the service Envoy is initiating the connection to.

Downstream connections are the client that is initiating a request through Envoy.

Envoy downstream upstream diagram

Reserved ports

The following ports and protocols are used by Istio. Ensure that there are no TCP headless services using a TCP port used by one of Istio’s services.

PortProtocolUsed byDescription
8060HTTPCitadelGRPC server
15000TCPEnvoyEnvoy admin port (commands/diagnostics)
15004HTTPMixer, PilotPolicy/Telemetry - mTLS
15010HTTPPilotPilot service - XDS pilot - discovery
15011TCPPilotPilot service - mTLS - Proxy - discovery
15014HTTPCitadel, Mixer, PilotControl plane monitoring
42422TCPMixerTelemetry - Prometheus