藉著在 Ant 哥這一篇下的回覆（
https://www.facebook.com/1815507975/posts/10215890666418971/?d=n），剛好能帶出一個重點，其實CI 跟 CD 從來都不該是指 "build server"，而是狀態。

持續整合 (Continuous Integration) 指的是：當團隊不只一個人對同一份 code base 在進行修改時，能多快地被整合在一起，並確認執行結果符合需求預期。

持續交付 (Continuous Delivery) 指的則更偏向：對 code base 的任何修改，在整合完確認無誤之後，可以不間斷、自動、快速地交付到 production 給使用者用。（包含 hotfix 修問題，包含 feature flag 的 rollback）而不是得等待 release 的日期才能 release，而不是得等一堆環境上的手動測試完，再自行打包對應的 feature code base 上到 production.

那種 DevOps = CI/CD = build server 的，要嘛就是被迫得用這樣的說明其他人才聽得懂，要嘛就是根本不懂 DevOps 跟 CI/CD 背後真正的涵義，以及那種狀態下的軟體開發交付，以及真正想要解決的問題。（自動化只是其中的一小個必要條件）

看大家說的 CI, 可以簡單把持續整合當作有狹義跟廣義兩種。

狹義就是只到拉 code 跟 build 跟打包。

廣義就是包含整合 build 完的 package 「是不是符合預期」，要知道使用起來有沒有符合預期，自動化測試是基本的。包含最基底針對邏輯的單元測試，還有部署到測試環境之後 end-to-end 的驗收測試。

有趣的是，大部分人在講 CI 都是廣義的，該有的都要有（我們以前 build job 還包含要自動產生符合公司規定或政府規定的 上版文件並自動發送通知），基本款就是拉 code, build, 靜態程式碼分析, 自動單元測試, 打包, 部署到下個環境, 執行該環境的 end-to-end 測試，產生文件。

但大部分嘴巴講廣義 CI 的人，他們實際的 CI 卻是狹義的 CI，只有拉 code + build, 勉強多一點靜態程式碼分析的套件，但也只是分析而已，也不會依據報告結果去修正或重構。

這是一篇幻想文，幻想如果你可以重新設計 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/