<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          服務(wù)網(wǎng)格仍然很難

          共 3300字,需瀏覽 7分鐘

           ·

          2020-11-18 03:55

          點擊上方藍色“程序猿DD”,選擇“設(shè)為星標”

          回復(fù)“資源”獲取獨家整理的學(xué)習(xí)資料!

          來源:6d.cn/8gd2


          北美KubeCon + CloudNativeCon虛擬大會贊助商客座文章作者:Lin Sun,IBM高級技術(shù)人員


          在今年8月的歐洲ServiceMeshCon會議上,來自Linkerd的William Morgan和我共同發(fā)表了篇題為service mesh is still hard的演講。William詳細介紹了對Linkerd的改進,而我介紹了對Istio的改進。很明顯,這兩個項目都在努力讓用戶更容易地采用服務(wù)網(wǎng)格(service mesh)。


          服務(wù)網(wǎng)格已經(jīng)比一、兩年前成熟了很多,但是對于用戶來說仍然很困難。服務(wù)網(wǎng)格有兩種類型的技術(shù)角色,平臺所有者(platform owner)和服務(wù)所有者(service owner)。平臺所有者,也稱為網(wǎng)格管理員,擁有服務(wù)平臺,并為服務(wù)所有者定義采用服務(wù)網(wǎng)格的總體策略和實現(xiàn)。服務(wù)所有者在網(wǎng)格中擁有一個或多個服務(wù)。


          平臺所有者使用服務(wù)網(wǎng)格變得更加容易,因為這些項目正在實現(xiàn)簡化網(wǎng)絡(luò)配置、安全策略配置和整個網(wǎng)格可視化的方法。例如,在Istio中,平臺所有者可以按照他們喜歡的范圍設(shè)置Istio身份驗證策略或授權(quán)策略。在將目標服務(wù)的實際路由行為和流量策略委托給服務(wù)所有者時,平臺所有者可以在主機/端口/TLS相關(guān)設(shè)置上配置入口網(wǎng)關(guān)。實現(xiàn)經(jīng)過良好測試的常見場景的服務(wù)所有者從Istio的可用性改進中獲益,可以輕松地將其微服務(wù)裝載到網(wǎng)格中。實現(xiàn)不太常見場景的服務(wù)所有者繼續(xù)遇到陡峭的學(xué)習(xí)曲線。


          我相信服務(wù)網(wǎng)還是很難,原因如下:


          1. 缺乏關(guān)于是否需要服務(wù)網(wǎng)格的明確指導(dǎo)

          在用戶開始評估多個服務(wù)網(wǎng)格或深入到一個特定的服務(wù)網(wǎng)格之前,他們需要關(guān)于服務(wù)網(wǎng)格是否有用的指導(dǎo)。不幸的是,這并不是一個簡單的是或不是的問題。有多個因素需要考慮:

          • 你的工程組織里有多少人?

          • 你有多少微服務(wù)?

          • 這些微服務(wù)使用什么語言?

          • 你有采用開源項目的經(jīng)驗嗎?

          • 你在哪些平臺上運行你的服務(wù)?

          • 你從服務(wù)網(wǎng)格需要什么功能?

          • 對于一個給定的服務(wù)網(wǎng)格項目,這些特性是否穩(wěn)定?


          更復(fù)雜的是,對于不同的服務(wù)網(wǎng)格項目,答案可能是不同的。甚至在Istio 1.5之前的早期版本中,我們也采用了微服務(wù)來充分利用網(wǎng)格,但是我們決定將多個Istio控制面組件轉(zhuǎn)換為一個獨立的應(yīng)用程序來降低操作的復(fù)雜性。對于這種情況,運行一個單體服務(wù)比運行4個或5個微服務(wù)更合理。


          2. 你的服務(wù)可能會在射入邊車后立即中斷

          去年感恩節(jié),我試圖幫助一個用戶在網(wǎng)格運行一個Zookeeper服務(wù),使用最新的Zookeeper Helm chart。Zookeeper作為Kubernetes StatefulSet運行。當我試圖將Envoy邊車(sidecar)代理注入到每個Zookeeper pod時,由于無法建立領(lǐng)導(dǎo)者和成員之間的溝通,Zookeeper pod無法運行并一直重啟。默認情況下,Zookeeper監(jiān)聽pod的IP地址,以實現(xiàn)服務(wù)器之間的通信。然而,Istio和其他服務(wù)網(wǎng)格需要localhost(127.0.0.1)作為偵聽的地址,這使得Zookeeper服務(wù)器無法彼此通信。



          通過與上游社區(qū)的合作,我們?yōu)閆ookeeper以及Casssandra、Elasticsearch、Redis和Apache NiFi添加了個配置應(yīng)變方法。我確信還有其他應(yīng)用程序與邊車不兼容。如果你知道任何一些,請通知社區(qū)。

          https://istio.io/latest/faq/applications/#zookeeper


          3. 你的服務(wù)在開始或停止時可能有奇怪的行為

          應(yīng)用程序容器可能在邊車之前啟動,并導(dǎo)致應(yīng)用程序失敗。在停止時間也會發(fā)生類似的挑戰(zhàn),即邊車可能會在應(yīng)用程序容器之前停止。


          Kubernetes缺乏聲明容器依賴關(guān)系的標準方法。有個邊車Kubernetes增強建議(KEP),但是它還沒有在Kubernetes的版本中實現(xiàn),需要一段時間才能穩(wěn)定下來?,F(xiàn)在,服務(wù)所有者可能會在啟動或停止時觀察到意外的行為。

          https://github.com/kubernetes/enhancements/issues/753


          為了幫助解決這個問題,Istio為平臺所有者實現(xiàn)了個全局配置選項,可以延遲應(yīng)用程序的啟動,直到邊車準備就緒。Istio很快也將允許服務(wù)所有者在pod級別上進行配置。


          4. 服務(wù)零配置可以,零代碼更改不可行

          服務(wù)網(wǎng)格項目的主要目標之一是為服務(wù)所有者提供零配置。一些像Istio這樣的項目已經(jīng)添加了智能協(xié)議檢測來幫助檢測協(xié)議并簡化網(wǎng)格的加載體驗,然而,我們?nèi)匀唤ㄗh用戶在生產(chǎn)中顯式聲明協(xié)議。隨著Kubernetes中添加了appProtocol設(shè)置,服務(wù)所有者現(xiàn)在有了種標準的方法來為運行在新的Kubernetes版本(例如1.19)中的Kubernetes服務(wù)配置應(yīng)用程序協(xié)議。

          https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol


          不幸的是,要充分利用服務(wù)網(wǎng)格的強大功能,零代碼更改并不可行。

          • 為了讓服務(wù)所有者和平臺所有者正確地觀察服務(wù)跟蹤,在服務(wù)之間傳播跟蹤頭非常重要。

          • 為了避免混淆和意外行為,重新檢查服務(wù)代碼中的重試和超時非常重要,以查看是否應(yīng)該調(diào)整它們,并了解它們的行為與邊車代理配置的重試和超時之間的關(guān)系。

          • 為了讓邊車代理檢查從應(yīng)用程序容器發(fā)送的流量并智能地利用內(nèi)容來做出決策,例如基于請求的路由或基于標頭的授權(quán),對于服務(wù)所有者而言,確保從源服務(wù)發(fā)送純流量“plain traffic”到目標服務(wù)至關(guān)重要,并信任邊車代理安全地升級連接。


          5. 服務(wù)所有者需要了解客戶端和服務(wù)端配置的細微差別

          在使用服務(wù)網(wǎng)格之前,我不知道Envoy代理有這么多配置是與超時和重試有關(guān)。大多數(shù)用戶都熟悉請求超時、空閑超時和重試次數(shù),但有一些細微差別和復(fù)雜性:

          • 當涉及到空閑超時時,HTTP協(xié)議下有個idle_timeout,它應(yīng)用于HTTP連接管理器和上游集群HTTP連接。對于不存在上游或下游活動的流,可以使用stream_idle_timeout,甚至可以使用idle_timeout路由覆蓋stream_idle_timeout。

          • 自動重試也很復(fù)雜。重試不僅僅是重試的次數(shù),而是允許的最大重試次數(shù)(可能不是實際的重試次數(shù))。實際的重試數(shù)量取決于重試條件、路由請求超時和重試之間的間隔,這些必須在請求超時和重試的總體預(yù)算之內(nèi)。


          在非服務(wù)網(wǎng)格環(huán)境中,源和目標容器之間只有一個連接池,但在服務(wù)網(wǎng)格環(huán)境中,有三個連接池:

          • 源容器到源邊車代理

          • 源邊車代理到目標邊車理

          • 目標邊車代理到目標容器


          每個連接池都有自己的單獨配置。Karl Stoney有個很棒的博客,解釋了其中的復(fù)雜性,以及這三個連接池任何一個可能會出現(xiàn)錯誤,以及需要進行哪些檢查才能修復(fù)它們。

          https://karlstoney.com/2019/05/31/istio-503s-ucs-and-tcp-fun-times/


          總結(jié)

          我希望上述挑戰(zhàn)能與你產(chǎn)生共鳴,無論你在何階段采用服務(wù)網(wǎng)格。我期待著觀察所有項目的創(chuàng)新,因為我們正努力使服務(wù)網(wǎng)格盡可能的無聊但有用。



          DD自研的滬牌代拍業(yè)務(wù),點擊直達


          往期推薦

          10道棘手的Java面試題,看看你能答對幾個?

          如果MySQL磁盤滿了,會發(fā)生什么?

          Mysql 都會遭受哪些方面的攻擊?

          你了解 Java 的 jstat 命令嗎?

          Git 提交代碼之后的幾種后悔藥

          為什么大多數(shù)IOC容器使用ApplicationContext,而不用BeanFactory


          掃一掃,關(guān)注我

          一起學(xué)習(xí),一起進步

          每周贈書,福利不斷

          深度內(nèi)容

          推薦加入




          瀏覽 41
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  不用播放器的AV网站 | 99精品在线观看 | 亚洲一区韩国 | 欧美亚州另类激情 | 国产精品嫩草影院欧美成人精品a |