連結: https://itnext.io/how-to-set-kubernetes-resource-requests-and-limits-a-saga-to-improve-cluster-stability-and-a7b1800ecff1

今天這篇文章探討的則是 resources 底下的 request/limit 問題。 本文作者之前遇到一個非常規律的服務警告問題，花了非常多時間與步驟去查詢，最後才發現是 Pod 裡面 Resource 的設定不夠嚴謹與完善。 舉例來說， resources: limit: cpu: 1000m request: cpu: 100m 今天假設有一個服務描述，我對 cpu 的最低要求是 0.1顆，但是極限是 1顆 且有一個節點本身有 3 顆 CPU，這種情況下，我們對該服務設定多副本運行(10個). 那根據 request 的要求，10個副本頂多只需要 1 顆 cpu，所以非常輕鬆的可以將 10 個服務運行起來，但是如何今天遇到尖峰流量 ，每個 pod 都瘋狂使用 CPU會發生什麼事情？ 每個副本的極限都是 1 顆，因此 10 個副本就可以衝到 10 顆 CPU..而系統上只有 3顆，這就會造成 CPU 完全不夠使用，最後導致每個應用程式都在搶 CPU 使用，如果沒有特別設定相關的 nice 值來處理，可能會造 成關鍵 process 無法回應(案例中就是kubelet)。 這案例中 limit/request = 10x，作者認為這數字太大，它覺得合理的大概是 2x ~ 5x，並且最重要的是要定期去檢視系統上資源的用量， limit 要設定的合理，如果本身有很大量需求，建議還要搭配 node select, affinity/anti-affinity 讓每個 pod 最好找到適合的配置方式，然後也要避免尖峰流量到來時，系統資源被吃光甚至影響到 kubelet/kube-proxy 等底層服務的運作。

連結: https://medium.com/flant-com/cleaning-up-container-images-with-werf-ec35b5d46569

不知道大家有沒有遇過本地儲存空間滿了，再也抓不了 docker image 的慘痛經驗呢？ 本文就想要探討的是遠方 Container Image 上的管理問題，隨者時間演進，愈來愈多的版本產生，那作為管理者，我們要怎麼去> 看待這些 image，放任他們無限擴張嘛？ 這些資源背後都代表一個儲存空間，也就意味額外的成本開銷。 作者想要解決的問題是，如何設計一套自動機制去刪除用不到的 image tag，保留會用到的，為了解決這個問題，要先定義什麼叫做 "用得到的 image tag". 本文列舉了四種需要保留 image tag的情況 1) Production 環境正在使用的 image tag, 如果刪除了，遇到 ImagePullPolicy:Always 的情況那可真的麻煩了 2) 遇到緊急情況，應用程式需要退版，因此保留的 image tag 可不能只有當前版本，過往穩定版本也都要保留 3) 從開發角度來看需要的 image tag, 譬如我們開了一個 PR，這個 PR 有一個對應的 image tag, 再這個 PR 還沒有結束前，這個 image tag 應該都要保留讓開發者去驗證與使用 4) 最後則是特定版本號或是code name等專屬名稱 作者使用 werf 這套 k8s 建置佈署工具來幫忙，這工具除了常見的 build/deploy 外，還可以刪除遠方的 container image。 因此作者整合一套演算法，將其與 werf 整合，讓整個 CI/CD 的過程中能夠自動去產生新 的 image，並且根據需求去移除用不到的 image. 有興趣的記得點選下列原文來學習更多

連結: https://www.cncf.io/blog/2020/09/29/enforce-ingress-best-practices-using-opa/

不知道大家有沒有聽過 Open Policy Agent (OPA) 這個 CNCF 專案? 有滿多專案的背後都使用基於 OPA 的語言 Rego 來描述各式各樣的 Policy，譬如可以使用 conftest 來幫你的 kubernetes yaml 檢查語意是否有符合事先設定的 Policy。 本篇文章則是跟大家分享如何使用 OPA 來針對 Ingress 資源進行相關防呆與除錯，一個最基本的範例就是如何避免有多個 Ingress 使用相同的 hostname 卻指向不同的 backend service. 過往可能都是靠人工去維護 ，確保沒有一致的名稱，但是透過 OPA 的概念我們可以再佈署 Ingress 到 Kubernetes 前先進行一次動態的比對，確保當前設定符合所有 Policy，得到所謂的 Approved 後才能夠佈署進去。 有興趣的人可以看看這篇文章，甚至學習一下 OPA 的使用方式

連結: https://lwn.net/Articles/835962/

LWN.net 這幾天有一個文章是關於基於安全性考量下，改用其他工具取代 scp, 譬如使用 sftp 以及 rsync. 有常常使用 scp 這個工具的人可以看一下這篇文章討論的原因，以及如果要改成使用 rsync, 可以有什麼樣的參數使用

連結: 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 的一種工具 這篇文章從頭開始介紹如何整合上述工具，並且完成一個簡易的範例，透過這些範例也讓你理解每個元件對應的功能，如何使用，共重要的是從一個大範圍的視角來看，這些元件的地位，更可以幫助你瞭解整體架構 有興趣的可以閱讀全文

連結: 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 來測試，畢竟輕量化且同時支援多節點，環境也乾淨，測試起來也方便。

連結: 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) 有顯著的提升，有興趣的可以看看下列兩篇文章

連結: 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) 如何真正有效的隔離這些租戶 如果有這方面的需求，可以先看看別的開源軟體怎麼實作，再來思考是否滿足需求，如果要自己實現，有哪些好的設計值得參考!

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

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

• https://rancher.com/.../rancher-2-5-delivers-computing...
• https://github.com/rancher/fleet
• https://fleet.rancher.io/
• https://github.com/rancher/rancher/issues/23239

2. 針對美國環境要求而開發更具安全性的發行版，符合 FIPS(Federal Information Processing Standars)
3. 整合 GitOps 部署，針對大規模 Edge 叢集的自動部署解決方案 fleet
4. Monitoring 強化，減少與 Rancher 本身的連接性，反而更加使用 Prometheus operator 來提供服務。管理人員可以直接創建相關的 CRD 提供服務，而這些資訊也都會被 Rancher UI 給一併呈現 其中 (4) 裡面還提供的 cluster-level 的客製化設定，就不需要向過往一樣要開很多個 project-level 的 prometheus 來處理，這方面輕鬆不