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

三、Service Mesh

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

• 用来处理服务间通讯的专用基础设施层，通过复杂的拓扑结构让请求传递的过程变得更可靠。

• 作为一组轻量级高性能网络代理，和程序部署在一起，应用程序不需要知道它的存在。

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

1571209303145023963.png

市面上的 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 的架构。

1571209316275069808.jpeg

其中 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。

1571209334286034774.jpeg

(图片来源网络)

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

当然我们还配置了两个边缘节点。

4.1.3 Edge Node

• 边缘节点

• 流量入口

1571209343546024058.jpeg

边缘节点的主要功能是让集群提供对外暴露服务能力的节点，所以它也不需要稳定，我们的 IngressGateway 就是部署在这两个边缘节点上面，并且通过 Keeplived 进行管理。

4.2 外部服务请求流程

1571209353336042135.jpeg

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

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

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

4.3 Logging

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

• 节点 Filebeat 收集宿主机日志。

• 每个 Pods 注入 Filebeat 容器收集业务日志。

1571209362956038383.jpeg

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

1571209371156057534.jpeg

上图是我们可以从 Kibana 上看到所采集到的日志。

4.4 Prometheus + Kubernetes

• 基于时间序列的监控系统。

• 与 kubernetes 无缝集成基础设施和应用等级。

• 具有强大功能的键值数据模型。

• 大厂支持。

1571209381856051250.jpeg

4.4.1 Grafana

1571209391196040075.jpeg

4.4.2 Alarm

1571209399997027190.jpeg

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

1571209409016085856.jpeg

4.4.3 整体架构

1571209419697039213.jpeg

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

• 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