黑之学士 發表於 2019-10-17 14:41:00

Kubernetes+Docker+Istio 容器云实践

<p id="toc_0">随着社会的进步与技术的发展，人们对资源的高效利用有了更为迫切的需求。近年来，互联网、移动互联网的高速发展与成熟，大应用的微服务化也引起了企业的热情关注，而基于Kubernetes+Docker的容器云方案也随之进入了大众的视野。开普勒云是一个基于Kubernetes+Docker+Istio的微服务治理解决方案。</p>
<h2 id="toc_1">一、Microservices</h2>
<h3 id="toc_2">1.1 解决大应用微服务化后的问题</h3>
<p>现在各大企业都在谈论微服务，在微服务的大趋势之下技术圈里逢人必谈微服务，及微服务化后的各种解决方案。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571208174990085051.png"></p>
<h3 id="toc_3">1.2 当我们在讨论微服务的时候我们在讨论什么？</h3>
<p>使用微服务架构有很多充分的理由，但天下没有免费的午餐，微服务虽有诸多优势，同时也增加了复杂性。团队应该积极应对这种复杂性，前提是应用能够受益于微服务。</p>
<h4 id="toc_4">1.2.1 如何微服务化的问题</h4>
<ul>
<li>微服务要如何拆分</li>
<li>业务API规则</li>
<li>数据一致性保证</li>
<li>后期可扩展性考虑</li>
</ul>
<p>当然这不是本文主要讨论的问题，我不讲微服务具体要如何拆分，每个企业每个应用的情况都不太一样，适合自己的方案就是最好的拆分方案。我们主要来解决微服务化后所带来的一些问题。</p>
<h4 id="toc_5">1.2.2 微服务化后带来的问题</h4>
<ul>
<li>环境一致性</li>
<li>如何对资源快速分配</li>
<li>如何快速度部署</li>
<li>怎么做基本监控</li>
<li>服务注册与发现</li>
<li>负载均衡如何做</li>
</ul>
<p>以上都是大应用微服务化所需要解决的基础问题，如果还按照传统的方式使用虚拟机来实现，资源开支将会非常大。那么这些问题要怎么解决呢？比如:<span class="Apple-converted-space">&nbsp;</span></p>
<ul>
<li>流量管理</li>
<li>服务降级</li>
<li>认证、授权</li>
</ul>
<p>当然面对上述这些问题我们广大的猿友们肯定是有解决方案的。</p>
<h3 id="toc_6">1.3 Service governance</h3>
<h4 id="toc_7">1.3.1 Java 体系</h4>
<p>假设我们是Java体系的应用，那解决起来就很方便了，比如我们可以考虑使用SpringCloud全家桶系列。也可以拆分使用:<span class="Apple-converted-space">&nbsp;</span></p>
<ul>
<li>Eureka</li>
<li>Hystrix</li>
<li>Zuul</li>
<li>Spring-cloud</li>
<li>Spring-boot</li>
<li>ZipKin</li>
</ul>
<p>Java体系下能很方便的做以我们微服务化后的基础部分，但依然不能非常舒服地解决环境一致性，并且如果有其他语系的服务将很难融入进去。</p>
<p>我们来看基础编程语言一般有什么组合方式来解决基础问题。</p>
<h4 id="toc_8">1.3.2 其他体系</h4>
<ul>
<li>Consul</li>
<li>Kong</li>
<li>Go-kit</li>
<li>Jaeger/Zipkin</li>
</ul>
<p>假设我们是使用Golang语言，这里再捧一下Golang语言。go语言简直就是天生为微服务而生的语言，实在不要太方便了。高效的开发速度及相当不错的性能，简单精悍。</p>
<p>跑题了~我们使用上面这些工具也可以组成一套还不错的微服务架构。</p>
<ul>
<li>Consul: 当作服务发现及配置中心来使</li>
<li>Kong: 作为服务网关</li>
<li>Jaeger: 作为链路追踪来使</li>
<li>Go-kit: 开发组件</li>
</ul>
<p>但是这种方案也有问题，对服务的侵入性太强了，每个服务都需要嵌入大量代码，这还是很头疼的。</p>
<h2 id="toc_9">二、Docker &amp; Kubernetes</h2>
<p>基于Docker+k8s搭建平台的实践方案。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209168494083872.png"></p>
<h3 id="toc_10">2.1 Docker</h3>
<p>Docker 是一个非常强大的容器。</p>
<ul>
<li>资源利用率的提升</li>
<li>环境一致性、可移植性</li>
<li>快速度扩容伸缩</li>
<li>版本控制</li>
</ul>
<p>使用了Docker之后，我们发现可玩的东西变多了，更加灵活了。不仅仅是资源利用率提升、环境一致性得到了保证，版本控制也变得更加方便了。</p>
<p>以前我们使用Jenkins进行构建，需要回滚时，又需要重新走一次jenkins Build过程，非常麻烦。如果是Java应用，它的构建时间将会变得非常长。</p>
<p>使用了Docker之后，这一切都变得简单了，只需要把某个版本的镜像拉下来启动就完事了(如果本地有缓存直接启动某个版本就行了)，这个提升是非常高效的。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209181102046807.jpeg"></p>
<p>(图片来源网络)</p>
<p>既然使用了Docker容器作为服务的基础，那我们肯定需要对容器进行编排，如果没有编排那将是非常可怕的。而对于Docker容器的编排，我们有多种选择：Docker Swarm、Apache Mesos、Kubernetes，在这些编排工具之中，我们选择了服务编排王者Kubernetes。</p>
<h4 id="toc_11">2.1.1 Docker VS VM</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209258505054073.jpeg"></p>
<ul>
<li>VM: 创建虚拟机需要1分钟，部署环境3分钟，部署代码2分钟。</li>
<li>Docker: 启动容器30秒内。</li>
</ul>
<h3 id="toc_12">2.2 Why choose Kubernetes</h3>
<p>我们来对比这三个容器编排工具。</p>
<h4 id="toc_13">2.2.1 Apache Mesos</h4>
<p>Mesos的目的是建立一个高效可扩展的系统，并且这个系统能够支持各种各样的框架，不管是现在的还是未来的框架，它都能支持。这也是现今一个比较大的问题：类似Hadoop和MPI这些框架都是独立开的，这导致想要在框架之间做一些细粒度的分享是不可能的。</p>
<p>但它的基础语言不是Golang，不在我们的技术栈里，我们对它的维护成本将会增高，所以我们首先排除了它。</p>
<h4 id="toc_14">2.2.2 Docker Swarm</h4>
<p>Docker Swarm是一个由Docker开发的调度框架。由Docker自身开发的好处之一就是标准Docker API的使用。Swarm的架构由两部分组成：</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209269456054048.jpeg"></p>
<p>(图片来源网络)</p>
<p>它的使用，这里不再具体进行介绍。</p>
<h3 id="toc_15">2.2.3 Kubernetes</h3>
<p>Kubernetes是一个Docker容器的编排系统，它使用label和pod的概念来将容器换分为逻辑单元。Pods是同地协作（co-located）容器的集合，这些容器被共同部署和调度，形成了一个服务，这是Kubernetes和其他两个框架的主要区别。相比于基于相似度的容器调度方式（就像Swarm和Mesos），这个方法简化了对集群的管理.</p>
<p>不仅如此，它还提供了非常丰富的API，方便我们对它进行操作，及玩出更多花样。其实还有一大重点就是符合我们的Golang技术栈，并且有大厂支持。</p>
<p>Kubernetes 的具体使用这里也不再过多介绍，网站上有大把资料可以参考。</p>
<h3 id="toc_16">2.3 Kubernetes in kubernetes</h3>
<p>kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署、调度和节点集群间扩展。</p>
<ul>
<li>自动化容器的部署和复制</li>
<li>随时扩展或收缩容器规模</li>
<li>将容器组织成组，并且提供容器间的负载均衡</li>
<li>很容易地升级应用程序容器的新版本</li>
<li>提供容器弹性，如果容器失效就替换它，等等...</li>
</ul>
<h3 id="toc_17">2.4 Kubernetes is not enough either</h3>
<p>到这里我们解决了以下问题:</p>
<ul>
<li>Docker: 环境一致性、快速度部署。</li>
<li>Kubernetes: 服务注册与发现、负载均衡、对资源快速分配。</li>
</ul>
<p>当然还有监控，这个我们后面再说。我们先来看要解决一些更高层次的问题该怎么办呢？</p>
<p>在不对服务进行侵入性的代码修改的情况下，服务认证、链路追踪、日志管理、断路器、流量管理、错误注入等等问题要怎么解决呢？</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209280325062846.jpeg"></p>
<p>这两年非常流行一种解决方案：Service Mesh。</p>
<h2 id="toc_18">三、Service Mesh</h2>
<p>处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。</p>
<ul>
<li>用来处理服务间通讯的专用基础设施层，通过复杂的拓扑结构让请求传递的过程变得更可靠。</li>
<li>作为一组轻量级高性能网络代理，和程序部署在一起，应用程序不需要知道它的存在。</li>
</ul>
<p>在云原生应用中可靠地传递请求可能非常复杂，通过一系列强大技术来管理这种复杂性: 链路熔断、延迟感知、负载均衡，服务发现、服务续约及下线与剔除。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209303145023963.png"></p>
<p>市面上的ServiceMesh框架有很多，我们选择了站在风口的Istio。</p>
<h3 id="toc_19">3.1 Istio</h3>
<p>连接、管理和保护微服务的开放平台。</p>
<ul>
<li>平台支持: Kubernetes, Mesos, Cloud Foundry。</li>
<li>可观察性:Metrics, logs, traces, dependency 。visualisation。</li>
<li>Service Identity &amp; Security: 为服务、服务到服务的身份验证提供可验证的标识。</li>
<li>Traffic 管理: 动态控制服务之间的通信、入口/出口路由、故障注入。</li>
<li>Policy 执行: 前提检查，服务之间的配额管理。</li>
</ul>
<h3 id="toc_20">3.2 我们为什么选择Istio？</h3>
<p>因为有大厂支持~其实主要还是它的理念是相当好的。</p>
<p>虽然它才到1.0版本，我们是从 0.6 版本开始尝试体验，测试环境跑，然后0.7.1版本出了，我们升级到0.7.1版本跑，后来0.8.0LTS出了，我们开始正式使用0.8.0版本，并且做了一套升级方案。</p>
<p>目前最新版已经到了1.0.4, 但我们并不准备升级，我想等到它升级到1.2之后，再开始正式大规模应用。0.8.0LTS在现在来看小规模还是可以的。</p>
<h3 id="toc_21">3.3 Istio 架构</h3>
<p>我们先来看一下Istio的架构。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209316275069808.jpeg"></p>
<p>其中Istio控制面板主要分为三大块，Pilot、Mixer、Istio-Auth。</p>
<ul>
<li>Pilot: 主要作为服务发现和路由规则，并且管理着所有Envoy，它对资源的消耗是非常大的。</li>
<li>Mixer: 主要负责策略请求和配额管理，还有Tracing，所有的请求都会上报到Mixer。</li>
<li>Istio-Auth: 升级流量、身份验证等等功能，目前我们暂时没有启用此功能，需求并不是特别大，因为集群本身就是对外部隔离的。</li>
</ul>
<p>每个Pod都会被注入一个Sidecar，容器里的流量通过iptables全部转到Envoy进行处理。</p>
<h2 id="toc_22">四、Kubernetes &amp; Istio</h2>
<p>Istio可以独立部署，但显然它与Kuberntes结合是更好的选择。基于Kubernetes的小规模架构。有人担心它的性能，其实经过生产测试，上万的QPS是完全没有问题的。</p>
<h3 id="toc_23">4.1 Kubernetes Cluster</h3>
<p>在资源紧缺的情况下，我们的k8s集群是怎么样的？</p>
<h4 id="toc_24">4.1.1 Master集群</h4>
<ul>
<li>
<p>Master Cluster:</p>
<ul>
<li>ETCD、Kube-apiserver、kubelet、Docker、kube-proxy、kube-scheduler、kube-controller-manager、Calico、 keepalived、 IPVS。</li>
</ul>
</li>
</ul>
<h4 id="toc_25">4.1.2 Node节点</h4>
<ul>
<li>
<p>Node:</p>
<ul>
<li>Kubelet、 kube-proxy 、Docker、Calico、IPVS。</li>
</ul>
</li>
</ul>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209334286034774.jpeg"></p>
<p>(图片来源网络)</p>
<p>我们所调用的Master的API都是通过 keepalived 进行管理，某一master发生故障，能保证顺滑的飘到其他master的API，不影响整个集群的运行。</p>
<p>当然我们还配置了两个边缘节点。</p>
<h4 id="toc_26">4.1.3 Edge Node</h4>
<ul>
<li>边缘节点</li>
<li>流量入口</li>
</ul>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209343546024058.jpeg"></p>
<p>边缘节点的主要功能是让集群提供对外暴露服务能力的节点，所以它也不需要稳定，我们的IngressGateway 就是部署在这两个边缘节点上面，并且通过Keeplived进行管理。</p>
<h3 id="toc_27">4.2 外部服务请求流程</h3>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209353336042135.jpeg"></p>
<p>最外层是DNS，通过泛解析到Nginx，Nginx将流量转到集群的VIP，VIP再到集群的HAproxy，将外部流量发到我们的边缘节点Gateway。</p>
<p>每个VirtualService都会绑定到Gateway上，通过VirtualService可以进行服务的负载、限流、故障处理、路由规则及金丝雀部署。再通过Service最终到服务所在的Pods上。</p>
<p>这是在没有进行Mixer跟策略检测的情况下的过程，只使用了Istio-IngressGateway。如果使用全部Istio组件将有所变化，但主流程还是这样的。</p>
<h3 id="toc_28">4.3 Logging</h3>
<p>日志收集我们采用的是低耦合、扩展性强、方便维护和升级的方案。</p>
<ul>
<li>节点Filebeat收集宿主机日志。</li>
<li>每个Pods注入Filebeat容器收集业务日志。</li>
</ul>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209362956038383.jpeg"></p>
<p>Filebeat会跟应用容器部署在一起，应用也不需要知道它的存在，只需要指定日志输入的目录就可以了。Filebeat所使用的配置是从ConfigMap读取，只需要维护好收集日志的规则。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209371156057534.jpeg"></p>
<p>上图是我们可以从Kibana上看到所采集到的日志。</p>
<h3 id="toc_29">4.4 Prometheus + Kubernetes</h3>
<ul>
<li>基于时间序列的监控系统。</li>
<li>与kubernetes无缝集成基础设施和应用等级。</li>
<li>具有强大功能的键值数据模型。</li>
<li>大厂支持。</li>
</ul>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209381856051250.jpeg"></p>
<h4 id="toc_30">4.4.1 Grafana</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209391196040075.jpeg"></p>
<h4 id="toc_31">4.4.2 Alarm</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209399997027190.jpeg"></p>
<p>目前我们支持的报警有Wechat、kplcloud、Email、IM。所有报警都可在平台上配置发送到各个地方。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209409016085856.jpeg"></p>
<h3 id="toc_32">4.4.3 整体架构</h3>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209419697039213.jpeg"></p>
<p>整个架构由外围服务及集群内的基础服务组成，外围服务有:</p>
<ul>
<li>Consul作为配置中心来使用。</li>
<li>Prometheus+Grafana用来监控K8s集群。</li>
<li>Zipkin提供自己定义的链路追踪。</li>
<li>ELK日志收集、分析，我们集群内的所有日志会推送到这里。</li>
<li>Gitlab代码仓库。</li>
<li>Jenkins用来构建代码及打包成Docker镜像并且上传到仓库。</li>
<li>Repository 镜像仓库。</li>
</ul>
<p>集群有:</p>
<ul>
<li>HAProxy+keeprlived 负责流量转发。</li>
<li>网络是Calico, Calico对kube-proxy的ipvs代理模式有beta级支持。如果Calico检测到kube-proxy正在该模式下运行，则会自动激活Calico ipvs支持，所以我们启用了IPVS。</li>
<li>集群内部的DNS是 CoreDNS。</li>
<li>我们部署了两个网关，主要使用的是Istio的 IngressGateway，TraefikIngress备用。一旦IngressGateway挂了我们可以快速切换到TraefikIngress。</li>
<li>上面是Istio的相关组件。</li>
<li>最后是我们的APP服务。</li>
<li>集群通过Filebeat收集日志发到外部的ES。</li>
<li>集群内部的监控有：
<ul>
<li>State-Metrics 主要用来自动伸缩的监控组件</li>
<li>Mail&amp;Wechat 自研的报警服务</li>
<li>Prometheus+Grafana+AlertManager 集群内部的监控，主要监控服务及相关基础组件</li>
<li>InfluxDB+Heapster 流数据库存储着所有服务的监控信息</li>
</ul>
</li>
</ul>
<h3 id="toc_33">4.5 有了Kubernetes那怎么部署应用呢？</h3>
<h4 id="toc_34">4.5.1 研发打包成镜像、传仓库、管理版本</h4>
<ul>
<li>学习Docker。</li>
<li>学习配置仓库、手动打包上传麻烦。</li>
<li>学习k8s相关知识。</li>
</ul>
<h4 id="toc_35">4.5.2 用Jenkins来负责打包、传镜像、更新版本</h4>
<ul>
<li>运维工作增加了不少，应用需要进行配置、服务需要做变更都得找运维。</li>
<li>需要管理一堆的YAML文件。</li>
</ul>
<p>有没有一种傻瓜式的，不需要学习太多的技术，可以方便使用的解决方案？</p>
<h2 id="toc_36">五、Kplcloud platform</h2>
<h3 id="toc_37">5.1 开普勒云平台</h3>
<p>开普勒云平台是一个轻量级的PaaS平台。</p>
<ul>
<li>为微服务化的项目提供一个可控的管理平台。</li>
<li>实现每个服务独立部署、维护、扩展。</li>
<li>简化流程，不再需要繁琐的申请流程，最大限度的自动化处理。</li>
<li>实现微服务的快速发布、独立监控、配置。</li>
<li>实现对微服务项目的零侵入式的服务发现、服务网关、链路追踪等功能。</li>
<li>提供配置中心，统一管理配置。</li>
<li>研发、产品、测试、运维甚至是老板都可以自己发布应用。</li>
</ul>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209457127056307.jpg"></p>
<h3 id="toc_38">5.2 在开普勒平台部署服务</h3>
<p>为了降低学习成本及部署难度，在开普勒平台上部署应用很简单，只需要增加一个Dockerfile 就好了。</p>
<p>Dockerfile 参考：</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209472797023115.jpeg"></p>
<p>以上是普通模式，Jenkins代码Build及Docker build。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209521131092825.jpeg"></p>
<p>这是一种相对自由的部署方式，可以根据自己的需求进行定制，当然有学习成本。</p>
<h4 id="toc_39">5.2.1 为什么不自动生成Dockerfile呢？</h4>
<p>其实完全可以做到自动生成Dockerfile，但每个服务的要求可能不一样，有些需要增加文件、有些在Build时需要增加参数等等。我们不能要求所有的项目都是一样的，这会阻碍技术的发展。所以退而求其次，我们给出模版，研发根据自己的需求调整。</p>
<h3 id="toc_40">5.3 工具整合</h3>
<ul>
<li>开普勒云平台整合了 gitlab，Jenkins，repo，k8s，istio，promtheus，email，WeChat 等API。</li>
<li>实现对服务的整个生命周期的管理。</li>
<li>提供服务管理、创建、发布、版本、监控、报警、日志已及一些周边附加功能，消息中心、配置中心、还能登陆到容器，服务下线等等。</li>
<li>可对服务进行一健调整服务模式、服务类型、一键扩容伸缩，回滚服务API管理以及存储的管理等操作。</li>
</ul>
<h3 id="toc_41">5.4 发布流程</h3>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209533061062658.jpeg"></p>
<p>用户把自己的Dockerfile跟代码提交到Gitlab，然后在开普勒云平台填写一些参数创建自己的应用。</p>
<p>应用创建完后会在Jenkins创建一个Job，把代码拉取下来并执行Docker build（如果没有选择多阶构建会先执行go build或mvn），再把打包好的Docker image推送到镜像仓库，最后回调平台API或调用k8s通知拉取最新的版本。</p>
<p>用户只需要在开普勒云平台上管理好自己的应用就可以，其他的全部自动化处理。</p>
<h3 id="toc_42">5.5 从创建一个服务开始</h3>
<p>我们从创建一个服务开始介绍平台。</p>
<p>平台主界面:</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209547841058411.jpeg"></p>
<p>点击“创建服务”后进入创建页面。</p>
<p>填写基本信息:</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209559822027655.jpeg"></p>
<p>填写详细信息:<span class="Apple-converted-space">&nbsp;</span></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209569872093908.jpeg"></p>
<p>基本信息以Golang为例，当选择其他语言时所需填写的参数会略有不同。</p>
<p>如果选择了对外提供服务的话，会进入第三步，第三步是填写路由规则，如没有特殊需求直接默认提交就行了。</p>
<h4 id="toc_43">5.5.1 服务详情</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209583732036810.jpeg"></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209600142060832.jpeg"></p>
<p>Build 升级应用版本:<span class="Apple-converted-space">&nbsp;</span></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209619222016669.jpeg"></p>
<p>调用服务模式，可以在普通跟服务网格之间调整。</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209631902005060.jpeg"></p>
<p>服务是否提供对外服务的能力:<span class="Apple-converted-space">&nbsp;</span></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209646812049263.jpeg"></p>
<p>扩容调整CPU、内存：</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209658173009693.jpeg"></p>
<p>调整启动的Pod数量：</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209672292086340.jpeg"></p>
<p>网页版本的终端：</p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209755055004594.jpeg"></p>
<h4 id="toc_44">5.5.2 定时任务</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209765245065095.jpeg"></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209778265004475.jpeg"></p>
<h4 id="toc_45">5.5.3 持久化存储</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209789235021519.jpeg"></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209805425071729.jpeg"></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209823528085917.jpeg"></p>
<p>管理员创建StorageClass跟PersistentVolumeClaim，用户只需要在自己服务选择相关的PVC进行绑写就行了。</p>
<p>存储使用的是NFS。</p>
<h4 id="toc_46">5.5.4 Tracing</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209840209077637.jpeg"></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209854139036596.jpeg"></p>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209863439066168.jpeg"></p>
<h4 id="toc_47">5.5.5 Consul</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209878349082409.jpeg"></p>
<p>Consul当作配置中心来使用，并且我们提供Golang的客户端。</p>
<div>
<div class="cnblogs_code">
<pre>$ go <span style="color: rgba(0, 0, 255, 1)">get</span> github.com/lattecake/consul-kv-client</pre>
</div>
<p>&nbsp;</p>
</div>
<p>它会自动同步consul的目录配置存在内存，获取配置只需要直接从内存拿就行了。</p>
<h4 id="toc_48">5.5.6 Repository</h4>
<p><img src="http://college.creditease.cn/resources/upload/image/20191016/1571209899259008249.jpeg"></p>
<ul>
<li>Github:<span class="Apple-converted-space">&nbsp;https://github.com/kplcloud/kplcloud</span></li>
<li>Document:<span class="Apple-converted-space">&nbsp;https://docs.nsini.com</span></li>
<li>Demo:<span class="Apple-converted-space">&nbsp;https://kplcloud.nsini.com</span></li>
</ul>
<blockquote>
<p>作者：王聪</p>
<p>首发：宜技之长</p>
</blockquote><br><br>
来源：https://www.cnblogs.com/yixinjishu/p/11691932.html
頁: [1]
查看完整版本: Kubernetes+Docker+Istio 容器云实践