如何打造一個更好的 Kubernetes 發行版

來自專欄 KubernetesMeetup 社區4 人贊了文章

企業在使用 Kubernetes 前需要準備：重構業務以更適合微服務框架；重構應用程序，將其分離到不同的服務單元並容器化；僱用更多技術精湛的員工；重建整個團隊的技能集和管理流程以採用 DevOps。這個過程很複雜，所以需要一種產品/服務來縮短企業使用 Kubernetes 的過程，減少學習成本、人力成本，並將更多資源用於業務開發。

Gartner 分析認為，在 2020 年，大概有 50% 的企業會將他們的業務容器化，基於 Cloud Native 容器化之後，將業務跑在它的生產環境里。目前這個比例只有 5%，但用 2 年的時間就會有 10 倍的業務提升。這對企業內的技術人員來說是一個積極的信息，說明 Kubernetes 是一個值得投入人力和精力的大趨勢領域。接下來我將基於公司目前打造的一款 Kubernetes 發行版，總結一下在構建整個發行版的經驗。

使用 Kubernetes 問題與挑戰

Kubernetes 如此強大的平台，如此多的便利功能，也是有缺點的。比如說 Kubernetes 學習成本比較高。

案例一

在 1 年前，我們基於 App Center pass 平台，交付了我們的 K8S APP。我們是把一個全託管的 Kubernetes 集群，交付給客戶，客戶可以通過一鍵部署，擁有 Kubernetes 的集群。

用戶在使用這個 Kubernetes 集群時，會碰到一些實際問題。比如一個互金客戶，他是運維人員，以前他搭建一個環境，都是基於傳統虛擬化，需要 50 分鐘左右。而他基於 Kubernetes 搭建相同的一套環境只需要不到 5 分鐘。

以前搭建集群，這套環境是所有開發測試人員共用的。基於 Kubernetes 後，每一個測試人員都擁有一套獨立完整的環境，他們利用 Namespace 去做資源隔離。但他們整個運營團隊，都要圍繞 Kubernetes 這套環境，在外圍構建更多東西，就像它的 CI/CD(持續集成/持續交付)，還有企業內部的一些業務系統集成，需要通過我們 的 App Centerde 開放的 API 進行二次開發以完成對集群自動化操作。

案例二

近日，一個運維人員最近總是收到很多業務人員的抱怨。之前進行的容器化改造，他們已經花費了很大力氣。現在要跟他們介紹 Kubernetes。但開發者們並不關心你的平台是什麼。他們關心的是業務能力，通過熟悉的代碼，將業務能力變現，提供給企業，轉化成企業價值，所以他不願去承擔這種額外的學習負擔。

當你把一個 Kubernetes 集群拋給他們時，他們是不會關心這個 Pod、Namespaces 是什麼。開發人員的期望是，代碼提交後能給他一個可以訪問的入口去測試。出現問題時，可以給他一個能看監控日誌的地方，他們並不關心你用的是什麼平台環境。這就是 Kubernetes 本身的問題，它學習成本高，環境搭建複雜。

對於企業來講，它有一定的隱形成本，這個隱形成本是什麼？你需要有一個專業的團隊，幫你運維相應的東西。現在企業人力是最貴的，運維這樣的團隊，企業會產生很大的負擔。另外 Kubernetes 本身的多租戶比較複雜。在一個大型企業環境中，如何通過 Kubernetes 這套多租戶去對接現有企業 IT 環境里的權鑒系統，這是一個問題。另外它作為一個開源項目，怎樣去獲取持續支持，也是一個問題。

Kubernetes 發行版

Kubernetes 發行版是沒有統一的定義，在 CNCF 社區的 Landscape 頁面可以看到經過社區認證的 Kubernetes 發行版。這裡有很多版本，這對於用戶來說是非常苦惱的，用戶在接受 Kubernetes 已經花了很大的精力，但面對這麼多發行版又該如何選擇呢？

在我看來 Kubernetes 發行版是底層基於原生、定製化的 Kubernetes，在上層封裝多種服務組件，在 Kubernetes 之上提供更多的增值服務，滿足企業內各種場景需求的分散式容器編排管理平台。就像 Linux 發行版是基於 Linux 內核提供的一種操作系統。同樣 Kubernetes 是在分散式領域一個內核，發行版就是在這種內核之上，去構建一個可用的分散式操作系統。

對於企業來說 Kubernetes 最重要的幾點是什麼？

第一，就是安全。安全和管控是企業用戶最關心的問題，Kubernetes 本身的這種安全設計，雖然功能很強，但是它並不友好，複雜且沒有一個管控入口。比如說你可以通過命令，看到和管理裡面的一些許可權配置。但是它沒有很好的集成方式，管理起來也比較分散複雜。從發行版的角度來看，是能夠去對接企業現有的這種權鑒管理系統。

第二和第三個難點是網路和存儲，也是最難的兩件事。Kubernetes 專註的是一個分散式的調度平台，它的網路化存儲基於統一化的標準，開放給其他存儲和網路廠商，來幫助開源項目或是個人開發者去構建網路存儲解決方案。如何幫助企業做適合他們業務的網路化存儲選型，這是重點要考慮的事情。

比如，我們在 QingCloud AppCenter 上交付的 Kubernetes 集群，通過自己開發的網路插件，存儲插件，和 LB 插件，對接到現有的網路、存儲，和負載存儲器。在 我們的 Kubernetes 發行版里也會有類似的交付物給客戶。

比如，在基於非雲平台的環境上，它沒有 LB 的能力。我們也即將開源一款基於物理交換器的 LB 插件，通過它可以對接物理交換器，在 Kubernetes 環境里，把你的後端業務暴露出去，提供給集群之外去服務。另外 Kubernetes 對於 CI/CD 場景、服務治理場景，應用管理場景，它都沒有太好的支持。

Kubernetes 發行版應該幫助企業去解決這些問題。部署 Kubernetes 是比較複雜的事情。雖然現在有很多自動化的工具可以幫你很快地搭建一套 Kubernetes 環境。但是學習這些自動化工具，會帶來一定成本。從發行版的角度，應該為用戶提供一種習慣性的嚮導式的安裝方式快速搭建一套 Kubernetes 環境。

從發行版的角度來看控制台是一個很重要的地方，它是發行版產品的一個入口，客戶通過這個入口，接觸到 Kubernetes。以前 Kubernetes 只是通過 kubectl 的入口。雖然，社區是通過一個開源項目 Dashboard 提供 UI 的能力，但交付東西對用戶來說，有一定的學習成本。因為他是完全按 Kubernetes 這個架構去提供 UI 的,它的一些功能比較弱，所以從發行版來看，應該去幫用戶來解決這些問題。

什麼樣的用戶能夠從發行版上獲得益處？

第一種用戶，之前的業務是基於傳統虛擬化或用物理機去構建。如果它現在有這種容器化的需求，就可以通過發行版，快速遷移到這種容器化平台上。

第二種是已經容器化的客戶，他之前的業務量可能比較小。以前基於 Docker Swarm 簡單的集群，就可滿足業務需求。但是隨著整個業務的提升，它需要遷移到一個大規模的容器調度平台來幫助它去提升業務能力，通過發行版可以快速遷移到整個平台之上。

第三和第四種，是接觸 Kubernetes 比較早的用戶。他們在自己的 IT 環境里，構建了一些 Kubernetes 環境，也許這些環境是通過別的廠商來提供的，但這些都會給他們帶來很大的額外負擔。

在運維上，它需要有相應的運維人員幫助他們去管理這些來源不同的 Kubernetes 資源。如果是不同廠商提供的 Kubernetes，會有各自的平台入口。企業是希望通過統一的入口，把所有 Kubernetes 管理起來。發行版就是一個很好的統一平台入口，將這些不同來源和版本的 Kubernetes 管理起來。

不同 Kubernetes 的發行版基於不同的業務需求，不同的考量，還有不同的設計架構。各家交付與設計出來的東西不同，但是它都會有一個基本的架構。

基本上是這種三層的架構：

• 底層可以去對接不同的計算資源，可以是物理機、虛擬機、不同雲廠商提供的平台；
• 中間層可以把不同的 Kubernetes 集群管理起來。對於網路存儲，它可以通過不同插件，對接底層計算平台的網路和存儲；
• 上層可以提供不同的業務解決方案，比如說 CI/CD，它可以提供監控日誌告警、安全、應用管理、服務治理，可以交付給用戶真正地使用。

關鍵場景方案選型：微服務治理

我們在做 Kubernetes 發行版時，做了一些業務、產品上的選型，調研得到一些結果供大家參考。在這並不會說哪種解決方案最好，從企業人員角度來看是要考量企業內部的業務，究竟適合哪種場景，然後去選擇適合自己的解決方案。

場景一

對於我們自己打造的 Kubernetes 發行版，當時考量的是兩種解決方案，一種是基於Spring Cloud。另一種是基於 Istio。Spring Cloud 是 Java 語言綁定的，這意味著你在寫 Java 代碼時，基於這種標準，你需要在代碼里寫進各種標籤。這就意味著開發人員會承擔更多的責任。另外，Spring Cloud 的服務發現是基於 Eureka 組件做的。但 Kubernetes 本身會提供服務發現功能，這就有功能上的重疊。Eureka 和 Spring Cloud 也意識到了這個問題。它現在做的另一個方案就是利用 DiscoveryClient 去滿足 Kubernetes 這個平台的需求。但 DiscoveryClient 現在還在孵化階段。

另外，Spring Cloud 有代碼侵入，它需要在代碼里插入相應的標籤。同時，Spring Cloud 在做部署調度時，要通過 Spring Boot。Spring Cloud 專註的是服務治理，它要把整個流程串起來還需要其它的組件來完成整個的業務鏈條打通。

但是 Istio，第一，它跟語言無關；第二，它是基於 Kubernetes 做的服務發現；天然的適合 Kubernetes 這個平台；第三，它不會侵入你的代碼；第四，它的調度部署是直接使用 Kubernetes 本身的功能。

在我們自己的 K8S APP上，很早就把 Istio 作為一個服務組件，集成到這個 Kubernetes 的 APP 里。當時 Istio 是 0.6，後來又更新到 0.7。有些客戶就反映，Istio 有很多問題且性能相對較低。

目前我們在調研的 Istio 0.8 這個版本，它這已經能夠很好的解決之前的一些問題。同時，我們對它今年要發布的 1.0 版本也比較有信心，相信它能解決之前一些性能上的問題。

場景二

另外一個關鍵場景，就是 CI/CD 的持續集成、持續交付。它涉及到了三個環節，第一是應用管理，你的應用如何去交付，如何去做應用包管理。Kubernetes 本身在這個平台上有一個開源項目叫 Helm。比如，Linux 發行版在安裝一些軟體時，通過 apt-get 或 yum 去裝。Helm 在 Kubernetes 這個平台上類似於這種地位，它是做應用包管理的。

如果我要在產品裡面去集成，把這些三個鏈條，三個階段去打通，去集成這些產品的話，會給我帶來很多的風險，比如說許可權管控，流程管控，如何去跟企業現有的這種許可權系統去做集成。

為了解決這些問題，我們決定以微服務的方式去構建我們的 CI/CD 模塊，基於 Kubernetes 去交付，這樣可以天然地利用平台的種種已有功能區降低風險，比如發行版上已有的許可權管理，調度等功能可以直接作用於 CI/CD。

實踐分享

在做 Kubernetes 發行版時遇到的問題

第一，就是 etcd 和 MySQL。發行版最重要的就是給用戶提供統一的入口，用戶體驗是至關重要的。Kubernetes 把它整個集群裡面的信息都註冊到 etcd 里，但以 UI 的方式去把 etcd 交付。這並不是一件很友好的事情。因為 etcd 是一個分散式的 KV 存儲系統，它比較適合訂閱，服務發現等場景。

但在 UI 里，通過 etcd 去做一些分頁和複雜性的檢索會比較麻煩。最終我們通過 watch etcd 里的數據變化，把相應的數據導入到 MySQL 里。這樣前端人員直接面對的就是 MySQL 的後端數據業務展示，聚合會比較方便。

第二，監控。Kubernetes 監控，它本身推薦了幾種方式，包括 Heapster，Metrics Server，還有 Prometheus。那麼 Heapster 已經是 deprecated 的狀態，但它還是在維護階段。Heapster 可以支持到 1.12。Heapster 頁面的替代品是 Metrics server。但是 Metrics server 還在孵化階段，它的 Metrics 提供的監控比較少，它也支持不了 kubectl top，無法看到資源使用率排序數據，而且 Metrics server 在社區活躍度很低。

Prometheus，它不只支持 Kubernetes 這個平台，它還支持其它的一些平台。但這種通用的解決方案使用起來過於複雜，我們期望的是一種簡單化的方式交付給用戶。

目前，我們使用 Heapster 作為臨時解決方案，把數據 sink 到 Kafka，這樣很方便我們做 HA。通過 Kafka 去做第三方系統集成。在這種大型企業里，已經有監控系統和日誌管理系統。我們發行版會提供內置的監控和日誌這些服務組件，但是企業並不會去採用，企業想把所有監控信息，日誌信息通過統一的平台把它管理起來，所以我們要提供這種第三方對接的功能。

另外，我們在使用 Heapster 的過程中碰到一些問題。不同規模的集群，比說上百上千的這種集成規模，需要對 Heapster 所佔用的資源進行調整，根據做集群的規模的不同去做調優。Heapster 對於開發者並不友好。它的每個 Metrics 都是一個獨立的 REST API，前端使用起來很麻煩。

小結

Kubernetes 已經佔據了容器編排領域的主導地位，但其高昂的學習以及運維成本，導致個人和企業用戶望而卻步，在這個分散式操作系統的內核之上，我們打造了我們認為更好的 Kubernetes 發行版，讓它能更貼近於用戶，讓用戶更專註與自己的業務。在這個過程中，我們碰到並解決了諸多問題，借這次機會和這個平台分享給大家，希望能給各位在日常使用和評估相關 Kubernetes 產品的時候提供一定幫助，謝謝。

於爽 / Qingcloud 容器平台資深架構師

青雲容器研發工程師，負責青雲 QingCloud PaaS 平台容器相關服務的設計與研發工作。