容器云平臺的高可用設(shè)計(jì)

容器云平臺的高可用設(shè)計(jì)Ⅱ目錄Ⅱ1111133457778889PAGE08PAGE08

緒論雖然大部分情況下，我們的系統(tǒng)都能夠很好的運(yùn)行。但絕對不會故障的系統(tǒng)是不存在的。無論代碼寫的多好，硬件如何的可靠，也無法保證整個系統(tǒng)的穩(wěn)定。因?yàn)楣收峡偸菚l(fā)生在意想不到的地方。比如2015年5月27日支付寶在杭州的一個機(jī)房光纖被挖斷，導(dǎo)致部分用戶無法正常使用支付寶，直到當(dāng)日晚上7點(diǎn)20分，支付寶才宣布用戶服務(wù)恢復(fù)正常。1029支付系統(tǒng)宕機(jī)近30分鐘，使得近兩千萬筆訂單無法正常的完成。阿里騰訊的技術(shù)水平不可謂不強(qiáng)，而支付業(yè)務(wù)又是其中的重中之重。盡管如此，還是會有一些揪心的時刻。為了能夠盡可能的減少服務(wù)的不可用時間，最大降低損失，我們可以通過架構(gòu)設(shè)計(jì)的手段為服務(wù)提供強(qiáng)的可用性，即高可用架構(gòu)設(shè)計(jì)。N對于高可用架構(gòu)還應(yīng)當(dāng)考慮服務(wù)分級與降級，災(zāi)難恢復(fù)與異地多中心等等機(jī)制或場景。隨著服務(wù)規(guī)模的不斷擴(kuò)張，保持或提高可用性的成本會以一種夸張的方式上漲。由于篇幅有限，對于很多知識點(diǎn)都難以面面俱到的深入探討，在實(shí)際應(yīng)用中還是需要更多的參考實(shí)際場景來進(jìn)行規(guī)劃。通過前一節(jié)的介紹我們可以知道，如果想要保證整個云平臺的高可用，對于云平臺各個部分自然是需要一定程度了解的。接下來讓我們看看常見的容器云平臺架構(gòu)：IO應(yīng)用在容器這一新秀剛剛發(fā)展起來的那段時間里，曾經(jīng)出現(xiàn)過大量的容器編排系統(tǒng)。其中以Swarm、構(gòu)建的容器生態(tài)體系已經(jīng)成為了容器領(lǐng)域中的事實(shí)標(biāo)準(zhǔn)。安裝一個高可用的Kubernetes集群是保障容器云平臺高可用的第一步。盡管我們可以通過諸如Kubeadm、RKE或Kops之類的工具輕松的安裝一個Kubernetes集群，但是了解一下常見的Kubernetes高可用的實(shí)現(xiàn)方法才可以幫助我們更好的維護(hù)集群。etcd節(jié)點(diǎn)的是◎節(jié)點(diǎn)上部署◎時，為工作負(fù)載中各個的部署提供推薦的節(jié)點(diǎn)。如果我們在配置中加入了親和性、反親和性、選擇器、資源配額等配置的話，Schedule在調(diào)度也是化在用的集群進(jìn)行任何變更。是通信/raft/在中，數(shù)據(jù)的同步和n-1)/2（向下取整）。由這個算式我們可以發(fā)現(xiàn)，偶數(shù)個節(jié)點(diǎn)并不能為集群提供更多的冗余，所以通常情況357一個集群只能有一個或中也有(election-timeout)的時長來盡可雖然我們可以通過--consistency=s在linux上，我們可以通過ionice來配置磁盤優(yōu)先級：$sudoionice-c2-n0-p`pgrepetcd`$sudoionice-c2-n0-p`pgrepetcd`如果可以的話，給etcd掛載ssd盤可以顯著的提升etcd的性能。的才會＃命令行參數(shù)：$etcd--snapshot-count=5000＃環(huán)境變量：$ETCD_SNAPSHOT_COUNT=5000占用過多的內(nèi)存，甚至達(dá)到觸發(fā)＃命令行參數(shù)：$etcd--snapshot-count=5000＃環(huán)境變量：$ETCD_SNAPSHOT_COUNT=5000由于Etcd集群中數(shù)據(jù)會保持一致，所以當(dāng)我們發(fā)現(xiàn)某一個Etcd節(jié)點(diǎn)內(nèi)存緊張的時候，往往整個Etcd集群的節(jié)點(diǎn)內(nèi)存都以及處于比較緊張的狀態(tài)了。為Etcd的內(nèi)存狀態(tài)專門設(shè)置監(jiān)控和告警是很有必要的。即等對象確保這些◎：可以配置為模式與模式都會依賴于同時◎在后面的內(nèi)容中，我們會重點(diǎn)講解如何為集群中的應(yīng)用配置高可用性，使其能夠更加靈活的面對諸如worker節(jié)點(diǎn)不可用、網(wǎng)絡(luò)故障等種種問題高可用性是ITIT動變得高可用。為了能夠讓我們部署在上面的應(yīng)用（包括容器云平臺這個應(yīng)用）在這張圖中我們羅列了常見的5個潛在的故障點(diǎn)。通過認(rèn)識這些故障點(diǎn)，可以幫助我們通過冗余和反親和性的方式為應(yīng)用帶來更高的可用性。Worker節(jié)點(diǎn)通常都是運(yùn)行在物理機(jī)上的虛擬機(jī)，其可用性可能會受到其宿主機(jī)的硬件故障，網(wǎng)絡(luò)故障等故障的影響。為了避免單個Worker節(jié)點(diǎn)故障帶來的不可用，應(yīng)該要創(chuàng)建更多的Worker節(jié)點(diǎn)。服務(wù)器是從pod，以確保可用性和故障恢復(fù)。如果Worker節(jié)點(diǎn)未跨請使用)或服務(wù)的公共IPIPIPIPIP再將流量發(fā)送到此IP地址。但是有了多個集群就會存在多個集群打通的問題，直接的方法是通過手工或者工具將鏡像拷貝實(shí)現(xiàn)交付物流轉(zhuǎn)，或者是引入CICD實(shí)現(xiàn)交付物在不同集群中的流轉(zhuǎn)和發(fā)布。數(shù)據(jù)丟失接下來我們從Kubernetes中提供的功能下手，了解如何通過Kubernetes集群創(chuàng)建一個在集群中高可用的應(yīng)用。是對象的子集，其功能主要是維持某一個Pod的副本數(shù)量，通過這個功能我們可以實(shí)現(xiàn)/為多個和或者的io為AB如果在一定時間內(nèi)業(yè)務(wù)需求上下波動較多，可能會導(dǎo)致過多的擴(kuò)展與收縮，這種行為被稱為抖動我們希望應(yīng)用總是可用，又希望應(yīng)用能始終維護(hù)到最新的版本。對于這種情況，我們就需要滾動更新功能。滾動更新允許通過用新的Pod實(shí)例增量更新Pod實(shí)例。如果我們是通過Service的方式訪問的該Deployment，那么通過滾動更新就能做到無感知的更新服務(wù)。的修改的下一個版本出現(xiàn)了導(dǎo)致不可用的異常，或者寫了一個不存在鏡像。那么在更新時，舊的可用的在很多時候，服務(wù)可能不可用了，但是進(jìn)程仍然存在與機(jī)器中。或者服務(wù)可用，但是響應(yīng)時間超出我們的限制。又或者接口返回異常之類的其他我們認(rèn)為服務(wù)以及不可用的場景。這些情況下我們都需要進(jìn)行故障轉(zhuǎn)移。所以我們需要一種檢查服務(wù)是否健康的組件，這個組件可能需要預(yù)設(shè)一個目標(biāo)操作，響應(yīng)時間，響應(yīng)周期，正常響應(yīng)內(nèi)容等。然后這個組件就會周期性的檢查服務(wù)是否可用，并為故障轉(zhuǎn)移服務(wù)提供相應(yīng)的結(jié)果。在Kubernetes中，為健康狀態(tài)的檢查準(zhǔn)備以下幾種探針：◎◎通過靈活的配置探針，我們可以讓應(yīng)用及時的發(fā)現(xiàn)問題，并決定是否重啟。這樣由Kubernetes管理應(yīng)用的可用性與健康狀態(tài)后，可以減少很多額外的運(yùn)維工作。在Kubernetes集群中，我們通過CMO（Cluster-MonitoringOperator）來一鍵部署高可用監(jiān)控，并且評估告警規(guī)則，觸發(fā)告警后，會將告警推送到AlertManager中。因此，原生的監(jiān)控系統(tǒng)高可用體現(xiàn)在Prometheus的高可用和AlertManager的高可用。Prometheus高可用◎服務(wù)高可用：Prometheus通過Pull的模式去采集目標(biāo)的監(jiān)控?cái)?shù)據(jù)，這樣可以很容易的實(shí)現(xiàn)Prometheus的服務(wù)高可用，我們只需要部署多個Prometheus實(shí)例，配置相同的采集目標(biāo)即可?！驍?shù)據(jù)高可用：Prometheus內(nèi)置了時序數(shù)據(jù)庫TSDB，默認(rèn)會將監(jiān)控指標(biāo)數(shù)據(jù)以自定義格式保存在以PV掛載的本地磁盤中。AlertManager高可用是+的簡稱負(fù)責(zé)數(shù)據(jù)的展示。在集群中，我們可以通過進(jìn)行高可用部署。當(dāng)然，在實(shí)際情況中，我們可以將ES集群和Kibana部署在Kubernetes集群之外，同時引入Kafka等高性能消息隊(duì)列，可以有效避免采集端日志量過大，日志存儲無法及時落盤，避免日志的延遲和丟失；同時解耦采集端和存儲端，增加架構(gòu)的靈活性和擴(kuò)展性；可以有多個消費(fèi)者同時處理日志，提升日志處理效率。的抽象，為他們提供一個統(tǒng)一的內(nèi)部訪問入口。主Service的負(fù)載均衡可以有多個方式實(shí)現(xiàn)，目前Kubernetes提供三種模式：userspace，iptables以及ipvs。我們就可以在集群內(nèi)部通過Service輕松的建立起Pods之間的連接，但是在集群之外是無法訪問這些Service的，為了能夠從集群外訪問集群內(nèi)的服務(wù)，我們需要用Ingress將Service暴露出來。不過，雖然對象在對象是無法實(shí)現(xiàn)讓IngressController可以在更多節(jié)點(diǎn)上擴(kuò)展使得具有更多副本，提供高可用性。在多個ingresscontroller的環(huán)境中，我們借助外部硬件或者軟件負(fù)載均衡器來實(shí)現(xiàn)，采用負(fù)載均衡的方式，和前面提到的APIServer接入的高可用方式一致，在實(shí)際的生產(chǎn)環(huán)境中，我們建議將南北向的IngressLB和東西向的APILB進(jìn)行分離，以保證高可用和性能的實(shí)現(xiàn)。的可用性，在一組時A公司的流量使用一個中的每個◎Pod具有唯一網(wǎng)絡(luò)名稱：Pod具有唯一的名稱，而且在重啟后會保持不變。通過Headless服務(wù)，基于主機(jī)名，每個Pod都有獨(dú)立的網(wǎng)絡(luò)地址，這個網(wǎng)域由一個Headless服務(wù)所控制。這樣每個Pod會保持穩(wěn)定的唯一的域名，使得集群就不會將重新創(chuàng)建出的Pod作為新成員。中的每個可以有其自己獨(dú)立的◎有序的，優(yōu)雅的部署和縮放◎有序的，自動的滾動更新團(tuán)隊(duì)提出了概念。Srme，CRD擴(kuò)展了K8SAPI。其基本模式如下圖所示：V4或第三方的或開發(fā)的各種，用來部署和維護(hù)相應(yīng)的服務(wù)?？梢哉f，有狀態(tài)應(yīng)用上云，Operator可以很簡單，比如只負(fù)責(zé)軟件安裝，也可以很復(fù)雜，比如軟件更新、完整生命周期管理、監(jiān)控告警甚至自動伸縮等等。中如何創(chuàng)建高可容器云平臺本質(zhì)上可以視為一個無狀態(tài)的組件，平臺中的數(shù)據(jù)存儲在Kubernetes的Etcd中。我們將容器云平臺的通過的方式部署在集群中，并將其設(shè)置為一個不小于1暴露在同一個訪問到這個流量會走向其他的中。整N。”和”或者其他配置方式掛載多個鏡像倉庫的上，就可deRedis高可用設(shè)計(jì)鏡像掃描也是企業(yè)級鏡像倉庫必不可少的的功能之一。但由于鏡像數(shù)量往往非常的多，不論是jfrog的xray還是coreos的clair都會將需要掃描的鏡像層壓入一個隊(duì)列中。這里我們以Redis為例，講解如何為非關(guān)系型數(shù)據(jù)庫實(shí)現(xiàn)高可用。其他ip之間始終需要互相通信，進(jìn)而就需要為每一個配置服務(wù)發(fā)現(xiàn)。然而要為每一個配置Service，我們需要用到其Podname。所以我們需要有一組穩(wěn)定的標(biāo)識符（Label）來幫助我們發(fā)現(xiàn)RedisPod。在送到上，就會發(fā)生異常。為了保證能夠通過一個地址始終訪問到可用的s的4所有的不管是還是集群時都為了這些將是一個企業(yè)級的分發(fā)，以提高分布式開發(fā)站點(diǎn)之間的性能，并提高災(zāi)難恢復(fù)的彈性和冗余性。你可以使用在線的，也可以使用的Quay作為企業(yè)級鏡像倉庫，可以提供充足的功能，在高可用相關(guān)方面，包括了：◎地域復(fù)制：連續(xù)的地理分布可提高性能，確保您的內(nèi)容始終在最需要的地方可用?！虬踩┒礄z測集成：RedHatQuay漏洞檢測器（例如Clair）集成在一起，并掃描您的容器鏡像識別已知漏洞。◎持久存儲：支持多種存儲后端來存儲您的容器?！蚋呖捎眯裕嚎梢赃\(yùn)行RedHatQuay的多個實(shí)例以實(shí)現(xiàn)冗余，多個實(shí)例可以同時運(yùn)行，互相備份以共同分擔(dān)負(fù)載，提高可用性，防止單點(diǎn)故障?！騞t，和開放式ID連接◎指標(biāo)：內(nèi)置的Prometheus指標(biāo)導(dǎo)出可在每個實(shí)例上啟用臨時和批處理作業(yè)指標(biāo)，以便于監(jiān)視和