連結: https://mucahit.io/2020/01/27/finding-ideal-jvm-thread-pool-size-with-kubernetes-and-docker/
如果有在 Kubernetes 內部署 Java 應用程式的人,千萬不要錯過這篇文章,此文章中分享 Java 應用程式關於 Thread Pool Size 的問題,同時當 Java 應用程式容器化並且部署到 Kubernettes 內之後,該怎麼設定 JVM 來讓其能夠更高效率的於容器化環境下工作
連結: https://mucahit.io/2020/01/27/finding-ideal-jvm-thread-pool-size-with-kubernetes-and-docker/
如果有在 Kubernetes 內部署 Java 應用程式的人,千萬不要錯過這篇文章,此文章中分享 Java 應用程式關於 Thread Pool Size 的問題,同時當 Java 應用程式容器化並且部署到 Kubernettes 內之後,該怎麼設定 JVM 來讓其能夠更高效率的於容器化環境下工作
想必大家應該都聽過 Operator 的概念,透過 CRD 自定義資源格式並且配上程式化的運作邏輯來控管相關資源的操作。甚至有廠商針對 Operator 的概念來設計一個 Framework 讓大家能夠更輕鬆或是有效率的撰寫屬> 於自己的 Operator。 然而 Operator 真的一定好嗎? 底下這則推文則是來自於 Darren Shepherd(CTO/Co-founder Rancher Lab ) 對於一篇由 RedHat 所發表關於 Operator 好處文章的反面看法。 其推文最後表示:「Right now invest your IT teams time in GitOps, not operators.」 快來看看 Darren 與其他網友針對這些議題的討論,並且分享看看你的想法
連結: https://medium.com/hashicorp-engineering/creating-module-dependencies-in-terraform-0-13-4322702dac4a
Terraform 這個工具想必大家都玩過也聽過,這邊非常推薦大家升級到 0.13 版本,這個版本中解決了關於 Module 之間依賴性的問題,能夠使用原先就有的 depends_on 的語法來直接描述,而不需要按照過往以前用> 各種 fake resource 等機制來完成,整個 Terraform 程式碼會更佳清晰與簡單!
連結: https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/
想必大家一定都有使用過 CPU Limit 的經驗,透過這個機制能夠確保每個 Container 使用的 CPU 資源量,也可以保證每個節點上面會有足夠 CPU 供 Kubernetes 原生服務 (kubelet) 使用。 然而本篇文章就要來跟大家分享一個設定 CPU Limit 反而造成效能更差的故事,故事中當 CPU 設定為 800ms 的時候,卻發現實際運行的 Container 最高大概就只有 200ms 左右,這一切的一切都是因為 Liniux Kernel 的臭蟲導致! 一個直接的做法就是針對那些本來就沒有過高 CPU 使用量服務取消其 CPU Limit,作者於文章中也探討了一些機制要如何保護與應對這些被移除 CPU 限制的服務。 這個臭蟲於 Linux Kernel 4.19 後已經修復,但是要注意你使用的發行版本是否有有包含這個修復,作者列出一些已知的發行版本修復狀況 Debian: The latest version buster has the fix, it looks quite recent (august 2020). Some previous version might have get patched. Ubuntu: The latest version Ubuntu Focal Fosa 20.04 has the fix. EKS has the fix since December 2019, Upgrade your AMI if necessary. kops: Since June 2020, kops 1.18+ will start using Ubuntu 20.04 as the default host image. GKE: THe kernel fix was merged in January 2020. But it does looks like throttling are still happening.
連結: https://www.hwchiu.com/docs/2020/cni-performance-2020
連結: https://teamt5.org/tw/posts/container-escape-101/
這篇分享一篇非常有趣的問題,從 Container 的實作開始介紹,最後介紹幾個與 Container 相關的 CVE 對於資安有興趣的可以研究看看
連結: https://www.facebook.com/technologynoteniu/posts/125741595926648
本篇文章列出了七個企業想要踏入 Cloud Native 之路上最常遇到的問題 以下幫大家總結並節錄一點小內文
連結: https://buoyant.io/service-mesh-manifesto/
一篇關於 Service Mesh 的好文,發布已經有段時間了不過還是值得一讀, 文章作者是非常早期 Service Mesh 項目: Linkerd 的核心開發成員之一也是新創公司 Buoyant 公司的 CEO 相信大家應該對於 Service Mesh 一詞已經不陌生,可能對於這個名詞比較熟悉的朋友大多是從另一個 Service Mesh 項目: Istio 去了解 Service Mesh 的面貌,從這篇文章你可以從不同觀點認識 Service Mesh , 全文非常長內容涵蓋:
連結: 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 衝突 有興趣的人可以研究看看
連結: https://medium.com/swlh/amazon-eks-upgrade-journey-from-1-17-to-1-18-e35e134ca898
這邊跟大家分享一篇 EKS 升級的心得文章,該文章記錄了 EKS 從 k8s 1.17 到 1.18 的過程,並且先分享了幾個 1.18 主要新功能,包含了