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

如何用Kubernetes建立CDN服務

2019-04-15 分類：後端 閱讀(324) 評論(0)

 

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)
標籤：

相關推薦

熱門標籤

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)

熱門文章

分享創造快樂