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日志中心，日志中心包括以下几个部分：

原始访问日志存储：当Ingress Controller产生访问请求后，会实时将请求的访问日志推送到用户自身的Logstore中，整个过程的延迟一般在3-5秒即可完成，SLS的Logstore具备高可靠、实时索引、自动扩容等功能，保证日志的可靠性和可扩展性。
预聚和：由于原始访问日志量巨大，基于原始日志计算指标性能开销较大，因此SLS专门推出了基于访问日志的指标预聚和能力，能够将上百万甚至上亿的访问日志实时聚合成指标类型的时序数据，数据量会降低1-2个数量级，后续的分析与监控可直接基于时序数据进行，大大提高效率。
智能巡检：对于预聚和后的Metrics（指标数据），SLS提供了机器学习的自动巡检功能，帮助用户自动去检测各个Ingress的各个维度的指标异常，将异常信息实时展现在时序的图表中，结合实时告警能力进行自动的告警配置。此外后续还会支持异常打标，基于用户反馈的信息进行更加精确的检测。

通过以上3层数据链路，实现了从原始访问日志到预聚和的指标最后再到机器学习的异常事件整个数据的流转，对于用户来说，告警和监控只需要基于指标和智能巡检的结果进行，而涉及到具体服务的问题分析可以再回到原始的访问日志并基于SLS提供的各种SQL统计方式进行自定义的排查和分析。

实时预聚和

Ingress的访问日志数量和用户访问成正比，在原始访问日志上实时计算指标的开销较大，一般不适合长时间的指标分析，并且原始日志存储的成本较高，一般不会将日志存储较长时间，但我们还是希望指标数据能够尽可能长的存储，这样可以在分析的时候查看更长时间的数据。为此SLS专门为Ingress访问日志定制了一套全托管指标实时预聚合的功能，能够实时将Ingress的访问日志聚合成指标并存储在SLS的时序库中，这样所有的监控数据查询工作都可以基于聚合后的时序数据进行，大大提升监控数据的查询效率。

丰富可视化

Ingress访问日志分析的一个重要工作是可视化系统的搭建，我们需要针对不同场景创建不同的报表以便满足各个方面的需求，例如：

整体大盘：包括网站当前的访问UV/PV、整体延迟、成功率等，这个是老板们和SRE需要看的数据，需要保证数据时效性和刷新的速度
监控大盘：能够把监控需要关注的各种数据（延迟（平均、P99/P9999等）、流量、成功率、错误码、TOP类统计）等显示在一张报表上，并且能够支持各种维度的过滤，方便定位到问题的实例。
访问大盘：显示和用户相关的访问信息，例如PV/UV、访问的地域分布、设备分布等，一般情况技术Leader会关注，另外部分的运营同学可能也会需要这部分数据。
异常大盘：显示异常巡检的指标信息，能够把异常的指标显示在报表上，方便查看。
后端流量分析：快速分析后端的流量、QPS、延迟、错误率等分布信息，能够快速查找到“调皮”的机器。

智能巡检

在时序监控场景中，用户往往先确定监控对象，并通过其历史数据，结合业务经验，得到不同组的阈值参数，通过各种手段（同比、环比、连续触发几次等）进行监控，往往一个监控对象要设计4～5条监控规则，并配置不同的参数。还有更大的问题，各个参数阈值无法快速的复用到不同的类似观测对象中，当观测对象的规模达到数千，甚至上万后，传统的配置效率底下，无法满足在大规则时序指标数据下的监控需求。流式算法具有天然的优势可以解决上面的问题，用户只需要发起一个机器学习服务，模型自动拉取数据，实时训练，实时反馈（通俗地说：“来一个点，学习一个点，检测一个点”），在极大的降低成本的同时，实现对每一条线的单独建模，单独分析，单独模型参数保存，实现时序异常检测的“千线千面”。

智能HPA

基于业务访问量的HPA

HPA（Horizontal Pod Autoscaler）是Kubernetes提供的一个标准组件，用于POD的横向自动扩缩容，例如：当Pod CPU、内存等指标上升到一定程度时会自动扩容，当这些指标下去后会自动缩容。这样能够保证在用户体验不变的情况下集群整体的资源使用都能处于一个较低的位置。

默认的HPA只能针对集群的一些标准指标（CPU、内存、网络等）进行扩容，这种扩容方式相对静态，而且反应不出业务的情况。因此我们对HPA进行了一些扩展，支持按照Ingress访问QPS进行扩容。即可以设置某个Service下的Pod限定能够处理的QPS，当QPS上升到一定高度时会自动扩容一些Pod/节点，当QPS下降时会自动缩容一些Pod/节点。

基于业务量预测的HPA

HPA的预测原理是判断某些指标的值进行扩缩容，而指标的值相对来说都有10-30秒左右的延迟，并且还有几次的double check时间，因此从压力上升到扩容的时间基本上在2-3分钟左右，如果Pod启动还需要预热的话可能要更久，这段期间用户的访问请求很可能会出现高延迟或错误的情况。

因此最好的方式是我们能够提前知道未来几分钟的访问请求量，当我们发现未来访问请求会很高的时候，提前把Pod扩容出来并进行预热，这样可以在请求真正提升时Pod的资源已经提前分配好。为此我们结合SLS与阿里云达摩院联合研发的多模型预测算法，实时预测Ingress上每个服务的访问请求，并把这些预测的指标提供给HPA做动态扩容，能够在请求量即将超过阈值的时候提前扩出Pod/节点，保证用户访问一直流畅。