一. Traffic Management

使用 istio 的流量管理模型实质上解耦了 traffic flow 和 infrastructure scaling,
你可以通过 Pilot 指定 traffic 遵循的规则, 然后由 Pilot 和 Envoy 来做其余的事情, 而不是直接指定让哪个 Pods/VMs 接收 traffic.
例如, 你可以通过 Pilot 指定如下规则: 你想让某个特定服务的 5% 的流量转到 canary(金丝雀)版本, 而不管canary版本的部署副本数量的多少, 或者根据请求的内容将流量发送到某个特定版本的服务.
这种将 traffic flow 和 infrastructure scaling 解耦的模型让 istio 可以提供很多特性, 例如对请求进行动态的路由从而进行A/B测试, gradual rollouts(逐步升级), canary Release(金丝雀发布).
istio 还处理 failure recovery, 使用 timeouts, retries, circuit breakers, 和 fault injection 来测试 服务之间的 failure recovery policies 的兼容性.
这些功能都是通过 service mesh 上部署的 Envoy sidecars / proxies 实现的。

1. Pilot and Envoy

在 istio 中用于 traffic management 的核心组件就是 Pilot, 它管理和配置部署在 service mesh 中的 envoy.
Pilot 让你指定你想使用哪些规则来路由Envoy proxies 之间的 traffic , 并配置 failure recovery 特性,例如 timeouts, retries, circuit breakers.
它还维护一个网格中所有服务的 canonical model (规范模型) , 并且使用这个模型 让envoy实例 通过它的 discovery service 知道网格中的其他envoy实例的存在.

每个 envoy 实例都维护一份 load balancing 信息, 这份信息基于它从 Pilot 获取的信息, 并且周期性地对位于其 load-balancing pool 中的其他实例进行健康检查, 从而允许它可以在遵循指定的路由规则的同时也能智能地在目标实例之间分配流量.

Pilot 负责部署在服务网格中的 envoy实例 的生命周期.

2. Request routing

在istio中一个服务的模型和其在底层平台(例如kubernetes,Mesos,Cloud foundry(代工厂)等等)的表示形式无关.
Platform-specific adapters 负责将 istio中的服务模型 polulating 到指定平台.

istio 引进了 服务版本 的概念, 这可以区分不同版本的服务或不同环境的服务, 而且一般多哟用于 A/B测试 和 金丝雀发布.

对于服务调用方而言, 它们不知道服务版本的存在. 它们面对的还是原来的服务,没有变化. envoy 负责解析并转发 client 和 service 直接的请求和响应.
envoy 可以根据你通过 Pilot 制定的路由规则 选择服务, 可以根据请求的 headers, 源/目的地的tags, 或者某个版本的weight 来进行路由.

istio 不提供DNS, 应用可以尝试使用底层平台提供的DNS服务(例如 kube-dns, mesos-dns 等等)

3. Ingress and egress

istio 假设所有的进入和离开服务网格的流量 都是通过 envoy 代理的.

istio 假设已经存在一个服务注册表用于追踪服务的 pods/VMs . istio 还假设一个服务的新实例会自动注册到服务注册表中, 并且不健康的实例会自动移除. 底层平台(例如kubernetes和Mesos)已经为基于容器的应用提供了这些功能, 并且基于VM的应用也有很多已经存在的解决方案.

Pilot 消费服务注册表中的服务信息, 并提供一个平台无关的 服务发现接口. 服务网格中的envoy实例就从这个接口获取信息.

4. handling failures

envoy 提供了一套 out-of-the-box(开箱即用)的选项用于故障恢复功能, 这些功能包括:

• 超时返回: Timeouts
• 重试: Bounded retries with timeout budgets and variable jitter between retries
• 到upstream服务的并发连接数和请求数限制: Limits on number of concurrent connections and requests to upstream services
• 对负载均衡池中的服务的周期性的主动健康检查: Active (periodic) health checks on each member of the load balancing pool
• 细粒度的断路器(被动的健康检查): Fine-grained circuit breakers (passive health checks) – applied per instance in the load balancing pool

这些功能可以在 运行时 动态配置, 通过 istio 的 traffic management 的 rules.

Fine tuning

Istio’s traffic management rules 允许你设置每个服务的默认的 failure discovery, 和默认的服务版本.
然而, 服务的消费者也可以通过特定的HTTP请求头 来覆盖默认的 timeout 和 重试次数, 在 envoy 作为proxy时,这些头是 x-envoy-upstream-rq-timeout-ms and x-envoy-max-retries .

Failure handling FAQ

问题: 当应用运行在 istio 中, 它还需要处理 failures吗?
答: 需要. istio 改善了网格中的服务的可靠性和可用性. 但应用扔人需要处理 failure(errors) 并进行相应的 fallback 动作.
例如, 当负载均衡池中的所有服务都失败了, envoy 会返回 HTTP 503.

问题: envoy的 failure recovery 功能是否会破坏 应用已经使用的容错机制(例如 Hystrix)?
答: 不会. envoy 对应用是完全透明的. envoy 返回的失败响应和upstream返回的失败响应是不同的.

问题: failure如何同时被 应用级别的 Libraries 和 envoy 处理?
答: 假设同一个服务有两个 failure recovery policies, 更严格的policy 会触发 failure 的发生. 例如, 你有两个 timeouts, 假设在应用中设置了5s超时, 在 envoy 中设置了 10s超时, 那么应用的超时会先触发.

Fault injection

既然 envoy 提供了 服务的 failure recovery 机制, 那么同时使用 envoy 来进行 end-to-end 的 failure recovery capability 也势在必行.
错误配置的 failure recovery policies 会引起持续的关键服务的不可用, 这会导致可怜的用户体验.

istio 能够进行 protocol-specific fault injection into the network, 而不用 杀掉 pods 或 延迟或破坏 TCP层的包. 这样做的理由是, 无论网络级故障如何，应用层观察到的故障都是相同的，并且可以在应用层注入更有意义的故障（例如，HTTP错误代码）以实现应用程序的弹性。

5. Rule configuration

istio 提供了一个简单的配置模型 用于控制在不同服务之间的 API调用和layer-4 traffic flow.
这个配置模型允许你配置 服务级别的 属性,例如 ircuit breakers, timeouts, and retries, 还能配置持续的发布,例如 canary rollouts, A/B testing, staged rollouts with %-based traffic splits 等等.

在 istio 中有 4 个关于 traffic management 的配置资源:

• VirtualService: VirtualService 定义了 在服务网格内 对一个 istio服务 的请求应该如何被路由. 例如到某个 destination rule 或 某个k8s中的服务.
• DestinationRule: DestinationRule 配置不同版本的服务.
• ServiceEntry: ServiceEntry 一般用于让应用可以访问istio服务网格之外的服务.
• Gateway: Gateway 为 HTTP/TCP traffic 配置一个 load balancer , 一般工作于网格边缘,作为整个应用的入口

VirtualService

简单的定义

下面的 VirtualService 定义了 将访问 istio中的reviews 服务的100%流量都路由到 k8s中的 reviews 服务的v1版本

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

VirtualService 可以基于 请求的 source 和 destination, HTTP paths 和 header fields, 服务的不同版本的权重等信息对请求进行路由.

Routing rules(路由规则) 对应于 在 VirtualService 的配置中指定的一个或多个 destination hosts . 这些 hosts 可能和实际的 destination 负载相同,也可能不同, 甚至可能是网格中不可路由的服务.
例如, 要定义 请求 reviews 的服务, 可以通过其内部的网格服务名称 review 或 通过主机 bookinfo.com , VirtualService 可以这样定义它的 hosts field :

 hosts:
  - reviews
  - bookinfo.com

host 字段隐式指定或显式指定一个或多个 FQDN(fully qualified domain names). 对于短的名称 reviews ,它会被隐式地扩展成特定的FQDN, 例如在k8s环境中,它的FQDN可能是 reviews.default.svc.cluster.local
然后在服务网格内, envoy会劫持请求,根据请求的Host决定如何路由请求
VirtualService 定义的服务在 k8s 集群内是不可用的, 而且其定义的路由规则在k8s集群内也是无效的
以上是我猜的 :-)

路由规则可以将请求按权重路由到不同版本的服务.例如

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

路由规则可以设置超时和重试. 例如

( HTTP请求的timeout值默认是 15s )
( 注意: 请求的超时和重试 定义也可以被 per-request basis 覆盖, 即服务的消费者也可以通过特定的HTTP请求头 来覆盖默认的 timeout 和 重试次数, 在 envoy 作为proxy时,这些头是 x-envoy-upstream-rq-timeout-ms and x-envoy-max-retries )

# 设置超时返回
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
    - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s


---
# 设置重试次数
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
    - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

路由规则可以设置注入故障(延时或丢弃). 例如

# 设置10%的流量延迟5s
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percent: 10
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

---
# 设置10%的流量返回400错误码
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      abort:
        percent: 10
        httpStatus: 400
    route:
    - destination:
        host: ratings
        subset: v1

---
# 有时,delay 和 abort 可以结合起来使用,
# 例如下面的例子就表示所有来自 reviews-v2的服务到 ratings的服务都被路由到v1版本,并且设置固定延迟5s, 并丢弃 10% 的流量(使用返回码400)  
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    fault:
      delay:
        fixedDelay: 5s
      abort:
        percent: 10
        httpStatus: 400
    route:
    - destination:
        host: ratings
        subset: v1

条件路由. 例如可以匹配如下条件:

• 基于指定的client workload ( 通过 workload labels ) . 例子:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
      sourceLabels:
        app: reviews
    ...

sourceLabels 基于service的实现,在k8s平台上, 它一般和k8s中的服务的pod selector相同.

• 基于 HTTP headers. 如果定义了多个header,则表示要同时匹配,而不是任意匹配 , 例子:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    ...

• 基于 request URI. , 例子:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
    - productpage
  http:
  - match:
    - uri:
        prefix: /api/v1
    ...

多个匹配条件

如果同时配置了多个匹配条件, 此时,是使用 AND 还是 OR ,则基于它们是如何组织的.

如果写在同一个 match 中就是 AND 关系,例如:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
      headers:
        end-user:
          exact: jason
    ...

如果写在不同的 match 中就是 OR 关系,例如:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    - headers:
        end-user:
          exact: jason
    ...

优先级

当同时有多个规则能匹配到一个给定的目标, 它们按照在 VirtualService 中出现的顺序评估, 即先出现的规则有更高的优先级.

为什么优先级很重要? 基于权重的到某个特定服务的路由, 在任何时候它都可以指定在一个单独的规则中. 但是, 当其他条件(例如是来自于某个特定用户的请求)用于路由traffic时, 需要使用不同的规则来指定路由. 这时就必须要小心考虑规则的优先级, 以确保规则以正确的顺序 evaluated .

一般的模式是把匹配条件最多的规则放在前面, 把基于权重的没有任何匹配条件的规则放在最后.
例如:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        Foo:
          exact: bar
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Destination rules

DestinationRule 配置在 VirtualService 路由发生之后 应用到请求上的规则.
它们应该由服务所有者编写, 描述 circuit breakers, load balancer settings, TLS settings, 和其他设置
DestinationRule 还定义了 subsets , 即可命名的版本. 这些 subsets 用于VirtualService路由规范, 将流量发送到特定版本的服务.
例子:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3

注意在这个例子中, 在但一个单独的 DestinationRule 中定义了 默认的policies 和 v2-特定的 policies.

Circuit breakers

一个简单的断路器可以基于 connection 或 request 的数量限制.
下面的例子定义了 100个连接的断路器:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

Rule evaluation
和路由规则类似, 定义在 DestinationRule 中的 policies 和一个特定的 host 相关联.
但是, 如果它们是基于特定 subset 的, 则是否激活取决于 Virtual Service 的路由结果.

rule评估过程的第一步是 根据请求的 host 评估VirtualService 中的 路由规则(如果存在的话), 来决定路由到目标服务的哪个版本(subset), 然后是 决定哪个subset(如果是路由到了某个subset)的policies被实施.
注意: 一定要时刻记住 subset 设定的policies只有在显式地被路由到时才会被实施.
例如: 如下的配置 只定义了一个服务版本 v1, 同时也没有对应的 VirtualService 定义:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

既然没有对应的 VirtualService 定义, 那么现在你在 "服务网格" 内访问 reviews 服务, 会使用默认的 round-robin 路由行为, 当然这肯定会路由到 v1 版本的reviews, 但是 v1 版本中定义的断路器policies 是永远不会被实施的, 因为默认的路由已经在底层完成, rule评估引擎不知道最终的目标,也就不难匹配subset的policies
你可以使用两种方式来修复上面的问题.
一种方式将 policies 定义成默认policies, 这样这些策略就会被任意的版本实施, (此时如何显式路由到某个特定版本,那么实施的policies是在默认policies的基础上实施,还是仅仅加载特定版本自己配置的policies? 个人感觉应该是前者) , 如下所示:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
  subsets:
  - name: v1
    labels:
      version: v1

或者更好的办法是使用 VirtualService 显式定义路由到 v1 版本

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

虽然 istio 仅仅使用默认的行为就可以方便地将流量从任何源发送到目标服务的所有版本而不需要任何policies, 但是只要需要版本区分，就需要规则. 因此, 从一开始就为每个服务设置默认规则通常被认为是Istio中的最佳实践

Service entries

ServiceEntry 用于将其他条目添加到Istio内部维护的服务注册表中。
它最常用于启用对Istio服务网格之外的服务的请求。
例如，以下ServiceEntry可用于允许对 *.foo.com 域下托管的服务进行外部调用：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: foo-ext-svc
spec:
  hosts:
  - *.foo.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: https
    protocol: HTTPS

ServiceEntry 的目标由 hosts 字段指定, 它可以是 fully qualified 或 wildcard domain name. 它代表了一组服务的 white list , 这组服务可以被网格内的服务访问.

ServiceEntry 不仅可以配置外部服务. 它可以有 2 种类型: 网格内部或网格外部.
网格内部的条目 和网格内的其他服务类似, 但是它用于显式地向网格内添加服务. 这样的服务可以作为服务网格的扩展, 用来包含那些不被基础架构托管的服务(例如添加到基于Kubernetes的服务网格的VM).
网格外部的条目 表示网格外部的服务. 对于它们来说, 服务直接的 TLS 身份验证被禁用, 并且 policy 实施策略由 client-side 自己完成, 而不是和在网格内请求服务那样由服务器端完成(?在网格内服务端envoy做了policy了吗?).

ServiceEntry 也可以和 VirtualService 一起工作. 例子:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bar-foo-ext-svc
spec:
  hosts:
    - bar.foo.com
  http:
  - route:
    - destination:
        host: bar.foo.com
    timeout: 10s

如下的规则(redirect and forward traffic, to define retry, timeout, and fault injection policies)都适用于 外部服务, 但是基于版本的路由就不行了, 因为服务的版本定义要用到标签, 而外部服务没有这些.

Gateways

Gateway 配置一个 load balancer ,用于 HTTP/TCP traffic, 一般在 服务网格的边缘运行, 作为访问应用的入口.

和 k8s Ingress 不同, istio Gateway 只配置 L4-L6 层的功能(例如, 暴露端口,TLS 配置). 然后用户通过给 Gateway 绑定一个 VirtualService 就可以使用标准的 istio rules 控制进入到 Gateway的 HTTP 请求 和 TCP traffic .

例如下面的 Gateway 配置了一个 load balancer 允许外部的 HTTPS traffic 访问 bookinfo.com 到服务网格中:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - bookinfo.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

要配置对应的路由, 你必须定义一个使用相同 host 的 VirtualService , 并且该 VirtualService 还必须使用 gateways 字段绑定到该 Gateway :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - bookinfo.com
  gateways:
  - bookinfo-gateway # <---- bind to gateway
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    ...

要配置一个完整的 Ingress Gateway, 还需要下面的步骤
https://istio.io/docs/tasks/traffic-management/ingress/

简单步骤如下:

(1) 执行下面的命令确定你的k8s集群是否支持 external load balancer:

$ kubectl get svc istio-ingressgateway -n istio-system
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                      AGE
istio-ingressgateway   LoadBalancer   172.21.109.129   130.211.10.121  80:31380/TCP,443:31390/TCP,31400:31400/TCP   17h

如果 EXTERNAL-IP 是 <none> 或 一直是 <pending> , 那说明你的环境还没有为 Ingress Gateway 提供一个 external load balancer , 你可以使用 service's node port 来访问 Gateway.

可以看到 istio 在 istio-system 命名空间中部署了一个 istio-ingressgateway 服务, 我们就是要通过这个服务作为访问 gateway 的入口

如果你的环境支持 external load balancer , 可以使用下面的命令获取外部负载均衡器的IP和端口信息作为 INGRESS_HOST 和 INGRESS_PORT :

$ export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
$ export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')

注意: 如果 external load balancer 使用的是 host name 而不是 IP 地址, 那么获取 INGRESS_HOST 就要使用下面的命令:

$ export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

如果你的环境不支持 external load balancer , 可以使用下面的命令获取 istio-istio-ingressgateway 服务的NodePort信息作为 INGRESS_PORT :

$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
$ export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')

然后在根据 k8s 的部署环境获取 INGRESS_HOST , 一般就直接设置为当前主机的 IP地址 就可以.

(2) 使用 istio gateway 配置 ingress :

然后配置 gateway 和 VirtualService ,如下所示:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway # Gateway会应用为代理到具有标签 istio: ingressgateway 的pod上, 同时 istio 会配置 proxy 监听这些端口, 用户需要负责确保pod的这些端口可以被访问 
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "httpbin.example.com"
EOF


cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "httpbin.example.com"
  gateways:
  - httpbin-gateway
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: /delay
    route:
    - destination:
        port:
          number: 8000
        host: httpbin
EOF

现在可以尝试访问 httpbin 服务(这里没有说明如何部署 httpbin 服务, 你需要自己去部署,或者部署一个别的服务,改一改设置):
curl -I -HHost:httpbin.example.com http://$INGRESS_HOST:$INGRESS_PORT/status/200
注意 -HHost:httpbin.example.com 设置消息头的作用

如果你要使用浏览器访问 ingress service ?
浏览器不能像curl一样设置请求头中的Host信息, 但在现实世界中这也不是一个问题, 因为你可以正确的配置host或使用DNS可以解析的域名.
要想测试和做示例, 你可以使用 * 作为 Gateway 和 VirtualService 的 host.

配置一个完整的 Ingress Gateway 介绍完毕.

虽然 Gateway 主要用于管理 Ingress traffic , 但它也可以被用于建模纯内部的或egress代理.
无论其位置如何, 所有的 Gateway 都可以以相同的方式被配置和控制.
请参阅 Gateway reference 了解详情.

二. Security

三. Policies and Telemetry

Istio 提供了一种灵活的模型 来实施 authorization policies 和 收集网格中服务的 telemetry .

底层架构负责提供用于构建服务的功能. 这些功能包括 访问控制系统, telemetry 收集系统, 配额实施系统, 计费系统等等. 传统上, 服务直接与底层架构集成, 这构成了 硬耦合和 baking-in specific semantic 和 usage options.

istio 提供了一个统一的抽象模型, 这使得 istio 可以与一组开放式的底层架构交互.
这样做是为了向运营商提供丰富和深入的控制，同时不给服务开发者带来负担.
istio 旨在改变层之间的界限, 以降低系统复杂性, 从 service 代码中消除 policy logic 并给予用户控制权.
Mixer 是 istio 组件, 它负责提供 policy controls 和 收集 telemetry .

Envoy sidecar 在每次请求之前先调用 Mixer 执行前置条件检查, 并在请求之后报告 telemetry.
sidecar 会在本地缓存这些检查策略, 因此可以使用缓存执行大部分前置检查条件.
另外, sidecar 也会缓冲 outgoing telemetry, 使得它不用那么频繁的调用 Mixer.

At a level , Mixer 提供了:

• Backend Abstraction: 后端抽象, Mixer 将 istio的其他部分与底层架构的实现细节 隔离开来.
• Intermediation: 中介, Mixer 允许操作者对 网格和底层架构 之间的交互进行 细粒度的控制.

除了这些功能之外, Mixer 还具有如下所述的可靠性和可扩展性优势:
Policy 实施和telemetry 收集完全由配置来驱动, 你可以完全禁用这些特色并避免在部署istio时运行 Mixer 组件.

1. Adapters

Mixer 是一个高度 模块化和可扩展的组件.
其关键功能之一就是抽象出 不同policy和telemetry 后端系统的细节, 允许 istio 的其他部分与这些后端无关.

Mixer 的这种可以处理不同底层架构后端的灵活性来自于它的 通用插件模型.
插件就是 Adapters, 它们允许 Mixer 连接到不同的底层架构后端提供核心功能, 例如 logging, monitoring, quotas, ACL checking 等等.
使用哪些Adapter是在运行时配置的, 并且可以轻松地扩展到新的目标或自定义的后端架构.

2. 可靠性和延迟

Mixer 是一个高可用的组件 :

• Statelessness 无状态: Mixer 是无状态的, 所以它不会管理任何的持续性存储.
• Hardening : 强壮: Mixer 的目标是被设计为一个高可靠的组件. 每个单独的 Mixer 实例提供 99.999% 的 uptime
• Caching and Buffering:

四. Performance and Scalability