關於 docker 網 路 模式 ，我們在網路上蒐集到這些相關的討論、資訊與評價

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 給分開來。

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

本文延續前篇效能校正的經驗談，上篇文章探討了關於應用程式本身可以最佳化的部分，包含了應用程式以及框架兩個部分。本篇文章將繼續剩下最佳化步驟的探討。

Speculative Execution Mitigations
接下來探討這個最佳化步驟對於效能有顯著的提升，但是本身卻是一個非常具有爭議性的步驟，因為其涉及到整個系統的安全性問題。
如果大家對前幾年非常著名的安全性漏洞 Spectre/Meltdown 還有印象的話，本次這個最佳化要做的就是關閉這類型安全性漏洞的處理方法。
標題的名稱 Speculative Execution Migitations 主要跟這漏洞的執行概念與 Pipeline 有關，有興趣理解這兩種漏洞的可以自行研究。

作者提到，大部分情況下這類型的防護能力都應該打開，不應該關閉。不過作者認為開關與否應該是一個可以討論的空間，特別是如果已經確認某些特別情境下，關閉防護能力帶來的效能如果更好，其實也是一個可以考慮的方向。

舉例來說，假設今天你運行了基於 Linux 使用者權限控管與 namespaces 等機制來建立安全防護的多使用者系統，那這類型的防護能力就不能關閉，必須要打開來防護確保整體的 Security Boundary 是完整的。 但是如果今天透過 AWS EC2 運行一個單純的 API Server，假設整個機器不會運行任何不被信任的程式碼，同時使用 AWS Nitro Enclaves 來保護任何的機密資訊，那這種情況下是否有機會可以關閉這類型的檢查?

作者根據 AWS 對於安全性的一系列說明認為 AWS 本身針對記憶體的部分有很強烈的保護，包含使用者之間沒有辦法存取 Hyperviosr 或是彼此 instance 的 Memory。
總之針對這個議題，有很多的空間去討論是否要關閉，以下就單純針對關閉防護能力帶來的效能提升。

作者總共關閉針對四種攻擊相關的處理能力，分別是

Spectre V1 + SWAPGS
Spectre V2
Spectre V3/Meltdown
MDS/Zombieload, TSX Anynchronous Abort
與此同時也保留剩下四個，如 iTLB multihit, SRBDS 等
這種設定下，整體的運作效能再次提升了 28% 左右，從 347k req/s 提升到 446k req/s。

註: 任何安全性的問題都不要盲從亂遵循，都一定要評估判斷過

Syscall Auditing/Blocking
大部分的情況下，Linux/Docker 處理關於系統呼叫 Auditing/Blocking 兩方面所帶來的效能影響幾乎微乎其微，不過當系統每秒執行數百萬個系統呼叫時，這些額外的效能負擔則不能忽視，如果仔細觀看前述的火焰圖的話就會發線 audit/seccomp 等數量也不少。

Linux Kernel Audit 子系統提供了一個機制來收集與紀錄任何跟安全性有關的事件，譬如存取敏感的機密檔案或是呼叫系統呼叫。透過這些內容可以幫助使用者去除錯任何不被預期的行為。
Audit 子系統於 Amazon Linux2 的環境下預設是開啟，但是本身並沒有被設定會去紀錄系統呼叫的資訊。

即使 Audit 子系統沒有真的去紀錄系統呼叫的資訊，該子系統還是會對每次的系統呼叫產生一點點的額外處理，所以作者透過 auditctl -a never,task 這個方式來將整體關閉。

註: 根據 Redhat bugzilla issue #1117953, Fedora 預設是關閉這個行為的

Docker/Container 透過一連串 Linux Kernel 的機制來隔離與控管 Container 的執行權限，譬如 namespace, Linux capabilities., cgroups 以及 seccomp。
Seccomp 則是用來限制這些 Container 能夠執行的系統呼叫類型

大部分的容器化應用程式即使沒有開啟 Seccomp 都能夠順利的執行，執行 docker 的時候可以透過 --security-opt seccomp=unconfined 這些參數告訴系統運行 Container 的時候不要套用任何 seccomp 的 profile.

將這兩個機制關閉後，系統帶來的效能提升了 11%，從 446k req/s 提升到 495k req/s。

從火焰圖來看，關閉這兩個設定後，syscall_trace_enter 以及 syscall_slow_exit_work 這兩個系統呼叫也從火焰圖中消失，此外作者發現 Amazon Linux2 預設似乎沒有啟動 Apparmor 的防護，因為不論有沒有關閉效能都沒有特別影響。

Disabling iptables/netfilter
再來的最佳化則是跟網路有關，大名鼎鼎的 netfilter 子系統，其中非常著名的應用 iptables 可以提供如防火牆與 NAT 相關功能。根據前述的火焰圖可以觀察到，netfilter 的進入 function nf_hook_slow 佔據了大概 18% 的時間。

將 iptables 關閉相較於安全性來說比較沒有爭議，反而是功能面會不會有應用程式因為 iptables 關閉而不能使用。預設情況下 docker 會透過 iptables 來執行 SNAT與 DNAT(有-p的話)。
作者認為現在環境大部分都將 Firewall 的功能移到外部 Cloud 來處理，譬如 AWS Security Group 了，所以 Firewall 的需求已經減少，至於 SNAT/DNAT 這類型的處理可以讓容器與節點共享網路來處理，也就是運行的時候給予 “–network=host” 的模式來避免需要 SNAT/DNAT 的情境。

作者透過修改腳本讓開機不會去預設載入相關的 Kernel Module 來達到移除的效果，測試起來整體的效能提升了 22%，從 495k req/s 提升到 603k req/s

註: 這個議題需要想清楚是否真的不需要，否則可能很多應用都會壞掉

作者還特別測試了一下如果使用 iptables 的下一代框架 nftables 的效能，發現 nftables 的效能好非常多。載入 nftables 的kernel module 並且沒有規則的情況下，效能幾乎不被影響(iptables 則相反，沒有規則也是會影響速度)。作者認為採用 nftables 似乎是個更好的選擇，能夠有效能的提升同時也保有能力的處理。

不過 nftables 的支援相較於 iptables 來說還是比較差，不論是從 OS 本身的支援到相關第三方工具的支援都還沒有這麼完善。就作者目前的認知， Debian 10, Fedora 32 以及 RHEL 8 都已經轉換到使用 nftables 做為預設的處理機制，同時使用 iptables-nft 這一個中介層的轉換者，讓所有 user-space 的規則都會偷偷的轉換為底層的 nftables。
Ubuntu 似乎要到 20.04/20.10 的正式版本才有嘗試轉移到的動作，而 Amazon Linux 2 依然使用 iptables 來處理封包。

下篇文章會繼續從剩下的五個最佳化策略繼續介紹

https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

--課程已於 2020 年 10 月更新 --
如果你厭倦了學習如何部署 Web 應用程式，這是你的課程。
這是你夢想中學習如何部署任何網路應用程式的終極課程。 和 Kubernetes 是 Dev Ops 世界中最新的技術，並且戲劇性地改變了 Web 應用程式的建立和部署流程。 Docker是一種允許應用程式執行在稱為容器結構中的技術，而 Kubernetes 允許許多不同的容器進行協調執行。
✅ Docker 從頭開始學習！
在這門課程中，你將從絕對的基本知識中學習 Docker，從學習諸如”什麼是容器?”這樣的基本問題的答案開始 和”集裝箱是如何運作的?” . 從最開始的幾次演講開始，我們將深入研究集裝箱的內部運作，這樣你就可以核心理解它們是如何被實現的。 一旦你瞭解了什麼是容器，你就會學習如何使用基本的 Docker CLI 命令來處理它們。 在這之後，你將應用你對 Docker CLI 的新發現的掌握，來建構自己的自定義映像檔，有效地’Dockerizing’ 你自己的個人應用程式。
✅ CI + CD 管道
當然，如果沒有對持續整合和持續部署模式的全面理解，Docker 上的課程就不會完整。 你將學習如何使用 Github，Travis CI 和 Amazon Web Services 來實現一個完整的 CI + CD 工作流程，建立一個每次向 Github 推送最新更改時自動部署程式碼的管道(pipeline)！
✅ 多容器在 AWS 上的部署！
在構建一個部署管道之後，你將在 Amazon 網路服務上應用它來管理單個容器和多容器部署。 你將使用 Node、 React、 Redis 和 Postgres 建構一個多容器應用程式，看看容器在執行中的神奇力量(注意: 本課程中的所有 Javascript 程式碼都是可選的，如果不想編寫 JS，則提供完整的原始碼)。
✅ Kubernetes！
最後，你將處理 Kubernetes，這是一個用於管理多個不同執行容器的複雜應用程式的營運等級系統。 你將學習建構 Kubernetes 叢集的正確方法——這門課程沒有那些令人討厭的”不要在生產環境中這樣做”的評論！ 你將首先在本地機器上建構一個 Kubernetes 叢集，然後最終將其移植到雲端提供程式。 你甚至可以學習如何在 Kubernetes 上設定 HTTPS，這可比聽起來難多了！
下面就是你要做的:
1. 從零開始學習 Docker，不需要以前的經驗
2. 根據你的應用程式建立自己的自定義映像檔
3. 掌握 Docker CLI 來檢查和除錯執行的容器
4. 瞭解 Docker 是如何在幕後工作的，以及集裝箱(容器)是什麼
5. 使用 Github，Travis CI 和 AWS 一起從頭開始構建 CI + CD 管道
6. 當程式碼被推送到 Github 時自動部署它！
7. 從頭開始建構一個複雜的多容器應用程式並將其部署到 AWS
8. 瞭解 Kubernetes 的用途和理論
9 .將一個可營運的 Kubernetes 群集部署到 Google Cloud 中

https://softnshare.com/docker-and-kubernetes-the-complete-guide/