三、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进行处理。

四、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文件。

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

本文转载自宜信技术学院公众号。

原文链接：http://college.creditease.cn/detail/309

创作场景

Kubernetes+Docker+Istio 容器云实践（二）