團隊是否已經透過容器部署應用程式，如果沒有，那想要直接導入 Kubernetes 會是一個非常痛苦的過程，畢竟 Kubernetes 跟單純 Docker Container 的使用方式有非常大的差異，部署及管理的方式也困難很多
團隊目前是採用公有雲的環境來部署還是自行維護機房? 三大公有雲基本上都有提供非常多的功能來提供使用者去部署應用程式，有些團隊單純依賴這些服務而不使用 Kubernetes，結果來看整體的運作流程也非常順暢
團隊人員是否有足夠的技術與知識來使用 Kubernetes？如果沒有則導入 Kubernetes 也會是一個很大的過渡期，訓練既有人員或是招聘新員工對公司來說都會有成本增加的考量。
既有工作流程再導入 Kubernetes 之後是否會變輕鬆? 這部分可以再細分多個小節
a. 團隊的服務是否已經有針對不同流量的水平擴展計畫?
b. 網路流量要如何有效地處理，是否有 Load-Balancer 之類的可以自動地將流量導向後方服務?
c. 開發跟維運人員要如何更新版本測試

所以作為團隊的領導者，切記不要跟風，千萬不要因為 kubernetes 是潮流就貿然採用 Kubernetes，我認為一個可以參考的做法是

讓團隊中一個熟悉既有運作模式跟架構的員工去學習 Kubernetes
找出團隊目前維運上的痛點
比較 Kubernetes 如何解決維運上的痛點，這些痛點帶來的改善是否直得期待
如果評估後認為轉換有價值，從小服務開始導入來測試，不要一口氣直接轉換
也要注意混合過程中，部分服務是k8s，部分服務是原先架構的情況下會不會有什麼問題出現

假設今天決定想要導入 Kubernetes，則接下來談談如何管理與架設團隊的 Kubernetes 叢集

如何管理 Kubernetes

Kubernetes 本身是個開源專案，既然是個開源專案就意味使用者是有機會直接使用其開源版本的內容來架設屬於自己的 Kubernetes 叢集。
但是 Kubernetes 本身架構不算簡單，部署雖然容易但是長期的維護與除錯這部分需要仰賴對於 Kubernetes 的理解與經驗，特別是要與眾多服務進行整合時，整個難度又更高。
因此自然而然也會衍生出系統整合商的生意模式，提供一個更好使用且有技術支援的 Kubernetes 平台。
除此之外，公有雲本身也都有基於 Kubernetes 提供託管 Kubernetes 叢集的服務，譬如 Azure(AKS), GCP(GKE), AWS(EKS) 等，這類型的服務也都是要額外收費的。

我認為 Kubernetes 平台如何部署與架設，可以用下列的方式去分類

如果團隊打算使用地端(on-premises)環境
a. 直接於 bare-metal 的機器上使用開源專案來架設所有環境，譬如 K8s，必要時還可以先架設 VM
b. 找尋相關的系統整合商，請對方提供整體的解決方案，從機器到 k8s 叢集等
如果團隊打算使用雲端環境
a. 直接使用雲端的 Kubernetes 服務
b. 使用雲端的 VM 作為主體，上面使用開源專案幫忙架設 Kubernetes 並管理
c. 找尋相關的系統整合商，請對方提供整體的解決方案，包含使用哪套雲端環境，如何架設 k8s 叢集等

不考慮人力的情況下，基本上1(a),2(b)的價格會是相對低的，畢竟你付錢取得機器，後續的架設與管理都要自行處理，其餘三個選項都會有額外的金錢成本來購買相對應的服務。
除了成本外還需要考慮到所謂的技術支援。技術支援本身也是需要錢的，團隊如果本身沒有辦法培養熟悉 Kubernetes 的人才，也許用錢買服務是相對簡單的方式。
這也是採用開源專案的一個痛點，畢竟純開源專案的情況下，遇到問題都需要仰賴團隊的工程師自行想辦法解決。

談了這麼多種變化，本次系列文沒有辦法針對所有可能都去探討與分析，處而代之的則是從開源的角度出發，去探討如果想要自行管理與維護整個 Kubernetes 叢集的話會有什麼選擇。
接下來將使用開源專案 Rancher 作為管理多套 Kubernetes 叢集的平台，Rancher 能夠針對上述的 1(a), 2(a,b) 等三個類別去處理，提供了一個友善且強大的管理介面，讓團隊可以輕鬆的去架設與管理多套 Kubernetes 叢集。