Kubernetes+Docker+Istio 容器云实践

随着社会的进步与技术的发展，人们对资源的高效利用有了更为迫切的需求。近年来，互联网、移动互联网的高速发展与成熟，大应用的微服务化也引发了企业的热情关注，而基于Kubernetes+Docker的容器云方案也随之进入了大众的视野。开普勒云是一个基于Kubernetes+Docker+Istio的微服务治理解决方案。

1、Microservices

1.1 解决大应用微服务化后的问题

如今各大企业都在谈论微服务，在微服务的大趋势之下技术圈里逢人必谈微服务，及微服务化后的各类解决方案。

1.2 当咱们在讨论微服务的时候咱们在讨论什么？

使用微服务架构有不少充分的理由，但天下没有免费的午饭，微服务虽有诸多优点，同时也增长了复杂性。团队应该积极应对这种复杂性，前提是应用可以受益于微服务。

1.2.1 如何微服务化的问题

• 微服务要如何拆分
• 业务API规则
• 数据一致性保证
• 后期可扩展性考虑

固然这不是本文主要讨论的问题，我不讲微服务具体要如何拆分，每一个企业每一个应用的状况都不太同样，适合本身的方案就是最好的拆分方案。咱们主要来解决微服务化后所带来的一些问题。

1.2.2 微服务化后带来的问题

• 环境一致性
• 如何对资源快速分配
• 如何快速度部署
• 怎么作基本监控
• 服务注册与发现
• 负载均衡如何作

以上都是大应用微服务化所须要解决的基础问题，若是还按照传统的方式使用虚拟机来实现，资源开支将会很是大。那么这些问题要怎么解决呢？好比: 

• 流量管理
• 服务降级
• 认证、受权

固然面对上述这些问题咱们广大的猿友们确定是有解决方案的。

1.3 Service governance

1.3.1 Java 体系

假设咱们是Java体系的应用，那解决起来就很方便了，好比咱们能够考虑使用SpringCloud全家桶系列。也能够拆分使用: 

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

Java体系下能很方便的作以咱们微服务化后的基础部分，但依然不能很是舒服地解决环境一致性，而且若是有其余语系的服务将很难融入进去。

咱们来看基础编程语言通常有什么组合方式来解决基础问题。

1.3.2 其余体系

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

假设咱们是使用Golang语言，这里再捧一下Golang语言。go语言简直就是天生为微服务而生的语言，实在不要太方便了。高效的开发速度及至关不错的性能，简单精悍。

跑题了~咱们使用上面这些工具也能够组成一套还不错的微服务架构。

• Consul: 看成服务发现及配置中心来使
• Kong: 做为服务网关
• Jaeger: 做为链路追踪来使
• Go-kit: 开发组件

可是这种方案也有问题，对服务的侵入性太强了，每一个服务都须要嵌入大量代码，这仍是很头疼的。

2、Docker & Kubernetes

基于Docker+k8s搭建平台的实践方案。

2.1 Docker

Docker 是一个很是强大的容器。

• 资源利用率的提高
• 环境一致性、可移植性
• 快速度扩容伸缩
• 版本控制

使用了Docker以后，咱们发现可玩的东西变多了，更加灵活了。不只仅是资源利用率提高、环境一致性获得了保证，版本控制也变得更加方便了。

之前咱们使用Jenkins进行构建，须要回滚时，又须要从新走一次jenkins Build过程，很是麻烦。若是是Java应用，它的构建时间将会变得很是长。

使用了Docker以后，这一切都变得简单了，只须要把某个版本的镜像拉下来启动就完事了(若是本地有缓存直接启动某个版本就好了)，这个提高是很是高效的。

(图片来源网络)

既然使用了Docker容器做为服务的基础，那咱们确定须要对容器进行编排，若是没有编排那将是很是可怕的。而对于Docker容器的编排，咱们有多种选择：Docker Swarm、Apache Mesos、Kubernetes，在这些编排工具之中，咱们选择了服务编排王者Kubernetes。

2.1.1 Docker VS VM

• VM: 建立虚拟机须要1分钟，部署环境3分钟，部署代码2分钟。
• Docker: 启动容器30秒内。

2.2 Why choose Kubernetes

咱们来对比这三个容器编排工具。

2.2.1 Apache Mesos

Mesos的目的是创建一个高效可扩展的系统，而且这个系统可以支持各类各样的框架，无论是如今的仍是将来的框架，它都能支持。这也是现今一个比较大的问题：相似Hadoop和MPI这些框架都是独立开的，这致使想要在框架之间作一些细粒度的分享是不可能的。

但它的基础语言不是Golang，不在咱们的技术栈里，咱们对它的维护成本将会增高，因此咱们首先排除了它。

2.2.2 Docker Swarm

Docker Swarm是一个由Docker开发的调度框架。由Docker自身开发的好处之一就是标准Docker API的使用。Swarm的架构由两部分组成：

(图片来源网络)

它的使用，这里再也不具体进行介绍。

2.2.3 Kubernetes

Kubernetes是一个Docker容器的编排系统，它使用label和pod的概念来将容器换分为逻辑单元。Pods是同地协做（co-located）容器的集合，这些容器被共同部署和调度，造成了一个服务，这是Kubernetes和其余两个框架的主要区别。相比于基于类似度的容器调度方式（就像Swarm和Mesos），这个方法简化了对集群的管理.

不只如此，它还提供了很是丰富的API，方便咱们对它进行操做，及玩出更多花样。其实还有一大重点就是符合咱们的Golang技术栈，而且有大厂支持。

Kubernetes 的具体使用这里也再也不过多介绍，网站上有大把资料能够参考。

2.3 Kubernetes in kubernetes

kubernetes（k8s）是自动化容器操做的开源平台，这些操做包括部署、调度和节点集群间扩展。

• 自动化容器的部署和复制
• 随时扩展或收缩容器规模
• 将容器组织成组，而且提供容器间的负载均衡
• 很容易地升级应用程序容器的新版本
• 提供容器弹性，若是容器失效就替换它，等等...

2.4 Kubernetes is not enough either

到这里咱们解决了如下问题:

• Docker: 环境一致性、快速度部署。
• Kubernetes: 服务注册与发现、负载均衡、对资源快速分配。

固然还有监控，这个咱们后面再说。咱们先来看要解决一些更高层次的问题该怎么办呢？

在不对服务进行侵入性的代码修改的状况下，服务认证、链路追踪、日志管理、断路器、流量管理、错误注入等等问题要怎么解决呢？

这两年很是流行一种解决方案：Service Mesh。

3、Service Mesh

处理服务间通讯的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。

• 用来处理服务间通信的专用基础设施层，经过复杂的拓扑结构让请求传递的过程变得更可靠。
• 做为一组轻量级高性能网络代理，和程序部署在一块儿，应用程序不须要知道它的存在。

在云原生应用中可靠地传递请求可能很是复杂，经过一系列强大技术来管理这种复杂性: 链路熔断、延迟感知、负载均衡，服务发现、服务续约及下线与剔除。

市面上的ServiceMesh框架有不少，咱们选择了站在风口的Istio。

3.1 Istio

链接、管理和保护微服务的开放平台。

• 平台支持: Kubernetes, Mesos, Cloud Foundry。
• 可观察性:Metrics, logs, traces, dependency 。visualisation。
• Service Identity & Security: 为服务、服务到服务的身份验证提供可验证的标识。
• Traffic 管理: 动态控制服务之间的通讯、入口/出口路由、故障注入。
• Policy 执行: 前提检查，服务之间的配额管理。

3.2 咱们为何选择Istio？

由于有大厂支持~其实主要仍是它的理念是至关好的。

虽然它才到1.0版本，咱们是从 0.6 版本开始尝试体验，测试环境跑，而后0.7.1版本出了，咱们升级到0.7.1版本跑，后来0.8.0LTS出了，咱们开始正式使用0.8.0版本，而且作了一套升级方案。

目前最新版已经到了1.0.4, 但咱们并不许备升级，我想等到它升级到1.2以后，再开始正式大规模应用。0.8.0LTS在如今来看小规模仍是能够的。

3.3 Istio 架构

咱们先来看一下Istio的架构。

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

• Pilot: 主要做为服务发现和路由规则，而且管理着全部Envoy，它对资源的消耗是很是大的。
• Mixer: 主要负责策略请求和配额管理，还有Tracing，全部的请求都会上报到Mixer。
• Istio-Auth: 升级流量、身份验证等等功能，目前咱们暂时没有启用此功能，需求并非特别大，由于集群自己就是对外部隔离的。

每一个Pod都会被注入一个Sidecar，容器里的流量经过iptables所有转到Envoy进行处理。

4、Kubernetes & Istio

Istio能够独立部署，但显然它与Kuberntes结合是更好的选择。基于Kubernetes的小规模架构。有人担忧它的性能，其实通过生产测试，上万的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节点

• Node:

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

(图片来源网络)

咱们所调用的Master的API都是经过 keepalived 进行管理，某一master发生故障，能保证顺滑的飘到其余master的API，不影响整个集群的运行。

固然咱们还配置了两个边缘节点。

4.1.3 Edge Node

• 边缘节点
• 流量入口

边缘节点的主要功能是让集群提供对外暴露服务能力的节点，因此它也不须要稳定，咱们的IngressGateway 就是部署在这两个边缘节点上面，而且经过Keeplived进行管理。

4.2 外部服务请求流程

最外层是DNS，经过泛解析到Nginx，Nginx将流量转到集群的VIP，VIP再到集群的HAproxy，将外部流量发到咱们的边缘节点Gateway。

每一个VirtualService都会绑定到Gateway上，经过VirtualService能够进行服务的负载、限流、故障处理、路由规则及金丝雀部署。再经过Service最终到服务所在的Pods上。

这是在没有进行Mixer跟策略检测的状况下的过程，只使用了Istio-IngressGateway。若是使用所有Istio组件将有所变化，但主流程仍是这样的。

4.3 Logging

日志收集咱们采用的是低耦合、扩展性强、方便维护和升级的方案。

• 节点Filebeat收集宿主机日志。
• 每一个Pods注入Filebeat容器收集业务日志。

Filebeat会跟应用容器部署在一块儿，应用也不须要知道它的存在，只须要指定日志输入的目录就能够了。Filebeat所使用的配置是从ConfigMap读取，只须要维护好收集日志的规则。

上图是咱们能够从Kibana上看到所采集到的日志。

4.4 Prometheus + Kubernetes

• 基于时间序列的监控系统。
• 与kubernetes无缝集成基础设施和应用等级。
• 具备强大功能的键值数据模型。
• 大厂支持。

4.4.1 Grafana

4.4.2 Alarm

目前咱们支持的报警有Wechat、kplcloud、Email、IM。全部报警均可在平台上配置发送到各个地方。

4.4.3 总体架构

整个架构由外围服务及集群内的基础服务组成，外围服务有:

• Consul做为配置中心来使用。
• Prometheus+Grafana用来监控K8s集群。
• Zipkin提供本身定义的链路追踪。
• ELK日志收集、分析，咱们集群内的全部日志会推送到这里。
• Gitlab代码仓库。
• Jenkins用来构建代码及打包成Docker镜像而且上传到仓库。
• Repository 镜像仓库。

集群有:

• HAProxy+keeprlived 负责流量转发。
• 网络是Calico, Calico对kube-proxy的ipvs代理模式有beta级支持。若是Calico检测到kube-proxy正在该模式下运行，则会自动激活Calico ipvs支持，因此咱们启用了IPVS。
• 集群内部的DNS是 CoreDNS。
• 咱们部署了两个网关，主要使用的是Istio的 IngressGateway，TraefikIngress备用。一旦IngressGateway挂了咱们能够快速切换到TraefikIngress。
• 上面是Istio的相关组件。
• 最后是咱们的APP服务。
• 集群经过Filebeat收集日志发到外部的ES。
• 集群内部的监控有：
  • State-Metrics 主要用来自动伸缩的监控组件
  • Mail&Wechat 自研的报警服务
  • Prometheus+Grafana+AlertManager 集群内部的监控，主要监控服务及相关基础组件
  • InfluxDB+Heapster 流数据库存储着全部服务的监控信息

4.5 有了Kubernetes那怎么部署应用呢？

4.5.1 研发打包成镜像、传仓库、管理版本

• 学习Docker。
• 学习配置仓库、手动打包上传麻烦。
• 学习k8s相关知识。

4.5.2 用Jenkins来负责打包、传镜像、更新版本

• 运维工做增长了很多，应用须要进行配置、服务须要作变动都得找运维。
• 须要管理一堆的YAML文件。

有没有一种傻瓜式的，不须要学习太多的技术，能够方便使用的解决方案？

5、Kplcloud platform

5.1 开普勒云平台

开普勒云平台是一个轻量级的PaaS平台。

• 为微服务化的项目提供一个可控的管理平台。
• 实现每一个服务独立部署、维护、扩展。
• 简化流程，再也不须要繁琐的申请流程，最大限度的自动化处理。
• 实现微服务的快速发布、独立监控、配置。
• 实现对微服务项目的零侵入式的服务发现、服务网关、链路追踪等功能。
• 提供配置中心，统一管理配置。
• 研发、产品、测试、运维甚至是老板均可以本身发布应用。

5.2 在开普勒平台部署服务

为了下降学习成本及部署难度，在开普勒平台上部署应用很简单，只须要增长一个Dockerfile 就行了。

Dockerfile 参考：

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

这是一种相对自由的部署方式，能够根据本身的需求进行定制，固然有学习成本。

5.2.1 为何不自动生成Dockerfile呢？

其实彻底能够作到自动生成Dockerfile，但每一个服务的要求可能不同，有些须要增长文件、有些在Build时须要增长参数等等。咱们不能要求全部的项目都是同样的，这会阻碍技术的发展。因此退而求其次，咱们给出模版，研发根据本身的需求调整。

5.3 工具整合

• 开普勒云平台整合了 gitlab，Jenkins，repo，k8s，istio，promtheus，email，WeChat 等API。
• 实现对服务的整个生命周期的管理。
• 提供服务管理、建立、发布、版本、监控、报警、日志已及一些周边附加功能，消息中心、配置中心、还能登录到容器，服务下线等等。
• 可对服务进行一健调整服务模式、服务类型、一键扩容伸缩，回滚服务API管理以及存储的管理等操做。

5.4 发布流程

用户把本身的Dockerfile跟代码提交到Gitlab，而后在开普勒云平台填写一些参数建立本身的应用。

应用建立完后会在Jenkins建立一个Job，把代码拉取下来并执行Docker build（若是没有选择多阶构建会先执行go build或mvn），再把打包好的Docker image推送到镜像仓库，最后回调平台API或调用k8s通知拉取最新的版本。

用户只须要在开普勒云平台上管理好本身的应用就能够，其余的所有自动化处理。

5.5 从建立一个服务开始

咱们从建立一个服务开始介绍平台。

平台主界面:

点击“建立服务”后进入建立页面。

填写基本信息:

填写详细信息: 

基本信息以Golang为例，当选择其余语言时所需填写的参数会略有不一样。

若是选择了对外提供服务的话，会进入第三步，第三步是填写路由规则，如没有特殊需求直接默认提交就好了。

5.5.1 服务详情

Build 升级应用版本: 

调用服务模式，能够在普通跟服务网格之间调整。

服务是否提供对外服务的能力: 

扩容调整CPU、内存：

调整启动的Pod数量：

网页版本的终端：

5.5.2 定时任务

5.5.3 持久化存储

管理员建立StorageClass跟PersistentVolumeClaim，用户只须要在本身服务选择相关的PVC进行绑写就好了。

存储使用的是NFS。

5.5.4 Tracing

5.5.5 Consul

Consul看成配置中心来使用，而且咱们提供Golang的客户端。

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

 

它会自动同步consul的目录配置存在内存，获取配置只须要直接从内存拿就好了。

5.5.6 Repository

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

做者：王聪

首发：宜技之长