隨著數字化轉型的大潮到來，越來越多的企業開始上云，同時也紛紛加入到微服務和K8S隊伍中。但在K8S整體環境究竟應該用自建的還是非自建？以及他們需要用到的服務，究竟應該自建還是直接用PAAS服務？這些問題往往會困擾住大家。

我在這里以中立的角度闡述下各自的優劣，給大家提供一些參考幫助大家能做出更利于公司發展的選擇。

在進行對比之前，我們先來了解一些概念。

1、什么是自建K8S？

所謂自建，就是使用自己在物理機和虛擬機上部署的開源Kubernetes平臺。

2、什么是非自建K8S?

非自建就是云上的PAAS服務，全套的從物理層到容器層的環境都由云廠商提供，底層也是基于開源的Kubernetes打造的，云上一般都自帶管理工具。

k8S平臺對比

K8S平臺無論你用云上的還是自建的，其底層都是一樣的。云上的服務會比自建的多一個管理界面，讓管理K8S平臺變得更容易。在實際生產過程中，我們也很少需要登錄到Master節點上去進行命令行操作。

發布可以通過統一的發布平臺，看日志排錯可以通過統一的日志平臺。只有極少數的緊急突發情況需要登錄到K8S的容器環境里去進行生產的直接調試排錯。因為整個K8S環境是面向所有服務的，所以要盡可能的避免直接登錄到K8S服務器上進行操作。

然后回到對比這個問題的本身，個人認為云上的服務比自建要好。云上優勢如下：

1、維護成本低

云上K8S服務除了不需要你部署之外，產品自身出現問題均有客服幫你解決。且自帶的管理界面基本滿足日常的配置需求。

2、PAAS服務集成度更高

如果你要和NAS或其它PAAS服務做集成，那肯定是用云上的更方便，如果是自建的會有一定的定制開發成本甚至完全無法集成都有可能。

3、穩定性更高

穩定性為什么會比自建高呢？因為自建的是面向所有大眾的哪怕有人踩過了坑但他解決后不提交問題，所以這個問題仍然存在未被修復。而云上的只要有人反饋必定會被解決，而且廠商肯定會想辦法修復這些問題避免其它客戶踩坑。

4、環境部署速度快

不要小看這個優勢，也許有一天他是你業務能快速恢復的救命稻草。

說完優勢再來說下劣勢：

5、成本比自建略高

根據選擇的版本不同會有價格的差異，部分版本會收取額外的平臺增值費用。

6、對個人學習成長不利

如果你是一個技術控，那么自建更適合。

下面我再舉兩個實際案例：

案例1：某服裝電商K8S選型歷程

該公司最初為了不被云廠商綁定，選擇了自建k8S平臺，但在運行一段時間準備上生產之前，突然K8S網絡出現故障，持續數日無法解決問題。最后，還是選擇云上K8S服務，運行至今未出現任何問題。

案例2：某在線教育公司自建K8S故障

該公司初期資源都在IDC機房，和上面案例一樣，某一天突然K8S網絡出現故障，導致生產業務全部中斷，所幸當時已過了業務高峰期，在確定無法修復的前提下進行重新環境部署和生產發布調試，整個過程持續了一天一夜。

K8S管理平臺對比

在做這個對比之前，我首先要靈魂拷問一下讀者，你要用這個管理平臺做什么？是想要一個能從創建到應用發布多功能的平臺，還是要一個只管理K8S平臺自身的工具。

如果你想要一個多功能的平臺，那這個平臺是否直接支持云上K8S服務？功能是不是全部滿足？每個功能模塊是不是足夠出色？如果有新功能需求是否支持定制開發？還有如果是第三方產品，本身出問題或不更新維護了是否意味著業務將停止不前？

所以管理平臺我建議還是選用只管理K8S平臺自身的工具，讓非K8S自身的模塊交給其它專業的工具去處理。如果是用云服務的那用云服務自身的管理平臺就足夠了。

下面我分別介紹一個第三方的和阿里云自身K8S管理平臺，并做下比較供大家參考。

1、Rancher

Rancher是一個開源的企業級容器管理平臺。通過Rancher，企業再也不必自己使用一系列的開源軟件去從頭搭建容器服務平臺。Rancher提供了在生產環境中使用的管理Docker和Kubernetes的全棧化容器部署與管理平臺。

Rancher由以下四個部分組成：

•  基礎設施編排
•  容器編排與調度
• 應用商店
•  企業級權限管理

整體來說Rancher滿足企業日常的K8S平臺管理功能，同時他也能管理主流的云上K8S服務集群。如果作為一個K8S基礎管理平臺，它是完全符合的。

2、阿里云自帶K8S管理平臺

阿里云ACK平臺在經過數年打磨之后已經相當成熟和穩定，功能也比較豐富，并且可以結合服務網格服務進行流量的管控。

它主要功能如下：

? 集群管理

除了可以管理自身的集群外，也可以通過注冊集群管理外部的Kubernetes集群：

•  鏡像服務
• 編排模版
• 應用市場
•  應用中心

可以多云多集群的部署分發：

? 備份中心

備份中心為Kubernetes集群中應用/數據提供了備份、恢復與遷移的一站式的解決方案，并支持跨集群和混合云。從功能來說阿里云ACK平臺要比Racher更強大。完全可以滿足企業的日常需求。

針對K8S配套的數據庫和中間件

使用自建和PAAS服務選型

如果你是怕被綁定而選擇自建服務，那大可不必。因為在你選擇擁抱公有云的那刻起你就注定了會被公有云給綁定。它的優劣和選擇自建和非自建K8S服務基本是一樣。核心點也是穩定性，PAAS服務的穩定性要大于你自建服務。

而且PAAS服務通常會伴隨著各家云的一些特色功能。比如阿里云的RDS原生支持數據存儲加密和傳輸加密，還支持讀寫分離。做備份和容災也更容易。

也許你還會問如果你要遷移怎么辦？遷移的話無論你是用自建還是PAAS服務都是可以遷移的，兩者在耗時上實際是差不多的。遷移服務一直都不是一件容易的事。

K8S環境CICD的選擇

現在各家平臺和廠商都會在管理K8S的時候集成發布平臺。但要把發布這個工作做好并不容易。各家平臺提供的大多數是基礎的修改Yaml配置來達到發布的效果。如果要在發布流水線中集成代碼安全掃描和自動化測試會變得很困難。所以專業的發布工作還是要交給專業的發布工具。例如：Jenkins。

總結

K8S環境應該為業務服務，要力求穩定、可彈性，其它任何理由均要在這個基礎上才能做進一步的分析。

以下為個人對上述觀點的總結，僅供參考：

K8S平臺選擇自建還是非自建個人建議選擇非自建的PAAS服務，原因是更穩定。無論其它理由在怎么充分穩定肯定是業務的首要關注點。如果非要嘗試自建則建議在非生產環境部署同樣版本的K8S環境。

K8S管理平臺選擇順序如下：

• 如果云環境自帶的管理平臺功能滿足則優先使用云平臺自帶的。
• 如果云環境自帶功能不滿足則考慮多個產品同時使用，不建議綁死在一個產品上。

數據庫和中間件選擇云的PAAS服務，如果是非核心業務且對穩定性要求不高的可以考慮自建。

CICD使用專業的工具，前期維護成本略高，后期穩定后只要修改下模板參數即可。

以下為總結的對比表：

最后建議，如果最終目標是想要實現PAAS服務自建的，建議在非生產環境做。如果有一天認為各方面條件都達到上生產環境了。則進行逐步的生產環境業務替換。把生產環境的PAAS服務逐步替換成自建服務。