kubectl-view-allocations

Ref: https://github.com/davidB/kubectl-view-allocations

我認為非常好用的專案，可以一眼看出目前運行應用所消耗的資源
對於規劃 Resource Limit 來說是個滿好的開始，畢竟要先瞭解自己的服務會用到多少資源，也才會有一個底去思考到底你的 soft/hard limit 要設定多少

stern

Kubernetes 支援多副本資源運行，特別是當這些資源是透過 Deployment/ReplicaSet 產生時，名稱中間都會包含者不易閱讀的字串。這種情況下要如何快速且方便的讀取多副本 logs?
除了使用原生 kubectl 加上 –all-containers=true 參數來處理外
這邊跟大家分享其他開源工具，分別是 kail , stern, k8stail 以及 kubetail
有任何使用經驗跟心得都歡迎分享!
https://github.com/wercker/stern
https://github.com/boz/kail
https://github.com/dtan4/k8stail
https://github.com/johanhaleby/kubetail

Amazon EKS Upgrade Journey From 1.17 to 1.18

Ref: https://medium.com/swlh/amazon-eks-upgrade-journey-from-1-17-to-1-18-e35e134ca898

這邊跟大家分享一篇 EKS 升級的心得文章，該文章記錄了 EKS 從 k8s 1.17 到 1.18 的過程，並且先分享了幾個 1.18 主要新功能，包含了

Topology Manager (Beta)
Service Side Apply (Beta)
Pod Topology Spread (Beta)
… 等
詳細升級過程看起來無痛輕鬆，有興趣的可以參考全文
當然升級 K8S 最重要的還是要注意 Resource 的 API 版本是否有變，譬如 1.16 就讓很多人採到 Deployment 使用 extensions/v1beta1 的錯誤，所以每次升級請先檢查有沒有哪些過舊的 API 版本被丟棄，以免升級後現有的服務部屬不上去
題外話： ingress 如果還是使用 extensions/v1beta1 的話，建議都換成 networking.k8s.io/v1beta1 (k8s 1.14+), 到了 1.22 後本來的 extensions/v1beta1 就不能用囉

GitOps 帶來的痛點與反思

Ref: https://www.hwchiu.com/gitops-bad-and-ugly.html

這次跟大家分享一個有趣的反面議題，探討 GitOps 部署策略所帶來的痛點與負荷，本文主要內容翻譯自 Container-Solutions 的原始文章，已獲得原作者同意
原作者列出了數個實際採用 GitOps 遇到的麻煩與痛點，並講述期望的解決方案，最後則提供了一些不同的開源軟體來讓大家去嘗試
如同我不停強調的就是沒有最好的解決方案，只有最適合你環境的解決方案，我們要培養的一直都是如何分析自己的情境，找到對的工具並整合，一昧的追求最新最潮流的東西往往不會是最穩定且最有用的。
有興趣的人可以點選本文內的連結來瞭解更多原作者的思考

How to enforce Kubernetes network security policies using OPA

Ref: https://www.cncf.io/blog/2020/09/09/how-to-enforce-kubernetes-network-security-policies-using-opa/

不知道大家是否都有使用 Network Policy 來設定 Kubernetes 內部的 ACL?
這邊有個叫做 OPA 的工具可以用幫你驗證你的 Network Policy 是否運作良好，甚至當有新的應用服務要部署的時候，也會確定是否有跟 Network Policy 衝突
有興趣的人可以研究看看

The Service Mesh

Ref: https://buoyant.io/service-mesh-manifesto/

一篇關於 Service Mesh 的好文，發布已經有段時間了不過還是值得一讀，文章作者是非常早期 Service Mesh 項目: Linkerd 的核心開發成員之一也是新創公司 Buoyant 公司的 CEO
相信大家應該對於 Service Mesh 一詞已經不陌生，可能對於這個名詞比較熟悉的朋友大多是從另一個 Service Mesh 項目: Istio 去了解 Service Mesh 的面貌，從這篇文章你可以從不同觀點認識 Service Mesh ，全文非常長內容涵蓋：

Service Mesh 詳盡介紹
為什麼 Service Mesh 可以被施行？
為什麼 Service Mesh 是個好的 idea (比起其他方法)？
Service Mesh 幫助了什麼？
Service Mesh 有解決掉所有問題嗎？
為什麼在現今 Service Mesh 可以被施行？
為什麼人們那麼愛談論 Service Mesh？
身為一個謙虛的開發者需要關注 Service Mesh 嗎?
一系列F&Q
這裡對 Service Mesh 的需求做個小結，Service Mesh 帶來了三大好處：

Reliability: 包含提供請求重試、超時、金絲雀部署(Traffic shifting/splitting) 等功能
Observability: 包含提供請求成功率、延時、粒度到個別服務等級的請求量、個別服務等級路由、服務等級拓墣圖等功能
Security: ACL 及 Mutual TLS (客戶端及服務端互信）
值得一提的是，本篇作者 William Morgan 對於 istio 持負面的態度，並不是因為 istio 與 linkerd 處於競爭關係的兩個產品，而是對於 istio 在 service mesh 做了太多的商業性 marketing 操作（大部分來自Google的操作)
有興趣的朋友也可以在 Podcast 上聽到作者在 Podcast 上的訪談: https://reurl.cc/N6GbW9

個人資訊

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程，歡迎有興趣的人參考並分享，裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外，歡迎按讚加入我個人的粉絲專頁，裡面會定期分享各式各樣的文章，有的是翻譯文章，也有部分是原創文章，主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來，裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力

Hwchiu Learning Note

[閱讀筆記] - Week 1