Slides

• 2018 Google Cloud Platform User Group Taiwan #41
• 2018 Kubernetes 大講堂

前言

為因應環境、需求改變，工程師會替 Application 不斷增添新功能。然而這樣的做法卻會讓 Application 逐漸「特化」導致最後無法普遍應用在異質環境。 顯然隨時間演進會引發幾種問題:

1. Application 越趨複雜、難以偵錯，最後變成巨型單體 (monolith)
2. Git tree 出現許多分枝，管理困難
3. 容器映像檔、程式碼重用性 (reusability) 降低

但正如微服務架構的概念一樣，適當的將主應用功能與新功能進行解耦，便能提高重用性與降低複雜度。

以下將會為各位介紹邊車模式如何解決上述問題

邊車模式

不知道各位是否有印象，在看美劇或電影時常會看到有人騎哈雷時為了多載人會在旁邊外掛一輛車

整輛車的主體是位於中心的哈雷「負責前進」，而旁邊的側車「增加載物、載人的可能性」。

這正是邊車模式的概念來源:

透過其他容器來「增添、擴展」主要容器的功能性

前言

從研究所開始接觸到 OpenStack、分散式系統設計，甚至開始工作後都不斷在相關領域打轉。接觸到 Kubernetes 前，其陡峭的學習曲線 (和 Docker Swarm 相比) 讓許多人為之卻步 ，但從設使用方式甚至架構設計便能夠深刻體會，Kubernetes 是如何真正解決許多分散式系統上的困難點，並且將分散式系統內大部分的難題交由平台來處理，也可以說它將「開發」與「維運」間的高牆打掉不少。

Kubernetes 有以下幾個特點非常吸引我:

1. 維運方便: 內建滾動升級、健康度檢測、標籤組合調控流量分流
2. 生態系完整: 從本地開發到線上部署皆有對應工具處理，加速整體系統迭代
3. 跨雲提供商: 橫跨三本柱 GKE、AWS、Azure，從而避免 Vendor lock-in

正好前陣子微軟釋出 Desigining Distributed Systems 的電子書，內容主要針對在 Kubernetes 上的分散式系統設計模式，最近在練習英文以及重新回顧分散式系統設計的相關知識，趁此機會為該書內容做個導讀，重點會擺放在設計模式的講解與搭配不同的實際案例作為說明。

課堂挑戰題影片說明

• 課程 Repo: https://github.com/life1347/k8s-workshop

課堂疑問整理

若有任何疑問歡迎在下面 DISQUS 提問 :)

容器在不做資源限制的狀況下是否會使用 Host 所有資源?

沒錯，因此必須針對各容器做適當的限制避免耗盡資源。另外，有以下幾點好處

1. 利於容器調度
2. 避免單一容器異常波及其他正常服務
3. 統計容器叢集資源使用總量
4. 避免影響 host 正常運作

單台 host 開越多容器是否意味著能夠負載更多連線

這邊是常見的誤區，儘管容器之間的資源可以共享但實際上仍然受制於 host 上的資源總量。假設某應用在 host 上執行最高能負載 500 條連線，打包成容器執行後會變成 total connections <= 500，不會變成 500 * N。容器的優勢在於開關快速，可以根據服務的負載快速開關，以因應服務需求。但當資源總量不足時仍然需要透過擴張節點來支撐流量。

開發流程發生什麼問題

對於一般開發者來說要架設 Kubernetes 是件吃力不討好的事情，自從 minikube 推出後大幅減低進入門檻，讓任何人都可以輕易在電腦上執行本地端的 Kubernetes。minikube 原理是利用 Hyperviosr 在電腦上執行已經安裝好 Kubernetes 的虛擬機，再將 kubelet 的設定指向 minikube 內。

一般開發流程大概是:

1. 修改程式
2. 打包成映像檔，送到 remote registry
3. 更新 pod spec
4. docker daemon 從 registry 拉最新映像檔