Egress Gateway逻辑示意图

image

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

控制出口流量描述了如何通过ServiceEntry将外部服务暴露给集群内的客户端

本文则通过一个官方的用例解释如何通过Egress Gateway配置Istio的出口流量，这个例子主要适用于两种场景：

1. 离开服务网格的所有流量必须流经一组专用节点，这一组节点会有特殊的监控和审查
2. 集群中不是所有节点都有public IP，定义egress网关，通过它引导所有出口流量并将public IP分配给egress网关节点，允许应用节点以受控方式访问外部服务

原理

根据官方文档的解释：

Gateway 描述了一个负载均衡器，用于承载网格边缘的进入和发出连接。这一规范中描述了一系列开放端口，以及这些端口所使用的协议、负载均衡的 SNI 配置等内容。

之前的 Service Entry 一文中讲到了 ServiceEntry 对象，让网格内部的应用在访问外部应用时，可以使用 VirtualService 进行部分控制。但是如果我们进一步尝试策略的话，会发现常用的 Denier 等适配器都是无效的（这点并没有经过官方验证）。这里就需要使用刚才说的 Egress Gateway 了。

根据官方示例介绍，这种方式的基本访问流程是：

1. 建立 Service Entry 对象，注册外部服务。
2. 建立 Egress Gateway 注册出口。
3. 创建 DestinationRule，定义一个到 istio-egressgateway.istio-system.svc.cluster.local 服务 的目标规则。
4. 创建 VirtualService 对象，这一对象对主机名 edition.cnn.com 生效：
   • 如果流量发生在 mesh gateway，则把请求转发给 istio-egressgateway.istio-system 服务。
   • 如果流量发生在 egress gateway，则把请求转发到外部。

开始之前

跟前文一样，需要部署两个版本的 sleep 服务。源码见后。

$ istioctl kube-inject -f sleep-v1v2.yaml | kubectl apply -f -
service/sleep created
deployment.extensions/sleep-v1 created
deployment.extensions/sleep-v2 created

接下来把两个版本的 Pod 分别保存到环境变量之中。

$ export SLEEP_V1=$(kubectl get pod -l app=sleep,version=v1 -o jsonpath={.items..metadata.name})
$ export SLEEP_V2=$(kubectl get pod -l app=sleep,version=v2 -o jsonpath={.items..metadata.name})
$ env | grep SLEEP
SLEEP_V2=sleep-v2-69f4fc6c68-s9d96
SLEEP_V1=sleep-v1-d5b4f795f-fcrxs

再建立一个 ServiceEntry，完成准备工作。

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
 name: httpbin-ext
spec:
 hosts:
   - httpbin.org
 ports:
   - number: 80
     name: http
     protocol: HTTP
 resolution: DNS

设立别名并确认可访问性：

$ alias S1_HTTPBIN="kubectl exec -it $SLEEP_V1 -c sleep -- curl http://httpbin.org/ip"
$ alias S2_HTTPBIN="kubectl exec -it $SLEEP_V2 -c sleep -- curl http://httpbin.org/ip"
$ S1_HTTPBIN
{
 "origin": "13.67.109.88"
}

成功返回。

创建 Gateway 和 DestinationRule

建立 Gateway

这里为域名 “httpbin.org” 创建一个网关，selector 字段表明这里使用的是 Egress gateway。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: httpbin-gateway
spec:
 selector:
   istio: egressgateway
 servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:
       - httpbin.org

为服务 istio-egressgateway 创建一个目标规则

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: dest-rule-httpbin
spec:
 host: istio-egressgateway.istio-system.svc.cluster.local
 subsets:
   - name: ext

上面的 host 字段使用了 istio-egressgateway 的 FQDN，指向 istio-system 命名空间。

创建 VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: vs-httpbin
spec:
 hosts:
   - httpbin.org # 这一对象对域名 “httpbin.org” 生效。
 gateways: # 本对象所针对的 Gateway。
   - httpbin-gateway # 前面为 “httpbin.org” 注册的 Egress gateway。
   - mesh # 内置 Gateway，代表网格中的所有 Sidecar
 http:
   - match: # 这一条规则匹配的是 “mesh” Gateway 的流量
       - gateways:
           - mesh
         port: 80
     route: # 如果是 “mesh” gateway 的流量，则转发到 egress 网关服务。
       - destination:
           host: istio-egressgateway.istio-system.svc.cluster.local
           subset: ext
           port:
             number: 80
         weight: 100
   - match:
       - gateways: # 这一条规则匹配的是外发流量
           - httpbin-gateway
         port: 80
     route: # 通过 Service Entry 流向目标的外网流量
       - destination:
           host: httpbin.org
           port:
             number: 80
         weight: 100

这一对象创建之后，我们再次尝试访问 “http://httpbin.org/ip” ：

$ S1_HTTPBIN
{
 "origin": "10.240.0.41, 13.67.109.88"
}

可以看到访问成功，并且返回地址中因为转发的原因，代入了 Pod IP。

如果查看 Egress gateway controller 的日志，也会看到这一访问的踪迹：

$ kubetail  egress -n istio-system
Will tail 1 logs...
istio-egressgateway-55449548bd-99mvl
[istio-egressgateway-55449548bd-99mvl] [2018-08-25T15:07:29.272Z] "GET /ip HTTP/2" 200 - 0 44 477 473 "10.240.0.41" "curl/7.35.0" "e9cc4d93-7617-9f97-b29e-3411c3b66543" "httpbin.org" "52.73.140.127:80"

加入策略限制

经过上面一番折腾之后，应用对外部网站的请求就有了一段完全在网格内的部分，接下来就可尝试使用策略了。