參賽將近半個月，終於完成了我認為貼近infra的部分，這也是為什麼要做個小結的原因，大部分企業在使用kubernetes的時候，常常會有一個疑問是，到底這個的管理要怎麼歸屬呢？

如果用比喻的方式來形容，資訊架個的演進，從bare-matal -> hypervisor -> containerized，k8s 是很接近hypervisor內host的角色(like vCenter)，每一個node用vmware來看的話就像是esxi host一樣，而pod就像是vm不過更輕更小，但是差異點在於以往的vm通常會有os的管理員可能會是公司內的維運team在系統異常時登入進行troubleshooting，而container 沒有管理員的角色，並且很少會有進到container進行維運的需求，如果要說對pod的維運，反而更貼近把yaml調整成正確或是可用的宣告。

所以以簡易的二分法 infra(mis) 與 ap 界線，在我今天之前的內容我認為都列屬於infra的權責，當然如果公司內部infra還有細分到系統管理員、資管、devops team，SRE、k8s RD，那麼又可以切分到更細緻像是k8s底層的維運控管 add node 建置等等..給系統管理員，argo promo和k8s管控介面權限給資管，devops負責設計gitops的流程和yaml，SRE處理metric logging tracing，RD負責優化及增進功能諸如base image的設計，這樣看起來就是較為優秀的維運團隊。

另外前面這段日子所構築出來的架構，是可以整成一段自動化的流程的，透過ansible和terraform自動的建置出kubernetes，並搭配yaml和cli將管理功能配置完成，甚至搭配gitops的方式在k8s建置完成後自動的sync git repo將management namespaces完成，這樣在更新管理機制時也可以一併同步給所有的cluster呢。