鍾成 / 華為高階工程師

嘉賓介紹：Zlog 日誌函式庫作者。從 2014 年開始設計研發容器叢集和產品，目前致力於 Kubernetes 的效能和可擴充套件性優化，以及 PaaS 產品形態的探索和設計。

大家好！非常感謝才雲給我提供機會，來到技術論壇和大家分享一下十年後的 Kubernetes。大家聽到現在應該比較累了，我想這應該是一個比較輕鬆的話題。我今天想談的其實是一個比較偏輕鬆的話題，也是一個比較長遠的話題。再過十年之後，Kubernetes 這個專案或者這個生態會往哪個方向發展。

目  錄

先自我介紹一下，大家對我不太熟悉。我是 Zlog 的作者，以前寫過一些開源軟體，個人也喜歡在社群裡玩，然後物理系畢業，對中醫、雲端計算、人工智慧都有一定的興趣，喜歡折騰各種軟硬體系統。目前在華為搞 Kubernetes 和 Etcd 相關雲端計算產品，我做 Kubernetes 已經有三年了。今天我分享的話題希望從三個方面談談 Kubernetes 這個生態的後續的發展方向，包括通用系統、人機介面、網際網路產品。

通用系統

開發者角度：當前的分散式系統研發過程首先，我想提一個問題，現在 Kubernetes 非常火，十年之後，它會怎麼樣？ 我說的這些東西可能都是扯淡，不代表公司的看法，僅僅是個人想法和思考。

我想談的話題就是從開發者的角度來看，現在分散式系統的研發過程。現在分散式研發過程比較長，作為一個開發者，要做一個分散式系統還是很困難。也就是說，這裡列了幾個步驟，如果要做分散式系統，要做幾個拆分。要有一個大的拆分，有的模組是商務，有的模組是做業務，還有審計，還有日誌分析等等。模組拆分之後，就要寫程式。寫完單機程式之後要做測試，測試過程中由於拿不到別的系統的環境，就效果做打樁和整合測試。接下來會部署到真實的線上環境，有一個真實的線上業務進來，會做真實的除錯。

除錯完之後會做部署上線的釋出，釋出之後又會是一個系統的工程再往後就是說可能要解決執行過程的問題。前面還只是開發，後面是做運維。要做運維關心的實行更多，要解決配置、流程熔斷、授權認證、日誌聚合等等，整個過程非常長也非常繁瑣。如果我想要知道未來世界到底會怎樣發展，很簡單不需要思考未來，只要看現在和歷史就可以了。整個計算機在發展早期的時候，如果寫一個單機的程式是怎樣的，那時候就非常簡單。我的作業系統就是一個可以編譯，可以構建，可以釋出的完整系統，這就是一個系統的環境。寫完程式以後，在單機上一測試，二機制一執行，執行了就可以跑了。

從這個角度來說，我認為目前的整套生態系統，它在慢慢簡化，但萬里長征只走了一步。Kubernetes 解決了執行的問題，但並沒有解決前面流水線的問題。前面像馬道長也 Focus 這個問題，其實整個鏈上還有很多東西要做。這個系統發展到最後，可能做一個分散式應用，就和現在開發一個單機應用和現在一樣的方便和簡單。作為開發者來說，隨時可以啟動在 1000 個節上跑的分散式應用，這是我對未來的想法，中間肯定要經歷很多過程。

如果開發系統或者計算機系統往這個方向發展，會到怎樣的狀態呢？我個人認為它有點像現在的 Serverless，已經在往這個方向走了。它提供的是可以直接執行一些語言函式。對於使用者來講，只要編寫函式，直接在分散式上就可以跑。

但當前的 Serverless 有幾個問題：第一個問題，依賴於現在的關係資料庫，依賴於雲平臺；第二個它並不是非常通用的標準，現在已經有一個 Serverless 的專案在 GitHub 上，做得也挺好的。但它還是依賴於各個軟體平臺，並不是通用的作業系統，依賴於各大公司的一個產品。我個人更希望能看到有一種通用的正規化，就是任何一個人拿到這套東西之後，可以在 1000 臺機器上就可以跑自己的應用，這是我個人的希望。這樣帶來一個什麼問題呢？假定現在這個平臺是依賴於各個大的雲廠商，這個標準庫無法積累，就是一個語言一套東西要慢慢的發展，一定需要積累。就像現在 Kubernetes 正在積累自己的擴充套件庫，現在 Serverless 的發展沒法往下擴充套件。

我認為，容器是一箇中間狀態，說起來這句話有點不是很合適，但是我還是想講這句話，容器這個東西做了一個非常好的折中。它在前面的區域級應用和可打包的應用上做了一個非常漂亮的折中。我認為並不是終極形態，如果真的可以直接在所有的機器上跑應用，不用直接打包成一個容器，直接在一個執行器或者是解析器上跑就完了，沒有必要再通過容器。這個是我的看法。

現在肯定不可能，在工業界也不可能，不具有可操作性，但我認為未來肯定會往這個方向走。後面是我認為理想中的分散式計算的形態，它可以在多機上直接進行構建部署，測試執行。如果說做這個事情，前面業界已經做了很多的嘗試，包括 Golang。或者是一種分散式的編譯器，完全可以直接通過這個語言，在各個機器上直接執行，我可以提供所有的工具鏈的環境。

人機介面

UI及人機互動: pilotage的嘗試這是我個人做的關於人機互動的嘗試，我啟動了 Kubernetes 的叢集，我希望在人機互動上做一定程度的改進。大家可以看到，我啟動了一個 Kubernetes 的叢集，這和前面不一樣，我希望在人機互動方面可以進行改進。啟動了一個 Kubernetes 的叢集，啟動了一個 Pilotage 的工具，這個工具可以進入一個 Shell 的環境，然後我可以把 Kubernetes 的資源，全部都在一個檔案的樹上進行表示。

我進入一個 Name 就可以直接操作下面的資源，這個專案已經在 GitHub 開源了，大家有興趣可以就掃一下這個二維碼，它採用了樹型結構，用基本的命令列操作有的資源，包括 Pod，Node，這樣就可以直接看到這個容器裡所有東西。這樣就可以在一臺終端裡操作所有的資源，這就是我做的一個 Demo 的專案。

後面我會對它進一步深化，就是整合更多的資源或者說提供一些更通用的手段，做一個頂層的 Shell。

UI及人機互動: 手機端操作及包依賴另外的想法是服務端的軟體一般都是基於命令列操作，但我認為因為有很多資料要填，發展到最後肯定會類似於手機的 APP 一樣，可以通過像手機 APP 拖動進行安裝和解除安裝的方式，就像蘋果的操作方式進行安裝了解除安裝。因為手指的習慣更符合人的自然習慣，現在我們花了很多時間，填了很多引數，搞了很多包，把這個系統搞得很複雜，今後肯定有很好的方式做這個事情。

實際上，蘋果做這套系統有一個前提，底層有一個比較好的包管理工具。這個包管理工具是傳統的 Linux 的 DEB 或者是 Apt 的工具，我覺得這個工具非常好。現在的社群包就是 Helm，是靜態的依賴，它有點類似於 Windows 安裝方式，就是把所有的東西打到一個地方，把技術棧上的東西打到一個包上面進行部署。這樣有一個問題，這不符合分散式的習慣，執行是互相依賴的。比如說有一個數據庫，A 技術棧要用，B 技術棧也要用，打兩個包，我會把兩個後端資料放在同一個地方。現在還缺乏一種語言或者工具描述這種關係，就是它展現的是一種執行式的依賴，這個東西有點類似於現在Linux裡的 SystemD，可以動態的展示所有的關係，可以看出每個服務的啟動時間。

安裝方面沒有什麼改進的空間，Docker 本身就可以分層，Charts 我覺得安裝依賴沒有可以做一些嘗試和探索，但這還是初步的想法，我還沒有仔細考慮過這些問題，這裡面有很多的空間可以做。

網際網路產品

接下來我想談談這個平臺本身的命運。這個平臺或者一套作業系統，命運取決於到底有多少人使用它的目前對企業應用或者是微服務類的應用，已經有一些固定的正規化，想遷移上來比較困難，傳統都比較喜歡用虛擬機器的方式進行操作。包括阿里雲，我和他們交流過，他們把容器做成虛機，幾個容器之後就直接登入到虛機，也是張磊所駁斥的方法，裡面寫一個 SystemD 就直接在上面監控。

但有很多傳統的應用或者已經成熟的應用想遷過來很難，我認為為 Kubernetes 這個生態系統肯定是面向未來的，如果它想發展壯大，一定要擁抱新的應用、新的產品。這些新的應用和新的產品，可能是 AI，可能是大資料，這可能是未來的發展趨勢。

微軟的 Windows 為什麼會成功，是因為有了 Office 這個工具。使用者用得好，就會帶動平臺的發展。對 Windows 來說是 Office，對 Linux，就是 PHP 或者是 Apache 這樣的 Web 伺服器，讓 Linux 得到壯大。對 Kubernetes 系統來說，AI 或者是大資料會成為將來的主流，帶動這個平臺的發展。

作為開發者和程式設計師，編寫程式的時候，雖然現在還沒有這個環境，但可以考慮，不要把思想侷限在單一的伺服器上，可以去考慮未來的分散式應用，這個應用本身就是分散式，怎麼設計它，實現它。可以做新的程式，和以前的程式完全不一樣，充分利用現在大規模平行計算能力，因為現在的規模越來越大，各個行業沒有辦法完全解決這個問題，這是我的觀察點。

其實今天我的演講比較簡單。後面有時間可以開放性地討論一下。

內容來源：2017 年 10 月 15 日，華為高階工程師鍾成在 “首屆Kubernetes 中國使用者大會” 進行的《10 年後的 Kubernetes》為主題的演講分享。「K8sMeetup 中國社群」經演講者審閱授權釋出。