Conduit AMA 活動回放

本月初我們面向 Kubernetes 發布了 Conduit —— 新一代超輕量級 Service Mesh。在享受對 Conduit 的熱烈歡迎的同時，我們還在 KubeCon + CloudNativeCon 上同大家有了近距離接觸。為了和未能參加奧斯汀會議的用戶進行溝通，我們於 12.11 日在 Slack 上舉辦了一場由 Buoyant 共同創始人 William Morgan 和 Oliver Gould 主持的AMA 活動。

我們還給錯過這一活動的用戶準備了一份談話記錄。為了方便閱讀，這裡在保持內容完整性的前提下對談話稿進行了一些編輯。

Conduit 和 Istio 有什麼不同？

William：基本上說來，Conduit 和 Istio 具有相同的目標(Linkerd 也是)：面向微服務應用，通過管理通訊層，為其加入超時、重試、斷路器、TLS、策略等在 Linkerd 中備受歡迎的功能，提高應用的可靠性、彈性和安全性。但是其切入角度不同：Conduit 希望為這一目標提供一個儘可能小的方案。這個小字的範圍，除了包含 CPU、內存、延遲影響之外，還包含了 API 和學習曲線等方面，這是很重要的區別。

Linkerd 進入生產運維的 18 個月以來，我們積累了很多經驗，其中的相當一部分是我們沒有預料到的。Conduit 將會吸取這些寶貴經驗。如我所願，Conduit 應該在不大幅提高用戶和系統負擔的情況下，為用戶提供 Service Mesh 應用的所有功能。

今天發布的 Conduit 0.1 包含了什麼？路線圖的下一步是什麼？

Oliver：0.1 版本的首要目標是為 gRPC 服務提供第一支持。這主要是一個工程目標——相對於老舊的 HTTP/1 來說，HTTP/2 的傳輸是一個比較複雜的問題。在後續版本中，我們會把代理範圍擴展到 HTTP/1 以及其他 TCP 連接。另外，我希望我們可以集成 CA 系統來提供開箱即用的 TLS 支持。

Conduit 什麼時候會達到生產可用水平？

Oliver：Conduit 有了生產環境部署的時候就說明是生產可用了;D

不過我們希望是在 2018 年初。我們會專註於提供預設的的可視化、安全性功能，以及基本的運維能力，這些都是進入生產環境的基礎要求。我希望在成功提供一批生產特性之後再考慮提供更多的配置界面。

看起來 Conduit 目前沒有提供 Ingress 控制器。這是否說明 Conduit Proxy 會當做 K8S Ingress 控制器運行？在這個(沒有 Ingress 控制器)的空檔期，如何讓 Conduit 和現有的 K8S Ingress 控制器協同運行？

Oliver：在我們達成透明代理的目標之後，Conduit 能夠支配任意流量的時候，這就很簡單了。在這之後我們會有 K8S Ingress 資源的集成手段；日後我們會需要更好的東西。不過目前 Conduit 的路由功能優先順序是最高的。

William：個人看法，我覺得 Conduit 和 Contour 這樣的產品系統工作會很有意思。

Oliver：Conduor ？

William：TourDuit ？

注入了 Conduit 的 Deployment ，如果運行過程中 Conduit Sidecar 奔潰了會怎樣？會導致整個 Deployment 失效么？能恢復么？

William：Sidecar 崩潰和 Pod 崩潰是一樣的。我們在 K8S 中用了很多措施來處理這些問題。。。他應該不會崩潰。

Oliver：如果崩潰，歡迎提 Bug。

現在 Buoyant 所有的工程師都在做 Conduit 么？或者 Conduit 和 Linekerd 各自為政？如何協調雙方的支持呢？

William：我們會持續對 Linkerd 做出重大的投入。Linkerd 是世上應用最廣泛的開源 Service Mesh，也是世界上唯一一個生產就緒的 Service Mesh。雙方佔用的都是團隊成本，很難分拆。總的說來，Linkerd 和 Conduit 是同一群工程師開發的，對我來說 Buoyant 的每個人都共享各自的特長也是很重要的。

這樣是不是可以說在 Buoyant 兩者的優先順序是同樣的？

William：更合適的說法是，我們把創意方面的點數加給了 Conduit。

Oliver：我們想讓 Linkerd 變得穩定，穩定到無聊。

William：Conduit 也會無聊的。。在未來。

Conduit 最鵝妹子嚶的特性是什麼？

Oliver：Tap，必須是 Tap。可能還有基於路徑的統計。又或者是深度集成到緩衝管理中的流量控制。

非 Buoyant 社區成員如何參與這一新項目？

Oliver：最好的方式就是提出 https://github.com/runconduit/conduit/issues 以及提供反饋！未來的幾個星期，我們會貼出更多的路線圖和入門指南。

William：是的，我們在 Slack 的 #conduit 頻道收到了第一個 Issue，有用戶指出無法運行 Conduit，我們推測是 RBAC 問題。這很好，我們會跟進的。

從貢獻的角度呢？選擇 Rust 是否會對潛在的 PR 造成限制？

William：我真的希望採用 Go 編寫控制平面會降低為 Conduit 做出貢獻的門檻。我認為在 Linkerd 中，Scala 不太容易，這 (不是常規的 Scala，是 Finagle 式的 Scala) 造成了一些困難。

Oliver：Rust 也不太容易——雖然 Rust 挺有意思。

William：Rust 的學習曲線比較陡峭，但是數據平面和多數用戶需要的東西進行了隔離，所以總體上來說，我們認為給 Conduit 做提交會更容易。我們正期待第一個 PR。

12.22 我們接受了第一個社區 PR，感謝 Fakod。

周末試用 Conduit 的過程中，感覺 Proxy 狀態界面有點困惑，能說明一下這一界面中表達的意義和預備如何使用么？

William：界面中呈現了 Deployment 之中的 Pod，綠色那些是注入了 Conduit 的，灰色的是沒有注入的。在截屏中你會看到一個引發的滾動更新過程正在進行。目前的展示還是符合目標要求的，但是一定有些方法能夠讓這一界面更加清晰。

Kevin Lingerfelt：上星期我們給這些圓形圖標加入 hover 狀態，用於說明具體意義。這一特性將在 0.1.1 版本中提供。

William：這樣很好。我們目前還沒提供 Pod 終結過程的展示，有了這個的話，Deployment 的遷移過程會更加清晰。

對 Conduit 感興趣的非 Rust 開發者如何做出貢獻呢？有個入門指南會很有用吧？

William：是的。我們的短期 TODO 列表中就包含這一項目。事實上無需 Rust 也能做出貢獻。事實上我希望除了一些非常特定的功能，無需學習 Rust 都能做出貢獻。

Oliver：基本同意。控制器 API 還在落實，這些是幫助構建更好功能的去處。

Conduit 的發布方式是怎樣的？Linkerd 每兩星期一次發布，Conduit 會如何呢？

William：雖然喜歡，但是我不確定是否能保證兩星期一次的更新。為了能夠儘快以最小功能集進入生產，我們有一些較為激進的目標，正如 Oliver 上面提到的，我們的目標是在 2018 年初完成。另外一個讓我們比 Linkerd 輕鬆一點的是我們的控制平面是可以使用 gRPC 插件配置的，這意味著我們可以：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！