【轉載】如何降低Istio服務網格中Envoy的內存開銷

Envoy的內存占用

在Istio服務網格中，每個Envoy占用的內存也許并不算多，但所有sidecar增加的內存累積起來則是一個不小的數字。在進行商用部署時，我們需要考慮如何優化并減少服務網格帶來的額外內存消耗。

下面是在我環境中的一個實測數據：

Envoy配置中的Listener和Cluster數量

Listener數量 175

Cluster數量 325

endpoint數量 466

內存占用情況

$?sudo?docker?stats?2e8fb CONTAINER???????????CPU?%???????????????MEM?USAGE?/?LIMIT?????MEM?%???????????????NET?I/O?????????????BLOCK?I/O???????????PIDS 2e8fb???????????????0.75%???????????????105.9?MiB?/?256?MiB???41.39%??????????????0?B?/?0?B???????????0?B?/?0?B???????????165

從上面的數據可以看到，在一個有325個cluster和175個Listener的服務網格中，一個Envoy的實際內存占用量達到了100M左右；網格中一共有466個實例，則所有Envoy占用的內存達到了466*100M=46.6G，這些增加的內存消耗是一個不容小視的數據。

減少TCMalloc預留系統內存

根據Istio官方文檔，Envoy占用的內存大小和其配置相關，和請求處理速率無關。在一個較大的namespace中，Envoy大約占用50M內存。然而對于多大為“較大”，Istio官方文檔并未給出一個明確的數據。

通過Envoy的管理端口查看上面環境中一個Envoy內存分配的詳細情況：

$?sudo?docker?exec?2e8fb?curl?http://127.0.0.1:15000/memory { ?"allocated":?"50315720",????????????????//Envoy實際占用內存 ?"heap_size":?"102637568",???????????????//TCMalloc預留的系統內存 ?"pageheap_unmapped":?"4603904", ?"pageheap_free":?"9183232", ?"total_thread_cache":?"27784296" }

各個指標的詳細說明參見Envoy文檔。從上面的數據可以看到Envoy真正使用的內存為50M左右，和官方文檔一致。但由于Envoy采用了TCMalloc作為內存管理器，導致其占用內存大于Envoy實際使用內存。

TCMalloc的內存分配效率比glibc的malloc更高，但會預留系統內存，導致程序占用內存大于其實際所需內存。從前面的Envoy admin 接口的輸出可以看到TCMalloc預留的內存為100M左右，遠遠大于了Envoy實際所需的內存數量。

根據Envoy的實際內存占用情況，將container的最大內存限制調整為60M后再運行，Envoy可以正常啟動。再次用docker stat命令查看，其消耗的內存也在60M以內。

通過優化配置降低Envoy內存占用

即使將內存降低到50M，在一些對資源要求比較嚴格的環境，例如邊緣計算的場景中，網格中這些Envoy內存累加在一起也是不能接受的，因此需要想辦法進一步降低Envoy的資源使用。

根據Envoy的這個github issue（Per listener and per cluster memory overhead is too high #4196）和Istio文檔可以得知，Envoy占用的內存和其配置的Listener和Cluster個數是成線性關系的，Listener和Cluster越多，Envoy占用的內存越大，因此一個自然的想法就是通過減少Pilot為Envoy創建的Listener和Cluster數量來降低Envoy的內存開銷。

按nampese對配置進行隔離

在Istio 1.3中，Pilot在創建Lister和Cluster時已經按照namespace對Service進行了隔離，Pilot缺省只會為Envoy創建和其代理服務在同一個namespace中的Service相關的Listener和Cluster。按照namespace進行隔離在一定程度上減少了Envoy中的Listener和Cluster數量，但還是太過于粗獷，對內存的優化效果有限。

在實際的產品部署中，一個namespace中往往會部署大量相關的微服務，這些微服務在邏輯上屬于同一個業務系統，但并不是namespace中的任意兩個微服務之間都存在訪問關系，因此按照namespace進行隔離還是會導致Envoy中存在大量該sidecar不需要的Listener和Cluster配置。

按服務訪問關系進行細粒度隔離

在一個微服務運用中，一個服務訪問的其他服務一般不會超過10個，而一個namespace中可能部署多達上百個微服務，導致Envoy中存在大量冗余配置，導致不必要的內存消耗。最合理的做法是只為一個sidecar配置該sidecar所代理服務需要訪問的外部服務相關的配置。

Istio提供了Siedecar CRD，用于對Pilot向sidecar下發的缺省配置進行更細粒度的調整。下面以Bookinfo示例程序說明如何調整一個sidecar的配置。

在Bookinfo示例程序中，幾個微服務之間的調用關系如下：

從圖中可以看到，reviews服務只需要訪問ratings服務，因此在reviews的sidecar中只需要ratings服務相關的outbound配置。

但是通過查詢reviews pod中proxy的配置，可以看到Pilot下發的缺省配置信息中包含了reviews， productpage，details這些它并不需要的outbound cluster信息，這些outbound cluster會導致額外的內存消耗。

master?$?kubectl?exec?reviews-v3-54c6c64795-2tzjc?-c?istio-proxy?curl?127.0.0.1:15000/clusters|grep?9080|grep?added_via_api::true|grep?outbound outbound|9080||reviews.default.svc.cluster.local::added_via_api::true outbound|9080||details.default.svc.cluster.local::added_via_api::true outbound|9080||ratings.default.svc.cluster.local::added_via_api::true outbound|9080||productpage.default.svc.cluster.local::added_via_api::true

下面通過sidecar來對reviews服務的sidecar進行配置，只為ratings服務創建相關的outbound cluster。

創建一個sidecar.yaml文件，對reviews服務進行配置。

apiVersion:?networking.istio.io/v1alpha3 kind:?Sidecar metadata: ??name:?reviews ??namespace:?default spec: ??workloadSelector: ????labels: ??????app:?reviews ??egress: ??-?hosts: ????-?"./ratings.default.svc.cluster.local"

在Istio中運用該sidecar配置。

master?$?kubectl?apply?-f?sidecar.yaml sidecar.networking.istio.io/reviews?created

再查看Reviews Pod中的Envoy配置，配置中的outbound cluster只包含ratings服務，去掉了其他無關的服務相關的配置。

master?$?kubectl?exec?reviews-v1-75b979578c-x7g46?-c?istio-proxy?curl?127.0.0.1:15000/clusters|grep?9080|grep?added_via_api::true|grep?outbound outbound|9080||ratings.default.svc.cluster.local::added_via_api::true

在本文開始的環境中再進行測試，通過該方法去掉無關配置，只保留5個左右相關的outbound service，可以把Envoy的內存控制在15M以內。

總結

在Istio服務網格中，伴隨應用部署的Envoy sidecar導致了較大的內存占用。通過對sidecar鏡像的內存進行限制，并通過Pilot對sidecar的缺省配置按照服務的實際關聯關系進行細化調整，可以對Envoy的內存占用進行優化，減少Istio服務網格部署對內存的額外消耗。

參考文檔

Envoy Admin: Memory

TCMalloc : Thread-Caching Malloc

Istio Performance and Scalability

Per listener and per cluster memory overhead is too high #4196

Istio Traffic Management: Sidecar

Istio Kubernetes

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。