本文延續前篇效能校正的經驗談，上篇文章探討了關於Locality與中斷中可以最佳化的部分，。本篇文章將繼續剩下最佳化步驟的探討。

The Case of the Nosy Neighbor
從前述最後的火焰圖中，作者觀察到幾個跟網路有關的 kernel call，譬如 dev_queue_xmit_nit 以及 __netif_receive_skb_core 等有可能有成長的空間，於是輾轉前往這邊去研究。
作者觀察到 packet_rev 這個函式有不少的比例，而該函式的意思是有人嘗試透過使用 AF_PACKET 等方式開啟了 RAW socket 來處理封包。透過 ss 這個指令，作者觀察到系統中有其他的應用程式透過 AF_PACKET/SOCKET_RAW 也在處理封包，最後輾轉發現原來是系統上的 dhclient。

DHCP Client 必須要在系統有 IP 以前就有收送封包的能力，所以使用 AF_PACKET 也滿合理的。作者思考是否有辦法可以讓 DHCP Client 拿到 IP 之後就關閉 AF_PACKET，改使用純 UDP 的方式來進行後續的 DHCP Renewal 功能，可惜這個方向沒有辦法達成。

根據 AWS 的官方文件，當一個 IP 被分配到一個機器後，這個 IP 會跟該機器同生死，因此這種情況下 其實不需要透過 DHCP Renewal 來反覆取得 IP，只要取得一次 IP 即可。

作者變修改相關腳本，當 DHCP 取得 IP 後關閉 dhclient，此外還必須要記得去修改網卡層級關於該 IP 的記憶，預設期間是一小時，作者將其修改為永遠。

透過這樣簡單的設定，整體的效能又再度提升了 6%，從 1.06M req/s 提升到 1.12M req/s

The Battle Against the Spin Lock
作者陳述自己花了非常多時間與 Spin Lock(作者心魔的大白鯨) 奮戰，幾乎是茶不思飯不想的滿腦都在思考如何加速，然後再經歷過反反覆覆的失敗後，作者最後決定還是要寫出一些關於 Spin Lock 的嘗試與研究心得，算是一個很精彩的踩雷心得。

這部分的篇幅很長，而且內容也滿深的，最後的解決方式也只有提升 2%左右的效能，所以對這部分有興趣的讀者再自行閱讀囉

This Goes to Twelve
終於來到最後的最佳化步驟了，這個步驟中的範疇都只能勉強壓榨出些許的效能，包含了關閉 GRO, TCP壅塞控制以及靜態中斷處理。

(Generic Receive Offload)GRO 是一個網路相關的功能，目的是用來將 Kernel 層級的封包給聚合起來變成一個大封包，而 Kernel 收到這個封包後會把該大封包重新組合變成本來的小封包，對於使用者的應用程式來說不會有任何感覺，但是對於整體的封包傳輸來說能夠節省花費的並提升效能。大部分情況下這個功能都是開啟的，Amazon Linux 2 預設也是打開這個選項。
然而針對作者的測試情境，由於所有的封包基本上都是同一條連線且資料量也不大，因此 GRO 雖然可以帶來聚合的效果，但是也會拖延封包進入到 Linux Kernel Network Stack 的時間點，因此開啟 GRO 帶來的好處沒有很大。

TCP 壅塞控制有不同的演算法，Amazon Linux2 內建兩種演算法 Cubic 以及 Reno，除此這兩個之外常見的還有 Google 多年前貢獻的 BBR。根據作者測試，其實驗環境中有比較好效能的則是 Reno

註: 不同算法針對不同應用場景，所以要切換演算法前要先釐清自己的應用情境以及用哪種演算法比較合適。

全部零零總總的修改後提升了 4%，整體的效能服務來到了 1.2M reqs/s

這篇文章真的很長，有些最佳化的方式是針對該應用場景而特別去使用的，這也意味者並非所有的修正方式都可以套用到各位的應用程式。
本篇文章還是很值得一讀，整個分析的思路與想法都非常有趣，雖然不一定用得到但是也許未來有一天會有機會使用。

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

原文在這邊: https://www.teamblind.com/post/50-Reasons-Kubernetes-Sucks-S77O8VZ8

不知道大家看完有什麼想法

我個人認真看完後其實覺得真的是幹樵而已，可以單純當作幹話發洩文就好。有些理由沒什麼前後文，不知道想要表達什麼，有些感覺就是剛好自己踩到通點，基本上任何的軟體架構都可以有類似的議題

稍微看了一下
1. 難道你跑 openstack 就沒有這個感覺嗎? 我自己經驗是更痛苦
2. API 不相容這點我倒覺得還好，沒有遇到特別嚴重的，基本上 k8s 都會給予4-5個版本要使用者替換 apiVersion, 不看警告訊息無腦使用不能怪人
3. charts的問題應該是 Helm Charts 的問題，我倒覺得不是 k8s 自己的問題，不喜歡 charts 何不考慮 kustomize.
4,5 兩個應該是軟體發展一定會遇到的問題，任何系統遇到環境升級都是膽戰心驚吧?
9. 不確定是不是 kubectl 輸入到手酸XD，可以考慮 k9s?
10,11 最後談
13. 為什麼你會有一個兩年不升級的k8s叢集才是一個問題? 不如反過來問，如果你覺得兩年不升級沒問題，為什麼會突然想要升級
14. golang 中槍
19. 我覺得還是可以慢慢看，openstack 等VM為主題的 orchestration 實在是太不平易近人，學習曲線太高
...
32(a). 不太能理解 pause container 的問題是什麼XD，除非最小單位變成 Container 而不是 Pod，不然 Pause 的用途我還沒想到要怎麼取代
32(b). 完全同意， secret 帶來的好處只有透過編碼讓文件內容好處理，可以避掉一堆雙引號，分號等問題

10 跟 11 分別幹瞧了 overlay network 與 service mesh 兩個解決方案的痛點，我覺得很有趣的是這兩個點分別是從不同層面來解決問題。

早期大家碰到 Kubernetes 時都可能使用過 Flannel 這套 CNI，大部分情況下都是急於 VXLAN 來建置 overlay network，透過 UDP 標頭來重新包裝封包並且利用 Layer2,3,4 來重新搭建整個架構網路，是一個專注於底層網路L2-L4的解決方案

目前的 Service Mesh 的則是專注於 L7 的網路傳輸，期望能夠打造出一個串連不同 L7 應用程式的服務，譬如 HTTP,gRPC 等，讓這些應用程式的流量會根據不同 L7 的設定而有不同走法與走向。
只是為了轉發這些不同容器間的封包，最快速的做法就是大量利用已知的架構(iptables,route)等機制來控制各別網路連線，我覺得帶來的缺點就是架構非常龐大，規則非常複雜，大家除錯方式就是不停 restart/reboot，很少人真的能夠講清楚到底每個封包是怎麼被修改的

網路的世界真的非常有趣!

根據Netscout指出，網路上有超過3萬臺Windows RDP伺服器，需要特別注意有被濫用的風險，因為他們的研究人員已經觀察到，當UDP/3389埠啟用後，攻擊者可利用這些RDP伺服器來進行UDP反射/放大攻擊，而且，攻擊者可以發送偽造的UDP封包，讓RDP伺服器反射到DDoS攻擊的目標。

該業者並建議，以VPN連線存取RDP伺服器，或是關閉以UDP/3389啟動RDP服務