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

看到一個號稱快速幫你搭建一個 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/

仔細一看是打算採用藍綠部署來解決兩個版本之間升級的過渡期
以 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

根據華爾街日報 (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

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

這篇文章是來自 Medium 的官方技術文章，稍微探討了一下其內部如何使用 Kubernetes 的，整體是偏向 high level 的角度，因此不會有太多細節

1. Production 環境是建立於 4 個 AZ 上
2. 使用 Terraform 以及其他內部自行搭建的軟體來管理
3. 使用 cluster-overprovisioner 來提早部署節點以因應服務資源的變動需求
4. 其他細節可以看文章內容

https://medium.engineering/kubernetes-infrastructure-at-medium-d9e2444932ef?gi=531e0733b35c

來自 Cloudflare 的技術文章，非常特別是文章進去有繁簡版本可以直接閱讀

文章摘要為
1. Cloudflare 以 Rust 重新打造名為 Pingora 的 HTTP Proxy
2. 效能比 Nginx 更好
3. 探討 Nginx 原生 worker(process) 運作模式的缺點以及為什麼「重複連線使用」的表現會非常差
4. Nginx 原生的模型不容易客製化功能，採用 Lua 效能不好且非靜態語言
5. 多方考量後決定自行打造一個屬於自己的 HTTP Proxy，採用 Thread 為基礎已達到共有效的共用資源。
6. 結果論: CPU 減少70%, 記憶體減少 67%




Ref: https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/

過往本地開發家打包 Container Image 普遍採用 docker 的方式來打包，而本篇文章則是要介紹一個發展也很久的工具 Buildpacks，比較一下兩者的優缺點以及什麼情況下適合使用 Buildpacks


https://medium.com/itnext/replace-dockerfile-with-buildpacks-f7e435ad2bfc

隨者 Kubeval 本底開發效率降低後而生的新專案 Kubeconform，很多概念都源自於 Kubeval 但是解決諸如 CRD, wirldcard 資料夾等各種問題。


這年代專案來得快也去得也快...今天可以用的東西也許兩三年後就沒人維護了，沒有持續更新很容易就會握者一大堆死去專案, sad

https://github.com/yannh/kubeconform

Google SRE 團隊分享運行 SRE 20 年的 11 條經驗

對 Google 來說，20 年的時間有非常多的架構改變，最初每個 datacenter 大約只有數千台伺服器，其中透過 2.4G 頻寬的網路連結串連彼此。
如今資料中心的規模是過往的一千倍，網路的規模更是一萬倍。

因此該篇文章就細數這段改變以來所學到的經驗

節錄幾個有趣且常被忽略的點
1. Recovery mechanisms should be fully tested before an emergency

備援方案不是紙上談兵，沒有定期維護驗證過的備援方案跟我出嘴喊喊其實差不多


2. COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

溝通設備需要有備案，但是這些備案基本也與上述環環相扣，需要測試才算是真正的備案

3. A single global hardware version is a single point of failure

單一型號的硬體簡化了維運與操作，但是一旦該型號出現大問題，你就慘了
文章舉出 2020 內某網路裝置就出現這種問題

剩下的八個經驗就請自行閱讀囉

https://sre.google/resources/practices-and-processes/twenty-years-of-sre-lessons-learned/

一張圖圖解 HAP, VPA, CA 以及 CPA 等四種 Kubernetes 內自動擴展機制的差異


https://hwchiu.medium.com/what-are-the-differences-between-vpa-hpa-ca-and-cpa-in-kubernetes-5f74c97001ed