控制 Egress 流量

本文主要内容来自 Istio 官方文档，并对其进行了大量扩展和补充。

缺省情况下，Istio 服务网格内的 Pod，由于其 iptables 将所有外发流量都透明的转发给了 Sidecar，所以这些集群内的服务无法访问集群之外的 URL，而只能处理集群内部的目标。

本文的任务描述了如何将外部服务暴露给 Istio 集群中的客户端。你将会学到如何通过定义 ServiceEntry 来调用外部服务；或者简单的对 Istio 进行配置，要求其直接放行对特定 IP 范围的访问。

开始之前
#

根据安装指南的内容，部署 Istio。
启动 sleep 示例应用，我们将会使用这一应用来完成对外部服务的调用过程。如果启用了 Sidecar 的自动注入功能，运行：

$ kubectl apply -f samples/sleep/sleep.yaml

否则在部署 sleep 应用之前，就需要手工注入 Sidecar：

$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)

实际上任何可以 exec 和 curl 的 Pod 都可以用来完成这一任务。

Istio 中配置外部服务
#

通过配置 Istio ServiceEntry，可以从 Istio 集群中访问外部任意的可用服务。这里我们会使用 httpbin.org 以及 www.baidu.com 进行试验。

配置外部服务
#

1. 创建一个 ServiceEntry 对象，放行对一个外部 HTTP 服务的访问：

$ cat <<EOF | istioctl create -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin-ext
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
EOF

2. 另外创建一个 ServiceEntry 对象和一个 VirtualService，放行对一个外部 HTTPS 服务的访问：

$ cat <<EOF | istioctl create -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: baidu
spec:
  hosts:
  - www.baidu.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: baidu
spec:
  hosts:
  - www.baidu.com
  tls:
  - match:
    - port: 443
      sniHosts:
      - www.baidu.com
    route:
    - destination:
        host: www.baidu.com
        port:
          number: 443
      weight: 100
EOF

发起对外部服务的访问
#

使用 kubectl exec 命令进入测试 Pod。假设使用的是 sleep 服务，运行如下命令：

$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o go-template='{{range .items}}{{.metadata.name}}{{end}}')
$ kubectl exec -it $SOURCE_POD -c sleep bash

发起一个对外部 HTTP 服务的请求：

$ curl http://httpbin.org/headers

发起一个对外部 HTTPS 服务的请求：

$ curl https://www.baidu.com

HTTP ServiceEntry 配置深度解析
#

按照之前的惯例，还是先来解读一下 HTTP 协议的 ServiceEntry 映射到 Envoy 配置层面具体是哪些内容，这样才能对 ServiceEntry 有更加深刻的认识。

创建一个 HTTP 协议的 ServiceEntry（不指定 GateWay）本质上是在服务网格内的所有应用的所有 Pod上创建相应的路由规则和与之对应的 Cluster。指定 GateWay 的 ServiceEntry 遵循的是另一套法则，后面我们再说。

可以通过 istioctl 来验证一下（以 httpbin-ext 为例）：

# 查看 sleep 的 Pod Name：
$ kubectl get pod -l app=sleep

NAME                     READY     STATUS    RESTARTS   AGE
sleep-5bc866558c-89shb   2/2       Running   0          49m

查看路由

$ istioctl pc routes sleep-5bc866558c-89shb --name 80 -o json

[
    {
        "name": "80",
        "virtualHosts": [
            {
                "name": "httpbin.org:80",
                "domains": [
                    "httpbin.org",
                    "httpbin.org:80"
                ],
                "routes": [
                    {
                        "match": {
                            "prefix": "/"
                        },
                        "route": {
                            "cluster": "outbound|80||httpbin.org",
                            "timeout": "0.000s",
                            "maxGrpcTimeout": "0.000s"
                        },
                        "decorator": {
                            "operation": "httpbin.org:80/*"
                        },
...

可以看到从 Pod sleep-5bc866558c-89shb 内部对域名 httpbin.org 发起的请求通过 HTTP 路由被定向到集群 outbound|80||httpbin.org。outbound 表示这是出站流量

查看 Cluster：

$ istioctl pc clusters sleep-5bc866558c-89shb --fqdn httpbin.org -o json

[
    {
        "name": "outbound|80||httpbin.org",
        "type": "ORIGINAL_DST",
        "connectTimeout": "1.000s",
        "lbPolicy": "ORIGINAL_DST_LB",
        "circuitBreakers": {
            "thresholds": [
                {}
            ]
        }
    }
]

type : 服务发现类型。ORIGINAL_DST 表示原始目的地类型，大概意思就是：连接进入之前已经被解析为一个特定的目标 IP 地址。这种连接通常是由代理使用 IP table REDIRECT 或者 eBPF 之类的机制转发而来的。完成路由相关的转换之后，代理服务器会将连接转发到该 IP 地址。httpbin.org 是外网域名，当然可以解析，所以连接进入之前可以被解析为一个特定的目标 IP 地址。Envoy 服务发现类型的详细解析可以参考： Service discovery。ServiceEntry.Resolution 字段的解析可以参考： ServiceEntry.Resolution。
这里我简要说明一下，ServiceEntry 的 resolution 字段可以取三个不同的值，分别对应 Envoy 中的三种服务发现策略：
- NONE : 对应于 Envoy 中的 ORIGINAL_DST。如果不指定 resolution 字段，默认使用这个策略。
- STATIC : 对应于 Envoy 中的 STATIC。表示使用 endpoints 中指定的静态 IP 地址作为服务后端。
- DNS : 对应于 Envoy 中的 STRICT_DNS。表示处理请求时尝试向 DNS 查询 IP 地址。如果没有指定 endpoints，并且没有使用通配符，代理服务器会使用 DNS 解析 hosts 字段中的地址。如果指定了 endpoints，那么指定的地址就会作为目标 IP 地址。
lbPolicy : 负载均衡策略。ORIGINAL_DST_LB 表示使用原始目的地的负载均衡策略。具体参考: Load balancing。

如果你还部署了 bookinfo 示例应用，可以通过执行 istioctl pc routes <productpage_pod_name> --name 80 -o json 和 istioctl pc clusters <productpage_pod_name> --fqdn httpbin.org -o json 来验证一下，你会发现输出的结果和上面一模一样。如果还不放心，可以查看 bookinfo 应用内的所有 Pod，你会得到相同的答案。至此你应该可以理解在服务网格内的所有应用的所有 Pod上创建相应的路由规则和与之对应的 Cluster这句话的含义了。

HTTPS ServiceEntry 配置深度解析
#

HTTPS 协议的 ServiceEntry 与 Envoy 配置文件的映射关系与 HTTP 协议有所不同。

创建一个 HTTPS 协议的 ServiceEntry（不指定 GateWay）本质上是在服务网格内的所有应用的所有 Pod上创建相应的监听器和与之对应的 Cluster。指定 GateWay 的 ServiceEntry 我会另行发文详说。

可以通过 istioctl 来验证（以 baidu 为例）。为了更精确地分析该 ServiceEntry，可以先把 VirtualService 删除：

$ istioctl delete virtualservice baidu

查看监听器：

$ istioctl pc listeners sleep-5bc866558c-89shb --address 0.0.0.0 --port 443 -o json

[
    {
        "name": "0.0.0.0_443",
        "address": {
            "socketAddress": {
                "address": "0.0.0.0",
                "portValue": 443
            }
        },
        "filterChains": [
            {
                "filters": [
                    ...
                    {
                        "name": "envoy.tcp_proxy",
                        "config": {
                            "cluster": "outbound|443||www.baidu.com",
                            "stat_prefix": "outbound|443||www.baidu.com"
                        }
                    }
...

name : 监听器过滤器的名称。该字段的值必须与 Envoy 所支持的过滤器匹配，不可随意填写，具体参考： listener.Filter。此处 envoy.tcp_proxy 表示使用 TCP 代理，而 TCP 代理是无法基于路由过滤的，所以这里不会创建路由规则，而是直接将请求转到 Cluster。

查看 Cluster：

$ istioctl pc clusters sleep-5bc866558c-89shb --fqdn www.baidu.com -o json

[
    {
        "name": "outbound|443||www.baidu.com",
        "type": "STRICT_DNS",
        "connectTimeout": "1.000s",
        "hosts": [
            {
                "socketAddress": {
                    "address": "www.baidu.com",
                    "portValue": 443
                }
            }
        ],
        "circuitBreakers": {
            "thresholds": [
                {}
            ]
        },
        "dnsLookupFamily": "V4_ONLY"
    }
]

从监听器的配置来看，由于绑定的是 0.0.0.0，而且也没有指定域名，看起来应该可以访问集群外任何 443 端口的服务。实际上这是行不通的，因为当请求通过监听器转到 Cluster 之后，由于 Cluster 采用的是严格的 DNS 服务发现策略，只要域名不是 www.baidu.com，都不会解析。你可以使用 kubectl exec 命令进入 sleep Pod 来测试一下：

$ kubectl exec -it $SOURCE_POD -c sleep bash

发起对外部 HTTPS 服务的请求：

$ curl https://www.163.com
curl: (51) SSL: no alternative certificate subject name matches target host name 'www.163.com'

$ curl https://www.taobao.com
curl: (51) SSL: no alternative certificate subject name matches target host name 'www.taobao.com'

$ curl https://192.192.192.192
curl: (51) SSL: certificate subject name 'baidu.com' does not match target host name '192.192.192.192'

而如果你将服务发现策略改为 NONE，就会发现除了可以访问 www.baidu.com，还可以访问 www.163.com 和 www.taobao.com 等其他 https 协议的网站，至于为什么会这样，前面介绍服务发现策略的时候我已经详细解释过了。

TLS VirtualService 配置深度解析
#

关于 VirtualService 的解析之前的文章已有相关说明，不过这里的 VirtualService 与之前遇到的不同，涉及到了 TLSRoute。

tls : 透传 TLS 和 HTTPS 流量。TLS 路由通常应用在 https-、tls- 前缀的平台服务端口，或者经 Gateway 透传的 HTTPS、TLS 协议端口，以及使用 HTTPS 或者 TLS 协议的 ServiceEntry 端口上。具体参考： TLSRoute。
- sniHosts : 必要字段。要匹配的 SNI（服务器名称指示）。可以在 SNI 匹配值中使用通配符。比如 *.com 可以同时匹配 foo.example.com 和 example.com。
route : 流量的转发目标。目前 TLS 服务只允许一个转发目标(所以权重必须设置为 100)。当 Envoy 支持 TCP 权重路由之后，这里就可以使用多个目标了。

查看映射到 Envoy 中的配置：

$ istioctl pc listeners sleep-5bc866558c-89shb --address 0.0.0.0 --port 443 -o json

[
    {
        "name": "0.0.0.0_443",
        "address": {
            "socketAddress": {
                "address": "0.0.0.0",
                "portValue": 443
            }
        },
        "filterChains": [
            {
                "filterChainMatch": {
                    "serverNames": [
                        "www.baidu.com"
                    ]
                },
                "filters": [
                    ...
                    {
                        "name": "envoy.tcp_proxy",
                        "config": {
                            "cluster": "outbound|443||www.baidu.com",
                            "stat_prefix": "outbound|443||www.baidu.com"
                        }
                    }
...

filterChainMatch : 用于为监听器过滤器链指定匹配条件，具体参考： listener.FilterChainMatch。

最后我们来思考一下：既然不创建 TLS VirtualService 也可以访问 www.baidu.com，那么创建 TLS VirtualService 和不创建 TLS VirtualService 有什么区别呢？正确答案是：没有关联 VirtualService 的 https- 或者 tls- 端口流量会被视为透传 TCP 流量，而不是透传 TLS 和 HTTPS 流量。

为外部服务设置路由规则
#

通过 ServiceEntry 访问外部服务的流量，和网格内流量类似，都可以进行 Istio 路由规则的配置。下面我们使用 istioctl 为 httpbin.org 服务设置一个超时规则。

1. 在测试 Pod 内部，调用 httpbin.org 这一外部服务的 /delay 端点：

$ kubectl exec -it $SOURCE_POD -c sleep bash
$ time curl -o /dev/null -s -w "%{http_code}\n" http://httpbin.org/delay/5

200

real    0m5.024s
user    0m0.003s
sys     0m0.003s

这个请求会在大概五秒钟左右返回一个内容为 200 (OK) 的响应。

2. 退出测试 Pod，使用 istioctl 为 httpbin.org 外部服务的访问设置一个 3 秒钟的超时：

cat <<EOF | istioctl create -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin-ext
spec:
  hosts:
    - httpbin.org
  http:
  - timeout: 3s
    route:
      - destination:
          host: httpbin.org
        weight: 100
EOF

3. 等待几秒钟之后，再次发起 curl 请求：

$ kubectl exec -it $SOURCE_POD -c sleep bash
$ time curl -o /dev/null -s -w "%{http_code}\n" http://httpbin.org/delay/5

504

real    0m3.149s
user    0m0.004s
sys     0m0.004s

这一次会在 3 秒钟之后收到一个内容为 504 (Gateway Timeout) 的响应。虽然 httpbin.org 还在等待他的 5 秒钟，Istio 却在 3 秒钟的时候切断了请求。

直接调用外部服务
#

如果想要跳过 Istio，直接访问某个 IP 范围内的外部服务，就需要对 Envoy sidecar 进行配置，阻止 Envoy 对外部请求的劫持。可以在 Helm 中设置 global.proxy.includeIPRanges 变量，然后使用 kubectl apply 命令来更新名为 istio-sidecar-injector 的 Configmap。在 istio-sidecar-injector 更新之后，global.proxy.includeIPRanges 会在所有未来部署的 Pod 中生效。

使用 global.proxy.includeIPRanges 变量的最简单方式就是把内部服务的 IP 地址范围传递给它，这样就在 Sidecar proxy 的重定向列表中排除掉了外部服务的地址了。

内部服务的 IP 范围取决于集群的部署情况。例如你的集群中这一范围是 10.0.0.1/24，这个配置中，就应该这样更新 istio-sidecar-injector：

$ helm template install/kubernetes/helm/istio <安装 Istio 时所使用的参数> --set global.proxy.includeIPRanges="10.0.0.1/24" -x templates/sidecar-injector-configmap.yaml | kubectl apply -f -

注意这里应该使用和之前部署 Istio 的时候同样的 Helm 命令，尤其是 –namespace 参数。在安装 Istio 原有命令的基础之上，加入 --set global.proxy.includeIPRanges="10.0.0.1/24" -x templates/sidecar-injector-configmap.yaml 即可。

然后和前面一样，重新部署 sleep 应用。更新了 ConfigMap istio-sidecar-injector 并且重新部署了 sleep 应用之后，Istio sidecar 就应该只劫持和管理集群内部的请求了。任意的外部请求都会简单的绕过 Sidecar，直接访问目的地址。

$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o go-template='{{range .items}}{{.metadata.name}}{{end}}')
$ kubectl exec -it $SOURCE_POD -c sleep curl http://httpbin.org/headers

总结
#

这个任务中，我们使用两种方式从 Istio 服务网格内部来完成对外部服务的调用：

使用 ServiceEntry (推荐方式)
配置 Istio sidecar，从它的重定向 IP 表中排除外部服务的 IP 范围

第一种方式（ServiceEntry）中，网格内部的服务不论是访问内部还是外部的服务，都可以使用同样的 Istio 服务网格的特性。我们通过为外部服务访问设置超时规则的例子，来证实了这一优势。

第二种方式越过了 Istio sidecar proxy，让服务直接访问到对应的外部地址。然而要进行这种配置，需要了解云供应商特定的知识和配置。

清理
#

1. 删除规则：

$ istioctl delete serviceentry httpbin-ext baidu
$ istioctl delete virtualservice httpbin-ext baidu

2. 停止 sleep 服务：

$ kubectl delete -f samples/sleep/sleep.yaml

-------他日江湖相逢再当杯酒言欢-------

数据包在 Istio 网格中的生命周期（下）

2018年8月13日·2535 字·6 分钟·

服务网格 Istio Kubernetes

数据包在 Istio 网格中的生命周期（上）

2018年8月8日·3321 字·7 分钟·

服务网格 Istio Kubernetes

Istio 服务网格中的网关

2018年8月2日·2040 字·5 分钟·

服务网格 Istio

Vistio—使用 Netflix 的 Vizceral 可视化 Istio service mesh

2018年8月3日·1745 字·4 分钟·

服务网格 Istio

Istio 流量管理

2018年8月1日·3385 字·7 分钟·

服务网格 Istio

Istio 1.0 部署

2018年8月1日·1135 字·3 分钟·

服务网格 Istio

开始之前#

Istio 中配置外部服务#

配置外部服务#

发起对外部服务的访问#

HTTP ServiceEntry 配置深度解析#

HTTPS ServiceEntry 配置深度解析#

TLS VirtualService 配置深度解析#

为外部服务设置路由规则#

直接调用外部服务#

总结#

清理#

相关文章

开始之前
#

Istio 中配置外部服务
#

配置外部服务
#

发起对外部服务的访问
#

HTTP ServiceEntry 配置深度解析
#

HTTPS ServiceEntry 配置深度解析
#

TLS VirtualService 配置深度解析
#

为外部服务设置路由规则
#

直接调用外部服务
#

总结
#

清理
#