容器云平臺的高可用設計Ⅱ目錄Ⅱ1111133457778889PAGE08PAGE08

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