kubernetes, sdn, linux,devops

這篇要來跟大家介紹什麼是 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 本身標準涵蓋的範圍與流程，以及部署上的一些常見做法，包含多種服務器各自的角色與地位。

本文開始又是嶄新的一篇，開始探討也是非常重要的儲存資源，儲存方面也有相關的標準再發展，其目的與 CRI 以及 CNI 一致，都是希望透過標準化接口能夠使得第三方的解決方案開發更加活絡且流暢，本文會開始來介紹儲存方面的基本概念以及為什麼需要 Container Storage Interface

本文作為網路分享的最後一篇，針對各式各樣的 CNI 相關議題進行討論，並且分享個人自身看法，沒有太深的技術研究與分析

本篇文章作為 CNI - Flannel 的最後一篇探討，藉由研究 VXLAN 的運作原理來研究到底 flannel 是如何透過 vxlan 來讓不同節點上並且擁有私有 IP 的 Pod 可以互相溝通溝通的。