知行學院總結 | 如何打造一個企業級 Kubernetes 發行版

知行學院是青雲QingCloud 爲廣大 CIO、架構師、開發者、運維工程師、技術愛好者提供的一個雲計算、大數據、容器等技術的最佳分享與實踐平臺。其中包括線上技術公開課、雲產品解析、線下實踐課堂、行業沙龍等衆多知識分享形式。html

本次咱們邀請了青雲QingCloud 容器平臺產品經理於爽(Calvin Yu),帶來《如何打造一個企業級 Kubernetes 發行版》。安全


視頻戳這裏網絡


正文:架構


做爲 KubeSphere 線上培訓教程的第一節課,今天的內容覆蓋幾個方面:第一個是介紹一下 KubeSphere 這款容器產品產生的背景,第二給你們比較一下 KubeSphere 和原生的 Kubernetes 的區別,第三部分會介紹一下 KubeSphere 高級版 1.0.0 裏面主要的功能,最後會有一個 Demo,給你們展現一下 KubeSphere 總體的使用方式。負載均衡



第一部分
KubeSphere 產生的背景


這個是 Gartner 在今年發佈的調研報告,Gartner 認爲到 2020 年大概有 50% 的企業會將內部很是重要的業務容器化,放到容器裏面去跑、並且是放在生產環境裏面跑。2018 年這個比例只有 5%,而兩年的時間將會有十倍的提高。運維



那麼,爲何如今愈來愈多的企業要採用容器呢?分佈式


容器帶來的改變



第一個緣由就是相比於傳統的虛擬化技術,容器能夠把主機資源的利用率最大化,能夠帶來更輕量地資源消耗,避免無心義的資源損耗;微服務


第二個就是經過容器咱們能夠把IT界討論的比較熱的一些話題,好比 CI/CD、微服務這些從理論變爲現實。特別是 CI/CD 這一塊,這也是不少使用容器的客戶的主要訴求,在沒有容器以前,並非說沒法作CI/CD,但缺乏了容器這種輕量的標準化的交付方式,帶了架構沉重、效率低下、環境不一致等問題。工具


基於標準化容器鏡像的構建方式以及統一鏡像的分發倉庫,用戶可使用一系列自動化運維的工具完成從開發、代碼提交、測試、預發佈、發佈一整套完整的流水線,它相比較於傳統的基於虛擬機的交互方式更經濟、更高效。同時基於容器咱們能夠實現跨平臺的部署,企業就沒有平臺綁定的風險了。學習


使用容器須要管理調度平臺,Kubernetes 無疑是如今這種管理平臺市場裏最主流、最受承認的一個平臺,咱們知道用戶想使用 Kubernetes 的熱情是很是高漲的,可是它有一系列的問題。


使用 Kubernetes 的問題與挑戰



首先就是學習成本比較高。Kubernetes 是由谷歌初始開源的一個項目,它起源於谷歌本身的 Borg 系統,你們都瞭解谷歌是一家技術出身的公司,Borg 系統或者說 Kubernetes 發佈之初的時候給人的印象也是如此——是面向開發者、面向技術人員的,使用起來很是的複雜。谷歌在裏面又抽象了不少他本身理解的調度層面的一些概念,用戶想要去了解、而後再去使用這個平臺須要很長的學習過程。


同時 Kubernetes 部署安裝很是複雜。在兩年前你要想搭建一套 Kubernetes 的平臺,可能要花一週甚至更長的時間。固然到了如今,因爲它愈來愈獲得你們的承認,有不少自動化工具能夠幫助你作這件事情,但即便有了這些工具的支撐幫助,去了解這些自動化工具其實也是一個二次學習的成本。


另外,Kubernetes 專一作的是底層分佈式的容器調度平臺,它把上游的一些業務場景以及跟底層資源的對接都開放出來,經過各類開源項目和廠商去支持。好比說存儲,它經過 CSI 標準,把標準定出來以後,存儲廠商能夠接進來,網絡、容器運行環境也都是如此;包括上游的一些場景,好比 CI/CD、微服務、這些都是經過其餘開源項目去支持的。


因此當企業想要去經過 Kubernetes 完成這種業務場景的交付,那麼就要去選型、去選擇合適本身的開源項目,這些對企業來講也是很麻煩的一件事情。


綜上能夠看出,想使用 k8s 它的隱造成本是很高的,企業須要運維一個專業的團隊去負責這個平臺,同時 Kubernetes 多租戶的模式很是複雜、安全性低,另外它做爲經過開源社區支持的一個項目,缺少本土化支持,這都是在使用 Kubernetes 過程當中很是典型的一些問題和挑戰。


因此基於客戶的這些痛點,咱們開發了咱們本身的 k8s 發行版 KubeSphere,咱們的 KubeSphere 和原生的 Kubernetes 的區別是什麼呢?


第二部分
KubeSphere 和原生的 Kubernetes 的區別


首先來講原生的 k8s 它的安裝是很是複雜的,可是咱們的 KubeSphere 很是簡單,只須要配置兩個配置文件,而後就能夠一鍵安裝了。



另外,因爲它整個安裝過程是須要拉取各類容器鏡像的,有些鏡像因爲網絡等緣由,拉取起來比較複雜,而 KubeSphere 支持離線安裝,在網絡環境比較限制的狀況下或者說在一些私有云的場景、私有化網絡狀況下,經過離線安裝,你能夠很方便地搭建一個 k8s 管理集羣。


原先的 Kubernetes 是沒有界面性的東西來輔助工做的,你能夠額外使用開源的 Dashboard,可是 Dashboard 提供的功能是比較弱的,體驗也不是很好,而 KubeSphere 的界面功能比較強大,你們能夠本身去體驗一下。


原先的 Kubernetes 的多租戶和權限控制是經過配置文件和命令行去完成的,咱們的 KubeSphere 提供了統一的管理入口、多租戶的管理方式,能夠提供資源和操做級別的權限配置。


另外,Kubernetes 沒有應用管理的概念,它是經過 Helm 去作的,使用命令行能夠完成 Helm 應用包的部署、升級、刪除的工做。而 KubeSphere 提供了完整的應用生命週期的管理,從應用的開發、發佈、版本管控、後面使用的運維,均可以提供一整套的完整的工具。


另外原生的 Kubernetes 是沒有 CI/CD、微服務這些業務場景支持的,在咱們的 KubeSphere 裏面提供了這些業務場景的支持。


監控告警,Kubernetes 它的配置是相對比較複雜的,須要基於不一樣的開源項目去選型。而咱們提供了更簡便的方式,同時咱們也能夠作第三方的集成支持,能夠把你的監控數據導入到企業現有的監控系統裏面。


而後是存儲網絡。Kubernetes 存儲網絡是兩大塊,有不少開源項目的支持,咱們 KubeSphere 也集成了這些主流開源的網絡存儲的解決方案,同時青雲做爲一個雲廠商,咱們也開發並開源了咱們本身的存儲網絡插件去對接青雲如今的 SDN 網絡、SDS 塊存儲,可使用青雲的雲平臺上的硬盤。


咱們還有另一款分佈式存儲產品 NeonSAN,它是能夠獨立部署的,咱們也開發了對應的 NeonSAN 的存儲插件。另外像雲平臺上有負載均衡器,咱們也開發了負載均衡器插件,若是你把 KubeSphere 部署在青雲的雲平臺之上,那麼你能夠經過咱們的負載均衡器插件,在暴露服務的時候選擇負載均衡器的類型,那麼你的服務就經過負載均衡器去暴露了。


簡單地歸納一下:KubeSphere 是在 Kubernetes 之上構建的企業級分佈式多租戶容器管理平臺。


它的幾大亮點包括:統一門戶、實現跨平臺管理多種 k8s;學習成本比較低,UI 體驗比較好;提供了多場景支持的總體化解決方案;能夠很方便地集成第三方的系統;咱們提供多租戶、更細粒度的權限管理方式;咱們除了提供開源的網絡和存儲解決方案,還有咱們本身特點的網絡和存儲方案。



這是 KubeSphere 一個簡單的架構圖,底層能夠支持不一樣的基礎設施,如物理機、vmware 虛擬機或者是公有云上的雲主機,中間的門戶管理多種 k8s 集羣,網絡和存儲咱們支持各類存儲插件、網絡插件,同時咱們還有本身的網絡和存儲插件的支持。


咱們本身做爲雲廠商有本身的負載均衡器插件,同時咱們還提供基於物理交換機的負載均衡器解決方案,這對物理機的部署是很是重要的。


它的上層提供了幾大場景的支持,包括多集羣的運維調度、CI/CD、微服務治理、應用生命週期管理。其中應用生命週期管理,咱們是基於 OpenPitrix——由咱們主導開源的一個項目,你們能夠在 GitHub 上搜到,它是實現多雲應用管理的一個平臺。


第三部分
KubeSphere 高級版 1.0.0 的主要功能



這是 KubeSphere 的全景功能圖,你們能夠看到這裏面體現了剛纔提到的幾大功能的支持。


多租戶管理


好比說多租戶這一塊,從集羣層面咱們提供了平臺管理角色;在集羣下面咱們提供了多租戶的支持,咱們叫作企業空間;企業空間底下咱們提供了項目,對應 k8s 裏面的就是 Namespace;另外基於 CI/CD 的場景,咱們有 DevOps 工程層級的資源支持,若是企業想去運行本身的 CI/CD 流水線,能夠建立一個 DevOps 工程,而後在裏面跑本身的流水線。


KubeSphere 定義了集羣層級、企業空間層級、項目的 DevOps 工程層級,這是三個層級,它綁定的是每一個層級資源不一樣的角色,角色底下關聯的是不一樣的用戶。關於多租戶,咱們接下來會專門有一期線上培訓,給你們介紹裏面詳細的概念和操做。


從右邊這一塊能看到,咱們支持的 k8s 資源工做負載類型有不少,包括部署、有狀態副本集、守護進程集、任務和定時任務。存儲這邊除了主流的開源存儲插件,咱們還有 NeonSAN 分佈式塊存儲,以及支持青雲的塊存儲;暴露服務能夠經過 Ingress 的方式;配置上咱們支持 Secret 和 Configmap。


DevOps 工程裏面咱們提供了可視化流水線,咱們支持 Jenkinsfile in&out of SCM。這是什麼意思呢?其實有不少企業已經用了 Jenkins 這種流水線管理平臺了,他們已經有了本身的 Jenkinsfile 去跑本身的流水線,並把 Jenkinsfile 做爲他們代碼管理的一部分,放在本身的代碼倉庫裏面。


好比說 OA 項目,我要跑本身的流水線,有一個代碼倉庫,你把 Jenkinsfile 放在這個代碼倉庫裏面了,咱們支持這種方式,那麼你在配置流水線的時候,告訴我代碼倉庫的位置,我會自動地去拉取你已有 Jenkinsfile 裏面的內容,去把流水線構建出來並運行。


若是你以前沒有 Jenkinsfile 、,那麼經過咱們提供的這種可視化流水線構建工具,你能夠在頁面上簡單地去操做、建立本身的流水線。


同時咱們的 DevOps 工程支持憑證管理,能夠去幫助你訪問各類代碼倉庫、鏡像倉庫等等。


另外在高級版 1.0.0 中咱們提供了獨立的監控中心,能夠提供不一樣維度的監控功能,好比說咱們能夠從集羣視角去查看各類指標,包括內存、CPU、磁盤、容器組運行狀況、網絡等等。從應用視角也能夠去監控整個業務的運行情況,好比說你的項目裏面使用多少資源,你的項目底下的應用使用多少資源,都是能夠去查看的。


總結一下多租戶的部分:



咱們如今已經支持了 LDAP 和 AD 的統一認證,同時咱們支持 OAuth 的認證集成。


網絡與存儲


除了支持各類主流的網絡存儲插件,咱們也提供了自主可控的網絡和存儲。特別是在一些關鍵性業務上,若是你使用一些開源的插件去跑一些關鍵性業務的話,一旦出了問題,服務、支持都是很頭疼的事情。這種自主可控的、能夠獲得及時支持的網絡和存儲的方案,對於某些客戶仍是很是重要的。



做爲咱們青雲平臺的企業用戶,在網絡上您可使用咱們提供的開源的 hostnic 網絡方案,pod 上直接綁定青雲 SDN 的網卡,能夠實現網卡的直通。


而後咱們還提供基於物理交換機的負載均衡器解決方案,且不綁定設備,好比說你能夠本身採購華三的交換機,經過物理交換器達到負載均衡器暴露服務的場景支持。


咱們本身的 CSI 存儲插件能夠直接掛載青雲的 SDS 塊存儲,咱們也開發了 QingStor CSI 的插件,這個 pod 能夠直接掛載 NeonSAN 的塊存儲。


CI/CD on KubeSphere


基於 CI/CD 咱們能夠實現容器的標準化交付物,快速構建、升級、回滾應用環境,提供完整的自動化工具的鏈條,下降運維成本,同時 CI/CD 爲微服務場景提供了強有力的支持。好比說把一些業務拆分放在不一樣的容器裏面去,而後再經過 CI/CD 構建整個的開發、測試和部署的鏈條,實現快速發佈,下降管理成本。


咱們如今發佈的是 1.0.0,剛纔也提到 Jenkinsfile In and out 和 Source Code Management 兩種方式,咱們即將發佈的 2.0.0 版本會支持 source to image,代碼到鏡像的構建,還支持代碼安全掃描。


集羣運維


咱們在項目這個層級提供配額管理,好比這個項目底下你能夠去使用多少 CPU、多少內存、能夠建立多少個部署、多少個服務,這些均可以經過配額去配置。在工做負載上除了支持 k8s 原生以外咱們還支持 HPA,即 pod 的自動彈性伸縮,你能夠設置本身的CPU指標,pod 的下限和上限,當指標達到、超過的時候,pod 會自動的擴容。


應用的生命週期管理


這個是經過咱們本身開源的一個項目 OpenPitrix 作的,OpenPitrix 是多雲應用的全生命週期管理,支持不一樣的雲廠商,如阿里雲、AWS 等,k8s 也是 OpenPitrix 支持的運行平臺。


它底層是基於 Helm 去作的,也就是說 OpenPitrix 是去調用 Helm 的 API,在應用層實現包的管理。可是 OpenPitrix 比 Helm 能作的事情更多,由於 Helm 其實就是簡單地實現應用打包,而後部署、版本管控、升級這些功能,可是其實應用管理、生命週期管理是很是複雜的場景,它不僅僅是 Helm 考慮到的那些東西,它還包括了不一樣角色人員的需求,還有不一樣場景的支持。


好比說我做爲一個應用開發者,我怎麼去開發本身的應用、怎麼發佈、版本管控,以及應用發佈以後,個人計費計量、用戶使用的狀況是什麼樣的?它碰到的各類問題怎麼經過個人平臺去獲取支持?這都是整個應用生命週期管理裏面各類場景的訴求,這個在 Helm 是沒有的。而 OpenPitrix 提供了整個應用生命週期管理的功能。



這裏簡單畫了一個 KubeSphere 和 OpenPitrix 怎麼作集成支持的場景介紹。好比說我是一個應用開發者,我開發一個應用,那麼我能夠經過 OpenPitrix 把個人應用打包上傳,上傳以後發佈應用,再經過個人 KubeSphere 的 CI/CD 流水線跑一些測試,都經過以後把它發佈,發佈以後我就能夠在個人應用倉庫裏面看到這個應用了。做爲一個應用的消費者、使用者,他能夠在應用倉庫的界面裏面看到並使用這個應用。



這個是 KubeSphere 高級版的產品路線圖。高級版 1.0.0 裏面咱們提供的是多租戶、監控和 CI/CD,高級版 2.0 的時候咱們會提供微服務治理、日誌、告警的支持。


2019 年,咱們會在公有云上線咱們本身的 QingCloud Kubernetes Service,提供容器超融合一體機。咱們的 AppCenter 裏提供了各類 PaaS 和 SaaS 的應用,咱們會把線上比較關鍵性的 PaaS 應用容器化,放到 KubeSphere 的內置應用倉庫裏,同時咱們在明年還會支持 GPU 和 arm 的架構,能夠支持大數據深度學習的場景。


最後,這是 KubeSphere 產品從開發至今累計的開源項目的地址,第一個就是 KubeSphere 這個項目的地址,而後是文檔的項目,你們使用時碰到的各類問題、各類需求均可以在這上面告訴咱們,咱們會及時去解答。


好比說我剛纔講到的咱們本身對接雲平臺的各類插件,像負載均衡器插件、網卡插件、存儲插件,還有我剛纔提到的多雲的應用管理平臺 OpenPitrix,咱們都在 Github 上開源。



另外咱們提供了兩個在線網站,KubeSphere.io 和 KubeSphere.qingcloud.com ,你們能夠在這些地址上獲取想了解的信息。

相關文章
相關標籤/搜索