Istio v1alpha3 routing groups rules around the addressed host

Several independent route objects can describe one service while hiding the order in which their conditions interact. Istio's April 25 routing API explanation replaces that composition with a host-oriented configuration model. A VirtualService holds an ordered list of routes, while a DestinationRule defines named subsets and forwarding policies. The redesign also gives gateways and service-registry additions their own resource types.

I value the attempt to make traffic configuration legible at the level of the service being operated. Moving routing out of application code helps only if the resulting configuration can be understood as a whole. An operator should be able to find the conditions for an addressed host and determine which actual workloads a request can reach.

The addressed host and destination can differ

The older RouteRule model associates separate rules with a destination and uses precedence values to establish evaluation order. The new model collects routing conditions in a VirtualService's ordered list. That changes how rules are added or removed. Modifying an existing host's routes becomes an update to the containing object rather than the creation or deletion of another independent RouteRule.

More significantly, the VirtualService's hosts and its routes' destination hosts have different meanings. The former identifies what a client addresses. A route can then send the request to another service. The introduction demonstrates this with a shared application host whose path prefixes select the reviews or ratings service.

This supports changing the application's internal decomposition without requiring every client to address its component services directly. The virtual host describes an entry point, while each route names the workload destination. Keeping those fields separate avoids making the public name depend on the implementation's current service layout.

The host does not have to be an ordinary routable service entry in Istio's internal registry. A VirtualService can model a virtual destination and bind that host to a Gateway. The routing object therefore represents the relationship between an addressed name and actual destinations, not merely an alternate place to store a Kubernetes Service definition.

Named subsets separate membership from routing

A route can refer to a subset such as v2. The corresponding DestinationRule maps that name to labels identifying the service's workloads. This replaces repeating the workload label selection inside each route. A named subset can also be referenced from more than one VirtualService, giving the version a consistent identity across routing configurations.

This fragment illustrates the membership declaration used by the introduction's reviews example.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

The declaration defines the available subsets without deciding which request should use each one. That decision belongs in the VirtualService. A header match can select v2, with an unmatched request falling through to a default route for v1. Membership and request selection remain linked by the subset name while living in separate parts of the API.

DestinationRule also holds forwarding behavior such as load balancing and TLS settings. The introduction includes both a default load-balancing policy and a policy specific to one subset in a single resource. This lets a service owner describe what happens after a route has chosen the destination. The route condition itself need not duplicate those forwarding settings.

The introduction's migration example combines a higher-precedence cookie match with a lower-precedence default. In the new representation, the conditional entry appears before the fallback entry in the same list. The ordering remains part of behavior, even though the separate numeric precedence fields disappear. Reviewing the list therefore includes reviewing which conditions precede the default.

Adding or removing a route which references a service version can also require updating the subset declarations. The new API gives those two decisions different locations, so a complete configuration change must account for both. A route naming a subset expresses an intended relationship with the DestinationRule's membership definition.

Gateway configures the listener boundary

The introduction describes Kubernetes Ingress as insufficient for the full set of Istio routing needs. Encoding proxy-specific capabilities in annotations makes those capabilities difficult to express through a shared API. Istio's Gateway instead describes the listener-facing configuration, including ports and TLS, while VirtualService supplies request routing.

A VirtualService binds to a Gateway through its gateways field and declares the corresponding host. This explicitly connects a listener boundary to the routing configuration which should apply there. The same abstraction can describe an edge proxy or an internal proxy. Its location does not require a separate routing model for the HTTP behavior attached to it.

That separation also clarifies operational responsibility. Exposing a TLS port and supplying a certificate are listener decisions. Sending requests under a path prefix to a particular service is a request-routing decision. The objects must agree on the host and binding, but neither has to contain the other's entire configuration.

ServiceEntry adds destinations to the registry

ServiceEntry replaces EgressRule by representing additional entries in Istio's internal registry. The introduction distinguishes mesh-internal entries from mesh-external entries. This permits explicit modeling of services on infrastructure outside the automatically discovered environment, as well as external APIs which mesh workloads consume.

Once the destination is in the registry, the same routing and destination-policy resources can apply to it. Adding a service does not have to combine discovery information with every possible forwarding decision. ServiceEntry also introduces explicit endpoint resolution modes and can represent multiple endpoints. This expands the external-dependency model beyond a single egress permission declaration.

I regard the shared model for external and internal destinations as useful, provided its security meaning remains explicit. A registry entry describes a destination the proxy can use. Mutual TLS identity and the location of policy enforcement still depend on how that destination participates in the mesh. The introduction treats mesh-external services differently from ordinary internal requests.

The Istio 0.7 release note calls its v1alpha3 support preliminary and subject to change. The April design explanation also states that conversion from the previous API is manual and not backward compatible. Adopting the new organization therefore requires translating the existing route order and membership relationships. An ordered VirtualService list and its DestinationRule subsets must preserve the behavior formerly distributed across RouteRule and DestinationPolicy objects.