我們知道在服務網格集群中的每個工作負載實例上都會透明地注入一個 Istio sidecar 代理,這個代理攔截負載的出入流量,并根據配置完成相應的流量管理,包括流量、安全、可觀測性等等。為了更加細粒度的控制代理的行為,從 1.1 版本開始 Istio 便引入了和服務網格數據面 Sidecar 同名的 Sidecar CRD 資源對象,控制負載上的出入流量以及課訪問的目標服務等。
Sidecar 對象描述了 sidecar 代理的配置,sidecar 代理管理與其連接的工作負載的 inbound 和 outbound 流量。默認情況下,Istio 將為網格中的所有 sidecar 代理服務,使其具有到達網格中每個工作負載所需的必要配置,并在與工作負載關聯的所有端口上接收流量。Sidecar 資源提供了一種的方法,在向工作負載轉發流量或從工作負載轉發流量時,微調端口集合和代理將接收的協議,此外,可以限制代理在從工作負載轉發 outbound 流量時可以達到的服務集合。
比如我們可以創建一個如下所示的 Sidecar 對象:
apiVersion: networking.istio.io/v1beta1kind: Sidecarmetadata: name: test-scspec: egress: - hosts: - "istio-system/*" - "default/*"
在上面的 Sidecar 對象中我們指定了 egress 字段,這個字段用于指定 sidecar 代理的出口流量,其中 hosts 字段用于指定 sidecar 代理可以訪問的目標服務,這里我們指定了 istio-system/* 和 default/*,意思是我們可以控制 default 命名空間下的 sidecar 代理只可以訪問 istio-system 和 default 命名空間下的服務,其他命名空間下的服務則無法訪問。
整體上 Sidecar 對象的核心包括四個字段:workloadSelector、ingress 與 egress、outboundTrafficPolicy。
port:這是一個必選的字段,表示監聽器對應的端口。
bind:監聽器綁定的地址。
captureMode:配置流量捕獲模式,與 egress 中的 captureMode 字段一樣。
defaultEndpoint:也是必選字段,表示流量的轉發目標地址,比如 127.0.0.1:port 或者 0.0.0.0:port。
outboundTrafficPolicy:這個字段用來配置 sidecar 代理對應工作負載的出流量控制,該字段有兩種訪問配置:
ALLOW_ANY:表示允許訪問任意服務,sidecar 代理在攔截到這個出流量后,會直接透傳。
REGISTRY_ONLY:sidecar 代理會攔截所有的出口流量,只允許服務網格內部服務可以被訪問,對于外部服務需要使用 ServiceEntry 注冊才可以被訪問。
Sidecar 對象可以定義在根命名空間 istio-system 下,這樣就會應用到所有命名空間下的工作負載上,比如我們可以創建一個如下所示的 Sidecar 對象:
# global-sidecar.yamlapiVersion: networking.istio.io/v1beta1kind: Sidecarmetadata: name: default namespace: istio-systemspec: egress: - hosts: - "./*"
上面的這個 Sidecar 對象定義在 istio-system 命名空間下,這樣就會應用到所有命名空間下的工作負載上,其中 egress 字段中的 hosts 字段指定了可以訪問的服務,這里我們指定了 "./*",表示限制整個服務網格中的服務只能訪問本命名空間的服務。在實踐中我們推薦使用這種方式在全局范圍定義一個統一的 Sidecar 規則,然后在特定的命名空間下再定義一個 Sidecar 對象來覆蓋全局的 Sidecar 規則。
比如我們可以在 default 命名空間下創建一個如下所示的 Sidecar 對象來覆蓋上面全局的這個對象:
# default-sidecar.yamlapiVersion: networking.istio.io/v1beta1kind: Sidecarmetadata: name: default namespace: defaultspec: egress: - hosts: - "foo/*"
這個對象就允許 default 命名空間的服務可以訪問 foo 命名空間的服務。
同樣我們還可以使用 workloadSelector 字段來指定 sidecar 代理所屬的工作負載,比如我們可以創建一個如下所示的 Sidecar 對象:
# default-sidecar.yamlapiVersion: networking.istio.io/v1beta1kind: Sidecarmetadata: name: default namespace: defaultspec: workloadSelector: labels: app: bar egress: - hosts: - "bar/foo-api"
上面的這個對象只會應用到 app: bar 標簽的工作負載上,并覆蓋以上命名空間級別的規則,使得 default 命名空間下面的 app: bar 標簽的工作負載只能訪問 bar 命名空間下面的 foo-api 服務。
接下來我們使用 sleep 和 httpbin 應用來進行測試說明,將這兩個應用部署到 default 和 other 兩個命名空間下面:
kubectl create ns otherkubectl label ns other istio-injectinotallow=enabledkubectl apply -f samples/sleep/sleep.yaml -n defaultkubectl apply -f samples/sleep/sleep.yaml -n otherkubectl apply -f samples/httpbin/httpbin.yaml -n defaultkubectl apply -f samples/httpbin/httpbin.yaml -n other
默認情況下,注入了 Istio 的工作負載會進行全網格的傳播,假設 default 和 other 兩個不相干的命名空間,other 中有大量的服務,而 default 中只有幾個,因為路由傳播的關系,default 命名空間中的工作負載,其 sidecar 代理中也會帶上 other 命名空間中的路由信息。例如:
$ istioctl proxy-config clusters sleep-9454cc476-jfw97 |grep otherhttpbin.other.svc.cluster.local 8000 - outbound EDSsleep.other.svc.cluster.local 80 - outbound EDS
可以看到,在 default 命名空間中的 Pod,保存了其它命名空間中的路由信息。這不管是對內存消耗還是路由控制來說,都會造成一定浪費,這個時候我們就可以定義一個 Sidecar 資源,限制 sleep 服務只訪問同一命名空間的其他服務,如下所示:
# sleep-sidecar.yamlapiVersion: networking.istio.io/v1alpha3kind: Sidecarmetadata: name: sleepspec: workloadSelector: labels: app: sleep egress: - hosts: - "default/*"
直接應用上面的資源對象即可:
$ kubectl apply -f sleep-sidecar.yaml$ kubectl get sidecarNAME AGEsleep 16s
這個時候可以看到在 sleep 應用中只剩下了本命名空間之內的服務了:
$ istioctl proxy-config clusters sleep-9454cc476-jfw97SERVICE FQDN PORT SUBSET DIRECTION TYPE DESTINATION RULE 80 - inbound ORIGINAL_DSTBlackHoleCluster - - - STATICInboundPassthroughClusterIpv4 - - - ORIGINAL_DSTPassthroughCluster - - - ORIGINAL_DSTagent - - - STATIChttpbin.default.svc.cluster.local 8000 - outbound EDSkubernetes.default.svc.cluster.local 443 - outbound EDSprometheus_stats - - - STATICsds-grpc - - - STATICsleep.default.svc.cluster.local 80 - outbound EDSxds-grpc - - - STATICzipkin - - - STRICT_DNS
現在我們可以在 sleep 應用中去訪問下 httpbin 的應用:
$ kubectl exec -it sleep-9454cc476-jfw97 -- curl http://httpbin.default:8000/ip{ "origin": "127.0.0.6"}
可以看到 default 命名空間下面的應用可以正常訪問,那么對于 other 命名空間下面的服務正常就不能訪問了。
$ kubectl exec -it sleep-9454cc476-jfw97 -- curl http://httpbin.other.svc.cluster.local:8000/ip
可以看到 default 命名空間下面的應用無法訪問 other 命名空間下面的服務了。
Istio 默認情況下,服務網格內部的所有數據面代理都通過 xDS 從控制面獲取全量的配置,這種方式在數據面代理數量較少的情況下是沒有問題的,但是當數據面代理數量較多的大規模服務網格的場景下,這種方式顯然會造成性能問題,全量的配置會引起數據面代理的內存暴漲,所以 Sidecar 對象是非常有必要的,通過 Sidecar 對象只維護少量依賴服務的配置,可以大大減少無用的內存消耗,所以在生產環境中我們推薦大家使用 Sidecar 對象來控制數據面代理的配置。
本文鏈接:http://www.www897cc.com/showinfo-26-48344-0.html使用 Sidecar CRD 優化 Istio 性能
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com