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

如何用Kubernetes建立CDN服務

 

kubeCDN:基於Kubernetes的自托管CDN。
GitHub: https://github.com/ilhaan/kubeCDN。
在這篇文章中,將討論為什麼要有CDN服務,如何用Kubernetes建立CDN服務,然後重點討論kubeCDN的設計和實現,它是一個用於簡化多地域部署Kubernetes集群並且提供CDN服務的工具,以便在全球範圍內部署高可用的服務。

 

用戶越多,問題就越多

 

互聯網改變了人們交流觀點和分享信息的方式。然而,這種傳遞信息的方式並不盡完美。因為互聯網已經成為用戶獲取信息的第一站,任何阻礙或減緩用戶獲取信息的方式都讓人不爽。我們都經歷過為了等待加載完共享文件或者視頻流而不得不等待幾秒或幾分鐘的”煎熬”。這種”煎熬”, 會影響用戶體驗,用戶會尋求其他的替代方案。沒有任何公司會想因為這種差的用戶體驗而失去用戶,但是避免這種問題,會有些技術上的挑戰。
就像下麵的圖,用戶一直在等待,等待……
用戶感知到互聯網服務延遲的主要原因是運行服務的服務器距離用戶比較遠。如果服務器在上海,而用戶在紐約,那距離上增加的延遲會導致資料獲取較慢,用戶體驗變差。
用戶距離服務器越遠,延遲就越大
將服務器部署到離用戶位置更近的地方可以減少這種延遲,但這樣做並不是那麼容易,因為管理全球基礎設施資源需要投資很大。

 

解決方案:內容分髮網絡(CDN)

 

剋服上述問題的一種方法是使用第三方CDN提供商。像Akamai、CloudFlare和Fastly這樣的CDN提供商將企業在一個地區建立的基礎設施服務擴展至全球,讓全球用戶受益。
CDN提供商通過在其全球不同節點(PoPs)之間快取靜態內容,減少用戶的訪問時延。這些PoPs由若干邊緣服務器組成,為請求靜態資源(如:圖片)的用戶提供快取。如果沒有找到請求的資源,則邊緣服務器將從源服務器或就近的服務器獲取資源。這種方式減少了不同地域的用戶訪問服務的時延。
越多更多的關於CDN的知識,參考:https://www.digitalocean.com/community/tutorials/using-a-cdn-to-speed-up-static-content-delivery。
CDN服務商的問題

 

儘管CDN提供商提供了一種方便的解決方案,但是這種方式也存在一定的問題。
第一個問題是安全問題。用第三方的CDN服務商,開始依賴外部服務來確保用戶獲得最佳體驗,最重要的是失去了對用戶資料安全性的控制。第三方CDN提供商系統中的漏洞(比如2017年的這個漏洞[1])會對用戶的安全和隱私造成嚴重影響。
第二個問題,CDN提供商可能並不總是考慮你的最佳利益,他們會優先考慮他們的利潤而不是你的服務質量。
最重要的問題是CDN服務商可以拿到你的業務資料。CDN服務商可以確定你的用戶的所在位置、用戶使用服務的時間以及他們使用何種設備訪問服務。這樣的業務資料對你的競爭對手非常有價值,而向第三方泄露信息會使你的業務有客戶流失的風險。
對於許多團隊來說,這些利弊可能值得使用CDN服務商的便利性。然而,對許多頂尖的工程團隊,比如Netflix和LinkedIn,已經決定在內部解決這個問題。如果想做同樣的事情並構建自己的CDN,就嘗試用kubeCDN。

 

kubeCDN

 

kubeCDN可以解決上述的問題。kubeCDN是一個基於Kubernetes的自托管CDN。作為一個自托管的解決方案,可以維護對基礎設施的完全控制。它消除了第三方CDN服務商的需要,並擁有了對從服務器到用戶設備的資料流的控制。
架構設計
kubeCDN使用Terraform在選定的區域部署EKS和AWS基礎資源。Route53,用於在多個區域之間路由用戶,而ExternalDNS[2]用於在部署新服務時自動創建DNS記錄。
下圖演示了在kubeCDN中如何使用Terraform。
Terraform用於部署kubeCDN所需的基礎設施,Route53用於將用戶流量路由到特定區域。如下麵的圖,在兩個AWS區域us-east-1和us-west-2中分別部署了一個視頻服務器,在Route53上為區域設置一個托管區域,併為部署集群的每個區域設置了記錄。使用基於延遲的路由策略將用戶路由到延遲最低的區域。在這個演示中[3],用戶總是被路由到地理上最近的區域。然而,情況並非總是如此。internet上的延遲可能隨時間而變化,Route53使用這些度量值來確定在實現路由策略時將用戶路由到何處。
上面的圖展示了Route53如何使用兩個區域中創建的集群來路由用戶流量。舊金山的用戶被路由到us-west-2中的集群,而不是us-east-1中的集群,因為到us-west-2提供了較低的延遲。
Route53上還有其他一些路由策略,可以與kubeCDN一起使用,以適應各種應用程式需求。具體參考:https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html。
解決的問題
kubeCDN使基礎設施服務可以在幾分鐘內輕鬆地擴展到全球不同地域。部署上述所述的集群所需的基礎設施大約需要15分鐘,與使用AWS控制台進行手動部署相比,效率有了顯著的提高。
除了易於擴展之外,kubeCDN還可以通過在低用戶活動期間分解區域來優化基礎設施成本。當預算緊張時,為了確保最大的盈利能力,這種基礎設施成本優化水平可能是至關重要的。

 

開發的挑戰

 

和其他專案一樣,在開發kubeCDN時遇到了一些問題。下麵將描述兩項比較難解決的問題。
Terraform代碼重構
kubeCDN中用於將EKS集群部署到某個區域的Terraform代碼是基於HashiCorp 單獨創建的代碼庫。儘管代碼非常清晰,有詳細的說明,但它不能進行多區域部署。部署的區域都是硬編碼的,需要為每個所需區域複製儲存庫。這是一個繁瑣的手工過程,很容易由於人為錯誤導致配置錯誤。它還將導致管理結構的隨意性,使監測基礎設施和優化成本變得困難。
重構Terraform代碼是解決這個問題的一種方法,但是,挑戰在於如何進行重構。在閱讀了相關的文章並查看了另一個具有類似需求的開源專案之後,認為下麵所示的結構是現階段組織專案基礎設施部分的最佳方式。

 

  1. ├── terraform (Dir containing all infrastructure code)
  2. ├── cluster (EKS cluster components)
  3. ├── main.tf
  4. ├── outputs.tf
  5. ├── rbac.yaml
  6. └── variables.tf
  7. ├── main.tf (Main .tf file where regions are specified)
  8. └── variables.tf
  9. (Some files have been removed for brevity)
在上面顯示的目錄結構中,main.tf是指定所有所需區域的地方。區域部署使用以下代碼段定義:
  1. module "" {
  2. source = "cluster"
  3. region = ""
  4. }
這使得在一個配置檔案中輕鬆定義新區域成為可能,而這個配置檔案也易於管理。
ExternalDNS的問題
ExternalDNS是一個通過Kubernetes資源動態配置DNS記錄的工具。可以與DNS服務商(如Route53等)對接。當將新服務部署到Kubernetes集群(例如Web服務器)時,ExternalDNS創建DNS記錄,以便使用公共DNS服務器發現web服務器。
對於kubeCDN,計劃使用ExternalDNS為不同的區域部署自動創建DNS記錄,並配置Route53使用基於延遲的路由策略將用戶路由到延遲最低的區域。雖然能夠做到這一點,但必須解決一些與ExternalDNS有關的問題,這些問題無法完全自動化不同區域服務的DNS記錄的動態配置。
kubeCDN的改進

 

開發kubeCDN只用了三周的時間,還有非常大的改進空間,其中有幾個方面的改進方向可以讓它更加強大。
不同雲服務商的支持
目前,kubeCDN僅基於AWS。這主要是因為Insight的Fellows在專案中可以使用AWS。對多個雲服務商(如GCP和Azure)的支持,會避免僅使用一個雲服務商,在雲服務商宕機時造成的問題。
目前,kubeCDN是用AWS提供的EKS管理的Kubernetes服務。要支持其他雲服務商的支持,需要滿足以下條件之一:
  • 合併對所有雲服務商的Kubernetes服務。雖然這將簡化部署,但是將不同的托管服務合併到kubeCDN中將非常困難。

  • 使用自定義Kubernetes部署。這將涉及使用kops安裝一個自定義Kubernetes集群,使用來自所選雲服務商的基礎設施。

儘管kops安裝Kubernetes的方式,從長期考慮似乎是最佳的選擇,但需要大量的開發工作。即便如此,採用kops的Kubernetes安裝在未來將為kubeCDN帶來較大的靈活性。
多地域的自動伸縮
雖然在全球範圍內擴展基礎設施可以極大提高用戶體驗,但是在許多地方,並沒有必要7*24小時地運行服務。從盈利的角度來看,移除一個地區的基礎設施,並讓該地區為數不多的(或者可以忽略不計的)用戶有較多的延遲,會帶來成本的一定降低。
為了實現這一點,需要一個監視方案來監視所選的度量。當該指標在某個區域達到預定義的閾值時,可以移出該地域的基礎設施服務。如果某個特定區域的用戶出現峰值,則可以使用類似的閾值在預先定義的區域中自動啟動擴展該地域的基礎設施服務。
預定義區域串列
kubeCDN使得將EKS集群部署到新區域變得很容易。但是,有比當前為每個區域複製三行代碼的方法更好的方法來實現這一點。在檔案中列出所需區域是一種更簡潔的方法。
該特性可以將與前面提到的多地域自動伸縮特性很好地結合在一起。向kubeCDN提供兩個區域串列,其中一個區域的基礎設施服務需要連續運行,另一個區域可以自動伸縮,這將極大地簡化基礎設施服務管理。

 

總結

 

kubeCDN簡化了Kubernetes集群的跨地域配置,並可以方便的擴展。由於是自托管的,kubeCDN允許適應獨特的基礎設施需求,併為基礎設施的管理提供了強大的靈活性。
然而,有些限制和增強的功能可以讓kubeCDN成為更健壯的工具。其中一些已經在這篇文章中討論過了。影響未來kubeCDN另一個主要因素是Kubernetes專案本身的改進。預計,隨著Kubernetes Federation的成熟,未來kubeCDN的功能和特性將發生巨大的變化。
相關鏈接:
  1. https://arstechnica.com/information-technology/2017/02/serious-cloudflare-bug-exposed-a-potpourri-of-secret-customer-data/

  2. https://github.com/kubernetes-incubator/external-dns

  3. https://www.youtube.com/watch?reload=9&v;=N31tho5CRNY&feature;=youtu.be

原文鏈接:https://blog.insightdatascience.com/how-to-build-your-own-cdn-with-kubernetes-5cab00d5c258

已同步到看一看
赞(0)

分享創造快樂