92 docs tagged with "Network"

The most import feature of the container is the resource isolation, including the mount, network, user, UTC and PID. that's the reason why we can't see those resources status of the host. The resources isolation are supported by the Linux Kernel and we will demostrate the networking part by the network namespace and also show you how does the docekr use the network namespace and Linux Bridge to proivde the network connectivity for each container.

Container Network Interface (CNI) as a Network Interface between the network soluition and the container mechanism. Without the CNI, the network solution developer should implement his/her plugin for every container environment and it must be a disaster. Fortunately, with the help of the CNI, the developer can only focus on one interface and it should work for every container mechanism. In this post, we will see why we need the CNI, what is CNI and how kubernetes use the CNI to provide the network connectiviy for the computing unit, so called Pod.

As we know, the kubernetes use the CNI to provide the network connectivity for its Pod unit and the cluster administrator can choose what kind of the CNI should be installed in the cluster. For example, if the only requirement is the overlay network, you can choose the flannel CNI and choose the calico CNI if you have the requirement of the BGP. In this post, we will learn how to write your own CNI in golang language. Actually, You can implement it with any language as you like.

在前述中我們已經學過了什麼是 kubernetes service, 一般情況下都會採用 ClusterIP 的形態幫特定的容器應用程式提供 Service 的服務. 本文會針對 ClusterIP 的概念進行更深入的探討,並且嘗試從系統層面的設計與應用來研究到底 ClusterIP 底層是怎麼實作的,這部分的實作包含了1) ClusterIP 到底在那裡？ 2) 如果有多個 Endpoints 的話, 是如何選擇當前連線的最終目標. 這些研究的內容包含了常見了網路概念，如 NAT(Network Address Translation) 以及 iptables 本身的設計及使用，如 table/chian 等概念有初步的認知,這樣對於本文的探討會更明白與瞭解.

在前述中我們已經學過了什麼是 kubernetes service 以及如何實現 ClusterIP 這種類型的 service. 透過對 iptables 的探討與研究, 我們可以理解到 ClusterIP 本身會提供一個虛擬的 IP 地址,接下來只要跟這個地址有關的封包,都會透過 DNAT 的方式進行轉換找到最後的 Endpoint IP. 至於如何選擇的部分,則是透過機率的方式去尋找. 接下來我們要來探討另外一個也是很常使用的 kubernetes service 類型, 也就是 NodePort. NodePort 本身包含了 ClusterIP 的所有功能, 此外也額外開啟了一個新的存取方式. 透過直接存取節點的 IP 地址配上一個設定好的 Port, 也可以將該封包直接送到最後面的容器應用程式. 因此本文也要延續上一篇的思路,繼續研究 iptables 的規則來探討 NodePort 到底是如何實現的

在前述中我們已經學過了什麼是 kubernetes service 以及如何實現 ClusterIP/NodePort 等 service 類型. 透過對 iptables 的探討與研究. 接下來要研究的則是 Service 裡面的一個參數, 叫做 SessionAffinity, 所謂的連線親和力, 透過該參數的設定,希望能夠讓符合特定條件的連線最後都會選用到相同的後端應用程式,目前有支援的選項是 ClinetIP, 這意味者只要連線的來源 IP 地址是相同的,最後都會被導向到相同的容器應用程式. 然而這部分到底是如何實現的, 本文會先介紹什麼叫做 Connection. 並且介紹 SessionAffinity 的使用方式以及使用後的結果. 最後一樣透過相同的思路, 藉由研究 iptables 的規則來學習到 SessionAffinity 要如何完成, 同時也可以學習到 iptables 衆多靈活的使用方式.

於 kubernetes 叢集中，我們會部屬大量的容器應用程式,而這些應用程式有些是面向使用者,也有些是彼此容器間互相溝通使用的.舉例來說,管理人員可能會在叢集中佈署了相關的資料庫容器服務,而其他的應用服務就必須要透過網路連線的方式來存取該資料庫.為了要透過網路的方式存取,就意味要使用 IP 地址的方式來存取對應的容器服務,然而在 kubernetes 的叢集中,這些 Pod 重啟後預設情況下都會拿到不相同的 IP 地址， 這意味我們的客戶端應用程式就沒有辦法寫死這些 IP 地址來存取,必須要有更動態的方式讓客戶端應用程式可以取得當前目標容器(資料庫)的最新 IP 地址. 為了解決這個問題, 我們可以透過 kubernetes service 的架構來達成上述的目的。本文會跟大家介紹什麼是 kubernetes service 以及透過實際範例介紹該如何使用

本文透過對 iptables/ebtables 來設定相對應的規則，藉由這些規則來觀察在 Docker Bridge Network 的網路設定下，不同情境的網路傳遞實際上會受到哪些 iptables/ebtables 規則的影響。這些情境包含了常見的用法，譬如容器與容器之間同網段的傳輸，宿主機透過容器IP位址直接連線，甚至是外部網路透過 docker run -p xxx.xxx 的規則來接觸到內部容器。這些不同情境的網路連線牽扯到關於 Layer3 路由，Layer2 橋接 等不同方式的處理，因此在 iptables/ebtables 都會有不同的走向。只要能夠更佳的熟悉 iptables/ebtables 的用法與規則，未來有需要親自設定相關規則時，都能夠更精準且安全的去達到想要的目的，減少盲目猜測的時間與花費。

本文是 iptables/ebtables 系列分享文的第一篇，會先著重於 iptables/ebtables 本身的架構，更準確的是 netfilter 的架構介紹，從 User-Space 到 Kernel-Space 的組成元件，並且簡單敘述一下整體的運作流程。最後開始介紹 ebtables 這個存在但是較少人知道的工具，不同於 iptables, ebtables 更專注於基於 MAC 地址的 Layer2 轉發。 文章最後介紹了 ebtables 的規則組成，並且將 ebtables 規則的處理順序以圖表的方式呈現，讓大家更容易理解在 Layer2 轉發時，該怎麼透過 `ebtables` 去設定相關的規則來處理封包。

透過瞭解 iptables 規則的四大組成 Table/Chian/Match/Target 來學習 iptables 的規則含義，同時透過圖表的方式來釐清封包在 Linux Kernel 傳輸過程中受到 iptables 規則的處理順序。最後會將 iptables 以及 ebtables 兩者的流程圖整合在一起，構建出一個更全面的封包轉送流程圖，於此流程圖中可以觀察到封包在 Routing/Bridging 不同過程中，是如何通過不同的 ebtables/iptables 規則的處理。 擁有這些資訊能夠讓你對系統上的 iptables/ebtables 有更全面性的理解其功用以及發生時機

探討 Kernel 如何實作 SwitchDev (I)

探討 Kernel 如何實作 SwitchDev (II)

探討 SwitchDev 架構問題

本篇文章是節錄自網路上一篇關於 CNI 於10G網路下的效能分析，主要是讀後心得分享

本文屬於論文導讀系列，這次針對的是高速網路(RDMA)的應用，來源是 SICCOM 2017 會議上。這篇文章有趣的地方在於他不是單純的介紹架構，而是透過一個實際的應用程式來闡述當該應用程式搭配上 RDMA 後獲得了 Zero Copy 的特色，在此特色加持下，原先應用程式的效能提升了多少。本文的標題是 Towards Zero Copy Dataflows using RDMA, 其內容跟 AI 的訓練過程有關，採用了由 Google 開源的訓練框架， Ternsorflow, 並且分析了在原先分散式的訓練模型中，資料不論在 CPU/GPU UserSpace/KernelSpace 甚至節點間都有大量的資料複製行為。透過 RDMA 的幫忙減少了這些行為最後證明了整體分散式訓練的時間大幅度縮短，是個非常有趣的短文.

本篇文章是屬於論文導讀系列，這次的對象是Google所推出的Software Network Load Balancer, Meglev. 透過對該論文的研究後可以學習到Google對於一個 Network Load Balancer 的期許以及設計的思考脈絡，並且實際理解其架構來學習到如何設計一個通用(可運行在任意的 Linux Server上), 分散式且易於擴充的彈性架構以及高PPS(Packet Per Second)處理能力的軟體程式。最後透過論文中的實驗與效能評估來觀察實際上 Meglev 的效能以及是否有滿足Google對該軟體架構的期望。

本文屬於論文導讀系列，這次針對的是SIGCOMM 2017所發表的論文中關於Data Center架構的論文。SIGCOMM這個 Conference裡面都有很多跟網路相關且高品質的論文，除了學界之外，也常常有很多業界會將相關的研究與產品設計投稿於此，因此是個滿好學習網路概念的一個資源。本篇文章針對的主題是 Re-architecting datacenter networks and stacks for low latency and high performance, 該文主旨希望重新打造一個有真正高傳輸效能的資料中心，其中涉及了非常多的面相，從交換機的實現到上層 TCP 協定的修正，從諸多面向來探討傳統的諸多協定為什麼沒有辦法達到真正的高效能傳輸，該論文非常精彩，可以學習到非常多的概念與知識，非常歡迎閱讀。

本篇文章主要的概念是閱讀筆記, 主要是針對 Google 於 2018 Sigcomm 所發表關於 SD-WAN 的相關論文,這篇論文非常直得一看的點是這篇論文算是 2013 Sigcomm B4 論文後的後續，講述了 SDN 概念引進 B4 帶來的好處以及這幾年因應環境變化而該 B4 資料中心的成長，其中包含了眾多的問題以及處理的方式，著實非常有趣，能夠學習到更多的想法與概念

除了自行架設 Kubernetes 之外，採用公有雲廠商所提供的 Kubernetes Service 也是一個方便的選擇，然而這種情況下有許多的設定跟功能都會依賴該公有雲廠商自行實作，大部分的功能都會與公有雲本身的架構進行高度整合以提供更方便的使用與操作。本文針對 Container Network Interface (CNI) 於 Azure 中的實現與使用進行了討論，藉此了解公有雲的 CNI 有什麼特別的設計與使用方式

Binomial Heap是由一群 Binomail Tree所組成的

AsyncConnection 此物件代表整個 connection，裡面提供了收送(Write/Read)兩個主要介面供應用層(OSD/MON等)使用外，裡面也處理了整個 Ceph Node收送封包的邏輯處理，這部分比較像是一個 finite state machine(FSM)，當前狀態是什麼時候，收到的封包是什麼，就切換到什麼狀態來處理。

此篇文章主要研究目前很熱門的 scale out storage 軟體 ceph 的網路架構。

Async 希望在與底層kernel socket進行I/O處理時是以 Async 的方式去運行，而不是像 Simple 一樣每條 connetion 都要開兩個 threads 來負責處理 read 跟 write。

延續上篇文章 (Ceph Network Architecture 研究(一))[https://www.hwchiu.com/ceph-network-i.html#more]，本文將繼續探討 Async 這種網路類型底層真的架構與概念，所以本文章也不會有太硬的程式碼解讀，反而會比較偏向概念性的分析。

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

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

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

本篇文章紀錄了作者這陣子以來與大家討論 CNI 時常常被問到的問題，透過對這些問題的理解可以更加深入的去學習什麼是 CNI, 以及 CNI 本身能夠能夠觸擊的功能與範圍。同時也附上一些相關的資源讓大家可以從不同角度更深入的去研究 CNI 的領域。

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

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

Introduction

本篇文章從入門的概念來介紹 Docker 的網路模型，透過對其使用上的瞭解，可以幫助我們去理解容器之間網路的使用，對於未來學習 Kubernetes 時會得心應手

本篇文章探討 Docker Bridge 網路模型的運作過程，透過一系列步驟去拆解到底容器是如何對外上網

本篇文章探討 Docker Bridge 網路模型的運作過程，透過一次次的步驟手動搭建出一個 Linux Bridge，並且成功讓多個容器可以彼此互通

本篇文章探討 Docker Bridge 網路模型的運作過程，透過步驟去分析到底 docker -p 的背後運作原理

Introduction

整個 DRBD 分成 kernel space 跟 user space。

本文延續之前研究 drbd 9.0 網路的工作流程，這篇文章主要在研究其 kernel space 中的行為與邏輯。

本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以瞭解每個開放出來的 Restful API 該怎麼使用。相對於文件的更新速度，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。

這篇文章用來介紹在 Fllodlight 中是如何去完成下列事情, 1)不使用 Spanning Tree Protocol 的方式也能夠正確的在有迴圈的網路拓樸中來傳輸封包，2) 針對任意兩個點對點的網路節點，能夠找到一條最短的路徑用來傳輸封。 這些事情在該控制器中，其實是透過計算一個 Tree 的方式來完成所謂的 Broadcast Tree, 藉此避免廣播風暴的問題，同時透過 Djikstra 的演算法來在拓樸中找到一個最短路徑來傳輸封包。

Floodlight把module分成core跟application兩個方向為主

在floodlight這個openflow controller中，對於module之間的執行順序是如何決定的，這部分很重要

本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以學習到其內部是如何轉送封包的，藉由 Topology 模組提供的 Global Topology 資訊, Floodlight 可以從該資訊中對於任何一個點到點的之間的連線找到一條傳送路徑。接者針對這傳送路徑上所有的交換機輸入對應的 Openflow 規則來幫忙轉送封包。相對於文件的更新，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。

本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以學習到其內部關於網路拓樸的處理，這些拓樸除了影響 Controller 怎麼看待整個網路之外，也會間接的影響該 Controoler 要如何去正確的轉送封包。相對於文件的更新，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。

探討如何於 Ceph 環境中開啟 RDMA 功能

Kubernetes 本身提供了非常多好用且方便的資源，其中專於網路存取的部分除了 Service 是常用元件以外， Ingress 也是一個熱門且重度發展的項目。本文詳細的介紹了 Kubernetes Ingress 的架構並且實際以 Nginx Ingress Controller 作為一個範例去架設測試環境。該測試環計中會實驗基於 Host 與 Path 等不同方式的路由設定，並且解釋該測試環境的運作原理，讓讀者更能夠直接瞭解到 Ingress 的運作方式。

本文作為 IPVS 系列文第一篇，主要跟大家粗略的介紹 IPVS 的概念以及相關用法，接下來會再仔細的探討一些更深層的概念，譬如實作細節以及一些使用技巧，最後再看看 Kubernetess 是如何與之互動的

本文作為 IPVS 系列文第三篇， 會從 Kernel 作為出發點，探討一下 IPVS 本身的模組概念，分享兩種不同的內建除錯方式，此外也會從原始碼的部分看一下 IPVS 初始化的過程做了哪些事情

本文作為 IPVS 系列文第二篇，主要是跟大家介紹 IPVS 與 Kubernetes 的互動，包含如何設定以及 IPVS 如何實踐 Kubernetes Service 的功能

本文作為 IPVS 系列文第四篇，主要是跟大家介紹 IPVS 於 Linux Kernel 內的架構設計，透過理解其設計更可以幫助我們去瞭解 IPVS 與 IPTABLES 的差異，面對諸如此類的探討文章更能夠有足夠的背景去思考與學習

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

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

本文探討一種備份復原過程中可能會發生的 IP 重複問題，文章開頭先用簡單的模擬方式來模擬如何產生 IP 重複問題，接下來針對 CNI 的運作來探討其運作流程。

談談 Kubernetes 的世界中如果想要用 tcpdump 抓封包可以怎麼做

淺談如何除錯 Kubernetes 中的各種網路問題

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

本篇文章透過閱讀原始碼的方式來學習 MASQUERADE 的運作模式，而 MASQUERADE 則是被廣為使用的 SOURCE NAT 模組。作為一個 IPTABLES 的擴充模組，透過觀察原始碼的方式可以學習到是如何處理相關的參數甚至，選擇來源 IP 地址以及來源連接埠等相關行為

本篇文章透過修改 MASQUERADE Kernel Module 原始碼的方式來觀察系統的變化，專注於當 NAT 功能執行前後， conntrack 這個結構的改變。透過不同的實驗與環境來觀察 1)多重 IP 的情況下怎選擇 2)指定不同參數時，連接埠的變化。此外為了簡化整體操作過程，將整個實驗環境都透過 Vagrant 打包成為一個可重複執行的環境，並且也準備好可以編譯 Kernel Module 的環境與指令。

最近突然對抓封包挺有興趣的，正好以前修網際網路規約時，有trace過linux中TCP/IP相關的code

Introduction

上一篇mininet-and-network-subnet中提到如何在mininet中創造不同subnet的網路，並且透過手動下flow的方式讓不同subnet的hosts可以互相溝通。

Introduction

VPN server is a very useful tool for your network connectivity, although there're many online VPN service around the world, it's slow speed and money cost and you can't sure they won't collect your connection data. That's why sometimes we want to build the VPN server by ourself and this porst introduce a way to setup a VPN server in your FreeBSD server.

之前在網路上看到了一篇 paper

Purpose

介紹 NAT Loopback 的概念

探討 NFQUEUE + iptables 結合後丟棄 UDP 封包的問題

對於 SDN Controller 來說，最基本的功能就是要可以傳輸封包，然而在這種集中式管理的情況下，傳統的 Spanning Tree Protocol 不會運行。因此 Controller 本身要有辦法判斷當前的網路拓墣中是否有迴圈以避免產生廣播風暴。本文會透過觀察原始碼的方式來研究在 NOX Conroller 是如何實現的。

探討如何運行 ONOS Trellis

ovs-vsctl add-port br eth1

Environment

hmap 是一種hash bucket的資料結構，在 OpenvSwitch 中到處都可以看到其身影，，譬如 kernel space 中的 flow_key 就是透過這種結構來存放的。本文會檢視一下該 hamp 的結構，並且稍微看一下關於插入這個動作的原始碼

This post shoes about what the system do when we install the OpenvSwitch in your system. The architecture of OpenvSwitch covers both user-space and kernel-space and we can see functions of each part in this porsts.

In this post, I try to study the soruce code of openvswitch to learn how does the openvswitch kernel module works.

這篇文章中，我們決定透過閱讀原始碼的方式，來瞭解 OpenvSwitch 操作上最常使用的指令，也就是 add-port 這個指令每次運行時，整個系統到底怎麼運行的。藉由閱讀原始碼的方式來釐清整個 OpenvSwitch 的架構，從 User-space 的程序到 Kerenel Space 的 Module, 這中間到底是怎麼處理的。

這篇文章帶領大家透過閱讀原始碼的方來學習如何 OpenvSwitch 是如何處理封包的，當底層的 Kernel Switch(datapath) 沒有辦法轉發封包時，要如何將該封包送到上層的 User Space Table 進行 Openflow 規則的查詢。這部份牽扯到資料如何橫跨於 User-Space 以及 Kernel-Space.

本文介紹了一種將 Contaienr 創建於 OpenvSwitch 與 DPDK 整合的網路拓墣下所遇到的連線問題。開頭先闡述了拓墣架構以及相關的軟體版本，接者介紹是如何搭建起整個測試環境，並且在測試環境中遇到了網路連線的問題，眾多的測試組合中，卻只有一種組合能夠正常的在 Container 間建立起能夠傳輸的 TCP 連線。最後透過 AB 測試的方法歸納出一些會造成問題出現的環境。

Question

探討何謂 RDMA

Introduction

Introduction

OS:Linux

這篇文章要跟大家分享在 OpenvSwitch 裡面內建的 Bonding 模式，相對於傳統 Linux Kernel 自帶的六種模式，OpenvSwitch 只有提供三種模式。這三種模式的用途以及分配的方式都完全不同，完全取決於使用者本身的環境需求，來判斷自行的環境需要採用哪種模式，有單純的 Active-backup 模式，也有 Active-Active 的模式。再 Active-Active 的模式中要如何去分配封包，可以針對 Layer2 也可以針對 Layer3/4 的環境來使用，這部份就是依賴管理員去思考的。

這篇文章主要分享如何於 Wireshark 中安裝額外的模組使得其有能力去解析 OpenFlow 的封包結構，對於研究 Openflow 的人來說這是一個很好使用的工具，能夠觀察 Switch to Controller, Controller to Switch 等各種封包.

探討 ping 指令的不同實作方式

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

本文透過 IPTABLES/EBTABLES 的規則與 Docker Container 的環境來觀察不同情況下的封包流向，主要是幫線上議程進行的重點整理，主要內容都在影片中。

作為一個 Kubernetes 使用者，可能都有聽過 CNI/CRI/CSI 等眾多的介面。而 CNI 作為一個掌管整個 Kubernetes 叢集網路的核心元件，負責提供各式各樣的網路功能。目前為數眾多的開源 CNI 專案們，到底各別擁有什麼樣的特性與效果，作為一個管理者在選擇 CNI 的時候應該怎麼考慮。本文針對常見的 CNI 專案們進行了一個簡單的分析與介紹，讓讀者能夠更加得清楚自己需要的功能及應用是什麼，才能夠更聰明的選擇所要的 CNI

從 KIND(Kubernetes IN Docker) 中學習到的一些網路小趣聞

探討 Kubernetes 架構下網路能力的不足，導入 Kubernetes 時有可能會無法解決的網路架構問題。

相信不少開始學習 SDN 的人一定都有聽過 mininet 這套軟體，甚至大量使用過。

本篇文章作為 Container 介紹的最後一篇，簡單的透過 namespace 的操作讓大家看看 network 以及 storage 本身的運行模式，接下來到 CNI 以及 CSI 相關的章節的時候會再仔細介紹 kubernetes 中是怎麼處理 network 與 storage 這兩大重要資源。