Prateek Dubey
-5 分鐘閱讀
這篇文章是關於我在以前和現在的組織中圍繞資料基礎設施所做的一些工作。在過去的幾年裡，我一直在使用Kubernetes作為容器協調平臺來管理docker容器，同時也執行大資料和ML工作負載。我想現在是時候與大家分享一些這方面的知識和我的心得了。讓我們來看看我們如何在Kubernetes上建立一個數據平臺。
資料基礎設施的狀況
當我加入我現在的組織時，我們在裸機CentOS伺服器上使用CDH 6。1（Cloudera Distribution Hub）On-Premise來執行我們的資料和ML工作負載。我們利用CDH來管理Apache Kafka叢集、Apache Hive、Apache Hadoop和Apache Spark。我們的資料工程師在閘道器節點上使用crontab排程資料和ML管道。我們缺少一些重要的功能，如資料治理、適當的作業排程、可觀察性/監控、任何DevOps流程和最重要的可靠性。
為了滿足資料治理的要求，我首先將Apache Atlas、Apache Ranger和HUE新增到我們的資料基礎設施中。這些技術幫助我們為儲存在Hive和HDFS中的資料新增訪問控制，並提供元資料發現、沿襲和編目功能。我開始以docker容器的形式執行所有這些服務，並將它們與CDH服務整合。與CDH的整合並不是一件容易的事，因為它需要不斷地更新配置屬性和多次重啟Cloudera叢集。
Cloudera資料平臺
替換CDH的動機僅從這裡開始。我們的要求很簡單——
重新設計平臺，使整合其他服務成為一項無縫任務。
減少我們的CDH環境中由於記憶體問題和計算資源（CPU和記憶體）利用不當而導致的頻繁停機。
我們有計劃在未來將一些工作負載從內部部署轉移到AWS，所以我們希望我們的遷移到雲端是無縫的。
因此，我開始了現代資料平臺的工作，目的是建立一個不依賴於雲的、雲原生的和具有成本效益的解決方案。在我之前的工作中，我積累了相當多的系統和基礎設施設計經驗。我的目標是利用這些經驗，利用大資料領域廣泛認可的開源技術建立一個數據平臺，並建立一個可以在任何地方（內部或雲）部署的平臺。
我從AWS的解決方案開始，做了一個POC，向我們的領導層展示我們如何利用Kubernetes來建立一個數據平臺。這個解決方案看起來像下面這樣 -
AWS資料平臺
POC是成功的，我們能夠實現我們的關鍵任務，即：
在Kubernetes上構建一個數據平臺解決方案。
為我們的資料科學家和資料工程師在Kubernetes上設定JupyterHub。
在Kubernetes上執行Apache Spark作業，處理TB級的資料。
使用同樣在Kubernetes上執行的Apache Airflow安排Apache Spark作業。
我們能夠證明建立這樣一個平臺的價值，將其用於我們的專案，甚至跨越不同的專案。我們還能夠圍繞這樣一個平臺提出一個好的CI/CD解決方案。我的建議是使用EKS（Elastic Kubernetes Service）作為部署所有資料平臺服務的容器編排平臺。
這給了我們最終用Rancher Kubernetes平臺上執行的現有解決方案取代內部執行的CDH的途徑。該解決方案看起來像下面這樣 -
企業內部資料平臺
如果你仔細觀察，我們能夠設計出一個完全相似的資料平臺，可以在AWS和On-Premise裸機上執行。
我從一個有3個主節點和3個工作節點的高可用Rancher 2。5。5 Kubernetes叢集開始。到現在為止，我們的叢集已經增長了8倍，全部使用Ubuntu作業系統。我們決定用Ubuntu取代CentOS，因為CentOS的支援即將消失。選擇Rancher的原因很簡單——它是完全開源的。
在建立這樣一個平臺的過程中，一些關鍵的經驗是： ——
仔細閱讀文件。Rancher寫了一份關於如何建立一個高可用、生產就緒的Kubernetes叢集的驚人文件。
在Kubernetes上執行HDFS是可能的，但是我們還沒有看到任何文章/部落格說公司已經在生產中使用它。因此，我們決定用Ceph代替HDFS。Ceph可以使用Rook部署在Kubernetes上，也可以部署在沒有Kubernetes的裸機上。
使用MetalLB作為負載平衡器，在企業內部執行K8s應用程式。
使用Bind9 DNS伺服器和外部DNS來更新帶有Ingress記錄的DNS伺服器。
我們使用Ceph來建立具有一次讀取寫入（RWO）訪問模式的永續性卷，使用Longhorn來建立多次讀取寫入（RWX）訪問模式。Longhorn是Rancher公司為Kubernetes建立的一個分散式儲存平臺。
讓我也帶你看看我是如何為這個平臺建立我們的CI/CD解決方案的。我決定用GitLab做CI，用ArgoCD做CD。我們還使用GitLab來儲存我們的Docker映象。我想把我們的CICD作為兩部分解決方案來介紹，一部分涉及我們的Kubernetes平臺，另一部分是我們的資料管道。
CI/CD Kubernetes平臺
CI/CD Kubernetes平臺
這是一個跨組織使用的標準CICD流程。使用GitLab來儲存所有的工件，同時利用GitLab進行CI。在我們的案例中，由於我們的平臺是在內部執行的，所以我們也使用GitLab進行Docker註冊。我建立了Gitlab CI管道來構建和釋出映象到GitLab Container Registry。我使用ArgoCD將對Helm圖表的任何修改部署到Rancher Kubernetes叢集上。
CI/CD資料管線
CI/CD資料管線
為了給我們的資料ETL管道建立一個CICD流程，我使用了與我們的K8s叢集相同的方法。我們使用Apache Airflow來安排ETL管道，並設定了Gitlab CI管道來推送PySpark指令碼到Ceph桶。我們的Airflow部署啟用了Git Sync，因此DAG會自動同步到Airflow排程器，從而每60秒同步到Airflow webserver。
我在我們的DAG中使用KubernetesPodOperator來提交Spark作業到我們的K8s叢集。下面是一個使用GitLab Container Registry中的docker映象的DAG的例子：-
https：//gist。github。com/dprateek1991/3342b0e32a4de68ee60495a276b789d4
最後，在結束這篇文章之前，我想說我希望我的工作能讓人瞭解如何使用Kubernetes On-Premise，以及我們如何在其上有效地構建資料平臺。
請關注我即將發表的關於我們如何在EKS和On-Premise Kubernetes上執行JupyterHub的文章。
