kubernetes, sdn, linux,devops

本文開始又是嶄新的一篇，開始探討也是非常重要的儲存資源，儲存方面也有相關的標準再發展，其目的與 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 設計需要思考的部分以及相關議題

本篇文章算是一個手把手實作的文章，主要會介紹如何使用 golang 開發一個基於 Linux Bridge 的 CNI 應用程式，並且介紹如何搭配設定檔來使用這個 CNI 操作 Linux Network Namespace, 藉由這篇文章的過程理解到一個 CNI 的運作及開發，對於往後研究其他 CNI 都會有一些幫助，特別是城市的框架跟概念。 最後本篇開發的 CNI 應用程式其實是可以直接套用到 Kubernetes 裡面使用，就因為都遵循 CNI 的規則

Container Network Interface 的標準制定後，接下來要探討 kubernetes 本身與 CNI 的整合，這部分就如同 Contaienr Runtime Interface 一樣，可以透過 kubelet 的方式告知 kubernetes cluster 該啟用什麼樣的設定來設定 cluster 的網路，同時系統上也有相關的參數用來設定 CNI 相關的檔案，譬如執行檔以及設定檔，同時要注意的是 CNI 是基於節點為單位，所以設定的時候是每台機器都要設定。

本文作為網路系列文章的第一篇，將從 Container Network Interface 下手，相對於 Container Runtime Interface, CNI 以是個類似的架構，但是主打網路能力為主，至於網路能力這個字眼其實很模糊，畢竟不同情境，不同需求都會有不同的實現方式，很難用一個通用的說法來函索有可能力。本文會跟大家介紹 CNI 的相關資訊，包括標準的內容，相關設定，最後也會透過一些比較跟大家介紹不同 Container 實現方式其最後底層去操作 CNI 的方式也截然不同

本文作為 CRI 系列文章的最後一篇文章，要來跟大家分享一個比較少見的用法，透過 kubernetes 管理 Pod 的方式來管理 Virtual Machine，底層所有運行的服務都是基於 Virtual Machine 去跑，但是對於 Kubernetes 來說完全不知情，依然認為是一個 Pod 的形式。 這部分依賴重新撰寫一個符合 CRI 標準應用程式來對接 kubelet, 並且底下所有的運作都使用 virtual machine 來操作，因此這個範例就完全不會有 OCI 的存在，因為是真正的 virtual machine, 而非 container.