歡迎光臨
每天分享高質量文章

震坤行的容器雲實踐

本文通過分享 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)

分享創造快樂