Skip to main content

87 posts tagged with "Reading"

View All Tags

· 2 min read
HungWei Chiu

連結: https://adam-toy.medium.com/implementing-gitops-on-kubernetes-using-k3s-rancher-vault-and-argocd-f8e770297d3a

這邊跟大家分享一篇 GitOps 實作心路歷程，這篇文章中總共使用下列工具

  1. AWS, 所有環境都基於 AWS 此 cloud provider
  2. K3S, 一套由 Rancher 開發的輕量級 Kubernetes 發行版本
  3. Rancher, 管理 K3S 介面
  4. Cert-Manager, 與 Let's Encrypt 連動，管理相關憑證
  5. Vault, Secret 管理工具
  6. ArgoCD GitOps 使用工具，連動 Git Repo 與 K8s
  7. Terraform, IaaC 的一種工具 這篇文章從頭開始介紹如何整合上述工具，並且完成一個簡易的範例，透過這些範例也讓你理解每個元件對應的功能，如何使用，共重要的是從一個大範圍的視角來看，這些元件的地位，更可以幫助你瞭解整體架構 有興趣的可以閱讀全文

· 2 min read
HungWei Chiu

連結: https://www.dex.dev/dex-videos/development-clusters

不知道大家第一次接觸 kubernetes 的時候都是使用哪套解決方案來打造你的 K8s 叢集？ 亦或是作為一個開發者，你平常都怎麼架設 K8s 來本地測試? 這篇文章提到了作為一個 Local Kubernetes Cluster 幾個選擇，並且點出了三個需要解決的問題

  1. Container Registry, 作為一個開發環境，應該不會想要每次測試都要將 Container Image 給推到遠方，譬如 dockerHub, Quay，這樣整體效率低落
  2. Builder, 如何有效率的幫忙建置你的應用程式，並且與 Kubernete 整合，讓開發者可以更專心於本地開發，而不要擔心太多 k8s 之間的設定 https://www.dex.dev/dex-videos/development-clusters
  3. Runtime, 底層使用哪套 Container Runtime, 譬如 docker/containerd/cri-o 註: 我個人對第三點其實沒太多感覺，不覺得本地測試這個會影響太多 後面列舉了當前知名的相關專案，譬如 KIND, K3D, MicroK8S, Minikube 以及 Docker for desktop. 並且簡單的比較了一下這些本地開發的差異。 不知道大家平常本地開發時，都會用哪一套? 我個人是比較常使用 KIND 來測試，畢竟輕量化且同時支援多節點，環境也乾淨，測試起來也方便。

· 2 min read
HungWei Chiu

連結: https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/

今天要來跟大家分享一個單一節點如何提高應用程式吞吐量與服務能力的方式 這個方式主要探討的是應用程式對於網路連線的 I/O 模型，試想一個常見的使用範例。 一個主要的 Process 會去聽取一個固定的 port number (ex port 80)，並且通知後面眾多的 worker 來幫忙處理這些封包連線，而這些 worker 的工作就是處理連線。 整個架構中是一個 1 v.s N 的狀況， 一個負責 Listen ，N個負責處理連線內容 而今天要分享的則是想要讓架構變成 N v.s N 的狀況， 會有 N 個 Process, 每個 Process 配上一個 Worker。 而這 N個 process 同時共享一樣的 Port (ex, port 80) 這種情況下可以減少多個 worker 共享一個 listen socket 時的各種保護機制，取而代之的則是每個 listen socket 配上一個專屬的 worker 來處理。 要達成這樣的架構非常簡單，只要透過 SO_REUSEPORT 這個 socket option 告 訴 Kernel 當前這個 PORT 可以重複使用。 當封包送到 kernel 後則是由 kernel 幫你分配封包到所有使用相同地址的 Listen Socket (Process) 根據 nginx 官方文章的測試，這種架構下對於 RPS (Request per second) 有顯著的提升，有興趣的可以看看下列兩篇文章

· 5 min read
HungWei Chiu

連結: https://faun.pub/kubernetes-multi-tenancy-a-best-practices-guide-88e37ef2b709?gi=6e43dc5ed7a

這邊跟大家分享一篇關於 Kubernetes 多租戶的相關文章，該文章中探討到底多租戶的定義，以及實現上的難易程度

  1. 多租戶可分成軟性與硬性兩種隔離， Kubernetes namespace 可以視為軟性隔離，而硬性隔離則是希望能夠更強力的隔離所有資源，文章中提到了 vClusters 的概念，連結放在最後
  2. 作者認為多租戶的 Kubernetes Cluster 實際上也會帶來一些限制，讓某些功能變得不方便使用。 a. 基於 namespace 的租戶隔離方式就只能大家都同樣一個 k8s 版本，同時有一些支援 RBAC 設定的 Helm Chart 可能就不方便使用。
  3. 作者這邊反思提出一個問題，為什麼真的需要多租戶的 Kubernetes 叢集，不能夠用多個單一租戶的 Kubernetes 叢集來取代? a. 真的有這樣的實例，但是其實成本過高且沒效率。 b. 如果公司內每個開發人員都需要一個自已的 k8s來操作測試，規模一大的話你每個月的成本非常可觀，因此如果可以有一個多租戶的 k8s，就可以解決這些問題
  4. 多租戶實作上的挑戰，作者這邊列出幾個問題，包含使用者管理，資源分配以及如何隔離 a.基本上每個組織本身都已經有管理使用者的解決方案，譬如 AD/LDAP 等，如果要將這些使用者的認證授權與 kubernetes 整合，推薦使用 dex 這個支持 OpneID/OAtuth2 的解決方案，幫你將 Kubernetes 與外> 部資料系統整合 b. 底層資源的共享，避免單一租戶過度使用導致其他租戶不能使用。資源包含了運算資源，網路頻寬等。作者列出透過 Resource Quotas 等可以幫忙限制運算資源，但是並沒有說出網路頻寬這部份該怎麼處理。> 這部份我認為需要導入更多的network qos解決方案來限制，應該會需要cni以及外部交換機路由器等來幫忙 c. 最後則是互動上的隔離，要如何確保這些多租戶不會互相影響彼此，甚至攻擊彼此。這部份可能要從 NetworkPolicy 來處理網路流量，同時透過 vCluster的方式來提供相對於 namespace層級更強烈的隔離，確 保彼此不會互相影響。
  5. 最後，作者列出了一些關於多租戶的可能解決方案，包含了 kiosk, loft等 結論來說就是，今天你如果有多租戶的需求，請先問自己，你需要什麼等級的多租戶管理，再來則是三個重點問題要先想清楚，你要怎麼處理 1) 如何管理使用者/租戶 2) 系統資源要如何分配與限制 3) 如何真正有效的隔離這些租戶 如果有這方面的需求，可以先看看別的開源軟體怎麼實作，再來思考是否滿足需求，如果要自己實現，有哪些好的設計值得參考!

· 2 min read
HungWei Chiu

連結: 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 去編輯內容的時候，到底該怎麼更新。

· 3 min read
HungWei Chiu

連結: 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 來處理，這方面輕鬆不

· One min read
HungWei Chiu

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

· One min read
HungWei Chiu

連結: 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 與其他網友針對這些議題的討論，並且分享看看你的想法

· One min read
HungWei Chiu

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

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