每日小知識 #20 - Kubernetes(序)

• 現狀思考: 假設我們已經建立了整組跑在 Docker 上的服務，可是這真的足夠了嗎？以下幾點需要各位一同思考:
  • 服務的職責
    • 對外的 REST API 是否分散在多個 Controller？
    • 承上，每一個微服務的職責是否不夠單一？
  • 服務間的相依
    • 每個服務是否能獨立 Deploy？
    • 是否一定要知道某個服務的連線資訊才能處理？
  • Horizontal Scale
    • 每一個服務本身是否支援多個 instance？
    • 如果有多個 instance，是否能跨機器？
    • 如果跨機器，多個 instance 怎麼作 Load balance？
    • 承上，多個服務間還能 僅 透過 container name 溝通？
    • 服務間的驗證該怎麼處理，取消驗證？還是應該要有一個統一的驗證服務？
  • High Availability
    • 只在一台機器上，如果那台機器掛了？
    • 承上，如果有備援，怎麼備，備在哪，備的機制是什麼
    • 服務本身的錯誤處理機制完善嗎？會不會相依的服務掛了就直接拋錯誤？

• Kubernetes 可以做什麼？
  • 透過 Pod 管理 container (不限於 Docker)，可自動重啟壞掉的服務，不用手動下 docker restart
  • 透過定義不同種類 Kubernetes service，得以作為同服務跨機器的 instance 之統一入口
  • 透過定義 Ingress 提多個服務的統一入口
  • 透過 Master/Worker node的區分，各自有其對應的 HA 機制
  • 提供 Networking 的介面，讓各個 Vendor 可以實作 plugin 掛上，處理不同機器間的網路溝通機制
  • 其他還有很多很多，但主要都是在管理 container 的 叢集，或是彼此間的溝通，它的生命週期，…等等
• 除了 Kubernetes 還有什麼選擇？
  • Redhat 釋出的 OpenShift
  • Google 的 Google Kubernetes Engine(GKE)
  • Amazon 的 Elastic Kubernetes Service(EKS)
  • Azure 的 Azure Kubernetes Service(AKS)
  • VMWare 推出的 VMWare Enterprise PKS
  • 但其實以上都是在 Kubernetes 墊了一層什麼，來提供更多樣化的服務給客戶
  • 承上，這是因為 Kubernetes 其實是一組 Interface，開放由各家廠商自行實作，前面提到的其實就是付費版的雲服務。
• 難道只能付錢？
  • 免費地端的架法也是有的，像是 Rancher 的 RKE，Apache Mesos Marathon…等。
  • 當然，也可以選擇去官方網站載 binary 包下來自行安裝設定。
  • 承上，但這相當累人，別忘了我們的本業是 Developer，Ops 的東西是該有觀念，而非必須全部土法鍊鋼，有快速方便的方法自然選擇有效率的

以上是 Kubernetes 的一些簡介，接下來的幾十天內會盡可能深入講解如何 使用 Kubernetes，還請各位敬請期待…

(To be continued …)