事故起因
業務上新集羣,本來以爲"灑灑水",11 點切,12 點就能在家睡覺了。流量切過來後,在驗證過程中,發現網頁能夠正常打開,在登錄時返回了 502,當場懵逼。在相關的容器日誌發現一個高頻的報錯條目“7000 端口無法連接”,向業務組瞭解到這是 redis 集羣中的一個端口,前後端是通過 redis 交互的,該集羣同時還有 7001-7003 其它三個端口。
用 nc 命令對 redis 集羣進行連接測試:向服務端發送 keys *
命令時,7000 端口返回的是 HTTP/1.1 400 Bad Request
,其他三個端口是 redis 返回的 -NOAUTH Authentication required
。
$ nc 10.0.0.6 7000
keys *
HTTP/1.1 400 Bad Request
content-length: 0
connection: close
$ nc 10.0.0.6 7003
keys *
-NOAUTH Authentication required
判斷 7000 端口連接到了其他應用上,至少不是 redis。在宿主機上抓包發現沒有抓到訪問 7000 端口的流量,然後查看容器的 nf_conntrackb 表,發現 7000 端口的數據只有到本地的會話信息;7003 的有兩條會話信息,一條到本機的,一條到目標服務器的。
$ grep 7000 /proc/net/nf_conntrack
ipv4 2 tcp 6 110 TIME_WAIT src=10.64.192.14 dst=10.0.0.6 sport=50498 dport=7000 src=127.0.0.1 dst=10.64.192.14 sport=15001 dport=50498 [ASSURED] mark=0 zone=0 use=2
$ grep 7003 /proc/net/nf_conntrack
ipv4 2 tcp 6 104 TIME_WAIT src=10.64.192.14 dst=10.0.0.6 sport=38952 dport=7003 src=127.0.0.1 dst=10.64.192.14 sport=15001 dport=38952 [ASSURED] mark=0 zone=0 use=2
ipv4 2 tcp 6 104 TIME_WAIT src=10.64.192.14 dst=10.0.0.6 sport=38954 dport=7003 src=10.0.0.6 dst=10.64.192.14 sport=7003 dport=38954 [ASSURED] mark=0 zone=0 use=2
由此判斷出 istio 沒有代理轉發出 7000 的流量,這突然就觸及到了我的知識盲區,一大堆人看着,辦公室 26 度的空調,一直在冒汗。沒辦法了,在與業務商量後,只能先關閉 istio 注入,優先恢復了業務。回去後惡補 istio 的相關資料。終於將問題解決。記錄下相關信息,以供日後參考。
背景知識補充
istio Sidecar 的模式
istio 的 Sidecar 有兩種模式:
- ALLOW_ANY:istio 代理允許調用未知的服務,黑名單模式。
- REGISTRY_ONLY:istio 代理會阻止任何沒有在網格中定義的 HTTP 服務或 service entry 的主機,白名單模式。
istio-proxy(Envoy)的配置結構
istio-proxy(Envoy)的代理信息大體由以下幾個部分組成:
- Cluster:在 Envoy 中,Cluster 是一個服務集羣,Cluster 中包含一個到多個 endpoint,每個 endpoint 都可以提供服務,Envoy 根據負載均衡算法將請求發送到這些 endpoint 中。cluster 分爲 inbound 和 outbound 兩種,前者對應 Envoy 所在節點上的服務;後者佔了絕大多數,對應 Envoy 所在節點的外部服務。可以使用如下方式分別查看 inbound 和 outbound 的 cluster。
- Listeners:Envoy 採用 listener 來接收並處理 downstream 發過來的請求,可以直接與 Cluster 關聯,也可以通過 rds 配置路由規則(Routes),然後在路由規則中再根據不同的請求目的地對請求進行精細化的處理。
- Routes:配置 Envoy 的路由規則。istio 下發的缺省路由規則中對每個端口(服務)設置了一個路由規則,根據 host 來對請求進行路由分發,routes 的目的爲其他服務的 cluster。
- Endpoint:cludter 對應的後端服務,可以通過 istio pc endpoint 查看 inbound 和 outbound 對應的 endpoint 信息。
服務發現類型
cluster 的服務發現類型主要有:
- ORIGINAL_DST:類型的 Cluster,Envoy 在轉發請求時會直接採用 downstream 請求中的原始目的地 IP 地址
- EDS:EDS 獲取到該 Cluster 中所有可用的 Endpoint,並根據負載均衡算法(缺省爲 Round Robin)將 Downstream 發來的請求發送到不同的 Endpoint。istio 會自動爲集羣中的 service 創建代理信息,listener 的信息從 service 獲取,對應的 cluster 被標記爲 EDS 類型
- STATIC:缺省值,在集羣中列出所有可代理的主機 Endpoints。當沒有內容爲空時,不進行轉發。
- LOGICAL_DNS:Envoy 使用 DNS 添加主機,但如果 DNS 不再返回時,也不會丟棄。
- STRICT_DNS:Envoy 將監控 DNS,而每個匹配的 A 記錄都將被認爲是有效的。
兩個特殊集羣
BlackHoleCluster:黑洞集羣,匹配此集羣的流量將被不會被轉發。
{
"name": "BlackHoleCluster",
"type": "STATIC",
"connectTimeout": "10s"
}
類型爲 static,但是沒有指定可代理的 Endpoint,所以流量不會被轉發。
PassthroughCluster:透傳集羣,匹配此集羣的流量數據包的目的 IP 不會改變。
{
"name": "PassthroughCluster",
"type": "ORIGINAL_DST",
"connectTimeout": "10s",
"lbPolicy": "CLUSTER_PROVIDED",
"circuitBreakers": {
"thresholds": [
{
"maxConnections": 4294967295,
"maxPendingRequests": 4294967295,
"maxRequests": 4294967295,
"maxRetries": 4294967295
}
]
}
類型爲 original_dst,流量將原樣轉發。
一個特殊的 Listener
istio 中有一個特殊的 Listener 叫 virtualOutbound,定義如下:
- virtualOutbound:每個 Sidecar 都有一個綁定到 0.0.0.0:15001 的 listener,該 listener 下關聯了許多 virtual listener。iptables 會先將所有出站流量導入該 listener,該 listener 有一個字段 useOriginalDst 設置爲 true,表示會使用最佳匹配原始目的地的方式將請求分發到 virtual listener,如果沒有找到任何 virtual listener,將會直接發送到數據包原目的地的 PassthroughCluster。
useOriginalDst 字段的具體意義是,如果使用 iptables 重定向連接,則代理接收流量的目標地址可能與原始目標地址不同。當此標誌設置爲 true 時,偵聽器會將重定向流量轉交給與原始目標地址關聯的偵聽器。如果沒有與原始目標地址關聯的偵聽器,則流量由接收它的偵聽器處理。默認爲 false。
virtualOutbound 的流量處理流程如圖所示:
這是 virtualOutbound 的部分配置:
{
"name": "envoy.tcp_proxy",
"typedConfig": {
"@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
"statPrefix": "PassthroughCluster",
"cluster": "PassthroughCluster"
}
}
……………
"useOriginalDst": true
istio 的 outbond 流量處理
開啓流量治理後,pod 訪問外部資源的流量轉發路徑如圖所示:
istio 注入後 istio-proxy 有一個監聽在 15001 的端口,所有非 istio-proxy 用戶進程產生的 outbond 流量,通過 iptables 規則被重定向到 15001。
# Sidecar 注入的 pod 監聽的端口
$ ss -tulnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:80 *:*
LISTEN 0 128 *:15090 *:*
LISTEN 0 128 127.0.0.1:15000 *:*
LISTEN 0 128 *:15001 *:*
LISTEN 0 128 *:15006 *:*
LISTEN 0 128 [::]:15020 [::]:*
# Pod 內部的 iptables 表項
$ iptables-save
# Generated by iptables-save v1.4.21 on Fri Sep 17 13:47:09 2021
*nat
:PREROUTING ACCEPT [129886:7793160]
:INPUT ACCEPT [181806:10908360]
:OUTPUT ACCEPT [53409:3257359]
:POSTROUTING ACCEPT [53472:3261139]
:istio_INBOUND - [0:0]
:istio_IN_REDIRECT - [0:0]
:istio_OUTPUT - [0:0]
:istio_REDIRECT - [0:0]
-A PREROUTING -p tcp -j istio_INBOUND
-A OUTPUT -p tcp -j istio_OUTPUT
-A istio_INBOUND -p tcp -m tcp --dport 22 -j RETURN
-A istio_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A istio_INBOUND -p tcp -j istio_IN_REDIRECT
-A istio_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A istio_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
-A istio_OUTPUT ! -d 127.0.0.1/32 -o lo -j istio_IN_REDIRECT
-A istio_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A istio_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A istio_OUTPUT -d 127.0.0.1/32 -j RETURN
-A istio_OUTPUT -j istio_REDIRECT
-A istio_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# Completed on Fri Sep 17 13:47:09 2021
istio-proxy 收到流量後,大致的處理步驟如下:
- Proxy 在 ALLOW_ANY 模式下沒有匹配上 listener 將被直接轉發
- listener 關聯了 type 爲 ORIGINAL_DST 的 cluster 將使用原始請求種的 IP 地址
- 匹配上了 BlackHoleCluster,將不會被轉發
被代理流量的匹配步驟大致如下:
疑問:isito 爲 svc 創建的 listener 地址是全零的,集羣內部的端口是會存在複用的,那 istio 到底是怎麼區分流量的呢?
關鍵就在於 route,route 由 virtual_host 條目組成,這些 virtual_host 條目就是根據 svc 的信息生成的,訪問集羣內部的 svc 時,在 route 裏可以根據域名或者 svc 對應的 virtual_ip 進行精確匹配,所以完全不需要擔心啦。
$ kubectl get svc -A | grep 8001
NodePort 10.233.34.158 <none> 8001:30333/TCP 8d
NodePort 10.233.9.105 <none> 8001:31717/TCP 8d
NodePort 10.233.60.59 <none> 8001:31135/TCP 2d16h
NodePort 10.233.18.212 <none> 8001:32407/TCP 8d
NodePort 10.233.15.5 <none> 8001:30079/TCP 8d
NodePort 10.233.59.21 <none> 8001:31103/TCP 8d
NodePort 10.233.17.123 <none> 8001:31786/TCP 8d
NodePort 10.233.9.196 <none> 8001:32662/TCP 8d
NodePort 10.233.62.85 <none> 8001:32104/TCP 8d
ClusterIP 10.233.49.245 <none> 8000/TCP,8001/TCP,8443/TCP,8444/TCP
這是 route 下的 virtual_host 條目:
{
"name": "8001",
"virtualHosts": [
{
"name": "merchant-center.open.svc.cluster.local:8001",
"domains": [
"merchant-center.open.svc.cluster.local",
"merchant-center.open.svc.cluster.local:8001",
"merchant-center.open",
"merchant-center.open:8001",
"merchant-center.open.svc.cluster",
"merchant-center.open.svc.cluster:8001",
"merchant-center.open.svc",
"merchant-center.open.svc:8001",
"10.233.60.59",
"10.233.60.59:8001"
],
"routes": [
{
"name": "default",
"match": {
"prefix": "/"
},
"route": {
"cluster": "outbound|8001||merchant-center.open.svc.cluster.local",
"timeout": "0s",
"retryPolicy": {
"retryOn": "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes",
"numRetries": 2,
"retryHostPredicate": [
{
"name": "envoy.retry_host_predicates.previous_hosts"
}
],
"hostSelectionRetryMaxAttempts": "5",
"retriableStatusCodes": [
503
]
},
"maxGrpcTimeout": "0s"
},
…………………
{
"name": "cashier-busi-svc.pay.svc.cluster.local:8001",
"domains": [
"cashier-busi-svc.pay.svc.cluster.local",
"cashier-busi-svc.pay.svc.cluster.local:8001",
"cashier-busi-svc.pay",
"cashier-busi-svc.pay:8001",
"cashier-busi-svc.pay.svc.cluster",
"cashier-busi-svc.pay.svc.cluster:8001",
"cashier-busi-svc.pay.svc",
"cashier-busi-svc.pay.svc:8001",
"10.233.17.123",
"10.233.17.123:8001"
],
…………………
{
"name": "center-job.manager.svc.cluster.local:8001",
"domains": [
"center-job.manager.svc.cluster.local",
"center-job.manager.svc.cluster.local:8001",
"center-job.manager",
"center-job.manager:8001",
"center-job.manager.svc.cluster",
"center-job.manager.svc.cluster:8001",
"center-job.manager.svc",
"center-job.manager.svc:8001",
"10.233.34.158",
"10.233.34.158:8001"
],
……………
問題分析
基於以上信息,對集羣內的 svc 進行端口過濾,終於發現了集羣中存在使用了 7000 端口的 service:
istio 會爲 10.233.0.115:7000 自動生成一個 0.0.0.0:7000 的 listener:
ADDRESS PORT TYPE
0.0.0.0 7000 TCP
查看詳細配置信息,在該 listener 中對於 tcp 流量是不轉發(BlackHoleCluster),所以目標地址爲 10.0.x.x:7000 的流量被 listener_0.0.0.0:7000 匹配到時,因爲是 tcp 的流量(nc 命令默認 tcp 協議),所以代理沒有對該流量進行轉發。這與開頭提到的 pod 沒有流量發出來現象一致。
{
"name": "0.0.0.0_7000",
"address": {
"socketAddress": {
"address": "0.0.0.0",
"portValue": 7000
}
},
"filterChains": [
{
"filterChainMatch": {
"prefixRanges": [
{
"addressPrefix": "10.64.x.x",
"prefixLen": 32
}
]
},
"filters": [
{
"name": "envoy.tcp_proxy",
"typedConfig": {
"@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
"statPrefix": "BlackHoleCluster",
"cluster": "BlackHoleCluster"
}
}
]
}
至於 7001-7003 爲什麼能通,是因爲 istio-proxy 默認使用的是 ALLOW_ANY 模式,對於沒有匹配上 listener 的流量是直接放行。可以通過 istio_configmap 配置信息來驗證一下:
$ kubectl get cm istio -n istio-system -o yaml | grep -i -w -a3 "mode"
# REGISTRY_ONLY - restrict outbound traffic to services defined in the service registry as well
# as those defined through ServiceEntries
outboundTrafficPolicy:
mode: ALLOW_ANY
localityLbSetting:
enabled: true
# The namespace to treat as the administrative root namespace for istio
--
drainDuration: 45s
parentShutdownDuration: 1m0s
#
# The mode used to redirect inbound connections to Envoy. This setting
# has no effect on outbound traffic: iptables REDIRECT is always used for
# outbound connections.
# If "REDIRECT", use iptables REDIRECT to NAT and redirect to Envoy.
# The "REDIRECT" mode loses source addresses during redirection.
# If "TPROXY", use iptables TPROXY to redirect to Envoy.
# The "TPROXY" mode preserves both the source and destination IP
# addresses and ports, so that they can be used for advanced filtering
# and manipulation.
# The "TPROXY" mode also configures the Sidecar to run with the
# CAP_NET_ADMIN capability, which is required to use TPROXY.
#interceptionMode: REDIRECT
#
解決方案
最後我們來解決開頭提到的問題,總共有三種解決方案。
方法 1:Service Entry
服務條目(Service Entry)是 istio 重要的資源對象之一,作用是將外部的資源註冊到 istio 內部的網格服務中來,以提供網格內對外部資源的更加精細化的控制。我們可以簡單理解爲白名單,istios 根據 Service Entry 的內容生成 listeners。
我們在命名空間 dev-self-pc-ct 中添加如下配置:
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: rediscluster
namespace: dev-self
spec:
hosts:
- redis
addresses:
- 10.0.x.x/32
ports:
- number: 7000
name: redis-7000
protocol: tcp
- number: 7001
name: redis-7001
protocol: tcp
- number: 7002
name: redis-7002
protocol: tcp
- number: 7003
name: redis-7003
protocol: tcp
resolution: NONE
location: MESH_EXTERNAL
EOF
查看 listener:
$ ./istioctl proxy-config listeners test-8c4c9dcb9-kpm8n.dev-self --address 10.0.x.x -o json
[
{
"name": "10.0.x.x_7000",
"address": {
"socketAddress": {
"address": "10.0.x.x",
"portValue": 7000
}
},
"filterChains": [
{
"filters": [
{
"name": "mixer",
"typedConfig": {
"@type": "type.googleapis.com/istio.mixer.v1.config.client.TcpClientConfig",
"transport": {
"networkFailPolicy": {
"policy": "FAIL_CLOSE",
"baseRetryWait": "0.080s",
"maxRetryWait": "1s"
},
"checkCluster": "outbound|9091||istio-policy.istio-system.svc.cluster.local",
"reportCluster": "outbound|9091||istio-telemetry.istio-system.svc. cluster.local",
"reportBatchMaxEntries": 100,
"reportBatchMaxTime": "1s"
},
"mixerAttributes": {
"attributes": {
"context.proxy_version": {
"stringValue": "1.4.8"
},
"context.reporter.kind": {
"stringValue": "outbound"
},
"context.reporter.uid": {
"stringValue": "kubernetes://test-8c4c9dcb9-kpm8n.dev-self"
},
"destination.service.host": {
"stringValue": "redis"
},
"destination.service.name": {
"stringValue": "redis"
},
"destination.service.namespace": {
"stringValue": "dev-self "
},
"source.namespace": {
"stringValue": "dev-self "
},
"source.uid": {
"stringValue": "kubernetes://test-8c4c9dcb9-kpm8n.dev-self"
}
}
},
"disableCheckCalls": true
}
},
{
"name": "envoy.tcp_proxy",
"typedConfig": {
"@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
"statPrefix": "outbound|7000||redis",
"cluster": "outbound|7000||redis"
}
}
]
}
],
"deprecatedV1": {
"bindToPort": false
},
"listenerFiltersTimeout": "0.100s",
"continueOnListenerFiltersTimeout": true,
"trafficDirection": "OUTBOUND"
},
......
]
我們可以看到 listener "10.0.1.6_7000" 中 tcp 流量關聯了 outbound|7000||redis
集羣,該集羣的類型是 ORIGINAL_DST
,即保持源報文的目的地址,並且沒有關聯任何 service。
所以此時訪問 10.0.x.x:7000 的目標地址不會改變。
{
"name": "outbound|7000||redis",
"type": "ORIGINAL_DST",
"connectTimeout": "10s",
"lbPolicy": "CLUSTER_PROVIDED",
"circuitBreakers": {
"thresholds": [
{
"maxConnections": 4294967295,
"maxPendingRequests": 4294967295,
"maxRequests": 4294967295,
"maxRetries": 4294967295
}
]
}
}
再次訪問測試:
$ nc 10.0.0.6 7000
keys *
-NOAUTH Authentication required.
$ nc 10.0.0.7 7000
keys *
-NOAUTH Authentication required.
$ nc 10.0.0.8 7000
keys *
-NOAUTH Authentication required.
已經可以正常轉發。
方法 2:更改 global.proxy.includeIPRanges 或 global.proxy.excludeIPRanges 配置選項
- global.proxy.includeIPRanges:需要進行代理 ip 地址範圍
- global.proxy.excludeIPRanges:不需要進行代理的 ip 地址範圍。
最終效果爲在 pod 的 iptables 規則上匹配或排除對應的地址,訪問這些地址流量不會被重定向到 istio-proxy,而是直接發送。
我們可以使用 kubectl apply 命令更新 istio-Sidecar-injector 配置,也可以修改 spec. template.metadata. annotations 中的 traffic.Sidecar.istio.io/includeOutboundIPRanges 來達到相同的效果。
template:
metadata:
annotations:
kubectl.kubernetes.io/restartedAt: '2021-06-09T21:59:10+08:00'
kubesphere.io/restartedAt: '2021-09-13T17:07:03.082Z'
logging.kubesphere.io/logSidecar-config: '{}'
Sidecar.istio.io/componentLogLevel: 'ext_authz:trace,filter:debug'
Sidecar.istio.io/inject: 'true'
traffic.Sidecar.istio.io/excludeOutboundIPRanges: 10.0.1.0/24
Pod 裏的 iptables 規則會將目標地址爲 10.0.x.x/24 的流量正常轉發:
# Generated by iptables-save v1.4.21 on Fri Sep 17 14:26:10 2021
*nat
:PREROUTING ACCEPT [131058:7863480]
:INPUT ACCEPT [183446:11006760]
:OUTPUT ACCEPT [53889:3286544]
:POSTROUTING ACCEPT [53953:3290384]
:istio_INBOUND - [0:0]
:istio_IN_REDIRECT - [0:0]
:istio_OUTPUT - [0:0]
:istio_REDIRECT - [0:0]
-A PREROUTING -p tcp -j istio_INBOUND
-A OUTPUT -p tcp -j istio_OUTPUT
-A istio_INBOUND -p tcp -m tcp --dport 22 -j RETURN
-A istio_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A istio_INBOUND -p tcp -j istio_IN_REDIRECT
-A istio_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A istio_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
-A istio_OUTPUT ! -d 127.0.0.1/32 -o lo -j istio_IN_REDIRECT
-A istio_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A istio_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A istio_OUTPUT -d 127.0.0.1/32 -j RETURN
-A istio_OUTPUT -d 10.0.0.0/24 -j RETURN
-A istio_OUTPUT -j istio_REDIRECT
-A istio_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# Completed on Fri Sep 17 14:26:10 2021
方法 3:用 Service 打敗 Service
這個方法基於 istio 會爲集羣中的 svc 自動生成 listener 的工作方式,手動在集羣中爲外部服務創建 service 和 endpoints:
apiVersion: v1
kind: Endpoints
metadata:
name: rediscluster
labels:
name: rediscluster
app: redis-jf
user: jf
namespace: dev-self
subsets:
- addresses:
- ip: 10.0.x.x
- ip: 10.0.x.x
- ip: 10.0.x.x
ports:
- name: tcp-7000
port: 7000
- name: tcp-7001
port: 7001
- name: tcp-7002
port: 7002
- name: tcp-7003
port: 7003
---
apiVersion: v1
kind: Service
metadata:
name: rediscluster
namespace: dev-self
spec:
ports:
- name: tcp-7000
protocol: TCP
port: 7000
targetPort: 7000
- name: tcp-7001
protocol: TCP
port: 7001
targetPort: 7001
- name: tcp-7002
protocol: TCP
port: 7002
targetPort: 7002
- name: tcp-7003
protocol: TCP
port: 7003
targetPort: 7003
selector:
name: rediscluster
app: redis-jf
user: jf
應用以上配置後 istio 會自動生成一個 service_ip+port 的 listener。Service 信息如下:
Selector: app=redis-jf,name=rediscluster,user=jf
Type: ClusterIP
IP: 10.233.40.115
Port: tcp-7000 7000/TCP
TargetPort: 7000/TCP
Endpoints: <none>
Port: tcp-7001 7001/TCP
TargetPort: 7001/TCP
Endpoints: <none>
Port: tcp-7002 7002/TCP
TargetPort: 7002/TCP
Endpoints: <none>
Port: tcp-7003 7003/TCP
TargetPort: 7003/TCP
Endpoints: <none>
Session Affinity: None
Events: <none>
Listener 部分信息如下:
{
"name": "10.233.59.159_7000",
"address": {
"socketAddress": {
"address": "10.233.59.159",
"portValue": 7000
}
},
"filterChains": [
{
"filters": [
{
"name": "mixer",
"typedConfig": {
"@type": "type.googleapis.com/istio.mixer.v1.config.client.TcpClientConfig",
"transport": {
"networkFailPolicy": {
"policy": "FAIL_CLOSE",
"baseRetryWait": "0.080s",
"maxRetryWait": "1s"
},
"checkCluster": "outbound|9091||istio-policy.istio-system.svc.cluster.local",
"reportCluster": "outbound|9091||istio-telemetry.istio-system.svc.cluster.local",
"reportBatchMaxEntries": 100,
"reportBatchMaxTime": "1s"
},
"mixerAttributes": {
"attributes": {
"context.proxy_version": {
"stringValue": "1.4.8"
},
......
該 listener 指向了一個 cluster:
{
"name": "envoy.tcp_proxy",
"typedConfig": {
"@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
"statPrefix": "outbound|7000||redis",
"cluster": "outbound|7000||redis"
}
}
對應的 service 信息如下:
可以看到 endpoint 就是剛纔我們指定的外部服務器地址:
進行訪問測試:
已經可以正常訪問了。
總結
最後我們來比較一下這三種方法。
- 方法 1:通過添加 ServiceEntry,以允許訪問外部服務。可以讓你使用 istio 服務網格所有的功能去調用集羣內或集羣外的服務,這是官方推薦的方法。
- 方法 2:直接繞過了 istio Sidecar 代理,使你的服務可以直接訪問任意的外部服務。 但是,以這種方式配置代理需要了解集羣提供商相關知識和配置。將失去對外部服務訪問的監控,並且無法將 istio 功能應用於外部服務的流量。
- 方法 3:這個方法相對於其他兩種,配置有點複雜,同時還要通過 service 的方式來訪問外部服務,這意味着對於已經存在的應用需要進行改造。具體能否實施看實際情況。
方法 1 的做法類似於“白名單”,不但能達到訪問外部服務的目的,並且可以像集羣內部服務一樣對待(可使用 istio 的流量控制功能)。另外,即使服務受到入侵,由於“白名單”的設置入侵者也無法(或較難)將流量回傳到入侵機器,進一步保證了服務的安全性;
方法 2 直接繞過了 istio Sidecar 代理,使你的服務可以直接訪問任意的外部服務。 但是,以這種方式配置代理需要了解集羣提供商相關知識和配置。 你將失去對外部服務訪問的監控,並且無法將 istio 功能應用於外部服務的流量;
方法 3 雖然也可以使用 istio 的流量控制功能來管理外部流量,但是在實際操作中會存在配置複雜、改造應用等問題
因此,強烈推薦大家使用方法一。最後,特別提醒一下大家。將 includeOutboundIPRanges
設置爲空是有問題的,這相當於將所有的服務都配置代理繞行,那 Sidecar 就沒起作用了,沒了 Sidecar 的 istio 就沒有靈魂了。。
本文由博客一文多發平臺 OpenWrite 發佈!