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

創(chuàng)新互聯(lián)主營(yíng)大渡口網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,重慶App定制開(kāi)發(fā),大渡口h5成都小程序開(kāi)發(fā)搭建,大渡口網(wǎng)站營(yíng)銷推廣歡迎大渡口等地區(qū)企業(yè)咨詢

一、Microservices

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

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

1.2 當(dāng)我們?cè)谟懻撐⒎?wù)的時(shí)候我們?cè)谟懻撌裁矗?/h4>

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

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

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

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

1.2.2 微服務(wù)化后帶來(lái)的問(wèn)題

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

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

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

當(dāng)然面對(duì)上述這些問(wèn)題我們廣大的猿友們肯定是有解決方案的。

1.3 Service governance

1.3.1 Java 體系

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

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

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

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

1.3.2 其他體系

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

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

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

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

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

二、Docker & Kubernetes

基于Docker+k8s搭建平臺(tái)的實(shí)踐方案。

2.1 Docker

Docker 是一個(gè)非常強(qiáng)大的容器。

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

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

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

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

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

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

2.1.1 Docker VS VM

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

2.2 Why choose Kubernetes

我們來(lái)對(duì)比這三個(gè)容器編排工具。

2.2.1 Apache Mesos

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

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

2.2.2 Docker Swarm

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

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

它的使用，這里不再具體進(jìn)行介紹。

2.2.3 Kubernetes

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

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

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

2.3 Kubernetes in kubernetes

kubernetes（k8s）是自動(dòng)化容器操作的開(kāi)源平臺(tái)，這些操作包括部署、調(diào)度和節(jié)點(diǎn)集群間擴(kuò)展。

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

2.4 Kubernetes is not enough either

到這里我們解決了以下問(wèn)題:

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

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

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

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

三、Service Mesh

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

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

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

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

3.1 Istio

連接、管理和保護(hù)微服務(wù)的開(kāi)放平臺(tái)。

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

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

因?yàn)橛写髲S支持~其實(shí)主要還是它的理念是相當(dāng)好的。

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

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

3.3 Istio 架構(gòu)

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

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

• Pilot: 主要作為服務(wù)發(fā)現(xiàn)和路由規(guī)則，并且管理著所有Envoy，它對(duì)資源的消耗是非常大的。
• Mixer: 主要負(fù)責(zé)策略請(qǐng)求和配額管理，還有Tracing，所有的請(qǐng)求都會(huì)上報(bào)到Mixer。
• Istio-Auth: 升級(jí)流量、身份驗(yàn)證等等功能，目前我們暫時(shí)沒(méi)有啟用此功能，需求并不是特別大，因?yàn)榧罕旧砭褪菍?duì)外部隔離的。

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

四、Kubernetes & Istio

Istio可以獨(dú)立部署，但顯然它與Kuberntes結(jié)合是更好的選擇?；贙ubernetes的小規(guī)模架構(gòu)。有人擔(dān)心它的性能，其實(shí)經(jīng)過(guò)生產(chǎn)測(cè)試，上萬(wàn)的QPS是完全沒(méi)有問(wèn)題的。

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é)點(diǎn)

• Node:

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

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

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

當(dāng)然我們還配置了兩個(gè)邊緣節(jié)點(diǎn)。

4.1.3 Edge Node

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

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

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

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

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

這是在沒(méi)有進(jìn)行Mixer跟策略檢測(cè)的情況下的過(guò)程，只使用了Istio-IngressGateway。如果使用全部Istio組件將有所變化，但主流程還是這樣的。

4.3 Logging

日志收集我們采用的是低耦合、擴(kuò)展性強(qiáng)、方便維護(hù)和升級(jí)的方案。

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

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

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

4.4 Prometheus + Kubernetes

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

4.4.1 Grafana

4.4.2 Alarm

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

4.4.3 整體架構(gòu)

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

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

集群有:

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

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

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

• 學(xué)習(xí)Docker。
• 學(xué)習(xí)配置倉(cāng)庫(kù)、手動(dòng)打包上傳麻煩。
• 學(xué)習(xí)k8s相關(guān)知識(shí)。

4.5.2 用Jenkins來(lái)負(fù)責(zé)打包、傳鏡像、更新版本

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

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

五、Kplcloud platform

5.1 開(kāi)普勒云平臺(tái)

開(kāi)普勒云平臺(tái)是一個(gè)輕量級(jí)的PaaS平臺(tái)。

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

5.2 在開(kāi)普勒平臺(tái)部署服務(wù)

為了降低學(xué)習(xí)成本及部署難度，在開(kāi)普勒平臺(tái)上部署應(yīng)用很簡(jiǎn)單，只需要增加一個(gè)Dockerfile 就好了。

Dockerfile 參考：

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

這是一種相對(duì)自由的部署方式，可以根據(jù)自己的需求進(jìn)行定制，當(dāng)然有學(xué)習(xí)成本。

5.2.1 為什么不自動(dòng)生成Dockerfile呢？

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

5.3 工具整合

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

5.4 發(fā)布流程

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

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

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

5.5 從創(chuàng)建一個(gè)服務(wù)開(kāi)始

我們從創(chuàng)建一個(gè)服務(wù)開(kāi)始介紹平臺(tái)。

平臺(tái)主界面:

點(diǎn)擊“創(chuàng)建服務(wù)”后進(jìn)入創(chuàng)建頁(yè)面。

填寫(xiě)基本信息:

填寫(xiě)詳細(xì)信息:

基本信息以Golang為例，當(dāng)選擇其他語(yǔ)言時(shí)所需填寫(xiě)的參數(shù)會(huì)略有不同。

如果選擇了對(duì)外提供服務(wù)的話，會(huì)進(jìn)入第三步，第三步是填寫(xiě)路由規(guī)則，如沒(méi)有特殊需求直接默認(rèn)提交就行了。

5.5.1 服務(wù)詳情

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

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

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

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

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

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

5.5.2 定時(shí)任務(wù)

5.5.3 持久化存儲(chǔ)

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

存儲(chǔ)使用的是NFS。

5.5.4 Tracing

5.5.5 Consul

Consul當(dāng)作配置中心來(lái)使用，并且我們提供Golang的客戶端。

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

它會(huì)自動(dòng)同步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ā)：宜技之長(zhǎng)

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

網(wǎng)頁(yè)名稱：Kubernetes+Docker+Istio容器云實(shí)踐-創(chuàng)新互聯(lián)
瀏覽地址：http://weahome.cn/article/hdsgs.html