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

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

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

今天這篇文章來分享 knative 這套 Kubernetes 內的 serverless 解決方案
該文章分成幾個部分
1. 什麼是 Serverless, 帶來的好處是什麼
2. 什麼是 knative，該專案的特色有什麼
3. 透過實際範例，安裝 knative 到你的 kubernetes cluster 中，並且透過一個簡單的 golang 應用程式來展示 knative 是如何運作的

作者認為 serverless 最大的好處就是可以讓開發者專心寫程式，不需要考慮太多底層的架構，譬如說什麼是 Kubernetes，如果要部署我寫的程式，我應該怎麼做
Knative 該專案基於 Kubernetes而開發，希望能夠提供簡單且靈活的 serverless 解決方案。

採用 Knative 的話，開發者可以專心寫程式，並且使用一行指令去部署你的程式到 Kubernetes 中， Knative 會幫你把剩下的事情完成，譬如創建相關的 Deployment/Service/Ingress 這些資源。

Knative 收到相關創建請求時，本身並不會馬上創建相關資源，反而是等到該應用程式第一次被呼叫時，才會開始創建相關資源，同時也能夠根據當前的流量而自動調整需要的 instance 數量。藉由這個機制可以提供更好的資源管理

對於該專案有興趣的，記得點選下列連結觀看全文來瞭解更多

https://medium.com/better-programming/go-serverless-on-kubernetes-with-knative-b3aff3dbdffa

兩年前開始有個想法，想把 PTT 套上 HBase 的架構，再加上 cache, LB, HA 的機制，應該可以讓 PTT 再戰三十年。

主要是覺得 PTT 現在還是用 file-based 的方式在處理資料，其實比較不便於搜尋，資料毀損時要復原也比較麻煩。再加上現在一大堆透過 PTT 抓資料的爬蟲，如果有 API 可以取得的話，就不用像現在暴力拉資料，消耗一些不必要的資源。

用 HBase 有另個好處，優良的 rowkey 設計會大幅增加讀寫效能，小編現在就可以想到對於文章跟推文的幾種設計方式了 XDDD

其實當初開這個 issue 的時候，站長 @wens 也提出一些看法，像是其實有很多方式可以改進目前的儲存結構，只不過缺少時間跟資源，還有一些老舊的程式碼要整理，真的是一個大工程啊！

也有看到一些其他的實作，像是 @clkao 整合 zmq，@livinginportal 打算要用 golang 來改寫之類的。

無論如何，還是希望有志之士能夠一起來改善 PTT 啊！！！

* 小編之前提出的 HBase 導入 issue：https://github.com/ptt/pttbbs/issues/2
* @clkao 的 zmq 整合：https://github.com/clkao/pttbbs
* @livinginportal 改寫 PTT 的討論串：https://github.com/ptt/pttbbs/issues/5

#ptt #hbase