47

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

 5 years ago
source link: http://dockone.io/article/8517?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

1.1、背景

写这篇文章的目的是为了说明以下问题:如何使用TCP协议相同的端口访问网格外多个服务? 这是最近直播的时候有一个同学提出的,当时我没有完全明白,“访问多集群” 的意思。后来仔细思考了一下,问题应该就是Istio服务网格内如何通过相同的协议,端口访问不同的服务。

1.2、使用场景

肯定会有人回答,既然相同的端口不能使用,何不换一个端口呢,这样做也是一种解决方法。我在想有一些场景一定没法或者不方便绕过去。

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

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

在微服务盛行的今天,往往需要团队之间协作,没办法保证所有的微服务都运行在同一服务网格内。尤其是中间件服务,作为公司公共服务,一定是业务共享的。既然我们不可避免的需要使用相同的端口,访问外部服务,接下来告诉大家两种方案解决以上问题。

1.3、解决方案

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

1) www.huaweicloud.com

cat <<EOF | kubectl apply -f -

apiVersion: networking.istio.io/v1alpha3

kind: ServiceEntry

metadata:

name: hwcloud

spec:

hosts:

  • www.huaweicloud.com
    ports:
  • number: 443
    name: tcp
    protocol: TCP
    resolution: DNS
    location: MESH_EXTERNAL

EOF

2) github.com

cat <<EOF | kubectl apply -f -

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]

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

QFBnQvv.jpg!web

同样的方法更新 github

IbAJRfM.jpg!web

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

ueaquar.jpg!web

虽然着这种方式一定程度上可以解决同一端口访问外部服务的需求。但是由于需要提前设置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 <<EOF | kubectl apply -f -

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 <<EOF | kubectl apply -f -

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/traf ... -cmd/


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK