kubernetes, sdn, linux,devops

Service Catalog 是一套基於 Open Service Broker API 的資源創建解決方案，這邊的資源指得是一些並非 kubernetes 內建，但是常常被使用的資源，譬如資料庫等。透過 Service Catalog 的框架，使用者也可以透過 kubernetes yaml 的方式來創建與管理這些外部資源，並且使用 kubernetes secret 來保管相關的資訊檔案。

Operator 從 2018 年開始串紅，愈來愈多的服務都宣稱支援 Operator 的運作模式，所以本篇文章就來探討到底什麼是 Operator 以及使用這種運作模式可以帶來什麼樣的好處及壞處。

這篇要來跟大家介紹什麼是 Single Root Input Output Virtualization (SR-IOV)，作為一個 OpenStack 世界中就大量被使用的裝置，到底其提供什麼樣的功能，以及為什麼 kubernetes 中會需要這個裝置，並且什麼情境下需要使用這個裝置。

這篇要來跟大家介紹什麼是 Remote Directly Memory Access(RDMA)，從這個裝置的概念介紹來學習該裝置的使用情境，並且套用到 kubernetes device plugin 的框架中可以怎麼使用。

本篇文章會就 device plugin 本身的架構來探討如何實做一個 device plugin 的解決方案，從其溝通介面到運作流程進行探討，透過這些理解與討論會對 device plugin 有更多的了解

除了三大標準 CRI, CNI, CSI 之外， kubernetes 本身也有自行時做一些方式來擴充整個叢集的功能，而本文要介紹的就是 Device Plugin 這個擴充功能，這個功能最著名的使用方式我想就是 GPU運算了，透過 Device Plugin, 可以讓不同 GPU 廠商都能夠自行實作相關的方式把 GPU 跟運算資源結合並且透過 kubernetes內建的 scheduler 等有效地使用這些資源。

本篇文章作為 Storage 的最後一塊，就沒有特別針對主題探討，反而是聊聊閒聊一些 Storage 方面的議題，順便聊聊 Mount 這個東西除了常見的功能之外，還有什麼參數可以使用，並且有什麼樣的效果。

前述分享了關於不少 Container Storage Interface 的事情，接下來我們直接使用 NFS 作為範例，來看看要如何透過 CSI 的架構來掛載 NFS 到 kubernetes cluster 中供運算資源使用

本篇文章著重於 Kubernetes 本身與 CSI 的關係，一直以來 kubernetes 甚至到 1.16 來說， CSI 都不是一個必需的設定，反而是依賴大量 in-tree 的整合程式碼來處理各式各樣的儲存後端，這雖然使用方便但是對於後續的擴充性，維護性，彈性都帶來的很大的危害。也因此 CSI 才有誕生的機會，所以對於長期使用 in-tree 的管理人員來說，勢必有一天要轉移到 CSI才有機會想到新的功能以及相關功能的修復

本文針對 Container Storage Interface 的標準進行介紹，探討 CSI 本身標準涵蓋的範圍與流程，以及部署上的一些常見做法，包含多種服務器各自的角色與地位。