再升级-Kubernetes Ingress监控进入智能时代 Kubernetes的门户-Ingress目前Kube

Kubernetes的门户 - Ingress目前Kubernetes（K8s）已经真正地占领了容器编排市场，是默认的云无关计算抽象，越来越多的企业开始将服务构建在K8s集群上。在K8s中，组件通过Service对外暴露服务，常见的包括NodePort、LoadBalancer、Ingress等。其中Ingress主要提供HTTP层（7层）路由功能，相比TCP（4层）的负载均衡具备非常多的优势（路由规则更加灵活、支持金丝雀、蓝绿、A/B Test发布模式、SSL支持、日志、监控、支持自定义扩展等），是目前K8s中HTTP/HTTPS服务的主流暴露方式。
文章插图
Ingress提供的7层负载均衡具有非常强大的能力，例如：

会话保持：让相同的session ID路由到同一台后端机器，保证每个用户的会话只在一台机器上处理。
基于内容的转发：能够根据HTTP协议内容进行转发，例如Host、URL甚至是PostBody等。
重写请求：能够对用户的请求进行动态修改，非常适用于新老系统的兼容性改造。
加密：在负载均衡上配置SSL ，提供统一的证书管理，每个服务器无需单独维护证书。
健康检查增强：可基于业务规则进行健康检查，而不仅仅是判断端口连通性，使健康检查更加精确。
日志监控：全量7层访问日志，能够获取每个请求的结果、耗时、请求大小等信息，能够基于访问日志监控到每个服务的质量。

Ingress日志分析与监控原始的访问日志记录了网站的每个访问请求，每个请求包括用户地址、Host、URL、状态码、耗时、请求大小等多个维度的信息，基于访问日志可以统计出不同维度下的访问qps、成功率、延迟等黄金指标，以此实现可以针对各种维度的网站质量监控。但构建一套完整的访问日志分析系统还是非常困难，这其中包括了很多过程和工作：采集、存储、分析、可视化、告警等。在实施过程中最为复杂的点在于：

采集问题：如何保证日志采集的可靠性、性能消耗、延时问题；
分析：在保证分析灵活性的同时能够保持快速的分析、查询速度以及较低的实施成本；
自动化：尤其在业务规模比较大的情况下，如何智能的监控和分析各个服务的状态是一个迫切需要的功能。

文章插图
为简化广大用户对于Ingress日志分析与监控的门槛，阿里云容器服务和日志服务将Ingress日志打通（官方文档），只需要应用一个yaml资源即可完成日志采集、分析、可视化等一整套Ingress日志方案的部署。这套系统主要包括：

日志实时采集方式：通过Logtail实时采集Ingress产生的输出日志，并进行格式转换
存储：SLS提供负载均衡的实时队列用于日志的存储，并提供按照TTL的存储方式，可任意设置保存的日志天数。
查询/分析：基于SLS提供的SQL92语法可实现对Ingress日志各个维度的交互式分析与计算，例如统计UV变化，访问请求分布， TOP延迟等。
可视化大盘：将常见的监控、分析场景需求以图表的形式固化成大盘，用户绝大部分时间只需要查看大盘即可了解整个系统的状态。

再次升级-从1.0到2.0

文章插图
Ingress日志分析与监控的方案已经发布2年左右，目前已经有上万的实例使用了该方案。在长期的使用中，我们也发现了这套方案的一些限制，为了适应新时代的DevOps节奏，我们需要对方案进行整体的升级，提供更加简单、更快速、更普惠、更智能的Ingress日志监控方案。

更简单：整个方案用户的使用更加简单，不需要去关注SLS的相关的资源，可以直接以单独Ingress监控APP的方式使用；
更快速：1.0的方案基于原始访问日志实时计算，在时间跨度较大或日志量较大的情况下查询速度较慢，使用体验较差；
更普惠：由于计算依赖原始日志，所以必须将日志长期保存，原始日志的存储量较高，会产生较高的费用；
更智能：随着K8s集群中运行服务数量的增加，传统的监控方式越来越吃力，依赖静态指标的告警规则很难监控所有的异常，因此急需更加智能的AIOps能力来解放生产力。

方案架构

文章插图
为了达到高性能、低成本、快速、智能等要求， SLS和阿里云容器服务团队联合对Ingress日志监控方案进行了一次架构升级，正式发布了2.0版本的Ingress日志中心，日志中心包括以下几个部分：