Kubernetes

收費課程 - Kubernetes 容器編排平台導入

讓機器管機器，你才能專注在最有價值的工作上

ta-ching chen

1 minute read

課程推廣

為應付更龐大的流量，許多企業開始將傳統架構轉型成微服務架構，而微服務架構往往牽涉到部署與管理大規模伺服器叢集， 而 Kubernetes 不僅使用到容器技術，更結合 Google 自身多年經驗，將微服務管理變得更為輕鬆。

近年來許多 DevOps、SRE 職缺開始將 Kubernetes 列為面試加分選項，相信未來技術越加普及後會逐漸成為職缺必要條件。用一堂實體課程時間，學習新技能讓自己職業生涯越走越順!

但對於剛接觸的人來說，常會被不同用途的 Controller、Volume、Service 概念搞得頭昏眼花。因此於 2020/10/17、10/24 我會開設 2020 北部實體線下課程 「Kubernetes 容器編排平台導入」， 讓更多人能真正瞭解 Kubernetes 的精髓，並能真正應用於他們日常工作上。

課程內容

內容會從 Kubernetes 基礎開始教起，接著學習進階內容最後上機練習。

你會學到在這個部落格內的 Kubernetes 內容的精華版，並且我會分享使用於生產環境的經驗，以及該如何避免採坑。

基礎概念

  • Container (Docker)
  • Kubernetes 核心架構介紹
  • Kubernetes Pod
  • Kubernetes Service
  • Kubernetes Volume
  • K8S Configuration
  • 實戰訓練
    • 指令使用與聲明式宣告
    • 物件組合與應用
    • 系統操作、除錯、分析

Fission 1.4 更新重點聚光燈

你知道 Fission 能夠部署 Tensorflow ML 模型了嗎 ?

ta-ching chen

2 minute read

Introduction

在近兩個月的時間裡，針對來自不同用戶的反饋及問題回報 (包含前陣子的通靈故事 Localhost 迷航記)， 我們在 1.4.0 與 1.4.1 做出許多值得一提的改變，讓 Fission 能更加適應跑在不同生產環境上。就讓我們來看看多了什麼改變吧!

Highlight

新的實驗環境: Tensorflow Serving

Tensorflow 作為被廣泛接納的機器學習框架，許多公司會利用它來訓練自家模型。但常會發生:

  1. 工程師懂得寫跟訓練模型，卻沒有相關部署知識
  2. 需要花額外時間撰寫 RESTful API server 來服務請求

因此「如何將機器學習模型快速部署到生產環境上」，一直是許多人心中的痛。

有鑑於此 Tensorflow 官方推出 (Tensorflow) Serving 試圖降低模型產出到部署之間的難度。 只要將模型放到對應資料夾內，Serving 偵測到模型後便會啟動對應 API server 服務，甚至版本異動時亦會將請求流量逐步轉移至新的模型。

然而，實際營運上考慮的因素絕不單單只有「將模型利用 API server 來服務預測請求」這麼簡單。

更多數情況我們會問的是:

如何大規模部署機器學習模型? (How to deploy ML models at scale?)

這個問題就牽涉到「底層架構」與「服務水平伸縮」等等議題。

Localhost 迷航記

當 localhost 不再是 localhost 時

ta-ching chen

2 minute read

Introduction

故事背景稍微介紹一下，使用者反映 Fission基於 Kubernetes 之上的 FaaS (Function-as-a-Service) 框架 在週末突發性的無法正常運作。作為一個興趣使然的工程師，遇到使用者反應問題當然要 (義不容辭) 協助排解。 經過各種遠端通靈一種在不知曉確切運作環境或對於問題毫無頭緒下，仍然嘗試除錯的技術 ，發現問題發生在當要初始化使用者的 function 時出現。

function-pod

Fig. 1 Fission function pod specialization process

整個初始化流程如 Fig. 1，首先 executor 會送出 specialize 請求給 fetcher，讓它取得 function code 後放至 share volume 內。 再由 fetcher 呼叫 env runtime，讓其載入 function code 後服務 HTTP 請求。

"logger":"fetcher"
"msg":"error connecting to function environment pod for specialization request, retrying"
"error":"dial tcp 10.58.152.224:8888: i/o timeout"

從日誌上來看錯誤是 i/o timeout。奇妙的地方在於本來是呼叫 localhost，卻顯示 10.58.152.224 超時 ?!

而用戶反應問題是在公司開始導入 proxy 後發生的，到這邊可能性有兩個:

  1. Proxy 設定出現異常，導致 Pod 內部的本地端 HTTP call 被攔截送往其他地方
  2. DNS 解析出現錯誤

原本想說會不會跟 docker 的 NO_PROXY 設定相關，但該設定主要跟 pull image 相關且測試後也驗證不是這個原因。

事已至此，剩下 DNS 解析出錯的可能性，也只能開始往最瞎的方向開始思考:

是不是在 namespace 底下有個名為 localhost 的服務存在？

邊車模式 (The Sidecar Pattern) - 介紹

講解如何透過邊車容器來「添加、擴增主應用功能」

ta-ching chen

2 minute read

前言

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

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

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

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

邊車模式

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

sidecar

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

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

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