Kubernetes+Docker+Istio 容器云实践(二)

阅读数:1 2020 年 2 月 6 日 21:29

Kubernetes+Docker+Istio 容器云实践(二)

三、Service Mesh

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

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

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

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

Kubernetes+Docker+Istio 容器云实践(二)

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

Kubernetes+Docker+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。

Kubernetes+Docker+Istio 容器云实践(二)

(图片来源网络)

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

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

4.1.3 Edge Node

  • 边缘节点

  • 流量入口

Kubernetes+Docker+Istio 容器云实践(二)

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

4.2 外部服务请求流程

Kubernetes+Docker+Istio 容器云实践(二)

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

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

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

4.3 Logging

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

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

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

Kubernetes+Docker+Istio 容器云实践(二)

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

Kubernetes+Docker+Istio 容器云实践(二)

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

4.4 Prometheus + Kubernetes

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

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

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

  • 大厂支持。

Kubernetes+Docker+Istio 容器云实践(二)

4.4.1 Grafana

Kubernetes+Docker+Istio 容器云实践(二)

4.4.2 Alarm

Kubernetes+Docker+Istio 容器云实践(二)

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

Kubernetes+Docker+Istio 容器云实践(二)

4.4.3 整体架构

Kubernetes+Docker+Istio 容器云实践(二)

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

  • 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

评论

发布