0%

[閱讀筆記] - Week 3

terraform,Terraform Module 依賴性討論

Ref: https://medium.com/hashicorp-engineering/creating-module-dependencies-in-terraform-0-13-4322702dac4a

Terraform 這個工具想必大家都玩過也聽過,這邊非常推薦大家升級到 0.13 版本,這個版本中解決了關於 Module 之間依賴性的問題,能夠使用原先就有的 depends_on 的語法來直接描述,而不需要按照過往以前用各種 fake resource 等機制來完成,整個 Terraform 程式碼會更佳清晰與簡單!

CRD 與 Operator 的探討

Ref: https://twitter.com/ibuildthecloud/status/1295810776179961856?fbclid=IwAR3zVNFSodC-PK7JBUDA63vNONwrovxJP7qBvaTtq735dWonROlD5xWN13s

想必大家應該都聽過 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 與其他網友針對這些議題的討論,並且分享看看你的想法

Java 應用程式於容器內的效能問題

Ref: 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 來讓其能夠更高效率的於容器化環境下工作

Rancher v2.5 Release

Ref: https://www.suse.com/c/rancher_blog/rancher-2-5-delivers-on-computing-everywhere-strategy/

Rancher v2.5 版本與過往的差異,這邊就來重點節錄一些改變

  1. 強化與雲端環境 EKS 與 輕量級 K3s 環境的整合,此外宣稱所有 Kubernetes 服務上面都可以安裝 Ranche 用其來幫忙管理
    Rancher v2.5 釋出!
    這幾天 Rancher 正式釋出 v2.5 版本,這邊就來重點節錄一些改變
  2. 強化與雲端環境 EKS 與 輕量級 K3s 環境的整合,此外宣稱所有 Kubernetes 服務上面都可以安裝 Ranche 用其來幫忙管理
  3. 針對美國環境要求而開發更具安全性的發行版,符合 FIPS(Federal Information Processing Standars)
  4. 整合 GitOps 部署,針對大規模 Edge 叢集的自動部署解決方案 fleet
  5. Monitoring 強化,減少與 Rancher 本身的連接性,反而更加使用 Prometheus operator 來提供服務。管理人員可以直接創建相關的 CRD 提供服務,而這些資訊也都會被 Rancher UI 給一併呈現
    其中 (4) 裡面還提供的 cluster-level 的客製化設定,就不需要向過往一樣要開很多個 project-level 的 prometheus 來處理,這方面輕鬆不少
    資料來源:
  1. 針對美國環境要求而開發更具安全性的發行版,符合 FIPS(Federal Information Processing Standars)
  2. 整合 GitOps 部署,針對大規模 Edge 叢集的自動部署解決方案 fleet
  3. Monitoring 強化,減少與 Rancher 本身的連接性,反而更加使用 Prometheus operator 來提供服務。管理人員可以直接創建相關的 CRD 提供服務,而這些資訊也都會被 Rancher UI 給一併呈現
    其中 (4) 裡面還提供的 cluster-level 的客製化設定,就不需要向過往一樣要開很多個 project-level 的 prometheus 來處理,這方面輕鬆不少

Kubernetes manageFields 討論

Ref: https://github.com/kubernetes/kubernetes/issues/90066?fbclid=IwAR3d3oXBtTz2ChxmqXQmLGIrghUxN3Tz67EYWZiuzNfltqVedAlFheg3qLA

如果你機會跑過 kubernetes 1.18 版本,一定要試試看最基本的 kubectl get pods -o yaml,看看是不是內容裡面多出了非常多 f:{} 系列的檔案,導致整個 Yaml 變得非常冗長,閱讀不易,甚至想要抓取到最原始的內容都非常麻煩。
Kubernetes 官方 Github 上還有相關的 issue 再討論這個欄位,詢問是否有辦法能夠清除。不少人都提出了一些希望的用法來處理
Issue: https://github.com/kubernetes/kubernetes/issues/90066
目前看下來最簡單的做法還是透過 kubectl plugin, kubectl-neat 來幫忙完成,可以透過 krew 這個 kubectl 管理工具來安裝管理
https://github.com/itaysk/kubectl-neat
此工具可以將 Server 上得到 Yaml 的內容給整理最後得到最初的檔案
至於到底什麼是 managedFiles? 這個由欄位的出現是因為 1.18 以後,已經將 Server Side Apply 更新策略預設啟用而導致的,而 Server Side Apply 則是一種用來管理 Declarative 設定檔案的方式,對使用者來說基本上完全無感,因為一切都還是透過 kubectl apply 來使用,只是到底如何判斷 當前檔案內容與系統上內容誰先誰後,誰對誰錯,甚至當有人透過 kubectl edit 去編輯內容的時候,到底該怎麼更新。

個人資訊

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

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

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

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

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

Welcome to my other publishing channels