標題: 「Datree, Kubernetes Configuration 檢查工具」 類別: tools 連結: https://opensource.com/article/22/4/kubernetes-policies-config-datree

如同各類程式語言的測試框架， Kubernetes 的部署文件(YAML)實際上也是可以導入 CI 的概念，那到底 YAML 檔案有什麼東西需要檢驗？ 最基本的概念大致上可以分成三種

1. YAML 語法的檢查
2. Kubernetes YAML 的語意檢查
3. Kubernetes YAML 的設定規範檢查

除了基本的 YAML 部署外，還要考慮一下團隊是採用何種方式來管理 Kubernetes App，譬如原生 YAML, Helm, Kustomize 等各種不同方法。

(1) 的話其實最基本的方式就是使用 yq 指令，其本身就可以檢查基本的 YAML 語法，如果是 Helm 的使用者也可以透過 Helm template 的方式來嘗試渲染，渲染的過程也會幫忙檢查 YAML 的合法性。 (2) 的話其實也有其他如 kubeval 等類型的工具去幫忙檢驗 YAML 內容是否符合 Kubernees Scheme，這邊要特別注意的還有版本問題，畢竟每次升級都會有很多 API Version 被調整 (3) 的話講究的是規範，譬如要求所有 workload 都必須要描述 CPU/Memory 的Request/Limit，或是要求所有容器都要以 non-root 的身份運行， 這部分有如 kube-score，或是基於 REGO 的 conftest 等工具可以檢測。

而今天分享的這個工具 datree 基本上就是一個人包辦上述三個工具，該工具基本上有兩種模式使用

1. local 使用，就如同上述所有工具一樣，你可以把所有策略與規則都放到本地環境，搭配 git hook, CI pipeline 等概念去執行
2. datree 還提供了一個中央管理 Policy 的伺服器，每個運行 datree 的環境都可以與該團隊維護的 server 連動，讓你透過網頁的方式去設定想要驗證的 k8s 版本以及想要檢測的規範有哪些。

基本上這類型的工具愈來愈多，找到一個適合團隊的工具將其整合到 CI 中，讓團隊的 Kubernetes YAML 都能夠符合團隊規範，同時也透過 CI 的流程盡可能提早地找出問題

標題: 「三座獨立 k8s cluster 還是一個跨三個地區的 k8s cluster ?」 類別: kubernetes 連結: https://itnext.io/3-reasons-to-choose-a-wide-cluster-over-multi-cluster-with-kubernetes-c923fecf4644

講到多套 kubernetes 的情況下，目前大部分的文章都會推薦用三套獨立的 kubernetes 叢集而非架設一套同時管理三個地點的 kubernetes 叢集。 本篇文章作者從不同的面向分享為什麼要選擇一個 kubernetes 管全部，而不是要架設三套 kubernetes 叢集。

Latency

一套 kubernetes 最令人詬病且很難處理的就是 Latency 的問題，作者提到 Latency 的問題會影響 ETCD ETCD 被影響後會影響整個叢集的運作，甚至連應用程式相關的處理都會變慢。

作者提到其實這個問題能夠採取兩個步驟來解決

1. 重新安排 etcd 的節點位置，或是使用 non-etcd 的解決方案
2. 透過 node labels 讓要使用 etcd 的服務跟 etcd 盡量靠近

註: 我是覺得這說法不能解決問題，一般應用程式要是被分散到不同地區你的存取還是有機會跨地區，除非要很認真地針對不同地區去設計 label，讓應用程式的部屬都只會固定同個地區，但是要這樣搞跟我直接搞三套不覺得後者會比較累。

Security

作者一直強調使用 mesh VPN 來打通底層所有網路封包處理，讓你一個大 k8s 管理多個地區，就不用擔心底層網路問題

單套 k8s 的好處有什麼？作者認為有

No Complicated tooling

作者提到 2021 年的 KubeConf 有各種管理多套 k8s 叢集的工具，如 KubeEdge, OpenShift Edge, Akri, Baetyl, Kubermatic, Rancher, KubeFed... 等，如果用一套大 k8s 就可以不使用這些工具，直接減少與這類型複雜工具的依賴性 一套 k8s 叢集可以讓你使用最簡單也是最習慣的方式來管理所有環境

No extra overhead

每套 K8s 環境中都會有如監控，日誌， registry 等各種工具，多套 k8s 的架構就是每個叢集都要安裝一份，但是如果採用一個大 k8s 的架構就只要維護一份即可 所以可以減少很多不必要的重複安裝。

Ultimate Flexibility

這段其實不很理解，為什麼作者這麼想要推廣 mesh VPN ...

註: 這篇文章底下有留言說探討到說 RBAC 等相關權限問題是個很大的問題，你一套 k8s 很難處理這些，事情沒有想像的這麼簡單

標題: 「強化 Kubernetes 叢集的必備工具」 類別: kubernetes 連結: https://medium.com/mycloudseries/must-haves-for-your-kubernetes-cluster-to-be-production-ready-dc7d1d18c4a2

作者本篇文章想要分享一個其用來讓一個 Kubernetes 變得能夠真正上戰場的相關工具，因此文章中特別強調是 Production-Ready 的情況。 一個 Production Ready 的 K8s 叢集必須對於下列每個大項目都要有相關處理方式，譬如

1. Reliability and Availability
2. Security
3. Network, Monitoring & Observability
4. Backup/Recovery
5. Cost Optimization
6. Cluster Visualization

Reliability and Availability: 該領域的兩個指標代表的意義不太一樣，但是對於一個提供服務的叢集來說都一樣重要

這邊作者列舉了幾個工具譬如

1. K8s 內建的 HPA
2. AWS 的 karpenter，讓你針對基於節點為單位來擴充
3. Cluster-Autoscaler
4. Goldilocks

Backup/Recovery 有不少人團隊都對於對於叢集的備份與還原感到頭痛，目前最知名的開源專案莫過於 Velero，其支援不同的儲存設備如 Cloud Storage 等來存放，讓不同環境的 k8s 使用者都有辦法去備份其叢集內的資料

Cost Optimization

對於雲端架構來說，基本上雲端業者的內建功能已經可以針對如 VM, 底層架構等各種服務去列舉出各自的花費金錢，將此概念套入到 Kubernetes 本身大抵上只能理解到 Master Node, Worker Node 等之類的花費， 因此透過 Kubecost 之類的專案來將成本的洞察範圍擴充到 Kubernetes 內部，以 namespace, pod 等各種 k8s 的資源為單位來列舉實際花費的金額，能夠讓團隊更有效地去管理相關花費

標題: 「透過 Kubernetes Event-Driver Autoscaler(KEDA) 來根據各種指標動態擴充容器」 類別: kubernetes 連結: https://medium.com/@casperrubaek/why-keda-is-a-game-changer-for-scaling-in-kubernetes-4ebf34cb4b61

Kubernetes 內已經有 HPA 的物件可以讓 K8s 根據一些基本的指標來動態調整 Pod 的數量，而 KEDA 這款 CNCF 的孵化專案則是完全強化 HPA 的效果 KEDA 的概念很簡單，就是應用程式應該要可以有更多的指標來幫忙動態擴充，除了最基本的 CPU/Memory 等基本指標外， KEDA 來支援了下列各種不同指標，讓 k8s 可以使用更為廣泛的指標，譬如

1. Redis 內某個 Queue 的長度
2. K8s 內其他 Pod 的數量
3. PostgreSQL Query 的結果
4. Elasticsearch Query 的結果
5. 各種雲端服務，如 Azure Event Hubs, AWS CloudWatch, GCP Pub/Sub
6. Kafka ... 等各種不同指標

使用方式很單純，一切的規則都是基於 K8s 的 CRD 來描述與管理，因此團隊可以使用 YAML 的方式來定義這些擴充的規則 文章中有基於 CPU/Memory 的基本介紹使用，同時文章中也有官方的連結來介紹各種不同指標的示範用法

標題: 「升級 Kubernetes 1.22 的注意事項」 類別: kubernetes 連結: https://blog.runx.dev/will-that-kubernetes-v1-22-upgrade-break-my-application-cc339dc2e2c7

隨者各大公有雲逐步支援 Kubernetes 1.22，相關使用者可能都會開始進入升級的準備階段，而每次 Kubernetes 升級除了單純 思考 Kubernetes 本身的升級順利與否外，也要確認正在運行的所有 Kubernetes 資源與相關工具是否也能夠順利運行，這使得整個準備工作變得複雜與龐大。

從 Kubernetes 的角度來看，每次的升級除了基本的穩定性與相關功能修正外，最重要的還有 Kubernetes API 的改變，該改變影響巨大，譬如所有 Manifest 的內容，譬如眾多透過 YAML 所描述的各種資源 API 的改變都會提早通知所有社群，於先前的版本先將該 API 標為 deprecated 接者後續版本才會正式移除，譬如 networking.k8s.io/v1beta1 於 1.19 被標示為 deprecated 然後正式於 1.22 移除。 正式的版本 networking.k8s.io/v1 則從 1.19 正式啟用，讓管理者有大概有三個版本的時間轉移。

因此升級前一定要先架設一個測試環境，嘗試部署所有現存的資源來確保升級不會出現不預期的錯誤。

作者整理出關於 1.22 升級要注意的版本變化，如下(幾乎都是從 v1beta 變成 v1)

1. Webhook: admissionregistration.k8s.io/v1beta1 → admissionregistration.k8s.io/v1
2. CRD: apiextensions.k8s.io/v1beta1 → apiextensions.k8s.io/v1
3. APIService: apiregistration.k8s.io/v1beta1 → apiregistration.k8s.io/v1
4. TokenReview: authentication.k8s.io/v1beta1 → authentication.k8s.io/v1
5. SubjectAccessReview: authorization.k8s.io/v1beta1 → authorization.k8s.io/v1
6. CertificateSigningRequest: certificates.k8s.io/v1beta1 → certificates.k8s.io/v1
7. Lease: coordination.k8s.io/v1beta1 → coordination.k8s.io/v1
8. Ingress: extensions/v1beta1, networking.k8s.io/v1beta1 → networking.k8s.io/v1
9. IngressClass: networking.k8s.io/v1beta1 → networking.k8s.io/v1
10. RBAC resources: rbac.authorization.k8s.io/v1beta1 → rbac.authorization.k8s.io/v1
11. PriorityClass: scheduling.k8s.io/v1beta1 → scheduling.k8s.io/v1
12. Storage resources: storage.k8s.io/v1beta1 → storage.k8s.io/v1

標題: 「一個用來管理 Kubernetes 開源工具的開源工具」 類別: tools 連結: https://github.com/alexellis/arkade

作者因應過去於 Kubernetes 的教學與開源過程中，必須要一直不停地去安裝各式各樣必備的工具而感到厭煩，譬如每次都要安裝 kubectl, kind, kubectx 等各種常見工具 而每個工具又會有不同的版本，每次都要專寫相關的安裝流程都很麻煩，因此作者萌生出開發一個能夠安裝這些工具的開源工具, arakde.

該工具用起來非常簡單，同時也支援不同版本的工具，除了基本 CLI 工具外也支援 Helm App 的安裝，我個人認為光工具本身就非常好用了，譬如可以透過該指令輕鬆的安裝不同版本的下列工具

1. dive
2. helm
3. gh
4. jq
5. k3d
6. kind
7. kubectl
8. k9s
9. kail
10. opa
11. terraform ...

如果你常常需要撰寫文件去分享安裝各種文件的需求，也許可以考慮使用看看此工具來簡化流程

標題: 「透過 Helm 與 Terraform 來自動 Re-new Cloudflare origin CA」 類別: usecase 連結: https://awstip.com/auto-renew-cloudflare-origin-ca-with-terraform-and-helm-d28be3f5d8fa?source=linkShare-91a396987951-1645539866&gi=a18b2bbd9604

本篇文章是過工具介紹文，探討如何基於 Helm 與 Terraform 這兩個不同層級的工具來處理 Cloudflare 的憑證。

Why Cloudflare

根據 W3Techs 的調查顯示， 81.2% 的網站都使用 Cloudflare 來提升讀取速度或安全防護。 透過 CDN 的概念與機制，網站可以讓全球使用者有更快的讀取速度，此外也愈來愈多的網站會透過 Cloudflare 來處理如機器人, DDOS 之類的流量攻擊，畢竟要自己架設網站處理這些攻擊非常困難 因此讓 Cloudflare 這類型的網站來幫忙過濾與處理能夠讓團隊更專注於本身的業務開發與維運

Kubernetes

想要在 Kubernetes 內妥善管理所有使用的憑證其實也是一個麻煩事情，除了要能夠設置正確來創立憑證外，能夠於到期前自動 re-new 也是一個不可或區的功能。 Kubernetes 內跟憑證有關的最知名專案我想就是 Cert-Manager，而 Cloudflare 也基於此專案撰寫了相關的 Kubernetes Controller，如 Origin CA 等 因此本文使用的功能與示範都會基於 cert-manager 與 Cloudflare 的架構。

目的

本文的目的是希望能夠將過往手動的繁瑣步驟給自動化，讓 Kubernetes 可以獲得 Cloudflare 提供的好處，如憑證與相關域名等。 內文是基於 Terraform 作為出發點，然後透過 Kubernetes Provider 的方式來與之互動，一步一步的安裝各種資源最後成功於叢集內獲得相關域名的 SSL 憑證以及其他資源

標題: 「Kubernetes 紀錄片 」 類別: others 連結: https://thenewstack.io/a-kubernetes-documentary-shares-googles-open-source-story/

來自歐洲的 Honeypot.io 與 RedHat, Google 以及 CNCF 合作完成一個長達一小時的 Kubernetes 紀錄片，該紀錄片分成上下兩集，探討 Kubernetes 的發展及過程 被戲稱就像是給開發人員的 Netflix 影片 如果英聽還行的話，非常推薦當個小品影片去聽聽看 Kubernetes 的今生前後

標題: 「Paypal 如何調整 Kubernetes 讓其規模達到四千節點，20萬個 Pod」 類別: usecase 連結: https://medium.com/paypal-tech/scaling-kubernetes-to-over-4k-nodes-and-200k-pods-29988fad6ed

摘要: Paypal 過去一直都使用 Apache Mesos 來運行其大部分的服務，而其最近正在針對 Kubernetes 進行一個評估與測試，想瞭解如果需要轉移到 Kubernetes 會有哪些問題需要挑戰與克服。 本篇文章著重的是效能問題，原先的 Apache Mesos 可以同時支持一萬個節點，因此 Kubernetes 是否可以拿到相同的效能 而本文節錄的就是擴充 Kubernetes 節點中遇到的各種問題以及 Paypal 是如何修正與調整讓 Kubernetes 可能容納盡可能更多的節點。

Cluster Topology

1. 三個 Master 節點與三個獨立的 ETCD 叢集，所有服務都運行於 GCP 上。
2. 工作節點與控制平面的服務都運行於相同的 GCP Zone 上。

Workload

效能測試方面是基於 k-bench 去開發的測試工具，基於平行與依序等不同方式來創建 Pod/Deployment 兩種資源。

Scale

1. 測試初期先以少量的節點與少量的 Pod 開始，接者發現還有提升的空間就會開始擴充 Pod 與節點的數量。
2. 測試的應用程式是一個要求 0.1m CPU 的無狀態應用程式。
3. 最初的工作節有點 4 個 CPU，根據測試可以容納大概 40 Pod 左右。 接者就是不停地擴充數量，先從一千個節點開始，接者調整Pod 的數量直到 32,000 個 Pod。最後擴充到 4,100 個節點並且配上 200,000 個 Pod. 過程後期有調整節點的 CPU 數量讓其能夠容納更多的 Pod 數量

文章接下來開始針對 API Server, Controller Manager, Scheduler, ETCD 元件遇到的問題並且如何解決，中間提到了不少參數，這部分應該是大部分使用者都比較不會去研究與使用的參數 因此我認為本篇文章非常值得閱讀。 ETCD 的部分遇到很嚴重的效能問題，作者團隊觀察到大量的 Raft 溝通失敗個訊息，觀測到跟硬碟寫入速度有關，然而 GCP 沒有辦法單純增加效能，必須要同時提升硬碟空間，所以使用上彈性不變。 不過就算採用 1TB 的 PD-SSD ，當 4 千個節點同時加入到 Kubernetes 時依然會遇到效能上的問題，團隊最後決定使用本地端的 SSD 來想辦法改善寫入速度，結果又遇到 ext4 的一些設定 過程很多問題也很多解決方式。

結論來說: k8s 複雜

標題: 「 Kubernetes 四種不同開發環境的比較」 類別: Kubernetes 連結: https://loft-sh.medium.com/kubernetes-development-environments-a-comparison-f4fa0b3d3d8b

根據 VMware 2020 的一個研究報告指出，如何存取 Kubernetes 叢集是影響開發者生產效率的最大要素，所以本篇文章就是就會針對如何去評估與挑選一個適合開發者的 Kubernetes 叢集與存取方式。

作者將 Kubernetes 叢集分成四大類，分別是

1. Local Cluster: 開發者會基於自己本地的電腦來創造一個本地的 Kubernetes 叢集
2. Individual Cloud-Based Cluster: 開發者基於雲端環境來創建一個專屬於該開發者的 Kubernetes 叢集
3. Self-Service Namespace: 使用基於 namespace 的方式來讓多位開發者共享一個 Kubernetes 叢集
4. Self-Service Virtual Cluster: 讓 Kubernetes 來創建更多小 Kubernetes 叢集並且讓每個使用者有獨立專屬的 Kubernetes 叢集

為了比較這四種不同的叢集，作者定義了幾個不同的面向，針對這幾個面向來評比，分別是

1. Developer Experience: 對於開發者來說要如何開始使用叢集，包含架設的複雜度，使用的難易度以及需要的相關背景多寡
2. Admin Experience: 對於公司的管理人員來說需要花多少心力來管理該從開發者環境，除了基本的管理還要考慮增加新使用者帶來的負擔
3. Flexibility/Realism: 該開發環境與正式生產環境的架構相似度如何，此外開發者是否有足夠的彈性去客製化該叢集的所有設定
4. Scalability: 該環境是否能夠根據開發需求來擴充？ 特別是針對部分需要大量使用資源的應用程式開發是否有辦法處理。
5. Isolation/Stability: 開發者彼此之間的隔離程度如何，彼此之間的工作是否會影響彼此？ 有資安問題的時候是否會連環爆？
6. Cost: 該解決方案的成本多寡，成本就是真正的金錢考量。

文章一開始就有列出一個結論表，對於這個議題有興趣的歡迎閱讀