默认状况下，来自启用Istio的Pod的所有出站流量都会重定向到其Sidecar代理，因而集群内部URL的可拜访性取决于代理的配置。网格中的工作负载想要拜访网分外的服务时，有以下三种办法：

  1. 容许Envoy代理将申请透传到未在网格外部配置的服务。
  2. 配置 ServiceEntries 以提供对外部服务的受控拜访。
  3. 对于特定范畴的IP，齐全绕过Envoy代理。

默认Istio将Envoy代理配置为透传对未知服务的申请，这简化了利用程序开发以及现有应用程序到网格的迁徙。

第2种办法，应用Istio ServiceEntry配置，您能够从Istio集群中拜访任何可公开拜访的服务。而且不失落Istio的流量监督和管制性能。该办法也是本文次要讲述的办法。

对于第三种办法，通过global.proxy.includeIPRanges配置。对于一些对性能要求比拟高的利用能够抉择应用，然而须要保障IP范畴在一个可信的环境下。

代理出站流量策略模式

Istio有一个装置选项meshConfig.outboundTrafficPolicy.mode，用于配置对外部服务（即Istio外部服务注册表中未定义的那些服务）的解决形式。如果此选项设置为ALLOW_ANY，则Istio代理将容许对未知服务的调用。如果该选项设置为REGISTRY_ONLY，则Istio代理将阻止在网格中未定义HTTP服务或ServiceEntry的任何主机。

默认状况下，ALLOW_ANY为该配置项的默认值。

ServiceEntry

ServiceEntry是扩大Istio服务注册表的一种形式，以便现有的主动发现的服务能够拜访其余服务，无论它们是未发现的外部服务还是齐全在网格内部的服务（例如，Web API）。

通过配置ServiceEntry，您能够治理在网格内部运行的服务的流量，包含以下性能：

  • 重定向和转发用于内部指标的流量，例如从网络应用的API或到旧根底构造中服务的流量。
  • 为内部指标定义重试，超时和故障注入策略。
  • 通过将虚拟机增加到网格中，在虚拟机（VM）中运行网格服务。
  • 在逻辑上将来自其余集群的服务增加到网格，以在Kubernetes上配置多集群Istio网格。

以下示例形容了外部应用程序应用DNS通过主机名解析通过HTTP拜访的内部API。

apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: httpbin.org  namespace: foospec:  hosts:  - httpbin.org  - www.httpbin.org  ports:  - number: 80    name: http    protocol: HTTP  exportTo:  - "."  resolution: DNS  location: MESH_EXTERNAL

咱们对该配置逐个字段解析：

  • hosts：DNS名称。能够具备通配符前缀。
  • ports：关联的端口。
  • ports.protocol： 以下之一：HTTP，HTTPS，HTTP2，GRPC，MONGO，TCP或TLS。
  • exportTo：默认状况下应用“*”，这意味着该ServiceEntry公开给每个命名空间。 “.”仅将其限度为以后命名空间。目前，exportTo值仅限于这两个。
  • resolution：主机的服务发现模式
  • location：从网格的角度来看，应将此服务视为外部或内部服务。

这里的字段并不是ServiceEntry反对的所有字段，更多请查看官网文档。

Demo

该demo咱们不仅仅是演示如何通过ServiceEntry拜访内部服务，而且是演示如何对外部服务定义注入超时等策略。

1: 部署之前先部署咱们的sleep pod，作为网格内的工作负载。因为咱们在之前的文章中曾经部署实现，所以这里略过。

kubectl get pods -n fooNAME                       READY   STATUS    RESTARTS   AGEhttpbin-779c54bf49-dqmgm   2/2     Running   0          27hsleep-d6b58ff57-jl8pq      2/2     Running   0          27h

2: 将下面示例ServiceEntry利用到集群中。

kubectl apply -f - <<EOFapiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: httpbin.org  namespace: foospec:  hosts:  - httpbin.org  - www.httpbin.org  ports:  - number: 80    name: http    protocol: HTTP  exportTo:  - "."  resolution: DNS  location: MESH_EXTERNALEOF

3：从sleep的Pod外部，向http://httpbin.org内部服务的/delay端点收回curl申请：

$ kubectl exec sleep-d6b58ff57-jl8pq -c sleep -n foo -- time curl -o /dev/null -s -w "%{http_code}n" http://httpbin.org/delay/5200real    0m 5.70suser    0m 0.00ssys    0m 0.00s

该申请应在大概5秒钟内返回200(OK)。

4: 对外部服务httpbin.org减少超时设置，咱们须要创立一个VirtualService如下：

$ kubectl apply -f - <<EOFapiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: httpbin.org  namespace: foospec:  hosts:    - httpbin.org    - www.httpbin.org  http:  - timeout: 3s    route:      - destination:          host: httpbin.org        weight: 100EOF

5: 再次从sleep的Pod外部，向http://httpbin.org内部服务的/delay端点收回curl申请：

kubectl exec sleep-d6b58ff57-jl8pq -c sleep -n foo -- time curl -o /dev/null -s -w "%{http_code}n" http://httpbin.org/delay/5504real    0m 3.01suser    0m 0.00ssys    0m 0.00s

这次3秒后呈现504(网关超时)。只管http://httpbin.org期待5秒，但Istio却在3秒时截断了申请。

总结

事实的世界中，并不能做到所有的业务都容器化，Istio也意识到了这个问题，所以正在反对非容器部署的业务。除了ServiceEntry，又减少了WorkloadEntry，从而反对将vm部署的业务纳入mesh中。