無伺服器架構和微服務架構會是雲端應用程式逐漸採納的主要軟體架構，在前幾期技術專欄中已介紹過微服務架構的演進過程，以及導入微服務所帶來的好處與問題，接下來的幾篇文章將介紹無伺服器架構和Kubernetes容器管理平台的無伺服器框架Knative。
無伺服器架構和Kubernetes容器管理平台的無伺服器框架「Knative」，可同時於雲端和本地端的Kubernetes叢集上運行，只須撰寫好建置模板（buildtemplate），即可執行Azure Functions和AWS Lambda等大廠的無伺服器運算程式，避免被雲端廠商技術鎖定（Vendor Lock-in），當然這Knative無伺服器框架的底層技術仍是採用容器方式來運作，因此必須熟悉Docker容器技術，才能輕鬆上手。
無伺服器運算簡介
在2014年，筆者接受媒體專訪Docker容器技術時，就聊到雲端PaaS平台會因為容器技術而再次演化，成為新的PaaS運作方式。 時至今日，亞馬遜AWS與微軟Azure已有容器代管的雲端服務ECS（Elastic Container Service）、ACI（Azure Container Instance）等，為何從Heroku（*註一）和Google GAE推出後，虛擬機層級的IaaS仍是主流，主要原因可從柏克萊大學（*註二）的論文《Cloud Programming Simplified: A Berkeley View on Serverless Computing》（https://arxiv.org/abs/1902.03383）洞察出答案。
其研究觀點認為虛擬機成功的主要原因是，在雲端運算的早期階段，使用者希望在雲端重建與本地端相同的系統環境，因它們是直接將本地端伺服器的工作負載搬移到雲端，而且完全無須改寫程式和架構，理所當然地，這樣運作方式會偏好EC2這樣的IaaS平台。
但此種雲端託管方式就必須自行管理作業系統，並且配置執行環境，雖然可透過虛擬機映像檔來複製和橫向擴展（Auto-scaling），但是系統軟體升級或改版的第一次施作仍舊必須全部重製，而且當應用程式只是簡單的幾行程式時，此作業系統和執行環境的準備工作就占據了所有前製時間。因此，PaaS推出後獲得相當多開發者關注和喜愛，但PaaS卻因程式執行環境、相容性、效能和資安問題，本地端程式必須要改寫才能移植到雲端PaaS，企業須投入高額的改寫成本並擔心被雲端廠商技術綁定，大幅降低了使用PaaS平台的意願。
直到2013年，Docker容器技術浮上檯面，以容器方式代管的PaaS接踵而來，PaaS進入2.0世代，可避開程式重新改寫的負擔，又可免除作業系統和系統維運的繁瑣工作，而容器並非要取代虛擬機，它是一種新的軟體包裝方式，將執行環境、函式庫和程式執行檔放入容器，並以Process程序層級作隔離並執行，所以Kubernetes是為了管理這些容器程序所發展出的容器管理平台，故Google K8S傳教士Kelsey Hightower就直白表達：「Kubernetes isn't the kernel; it's systemd.」，如圖1所示。
圖1 Kelsey Hightower直白表示K8S is system。
在2015年，亞馬遜推出了AWS Lambda服務，標榜無須關注任何伺服器相關問題，透過專門的Serverless Framework（無伺服器框架）撰寫程式，整合雲端的特定後端服務API（Backend as a Service，BaaS）或功能即服務（Function as a Service，FaaS），就只需要專注在業務邏輯的雲端架構，因此「Serverless = FaaS + BaaS」。
當然，這無伺服器程式仍有雲端服務和平台相依性問題，不過因為採用以呼叫次數來計費，有別於傳統以使用時間計費，加上可自動橫向擴展、支援客製執行環境和以容器方式包裝後部署，如AWS Lambda custom runtime（https://docs.aws.amazon.com/zh_tw/lambda/latest/dg/runtimes-walkthrough.html）和Azure Functions，故逐漸吸引有巨幅變動請求和大量運算需求的企業使用，連AWS自身的服務都轉移到Lambda平台上，IaaS、PaaS和SaaS及Serverless之比較如圖2所示。
圖2 IaaS、PaaS和SaaS及Serverless比較圖。（資料來源：Beginning Serverless Computing, Apress）
下列適用情境，提供選擇使用無伺服器運算或容器代管平台：
‧建議使用無服務器運算：
1. 應用程式只須執行排程工作，而無須持續運行。
2. 基於IoT領域的應用程式，僅在某些情況下才會啟用。
3. 著重在初期的開發速度和營運成本上。
4. 需要自動橫向擴展。
5. 需要處理Web網站和行動應用App的大量後端服務。
6. 需資源密集型的應用情境，如即時應用程式、資料流和上傳資料。
7. 須將數據遷移到長期儲存庫，並針對資料執行詳細分析。
‧推薦使用容器代管平台：
1. 具複雜和長時間運行的應用程序，且需要高度掌控的執行環境。
2. 需要將遺留應用系統搬遷到雲端上（Kubernetes和Docker Swarm很適合這樣應用情境），或整併到容器化環境。
3. 需要維運電子商務網站，該網站需要以容器包裝服務，且沒有時間或記憶體限制。
4. 需要靈活且完全掌控整個系統。
5. 希望可自行選擇作業系統和程式語言。
6. 希望系統能自動處理流量問題。
而容器即服務（Caas）和Serverless的架構上差異，如圖3所示。
圖3 CaaS與Serverless無伺服器之架構對比。
無服務器和容器技術亦可一同運行工作，像是特定後端服務，如資料庫，其存取層可用容器來提供Access API，再讓無伺服器程式來使用，就可將資料庫相依性解耦，若本地端運行Knative框架，只需要改寫存取層微服務，替換為本地端資料庫，建構出可輕鬆遷移的雲原生系統架構，整個Serverless無伺服器雲端架構如圖4所示。
圖4 Serverless無伺服器雲端架構（資料來源：https://arxiv.org/abs/1902.03383）。
什麼是Knative
Knative的目的是建立在Kubernetes基礎之上，協助以無伺服器方式提供整個軟體開發生命週期。具體手法是：首先開發人員能夠以想要的語言和想要的方式來撰寫程式碼，接著建構和打包應用程式，最後再協助運行和擴縮整個應用程式。
Knative的三個關鍵元件
因此，Knative將重點放在三個關鍵元件：建構應用程式（Build），為其提供流量服務（Serving），及確保應用程式能夠輕鬆地以事件方式產出和消費（Event）。
透過靈活的Plugin插件式建構系統，將使用者程式碼包裝成容器，目前已支援多種建構系統，如Google的Kaniko，無須執行Docker daemon就可以在Kubernetes叢集上建置容器映像檔。
Serving
基於負載量的自動擴縮，包括在沒有負載時縮減成零。允許多個修改版本（Revision）的應用程式，建立流量策略，進而能夠藉由URL輕鬆繞送請求到目標應用程式。
使產出和消費事件變得更容易，抽象化事件來源，允許使用者選擇適合自己的訊息傳遞層和觸發邏輯，例如HTTP、MQTT等等。
針對不同目標客群所開發
Knative是針對不同的目標客群所開發的，圖5提供了整體輪廓：
圖5 Knative目標客群之描繪。
開發人員
Knative元件提供開發人員Kubernetes原生API，可用於部署無服務器風格的Functions函式、應用程式和容器到自動擴展的運行環境。
維運人員
Knative元件目標在整合到更優秀的產品之中，讓雲端服務供應商或大型企業的內部團隊可以持續運作，任何企業或任何雲端供應商都可以將Knative元件應用到他們自己的系統中，並賦予這些優勢到他們的顧客。
貢獻者
Knative有規定明確的專案範疇，輕量化管控模型和可抽換元件之間具有清楚的切割，可以建立有效率的貢獻者工作流程。
雖然Kubernetes已經演進並開始解決軟體架構當中的一些問題，但是前面提到的關於持續發展中的無服務器架構（Serverless）上，卻產生了更多的問題，如何管理多個事件類型的一致性？如何定義事件來源和目的地？
許多無服務器架構或函數即服務（FaaS）框架都嘗試回答這些問題，但是它們以不同的方式來解決這類問題，而且不是所有的解決方案都用到了Kubernetes。而Knative建立在Kubernetes的基礎上，並且為建構和部署無服務器架構及基於事件驅動的應用程式提供了一致的標準模式。
Knative準備工作：架設K8S叢集
由於Knative是建立在Kubernetes之上，所以必須先建立好Kubernetes叢集，此操作以微軟雲端平台Azure上的AKS（Azure Kubernetes Service）來示範。
STEP 1：首先登入Azure Portal網頁，如圖6所示。
圖6 登入Azure Portal網頁。
STEP 2：點選新增資源，接著選擇「Containers（容器）」，再選取右邊的「Kubernetes Service」，如圖7所示。
圖7 新增資源畫面。
STEP 3：接著輸入詳細資訊，例如資源群組名稱、AKS叢集名稱以及位於哪個Region等資訊，如圖8所示。
圖8 Basic頁面。
STEP 4：在Node size選項，可以修改自己需要的叢集節點VM規格，然後按下「Change size」，如圖9所示。
圖9 Node Size選項畫面。
STEP 5：選擇所需的CPU Core、記憶體和硬碟速度，確認好後，按下〔Select〕按鈕，如圖10所示。
圖10 選擇節點規格畫面。
STEP 6：確認好了之後，按下〔Next: Scale >〕按鈕，到下個頁面，如圖11所示。
圖11 完成第一個設定頁面。
STEP 7：此頁面可選擇是否啟用「Virtual node（虛擬節點）」，透過虛擬節點，可以在能夠高負載時執行ACI與AKS叢集之中Pod的網路通訊，透過ACI服務來快速代管Pod。而「VM scale sets」是將Auto Scaling功能應用到AKS叢集，動態增加Worker的節點。接著，按下〔Next: Authentication >〕按鈕，如圖12所示。
圖12 Scale設定頁面。
STEP 8：因為安裝Istio需要啟用RBAC（Role Based Access Control），因此務必設定成「Yes」。接著，按下〔Next: Networking >〕按鈕，如圖13所示。
圖13 Authentication設定頁面。
STEP 9：Networking方面若沒有額外需求，直接按下〔Next: Monitoring >〕按鈕，如圖14所示。
圖14 Networking設定頁面。
STEP 10：可選擇是否啟用容器監控，需要新增Log Analytics workspace，然後按下〔Next: Tags >〕按鈕，如圖15所示。
圖15 Monitoring設定頁面。
STEP 11：若不需要額外的標籤說明，可直接按下〔Next: Review + create >〕按鈕，如圖16所示。
圖16 Tags設定頁面。
STEP 12：若驗證沒有錯誤，即可按下〔Create〕按鈕，建立AKS叢集，如圖17所示。
圖17 Review設定頁面。
STEP 13：叢集建立好之後，按下最上面的「>_」符號，開啟雲端命令列功能，可直接下命令來設定，首先輸入「az login」，將會出現網址要求登入，以及其驗證碼，如圖18所示。
圖18 Azure CLI Console畫面。
STEP 14：輸入「az login」所顯示的驗證碼，便完成認證，接著選取Azure帳號。完成後，命令列會列出所有的Subscription帳號資訊。
STEP 15：接下來輸入「az account set -s YOUR_SUB_ID選擇使用哪個Azure帳號」，可使用「az aks show --resource-group YOUR_RESOURCE_GROUP --name YOUR_AKS_NAME --query nodeResourceGroup -o tsv」，查詢AKS叢集資訊，接著下載AKS的連線憑證，輸入「az aks get-credentials --resource-group YOUR_RESOURCE_GROUP --name YOUR_AKS_NAME」，可將必要的連線資訊和憑證安裝到「.kube」目錄中，最後使用kubectl來測試是否可控制AKS叢集，輸入「kubectl get nodes」，可看到建立的叢集節點，如圖19所示。
圖19 完成AKS憑證匯入畫面。
待續
建立好Kubernetes之後，將在下一篇開始安裝必要的Istio和Knative無伺服器框架，若想要學習K8S相關知識，微軟網頁有非常完整的資訊（https://azure.microsoft.com/en-us/resources/kubernetes-learning-path/）和教材（https://aksworkshop.io/），而且Kubernetes的原創作者之一Brendan Burns被挖角到微軟並協助發展Azure雲端服務，還錄製了Kubernetes Basics（https://www.youtube.com/playlist?list=PLLasX02E8BPCrIhFrc_ZiINhbRkYMKdPT）線上教學影片，建議對Kubernetes有興趣的朋友可以從這些資訊著手開始。
＜本文作者：鄭淳尹，Docker.Taipei社群共同發起人，現任微軟MVP，momo購物網架構師，曾任臺北榮民總醫院資訊工程師、玉山銀行資訊處專員、宏碁eDC維運工程師，系統維護及開發設計超過15年。開源技術愛好者，曾在多間大學資工系擔任Docker容器技術講師，並翻譯審閱多本容器技術書籍。＞