iT邦幫忙

2021 iThome 鐵人賽

DAY 14
0
DevOps

玩耍開源k8s30天系列 第 14

day14 : 前半段小結

參賽將近半個月,終於完成了我認為貼近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呢。


上一篇
day13 : argo gitops服務以及ingress (下)
下一篇
day15 : NATS 、NATS Streaming、JetStream服務應用 on K8S (上)
系列文
玩耍開源k8s30天31

尚未有邦友留言

立即登入留言