原文在這邊: 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，很少人真的能夠講清楚到底每個封包是怎麼被修改的

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