Istio如何使用相同的端口访问网格外服务

1.1、背景

写这篇文章的目的是为了说明以下问题：如何使用TCP协议相同的端口访问网格外多个服务？ 这是最近直播的时候有一个同学提出的，当时我没有完全明白，“访问多集群” 的意思。

后来仔细思考了一下，问题应该就是Istio服务网格内如何通过相同的协议，端口访问不同的服务。

1.2、使用场景

肯定会有人回答，既然相同的端口不能使用，何不换一个端口呢，这样做也是一种解决方法。

我在想有一些场景一定没法或者不方便绕过去。

1) 假如同一个网格内部署了生产，测试，开发三套环境，都需要通过3306端口访问对应环境的mysql数据库。

2) 假如同一个网格内部署了生产，测试，开发三套环境，都需要通过6379端口访问对应环境的redis。

在微服务盛行的今天，往往需要团队之间协作，没办法保证所有的微服务都运行在同一服务网格内。

尤其是中间件服务，作为公司公共服务，一定是业务共享的。

既然我们不可避免的需要使用相同的端口，访问外部服务，接下来告诉大家两种方案解决以上问题。

1.3、解决方案

通过相同的端口443访问 https://github.com 和 https://www.huaweicloud.com，从网格内访问外部服务，需要分别创建对应的ServiceEntentry：

1) www.huaweicloud.com

cat <
 
  
cat <
    
   
  
apiVersion: networking.istio.io/v1alpha3
  
kind: ServiceEntry
  
metadata:
  
name: github
  
spec:
  
hosts:
  
github.com
  
ports:
  
number: 443
  
name: tcp
  
protocol: TCP
  
resolution: DNS
  
location: MESH_EXTERNAL
  
EOF
  
两条规则建好之后，等待pilot将新的配置下发到所有的proxy，我们通过sleep pod验证连通性


  
$ kubectl exec sleep-754684654f-trpt2 -- curl -sL -o /dev/null https://www.huaweicloud.com –v

  
…

  
< HTTP/1.1 200 OK

  
< Server: NWSs

  
< Date: Fri, 21 Dec 2018 02:23:11 GMT

  
< Content-Type: text/html;charset=utf-8

  
< Content-Length: 703122

  
< Connection: keep-alive

  
< Cache-Control: public, max-age=600

  
< Expires: Fri, 21 Dec 2018 02:33:10 GMT

  
< Last-Modified: Thu, 20 Dec 2018 10:30:00 GMT

  
< X-NWS-LOG-UUID: 0d13017f-8767-4399-a509-6c11b2a9f3d0

  
< Access-Control-Allow-Origin: *

  
< dl-from: qcloud

  
< X-Cache-Lookup: Hit From Disktank3

  
< X-Via: LIANTONG-HENAN_171(200:hit)

  
<

  
{ [15930 bytes data]
Connection #0 to host www.huaweicloud.com left intact

  


  
kubectl exec sleep-754684654f-trpt2 -- curl -sL -o /dev/null https://github.com –v -k

  
…

  
< HTTP/1.1 404 Not Found

  
< Server: NWSs

  
< Date: Fri, 21 Dec 2018 02:29:26 GMT

  
< Content-Type: text/html

  
< Content-Length: 52

  
< Connection: keep-alive

  
< X-NWS-LOG-UUID: b283fee3-89e0-48bc-8d6e-0c3a68ecc4bf

  
< X-Via: LIANTONG-HENAN_25(404:hit)

  
<

  
{ [52 bytes data]
Connection #0 to host github.com left intact

  
由此可见可以在网格内部访问https://www.huaweicloud.com，但是不可以访问https://github.com. 这里有一个原因是istio会将ServiceEntry规则按照创建时间排序，创建时间较早的优先级高，所以先创建的 hwcloud ServiceEntry生效。



可以查看sleep pod上的配置来确认：listener配置只有到华为云的cluster "outbound|443||www.huaweicloud.com"


  
$ istioctl pc listener sleep-754684654f-trpt2 --address=0.0.0.0 --port=443 -ojson

  
[

  
{

    "name": "0.0.0.0_443",

    "address": {

        "socketAddress": {

            "address": "0.0.0.0",

            "portValue": 443

        }

    },

    "filterChains": [

        {

            "filters": [

                {

                    "name": "mixer",

                     …

                },

                {

                    "name": "envoy.tcp_proxy",

                    "config": {

                        "access_log": [

                            {

                              …

                            }

                        ],

                        "cluster": "outbound|443||www.huaweicloud.com",

                        "stat_prefix": "outbound|443||www.huaweicloud.com"

                    }

                }

            ]

        }

    ],

    …

}

  
]

  
为了同时访问两者，这里我提供两种方法：

1.3.1创建ServiceEntry时指定Address

查询www.huaweicloud.com域名绑定的ip地址，选择一个或者多个更新hwcloud ServiceEntry

同样的方法更新 github 

验证https://www.huaweicloud.com和https://github.com均可以从网格内访问，因为指定了spec.addresses 后，pilot生成listener使就会使用指定的ip地址代替‘0.0.0.0’的全匹配方式。



虽然着这种方式一定程度上可以解决同一端口访问外部服务的需求。

但是由于需要提前设置ip地址，所以在ip经常变动的场景下缺少灵活性。

下面提供一种更灵活的方法。



1.3.2 指定ServiceEntry的作用域

Istio社区最近实现了网络的配置作用域特性：https://github.com/istio/istio/pull/10287, 允许用户设置相应规则的作用域范围。



目前 ServiceEntry，VirtualService，Gateway， DestinationRule等都可以通过spec.configScope设置作用范围。

ConfigScope 可以设置为"PUBLIC"，"PRIVATE"类型。



"PUBLIC" 表示规则对网格内所有的工作负载可见，这也是默认值。



"PRIVATE" 表示规则仅对同一namespace下面的工作负载可见。



因此可以利用ConfigScope将github以及hwcloud都设置成PRIVATE，分别创建在两个不同的namespace下面。

这样也可以做到ns1内的工作负载访问https://github.com, ns2内的工作负载访问https://www.huaweicloud.com .


  
cat <
    
   

  
apiVersion: networking.istio.io/v1alpha3

  
kind: ServiceEntry

  
metadata:

  
name: github

  
namespace： ns1

  
spec:

  
hosts:

  
github.com

  
ports:

  
number: 443

  
name: tcp

  
protocol: TCP

  
resolution: DNS

  
location: MESH_EXTERNAL

  
configScope: PRIVATE

  
EOF

  
cat <
    
   

  
apiVersion: networking.istio.io/v1alpha3

  
kind: ServiceEntry

  
metadata:

  
name: hwcloud

  
namespace： ns2

  
spec:

  
hosts:

  
www.huaweicloud.com

  
ports:

  
number: 443

  
name: tcp

  
protocol: TCP

  
resolution: DNS

  
location: MESH_EXTERNAL

  
configScope: PRIVATE

  
EOF

  

ConfigScope这种方式非常适合前面提到的场景：在同一个微服务网格内同时部署生产，测试环境, 并且生产，测试环境都需要调用对应环境的中间件服务(缓存，数据库，MQ等)。



1.4、小结

Istio服务网格内，端口冲突导致的服务连通性问题非常常见，但是千变万化都逃不过Listener - Route – Cluster – Endpoint, Envoy的所有功能归根到底都是通过这四种配置控制。

社区提供的命令行工具：istioctl可以很方便的能够解析出Envoy的配置，便于快速定位问题。

Ref：https://istio.io/help/ops/traffic-management/proxy-cmd/