對於雲原生化改造，大部分傳統企業可能還在初步摸索階段，但圍繞着Kubernetes的技術生態已經越來越豐富和完善，可應用的場景也逐漸增多。本文，InfoQ有幸採訪了Rancher Labs聯合創始人及CEO樑勝，探討Rancher在雲原生時代的技術思考。
雲原生
2017 年末，Google 在過去十年編織全世界最先進的容器化基礎設施經驗，最終幫助 Kubernetes 項目取得關鍵領導地位，並將 CNCF 這個以“雲原生”爲關鍵詞的組織和生態推向巔峯。根據 CNCF 的定義（V1.0），雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。
通俗理解，所謂“雲原生”，實際上就是在定義一條能夠讓應用最大程度利用雲的能力、發揮雲的價值的最佳路徑。在這條路徑上，脫離了“應用”這個載體，“雲原生”就無從談起；容器技術，則是將這個理念落地、將軟件交付的革命持續進行下去的重要手段之一。
然而，即便如今的Kubernetes項目獲得瞭如此多關注，但以此爲基礎的雲原生整個生態體系還沒有得到開發者的廣泛青睞，樑勝在採訪中表示，從概念上來說，雲原生已經被廣大開發者普遍接受，但總體而言，開發者對於技術的成熟度及穩定性仍存在信心不足等問題，還需要一段時間的發展以及推廣。從今年的情況看來，KubeCon的參會者逐年累增，側面反映了技術成長很快，關注的開發者也越來越多。
此外，技術的發展需要與應用場景相結合。樑勝表示，在大型互聯網公司比如阿里，Kubernetes的應用已經非常普遍，大量雲原生的場景給了Kubernetes用武之地，但傳統企業的很多應用場景，沒辦法在短時間內基於Kubernetes進行重構，因此發展會相對緩慢。在這種情況下，即便整個雲原生平臺都準備就緒，但在應用重構之前，企業也無法真正體會到雲原生平臺的優勢，對於傳統企業而言更爲尤甚。而目前的容器平臺尚沒有辦法真正做到免運維，當應用場景擴展到家用電器甚至偏遠地區的某個邊緣節點，技術人員將難以對其進行把控。雲廠商已嘗試在這一方向上發力，通過大量的自動化工具提高整體效率，但目前看來依舊有很長的路要走。
Kubernetes
在容器的發展過程中，Kubernetes是一個非常重要的項目，它提出了一整套容器化設計模式和對應的控制模型，從而明確瞭如何真正以容器爲核心構建能夠真正跟開發者對接起來的應用交付和開發範式。
過往一年，也有很多圍繞着Kubernetes展開的討論，比如Kubernetes的複雜性問題等。儘管這個項目已經成長了五年，並取得了很好的發展，但大部分企業和開發者還是會在Kubernetes項目上花費大量精力。而從另一角度出發，即使如今CNCF的原生技術圖譜已經十分龐大，在樑勝看來，暫時還沒有哪個項目的重要程度可以與Kubernetes對等，在Kubernetes上可以做的事情還有很多。言外之意，對Kubernetes的技術探索在未來一段時間內還將持續進行下去。
樑勝表示，首先，Kubernetes在設計之初是一種大集羣的概念，將所有機器都變成一個大集羣來管理，這一理念來源於谷歌大規模集羣管理器Borg，這樣的設計思想讓用戶無需關注資源管理的問題，並且實現了跨多個數據中心的資源利用率最大化。隨着Kubernetes技術的應用及發展，我們發現真正的企業用戶，特別是基於雲平臺使用Kubernetes的用戶，大部分都是多集羣的狀態，集羣數量可以達到十幾個甚至幾百個，且大多分佈在不同的地方，甚至使用不同的發行版和雲平臺。Rancher一直致力於解決生產環境中企業用戶可能面臨的基礎設施不同的困境，改善Kubernetes原生UI易用性不佳以及學習曲線陡峭的問題。
其次，目前大部分企業對於Kubernetes的探索主要集中在雲或者數據中心上，近兩年，邊緣節點上的Kubernetes也有了不同程度的進展，邊緣計算有着非常多的、值得探索的應用場景，比如智慧城市中就包含着大量邊緣計算的應用場景。這些邊緣節點產生的數據同樣需要收集處理，但由於部分邊緣節點的位置比較偏僻而導致帶寬不是很高，必須在本地處理數據，這也是Kubernetes值得關注和探索的一個重要方向。
最後，Kubernetes雖然已經發展得相對成熟，但在開發人員的推廣上還存在一定問題，Kubernetes技術的複雜性問題大家均有目共睹，沒有經歷過專業培訓的開發人員可能較難上手，這是需要持續優化迭代的地方。如今，Service Mesh、Istio等新技術的出現讓Kubernetes生態得到了進一步擴充，這些都是值得花費精力探究的內容。
樑勝指出，有些應用場景比較適合進行容器化改造，比如無狀態的應用、對可伸縮性要求比較高的應用和對快速迭代開發要求較高的應用。而其他的應用場景，如中臺和前臺的應用比較無狀態並有伸縮性要求，後端應用實際上狀態比較多，這些有狀態應用在容器化方面的進展則比較緩慢。
邊緣計算
隨着5G的標準化工作越來越完善，邊緣計算得到了長足的發展，這是很多企業都存在切實需求的一環。從Kubernetes的角度看，邊緣計算是一個非常複雜的問題，但從Rancher的角度來講，樑勝表示，Rancher定義下的邊緣計算是一個非常小的計算中心和數據中心。傳統的數據中心要麼是雲，要麼是機房。對於部分企業客戶而言，他們存在在地鐵站、風力發電站、收銀機等地方部署終端並進行數據分析計算的需求，如果統一在中央雲節點進行計算，帶寬需求比較高，網絡和數據可靠性也將是很大的問題，在邊緣節點直接進行計算是最爲可靠便捷的計算方式。
因此，樑勝認爲，邊緣計算在未來存在很多發展機會。基於此，Rancher開源了輕量級Kubernetes發行版k3s和業界首個Kubernetes操作系統k3OS。k3s是一個輕量級的Kubernetes發行版，專爲在資源有限的環境中運行Kubernetes的研發和運維人員設計，滿足在邊緣計算環境中運行在x86、ARM64和ARMv7處理器上的小型、易於管理的Kubernetes集羣日益增長的需求；k3OS是業界首個專爲Kubernetes而生的極輕量操作系統，資源消耗極低，操作極簡，秒級啓動，能大大簡化在低資源計算環境中的Kubernetes操作，提高Kubernetes運維的安全性，全面賦能邊緣計算場景，這是一對在邊緣計算場景的完美搭檔。
Rancher雲原生實踐
如果企業對雲原生的概念表示認可，並希望可以進行雲原生改造，就需要在技術選型上花費大量時間。在過去對於雲原生技術的探索過程中，Rancher向開源社區貢獻了輕量級的Kubernetes發行版k3S、基於Kubernetes的極簡MicroPaaS平臺Rio、業界首個Kubernetes操作系統k3OS、支持多個Kubernetes集羣之間的跨集羣網絡連接項目Submariner和爲Kubernetes集羣提供分佈式塊存儲的雲原生解決方案Longhorn。
爲了減少運行Kubernetes所需內存，k3s開發團隊主要專注於以下四個方面的主要變化：
- 刪除舊的、非必須的代碼：K3s不包括任何默認禁用的Alpha功能或者過時的功能，原有的API組件目前仍運行於標準部署當中。除此之外，Rancher還刪除了所有非默認許可控制器，in- tree雲提供商和存儲驅動程序，但允許用戶添加任何他們需要的驅動程序。
- 整合正在運行的打包進程：爲了節省RAM，k3s將通常在Kubernetes管理服務器上運行的多流程合併爲單個流程。還將在工作節點上運行的kubelet、kubeproxy和flannel代理進程組合成一個進程。
- 使用containerd代替Docker作爲運行時的容器引擎：通過用containderd替換Docker，k3s能夠顯著減少運行時佔用空間，刪除libnetwork、swarm、Docker存儲驅動程序和其他插件等功能。
- 除了 etcd 之外，引入 SQLite 作爲可選的數據存儲：在k3s中添加了SQLite作爲可選的數據存儲，從而爲etcd提供了一個輕量級的替代方案。該方案不僅佔用了較少的內存，而且大幅簡化了操作。
而在k3OS中，Kubernetes集羣配置和底層的OS配置都使用同樣的語法方式，這種方式類似Kubernetes中的CRD。如此一來，研發人員和運維人員將可以同時安裝和升級k3s及底層操作系統。與此同時，k3OS還將讓研發人員和運維人員能真正從“基礎設施即代碼（infrastructure-as-code）”模式當中受益，從而實現可靠的、可重複的集羣部署。這種操作方法將大大簡化管理員的使用體驗，同時也讓k3s在低配的計算環境中保持安全性。
“雖然Kubernetes可以安裝在任何的Linux發行版上，但將Kubernetes與底層操作系統分開進行系統補丁或升級的話，操作會很複雜。系統服務中的錯誤配置或安全漏洞，可能會危及到整個Kubernetes集羣。而k3OS的用戶永遠不必擔心計劃外的操作系統升級，只需一步即可將安全補丁應用於整個軟件堆棧。”樑勝解釋道：“作爲Linux系統和Kubernetes發行版的組合，相較於業界所有Kubernetes安裝，在k3OS上運行的k3s擁有最小的攻擊面，以及最簡單的升級過程。”
Rio則是Rancher今年發佈的第三個全新的Kubernetes輕量級項目，由一些Kubernetes自定義資源、一個可選的CLI和一個集羣中運行的控制器組成，在集羣中運行Rio，與在集羣中運行其他應用的方法及體驗並沒有什麼不同。傳統的PaaS平臺，向用戶承諾了一系列理想功能，從以往表現上看，PaaS平臺一直難以爲用戶提供真正優質的使用體驗，通常是重量級並難以運行的，在企業中需要有大型專用項目來部署它們，還需有專門的團隊對其進行管理。PaaS用戶經常發現平臺有太多的規範和限制，它們可能適用於特定的工作流程，但這未必是開發人員所熟悉的工作流程。
Rio來自Rancher的一系列項目（k3s、k3OS），這些項目均專注於輕量級、簡單且靈活的基於Kubernetes的項目。Rio的所有功能都經過專門設計，用戶可以直接使用默認設置來快速運行和使用Rio，當然也可以根據實際需要來進行靈活的配置、替換或禁用。如果只想使用Rio當中的一個功能，可以只使用這一功能並忽略其餘功能。總結來說，Rio是一個和Kubernetes生態系統緊密結合、並從中汲取了大量資源的平臺。
這些項目的共同點在於保證穩定性的同時，還做到了極其輕量。
樑勝強調，在項目輕量級的情況下，安全性並非最關鍵的問題，Rancher解決的最大問題是運維難題。傳統的技術開發流程對運維提出了較高要求，企業需要配備專門的團隊負責實施，Kubernetes自身的複雜性也讓很多互聯網企業必須設置一個專門的團隊做安全、可靠方面的工作，Rancher花費了大量的精力將系統運維簡單化，並向無運維的方向靠攏，整體設計思想或者側重點與傳統的基於雲、基於機房、基於數據中心的場景不大一樣。
作爲基於 Kubernetes 的開源企業級容器管理平臺，Rancher 對於 CI/CD 管道解決方案也有自身的考量。對於用戶而言，大部分企業用戶或者互聯網用戶已經設好了 CI/CD 的管道，甚至有很大的 CI/CD 的平臺。這也就意味着 Rancher 無需提供內置的 CI/CD 解決方案，用戶在使用 Rancher 的過程中，可以直接調用 Kubernetes API 接口和自己的 CI/CD 管道或平臺進行對接。
隨着 Rancher 的使用不斷普及，針對還沒有構建自己的企業級 CI/CD 平臺的用戶，Rancher 構建了一個簡單易用的 CI/CD 管道：Rancher pipeline。這套解決方案的最大特點是簡單易用，用戶無需從頭開始使用其他工具設置 CI/CD 流水線。Rancher pipeline 在靈活性和功能上來說略爲簡單，但它可以使很多用戶，特別是現在還沒有 CI/CD 平臺的用戶，很快地享受到 CI/CD 的好處。
如果再往下走，RancherOS是用來運行Docker的量身定製的操作系統，就好像k3OS是運行Kubernetes的操作系統。
除此之外，圍繞Kubernetes生態，Rancher打造了分佈式塊存儲解決方案Longhorn，現已捐獻給CNCF，該項目的主要功能是雲原生存儲。另一方面，Submariner是跨集羣網絡連接項目，目前也已被K8s社區接受。
總而言之，一直以來，Rancher都非常具有開源情懷。而云原生時代正需要大量有着開源精神的開發者積極參與社區共建，纔有可能讓整個生態取得更好的發展。
嘉賓簡介：
樑勝，Rancher Labs 聯合創始人及 CEO，是 Java 語言 J2SE 平臺核心組件 JNI（Java Native Interface）的作者，領導設計和開發了 Java 語言最爲核心的 JVM。2014 年 9 月，樑勝創立 Rancher Labs 並擔任 CEO，爲全球企業客戶提供容器企業級落地的解決方案。截止目前，Rancher Labs 已獲得三輪累計超過 4億元人民幣的融資，在全球擁有超過 25000 家知名企業客戶。