如何理解設(shè)備集群上的Kubernetes

這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)如何理解設(shè)備集群上的Kubernetes，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Kubernetes是起源于Google、在最近三五年里大熱的容器編排工具。戰(zhàn)勝了其他競爭對手之后，Kubernetes現(xiàn)在毋庸置疑地在云計算環(huán)境中占據(jù)壟斷地位。在收購了Heptio、Bitnami等頗有影響的初創(chuàng)公司之后，VMware成為Kubernetes全球社區(qū)中舉足輕重的貢獻者。2020年3月，VMware發(fā)布了Cloud Foundation 4，內(nèi)置革命性的Tanzu平臺，全面支持Kubernetes在云中更高效透明的運維管理。

與此同時，相當多的用戶和廠商在不斷嘗試將Kubernetes應(yīng)用于邊緣計算環(huán)境中。然而，邊緣計算畢竟不同于云計算，很多云中習以為常的基本假設(shè)，在邊緣上是不成立、或者成本過高以至于不現(xiàn)實的。

本篇將淺析其中的原委，并比較不同技術(shù)方案的優(yōu)缺點。這里專注于設(shè)備層的探討，而不是云邊緣（Cloud Edge）或移動邊緣計算（MEC）。對于Kubernetes來講，后兩者的技術(shù)環(huán)境與云中相比差別不大，基本可以無縫遷移。

設(shè)備集群上的Kubernetes

原生Kubernetes的基本假設(shè)

Kubernetes原本設(shè)計是在云計算環(huán)境中運行，所以它的基本假設(shè)就是云計算資源、基礎(chǔ)設(shè)施即服務(wù)（IaaS）的特性，包括：

 - 計算是充分的、可分布式部署的 
 - 網(wǎng)絡(luò)是穩(wěn)定的、可雙向聯(lián)通的 
 - 存儲是易失的、本地的，或持久化的、網(wǎng)絡(luò)化的 
 - 管理是遠程的、自動化的、自服務(wù)的
 - 安全是確保的、可控的、可編程的

Kubernetes由此而來的架構(gòu)設(shè)計思路充分利用了以上特性，例如：

 - 主節(jié)點多實例、從節(jié)點多層次抽象、分布式部署 
 - 主從節(jié)點間雙向聯(lián)通、高頻同步 
 - 元數(shù)據(jù)存儲持久化、網(wǎng)絡(luò)化，有狀態(tài)應(yīng)用可持久化
 - 遠程、跨云的管理方式 
 - 安全策略自動化

設(shè)備層的局限

然而Kubernetes的設(shè)計思路并不完全適用于設(shè)備層，因為這里一般的資源特點是：

 - 計算是有限的
 - 北向網(wǎng)絡(luò)是不穩(wěn)定的、窄帶的、昂貴的
 - 存儲基本都是本地的、易失的
 - 管理傳統(tǒng)上是本地的、人工的
 -   安全是不完全可控的

將Kebernetes應(yīng)用于設(shè)備層的不同技術(shù)方案差異的焦點，就是如何解決以上這些問題。

超融合持久化存儲

上篇介紹的超融合設(shè)備集群方案，可以較好地解決本地存儲易失的問題。業(yè)界也有一些基于裸金屬（Bare Metal）的開源持久化存儲方案可供選擇，這里不再贅述。

在虛擬化設(shè)備集群上部署Kubernetes應(yīng)用的步驟如下：

 - 安裝開源軟件govmomi和govc，按照vSphere存儲Kubernetes指南配置虛機，特別是為所有虛機設(shè)置disk.EnableUUID為true，以確保VMDK的ID是恒定唯一的
 - 以kubernetes.io/vsphere-volume做持久化卷（PersistentVolume）的提供者，將StorageClass聲明在vsanDatastore之上
 - 正常創(chuàng)建PersistentVolume和PersistentVolumeClaim

這樣就可以實現(xiàn)三層結(jié)構(gòu)的高可用性：

 - 如設(shè)備失效，設(shè)備集群代理/管理器可在另外一臺設(shè)備上重建該虛機節(jié)點；
 - 如虛機節(jié)點失效，設(shè)備集群代理/管理器可發(fā)現(xiàn)并重啟該節(jié)點；
 - 如Pod/容器失效，由Kubernetes重建該Pod/容器。

在以上任何情況下，保存在持久化存儲路徑下的數(shù)據(jù)不丟失。

安全性問題留在后篇整體介紹。

下面的討論主要針對計算、網(wǎng)絡(luò)、管理、維護這幾方面展開。

早期探索

Target
Target是美國一家著名的大型連鎖超市。在2017年初，Target就開始用Kubernetes和Spinnaker自建Unimatrix平臺，進行遠程集群管理。Target采用艦隊管理（Fleet Management）的模式，將含主從節(jié)點設(shè)備的整個集群部署到1850個門店中，每個集群由完全主從復用的三個節(jié)點設(shè)備組成，每個門店內(nèi)的集群都是互相獨立的。并在Unimatrix上支持Kubernetes API，以對接云端Kubernetes社區(qū)內(nèi)豐富的應(yīng)用生態(tài)。Unimatrix方案將Agent部署到門店，以對接Kubernetes集群和云的通信。

[https://tech.target.com/infrastructure/2018/06/20/enter-unimatrix.html](https://tech.target.com/infrastructure/2018/06/20/enter-unimatrix.html) 

[http://eshepickett.com/achieving-enterprise-agility-at-the-retail-edge/](http://eshepickett.com/achieving-enterprise-agility-at-the-retail-edge/)

Chick-Fill-A

Chick-Fill-A是美國一家非常知名的餐飲連鎖商。在2018年將2000間門店從Docker遷移到Kubernetes平臺上。每個門店以一組Intel NUC設(shè)備組成三節(jié)點集群，利用Kubernetes和大量開源軟件集成進行艦隊管理（Fleet Management）。

https://qconnewyork.com/system/files/presentation-slides/caopia-chickfilamilkingthemostoutof1000sofk8sclusters_0.pdf

https://medium.com/@cfatechblog/bare-metal-k8s-clustering-at-chick-fil-a-scale-7b0607bd3541

Chick-Fill-A的方案整體上與Target是類似的，都是全集群部署到邊緣設(shè)備上，并以其他方式進行艦隊管理，與Kubernetes相補充，形成多層管理結(jié)構(gòu)。

現(xiàn)有方案

上面的兩例都是Kubernetes的用戶為解決自身遇到的問題所自建的方案，下面介紹的是幾個業(yè)內(nèi)正在推廣的技術(shù)方案。

KubeEdge

https://kubeedge.io/

KubeEdge于2019年成為云原生計算基金會（CNCF）旗下的沙箱項目，是專門為物聯(lián)網(wǎng)和邊緣計算場景的設(shè)備層設(shè)計的。在它的架構(gòu)中CloudCore是和Kubernetes主節(jié)點一同放在云上，EdgeCore部分運行于設(shè)備上，之間的網(wǎng)絡(luò)可只單向可見。

CloudCore內(nèi)部的EdgeController與Kubernetes API服務(wù)器的交互，主要是通過在https://github.com/kubeedge/kubeedge/blob/master/cloud/pkg/edgecontroller/controller/下的downstream.go和upstream.go這兩個程序里調(diào)用kubernetes.Clientset的API來完成的。比如：

// DownstreamController watch kubernetes api server and send change to edge

type DownstreamController struct {

kubeClient   *kubernetes.Clientset

……

}

// UpstreamController subscribe messages from edge and sync to k8s api server

type UpstreamController struct {

kubeClient   *kubernetes.Clientset

// message channel

……

}

而EdgeCore部分，除了利用現(xiàn)有的容器運行時（CRI）工具之外，其他與CloudCore交互的程序都是自建的，實現(xiàn)類似于Kubelet的功能。EdgeHub與CloudHub之間的接口不兼容于Kubelet，而是基于websocket或QUIC協(xié)議實現(xiàn)的。

https://github.com/kubeedge/kubeedge/blob/master/docs/proposals/quic-design.md

最特別的是在邊緣上還有MQTT Broker與EdgeCore通信，將物聯(lián)網(wǎng)協(xié)議映射進來，再通過EventBus轉(zhuǎn)發(fā)到DeviceTwin里去。至今只看到ModBus和藍牙這兩種協(xié)議實現(xiàn)映射，而這種將邊緣容器平臺和邊緣應(yīng)用邏輯混合在一起設(shè)計的架構(gòu)是非常罕見的。

因為要以自建代碼支持全套的Kubelet機制，并保持與Kubernetes API服務(wù)器兼容，KubeEdge需要跟Kubernetes的逐個發(fā)布追趕實現(xiàn)。2020年2月發(fā)布的KubeEdge 1.2與2019年12月發(fā)布的Kubernetes 1.17兼容。

K3S

https://k3s.io/

K3S是Rancher發(fā)布的開源項目，它的主要設(shè)計思路是將Kubernetes集群小型化、輕量化之后整體放在邊緣側(cè)，通過其他管理通道與云側(cè)協(xié)同。這很類似于上節(jié)介紹的Target或Chick-Fil-A的傳統(tǒng)思路。

K3S利用Kubernetes的基礎(chǔ)代碼、再由自建代碼封裝，將所有的程序都打包進同一個二進制文件，安裝非常方便。但它的命令行必須由K3S觸發(fā)，比如sudo k3s kubectl get node。K3S中來自第三方的代碼主要集中在k3s/pkg/generated目錄下。K3S可以粗略地被看作Kubernetes一個非官方的、輕量級的、API兼容的項目。2020年5月K3S最新發(fā)布版支持Kubernetes 1.17.5。

小型化的K3S內(nèi)嵌輕量級數(shù)據(jù)庫SQLite，也支持外掛數(shù)據(jù)庫。K3S對于非OS的外部軟件依賴也減到很低。如果輔以負載均衡節(jié)點 的話，K3S就可以實現(xiàn)高可用性的部署模式。

Virtual Kubelet

https://virtual-kubelet.io/

Virtual Kubelet是CNCF基金會的沙箱項目，它是kubelet的API兼容實現(xiàn)，以允許由其他在云或邊緣上的服務(wù)實現(xiàn)的節(jié)點可以像kubelet一樣與Kubernetes主節(jié)點通信。雖然Virtual Kubelet最初的目的是支持無服務(wù)（serverless）等容器平臺，但也支持其他類型的服務(wù)。Virtual Kubelet提供可插入的Provider接口，開發(fā)人員可實現(xiàn)Kubelet所需要的如下功能：

 - 后端必要的管道性支持，管理pod、容器和Kubernetes語境下的支持性資源的生命周期 
 - 符合和Virtual Kubelet提供的API
 - 限制到Kubernetes API服務(wù)器的所有訪問，提供定義良好的回調(diào)機制以獲取如Secrets和ConfigMaps的數(shù)據(jù)

例如Azure IoT Edge Connector就是一個基于Virtual Kubelet Provider接口的實現(xiàn)。通過封裝的IoT Edge Provider與Virtual Kubelet交互，可以標準Kubernetes API的方式將邊緣應(yīng)用部署到設(shè)備上。當然該部署是以不同于云應(yīng)用的異步方式實現(xiàn)。

https://github.com/Azure/iot-edge-virtual-kubelet-provider

與此類似的，技術(shù)上可以實現(xiàn)支持其他邊緣應(yīng)用部署的Provider，而主從節(jié)點其實都在云側(cè)，通過既有邊緣計算平臺的通道進行管理。

MicroK8s

MicroK8s是由Ubuntu推出的開源軟件，它封裝成snap形式的Kubernetes各應(yīng)用的一個集合體。它的特點是：

 - 小：將必要的程序打包在一起方便部署；
 - 簡單：單一snap包安裝，無外部依賴，簡化管理和運維；
 - 安全：來自上游的安全更新很快；
 - 現(xiàn)時：及時更新來自于上游的代碼，可選擇最新或任意版本；
 - 全面：包含積累的通用manifest集合。

MicroK8s里的自建代碼很少，主要實現(xiàn)snap打包的功能，它是非常簡化的Kubernetes發(fā)行版。Snap包的格式主要用于Ubuntu類系統(tǒng)，在其他各Linux發(fā)行版上 也有支持。

MicroK8s的命令行必須由microk8s觸發(fā)，比如sudo mirok8s kubectl get node 。它的主從節(jié)點需要都部署在邊緣側(cè)，然后從云側(cè)以其他通道進行遠程管理。

選項比較

以上介紹了幾種現(xiàn)在比較主流的將Kubernetes部署到邊緣上的開源項目和技術(shù)方案。每種方案各有優(yōu)缺點，列表對比如下：

從普通開發(fā)人員和用戶的角度出發(fā)，最理想的將Kubernetes部署在邊緣側(cè)的方案，應(yīng)當具有如下特點：

 - 資源消耗少
 - 完全兼容
-代碼與Kubernetes上游同步
-認證發(fā)行版

- 管理簡單
-主節(jié)點在云側(cè)
-從節(jié)點在邊緣

然而從上表中可以看出，任何現(xiàn)有方案都無法滿足所有的理想化需求。這樣的需求，也許只有Kubernetes項目重構(gòu)之后才有可能滿足。

沒有銀彈

在現(xiàn)有條件下，如果不能滿足所有理想化需求，是否可以退一步看，哪些是可以放棄或妥協(xié)的需求。比如：

有必要把主節(jié)點放在云側(cè)嗎？

主節(jié)點在云側(cè)、從節(jié)點在邊緣最主要的價值是統(tǒng)一簡化的管理。如果可以接受多層管理機制，及邊緣側(cè)較多的資源消耗，在這點可以讓步。

有必要用Kubernetes嗎？它對邊緣計算到底意味著什么？

Kubernetes的主要價值，對很多用戶來說是豐富的生態(tài)軟件，邊緣與云側(cè)管理統(tǒng)一的API。如果用戶的云環(huán)境里并未部署大量Kubernetes應(yīng)用，那基于云邊協(xié)同的直接價值就不明顯了。

有必要部署分布式邊緣應(yīng)用嗎？

Kubernetes是編排分布式容器應(yīng)用的主流工具，但邊緣應(yīng)用很多并不需要分布式部署。如果是這樣，Kubernetes可能用起來還不如Docker Compose順手。

總之，在現(xiàn)有條件下，用戶需要根據(jù)自己的實際狀況和需求選擇適合自己的Kubernetes部署工具，如果Kubernetes是必要的話。沒有放之四海而皆準的方案，也就是“沒有銀彈”。

文章介紹并比較現(xiàn)有的將Kubernetes應(yīng)用于邊緣的各種技術(shù)方案。實際上Linux基金會邊緣計劃托管的EdgeX Foundry就是需要分布式部署的邊緣計算應(yīng)用框架。

上述就是小編為大家分享的如何理解設(shè)備集群上的Kubernetes了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。