矽谷牛的耕田筆記

這篇文章是來自 Medium 的官方技術文章，稍微探討了一下其內部如何使用 Kubernetes 的，整體是偏向 high level 的角度，因此不會有太多細節 1. Production 環境是建立於 4 個 AZ 上 2. 使用 Terraform 以及其他內部自行搭建的軟體來管理 3. 使用 cluster-overprovisioner 來提早部署節點以因應服務資源的變動需求 4. 其他細節可以看文章內容 https://medium.engineering/kubernetes-infrastructure-at-medium-d9e2444932ef?gi=531e0733b35c

有趣的小專案，幫你掃出所有孤兒資源，特別是那些根本沒有被人用的 configmap, RBAC, PVC, HPA ... 等，不確定目前還有沒有其他的好工具可以瞬間掃出這些孤兒 https://github.com/yonahd/kor

根據華爾街日報 (WSJ) 的報導顯示， GitHub Copilot 努力虧損中，目前使用者付費是每個月$10美金，但是實際上對微軟來說卻是虧損$20左右 Copilot 目前約有 150 萬使用者，所以每個月粗估虧損 3000萬美金 推測也許未來會有 MS 365 Copilot 大概要花 $30 來提供服務以彌補虧損 另外跟文章中想到的 Bing Chat, Bing Image Creator 目前也都是免費的服務，這樣下去應該不久就要全面邁入使用者付費的行列的？ https://www.thurrott.com/cloud/290661/report-github-copilot-loses-an-average-of-20-per-user-per-month

仔細一看是打算採用藍綠部署來解決兩個版本之間升級的過渡期 以 Kubernetes 來說，原生沒有支援藍綠部署的機制，所以原生做法大抵上都會跟文章內一致，部署兩個版本並且透過 Ingress/Service 等機制來切換流量，粗暴但可行 如果採用 Argo Rollout 的話可以把這些步驟給簡化並且透過 Portal 的方式一目瞭然目前的更新版本狀況。 若要採用原本 Rolling Upgrade 升級的話，其實也有很多參數需要調整，包含 1. Strategy 裡面的 MaxUnavailable /MaxSurge-> 每次升級同時間可以減少/新增的 Pod 2. TerminationPeriod -> 有些應用程式預設30秒停不住，需要提升以確保關機前已經釋放所有資源 3. PDB -> 平常用不到，但是遇到 Node Drain 機制時也要能夠確保 Pod 不會一口氣被踢掉太多 4. 考慮到多節點跨多區域的情況下，適當的 Pod Affinity 或是 PodSpreadConstraint 可能都需要導入來確保 Pod 的分配是均勻或是如預期的 https://medium.com/@a.j.abbott24/kubernetes-zero-downtime-release-pattern-942223d6bad3

看到一個號稱快速幫你搭建一個 Production-Ready Kubernetes Cluster 的開源專案，比較直得看一下的是他心目中所謂的 Production-Ready 應該會包含哪些專案 從架構圖來看，看起來會有 1. ArgoCD，搞定 GitOps & Application 2. Nginx + Cert-Manager 搞定 Certificate + Ingress 3. Vault + External Secrets Operators-> Secret 4. ChartMuseum -> 放 Helm Chart 5. Terraform + Atlantis -> Terraform automation 6. Argo Workflows -> For CI 7. Container Registry -> ECR/Gitlab/GItHub 根據不同環境 (Local, AWS ...etc) 他會採取不同的整合但是基本元件還是盡量以上述為主 不過我想 ChartMuseum 也應該會慢慢被 OCI Registry 給汰換掉了，畢竟連 Harbor 也要將其從內部移除，為了都走 OCI 的格式即可 https://docs.kubefirst.io/

標題: 「ArgoCD v2.9 要來了！」 類別: Kubernetes 連結: https://medium.com/argo-project/argo-cd-v2-9-release-candidate-a1e256d01017 ArgoCD v2.9 Release 即將到來，其中包含 32 新功能以及 26 舊有 bug 的修復 1. 重新強化 Shard 功能的使用體驗，過往為了解決單一控管叢集資源量過大導致 ArgoCD 運作起來緩慢的情況， ArgoCD 引入了 Shard 的概念讓你可以部署多副本的 ArgoCD Controller 來水平處理請求，而過往這些流程牽扯到不少手動操作。 v2.9 則嘗試提供更為自動的機制來處理 Shard 的處理 2. 針對 ApplicationSet 提供了 Difference 的功能，讓產生出來的 Application 都可以繼續保留 Differences 來避免各種 re-sync 等狀態不一致的問題 3. 強化 ApplicationSet 設定下，使用 SCM Provider(Gitlab) 的使用體驗 文章中還有列出一些小改進，譬如 1. 補齊 External Secrets 專案中 PushSecret 物件的健康狀態檢查 2. 補齊 AnsibleJob CRD 的健康狀態檢查 3. ApplicationSet 支援 AzureDevOps Webhooks 有大量使用 ArgoCD 的人可以看一下新版功能有哪些可以改善當前工作流程的

標題: 「三大公有雲 Kubernetes 詳細比較表」 類別: Kubernetes 連結: https://medium.com/@mohamed.benhassine/comparing-the-top-three-managed-kubernetes-providers-gke-eks-aks-5fa90d06c063 作者於文章內去比較 AKS/EKS/GKE 三個平台的差異，從 Kubernetes 的功能到雲端相關如LB 等各種比較，並且透過一張表列出所有差異，一目了然

標題: 「初探 Kubernetes 1.28 Sidecar Container 新功能」 類別: Kubernetes 連結: https://medium.com/p/ed1a39ac7fe0 Sidecar Container 一直以來都是 Kubernetes 部署的一種常見模式，將主要與 Sidecar 容器部署到相同 Pod 來提供更多功能，常見的如 1. Network Proxy: Service Mesh(istio) 等都是基於此模式處理 2. SQL Proxy: GKE 上面透過 Cloud SQL Proxy 來存取 GCP Cloud SQL 3. Logger: 針對那些改不動的應用程式，去轉發或是轉換其輸出日誌 對 Kubernetes 來說，這兩種容器(主要/Sidecar)都是容器的一種，因此其管理上一視同仁，特別是生命週期等都完全一樣。 這情況反而對實作上造成一些困擾，主要是這些 sidecar 容器都是為了輔佐主要容器而活，但是運行順序上卻沒有辦法保障，因此 若是運氣不好導致運行順序有差錯，可能就會發生主要容器無法連線導致失敗，需要等待下次容器重啟才可以正常運行 Kubernetes 於 1.28 正式從內部提供 Sidecar Container 的支援，完全不同的生命週期管理，從 initContainer 出發去設定來確保 Sidecar Container 的使用更符合情境，減少過往各種 Workaround 的設定。

標題: 「如何於 ArgoCD 中打造多租戶的需求」 類別: Kubernetes 連結: https://medium.com/@geoffrey.muselli/argocd-multi-tenancy-strategy-94d72183c94 本篇文章探討的是當 ArgoCD 落地逐漸成熟且使用者愈來愈多，這時候該有效地管理各團隊的使用方式與相關權限 其探討的 ArgoCD 中的 1. Projects 2. RBAC 3. ApplicationSet 這些已知元件如何組合可以達到讓租戶有自己的 namespace 與對應的權限控管

標題: 「Analyzing Volatile Memory on a Google Kubernetes Engine Node」 類別: Kubernetes 連結: https://engineering.atspotify.com/2023/06/analyzing-volatile-memory-on-a-google-kubernetes-engine-node/ 本篇文章是 Spotify 官方技術部落格的文章，主要探討該團隊如何使用 AVML, dwarf2json 以及 Volatility3 等工具整合打造出一套能夠針對節點上所有行程 Memory 使用量快照的方式，透過快照保存所有用量以便日後分析任何資安或是用量問題。

標題: 「k8s 1.28: Beta support for using swap on Linux」 類別: Kubernetes 連結: https://kubernetes.io/blog/2023/08/24/swap-linux-beta/ 最早期學習 K8s 並且使用 kubeadm 安裝的時候，一定都會遇到要將 swap 關閉的情況，否則 kubelet 就沒有辦法順利運行起來。 原因主要是關於記憶體控制方面會有些衝突，而這個問題於 k8s 1.22 時正式提出了相關開關來解決，該功能於 1.28 正式標示為 BETA 版本，並且將較於 1.22 Alpha 版本有更多的改善

標題: 「如何調整系統使得 EMQX 可以支援 1M 連線」 類別: Kubernetes 連結: https://www.infracloud.io/blogs/scale-emqx-one-million-connections-kubernetes/ 本篇文章雖然有提到 MQTT 以 EMQX 相關的東西，不過更大的重點是文章後半部分如何最佳化系統來支援更多連線數，提到非常多 sysctl 下關於網路會用到的設定，譬如 fs.file-max, fs.nr_open, net.core.somaxconn ...等各種設定 另外也要注意的是， systctl 下並不是每個設定都有 namespace 的概念，這意味有些設定是 by pod，有些是 by node.

標題: 「比較 Prometheus Thanos Mimir VictoriaMetrics」 類別: Kubernetes 連結: https://sennasemakula.medium.com/evaluating-monitoring-solutions-prometheus-thanos-mimir-victoria-metrics-6bf9f4f9d602 本篇文章從多個角度去比較 Open source metrics solution 之間的差異，Prometheus 眾所皆知非常有名，但是本身的架構與設計使得它本身很難有 HA 等架構，因此後續就有各式各樣的專案以相容 Prometheus 為基準提供更多維運方面的功能，不論是 HA, remote object storage...等。

標題: 「Kuberentes 即將於明天關閉過往的 Package Repository」 類別: Kubernetes 連結: https://kubernetes.io/blog/2023/08/31/legacy-package-repository-deprecation/ 今年八月左右時 Kubernetes 官方宣布要將用來維護 Debian/PRM 相關套件的伺服器轉移至 pkgs.k8s.io，並且將逐漸替換掉過往使用的 "apt.kubernetes.io" 與 "yum.kubernetes.io". 而 09/13 也是正式關閉過往 apt.kubernetes.io/yum.kubernetes.io 的日子，所有安裝服務都要改到使用 pkgs.k8s.io 來使用。 有任何 script 寫死到該路徑的記得要處理一下，不然就會發生各種套件安裝不了

標題: 「探討 GitOps 下常見的 Git Repo 結構」 類別: Kubernetes 連結: https://hwchiu.medium.com/introduction-fdf73f6e012b 隨者 K8s + GitOps 愈來愈流行，許多團隊與組織都試圖導入並且使用，然而一樣的概念卻會隨者團隊規模/架構/基礎能力不同/目標而產生出不同的實作方式，光是採用何種方式維護 K8s 物件以及 Git Repo 要怎麼規劃就有各種變化。 雖然這種問題永遠都不會有最佳解，本文則紀錄與收集看過的一些案例與方式來探討規劃整個架構時需要探討與注意的部分。

標題: 「以 EKS + VPC CNI 為範例來理解封包流向」 類別: Kubernetes 連結: https://medium.com/@olexandr.pochapskiy/journey-of-the-web-request-from-a-laptop-to-containerized-application-9f6ea4211bb9 本文的主軸非常直觀，就是探討以 AWS VPC CNI + AWS LB + EKS 的環境下，客戶端的網路請求一路上是如何到達 K8s 上面的 Pod

標題: 「Kubernetes 1.28 重點整理」 類別: Kubernetes 連結: https://medium.com/@seifeddinerajhi/kubernetes-1-28-new-features-for-sidecar-containers-jobs-and-proxies-1c30315243e9 本篇文章簡單整理 1.28 的幾個新功能，詳細內容請點選連結細閱 1. User Namespace -> 讓 Container & Host 的 User 系統是完全獨立的， Container 內的 Root 其實是 host 上的普通使用者 2. sidecar contaienr 改進 -> sidecar container 的模式非常好用，但是實務上處理這些 sidecar container 的生命週期有點麻煩，因此系統中正式加入 sidecar container 的概念，只要對 init container 加上一個 "restartPolicy: Always"， kubernetes 就會將其視為 sidecar container 並且會有特別的管理方式，減少你管理上的麻煩 3. Rolling Upgrade -> 不少關於 kube-proxy 的 bug 被修正，使得 rolling upgrade 更加順暢，特別是網路連線的部分會減少更多瞬斷的情況。

標題: 「細探 Kubernetes 如何偵測節點損壞以及如何快速處理節點上的 Pod」 類別: Kubernetes 連結: https://medium.com/@hwchiu/handling-pods-when-nodes-fail-4daae20213b 本篇文章基於 Kubernetes & Kubelet & Controller Manager 之間來探討當節點損壞時，要花少時間該節點才會被判定為 NotReady，有哪些參數可以調整來加速整個過程，以及當問題發生時，這些 Pod 要花多少時間才會被重新調度。 簡易結論: 1. 預設情況下，最快需要 40 秒去偵測節點故障 2. 預設情況下，每個 Pod 可以於故障節點上存活 500 秒 3. 預設情況下，一個 Pod 最快需要 540 秒才可以從故障節點中被重新部署 4. Pod 可以透過 Taint-Based Evicition 的方式來調整反應時間 5. 節點可以透過 kubelet + controller manager 的設定來調整回報與偵測時間

標題: 「Grafana Loki 效能調整大補帖」 類別: O11y 連結: https://itnext.io/grafana-loki-performance-optimization-with-recording-rules-caching-and-parallel-queries-28b6ebba40c4 本篇文章探討 Loki 的基本架構並且以 Recording Rules, Caching 以及 Parallel Queries 等三種不同的方式來提升整體速度 如果對於使用 Loki 且只會單純不停提升 Pod 數量但是效能依然不如預期的，不如參考看看本篇文章

標題: 「ArgoCD + Argo Rollout 使用者調查報告」 類別: Kubernetes 連結: https://blog.argoproj.io/cncf-argo-cd-rollouts-2023-user-survey-results-514aa21c21df 這篇是今年七月由 Argo 官方所分享的使用者報告，主要聚焦於 ArgoCD 與 Argo Rollouts 的使用者情況 簡單摘要一下數字 1. 調查報告收到的回應數為 155 份 2. 每個調查內有回應的數量則不同，因此細部資料還是要點選全文去觀看每個類別的分析 ArgoCD 1. Net Promoter Score(NPS, 淨推薦值)為 76 2. 93% 的報告都顯示已將 ArgoCD 導入正式環境 3. 使用者有 45% 為 DevOps Eng, 25% 為 Platform Eng, 13% 為 Architecture, 5% 為 SW 4. 超過 75% 的生產環境使用者已經使用超過 6 個月，更有 28.4% 的使用者超過兩年 5. 77% 使用者的 Argo Instnace 是 1~5 座，有 11.2% 超過 10 座 6. 16% 的使用者用 Argo 管理超過 500 個應用程式 Argo Rollouts 1. 今年度是第一次收集 Rollout 的 NPS 資料，數值為 35 2. 使用者有 29% 為 DevOps Eng, 29% 為 Platform Eng, 15% 為 Architecture, 15% 為 SW 3. 19% 的使用者還在研究嘗試觀望，超過 47% 的使用者已經使用超過六個月 4. 75% 管理的應用程式小於 50 個，有 5% 的則是超過 2000 個 5. 搭配使用的 traffic 管理系統中，前三名為 Nginx, Istio, AWS ALB Argo 威武?