前言
最近公司準備要朝向往 K8S(kubernetes) 的方向架構走，因此也被 assign 去看一些相關架構 K8S 的任務。基本上，K8S 在企業 Solution 底下其實已經非常廣泛，很多的公司也會採用像是 Google 的 GCP (Google Cloud Plarform)，微軟的 Azure 或是 Amazon 的 AWS (Amazon Web Service)。
上面所提到的平台，其實是屬於 Public cloud 的範疇，但像是我們公司的產品是屬於 Private cloud，兩者對於 K8S 上有甚麼不同呢 ?
K8S in Public or Private cloud ?
就我個人而言，其實雲服務的根本精神的確是要架構在公有雲，而 K8S 正是可以實踐所謂的 Microservice 微服務、容器化等等的精神。因為企業的產品規模並不會一成不變，會針對使用者流量或是地區性配置進行產品的雲服務，在管理層面，可擴展性或是高可用性絕對是企業的 first priority! 當然，很多企業的考量也是不去架構自己的硬體設備，而用上述所提到的像是 GCP 等等的代為管理，降低成本以及方便性都是相當重要的原因之一。
那麼，Private cloud 有沒有必要使用 K8S 呢 ? 我在網路找資料並研究了一陣子，其實這近幾年，已經有越來越多企業需求是想要針對邊緣運算或說一個 On-Premise 的環境去架構雲的服務。不管是企業內部自己使用或是 IOT 物聯網的產品，都也是可以藉由 K8S 的容器化的精神，達到容易部屬(Easy to deploy)以及上述所提到的那些特性。
Rancher
因此 (前面扯了那麼多終於講到主角XD)，Rancher Lab 提出了一個叫做 K3S 的專案，CNCF (Cloud Native Computing Foundation) 也已經官方驗證過為 K8S 的一個輕量化的變形。誠如剛剛上述提到，對於邊緣運算的情景，其實 K8S 本身整體來說其實算是比較吃資源，因此 Racnher Lab 提出了 K3S，保留了一些必要的功能像是 etcd 等等。你可能會好奇，K3S 的 3 是甚麼 ? 其實就是把 K8S 的五個功能給移除達到瘦身，當然這五個功能重不重要見仁見智。但是，對於邊緣運算來說的確是一個很好的 solution。
這邊稍微提到一下 K3S 的運作原理。
其實當你在安裝完 Rancher 並去實際佈署一個 K8S 的環境，回過頭來再看看這張圖應該會更有感覺。Server-Agent的架構，Server 你可以是獨立的一台機器只裝Rancher或是也把 K8S 的 master node 所需要的元件安裝在同一台node上。Kubelet 我們都知道是 K8S 中 worker node 跟 master node (api-server)之間溝通的橋樑，在 K3S 裡是再透過 tunnel proxy 進行跟server的對話。簡單來說也就是再包一層的意思。其他元件其實跟原生 K8S 大同小異就不多描述。
簡易安裝
其實 K3S 安裝十分簡單，在官網的首頁也就是用一個大大的標題，貼一行 curl 指令給你，跟你說不會花太久時間的XDD。
1
2
3
4
curl -sfL https://get.k3s.io | sh -
# Check for Ready node, takes maybe 30 seconds
k3s kubectl get node
我這邊將不會是用此種做法，後續文章我將會介紹利用 Rancher 已經在 Docker Hub 上所包裝好的 K3S Image 來進行佈署。
Contact me
有任何疑問或是建議歡迎聯絡 Jimmy!
Gmail: jimmyw86878@gmail.com
-
Previous
Hello, my first blog. -
Next
Rancher with K8S cluster 之旅 (2) - Install Rancher and deploy a K8S cluster via Internet