mirror of https://github.com/istio/istio.io.git
89 lines
4.1 KiB
Markdown
89 lines
4.1 KiB
Markdown
---
|
|
bodyclass: docs
|
|
headline: Service Model
|
|
layout: docs
|
|
sidenav: doc-side-concepts-nav.html
|
|
title: Service Model
|
|
type: markdown
|
|
---
|
|
|
|
{% capture overview %}
|
|
The page explains Istio's overall service model.
|
|
{% endcapture %}
|
|
|
|
{% capture body %}
|
|
The Istio manager serves as an interface between the user and Istio,
|
|
collecting configuration, validating it and propagating it to various
|
|
components. It abstracts platform-specific implementation details from the
|
|
mixer and proxies, providing them with an abstract representation of user's
|
|
services that is independent of the underlying platform. The model
|
|
described below assumes a microservice-based application owned by a single
|
|
tenant.
|
|
|
|
**Istio-managed service:** Modern cloud applications are created by
|
|
composing together independent sets of services. Individual services are
|
|
referenced by their fully-qualified domain name (FQDN) and one or more
|
|
ports where the service is listening for connections.
|
|
|
|
**Platform-agnostic internal representation:** The Istio model of a
|
|
microservice is independent of how it is represented in the underlying
|
|
platform (Kubernetes, Mesos, CloudFoundry, etc.). Platform-specific
|
|
adapters are responsible for populating the internal model representation
|
|
with various fields, from the metadata found in the platform.
|
|
|
|
## Multiple versions of a service
|
|
|
|
Istio introduces the concept of a service version, which is a finer-grained
|
|
way to subdivide service instances by versions (`v1`, `v2`) or environment
|
|
(`staging`, `prod`). These variants are not necessarily different API
|
|
versions: they could be iterative changes to the same service, deployed in
|
|
different environments (prod, staging, dev, etc.). Common scenarios where
|
|
this occurs include A/B testing, canary rollouts, etc. Istio
|
|
[routing rules](../reference/rule-dsl.md) can refer to the service versions, to provide
|
|
additional control over traffic between services.
|
|
|
|
**Tags** Each version of a service can be differentiated by a unique set of
|
|
tags associated with the version. Tags are simple key value pairs
|
|
assigned to the instances of a particular service version, i.e., all
|
|
instances of the same version must have the same tags.
|
|
|
|
## Populating the abstract service model
|
|
|
|
Where possible, Istio leverages the service registration and discovery
|
|
mechanism provided by the underlying platform to populate its abstract
|
|
service model. Most container platforms come built-in with a service
|
|
registry (e.g., kubernetes, mesos) where a pod specification can contain
|
|
all the version related tags. Upon launching the pod, the platform
|
|
automatically registers the pod with the registry along with the tags. In
|
|
other platforms, a dedicated service registration agent might be needed to
|
|
automatically register the service with a service registration/discovery
|
|
solution like Consul, etc.
|
|
|
|
At the moment, Istio integrates readily with the Kubernetes service registry
|
|
and automatically discovers various services, their pods etc., and
|
|
groups the pods into unique sets -- each set representing a service
|
|
version. In future, Istio will add support for pulling in similar
|
|
information from Mesos registry and *potentially* other registries.
|
|
|
|
## Communication between services
|
|
|
|
Clients of a service have no knowledge of different versions of the
|
|
service. They can continue to access the services using the hostname/IP
|
|
address of the service. The Istio Proxy intercepts and forwards all
|
|
requests/responses between the client and the service.
|
|
|
|
The actual choice of the service version is determined dynamically by the
|
|
Istio Proxy based on the routing rules set forth by the operator. This
|
|
model enables the application code to decouple itself from the
|
|
evolution of its dependent services, while providing other benefits as well
|
|
(see [mixer](mixer.md)). Routing rules allow the proxy to select a version based on
|
|
criterion such as (headers, url, etc.), tags associated with
|
|
source/destination and/or by weights assigned to each version.
|
|
|
|
Note that Istio does not provide a DNS. Applications can try to resolve the
|
|
FQDN using the DNS service present in the underlying platform (kube-dns,
|
|
mesos-dns, etc.).
|
|
{% endcapture %}
|
|
|
|
{% include templates/concept.md %}
|