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
你的捐款將給予我文章成長的動力