ref: https://medium.com/swlh/quick-fix-sharing-persistent-disks-on-multiple-nodes-in-kubernetes-ef5541fd8376

這篇文章是 kubernetes 與 Storage 整合的經驗分享文，該文章包括了下列內容
Cloud Storage, NFS, Kubernetes, PV/PVC.

Kubernetes 內針對這些儲存相關的使用方式有
1. 使用 ephemeral 的儲存設備
ephemeral 只適合暫存資料使用，因為該儲存設備不是持久保存的，這意味 Container 如果重啟，資料就會消失。
2. 使用 Bind Mount 的方式將資料從節點掛載到容器中
就如同過往使用 Docker 時會使用 -v 的方式將同節點中的儲存目錄給掛載到容器中來使用。

基本上有任何永久性儲存的需求都會採用(2) 這個方式來處理，而目前很多 Cloud Provider 都有提供相關的儲存裝置讓你的 VM(k8s Node)
可以輕鬆存取與使用。

舉例來說，AWS 有 EBS， GCP 有 GPD，這類型的 Block Storage Device 本身支援動態掛載與卸載，所以就算 Kubernetes 將目標 Container 重新部署到
不同節點上也不需要擔心資料會不同，因為這些 Storage 可以隨者不同節點動態掛載上去，讓你的 Container 看到相同的資料。
但是以上兩個裝置都有一個限制，就是並不支援同時多人寫入的動作，於 Kubernetes 只能使用 Read/Write 模式。
這意味每個 Storage 同時只能有一個 Container 去進行讀寫操作(but Azure 的服務就沒有這個限制)

作者假設今天有一個服務底層是由三個元件組成，這些元件會需要針對相同一個資料集一起處理。
舉例來說有服務 A,B,C
A: 將資料寫入到儲存系統中
B: 從儲存系統中讀入資料進行二次處理，處理完畢再寫回去儲存系統中
C: 將資料從儲存系統中讀出並且供外部使用

上述情境簡單說就是一個儲存設備，會有三個服務同時想要讀取，一個專心寫，一個同時讀寫，一個專心讀。
這種需求就沒有辦法單純使用 EBS/GPD等裝置來使用，因此作者接下來就會針對如何使用 NFS 這套網路儲存系統來搭建一個符合上述需求的用法。
該解決方案流程如下
1) 透過 EBS/GPD 的方式掛載一個儲存空間到 k8s 節點中
2) 部署一個 NFS Server 的容器到 Kubernetes 中，該 NFS Server 會使用 EBS/GPD 作為其儲存空間的來源
3) NFS Server 透過 service 分享服務
4) 部署 PV/PVC 物件到 Kubernetes 中
5) A,B,C 三種容器透過 PVC 的方式來存取 NFS Server

因為 NFS 本身就是一個可多重讀寫的解決方案，作者透過這種方式讓多個應用程式可以同時讀寫，同時將這些資料保存到 EBS/GPD 的儲存空間中。
不過這種用法帶來的問題可能就是速度問題，從同節點直接存取變成透過網路存取，所以如果本身對於存取有非常高的頻寬需求時，使用這種解決方案也許會遇到
很難解決的瓶頸，畢竟大部分人的 k8s 叢集都是 data/control 兩種資料交雜於底層的網路架構中，沒有辦法將 data plane/control plane 給分開來。

有興趣看作者如何一步一步搞定上述流程的可以參考全文

今年終於有時間來寫一個原創的長篇文章了，希望大家繼續支持

不知道大家有沒有想要透過 tcpdump 去錄製 Kubernetes 內Pod的封包但是常常卡關的情況？

今天這邊文章跟大家分享兩種不同的思路
1. 從封包內去錄製封包
2. 從節點上去錄製封包

針對第一點會探討三種方式，包括 kubectl sniff 以及 docker run 直接硬掛 network namespace。
第二種方式則會探討如果是 Flannel 以及 Calico 不同的網路架構下，要如何找到對應的虛擬網卡 (veth)。

如果你有任何不同的方式可以幫忙錄製封包也歡迎討論分享

https://www.hwchiu.com/k8s-tcpdump.html