睽違兩年，終於稍微有空閒時間更新了! 這次非常幸運可以參與到 Google Cloud 線上研討會系列的培訓，我認為此次培訓對於目前工作上有一定程度上的幫助。
線上培訓資訊
Google Cloud 線上研討會系列 - Google Cloud OnBoard：Google Kubernetes Engine 入門
- 直播日期：2024年10月16日 13:00-16:40
- 單元項目：
- 模組1：Kubernetes 基礎介紹
- 模組2：建立與配置 GKE 集群
- 模組3：在 Kubernetes 中部署與擴展應用程式及服務
- 模組4：保護 GKE 並安全訪問 GCP 服務
軟體開發部署技術演進
(圖片來源：實體主機 (Physical Server)
- 自行安裝作業系統、所需軟體。程式完成後，直接在該主機運行服務
- 各服務模組間，可能會因所需版本不同，而有資源依賴相衝問題
虛擬主機 (Virtual Machine)
- 在作業系統與實體機器之間作抽象層，可在同樣實體機器上跑不同作業系統，簡化作業系統的管理
- 不同模組使用不同VM，解決資源相衝問題，但因為會各自啟動作業系統 kernel，而造成資源浪費，開啟速度慢
- 無法確保開發與正式環境相同，可能會發生在本地與正式環境呈現不同的結果
容器化服務 (Container)
- 在作業系統層上，安裝 Container Runtime 抽象層，讓不同的應用程式，在同一個作業系統上運行，模擬不同作業系統或環境
- 較輕量化，將不同 VM 改用容器的方式，可以重複利用到作業系統的資源，啟動速度相較 VM 快速
- 開發一致性，把服務本身與相依套件，包裝成一個部署單位，確保開發與正式環境相同
微服務 (Serverless)
- 無須煩惱容器，僅專注於程式碼即可
微服務架構優缺點
優點 - 開發上職責分明
- 模組開發速度快，專注於程式開發，無須再負擔其他成本
- 模組更版風險小，可獨立更版，不影響其他模組
- 不同服務可獨自優化，可各自選用不同的擴展策略
- 服務可選用不同的程式語言、runtime，選擇自已合適的環境架構
缺點 - 不同模組之間溝通成本提高
- 服務溝通複雜性變高，越多服務就須承擔越多的溝通，管理難度提升
- 如果一個請求會經過好幾個服務，就會造成溝通延遲
- 服務之間會使用網路做溝通，會提升資安的風險與挑戰
- 部署次數提高：例如有5個微服務，就需部署5次
- 確保各服務可維持向前相容：若一個模組版本更新，是否會影響其他模組的溝通
Kubernetes 簡介
一個容器管理的開源框架，為解決微服務帶來的挑戰與問題
(圖片來源：功能
- 支援 狀態(Stateful) 與 非狀態(Stateless) 應用程式
- 管理容器 擴展(Autoscaling) 問題
- 確保跑在容器背後的實體資源足夠
- 確保服務可支援在不同環境中運行
架構
(圖片來源：Control Plane：kubernetes 管理中心
- kube-APIserver：所有 kubernetes 操作都由此發動
- etcd：儲存系統
- 儲存運行在 kuberenetes 中，元件的各種狀態
- kube-scheduler：容器安排系統
- 安排容器要在哪台實體機或VM上面
- 觀察是否有充足的空間來運行該容器
- etcd：儲存系統
- kube-cloud-manager：管理kubernetes與cloud之間基礎設施的連結
- kube-controller-manager：管理 kubernetes 物件，監控與調整物件行為
Data Plane (Node)
- kubelet：與 Control plane 做溝通
- kube-proxy：節點間的網路路由連線管理
單體搬遷到微服務容器：採用漸進式過程
(圖片來源：- Monolith Container：單體程式碼轉換為容器
- 完全沒有拆為服務，整包轉成容器
- Google Cloud 有功能可以實現，但會有不相容的問題
- Monolith Pod：在單體容器中，找尋與其他服務相依性低的，拆出作容器化
- 共享網路與儲存，尚無網路溝通風險
- 逐步將個個服務各自拆成獨立單體容器
- 單體容器再逐步轉為pod
Tags
GKE GCPcomments powered by Disqus