歡迎光臨
每天分享高質量文章

Kubernetes 是下一代操作系統 | 面向 Kubernetes 編程

此文章適合沒有任何 Kubernetes/容器/Docker 經驗的同學 —  在不久的將來,你不懂如何操作 Kubernetes 接口,就等於現在的你不懂最普通的 Linux 命令。 此文章閱讀耗時大概 15 分鐘。

螞蟻金服資源調度組致力於將 Kubernetes 落地到世界上最有價值的金融科技獨角獸公司,歡迎聯繫作者微信: answer1991chen 咨詢招聘事宜。

文章 Markdown 原始碼位於

https://github.com/answer1991/articles/blob/master/Kubernetes-is-the-next-generation-os.md 

遵從 Apache License 2.0 開源協議。

導言

此文章著重介紹如何在入門階段使用 Kubernetes,以及要面向 Kubernetes 編程帶來的優勢,不會介紹複雜的 Kubernetes 架構、實現。因此此文章適合沒有任何 Kubernetes/容器/Docker 經驗的同學,對 Kubernetes 有瞭解的同學也可以從此文章裡面獲取一些靈感,可以更加酷炫的玩轉 Kubernetes。

希望在閱讀完此文章之後,你可以從 “我需要一個 Linux VM 做開發、測試和部署”,變成 “我需要一個 Kubernetes 做開發、測試和部署”。

Kubernetes 是下一代操作系統

Kubernetes 是這幾年非常熱門的一個詞彙,大概所有的軟體工程師都已經聽說過這個詞。

那麼 Kubernetes 到底是什麼呢?可能 Google 會告訴你很多,但是我想告訴你的是:Kubernetes 是下一代操作系統;一個 Kubernetes 集群是一個資源無限大(可擴容)的虛擬機。而且,Kubernetes 的接口是是宣告式的,是天然面向分佈式系統而設計的(下麵會詳細介紹)。

說到這裡,大家估計立刻就有疑問了。我想大概是這些:


Q: 那麼,Linux、Windows 要被淘汰了?

A: 不會被淘汰,只是 Linux、Windows 是一個底層的單機操作系統。而我們這些普通的應用軟體工程師將來都不會跟Linux 打交道了,都會使用 Kubernetes 這個更上層、同時功能也更強大的操作系統。


Q: 那麼,我不學 Kubernetes 可以嗎?

A: 不行!在未來不久的某一天,也許雲廠商只賣 Kubernetes “虛擬機”了:阿裡雲不單獨賣 ecs 了,亞馬遜AWS,微軟雲,Google 雲等各種雲廠商都不賣 Linux 虛擬機了。如果你想買單機版的 Linux 虛擬機,他們都會一臉驚訝的問你,你買那麼底層的、功能那麼薄弱的計算機乾什麼?就像你現在從雲廠商那裡買不到一個還沒有安裝 Linux 的虛擬機一樣。以後,雲廠商交付的 “虛擬機” 必定是 “集群級別的虛擬機” ,而 “集群級別的虛擬機” 的操作系統就是 Kubernetes。

在不久的將來,你不懂如何操作 Kubernetes 接口,就等於現在的你不懂最普通的 Linux 命令。


Q: 那這樣的話,我買不到 Linux 虛擬機,我連學習 Linux 的機會都沒有了?

A: 當然不是,有了 Kubernetes,你可以在 1秒內自己搞一個任何 Linux 發行版本的 “單機虛擬機” 出來。


Q: Kubernetes 真的是一個操作系統? Show me….

A:

“一頓操作猛如虎” 聽起來很酷,但是你在做一些沒必要的事情,同時你做了這些事情並不討好你的老闆,可能在因為你的失誤操作引起更大的故障和問題。

面向 Kubernetes 做最簡單的操作,達到最佳的效果,才是更酷的事情。


A: 行了行了,別說那麼多了,我還是需要一個 Linux VM。

Q: 好的,我給您一個 Kubernetes,然後給你一個 基礎 OS Pod “選單”檔案,然後您自己就可以創建任何一個 Linux 發行版、任何一個 Linux 版本的的 Linux VM了。在文章的最後會有介紹。

小試牛刀

既然是“小試”,那麼我們來嘗試一個最簡單的應用,一個 HTTP 服務: nignx。同時,我應該部署一個高可用、多副本(例子中為3副本)天然容災的 nginx。

部署完成的結構圖大概如下所示:

沒有 Kubernetes 之前的部署

在沒有 Kubernetes 之前,我們大概要做這麼些操作才能交付這個 nginx 服務:

  1. 到三個 Linux VM 上面,分別把三個 nginx 行程起好。這裡可能還需要關心 nginx 行程怎麼起、啟動命令是啥、配置怎麼配。

  2. 到負載均衡管理頁面,申請一個負載均衡,把 3個 nignx 行程的 IP 填入。拿回負載均衡的 IP。

  3. 到 DNS 管理頁面申請一個 DNS 記錄,寫入把拿到的負載均衡的 IP 寫入 A 記錄。

  4. 把這個 DNS 記錄作為這個 nginx 服務的交付成果,交付給用戶。

有了 Kubernetes 的部署

有了 Kubernetes 之後, 我們只需要寫一個 nginx 如何部署的 “選單”,然後提交這個“選單”給 Kubernetes,我們就完成了部署。 “選單” 是一個 yaml 檔案(例子中檔案名 nginx.yaml),大概這個樣子:

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.  name: nginx
  5. spec:
  6.  replicas: 3
  7.  selector:
  8.    matchLabels:
  9.      app-name: my-nginx
  10.  template:
  11.    metadata:
  12.      labels:
  13.        app-name: my-nginx
  14.    spec:
  15.      containers:
  16.        - name: nginx
  17.          image: nginx
  18. ---
  19. apiVersion: v1
  20. kind: Service
  21. metadata:

  22.  name: nginx

  23. spec:

  24.  selector:

  25.    app-name: my-nginx

  26.  type: ClusterIP

  27.  ports:

  28.    - name: http

  29.      port: 80

  30.      protocol: TCP

  31.      targetPort: 80

提交“選單”到 Kubernetes 集群:

    $ kubectl apply -f ./nginx.yaml

訪問剛部署的 HTTP 服務:

發生了什麼?這裡大概簡單的介紹一下我們的“選單”:

  1. 我們向 Kubernetes 提交了一個叫 nginx 的 Deployment。Deployment 是 Kubernetes 里的一種副本保持 “資源宣告”,我們在我們的 Deployment 宣告了 需要3個副本(replica: 3),副本的內容(template: … )是用 nginx 鏡像啟動的 Pod (Pod 即 Linux 里的行程,如上章節介紹的)。如果沒有玩過 docker 的同學,可以把 nginx 鏡像 認為是 nginx 二進制包,只不過它是 docker 鏡像方式存在的,不在這裡詳細展開。我們的 nginx Pod 打上了 my-app=nginx 這樣的 Label, Label 可以理解成 分類“標簽”,別人(Service)來定位我們 Pod 需要用這樣的 “標簽” 來匹配。

  2. 我們還向 Kubernetes 提交了一個 Service。 提交一個 Service 就是向 Kubernetes 申請一個 負載均衡。Service 依靠 Label (selector: …) 去找到它的後端真實行程(Pod)。

  3. Service 會根據規則自動生成域名。規則不在這裡詳細展開介紹。

  4. 我們就能用 Service 自動生成的域名作為交付成果,交付給用戶了!

容災

Deployment 能自動副本保持,即我們的 nginx Pod 少了一個,Kubernetes 能自動幫我們補齊。

變更、發佈、升級

  1. 如需要調整副本數目,我們只需要修改 Deployment.Spec.Replica 欄位,再次 kubectl apply-f./nginx.yaml 即可,副本調整完成。

  2. 如果我們需要升級鏡像(nginx 二進製版本),同樣的修改 PodSpec.Containers[*].Image 即可,然後 kubectl apply-f./nginx.yaml

  3. Deployment 支持滾動升級,在升級時可以一個個升級你的 Pod(滾動升級)。當然,我們線上可能有更加複雜的升級策略,螞蟻金服提供的增強版 Kubernetes 提供比 Deployment 更加實用的升級策略,比如“灰度升級”, “分批升級” 等更加符合生產環境發佈策略的升級方案。

關於“選單” 和 宣告式系統

Kubernetes 是宣告式的系統。關於詳細的介紹 “什麼是宣告式系統”,您可以去 Google 或者內網上面也有許多宣告式系統的介紹。

我這邊有個簡單的比喻:假如你需要一桌菜(至於為什麼是“菜”,是因為這個文章是我在做飯的時候構思的)。但是,這個放菜的 “桌子” 不太穩定(或者說有老鼠來偷吃菜品),一直發生一些事故,就像我們的線上部署應用的環境一樣,服務器可能故障。當你需要在這個桌子上面擺上一桌 “菜” 的時候,“菜”可能會壞掉。別擔心,在宣告式系統里,“廚師長”是個盡職的好同志,當你提交了一份“選單”之後,我們的“廚師長”會一直保證你桌子上的菜一直會和你寫的“選單”里的菜一模一樣。如果某道“菜”壞了,“廚師長”就幫你再做一份。

在 Kubernetes 裡面,有各種各樣這樣盡職的廚師長(有負責 Deployment 的廚師長,有負責 Service 的廚師長等等)。只要天沒塌下來,你提交的“選單”里的菜都會一直美美的在桌子上“迎客”。

那麼,我們回過頭來看我說的 “不久的某一天,雲廠商只賣 Kubernetes 虛擬機了,而不單純的賣 Linux VM”。你真的要買幾個 Linux VM 自己去啟動行程(命令式),然後自己去搭建一套宣告式的系統去守護你的落在各個機器上的分佈式應用行程?而不使用更高級、更好用的 Kubernetes 操作系統?

談軟體交付

軟體交付即把我們開發的一套應用程式部署到其它環境。

軟體交付幾個重要關註的點:

  1. 如何快速的部署一套我們的 “全家桶” 應用到客戶環境。為什麼說“全家桶”,是因為我們不可能只交付一個 nginx 服務,我們肯定會交付一套非常複雜的應用或者中間件系統,比如交付一套 “支付寶系統” 到某個商業銀行。

  2. 如何在客戶現場做自動化容災,降低駐場和支持成本,或者根本不駐場。

  3. 如何簡單、可靠地升級後續的版本。

  4. 上述的幾點,不管是 “部署”,“容災”,“升級” 都需要關註客戶現場的運行環境,我們有沒有辦法屏蔽這種運行環境差異。比如:我們帶過去的可運行軟體,在客戶的 OS 上是不是能運行;客戶現場的負載均衡方案都不一樣,如果到了客戶現場查看了他們的負載均衡方案之後再寫一個負責均衡部署方案肯定大大降低了交付效率。

  5. 客戶現場的環境不一樣,必定帶來配置檔案不一樣。讓一個現場交付人員弄懂所有應用的配置引數,是不是一件讓他很頭疼的事情?

軟體交付方案的歷史:

  1. 交付 原始碼: 這應該是最早的時代,客戶現場的環境(操作系統、機型)都不同,需要帶著代碼到客戶現場編譯,然後運行軟體。

  2. 交付 可運行檔案:像 Java 提出的 “Build once, run everywhere” 概念,在這個時代,我們可以面向一個運行時虛擬機交付軟體。或者我們都面向 Linux 交付,我們的使用 Go 編譯的二進制,能順利的部署到大多數的 Linux OS 上。但是這種方案也強依賴客戶現場需要裝上指定版本的 Java 虛擬機,或者 Linux 特定的版本(應用依賴 Linux 內核特性)。

  3. 交付 鏡像:交付鏡像,最大可能的屏蔽了底層 OS, Java 虛擬機的差異。在鏡像裡面,我們把自己需要的 OS 基礎 和 Java 虛擬機也裝上了。不再依賴客戶現場的 OS 和 Java 虛擬機版本了。

鏡像最大可能的程度上把我們需要的運行時環境和我們的應用可執行檔案打在一起,在各種環境下麵都能完美地運行。那麼,只有鏡像就能快樂的交付軟體了嗎?在我眼裡,鏡像做的事情完全不夠。原因無非也是這麼些:

  1. 怎麼配置啟動引數,要交付人員辛苦的讀懂啟動引數配置說明說嗎?

  2. 怎麼做分佈式應用的組網、服務發現

  3. 怎麼做容災

  4. 怎麼做部署的元資料錄入: 今天我在客戶現場把 A 應用部署到了 節點1 上面,我要把這個信息記在哪兒?

你可能會告訴我,你說的這些我們的 PaaS 系統都能搞定。是的,你說的沒錯!但是當 PaaS 能用統一標準管理應用、屏蔽應用的細節,解決應用的組網和服務發現,監聽每個應用的實體變化(自動化感知故障發生)然後自動恢復(副本保持),那麼它就已經差不多是 Kubernetes 了。把上述的所有功能邏輯都整合在 PaaS,勢必導致 PaaS 的臃腫,我們是不是可以面向 Kubernetes 這個 OS 去做一個輕量級的 PaaS?因為很多功能在 Kubernetes 已經有了,而且肯定比我們自己研發的 PaaS 要好用許多。我們的 PaaS 是不是可以向 Kubernetes 提交 Deployment,而不是自己親自去做行程拉起、副本健康檢查、副本保持等功能。

面向 Kubernetes 交付軟體

正如我上文所說,可能有一天所有客戶現場的 OS 都是 Kubernetes,那我們是不是可以像上文啟動 nginx 服務一樣,用這種 YAML “宣告” 的方式去交付我們的軟體?

當然可以!但是,當我們去交付一個 “全家桶” 服務的時候,我們會發現我們的 YAML 寫了幾千行,甚至上萬行了。這個上萬行的 YAML 誰來維護?就算是分開給各個子應用的 owner 維護,是不是也可能會發生牽一發而動全身。有沒有更加簡單的方式?

當然有。我們再回來談 “選單” 和做菜。我是一個吃貨,但是我很懶。當我點菜的時候,非常希望點一個 “套餐”,而不希望一個個的去點每個菜,更不希望弄懂菜是怎麼做出來的。我想要點一個 “滿漢全席”(複雜的應用),可我不想清楚的弄懂套餐裡面單獨有什麼菜、每個菜的配方是什麼。一個“滿漢全席”(複雜的應用)裡面,可能有“山珍”(資料庫)和“海味”(Web服務)。我只想告訴我們的“大廚”, 我要 “滿漢全席” ,然後我們的 “大廚” 就心領神會的知道 “滿漢全席” 裡面有什麼,然後把 “滿漢全席” 給做出來。那麼這個 “大廚” 要親自做這裡的每道菜嗎?也不必,因為我們的 “大廚” 也可能是個 “懶人”,當需要一桌 “滿漢全席” 的時候,他只會告訴負責 “山珍” 的 “大廚” ,要一桌 “山珍”(資料庫),然後告訴負責 “海味” 的 “大廚”,要一桌 “海味”(Web服務)。當我們的大廚發現 “山珍“ 和 “海味” 都準備好的時候,他會告我 “滿漢全席” 準備好了。

是不是發現和交付軟體很像?為什麼我們不交付一個 “大廚” 出去?到客戶現場負責交付的人員,只要告訴 “大廚” 我們需要一個 “滿漢全席” 這種套餐級別的宣告就行了。並不是說套餐沒有引數,只是套餐的引數能做到對用戶屏蔽不必要的細節:比如我們的 “滿漢全席” 就只要一個引數,只要讓用戶填他的 “滿漢全席” 需要支持 “多少QPS”。

面向 Kubernetes 編程:使用 Operator 交付軟體

上面提到的使用“交付大廚”的方式去交付軟體看起來很美好。那麼,如何實現呢?也就是我們要怎麼培養出屬於我們自己的“廚師”。

其實我們在 “小試牛刀” 的章節已經介紹了一位 “廚師” 了: 負責 “Deployment” 的廚師。只是,他的工作比較通用化、沒有什麼業務含義。它只是負責守護用戶在 “選單” 裡面描述的 “行程”(Pod) 數量,至於怎麼起 “行程” 都是用戶傳入的。

那麼,我們是不是可以根據這個 “廚師” 的模仿出有業務含義的 “廚師”?比如,業界有一位比較出名的一個 “廚師”,是負責 etcd 集群的。如果我需要一個副本數是3的 etcd 集群,只要向 Kubernetes 提交如下的一個 “選單”:

  1.  

    apiVersion: "etcd.database.coreos.com/v1beta2"

  2. kind: "EtcdCluster"

  3. metadata:

  4.  name: "example-etcd-cluster"

  5. spec:

  6.  size: 3

“etcd廚師長” 就會根據這個 “選單” 做出一個副本數是3(Spec.Size=3)的 etcd 集群給你。用戶不需要知道 3 副本的 etcd 集群里每個副本引數是什麼樣的。

“etcd廚師長” 真實的名字叫 etcd-operator。顧名思義,operator 就是“廚師長”,“xxx-operator”就是 “xxx應用-廚師長”。在不久的將來,我覺得我們也會有 “xx-db-operator”,“xx-web-operator”,我們也用這種簡潔明瞭的宣告方式,快速得到一個 db 實體, 或者一個 “xx-web” 應用。

回到怎麼培養廚師長的話題,首先我們來介紹一下名詞:

  1. CRD (CustomResourceDefinitions):定義“滿漢全席”這樣的全家桶。Deployment 是 Kubernetes 官方的資源定義,Kubernetes 同時向開發者提供了 “自定義資源定義”。開發者可以向 Kubernetes 集群提交有 “滿漢全席” 的定義,那麼當用戶提交一桌 “滿漢全席” 時,Kubernetes 就明白用戶的請求了,也就是說 Kubernetes 知道用戶所說的 “滿漢全席” 是什麼了。

  2. CR (Custom Resources):一個 CRD 實體,即一桌 “滿漢全席”,也就是類似上文一樣的 YAML 宣告。

  3. Custom Controller: 我們的“廚師長”。當 Controller 發現用戶提交了 一桌 “滿漢全席”,那麼他就開始做菜了。當然它並不是完全親自做每道菜,正如我上文所說。我們的 “廚師長” 可以依賴另一位 “廚師長”,比如 “db 廚師長” 可以依賴 “Deployment 廚師長”,當用戶需要一個 db 實體的時候,“db 廚師長” 只需要負責再向 Kubernetes 提交一個 Deployment 宣告即可。註意:“廚師長” 之間的交互也是靠 “CR” 或者 Kubernetes 官方定義的資源(如 Deployment、Pod)。“廚師長” 一般也是通過 Deployment 的方式部署在 Kubernetes 集群內(保證了 “廚師長” 自身的穩定性),除非像 “Deployment 廚師長” 這種 Kubernetes 核心 “廚師長”的穩定性 由 Kubernetes 服務提供商保證。

  4. Operator: Kubernetes 里的 Operator,即 CRD + Custom Controller。

一個簡單的圖將他們串起來:

上圖展示了我們的 My-App-Operator 的 “廚師長” 的關係圖。當我們需要一個 “my-app” 應用實體時,我們只要告訴我們的 “廚師長” 是需要多少副本數的實體。我們的 “廚師長” 自動將需求轉化成 Deployment,其它的功能就完全依靠了 “Deployment 廚師長”。

如何面向 Kubernetes 寫一個 Operator

首先我們來看一下 “廚師長” (Operator) 需要關註一些什麼事情,以及它做了什麼事情:

  1. 多久要開始做菜(Observe):即 “廚師長” (Operator/Controller) 需要知道多久他要開始工作了。當用戶提交了 “選單”(CR),“廚師長” 要開始做菜。或者,因為 “桌子” 上少了一個預期中的 “菜”(Pod 因為故障少了一個),“廚師長” 也要開始做菜了。

  2. 做什麼菜(Analyze): “廚師長” 首先要看看桌子上的菜,再對比一下用戶的 “選單”,得出還缺少什麼菜,那麼就做什麼菜。

  3. 開始做菜(Action):得出做什麼菜之後,那麼後面的事情就簡單了。通知其他 “廚師長” 做菜(提交一個其他的CR),或者自己親手做個菜(提交一個 Pod)。

這3件事情,其實就是 Controller 樣式的核心三件事:

那麼用 Kubernetes 寫一個 Operator 需要多久?

可能從 “0” 到可以把 Operator 運行起來只需要 10分鐘吧。因為 Kubernetes 的 Kube-Apiserver 提供天然的 watch 接口,我們可以去關註我們在意的資源(我們的 CR,我們的 Pod 等),這樣我們的 “廚師” 就能很自然的得到通知該幹活了。然後 “廚師” 就開始做出分析,到最後再向 Kube-Apiserver 提交我們想要的資源(Deployment,或者其它的 CR)。我們都面向 Kube-Apiserver 做編程, 所有的“廚師”都 向 Kube-Apiserver 提交、修改、Watch資源作為統一的交互協議,一切都會變得簡單許多。

最後,再加上 Operator 的腳手架幫我們生成基礎代碼(初始化 Kubernetes 客戶端,建立 Watch 等),我們開發者只需要關心的怎麼 Analyze 和 Action 即可。 Operator 的腳手架社區常見的有 kube-builder 和 coreos 提供的 operator-framework 等。

我們用偽代碼來寫一下上文畫的 My-App-Operator 核心邏輯 (其它都腳手架做好了,甚至如何 build,Operator 本身它自己如何部署的“選單” YAML 都是腳手架生成好了):

    // Reconcile 即我們 Operator 核心代碼邏輯

    // Reconcile 何時觸發,也是 Operator 生成好了

    func Reconcile(crName string) error {

        // 獲取 CR (用戶提交的“選單”)

        cr := client.getCR(crName)

        // 計算出這個 CR 期望的 Deployment (用戶提交的“選單”應該在桌子上有什麼菜)

        desireDeployment := getDesireDeployment(client, cr)

        // 目前集群裡面實際的 Deployment (實際上桌子上有什麼菜)

        deployment := client.GetDeployment(crName)

  1.     // 如果期望和實際的不太一樣,把實際的更新一下就行了。

  2.     if diff(desireDeployment, deployment) {

  3.         return client.UpdateDeployment(desireDeployment);

  4.     }

       // 如果期望和實際都一樣,什麼事情都不做了。

       return nil

  1. }

     

面向 Kubernetes 變成 和 Operator 的優勢總結

  1. 統一的信息獲取源和統一的接口: Kube-Apiserver 就像是一個大的信息流轉中心。所有的組件(“廚師長”)都通過這個中心上傳他負責的資源(CR,Deployment,Pod都是 Kubernetes 的資源)的信息,同時,他也通過這個接口,去感知其它資源狀態的變化,如果這些變化是他感興趣的,那麼他就開始工作(“廚師長” 開始工作)。

  2. 構建在 Kubernetes 核心組件以及 社區通用的 Operator 之上:站在巨人的肩膀上能讓我們的工作更加的減負同時達到更加理想的效果。上文中,我們的 Operator 可能在依賴 Deployment 之後,他負責的 “菜”(Pod)就自帶副本保持功能。同時,假如我們的應用(DB,Web)要依賴社區的 MySQL 資料庫,那麼我們的應用 Operator(Web + DB) 可以通過社區的 MySQL-Operator 提供的 CR 快速建出 MySQL 實體,然後再使用 Deployment 建出 Web。

優秀的社區 Operator

優秀的社區 Operator (awesome-operators): https://github.com/operator-framework/awesome-operators

FaaS

用 Operator 交付軟體,目前看起來是最酷的一種交付軟體方式。

但是在當今雲原生技術快速發展的時代,可能在不久的將來,Operator 樣式可能也會被淘汰。因為 Operator 也需要開發者關註一些部署的細節,讓開發者真正只關註在自己的業務邏輯,“業務代碼” 變成 “服務” 完全對開發者透明,可能需要比 Kubernetes 更上層的框架 – FaaS框架。

FaaS 全稱是 Function as a service 。用戶只要寫自己的業務函式,向 Kubernetes 提交業務函式,FaaS 框架將業務函式變成 Deployment,變成 Pod,變成 Service。但是 FaaS 目前還在發展階段,並不像 Kubernetes 已經變成事實標準,這裡不再詳細討論。

落地

說了那麼多,其實我的初衷是希望每個開發者都從 Linux VM 轉向 Kubernetes “VM”。但是轉變發生在每個人身上,應該是有各種困難。我能想到的一些最基本的困難大概列在下麵,同時歡迎跟我交流你的一些困惑。

代碼變成鏡像

大家都知道,Kubernetes 只允許以 Pod 的方式運行“行程”。在 FaaS 沒成熟之前,如何把我們的代碼變成一個鏡像是一個比較頭疼的事情。可能應用的開發同學並不想自己去理解 docker,怎麼去打鏡像。

別擔心!Spring 框架或者其擴展的腳手架應該已經可以在工程里自動添加 Dockerfile 檔案,使用腳手架之後,用戶只要執行 make image 這樣的命令,就能構建出鏡像了。

別說了,我還是想要一個 Linux VM

向 Kubernetes 提交下麵這樣的一個 YAML 檔案,你就能得到一個 ubuntu VM:

    apiVersion: v1

    kind: Pod

  1. metadata:

  2.   name: my-vm-1

  3. spec:

  4.   containers:

  5.   - name: vm

  6.     image: ubuntu

同時,告訴你一個更酷炫的玩法:自己定製一個屬於你自己的 Linux 發行版!在原有的 OS 鏡像基礎上,加上你的 Shell 工具腳本、寫一串向愛人表白的話、搞個開機 Logo,都很簡單!做一個屬於你自己的 Linux 鏡像,那麼在世界的任何地方,你都能起動一個經過你定製的 Linux VM。

哪裡去獲取一個 Kubernetes

首先,試試 mini-kube,或者立刻向 阿裡雲買一個!

 

   SOFA 活動推薦  

有趣實用的分佈式架構頻道,將作為 SOFA 所有在線內容的承載,包含直播/音視頻教程,集中體現 SOFAStack 的能力全景圖。

SOFAChannel 第二詳細介紹 SOFARPC 框架的開源部分性能優化點,直播回顧見上文推薦閱讀。

SOFAChannel 第三期會帶來關於 SOFARPC 框架 的執行緒池隔離、Server Fail Fast、記憶體操作優化、用戶可調節引數等方面的介紹。

2月28日一起來聊聊《SOFARPC 性能優化(下)—— 手把手帶你性能調優》,老時間見~
點擊閱讀原文或鏈接直接報名

https://tech.antfin.com/activities/245?chInfo=wx 

附:SOFARPC 剖析系列文章回顧

 

長按關註,獲取分佈式架構乾貨

歡迎大家共同打造 SOFAStack https://github.com/alipay

    赞(0)

    分享創造快樂