此文章适合沒有任何 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 服務：
到三個 Linux VM 上面，分别把三個 nginx 程序起好。這裡可能還需要關心 nginx 程序怎麼起、啟動指令是啥、配置怎麼配。
到負載均衡管理頁面，申請一個負載均衡，把 3個 nignx 程序的 IP 填入。拿回負載均衡的 IP。
到 DNS 管理頁面申請一個 DNS 記錄，寫入把拿到的負載均衡的 IP 寫入 A 記錄。
把這個 DNS 記錄作為這個 nginx 服務的傳遞成果，傳遞給使用者。
有了 Kubernetes 的部署
有了 Kubernetes 之後， 我們隻需要寫一個 nginx 如何部署的 “菜單”，然後送出這個“菜單”給 Kubernetes，我們就完成了部署。 “菜單” 是一個 yaml 檔案(例子中檔案名 nginx.yaml)，大概這個樣子:
apiVersion: apps/v1
kind:
Deployment
metadata:
name: nginx
spec:
replicas:
3
selector:
matchLabels:
app-name:
my
-nginx
template
:
metadata:
labels:
app-name:
my
-nginx
spec:
containers:
- name: nginx
image: nginx
---
apiVersion: v1
kind:
Service
metadata:
name: nginx
spec:
selector:
app-name:
my
-nginx
type:
ClusterIP
ports:
- name: http
port:
80
protocol: TCP
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 送出如下的一個 “菜單”：
apiVersion:
"etcd.database.coreos.com/v1beta2"
kind:
"EtcdCluster"
metadata:
name:
"example-etcd-cluster"
spec:
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” 應用。
回到怎麼培養廚師長的話題，首先我們來介紹一下名詞:
CRD (CustomResourceDefinitions)：定義“滿漢全席”這樣的全家桶。Deployment 是 Kubernetes 官方的資源定義，Kubernetes 同時向開發者提供了 “自定義資源定義”。開發者可以向 Kubernetes 叢集送出有 “滿漢全席” 的定義，那麼當使用者送出一桌 “滿漢全席” 時，Kubernetes 就明白使用者的請求了，也就是說 Kubernetes 知道使用者所說的 “滿漢全席” 是什麼了。
CR (Custom Resources)：一個 CRD 執行個體，即一桌 “滿漢全席”，也就是類似上文一樣的 YAML 聲明。
Custom Controller： 我們的“廚師長”。當 Controller 發現使用者送出了 一桌 “滿漢全席”，那麼他就開始做菜了。當然它并不是完全親自做每道菜，正如我上文所說。我們的 “廚師長” 可以依賴另一位 “廚師長”，比如 “db 廚師長” 可以依賴 “Deployment 廚師長”，當使用者需要一個 db 執行個體的時候，“db 廚師長” 隻需要負責再向 Kubernetes 送出一個 Deployment 聲明即可。注意：“廚師長” 之間的互動也是靠 “CR” 或者 Kubernetes 官方定義的資源（如 Deployment、Pod）。“廚師長” 一般也是通過 Deployment 的方式部署在 Kubernetes 叢集内（保證了 “廚師長” 自身的穩定性），除非像 “Deployment 廚師長” 這種 Kubernetes 核心 “廚師長”的穩定性 由 Kubernetes 服務提供商保證。
Operator: Kubernetes 裡的 Operator，即 CRD + Custom Controller。
一個簡單的圖将他們串起來：
上圖展示了我們的 My-App-Operator 的 “廚師長” 的關系圖。當我們需要一個 "my-app" 應用執行個體時，我們隻要告訴我們的 “廚師長” 是需要多少副本數的執行個體。我們的 “廚師長” 自動将需求轉化成 Deployment，其它的功能就完全依靠了 “Deployment 廚師長”。
如何面向 Kubernetes 寫一個 Operator
首先我們來看一下 “廚師長” (Operator) 需要關注一些什麼事情，以及它做了什麼事情：
多久要開始做菜（Observe）：即 “廚師長” (Operator/Controller) 需要知道多久他要開始工作了。當使用者送出了 “菜單”(CR)，“廚師長” 要開始做菜。或者，因為 “桌子” 上少了一個預期中的 “菜”(Pod 因為故障少了一個)，“廚師長” 也要開始做菜了。
做什麼菜（Analyze）： “廚師長” 首先要看看桌子上的菜，再對比一下使用者的 “菜單”，得出還缺少什麼菜，那麼就做什麼菜。
開始做菜（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)
// 如果期望和實際的不太一樣，把實際的更新一下就行了。
if
diff(desireDeployment, deployment) {
return
client.
UpdateDeployment
(desireDeployment);
}
// 如果期望和實際都一樣，什麼事情都不做了。
return
nil
} 面向 Kubernetes 變成 和 Operator 的優勢總結
統一的資訊擷取源和統一的接口： Kube-Apiserver 就像是一個大的資訊流轉中心。所有的元件（“廚師長”）都通過這個中心上傳他負責的資源（CR，Deployment，Pod都是 Kubernetes 的資源）的資訊，同時，他也通過這個接口，去感覺其它資源狀态的變化，如果這些變化是他感興趣的，那麼他就開始工作（“廚師長” 開始工作）。
建構在 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-operatorsFaaS
用 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
metadata:
name:
my-vm-1
spec:
containers:
-
name: vm
image: ubuntu
同時，告訴你一個更酷炫的玩法：自己定制一個屬于你自己的 Linux 發行版！在原有的 OS 鏡像基礎上，加上你的 Shell 工具腳本、寫一串向夫妻表白的話、搞個開機 Logo，都很簡單！做一個屬于你自己的 Linux 鏡像，那麼在世界的任何地方，你都能起動一個經過你定制的 Linux VM。