標題: 「K8s 1.27: 如何加速你 Pod Startup 的階段」
類別: Others
連結: https://kubernetes.io/blog/2023/05/15/speed-up-pod-startup/


本篇是官方部落格文章，而本篇內容主要是探討當今天 k8s 叢集量很大且瞬間有很多個 Pod 要被部署到同一個節點上時，要如何提升整體的 Startup 時間。
有部份提到的功能要到 1.27 才出現，甚至可能是 alphe 的設定。

1. 開啟 Parallel Container Image Pulls

預設情況下 kubelet 是採取依序下載的策略，這意味假設同時有多個 Pod Image 需要下載，那就會陷入排隊狀況，只有等待當前下載完成才會開始下載下一個 Image

此功能開啟後就可以讓 Kubelet 平行的去載多個 Container Image，藉此可以避免其他的 Pod都卡在等待時間

此外開啟此設定還要特別注意上限值問題，官方建議根據你遠方 Registry 的設定去調整到底 Kubelet 最多一次可以抓多少個 Container Image

以下就節錄大綱，詳細內容請點選文章閱讀

2. 提升 kubelet 與 API Server 溝通的瓶頸 (API Query-per-second)
3. 調整 Pod 的資源(limit) 用量 (memoryThrottlingFactor)
4. k8s 1.26 後還有新增一個新的 histogram metric, pod_start_sli_duration_seconds 可以用來幫助團隊來偵測這些啟動時間

標題: 「如何用 KubeGreen 夜晚關服務幫你省錢」
類別: Kubernetes
連結: https://medium.com/@sourabp/a-new-way-to-save-idle-kubernetes-cost-kube-green-ecb01372b448

如果有使用雲端託管 K8S 的玩家一定會瞭解大部分的收費方式都是基於底層 VM 來收費
VM 本身又可透過 Cluster Autoscaling(CA) 的方式來自動增減。
而 CA 的觸發條件跟 VM 本身的資源用量以及運行 K8s Pod Resource Request 的量有很大的關係

因此如果想要省錢就要從 K8s Pod Resource Request 下手調整，減少 VM 資源被 Request 的量最後達到減少 VM 的效果。

本篇文章要介紹的工具為 Kube Green, 其邏輯很簡單，就是透過排程的方式於特定的時間內將 deployment/cronjob 等 workload 調整讓其產生的 Pod 數量為 0。
讓夜晚用不到的服務下限藉此減少整體資源的 Request 總和就有機會觸發 CA 的運作去減少 VM 的數量，最後達到省錢的效果

標題: 「一個困擾一個多月的 DNS 網路問題」
類別: Kubernetes
連結: https://medium.com/adevinta-tech-blog/its-not-always-dns-unless-it-is-16858df17d3f

本篇文章作者分享的是一個與網路長期抗戰的學習歷程，團隊從客戶那邊發現定期會有網路相關，作者團隊開始從各種 Metrics 去研究看看問題發生時是否可以找到任何蛛絲馬跡
最初懷疑是 Ingress Controller 這邊效能不夠，同時因為 HPA 的問題使得 HPA 的數量會各種變動，同時也看到有 CPU Throttling 的現象發生，因此懷疑可能跟 Ingrss Controller 的效能有關，簡單調整 CPU Limit 與部署數量來修復，然而問題卻沒有任何改善

由於此問題頻繁出現，作者團隊就開始認真面對該問題，開始仔細鑽研，最後歸納出應該跟 DNS 有關聯，但是有關聯不代表解決問題，還是要找到這個問題到底為什麼跟 DNS 有關以及要如何解決

Kubernetes 內有 CoreDNS 的機制，而部分叢集為了提升 DNS 效能同時減少 CoreDNS 的負擔，都會透過 local resolver 的架構去部署一個 local DNS 作為 Cache 使用，因此團隊認為問題應該跟這個 local resolver 有關。

團隊接下來發現了相關問題並且嘗試解決，但是每次問題過一段時間就會以不同的形式出現
1. Local DNS (DNS Masq) 有連線上限，最多同時只能有 150 DNS Request
2. Missing Caches， CoreDNS 某個版本升級後導致預設情況下 DNS Masq 沒有辦法把 CoreDNS 的結果給存放到 local cache，所以導致整個效能下降
3. ndots 問題使得每個 DNS 請求都會產生超多用不到的 DNS Rquest，而這些封包也就佔據了大量的流量最終使得 DNS 效能出問題

修復這一切問題後，CoreDNS 收到的 DNS 數量從 4000/s直接降到 1000/s 左右，而所有功能都可以正常運作，這意味可能過往有 75% 的封包都是無意義的，因此修正 ndots 的問題實際上可以非常有效的提升 CoreDNS 的效能

文章中有探討所有除錯的步驟，問題發生點以及思考方式，非常推薦所有維運人員都要仔細看一次，並且一起記住當網路中出現奇怪問題時， "it's always DNS"

標題: 「Alpine Linux Image 的各種小問題」
類別: Kubernetes
連結: https://martinheinz.dev/blog/92

作者的這篇文章探討的是為什麼其不再繼續使用 Alpine 作為 Container Image 的基底，其列出幾個問題

1. 使用 musl 而非常見的 glibc

作者提到使用 musl 最大的問題就是其處理 DNS 的問題，除了 Bug 外其天生也不支援 DNS over TCP，大部分時間下使用 UDP 來查詢 DNS 都不會有太多問題，然後就有用過 Alpine + K8s 的人可能都有遇過 Pod 平常跑得好好的，突然天外飛來一筆 "Unknown Host"，而且隨機發生沒有任何跡象與模式可以研究。
Kubernetes 官方文件也直接表明 Alpine 3.3 以前的版本都有 DNS 的問題，不過作者連使用 3.16 也都有踩到這個問題，所以遠離 Alpine 如果不想要哪天被 DNS 問題踩雷的話。

2. 由於 Alpine 使用 musl，所以如果你的程式語言/相關函式庫底層很依賴標準 C 函式庫的話，你很有可能會發現 Alpine 上的運作結果跟你想像的不同，這種情況就要轉換使用基於 Alpine 環境所編譯的套件或是需要自己重新編譯
整個過程會搞得容器化變得複雜也麻煩。

作者文章中舉例了 Python, Node.JS, Golang 中都有些許官方套件是直接依賴底層 C 語言的實作，而使用上都有可能會踩到一些奇妙的問題

文章最後作者提及幾個可以取代 Alpine 的相關 Image，不過我想現在應該愈來愈多人使用 distroless 而非 Alpine 了吧?

標題: 「Pod Topology Spread 使用上的注意事項」
類別: Kubernetes
連結:https://medium.com/wise-engineering/avoiding-kubernetes-pod-topology-spread-constraint-pitfalls-d369bb04689e

談到如何讓 Kubernetes 去控制調度節點時，常見的方式有
1. NodeSelector
2. Taint/Toleration
3. Node Affinity
4. Inter-Pod (Anti)/Affinity
5. Pod Topoology Spread

其中 (1) 是早期開發的產物，其用途簡單設定單純，因此後來透過 (3) 可以完全取代 (1) 的用法，並且有更多細微的設定來處理。

當環境中有所謂 Zone/Regional 等概念時，很多人就會想要確保高可用性，即 Pod 本身部署的時候應該要避免全部放到同一個籃子中，因此這時候可能就會透過 Inter-Pod Anti Affinity 等機制來打散這些 Pod，讓他們可以散落到不同的 Zone 中以確保任何 Zone 發生意外時，線上服務所屬的 Pod 都還有副本可以繼續處理。

然而上述這些概念本身探討的都是調度選擇節點的資格，本身沒有太多跟數量有關的決定，有可能會發現 Pod 的分佈不夠均勻打散的結果，因此後來又有 Pod Topology Spread 這新 API 的發展，旨在解決不均勻分布的問題。

本篇文章就是跟大家介紹一下 Pod Topology Spread 的概念並且實際使用上可能會遇到的雷點以及要如何避免

標題: 「The future of Terraform must be open」
類別: Terraform
連結: https://medium.com/gruntwork/the-future-of-terraform-must-be-open-ab0b9ba65bca


本篇文章的作者是 Gruntwork 的 co-founder，該公司著名的產品為 Terragrunt 以及 Terratest，由產品可知該公司對於 Terraform 一定有非常深刻且獨到的見解，所以本篇文章的內容更值得好好閱讀審思，一個 Terraform 專家是怎麼看待 Terraform 的未來與發展

文章內頭開頭就是直接探討最近 HashiCorp 針對其產品調整授權的議題，從 MPL v2 轉換到 BSL v1.1，作者認為這種授權對於 Terraform 整個生態系以及未來發展都是一個毒丸，而作者團隊因應這個則推出了 OpenTF 這個致力於讓 Terraform 永遠開源的計畫。

文章內容很多，基本上都是針對 MPL 授權對於 Terraform 生態系帶來的幫助與正向發展以及為什麼 BSL 會毀了這一切。

心得: 一言難盡，看看紅帽近期對 RHEL 近期的更動，不同角色不同視野很難一概而論，作為曾經開源專案公司的開發者，其實對開源文化真的心情複雜，畢竟幫你繳房租的不是使用者數量，是錢啊...

標題: 「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 威武?

標題: 「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 數量但是效能依然不如預期的，不如參考看看本篇文章

標題: 「細探 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 的設定來調整回報與偵測時間

標題: 「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 更加順暢，特別是網路連線的部分會減少更多瞬斷的情況。

標題: 「以 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

標題: 「探討 GitOps 下常見的 Git Repo 結構」
類別: Kubernetes
連結: https://hwchiu.medium.com/introduction-fdf73f6e012b

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

標題: 「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 寫死到該路徑的記得要處理一下，不然就會發生各種套件安裝不了

標題: 「比較 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...等。

標題: 「如何調整系統使得 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.

標題: 「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 版本有更多的改善

標題: 「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 使用量快照的方式，透過快照保存所有用量以便日後分析任何資安或是用量問題。

標題: 「如何於 ArgoCD 中打造多租戶的需求」
類別: Kubernetes
連結: https://medium.com/@geoffrey.muselli/argocd-multi-tenancy-strategy-94d72183c94

本篇文章探討的是當 ArgoCD 落地逐漸成熟且使用者愈來愈多，這時候該有效地管理各團隊的使用方式與相關權限
其探討的 ArgoCD 中的
1. Projects
2. RBAC
3. ApplicationSet
這些已知元件如何組合可以達到讓租戶有自己的 namespace 與對應的權限控管

標題: 「初探 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 的設定。

標題: 「三大公有雲 Kubernetes 詳細比較表」
類別: Kubernetes
連結: https://medium.com/@mohamed.benhassine/comparing-the-top-three-managed-kubernetes-providers-gke-eks-aks-5fa90d06c063

作者於文章內去比較 AKS/EKS/GKE 三個平台的差異，從 Kubernetes 的功能到雲端相關如LB 等各種比較，並且透過一張表列出所有差異，一目了然

標題: 「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 的人可以看一下新版功能有哪些可以改善當前工作流程的