5 posts tagged with "ServiceMesh"

預設的 istio-proxy 都會吃掉一些 CPU/Memory，當叢集內的 Pod 數量過多時，這些 sidecar 吃掉的數量非常可觀 如果是採用 istiooperator 的方式安裝，可以採用下列方式修改

...
  spec:
    values:
      global:
        proxy:
          privileged: false
          readinessFailureThreshold: 30
          readinessInitialDelaySeconds: 1
          readinessPeriodSeconds: 2
          resources:
            limits:
              cpu: 2000m
              memory: 1024Mi
            requests:
              cpu: 100m
              memory: 128Mi

這個設定是 global 的設定，如果是單一的 Pod 要自行調整，可以於 Pod annotations 中加入列下資訊調整

annotations:
  sidecar.istio.io/proxyCPU: 50m
  sidecar.istio.io/proxyMemory: 128Mi

如果要更新 istio，建議參考官方 Canary Approach 的步驟，使用金絲雀部署的方式逐步調整 其原理很簡單

1. 同時部署兩個版本的 istiod
2. 逐步重啟 Pod 來套用新版本的 istio，直到所有 pod 都轉移到新版本的 istiod
3. 移除舊的

基本上安裝過程要透過 "--revision=1-14-2" 的方式去打版本，安裝完畢後就是單純只有 control plane

接下來就取決當初如何設定 sidecare 的，如果是 namespace 的話，就可以直接改 namespace 裡面的

istio.io/rev=1-14-2

接下來就逐步重啟 Pod 就可以切換到新的 istio 版本。

另外可以透過 istioctl proxy-status 觀察每個 Pod 目前搭配的版本，透過此指令觀察升級進度

一旦全部升級完畢可以用 istioctl uninstall --revision 1-13-1 -y 來移除舊版本

標題: 「基於 eBPF 的 ServiceMesh」 類別: networking 連結: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh

本篇文章是 2021末 由 Cilium 背後的 isovalent 公司團隊所發表的文章，主要探討一個全新的 Service Mesh 的架構可能帶來的好處，整篇文章以 Cillium + eBPF 為背景去探討 我認為如果對於 eBPF 沒有全面理解的情況下，其實只能讀懂這篇文章想要帶來的果，沒有辦法去理解到底整體實作與運作原理，同時因為 eBPF 本身的用途除了網路(Cilium)之外有愈來愈多的底層除錯工具都是透過 eBPF 的概念來實作的，因此學習 eBPF 的概念其實帶來的好處很多，有空的都推薦大家花點時間去學習。

本文主要分成幾個部分

1. 什麼是 Service Mesh 以及目前的主流做法
2. 聊一下 Linux 網路傳輸的歷史發展
3. 基於 eBPF 的 Service Mesh 架構
4. 不同架構下的差異以及可能的隱性成本

隨者分散式應用程式架構的興起，如何針對這些散落各地的應用程式提供關於網路連線方面的資訊一直以來都是維運上的問題，過往最簡單的方式就是針對各種開發環境導入相關框架 每個應用程式都需要修改來整合這些框架，但是隨者整個架構發展與要求愈來愈多，譬如開發環境有不同程式語言，甚至有不可修改的第三方應用程式，除了網路監控外還想要導入認證授權，負載平衡等各種功能 要求每個應用程式開發者引用這些框架已經沒有辦法漂亮的滿足所有需求，因此一個能夠無視應用程式本體的透明性框架架構就變成眾人追捧與渴望的解決方案。

現今大部分的 Service Mesh 就是採取這種透明性的架構，透過額外 Proxy 來攔截應用程式的封包進行後續管理與監控，使得

1. 應用程式開發者專注自己的商業邏輯開發
2. 第三方不可修改應用程式也可以導入這些進階網路功能

以 kubernetes 來說，目前主流都是透過 sidecar 的概念，讓每個應用程式旁邊都放一個 Proxy 的應用程式，同時基於 Pod 內 Containers 可以使用 localhost 互通的方式來處理連線。 應用程式本身都透過 localhost 打到 Proxy，而所有對外連線都讓 Proxy 幫忙處理，因此所有的進階功能都實作於該 Proxy 上。

Isovalent 認為這種方式功能面上可行，但是認為如果導入 Sidecar 其實有很多隱性成本

1. 根據測試不管哪種 Service Mesh/Proxy 的解決方案都會使得真正連線的 Latency 提高 3~4 倍，這主因是 Linux Kernel 的架構導致，所有的網路封包 都必須要於 Linux Kernel Network Stack 來回繞行很多次，封包這種東西來回本身又會牽扯到 Context Switch, Memory Copy 等各種成本，所以整體 Latency 的提升是不可避免的。
2. 系統的額外資源需求，每個 Pod 都需要一個額外的 Proxy 來處理，以一個 500 節點，同時每個節點都有 30 Pod 來說，整個環境就要額外部署 15,000 的 Proxy 的 Container，每個 Container 消耗 50MB 就至少要額外 750G 的記憶體， 同時也要注意隨者 Pod/Node 等數量增加，每個 Proxy 可能就需要更多的記憶體來維護這些 Mesh(網格) 之間的資訊，因此使用的 Memory 量只會愈來愈多。

所以 Cillium/Isovalent 想要引入基於 eBPF 的架構來打造一個不同架構的 Service Mesh。透過 eBPF 的架構使得整個 Service Mesh 的發生點是發生於 Kernel 階段，而非一個獨立的 Uses Proxy。 這邊帶來的改變有

1. 基於 eBPF 的特性，其本身就有辦法針對系統上所有 Socket 去執行特定的函式，所以 Cillium 就可以偷偷去修改應用程式的網路流量，不論是修改封包內容，偵錯與監控等都可以達到
2. 不需要如同之前一樣每個 Pod 都部署一個獨立的應用程式，取而代之的是撰寫通用的 eBPF 程式來提供各種功能
3. 由於所有的事情都發生於 Kernel，甚至可以達到基於 Socket-level 的封包處理，所以封包不需要繞來繞去，整個處理的路徑非常的短，因此產生的 Latency 非常的小

非常對於這系列戰爭有興趣的人花點時間去把 eBPF 的概念補齊，接下來針對這系列的大戰與討論就能夠有更多的背景去理解

標題: 「istio 下因為YAML 與 Go template 結合產生的 CVE」 類別: others
連結: https://paper.seebug.org/1882/

熟悉 Kubernetes 的使用者一定對於各式各樣的資源格式感到不陌生，譬如描寫一個 Pod 需要準備些關於 containers 的基本資料，其餘還有 Label, Annotation 等 各種資料需要填寫。

Kubernetes 內透過 apimachinery 的方式來驗證每個欄位是不是合法，譬如最常見的就是創建資源名稱時有時候會因為等出現格式不符合，準確來說是 Pod 的方式來驗證每個欄位是不是合法，譬如最常見的就是創建資源名稱時有時候會因為等出現格式不符合，準確來說是 透過 DNS RFC 1123 來驗證 Pod 是否合法。 部分的數值資料可能會於 Controller 中額外去檢查，至於自定義的 CRD(Customer Resource Definition) 則是創建時可以透過 openAPIV3Schema 去定義每個欄位的合法數值。

今天這篇文章要介紹的問題是跟 istio 環境的問題，當使用者創建一個名為 Gateway 的資源到叢集中時， istio 會去讀取該 Gateway 資料並且轉換為 Service/Deployment 兩個底層資源。 作者仔細研究發現創建 Service 時會從 Gateway 中的 Annotation 找到名為 "networking.istio.io/service-type" 的資料，並用其作為 Serivce 的 type.

然而 Annotation 的數值沒有並沒有任何檢查機制，所以使用者可以於該欄位 "networking.istio.io/service-type" 填入各種數值，因此作者就嘗試撰寫一個非常長的 Annotation，譬如

  annotations:
    networking.istio.io/service-type: |-
      "LoadBalancer"
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: pwned-deployment
        namespace: istio-ingress
      spec:
        selector:
          matchLabels:
            app: nginx
        replicas: 1
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
            - name: nginx
              image: nginx:1.14.3
              ports:
              - containerPort: 80
              securityContext:
                privileged: true

結果非常順利的， isio 最終創造了一個作者故意描述的 deployment，而該 deployment 還特別的設定 privileged: true 的選項並且透過這次的測試證明該 YAML 的檢查問題導致使用者有機會插入任何想要的資源到環境中 對本文有興趣的可以觀看一下

標題: 「如何判別到底要不要使用 Service Mesh」 類別: Network 連結: https://medium.com/google-cloud/when-not-to-use-service-mesh-1a44abdeea31

本篇文章是一個經驗探討文，想要探討近年來非常熱門的網路網格(Service Mesh) 到底導入時要怎麼抉擇與判斷。 Service Mesh 如果用得正確與適當，能夠為團隊帶來很多優勢，可以讓團隊更專注於軟體的服務上，讓 Service Mesh 幫忙提供各種方便的功能。 但是如果使用錯誤則可能只會造成整體架構更加複雜，同時也沒有解決什麼真的重點問題，一切只是疊床架屋的空殼而已。

1. 採用 Service Mesh 要儘早 作者認為到底要不要導入 Service Mesh 是一個專案初期就要決定的事情，即使 Istio 網站有特別教學如何將專案從 non-MTLS 給轉移到基於 Istio MTLS 的過程 但是作者說真的跑過這些流程就知道絕對不是官網寫的三言兩語這麼簡單，有太多額外的事情要考慮，譬如上層安裝的服務，網路分層設計等，這些會因為有沒有 Service Mesh 而有不同的決定

2. 不要當 Yes Man 作者體驗過最多的案例就是每個團隊看到下列問題都是不停的說 YES，然後最後就直接無腦導入 Service Mesh

3. 我們需不需要強化資安

4. 使用 mTLS 能不能強化資安

5. mTLS 是不是很難管理

6. Service Mesh 是不是可以讓 mTLS 便於管理

連續四個 YES 下來就直接無懸念的導入 Service Mesh，殊不知

因此作者接下來就列出幾個要導入 Service Mesh 前需要仔細思考過的問題

1. 是否有計畫於當下或是未來使用到 Serivce Mesh 的所有功能 Service Mesh 的功能除了 mTLS 外還有各式各樣跟流量有關的管理，譬如 A/B Testing, 金絲雀部署等。 透過 Service Mesh 能夠讓應用程式不需要實作這些功能而依然可以享有這些功能的好處。 所以作者認為團隊中的所有人都要仔細的注意，到底你們即將採用的 Service Mesh 有哪些功能可以用，這樣可以避免應用程式重複開發相同功能。 作者也提到不需要第一天就決定好要採用什麼功能，但是至少要仔細理解自己採用的解決方案到底有什麼功能，然後未來改善架構的時候可以即時的想起來這功能有提供

2. 團隊中是否有人對於 Service Mesh 有足夠的理論或是實戰理解？ 作者看到的非常多團隊很多人根本不理解 Kubernetes 以及 Service Mesh 但是就想要導入 Service Mesh。 由於對 Service Mesh 完全不理解，連其實作的概念都不同，所以當問題發生的時候就什麼都不能做，因為根本不懂也不知道該從何下手 請花時間學習與理解你要使用的專案，以確保你有足夠的背景知識去使用與除錯

除了問題之外，作者也認為要導入 Service Mesh 到生產環境並不是單純的建構一個 Hello World 這麼簡單，還有很多事情要考慮，譬如

1. 自動化
2. 監控與追蹤
3. 除錯與已難雜症排除

整篇文章非常的棒，有興趣的可以詳細閱讀

連結: https://buoyant.io/service-mesh-manifesto/

一篇關於 Service Mesh 的好文，發布已經有段時間了不過還是值得一讀， 文章作者是非常早期 Service Mesh 項目: Linkerd 的核心開發成員之一也是新創公司 Buoyant 公司的 CEO 相信大家應該對於 Service Mesh 一詞已經不陌生，可能對於這個名詞比較熟悉的朋友大多是從另一個 Service Mesh 項目: Istio 去了解 Service Mesh 的面貌，從這篇文章你可以從不同觀點認識 Service Mesh ， 全文非常長內容涵蓋：

• Service Mesh 詳盡介紹
• 為什麼 Service Mesh 可以被施行？
• 為什麼 Service Mesh 是個好的 idea (比起其他方法)？
• Service Mesh 幫助了什麼？
• Service Mesh 有解決掉所有問題嗎？
• 為什麼在現今 Service Mesh 可以被施行？
• 為什麼人們那麼愛談論 Service Mesh？
• 身為一個謙虛的開發者需要關注 Service Mesh 嗎?
• 一系列F&Q 這裡對 Service Mesh 的需求做個小結，Service Mesh 帶來了三大好處：

1. Reliability: 包含提供請求重試、超時、金絲雀部署(Traffic shifting/splitting) 等功能
2. Observability: 包含提供請求成功率、延時、粒度到個別服
3. Security: ACL 及 Mutual TLS (客戶端及服務端互信） 值得一提的是，本篇作者 William Morgan 對於 istio 持負面的態度，並不是因為 istio 與 linkerd 處於競爭關係的兩個產品，而是對於 istio 在 service mesh 做了太多的商業性 marketing 操作（大部分來自Go ogle的操作) 有興趣的朋友也可以在 Podcast 上聽到作者在 Podcast 上的訪談: https://reurl.cc/N6GbW9