隨著社會的進步與技術(shù)的發(fā)展，人們對資源的高效利用有了更為迫切的需求。近年來，互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)的高速發(fā)展與成熟，大應(yīng)用的微服務(wù)化也引起了企業(yè)的熱情關(guān)注，而基于Kubernetes+Docker的容器云方案也隨之進入了大眾的視野。開普勒云是一個基于Kubernetes+Docker+Istio的微服務(wù)治理解決方案。

一、Microservices

1.1 解決大應(yīng)用微服務(wù)化后的問題

現(xiàn)在各大企業(yè)都在談?wù)撐⒎?wù)，在微服務(wù)的大趨勢之下技術(shù)圈里逢人必談微服務(wù)，及微服務(wù)化后的各種解決方案。

1.2 當我們在討論微服務(wù)的時候我們在討論什么？

使用微服務(wù)架構(gòu)有很多充分的理由，但天下沒有免費的午餐，微服務(wù)雖有諸多優(yōu)勢，同時也增加了復雜性。團隊應(yīng)該積極應(yīng)對這種復雜性，前提是應(yīng)用能夠受益于微服務(wù)。

1.2.1 如何微服務(wù)化的問題

• 微服務(wù)要如何拆分
• 業(yè)務(wù)API規(guī)則
• 數(shù)據(jù)一致性保證
• 后期可擴展性考慮

當然這不是本文主要討論的問題，我不講微服務(wù)具體要如何拆分，每個企業(yè)每個應(yīng)用的情況都不太一樣，適合自己的方案就是最好的拆分方案。我們主要來解決微服務(wù)化后所帶來的一些問題。

1.2.2 微服務(wù)化后帶來的問題

• 環(huán)境一致性
• 如何對資源快速分配
• 如何快速度部署
• 怎么做基本監(jiān)控
• 服務(wù)注冊與發(fā)現(xiàn)
• 負載均衡如何做

以上都是大應(yīng)用微服務(wù)化所需要解決的基礎(chǔ)問題，如果還按照傳統(tǒng)的方式使用虛擬機來實現(xiàn)，資源開支將會非常大。那么這些問題要怎么解決呢？比如:

• 流量管理
• 服務(wù)降級
• 認證、授權(quán)

當然面對上述這些問題我們廣大的猿友們肯定是有解決方案的。

1.3 Service governance

1.3.1 Java 體系

假設(shè)我們是Java體系的應(yīng)用，那解決起來就很方便了，比如我們可以考慮使用SpringCloud全家桶系列。也可以拆分使用:

• Eureka
• Hystrix
• Zuul
• Spring-cloud
• Spring-boot
• ZipKin

Java體系下能很方便的做以我們微服務(wù)化后的基礎(chǔ)部分，但依然不能非常舒服地解決環(huán)境一致性，并且如果有其他語系的服務(wù)將很難融入進去。

我們來看基礎(chǔ)編程語言一般有什么組合方式來解決基礎(chǔ)問題。

1.3.2 其他體系

• Consul
• Kong
• Go-kit
• Jaeger/Zipkin

假設(shè)我們是使用Golang語言，這里再捧一下Golang語言。go語言簡直就是天生為微服務(wù)而生的語言，實在不要太方便了。高效的開發(fā)速度及相當不錯的性能，簡單精悍。

跑題了~我們使用上面這些工具也可以組成一套還不錯的微服務(wù)架構(gòu)。

• Consul: 當作服務(wù)發(fā)現(xiàn)及配置中心來使
• Kong: 作為服務(wù)網(wǎng)關(guān)
• Jaeger: 作為鏈路追蹤來使
• Go-kit: 開發(fā)組件

但是這種方案也有問題，對服務(wù)的侵入性太強了，每個服務(wù)都需要嵌入大量代碼，這還是很頭疼的。

二、Docker & Kubernetes

基于Docker+k8s搭建平臺的實踐方案。

2.1 Docker

Docker 是一個非常強大的容器。

• 資源利用率的提升
• 環(huán)境一致性、可移植性
• 快速度擴容伸縮
• 版本控制

使用了Docker之后，我們發(fā)現(xiàn)可玩的東西變多了，更加靈活了。不僅僅是資源利用率提升、環(huán)境一致性得到了保證，版本控制也變得更加方便了。

以前我們使用Jenkins進行構(gòu)建，需要回滾時，又需要重新走一次jenkins Build過程，非常麻煩。如果是Java應(yīng)用，它的構(gòu)建時間將會變得非常長。

使用了Docker之后，這一切都變得簡單了，只需要把某個版本的鏡像拉下來啟動就完事了(如果本地有緩存直接啟動某個版本就行了)，這個提升是非常高效的。

(圖片來源網(wǎng)絡(luò))

既然使用了Docker容器作為服務(wù)的基礎(chǔ)，那我們肯定需要對容器進行編排，如果沒有編排那將是非常可怕的。而對于Docker容器的編排，我們有多種選擇：Docker Swarm、Apache Mesos、Kubernetes，在這些編排工具之中，我們選擇了服務(wù)編排王者Kubernetes。

2.1.1 Docker VS VM

• VM: 創(chuàng)建虛擬機需要1分鐘，部署環(huán)境3分鐘，部署代碼2分鐘。
• Docker: 啟動容器30秒內(nèi)。

2.2 Why choose Kubernetes

我們來對比這三個容器編排工具。

2.2.1 Apache Mesos

Mesos的目的是建立一個高效可擴展的系統(tǒng)，并且這個系統(tǒng)能夠支持各種各樣的框架，不管是現(xiàn)在的還是未來的框架，它都能支持。這也是現(xiàn)今一個比較大的問題：類似Hadoop和MPI這些框架都是獨立開的，這導致想要在框架之間做一些細粒度的分享是不可能的。

但它的基礎(chǔ)語言不是Golang，不在我們的技術(shù)棧里，我們對它的維護成本將會增高，所以我們首先排除了它。

2.2.2 Docker Swarm

Docker Swarm是一個由Docker開發(fā)的調(diào)度框架。由Docker自身開發(fā)的好處之一就是標準Docker API的使用。Swarm的架構(gòu)由兩部分組成：

(圖片來源網(wǎng)絡(luò))

它的使用，這里不再具體進行介紹。

2.2.3 Kubernetes

Kubernetes是一個Docker容器的編排系統(tǒng)，它使用label和pod的概念來將容器換分為邏輯單元。Pods是同地協(xié)作（co-located）容器的集合，這些容器被共同部署和調(diào)度，形成了一個服務(wù)，這是Kubernetes和其他兩個框架的主要區(qū)別。相比于基于相似度的容器調(diào)度方式（就像Swarm和Mesos），這個方法簡化了對集群的管理.

不僅如此，它還提供了非常豐富的API，方便我們對它進行操作，及玩出更多花樣。其實還有一大重點就是符合我們的Golang技術(shù)棧，并且有大廠支持。

Kubernetes 的具體使用這里也不再過多介紹，網(wǎng)站上有大把資料可以參考。

2.3 Kubernetes in kubernetes

kubernetes（k8s）是自動化容器操作的開源平臺，這些操作包括部署、調(diào)度和節(jié)點集群間擴展。

• 自動化容器的部署和復制
• 隨時擴展或收縮容器規(guī)模
• 將容器組織成組，并且提供容器間的負載均衡
• 很容易地升級應(yīng)用程序容器的新版本
• 提供容器彈性，如果容器失效就替換它，等等...

2.4 Kubernetes is not enough either

到這里我們解決了以下問題:

• Docker: 環(huán)境一致性、快速度部署。
• Kubernetes: 服務(wù)注冊與發(fā)現(xiàn)、負載均衡、對資源快速分配。

當然還有監(jiān)控，這個我們后面再說。我們先來看要解決一些更高層次的問題該怎么辦呢？

在不對服務(wù)進行侵入性的代碼修改的情況下，服務(wù)認證、鏈路追蹤、日志管理、斷路器、流量管理、錯誤注入等等問題要怎么解決呢？

這兩年非常流行一種解決方案：Service Mesh。

三、Service Mesh

處理服務(wù)間通信的基礎(chǔ)設(shè)施層，用于在云原生應(yīng)用復雜的服務(wù)拓撲中實現(xiàn)可靠的請求傳遞。

• 用來處理服務(wù)間通訊的專用基礎(chǔ)設(shè)施層，通過復雜的拓撲結(jié)構(gòu)讓請求傳遞的過程變得更可靠。
• 作為一組輕量級高性能網(wǎng)絡(luò)代理，和程序部署在一起，應(yīng)用程序不需要知道它的存在。

在云原生應(yīng)用中可靠地傳遞請求可能非常復雜，通過一系列強大技術(shù)來管理這種復雜性: 鏈路熔斷、延遲感知、負載均衡，服務(wù)發(fā)現(xiàn)、服務(wù)續(xù)約及下線與剔除。

市面上的ServiceMesh框架有很多，我們選擇了站在風口的Istio。

3.1 Istio

連接、管理和保護微服務(wù)的開放平臺。

• 平臺支持: Kubernetes, Mesos, Cloud Foundry。
• 可觀察性:Metrics, logs, traces, dependency 。visualisation。
• Service Identity & Security: 為服務(wù)、服務(wù)到服務(wù)的身份驗證提供可驗證的標識。
• Traffic 管理: 動態(tài)控制服務(wù)之間的通信、入口/出口路由、故障注入。
• Policy 執(zhí)行: 前提檢查，服務(wù)之間的配額管理。

3.2 我們?yōu)槭裁催x擇Istio？

因為有大廠支持~其實主要還是它的理念是相當好的。

雖然它才到1.0版本，我們是從 0.6 版本開始嘗試體驗，測試環(huán)境跑，然后0.7.1版本出了，我們升級到0.7.1版本跑，后來0.8.0LTS出了，我們開始正式使用0.8.0版本，并且做了一套升級方案。

目前最新版已經(jīng)到了1.0.4, 但我們并不準備升級，我想等到它升級到1.2之后，再開始正式大規(guī)模應(yīng)用。0.8.0LTS在現(xiàn)在來看小規(guī)模還是可以的。

3.3 Istio 架構(gòu)

我們先來看一下Istio的架構(gòu)。

其中Istio控制面板主要分為三大塊，Pilot、Mixer、Istio-Auth。

• Pilot: 主要作為服務(wù)發(fā)現(xiàn)和路由規(guī)則，并且管理著所有Envoy，它對資源的消耗是非常大的。
• Mixer: 主要負責策略請求和配額管理，還有Tracing，所有的請求都會上報到Mixer。
• Istio-Auth: 升級流量、身份驗證等等功能，目前我們暫時沒有啟用此功能，需求并不是特別大，因為集群本身就是對外部隔離的。

每個Pod都會被注入一個Sidecar，容器里的流量通過iptables全部轉(zhuǎn)到Envoy進行處理。

四、Kubernetes & Istio

Istio可以獨立部署，但顯然它與Kuberntes結(jié)合是更好的選擇。基于Kubernetes的小規(guī)模架構(gòu)。有人擔心它的性能，其實經(jīng)過生產(chǎn)測試，上萬的QPS是完全沒有問題的。

4.1 Kubernetes Cluster

在資源緊缺的情況下，我們的k8s集群是怎么樣的？

4.1.1 Master集群

• Master Cluster:

  • ETCD、Kube-apiserver、kubelet、Docker、kube-proxy、kube-scheduler、kube-controller-manager、Calico、 keepalived、 IPVS。

4.1.2 Node節(jié)點

• Node:

  • Kubelet、 kube-proxy 、Docker、Calico、IPVS。

(圖片來源網(wǎng)絡(luò))

我們所調(diào)用的Master的API都是通過 keepalived 進行管理，某一master發(fā)生故障，能保證順滑的飄到其他master的API，不影響整個集群的運行。

當然我們還配置了兩個邊緣節(jié)點。

4.1.3 Edge Node

• 邊緣節(jié)點
• 流量入口

邊緣節(jié)點的主要功能是讓集群提供對外暴露服務(wù)能力的節(jié)點，所以它也不需要穩(wěn)定，我們的IngressGateway 就是部署在這兩個邊緣節(jié)點上面，并且通過Keeplived進行管理。

4.2 外部服務(wù)請求流程

最外層是DNS，通過泛解析到Nginx，Nginx將流量轉(zhuǎn)到集群的VIP，VIP再到集群的HAproxy，將外部流量發(fā)到我們的邊緣節(jié)點Gateway。

每個VirtualService都會綁定到Gateway上，通過VirtualService可以進行服務(wù)的負載、限流、故障處理、路由規(guī)則及金絲雀部署。再通過Service最終到服務(wù)所在的Pods上。

這是在沒有進行Mixer跟策略檢測的情況下的過程，只使用了Istio-IngressGateway。如果使用全部Istio組件將有所變化，但主流程還是這樣的。

4.3 Logging

日志收集我們采用的是低耦合、擴展性強、方便維護和升級的方案。

• 節(jié)點Filebeat收集宿主機日志。
• 每個Pods注入Filebeat容器收集業(yè)務(wù)日志。

Filebeat會跟應(yīng)用容器部署在一起，應(yīng)用也不需要知道它的存在，只需要指定日志輸入的目錄就可以了。Filebeat所使用的配置是從ConfigMap讀取，只需要維護好收集日志的規(guī)則。

上圖是我們可以從Kibana上看到所采集到的日志。

4.4 Prometheus + Kubernetes

• 基于時間序列的監(jiān)控系統(tǒng)。
• 與kubernetes無縫集成基礎(chǔ)設(shè)施和應(yīng)用等級。
• 具有強大功能的鍵值數(shù)據(jù)模型。
• 大廠支持。

4.4.1 Grafana

4.4.2 Alarm

目前我們支持的報警有Wechat、kplcloud、Email、IM。所有報警都可在平臺上配置發(fā)送到各個地方。

4.4.3 整體架構(gòu)

整個架構(gòu)由外圍服務(wù)及集群內(nèi)的基礎(chǔ)服務(wù)組成，外圍服務(wù)有:

• Consul作為配置中心來使用。
• Prometheus+Grafana用來監(jiān)控K8s集群。
• Zipkin提供自己定義的鏈路追蹤。
• ELK日志收集、分析，我們集群內(nèi)的所有日志會推送到這里。
• Gitlab代碼倉庫。
• Jenkins用來構(gòu)建代碼及打包成Docker鏡像并且上傳到倉庫。
• Repository 鏡像倉庫。

集群有:

• HAProxy+keeprlived 負責流量轉(zhuǎn)發(fā)。
• 網(wǎng)絡(luò)是Calico, Calico對kube-proxy的ipvs代理模式有beta級支持。如果Calico檢測到kube-proxy正在該模式下運行，則會自動激活Calico ipvs支持，所以我們啟用了IPVS。
• 集群內(nèi)部的DNS是 CoreDNS。
• 我們部署了兩個網(wǎng)關(guān)，主要使用的是Istio的 IngressGateway，TraefikIngress備用。一旦IngressGateway掛了我們可以快速切換到TraefikIngress。
• 上面是Istio的相關(guān)組件。
• 最后是我們的APP服務(wù)。
• 集群通過Filebeat收集日志發(fā)到外部的ES。
• 集群內(nèi)部的監(jiān)控有：
  • State-Metrics 主要用來自動伸縮的監(jiān)控組件
  • Mail&Wechat 自研的報警的服務(wù)
  • Prometheus+Grafana+AlertManager 集群內(nèi)部的監(jiān)控，主要監(jiān)控服務(wù)及相關(guān)基礎(chǔ)組件
  • InfluxDB+Heapster 流數(shù)據(jù)庫存儲著所有服務(wù)的監(jiān)控信息

4.5 有了Kubernetes那怎么部署應(yīng)用呢？

4.5.1 研發(fā)打包成鏡像、傳倉庫、管理版本

• 學習Docker。
• 學習配置倉庫、手動打包上傳麻煩。
• 學習k8s相關(guān)知識。

4.5.2 用Jenkins來負責打包、傳鏡像、更新版本

• 運維工作增加了不少，應(yīng)用需要進行配置、服務(wù)需要做變更都得找運維。
• 需要管理一堆的YAML文件。

有沒有一種傻瓜式的，不需要學習太多的技術(shù)，可以方便使用的解決方案？

五、Kplcloud platform

5.1 開普勒云平臺

開普勒云平臺是一個輕量級的PaaS平臺。

• 為微服務(wù)化的項目提供一個可控的管理平臺。
• 實現(xiàn)每個服務(wù)獨立部署、維護、擴展。
• 簡化流程，不再需要繁瑣的申請流程，大限度的自動化處理。
• 實現(xiàn)微服務(wù)的快速發(fā)布、獨立監(jiān)控、配置。
• 實現(xiàn)對微服務(wù)項目的零侵入式的服務(wù)發(fā)現(xiàn)、服務(wù)網(wǎng)關(guān)、鏈路追蹤等功能。
• 提供配置中心，統(tǒng)一管理配置。
• 研發(fā)、產(chǎn)品、測試、運維甚至是老板都可以自己發(fā)布應(yīng)用。

5.2 在開普勒平臺部署服務(wù)

為了降低學習成本及部署難度，在開普勒平臺上部署應(yīng)用很簡單，只需要增加一個Dockerfile 就好了。

Dockerfile 參考：

以上是普通模式，Jenkins代碼Build及Docker build。

這是一種相對自由的部署方式，可以根據(jù)自己的需求進行定制，當然有學習成本。

5.2.1 為什么不自動生成Dockerfile呢？

其實完全可以做到自動生成Dockerfile，但每個服務(wù)的要求可能不一樣，有些需要增加文件、有些在Build時需要增加參數(shù)等等。我們不能要求所有的項目都是一樣的，這會阻礙技術(shù)的發(fā)展。所以退而求其次，我們給出模版，研發(fā)根據(jù)自己的需求調(diào)整。

5.3 工具整合

• 開普勒云平臺整合了 gitlab，Jenkins，repo，k8s，istio，promtheus，email，WeChat 等API。
• 實現(xiàn)對服務(wù)的整個生命周期的管理。
• 提供服務(wù)管理、創(chuàng)建、發(fā)布、版本、監(jiān)控、報警、日志已及一些周邊附加功能，消息中心、配置中心、還能登陸到容器，服務(wù)下線等等。
• 可對服務(wù)進行一健調(diào)整服務(wù)模式、服務(wù)類型、一鍵擴容伸縮，回滾服務(wù)API管理以及存儲的管理等操作。

5.4 發(fā)布流程

用戶把自己的Dockerfile跟代碼提交到Gitlab，然后在開普勒云平臺填寫一些參數(shù)創(chuàng)建自己的應(yīng)用。

應(yīng)用創(chuàng)建完后會在Jenkins創(chuàng)建一個Job，把代碼拉取下來并執(zhí)行Docker build（如果沒有選擇多階構(gòu)建會先執(zhí)行g(shù)o build或mvn），再把打包好的Docker image推送到鏡像倉庫，最后回調(diào)平臺API或調(diào)用k8s通知拉取最新的版本。

用戶只需要在開普勒云平臺上管理好自己的應(yīng)用就可以，其他的全部自動化處理。

5.5 從創(chuàng)建一個服務(wù)開始

我們從創(chuàng)建一個服務(wù)開始介紹平臺。

平臺主界面:

點擊“創(chuàng)建服務(wù)”后進入創(chuàng)建頁面。

填寫基本信息:

填寫詳細信息:

基本信息以Golang為例，當選擇其他語言時所需填寫的參數(shù)會略有不同。

如果選擇了對外提供服務(wù)的話，會進入第三步，第三步是填寫路由規(guī)則，如沒有特殊需求直接默認提交就行了。

5.5.1 服務(wù)詳情

Build 升級應(yīng)用版本:

調(diào)用服務(wù)模式，可以在普通跟服務(wù)網(wǎng)格之間調(diào)整。

服務(wù)是否提供對外服務(wù)的能力:

擴容調(diào)整CPU、內(nèi)存：

調(diào)整啟動的Pod數(shù)量：

網(wǎng)頁版本的終端：

5.5.2 定時任務(wù)

5.5.3 持久化存儲

管理員創(chuàng)建StorageClass跟PersistentVolumeClaim，用戶只需要在自己服務(wù)選擇相關(guān)的PVC進行綁寫就行了。

存儲使用的是NFS。

5.5.4 Tracing

5.5.5 Consul

Consul當作配置中心來使用，并且我們提供Golang的客戶端。

$ go get github.com/lattecake/consul-kv-client

它會自動同步consul的目錄配置存在內(nèi)存，獲取配置只需要直接從內(nèi)存拿就行了。

5.5.6 Repository

• Github: https://github.com/kplcloud/kplcloud
• Document: https://docs.nsini.com
• Demo: https://kplcloud.nsini.com

作者：王聰

首發(fā)：宜技之長

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。