、托管集群介紹
所謂托管集群，即會有一個控制面幫助用戶管理k8s master組件的生命周期，用戶只需要將自己的虛擬機/物理機等注冊給某個k8s子集群的api server，即可將當前虛擬機/物理機納管成為某個k8s子集群的node節(jié)點，然后就可以通過k8s的api,在當前節(jié)點上運行各種workload。
一直以來，360都是通過rancher管理k8s集群的，rancher是一個容器管理平臺，用于在多個主機上部署和管理容器化應用程序。有web ui。rancher架構圖如下：
更多rancher相關信息請參考 https://ranchermanager.docs.rancher.com/
1. 集群搭建純cmd的實現(xiàn)方式，操作繁瑣；
2. 集群自定義組件實現(xiàn)不夠靈活，需要聲明完整的yaml,不夠友好 ；
3. 無法控制集群升級進度 ；
4. 集群node組件無法特異化配置，即每個node組件的啟動參數(shù)/配置可以不同；
二、托管k8s集群
相比傳統(tǒng)的集群搭建方式，需要創(chuàng)建k8s所有組件，及其依賴組件的方式，目前更為推廣的是托管k8s集群的模式。下圖為云廠商托管k8s集群大致的架構圖：
1. 可擴展性，架構分離
2. 減少集群管理工作
3. 減輕開發(fā)同學的壓力，專注
4. 便于資源預測，降低總擁有成本
5. 提升安全性
托管集群其實更多的是一種k8s集群管理概念，而其實現(xiàn)方式則多樣，容器云對這一類的集群叫做獨享集群，接下來看看我們是怎么做的吧。
三、項目實現(xiàn)過程
我們會發(fā)現(xiàn)，所謂集群托管，其實就是需要一個控制面去幫我們管理k8s控制面各個組件的生命周期，而k8s天然就是一個比較好的控制面，我們最終決定借助k8s去實現(xiàn)k8s托管集群的控制面，即 "k8s on k8s”。那么現(xiàn)在集群架構大致會是這樣：
1. 架構分離，用戶不必再維護集群控制面；
2. 生命周期管理，降低集群維護復雜度；
3. 可擴展性，自定義組件安裝的api ；
4. 安全，支持多種方式存在的etcd；
5. 聲明式集群定義方式，完全兼容k8s 原生api；
接下來，我們來介紹下這種方案在實踐的過程中遇到的問題。
四、項目經(jīng)驗
這種方案必然是和我們所處的網(wǎng)絡環(huán)境極相關的，想必這應該就是為什么各運廠商都在基于k8s做集群托管，但卻很少開源的原因吧。
網(wǎng)絡相關的問題很多，我們這里舉一個和k8s自身組件交互相關的例子。
問題是這樣的，我們通過konk的方式創(chuàng)建了一個新的k8s子集群，但是發(fā)現(xiàn)子集群中的很多基于webhook實現(xiàn)的系統(tǒng)組件均無法工作。
然后發(fā)現(xiàn)了一個非常奇妙的問題，子集群中webhook server對應的服務并沒有收到來自apiserver的請求，然后去排查子集群apiserver的日志，確實是有發(fā)送請求到webhook的，請求莫名其妙消失了？然后開始翻k8s的源碼，發(fā)現(xiàn)apiserver對于webhook請求的轉發(fā)的地址來自聲明的mutatingwebhookconfigurations/validatingwebhookconfigurations 資源的ClientConfig 的，詳細聲明如下：
// WebhookClientConfig contains the information to make a TLS
// connection with the webhook
type WebhookClientConfig struct {
URL *string
Service *ServiceReference
CABundle []byte
}可以看到，支持配置webhook server地址的方式有兩種，直接配置url地址，或者配置service信息。
大多時候，我們會直接通過service的方式去實現(xiàn)。
apiserver從這個配置找到自己應該把請求轉給誰，然后去拼http請求，但是遺憾的是，這個請求永遠無法到達子集群的webhook服務的。具體原因是，子集群的apiserver基于service拼完http請求進行轉發(fā)，首先請求從base集群中子集群apiserver的pod中發(fā)出，經(jīng)base集群的kubedns/coredns 將service轉成service ip，然后節(jié)點側基于kube-proxy下發(fā)的iptables/ipvs規(guī)則將請求轉發(fā)到具體的pod ip。問題就在于這條流程中, base集群中的pod去訪問service，那這個請求自然會被轉發(fā)到base集群的某個pod中，肯定是不可能到子集群中啊，天，恍然大悟，我們一直將子集群中的apiserver的所有流程和自己集群相關聯(lián)，但是卻忽略了它也只是base集群中的一個普通pod而已。
然后這個問題最終的解法是通過配置apiserver的一個flag
// Turns on aggregator routing requests to endpoints IP rather than cluster IP
--enable-aggregator-routing=true這樣從base集群轉出去的請求就可以到pod，所以這里其實還要求base集群中pod能夠訪問子集群中pod ip, 所以目前集群托管集群的webhook的pod必須用host network。
起初，我們的設計思路是這樣的，kubecluster crd會管理子集群維度的相關配置、證書管理、底層數(shù)據(jù)存儲等，然后k8s master的各個組件也會有對應的controller管理其生命周期，能夠單獨聲明不同組件的副本數(shù)，相關配置等等。
但是在項目落地的過程中在證書簽發(fā)部分遇到一系列問題，具體如下：
核心問題在于現(xiàn)在這種實現(xiàn)方式下，集群組件是pod創(chuàng)建的，而pod作為k8s集群中隨時可以被創(chuàng)建刪除替換的資源，隨著pod重新，pod ip也會發(fā)生變化，就會導致證書的白名單沒法確定。
所以其實種種說明這種設計模式下用pod ip去簽發(fā)證書是絕對不可以的。
最終我們通過將k8s master組件部署在同一個pod中解決，原因在于同一個pod中的多個container之間共享net namespace,這樣各個組件就可以通過127.0.0.1/0.0.0.0這種固定的方式去訪問，巧妙解決因為pod ip變化無法簽發(fā)證書的問題。
但是對于集群外我們一般通過kubeconfig 提供用戶訪問k8s的證書信息，在這里我們一般會將apiserver的pod ip注冊給一個lvs ip, 由于lvs ip在集群外是可以訪問的，通過lvs ip將流量下發(fā)到具體 apiserver pod ip，而這個lvs ip也會同時作為證書的白名單。這樣就解決了集群內外https訪問的所有問題。
k8s的容器運行時有多種多樣，目前獨享集群集群支持的容器運行時支持docker與containerd，也在serverless團隊的獨享集群當中替換了kata作為容器的運行時
在設計之初，獨享集群的node節(jié)點的kubelet與kube-proxy是通過docker容器啟動的，相比于systemed，通過docker容器啟動的kubelet與kube-proxy的容器在更新配置，更改命令行參數(shù)的時候更具有靈活性
但是在不同容器運行時的情況下，就會出現(xiàn)kubelet與kube-proxy是docker啟動的容器，k8s啟動的容器則為kubelet指定的容器運行時，這對于運維、開發(fā)來說去維護其實是一種很大難度的事，經(jīng)常會出現(xiàn)containerd修改了參數(shù),docker容器消失，宿主機出現(xiàn)僵尸進程的情況
為此獨享集群對于不同的容器運行時，定制了不同的容器運行時的kubelet與kube-proxy
但是在對接containerd的時候，啟動kubelet和kube-proxy容器出現(xiàn)了以下的問題：
創(chuàng)建出來的kubelet與kube-proxy不能正常使用；
k8s集群里的configmap與serviceaccout莫名其妙的失效；
問題的解決，第一個還很好說，很快解決了，第二個問題只需要給容器開特權模式與使用host網(wǎng)絡等一系列功能，就可以解決。
正常來說，configmap與serviceaccount是由kubelet通過api-server讀取etcd中記錄的信息，寫到宿主機kubelet定義的rootdir的pod某個目錄當中，再mount到具體的k8s容器當中的，異常現(xiàn)象是，kubelet容器內可以看到具體目錄下的cofigmap和serviceaccount信息，但是pod內看不到，導致一些控制面組件，連接apiserver的時候找不到配置文件而產(chǎn)生重啟的現(xiàn)象
仔細一想容器掛載configmap和serviceaccount的原理,kubelet通過將configmap和serviceaccount中的內容通過etcd中讀取出來，通過tempfs掛載到容器當中，這就需要提到一個關于namespace的小知識：
大家都知道，容器的隔離是通過不同的namesapce實現(xiàn)的，這里包括經(jīng)常使用的net、mount、pid的namesapce。
這里簡單提一下三個小知識：
1.mount namesapce：每個容器都可以擁有自己獨立掛載的文件系統(tǒng)
2.掛載傳播：簡而言之就是同一個掛載點可以讓不同容器使用
3.rootfsPropagation：和掛載傳播的作用類似，但是這個是解決嵌套容器的掛載傳播，正好符合我們的場景需求
我們的kubelet和正常的k8s容器在都是擁有自己mount的namespace的，也在宿主機上以容器啟動，而kubelet是調用containerd的unix socket進行pod的鏡像拉取，容器創(chuàng)建等功能
正好和rootfsPropagation所描述的關系一樣，通過加入以下代碼，調整kubelet的容器rootfsPropagation等于shared之后，pod內configmap，serviceaccount和secret都可以正常訪問，我們的問題也成功解決了。
opts=append(opts, oci.WithRootfsPropagation("shared"))
func WithRootfsPropagation(options string) SpecOpts {
return func(_ context.Context, _ Client, _ *containers.Container, s *Spec) error {
setLinux(s)
s.Linux.RootfsPropagation=options
return nil
}
}五、獨享集群支持的功能介紹
獨享集群目前支持的功能豐富多樣，下面我來通過在網(wǎng)絡、存儲、監(jiān)控等方面說一下現(xiàn)在獨享集群支持的哪些功能：
1.網(wǎng)絡方面
獨享集群目前集成了經(jīng)典網(wǎng)絡和hulk-vpc-cni網(wǎng)絡；
2.存儲方面
存儲方面目前集成了本地盤以及遠端存儲，各自功能優(yōu)勢如下：
3.日志方面
目前獨享集群支持的日志組件為arkit，通過與系統(tǒng)部的結合，給獨享集群提供了簡單，方便使用的日志組件。
4.監(jiān)控告警方面
監(jiān)控方面獨享集群適配了監(jiān)控組件firehawk-vmagent，k8s原生metrics server以及node exporter以及結合了推推告警，真正保障了提前預知問題風險，第一時間解決的獨享集群穩(wěn)定性。
5.流量方面
流量方面獨享集群支持4層與7層的流量控制：
7層：通過與hulk域名解析與ingress-controller的配合，實現(xiàn)了獨享集群內的7層流量控制，目前重度使用的用戶有360云盤、數(shù)據(jù)平臺部以及金融等。
4層：4層方面目前支持vpc網(wǎng)絡類型的獨享集群，通過自研l(wèi)oad-balancer與hulk四層負載均衡的結合，實現(xiàn)了獨享集群內的四層負載均衡。
6.資源隔離以及在離線混部方面
資源隔離：資源隔離目前獨享集群使用了lxcfs對pod進行資源試圖的隔離，在pod內使用top與free命令是看到的是自己本身的資源使用率而不是宿主機的。
在離線混合部署：在離線混合部署是指將低優(yōu)先級的服務與高優(yōu)先級的服務共同部署在同一個節(jié)點上，通過調度以及驅逐，保障了節(jié)點的健康狀態(tài)的同時增加了機器的資源使用率，目前在離線混部的獨享集群共有9個，所納管的裸金屬共有390臺，所有機器上都已經(jīng)部署了系統(tǒng)部的離線pod，未來這一數(shù)量會持續(xù)增加。
上述主要描述了獨享集群的底層實現(xiàn)原理，當前獨享集群在容器云上已經(jīng)有一定的集群規(guī)模，用戶可以按需創(chuàng)建和變更k8s集群，有很大的自主可控權，比較適合對k8s有定制化需求的用戶。未來在研發(fā)層面還會在集群自動升級流程、聲明式node管理等方面繼續(xù)迭代，也歡迎大家按需試用。
了解更多技術知識，歡迎關注“360智匯云”。
起企業(yè)網(wǎng)盤的安全，你會想到什么？
賬號登錄驗證、文件水印預覽、文件訪問權限管控、分享鏈接加密……
在億方云上，這些都是常見的安全防護功能。不過今天的主角不是它們，而是一個容易被大家忽視卻又極其重要的功能——云查毒。
自動查毒：從根源上杜絕
上傳文件是大部分人使用網(wǎng)盤的第1步，而這個動作恰好也是很多病毒傳播的源頭。如果病毒依附在某個文件中進入企業(yè)網(wǎng)盤，一旦被團隊成員下載或分享，那么對企業(yè)造成的損失是難以估量的。
查毒中的文件
對此，億方云設有「自動查毒」功能，可以排除所有新上傳文件的潛在風險。如發(fā)現(xiàn)病毒文件，系統(tǒng)會第一時間隔離處理，從根源上凈化企業(yè)的云端空間。
開啟/關閉「自動查毒」
「自動查毒」只能由企業(yè)管理員開啟/關閉，路徑：「控制臺」-「云查毒」-「自動查毒」。
Tips：
1. 開啟后，系統(tǒng)會自動對新上傳的文件（單個不超過1GB）進行查毒。
2. 新文件包括新上傳的文件、上傳的新版本文件、歷史版本設為最新版的文件、分享轉存的文件。
全盤查毒：給文件“定期體檢”
不過「自動查毒」只能檢測新上傳網(wǎng)盤的文件，如果你想對歷史文件做一個全面的“大體檢”，那么不妨試試「全盤查毒」功能。
正在查毒中
開啟方法很簡單，和自動查毒一樣，只有企業(yè)管理員才能操作，打開「控制臺」，在「云查毒」里找到「開始全盤查毒」，點擊即可開始。發(fā)起后無需等待，企業(yè)管理員可以先去安排其他工作，全盤查毒完成后會在億方云內發(fā)送一條系統(tǒng)消息提醒。
鑒于日常文件分發(fā)過程中的各種潛在危險因素，定期對所有文件進行一次“體檢”還是很有必要的。
疑似病毒文件怎么處理？
看完前面的內容，大家肯定有很多個疑問……
病毒文件被查到后會直接被刪除嗎？
病毒文件跟正常文件如何區(qū)分？
正常文件被誤傷了怎么辦？
……
下面我們就來看看億方云是如何高效處理疑似病毒文件的——一份病毒文件的億方云之旅。
① 發(fā)現(xiàn)病毒文件，第一時間「隔離」
隔離區(qū)
通過自動查毒和全盤查毒發(fā)現(xiàn)的疑似病毒文件，會被第一時間放入「隔離區(qū)」，防止病毒向外擴散。
如果病毒文件在「個人文件」中，則會被放置到個人的隔離區(qū)中；但如果是部門文件夾中的病毒文件，則會被放置到部門主管級文件所有者的隔離區(qū)中。
② 每個病毒文件被有「標簽」
文件標識
如果沒有病毒，那么億方云上的文件屬性里會有“安全”的標識。而疑似病毒文件的屬性里則會有“疑似病毒”的標識。
③ 根據(jù)病毒處理進度，實時「消息提醒」
在億方云上，疑似病毒的處理動態(tài)會實時同步給文件相關人。比如：
當新文件被移到隔離區(qū)時，會產(chǎn)生一條系統(tǒng)消息發(fā)送給文件相關人；
當文件被從隔離區(qū)復原時，也會產(chǎn)生一條系統(tǒng)消息發(fā)送給文件相關人。
文件相關人包括文件上傳者、當前所有者以及部門主管。
④ 疑似病毒文件「刪除和恢復」
隔離區(qū)的文件可以選擇恢復或者刪除，如果你有文件被誤判為疑似病毒文件，那么可以在這里恢復。
需要注意的是，隔離區(qū)刪除的文件不會進回收站，會直接被徹底刪除。
以上就是億方云關于文件安全防護的部分功能，雖然日常使用中感受不到，但是卻一直在背后默默保護著大家的文件安全。
360云盤的關閉短時讓網(wǎng)絡沸騰，用戶拼命的下載也一度讓360云盤里的東西無法下載。之所以會影響如此之大，是因為免費，360關閉云盤也可能是因為免費，沒錢賺的事情360也不能老干。
為什么說沒錢賺的事情360不干呢，因為本月360除了關閉了云盤，還關閉了一個重要的免費東西，也行很多人不知道，但360導航大家知道吧，360還有一個導航個人版，筆者一直喜歡的。沒錯，就是它被360關閉下線了
360導航個人版相對于其他導航非常簡潔，僅提供一個可以收藏修改網(wǎng)址的地方，用戶添加自己經(jīng)常上的網(wǎng)址，非常簡潔明了，對于密集恐懼癥的童鞋非常有愛。
然后360卻忍心把他下線了，傷了多少用戶的心。360云盤占用貴公司大量資源，一個導航成本總是小的吧，360為什么要關閉呢。也許因為免費沒錢賺，逼用戶使用導航正式版，那個才能給360帶來利益。
360論壇眾多用戶質疑為什么關閉個人版。筆者一直也用這個導航，用了好多年了，關閉實在心痛了一會，不過還是找到了替代產(chǎn)品，就是百度首頁，功能和其非常類似
希望百度的首頁會一直下去，和百度云盤一樣，一直為民眾服務