雲原生軟體開發相關概念與技術
由於我在交大選修由台積電開設的「雲原生架構與現代軟體發展趨勢介紹」，所以我對雲原生的概念十分有興趣，這篇會著墨在雲原生進行複習。
由於有版權問題，不會有相關檔案(eg. 投影片、上課內容)，請勿轉載!
介紹
什麼是 CI/CD
身為一個 DevOps 開發員，會 CI/CD 觀念很基本，不但降低錯誤發生，也可以提升服務品質。
CI/CD 簡單來說就是程式 push 到 GitHub 或 GitLab 後，會進行流程自動化: 自動 build code、執行 unit test、自動部署、自動更新線上服務等。
開發者執行 git push 到 GitHub 後，將程式更新到 server 的步驟由 Jenkins 負責(相關應用可以到我的另一篇文章參考: 連結)。
持續整合(Continuous Integration)
…
持續部署(Continuous Deployment)
…
什麼是 K8s
- VM
- Container
- Docker
- K8s 如何運作
- 微服務
簡單介紹 k8s
Kubernetes 因為中間有 8 個字母因此又稱 k8s，是一個幫助我們管理微服務(microservices)的系統，可以自動化部署及管理多台機器上的多個容器(container)。
想解決的問題: 手動部署多個容器到多台機器上並監測管理這些容器的狀態很麻煩
解決方法: 提供一個平台以較高層次的抽象化去自動化操作與管理多個容器
看 Kubernetes 官網說明，描述:
Automated container deployment, scaling, and management
簡單來說，k8s 可以做到:
- 同時部署多個容器到多台機器上(Deployment)
- 服務的乘載量有變化時，可以對容器做自動擴展(Scaling) –> 符合 TSMC 的 scale out 部署策略
- 管理多個容器的狀態，自動偵測並重啟故障的容器(Management)
看到這裡，想必有些讀者已經矇了，我在學關於 k8s 的觀念時其實也一知半解，特別是容器虛擬化、Docker 這些概念，在學 k8s 之前必須先了解 container 是什麼、Docker 是什麼、所以 k8s 要做什麼，甚至到後面到微服務觀念，都會在本篇一一介紹(如果已經很精熟的人可以直接跳過)。
什麼是虛擬化
想解決的問題: 我寫好了一支程式，在我的電腦上跑得很順，在你的電腦上就跑不動還要一直 debug，非常麻煩。
解決方法: 兩種虛擬化技術，在系統層級虛擬化，為 VM; 在作業系統層級，為 container。(例如: Virtual Box (VM)/ Docker (container))
簡單介紹: 每台電腦的作業系統和硬體配置都不太一樣，我的程式只在某台電腦上的環境相容，而虛擬化就是要模擬出這個環境，讓程式可以在不同電腦上執行。
虛擬機器 vs. 容器(container)
虛擬機器和容器雖然都是虛擬化技術，但兩者卻天差地別，接下來會簡單介紹兩者差別。
虛擬機器(VM)
- 虛擬化目標: 將一個應用程式所需的環境打包，並建立一個獨立環境，方便在不同的硬體中移動。
VM 是在系統層上虛擬化，透過 Hypervisor(eg. VirtualBox) 在目標機器提供一個或多個虛擬機器的平台。而這些 VM 可以執行完整的作業系統(Guest OS)。
容器(Container)
- 容器化目標: 改善 VM 因為要安裝 Guest OS 導致啟動慢、佔大量記憶體的問題。
Container 是在作業系統層上虛擬化，透過 Container engine(eg. Docker) 將一個應用程式所需的程式碼、函式庫、組態檔打包，建立資源控管機制隔離各容器，並分配 Host OS 上的系統資源。不用另外安裝 Guest OS。
–> 所需硬碟容量大幅降低、啟動更快，因為不用安裝 Guest OS。
什麼是 Docker
Docker 是容器打包的技術，包含了下列三元素
- 映像檔(Image)
- 容器(Container)
- 倉儲(Repository)
舉例來說: 利用蛋糕的模具(Image)，用這個模具烤蛋糕(Container)，並把模具在收納櫃(Repository)放好。
這邊只是給一個簡單的例子，就好比在物件導向中的概念，利用模組來建立模型，下面會有更多詳細介紹這三個概念。
映像檔(Image)
…
容器(Container)
…
倉儲(Repository)
k8s 四元件
講完 VM、Container、Docker 後，回來介紹 k8s 是如何運作的。首先了解四元件。
1 | Cluster -> Master Node -> Worker Node -> Pod |
Pod
是 k8s 運作的最小單位，一個 pod 對應到一個應用程式，例如: 一個 pod 對應到 一個 API server。
- 每個 pod 都有一個 ID，也就是專屬於這個 pod 的
yaml檔 - 一個 pod 裡可以有多個 container，但一般只會有一個
- 因為同一個 pod 中的 container 共享相同資源及網路，透過 local port number 溝通。
Worker Node
是 k8s 運作的最小硬體單位，一個 worker node (簡稱 node) 對應到一台機器，可以是實體機、AWS EC2 開的虛擬機或是 GCP 上的 Computer Engine。
Node 三元件:
1 | kubelet、kube-proxy、Container Runtime |
k8s 很強大，所有 Node 都抽象了，不用了解這些元件的詳細內容也可以很順利的操作! (所以這邊各元件先簡單介紹，後續有空的話會更詳細的補充)
Master Node
是 k8s 運作的指揮中心，他也是 Node，但他負責管理其他所有 Node，稱為 Master。
Master 四元件:
1 | kube-apiserver、etcd、kube-scheduler、kube-controller-manager |
Cluster
k8s 中 Master 與多個 Node 的集合，基本上就是在同一個環境裡所有 Node 集合在一起的單位。
微服務
微服務架構是一種雲原生架構方法，其中單一應用程式由許多鬆散連結且可獨立部署的小型服務所組成。
- 擁有自己的技術堆疊，其中包含資料庫和資料管理模型。
- 透過
REST API、事件串流與訊息分配管理系統的組合彼此相互通訊。 - 依商業功能組織，其中區隔服務的界線通常稱為有界限的環境定義。
優勢
- 程式碼可以輕鬆更新。
- 可以不用碰觸整個應用程式新增功能。
- 團隊可以針對不同的元件使用不同的堆疊或是不同的程式語言。
- 元件可以個別獨立擴充，減少因為單一特性可能面臨過多負載而必須擴充整個應用程式所造成的浪費和成本。
k8s 就是用來實作微服務架構的容器編排(container orchestration)，並且利用 Ingress 來進行通訊(可以想成就是利用 API 來串接)。
舉例來說，k8s 中的一個 pod 就是一個服務，一個 k8s 的 cluster 就是一支應用程式，實現了微服務架構。
什麼是自動化
為何需要 IaC?
Dynamic infrastructure 遇到的挑戰
Principles of IaC
Practice of IaC
為何讓資料中心自動化的過程會加速
- The leading companies in digitizing operations are growing 5x faster than the laggards.
- 維護和營運的成本會降低。
簡單介紹 IaC
- 透過機器可讀(machine-readable)的定義檔而不是實際上的硬體配置或交互式配置工具來管理和配置電腦資料中心的過程。
什麼是 Infrastructure as Code(IaC)
目標
- IT infrastructure 支持和促成變革，而不是成為障礙或約束。
- Changes are routune
- 系統更改是例行公事(routine)，不會給使用者或 IT 人員帶來戲劇性或壓力。
- Spend time on valuable things
- IT 人員將時間花在可以發揮他們能力在有價值的事情上，而不是日常的重複性任務上。
- Enable users
- 使用者能夠定義、配置和管理他們需要的資源，而不需要 IT 人員為他們做這些。
- Quick recover from failure
- 團隊能夠輕鬆快速地從失敗中恢復，而不是假設失敗可以完全預防。
Dynamic Infrastructure 的挑戰
Server Sprawl
- 團隊努力使伺服器維持補丁和最新，使系統容易受到已知漏洞的攻擊。
- 發現問題後，可能不會將修復程序推廣到可能受其影響的所有系統。
- 跨伺服器的版本和配置差異代表在某些機器上工作的軟體和腳本在其他機器上不能運作。
Configuration Drift
- Configuration Drift 是指同一件事的實例隨著時間的推移而變得不同。
Snowflake Servers
- 不同於網絡上的任何其他服務器。因為他不能複製。
Jenga Infrastructure
- Jenga 基礎設施很容易被破壞，也不容易修復。這是擴展到整個系統組合的 snowflake server 問題。
Automation Fear Spiral
- 許多團隊使用 Puppet 或 Chef 等自動化工具，但很少有人在無人值守(unattended)的情況下運行這些工具。
- 每次調整配置來適應特定的任務。
- 由於服務器不一致，對自動化缺乏信心。
- 服務器不一致，因為沒有頻繁且一致地執行自動化。
- 良好的監控和有效的自動化測試有助於建立信心，相信配置可以可靠地應用並迅速發現問題。
Erosion
結論
…