本篇文章是ㄧ個 Kubernetes 相關工具經驗分享文，作者認為即使是前端開發工程師也必須要瞭解一下 Kubernetes 這個容器管理平台，作者認為 k8s 基本上已經算是這個領域的標準(de-facto)。

因此作者於本篇文章介紹一些搭建一個 K8s 叢集時需要注意的工具，透過這些自動化工具來減少反覆動作的執行藉此簡化每天的工作流程。

工具包含
1. ArgoCD
2. MetalLB
3. External-secrets
4. Cert-manager
5. External-dns

Simplify deploying of new apps
作者大力推薦使用 ArgoCD 來簡化部署應用程式，作者提到一開始使用 ArgoCD 時也是感到無比煩感，因為心中一直存在要於 `GitLab CI/CD pipeline` 透過 kubectl apply 的方式來部署應用程式，並不想要導入其他的元件來加入更多的複雜性。

然而當作者嘗試 ArgoCD 後，第一眼發現的是其架構不如想像中複雜，完全依賴 GitOps 的原則來簡化整個部署流程，同時透過一個 WebUI 的方式來呈現當前應用程式的部署狀況

Load balancer for your on-prem clusters
地端環境的 Load-Balancer，沒什麼好說就是 MetalLB。

Managing your secrets
Secrets 是 Kubernetes 內一個非常重要的物件，然而大部分的團隊都會思考如何有效且安全的去管理 Kubernetes 內的 Secret 物件。雲端供應商譬如 AWS Secrets Manager, Azure Key Vault 或是廣受熱門的 HashiCorp Vault.

作者推薦使用 external-secrets operator 這個專案來將外部的管理系統給同步到 Kubernetes 內並且產生對於的 secrets。

詳細全文可以參考下列原文

https://chris-blogs.medium.com/tools-that-should-be-used-in-every-kubernetes-cluster-38969ed3e603

這是一篇幻想文，幻想如果你可以重新設計 Kubernetes，你會希望有什麼樣的改動。也因為是幻想文，所以以下所提的東西不一定真的可以實作，也沒有考慮實作上可能會有什麼困難。原文非常的長，所以這邊就稍微列出一些內容

# 前提
作者(David Anderson, MetalLB 的主要貢獻者)認為 Kubernetes 真的很複雜，從 MetalLB 的開發經驗來看，幾乎無法開發出一個永遠不會壞且與 k8s 整合的軟體。
k8s 發展快速，一些不相容的修改也很難除錯，往往導致這些整合應用程式一起壞掉。
此外，作者使用 GKE 的經驗讓他覺得就算是這些k8s專家，也很難大規模環境中平安順利的使用 k8s.

作者認為 k8s 就像是管理平台內的 c++，功能非常強大，什麼都可以做，但是它會一直傷害你，直到你奉獻餘生該領域內。
作者期盼有一天，可以出現一個像是 go 語言的管理平台，簡單，優雅，容易學習

接下來就來看一下如果時光倒流，作者會希望 k8s 有哪些功能

# Mutable Pod
不像其他的資源一樣， Pod 這個資源基本上是不能修改的，有任何的更動都需要先刪除，後重新部署這樣兩步走來處理。
作者希望可以有一種 Pod 是可以支援即時修改的。
舉例來說，我透過 kubectl edit 修改了 Pod Image，然後只要透過 SIGTERM 送給 Runc 底層容器，然後當該 Container 被重啟，就會使用新的設定。這一切的發生都在同一個 Pod 的資源內，而不是重新產生一個新的 Pod

# Version control all the things
當 Pod 可以修正後，下一個作者想要的功能就是基於 Pod 本身的 Rollback。這意味希望叢集內可以有這些資訊可以去紀錄每次的變化

為了實現這個功能，可能每個節點上面也要去紀錄過往的所有 image 版本資訊，並且加上 GC 等概念來清除過期或是太舊的內容

# Replace Deployment with PinnedDeployment
相對於 Deployment， PinnedDeployment 最大的改動就是一個 Deployment 內可以同時維護兩個版本的 Pod。

舉例來說，我今天要將 Nginx 從 1.16 升級到 1.17，我可以透過 PinnedDeployment 去部署 Nginx，其中 1.16 佔了 60% ，而新版本 1.17 佔了 40%。

當一切轉移都沒有問題後，可以逐漸地將新版本的比例遷移到 100% 來達成真正的移轉。
原生的 Deployment 要達到這個功能就要創建兩個 Deployment 的物件來達到這個需求。

# IPv6 only, mostly
作者期望能的話，想要把 k8s networking 內的東西全部移除，什麼 overlay network, serivce, CNI, kube-proxy 通通移除掉。

k8s 全面配置 IPv6，而且也只有 IPv6，通常來說你的 LAN 都會有 /64 這麼多的地址可以分配 IPv6，這個數量多到你根本不可能用完 (2^64)。
也因為都有 public IPv6 的緣故，所有的存取都採用 Routing 的方式，封裝之類的玩法也不需要了。

文章內還提了很多東西，譬如說如果今天真的需要導入 IPv4 於這個純 IPv6 的系統上，可以怎麼做，如何設計 NAT64 等，算是非常有趣的想法

# Security is yes
作者認為安全性方面要最大強化，預設情況下要開啟 AppArmor, seccomp profile 等控管機制，同時也要全面禁止用 Root 來運行容器， 基本上就是用非常嚴格的方式來設定安全性方面的規則。

目前 Kubernetes 內的資源， Pod Security Policy 非常類似作者想要完成的東西，通過這種機制確保所有部署的 Pod 都會符合這些條件。唯一美中不足的是 Pod Security Policy 也不是預設就有的規則。

# gVisor? Firecracker?
從安全性考量出發，是否預設改使用 gVisor 或是 Firecracker 這類型的 OCI Runtime 而非 Runc，同時搭配上述的各種安全性條件來打造非常嚴苛的運行環境

# VMs as primitives
是否可以讓 kubernetes 同時管理 container 以及 virtual machine，也許就會像是將 kubevirt 變成一個內建的功能，讓 kubernetes 更加靈活的使用

除了上面之外，文章內還有許多其他的想法，但是內容都滿長的，如果有興趣的可以點選下列連結參考看看
https://blog.dave.tf/post/new-kubernetes/

如果有在使用 Kubernetes Service 的人可能都有聽過 Load-Balacner 這個類型，然而 Kubernetes 本身並沒有實作 Load-Balacner，而是要仰賴其他的第三方服務，譬如公有雲上提供的 LB。如果今天想要餘地端環境使用，針對這些 bare metal 的機器，我們如果要使用 Load-Balancer 的話，就必須要使用額外的解決方案，譬如 MetalLB
今天要介紹的則是另外一個解決方案， porter，該解決方案的特色有

1. 支援 ECMP (Equal-Cost MultiPath) 多重路由協定
2. 支援 BGP
3. 支援 K8S Service
4. 可以用 Helm Chart 安裝
5. 透過 CRD 的方式來修改 BGP 設定，而不需要重起相關服務

專案內有列出跟 MetalLB 的差異，優點主要是基於 CRD 與 Controller 的概念去整合整個 BGP 的操作，同時與 Calico 衝突時有更好且優雅的方式去解決

有地端環境使用需求的人可以稍微看看這個專案囉

https://github.com/kubesphere/porter