為甚麼 「需要」 Kubernetes?

一個走完開發流程之後所產出的軟體應用程式(或稱系統)，都會有他自己的架構。
而我們在 Development 環境下的架構跟 Production 環境下的架構肯定是不會一樣的，畢竟裡面牽扯了很多安全性、可靠性、穩定性...之類的 Issue。

在真正的 Production 環境下，可能會涉及多個服務。 Maybe 你的系統會牽扯到資料庫服務、後臺管理服務、程式碼版本控制服務、雲端儲存服務等各式各樣的其他系統，那麼就有極大的可能你會在部屬的時候需要去做「跨伺服器、跨主機」的部屬。

這時候 Kubernetes 就會派上用場了，不論是在安全性、附載均衡、服務的 recovery、服務的 orchestration、日後的水平或垂直擴展，它都可以提供一個穩定、便捷的解決方案。

為甚麼「採用」 Kubernetes?

Source: https://www.redhat.com/en/topics/containers/what-is-kubernetes

一切都要從這張圖片開始說起，我將會由下往上說明。

容器化的服務 --- 微服務

如果有空的話可以先參考一下以下文章：
DevOps、微服務、容器化
何謂微服務？

有別於傳統的應用程式系統架構，這樣子微服務的架構會將一個應用到的服務部屬在一台虛擬主機上，會呈現一個一對多的樣態。而這樣子分散式部屬的系統會把整體應用程式切分成多個獨立的流程，為將來的擴充性跟服務的恢復提供一個解套。

小結論：微服務加上容器化技術，大大地將軟體系統的擴展性與服務開發的速度提升，也可以讓整個軟體系統更加的穩定。

容器服務的編排

Orchestration 編排一詞，主要敘述的是將微服務放進容器之後去編排它的執行，在 Kubernetes 中它的編排可以在該服務的 configuration yaml file 裡面去做詳細的設定，不僅僅是它的儲存位置、網路設定、以及安全性、自動化都會被有效的處理。
這不僅是對於 Production 環境有幫助，對於在 Git Repository 跟 Development 環境都會有大大的幫助。

根據 RedHat 組織所描述的 Container Orchestration 用途有：

• 服務供應、部屬
• 組態設定與排程
• 資源分配
• 可用性
• 水平擴展或減少
• 附載均衡
• 容器狀態監控
• 自動編排需要啟用的服務
• 維護容器間溝通的安全性

Migration 遷移

當你的應用程式系統已經採用了微服務的架構去部屬、開發了之後，將會獲得前所未有的可用性、可遷移性。
這代表說未來你在不論私有網路裏的伺服器、雲端服務的伺服器、又或者是自己架設的伺服器從集中都可以自由的遷移，也可以實現多方的服務備份、在伺服器不預期的 outage 或 downtime 時候快速的重新佈署、甚至是高速的 rollback 以及 self-recovery。

結論

經過這樣子的介紹，可以了解到在系統充分的容器化、微服務化之後，就可以更完善的利用 Kubernetes 的特性了，如果想要了解微服務的夥伴不妨可以先參考看看 RESTful API ，再重新審視過 datatable 的設計與 data 的可用性，最後去看看 Monolithic 架構與 Microservices 架構的不同，雖然這些都是開發取向的知識，但卻是更好的部屬進 Kubernetes 的基礎喔!