Multus-CNI === ###### tags: `CNI` `kubernetes` `multi-network` # Preface * Kubernetes 為範例，對於每一個創建的 Pod 只會呼叫一次 CNI 來設定相關的網路功能，然而在某些場景應用中，會特別希望該 Pod 中有多個網路介面。我這邊使用下圖作為一個範例介紹 * 試想一個情境，有很多的應用程式容器化之後要運行在 Kubernetes 上，這些容器本身需要互相溝通協調，同時這些容器本身有非常強烈的網路效能需求，譬如 High Throughput/Low Latency. * 在這些應用程式尚未容器化以前，其架構中常常會規劃成 Control Network 以及 Data Network. 這些應用程式透過 Control Network 來傳輸控制用的資料，而透過 Data Network 來傳輸真正的資料。 * 這些應用程式容器化遷移到 Kubernetes 之後，要如何在 Kubernetes 上滿足這些需求? * 就算今天 Kubernetes 不用 IPTables 而改用 IPvS 的模式來處理相關的功能，整體傳輸的速度還是受限於 Linux Kernel而沒有辦法達到令人滿意的境界，勢必要另尋它路來處理。 * 尤其是kubernetes的Pod是默認還不支援多網卡設定。  * 這種需求的情況下，有一種特別的 CNI 就誕生了，這類型的 CNI 本身沒有提供任何的網路應用功能，而是作為一個呼叫者去銜接數個 CNI Plugins 來處理。 # 概觀  * Multus可以運行在kubernetes的pod提供多個接口，幾乎支援多數CNI plugin: * CNI開發的plugin(Flannel、DHCP、Macvlan) * 第三方Plugin(Calico、Weave、Contiv) * 其他kubernetes會機制失效的plugin(SR-IOV、DPDK) * Multus 使用"delegates"的概念將多個CNI plugin組合起來，並指定一個主要的CNI plugin作為主網路能被k8s discover。 * 能夠客製化自己需要的CNI  ### How to build the multus-cni? [詳細操作](https://hackmd.mcl.math.ncu.edu.tw/s/rk84JK41S) ### Logging Best Practices * Followings are multus logging best practices: * Add logging.Debugf() at the begining of function * In case of error handling, use logging.Errorf() with given error info * logging.Panicf() only be used at very critical error (it should NOT used usually) # Summary * 這邊借用 Multus 的一張圖片來說  * 最終目的就是希望每個 Container 被創立的時候都可以執行多次的 CNI Plugin. * 因此整個架構就會是 Kubernetes –> Special CNI -> Other CNIs. * 現在提供這種需求的 CNI 也不少，由於目的相同，大部分都是單純用法不同，因此我將這些 CNI 都放在一起。 * Mutlus-CNI 是由 Intel 所主導開發的，看到這邊再來回想一下前面所介紹的 SRIOV/DPDK/Bonding 等也是由 Intel 所維護的相關 CNI Plugin。 * 不難想像 Intel 想要做的是一個整體的網路解決方案，先透過個別的 CNI 提供獨特的功能，最後透過 Multus 的方式將這些 CNI 全部串接起來來滿足使用者的需求。