kubernetes, sdn, linux,devops

本篇文章作為 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 可以互相溝通溝通的。

本篇文章針對 flannel 如何管理 IP 地址的事情進行探討與研究，許多人初次使用 kubeadm 安裝 flannel 的時候都曾經因為忘記加上 --pod-net-cidr 等參數導致安裝失敗，而這篇文章就會來探討這個參數的意義，為什麼需要這個參數，同時搭配前述已經分享過的 IPAM 管理，來重新仔細觀察 flannel 的運作過程

CNI 的選擇一直以來都是個探討的議題，各式各樣的 CNI 有者不同的特色與效果，使用者要怎麼選擇往往不知所措。老實說對於大部分的使用情況來說，其實 CNI 的選擇影響也不太大，畢竟很多情境只是要求網路可以通暢即可，沒有其他的需求。 而本文則針對一個常見的 CNI, Flannel 進行探討，來研究該 CNI 到底怎麼安裝的，安裝的過程怎麼處理設定檔案的問題。

IP Address Management 作為 CNI 本身可提供的一個重要功能之一，更是 kubernetes 本身不可或缺的能力，透過 IPAM 的管理可以讓每個 Pod 都獲得一個 IPv4 或是 IPv6 的地址，至於 Pod 本身能不能上網，那就是 CNI 本身要處理的問題，根據不同需求來建議不同的網路環境提供 Pod 上網能力。本篇文章主要是探討 IPAM 的部分，針對三個由官方維護作為參考用的 IPAM，分別介紹他們的用途以及使用方式，來深入了解 IPAM 設計需要思考的部分以及相關議題