歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

震坤行的容器雲實踐

2019-07-08 分類：後端 閱讀(730) 評論(0)

本文透過分享 Kubernetes 的好處，說明使用 Kubernetes 是震坤行的必然選擇，重點講解安裝 Kubernetes 以及目前震坤行的容器雲平臺實踐，最後分享震坤行的微服務架構實踐。
我們為什麼要用Kubernetes

 

擁抱微服務
微服務架構將巨大單體式應用分解為多個服務，每個服務透過 RPC 或者API 進行通訊，具備了各個自服務容易開發、維護的優點，另外子服務還具備獨立部署、快速擴充套件等優點。Kubernetes 對微服務本身有很好的支援，應用本身透過Deployment 進行部署，各個服務執行在 Pod 中，Pod 之間服務透過 Service 具備的服務發現實現相互間的通訊。同時微服務架構也恰好是雲原生應用的一種體現。
容器編排
Kubernetes 幫助使用者透過簡單易用的 API 高效地管理成千上萬個執行在容器中的微服務。Kubernetes 在 1.6 版本中已經支援 5000 個節點，這也說明 Kubernetes具備大規模叢集的編排管理能力。同時，Kubernetes 還具備包括監控、日誌、包管理等各種完善而專業的工具鏈，這將大大減輕運維和開發人員的負擔。
服務註冊發現
微服務的實踐過程中存在各種服務依賴關係，因此服務的註冊發現十分重要。Kubernetes 對服務進行抽象，透過抽象的服務層動態地解析到對應的容器服務。Kubernetes 同時提供了 DNS 和環境變數兩種方式，幫助實現服務的註冊和發現，Kubernetes 早期版本中使用的環境變數方式實現，現在 Kubernetes 則預設使用 DNS，透過使用 DNS 將服務名稱解析為服務的 IP 地址，然後 Proxy 轉到對應的 Pod。
 
主機資源利用率
Kubernetes 對主機的資源利用率，也是一種提升，基本上物理機，ECS，EC2，主機的利用率通常都在30%左右，極大的浪費了資源。使用 Kubernetes 後，可以根據主機資源使用情況，自動的排程 Pod 執行到那臺機器上。可以極大的提高主機的資源利用率。
彈性擴容
例如我們新上線的應用，因不同的業務場景，初次上線的時候不太確定給多少資源，預設就給應用 4G 記憶體，在 Kubernetes 中我們可以根據記憶體的使用率，來定義是否啟動一個新的 Pod，以及 Pod 最少多少個，最多多少個。
應用橫向擴充套件
例如我們應用在在訪問資源高峰期，應用需要進行新增機器，如果在 ECS、EC2 等機器，就需要再安裝服務呀，配置負載之類的，在容器中就簡單多了，直接修改ReplicaSet，修改節點數量，就會根據映象自動啟動新服務。
使用 Kubespray 安裝 Kubernetes

 

使用 Kubespray 安裝 Kubernetes 比常規要方便很多，配置完 ssh-ke y後，直接使用 Ansible 就可以快速的新增節點，刪除節點。

  1. 安裝 Ansible

  2. 叢集配置，修改映象源

  3. 部署 Kubernetes 叢集

  4. 安裝 SVC Ingress

  5. 安裝 Helm

  6. 新增節點

 

我們使用容器雲平臺

 

我們最早也是 LAMP，LNMP 平臺，後來因伺服器數量眾多，伺服器多數靠各專案的開發和運維進行管理，沒有統一的 CMDB，同時伺服器資源利用率也不高，有很大的資源閑置和資源浪費。我們是從 18 年 8 月份開始使用容器的。目前 60% 的業務都執行在容器平臺上。目前業務正在向容器雲平臺遷移中。
如何建設 DevOps 平臺
DevOps 平臺整體架構如下：
部署流程的最佳化：

整體的架構流程如下：

我們建設基於 Kubernetes 容器雲平臺，標的就是希望能夠提高研發人員從程式碼構建到業務上線的整體效率。這個過程是一個完整的 CI／CD 流程，包括從開發人員提交程式碼，進行程式碼 Review，到程式碼編譯、單元測試、整合測試，最後構建出業務映象，在不同的環境中部署業務，上下線服務等各個環節，形成統一的應用生命週期管理。
左側是持續整合框架，其中由應用基線管理、程式碼編譯、單元測試、釋出系統等模組組成。中間是多叢集統一管理平臺。業務會分別在開發、預發和生成三個不同的環境中部署。業務的最上層是由 SLB 軟負載統一管理 DNS、Nginx、LVS 等元件，將業務流量轉發給不同 Kubernetes 叢集中的業務容器。基於 Kubernetes 的 CaaS 由多叢集管理、映象管理、許可權管理、服務發現等子模組組成。
右邊是自研的監控告警系統和運維對接平臺，包括監控平臺、日誌平臺和運維 CMDB 等系統。
映象管理
我們是使用的 Harbor 作為自己的映象倉庫，目前都集中在阿裡雲，我們的服務都是基於基本的 JDK、Tomcat、Nginx、PHP、Nodejs等基於映象起來的，我們只需要維護這幾個基礎映象就可以。
許可權管理
使用者的容器叢集由許可權模組進行管理，目前提供給開發的只有日誌查詢許可權，賬戶與公司的 LDAP 對接。目前不支援虛擬賬戶的認證。
服務發現
我們是在各個專案中，單獨取用了一個自己寫的 jar 包，在 jar 包中定義了註冊中心地址。
穩定性
目前我們容器雲平臺，dev 環境是自建的，UAT 和 PRO 都是使用的阿裡雲。關於容器監控我們額外做了 Prometheus + Alerting 關聯釘釘機器人和微信報警。除了應用本身的錯誤外，整個容器雲平臺沒有出現過因服務類的 down 機情況。
成本
降低機器成本和運維成本是一項長期艱苦的工作，我們在遷入容器雲的過程中發現資源利用較好的兩種情況。

  • 混合排程。我們在提高容器部署的密度後，對業務帶來的好處就是快速擴充套件和資源混合利用，我們多條線的 Pod 會集中在一臺實體中，可以很好的提高單機資源利用率。

  • 彈效能力。電商行業的特徵決定了每年都會出現 618，雙 11，雙 12 等峰值流量。因為，在大促銷期間動態的租用公有雲服務，在平時只保留滿足日常流量的機器即可。

 

微服務架構

 

我們現在的微服務架構基本上也是多數公司的微服務架構，都是 Zuul + Eureka + Apollo 來完成了，Eureka本身有個監測機制，例如我的容器 A1、A2 註冊到了 Eureka，此時要部署容器，例如新部署的容器要 B1、B2，在健康檢查完全透過後，A1、A2已經被替換掉。在 Kubernetes 層面做到了無縫切換，但是 Eureka 本身還會將 A1、A2 保留約 2 分鐘。也就是這個時間內，Eureka（註冊中心）會同時存在 4 個 Pod。
在這個時間點透過 Zuul 來訪問服務的話，則會有 50% 的請求釋出到老地址上去。推薦更換掉 Eureka，使用 Istio，Istio 可以避免這個問題。
我們現在正在替換掉 Eureka，向 Istio 遷移。
Istio 具備統一的入口。

  • 動態服務發現和路由規則

  • 負載均衡

  • 策略和請求tracing

  • 熔斷器

  • 健康檢查，基於百分比流量拆分和灰度釋出

  • 認證和鑒權

我們左側註冊中心，到時候這一塊就會被砍掉，包括前端的閘道器，也會使用 Istio 來代替。目的是為了灰度釋出這一塊。

 

Q&A;

 

Q：Kubernetes 雲平臺和物理機平臺，在效能對比上，Kubernetes 差多少？
A：Kubernetes 的最小單元是 Pod，Pod 是跑在雲主機上的。整個 Kubernetes 都是基於雲主機/物理機來完成的。
Q：資料庫叢集是否適合丟在 Kubernetes 上，如果千萬級的日活是否有好的解決架構？
A：首先資料庫是可以跑在 Kubernetes 上的，資料庫叢集直接互連的 IP 是可以透過 Kubernetes 的內部 .svc.cluster.local 來代替。如果跑資料庫叢集，則需要將 Pod 使用硬碟 volume mount 將資料對映到硬碟上。目前我們 DEV，UAT 環境的資料庫在叢集中。針對千萬級的日活，主要是看瓶頸卡在那一塊。
Q：生產環境會跟著社群版本積極更新 Kubernetes 版本不？或者什麼頻率？
A：這個一般不會跟著社群積極更新，除非是當前版本出現重大bug，或者新功能比較適用於我們，才會考慮更新。
Q：Istio 有沒有進行最佳化，QPS 大概是多少？如有最佳化都是從那些方面進行最佳化的？
A：Istio 目前是進行過最佳化的，最佳化的細節暫時還未統計。當前的 QPS 我們大約是每秒 5000 個左右吧。更具體的要看業務。
Q：你們的 Kubernetes 叢集節點規模有多大？日活？Kubernetes 運維團隊多少人？
A：Kubernetes 叢集節點有，dev 24臺 4C 32G，UAT 30臺 4C 32G，生產 67臺 8C 64G，Kubernetes 運維團隊2個人。
Q：更換成 Istio 之後，就不需要單獨部署 Ingress 了吧？
A：需不需要不用 Ingress，具體還是得看下業務型別。我們是微服務 API 類的，走的 Istio，靜態頁面類，CDN –> Ingress 。或者是CDN –> SLB –> Pod。
Q：請問 Kubernetes 如何和雲服務的彈性伸縮配合使用，例如，因為業務需要，短時間內從 2 臺節點擴充套件到十多臺節點。可以做到像雲服務的彈性伸縮那樣嗎？不提前配置節點，或者如何讓 Kubernetes 自己觸發雲服務的彈性，自動新增雲服務的彈性節點。
A：我們一般會對容器雲的 ECS 資源保留 20%-25%。如果發現資源不夠了，就會提前購買 ECS 加進去。短時間擴容 Node 幾點的話，就多購買幾臺 ECS 同時加進去就可以了。Pod 是可以做彈性伸縮，ECS雲主機也可以做彈性伸縮增加到 Kubernetes 叢集裡邊，這個阿裡雲提供服務的。
Q：請問一下註冊到註冊中心的 IP 是容器內 IP 的問題如何解決？
A：我們是將註冊中心部署到 Kubernetes 叢集中的。註冊中心的內網 IP 和 Kubernetes 的內網是互相可以通訊的。
已同步到看一看
贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂