0%

[閱讀筆記] - Week 1

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 主要新功能,包含了

  1. Topology Manager (Beta)
  2. Service Side Apply (Beta)
  3. 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 帶來了三大好處:
  1. Reliability: 包含提供請求重試、超時、金絲雀部署(Traffic shifting/splitting) 等功能
  2. Observability: 包含提供請求成功率、延時、粒度到個別服務等級的請求量、個別服務等級路由、服務等級拓墣圖等功能
  3. 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

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

Welcome to my other publishing channels