Pilot

Pilot is the head of the ship in an Istio mesh, so to speak. It stays synchronized with the underlying platform (e.g., Kubernetes) by tracking and representing the state and location of running services to the data plane. Pilot interfaces with your environment’s service discovery system, and produces configuration for the data-plane service proxies (we’ll examine istio-proxy as a data-plane component later).

As Istio evolves, more of Pilot’s focus will be the scalable serving of proxy configuration and less on interfacing with underlying platforms. Pilot serves Envoy-compatible configurations by coalescing configuration and endpoint information from various sources and translating this into xDS objects. Another component, Galley, will eventually take responsibility for interfacing directly with underlying platforms.

Galley

Galley is Istio’s configuration aggregation and distribution component. As its role evolves, it will insulate the other Istio components from underlying platform and user-supplied configurations by ingesting and validating configurations. Galley uses the Mesh Configuration Protocol (MCP) as a mechanism to serve and distribute configuration.

Mixer

Capable of standing on its own, Mixer is a control-plane component designed to abstract infrastructure backends from the rest of Istio, where infrastructure backends are things like Stackdriver or New Relic. Mixer bears responsibility for precondition checking, quota management, and telemetry reporting. It does the following:

• Enables platform and environment mobility

• Provides granular control over operational policies and telemetry by taking responsibility for policy evaluation and telemetry reporting

• Has a rich configuration model

• Abstracts away most infrastructure concerns with intent-based configuration

Service proxies and gateways invoke Mixer to do precondition checks to determine whether a request should be allowed to proceed (check), whether communication between the caller and the service is allowed or has exceeded quota, and to report telemetry after a request has completed (report). Mixer interfaces to infrastructure backends through a set of native and third-party adapters. Adapter configuration determines which telemetry is sent to which backend and when. Service mesh operators can use Mixer’s adapters as the point of integration and intermediation with their infrastructure backends as it operates as an attribute processing and routing engine.

Citadel

Citadel empowers Istio to provide strong service-to-service and end-user authentication using mutual Transport Layer Security (mTLS), with built-in identity and credential management. Citadel’s CA component approves and signs certificate-signing requests (CSRs) sent by Citadel agents, and it performs key and certificate generation, deployment, rotation, and revocation. Citadel has an optional ability to interact with an identity directory during the CA process.

Citadel has a pluggable architecture in which different CAs can be used so that it’s not using its self-generated, self-signed signing key and certificate to sign workload certificates. The CA pluggability of Istio enables and facilitates the following:

• Integrates with your organization’s public key infrastructure (PKI) system.

• Secures communication between Istio and non-Istio legacy services (by sharing the same root of trust).

• Secures the CA signing key by storing it in a well-protected environment (e.g., HashiCorp Vault, hardware security module, or HSM)

Injection

The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to redesign or rewrite code. This is a significant attraction to using Istio. The promises of an immediate view of top-level service metrics, of detailed control over traffic, and of automated authentication and encryption between all services without having to change your application code or change your deployment manifests.

Using Istio’s canonical sample application Bookinfo, makes clear how service proxies come into play and form a mesh. Figure 3-3 shows the Bookinfo application without the service proxies. (We take a closer look at Bookinfo and deploy it in Chapter 4.)

In Kubernetes, automatic proxy injection is implemented as a webhook using a Kubernetes API Server with the mutating webhook admission controller. It is stateless, depending only on the injection template and mesh configuration configmaps as well as the to-be-injected pod object. As such, it is easily horizontally scaled, either manually via the Deployment object, or automatically via a Horizontal Pod Autoscaler (HPA).

Injection of the sidecar proxy into a newly created pod takes an average of 1.5 µs (per microbenchmark) for the Webhook itself to execute. Total injection time will be higher when accounting for network latency and API Server processing time.

Figure 3-3. Istio’s sample application, Bookinfo, shown without service proxies

Istio addresses the well-known distributed systems challenge of not having homogeneous, reliable, unchanging networks. It does so through deployment of lightweight proxies deployed between your application containers and the network. Figure 3-4 demonstrates how the full architecture of Istio includes the control and data planes with each of their internal components. A full-mesh deployment also includes ingress and egress service gateways.

Figure 3-4. Bookinfo shown with service proxies

Ingress

Configuring ingress gateways enables you to define traffic entryways into the service mesh for incoming traffic to flow through. Consider that ingressing traffic into the mesh is a reverse proxy situation—akin to traditional web server load balancing. Configuration for egressing traffic out of the mesh is a forward proxy situation in which you identify which traffic to allow out of the mesh and where it should be routed.

As an example, the following gateway configuration sets up a proxy to act as a load balancer exposing port 80 and 9080 (HTTP), 443 (HTTPS), and port 2379 (TCP) for ingress. The gateway will be applied to the proxy running on a pod with labels app: my-gateway-controller. Even though Istio will configure the proxy to listen on these ports, it is the responsibility of the user to ensure that external traffic to these ports is allowed into the mesh (for more details, see Istio’s gateway documentation):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-gateway
spec:
  selector:
    app: my-gateway-controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - uk.bookinfo.com
    - eu.bookinfo.com
    tls:
      httpsRedirect: true # sends 301 redirect for http requests
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - uk.bookinfo.com
    - eu.bookinfo.com
    tls:
      mode: SIMPLE #enables HTTPS on this port
      serverCertificate: /etc/certs/servercert.pem
      privateKey: /etc/certs/privatekey.pem
  - port:
      number: 9080
      name: http-wildcard
      protocol: HTTP
    hosts:
    - "*"
  - port:
      number: 2379 # to expose internal service via external port 2379
      name: mongo
      protocol: MONGO
    hosts:
    - "*"

Egress

Traffic can exit an Istio service mesh in two ways: directly from the sidecar or funneled through an egress gateway, where you can apply traffic policy.

Direct from a service proxy

If you want traffic destined to an external source to bypass the egress gateway, you can provide configuration to the ConfigMap of the istio-sidecar-injector. Set the following configuration in the sidecar injector, which will identify cluster-local networks and keep traffic destined locally within the mesh while forwarding traffic for all other destinations externally:

--set global.proxy.includeIPRanges="10.0.0.1/24"

After you’ve applied this and Istio proxies are updated with this configuration, external requests bypass the sidecar and route directly to the intended destination. The Istio sidecar will intercept and manage only internal requests within the cluster.

Route through an egress gateway

You may need to use an egress gateway in order to provide connectivity from your cluster’s private IP address space, monitoring, or cross-cluster connectivity.

An egress gateway allows Istio monitoring and route rules to be applied to traffic exiting the mesh. It also facilitates communication between applications running in a cluster where the nodes do not have public IP addresses, preventing applications in the mesh from accessing the internet. Defining an egress gateway, directing all the egress traffic through it, and allocating public IPs to the egress gateway nodes allows the nodes (and applications running on them) to access external services in a controlled way, as depicted in Figure 3-5.

Figure 3-5. Istio’s architecture and components