出售本站【域名】【外链】
做 者 | 徐可甲(烨陌)
云本生架构新风险取需求概述
安宁风险概述
传统的网络安宁架构理念是基于边界的安宁架构，企业构建网络安宁体系时，首先要作的是寻找安宁边界，把网络分别为外网、内网等差异的区域，而后正在边界上陈列防火墙、入侵检测、WAF等产品。然而那种网络安宁架构是基于内网比外网更安宁的如因建设起来，正在某种程度上预设了对内网中的人、方法和系统的信任，正视删强内网安宁门径。不法分子一旦冲破企业的边界安宁防护进入内网，会像进入无人之境，将带来重大的成因。另外，内部人员100%安宁的假说也是弗建立的，咱们可以从《内部威逼老原寰球报告》里看到，不论是内部威逼的数质，还是威逼老原都是呈显著回升的趋势。
跟着云计较、大数据、物联网、挪动办公等新技术取业务的深度融合，网络安宁边界也逐突变得愈加暗昧，传统边界安宁防照顾护士念面临弘大挑战。以办公网络安宁为例，曾经逐步从仅撑持公司内部网络方法连贯，展开到运用办公电脑通过VPN远程连贯，以至挪动办公的到来，使得个人手机等个人方法接入变为了可能。正在那样的布景下，零信任架构（Zero Trust Architecture, ZTA）应运而生。它突破传统的认证，即信任边界防护、静态会见控制、以网络为核心等防护思路，建设起一套以身份为核心，以连续认证、动态会见控制、审计以及监测为链条，以最小化真时授权为焦点，以多维信任算法为根原，认证达终实个动态安宁架构。
咱们晓得Kubernetes正在容器编排市场中占据了主导职位中央，用户基数呈逐年回升的趋势。K8s供给了壮大的运维陈列、弹性伸缩、毛病规复才华，极大地方便了分布式系统的开发和打点，但是随之而来的安宁问题却也比较突出。
依据《容器和Kubernetes安宁态势报告》报告，针对云本生使用的威逼已越来越多，仅有6%的人没有教训过取容器或K8s相关的安宁变乱。同时，还指出近70%的安宁风险都是由酬报舛错配置而激发的，另外运止时安宁及严峻安宁漏洞激发的安宁变乱也是重要的果素。《中国云本生用户盘问拜访报告》同样也撑持，容器安宁问题成为用户使用的最大担心。63%的用户认为容器安宁是紧迫的需求，大质用户应声网络安宁技术施止难度复纯度高，且监控系统、日志系统不完善，很难停行有效的安宁监控。
从上述的报告可以看出，K8s安宁问题会分布正在整个生命周期的各个阶段。一些常见的安宁风险暗示为：容器镜像漏洞或滥用镜像货仓招致的漏洞；容器大质陈列招致很难发觉安宁问题；K8s焦点组件漏洞威逼，多个高危漏洞爆出；集群配置欠妥，以至一些默许配置有安宁隐患；没有明白网络边界，网络断绝性问题；打击面变大、监控和防护难度大。果此，咱们迫切须要建设一个全方位的安宁体系，笼罩整个容器生命周期的各个阶段。
构建时：基于安宁的镜像货仓、权限最小化的安宁镜像构建业务系统，实时修复已知漏洞。
陈列时：依照K8s最佳理论陈列，修复舛错配置。
运止时：连续监控安宁威逼，并实时作出相应。
K8s 安宁体系
上图为阿里云容器效逸Kubernetes版给出的安宁体系，可以看出构建完善的安宁体系从下到上须要笼罩根原架构安宁、可信软件供应链、运止时安宁三个维度。
根原架构安宁：基于CIS kubernetes benchmark辅导安宁副署；依赖K8s的安宁体系，建设细粒度的会见控制机制。
可信软件供应链：通过镜像扫描发现已知安宁漏洞；通过镜像签名保障镜像起源的安宁性及不被窜改；通过DevSecOps集成，真现安宁右移，取开发、测试、运维等量质止动停行深度融合。
运止时安宁：通过PodSecurityPolicy针对容器陈列时停行安宁校验，有效约束使用运止时的止为安宁；使用运止时的安宁配置巡检；连续的无处不正在的运止时安宁监控机制和异样变乱告警通知机制，担保安宁变乱的实时发现及处置惩罚惩罚；选用安宁沙箱，供给更强的断绝环境。
咱们发现上述安宁体系可以跟零信任战略的“从不信任、始末验证”的思想相呼应的。
K8s 信任边界
为了更好的了解K8s系统的安宁风险，接下来咱们从K8s内外部网络边界的角度开展阐明。此中，红色直线局部可以被视为独立边界的子系统。
容器镜像：次要波及到的安宁打击点便是镜像货仓和镜像自身。此中，运用了不受信任的镜像货仓或被窜改的容器镜像会招致恶意代码被执止。
K8s控制平面：波及K8s 的 API Server、scheduler 和 controller-manager焦点组件等。此中API Server为K8s系统管控入口，是重点的打击对象。此外，焦点组件之间挪用链的安宁也同样重要。
K8s数据平面：波及Ingress Controller跟Service，Ingress做为内部效逸对外露出的端口，被打击风险较大。
节点上运止时安宁：波及kubelet、kube-proxy 和容器运止时环境，须要防行运止时容器越权或容器追劳等风险。
K8s安宁打击起源寡多，既可能是来自外部的控制平面打击，也可能是来自外部流质的数据面打击，以至可能是来自内部成员的恶意打击大概误收配等。果此，K8s打击面出格广，防护难度大，为了更好的护卫K8s安宁运止，须要倡议起一套战略防护跟监控防护相联结的防护体系。
原文重点将环绕监控防护开展，逐层递进地引见如安正在复纯的分布式容器化环境中借助可不雅视察性平台，连续监控K8s集群，实时发现异样的 API 会见变乱、异样流质、异样配置、异素日志等止为，并且联结折法的告警战略建设更自动的安宁防御体系。
K8s 场景下安宁数据支罗技术方案
安宁数据是做为K8s安宁监控的根基，假如没无数据这便是“巧妇难为无米之炊”，任何高级的监控战略都无从谈起。果此，首先咱们将会引见K8s相关的安宁数据源及相关的支罗技术。
安宁数据源
K8s 审计日志
正在 Kubernetes 中，Api Server是K8s集群资源变更、查问的入口，所有对集群形态的查问和批改都是通过向 Api Server 发送乞求，对 Api Server 的乞求起源可以分为4类：
控制面组件，譬喻 Scheduler，各类 Controller，Api Server 原身。
节点上的各类 Agent，譬喻 Kubelet、Kube-proxy 等。
集群的其他效逸，譬喻 Coredns、Ingress-controller、各类第三方的 Operator 等。
外部用户，譬喻运维人员通过 Kubectl。
Kubernetes 审计日志是 Api Server 孕育发作的构造化日志，记录了对 Api Server 的会见收配（蕴含光阳、起源、收配结因、建议收配的用户、收配的资源以及乞求/响应的具体信息等）。通过审计日志，可以逃溯对集群形态的变更；理解集群的运止情况；排查异样；发现集群潜正在的安宁、机能风险等等。蕴含不限于如下止为：
当前/汗青上集群发作了哪些变更变乱。
那些变更收配者是谁，是系统组件还是用户，是哪个系统组件/用户。
重要变更变乱的具体内容是什么，比如批改了POD中的哪个参数。
变乱的结因是什么，乐成还是失败。
收配用户来自哪里，集群内还是集群外。
Kubernetes Event
变乱（Event）次要是用来记录K8s集群内发作的形态变更，大到集群节点异样，小到 Pod 启动、调治乐成等。变乱具体记录了集群形态变更发作的光阳、组件、品级（Normal、Warning、Error）、类型、具体信息，通过变乱能够晓得使用的陈列、调治、运止、进止等整个生命周期，也能通过变乱去理解系统中正正在发作的一些异样。
K8s变乱存储正在etcd中，默许状况下只保存1个小时，由于etcd其真不撑持一些复纯的阐明收配，只供给了很是简略的过滤方式，比如通过Reason、光阳、类型等。同时那些变乱只是被动的存正在etcd中，其真不撑持自动推送到其余系统，但凡只能手动的去查察。而真际上咱们对变乱的运用需求很是高，比较典型的场景如下：
对系统中的异样变乱作真时告警，譬喻Failed、Evicted、FailedMount、FailedScheduling等。
但凡问题排查可能要去查找汗青数据，果此须要去查问更长光阳领域的变乱（几多天以至几多个月）。
变乱撑持归类统计，譬喻能够计较变乱发作的趋势以及取上一光阳段（今天/上周/发布前）对照，以便基于统计目标停行判断和决策。
撑持差异的人员依照各类维度去作过滤、挑选。
撑持自界说的订阅那些变乱去作自界说的监控，以便和公司内部的陈列运维平台集成。
默许状况下，Kubernetes变乱只关注容器打点相关的问题，应付硬件、收配系统、容器运止时、依赖系统（网络、存储等）其真不会供给更多的检测才华。NPD（node-problem-detector）做为Kubernetes节点诊断的工具，可以将节点的异样转换为Node的变乱，并推送到APIServer中，交由APIServer停行变乱的统一打点。NPD撑持多种异样检查，譬喻：
根原效逸问题：NTP效逸未启动。
硬件问题：CPU、内存、磁盘、网卡损坏Kernel问题：Kernel hang，文件系统损坏。
容器运止时问题：Docker hang，Docker无奈启动。
之后，可以借助开源变乱工具kube-eventer，将集群的变乱离线到钉钉、SLS、Kafka等系统，并供给差异品级的过滤条件，真现变乱的真时支罗、定向告警、异步归档。
Ingress
K8s中Ingress只是一种API资源的声明，详细的真现须要拆置对应的Ingress Controller，由Ingress Controller接支Ingress界说，将流质转发到对应的Service。目前Ingress Controller有很是多种真现，罕用的的是Nginx Ingress Controller。
日志和监控是所有Ingress Controller都会供给的根原罪能，日志正常蕴含会见日志（Access Log）、控制日志（Controller Log）和舛错日志（Error Log），监控次要从日志以及Controller中提与局部Metric信息。那些数据中会见日志的质级最大、信息最多、价值也最高，正常7层的会见日志蕴含：URL、源IP、UserAgent、形态码、入流质、出流质、响应光阳等，应付Ingress Controller那种转发型的日志，还蕴含转发的Service名、Service响应光阳等格外信息。从那些信息中，咱们能够阐明出很是多的信息，譬喻：
网站会见的PV、UV；
会见的地域分布、方法端分布；
网站会见的舛错比例；
后端效逸的响应延迟；
差异URL会见分布。
K8s 配置安宁
CIS Kubernetes Benchmark是CIS推出的一系列用于构建一个安宁牢靠的Kubernetes集群的安宁配置倡议，K8s运用者可以基于那些标准构建安宁的K8s集群。但是人工一个个去比对安宁配置规矩的倡议显然是不适宜的，正常会联结一些巡检工具停行。
security-inspector是一款针对K8s Workload配置停行多维度扫描工具，可以正在巡检报告中查察巡检扫描结因，蕴含安康检查、镜像、网络、资源、安宁等扫描信息。另外，kube-bench、kube-hunter等其余开源名目也是可选用的CIS规矩巡检方案。
K8s 运止时安宁
Falco是一款云本生运止时安宁开源名目，用于监控Kubernetes上使用的运止时异样流动。Falco正在内核态通过监控文件变动、网络流动、进程表和其余数据能否存正在可疑止为，并可以通过可插拔后端发送警报。
通过 Falco 可轻松检测以下异样：
容器内运止的 Shell
效逸器进程孕育发作不测类型的子进程
敏感文件读与（如 /etc/shadow）
非方法文件写入至 /dev
系统的范例二进制文件（如 ls）孕育发作出站流质
K8s 安宁数据源特点
以上咱们列举了一些K8s安宁监控场景下常见的数据源，而且每种日志特点各异。咱们可以发现安宁类数据品种繁多，起源寡多，格局也不统一。总结下来具有如下特点：
安宁数据类型包孕了日志、目标、变乱。
安宁数据可能是来自文件，也有可能来自范例输出大概范例舛错，以至可能是Syslog等范例和谈。
安宁文原数据可能会存正在于容器内的文件大概宿主机上的文件。
Ingress会见日志等波及数据面流质的日志往往会数据质极大。
审计日志做为集群安宁审计的必备日志，重要性极高，须要长光阳跨度存储（等保2.0要求至少须要存180天），并且不能有支罗的损失。
为了更片面的支罗安宁数据，须要具备一赋机能壮大、生态撑持片面、K8s本生撑持的安宁数据支罗器。该支罗器须要具备以下才华：
容器运止时撑持的片面性，可以撑持Docker、Containerd等运止时。
K8s供给了壮大的动态扩缩容才华，但也同时给数据支罗带了艰难。果此，支罗器须要适应容器动态的特点。
有些安宁数据是通过Job触发的，该类任务具有生命周期短的特点，支罗器须要供给短生命周期容器的支罗才华。
所支罗须要具备联系干系K8s高下文的才华，为后续阐明供给便利。
壮大的数据办理才华，可以正在不影响机能的前提下完成安宁数据的办理需求，为后续阐明场景打下根原。
K8s云上托管效逸越来越风止，须要能够撑持云上效逸的支罗场景。
K8s 支罗技术
阿里云SLS开源的可不雅视察数据支罗器iLogtail，可以彻底满足上述安宁数据的特点及场景要求，并且颠终阿里双十一、公有云等寡多复纯场景考验，正在安宁数据支罗规模也是一个很好的选择。接下来，咱们重点引见下iLogtail的技术特点及K8s下的支罗本理。
可不雅视察数据支罗器 iLogtail
iLogtail的焦点定位是可不雅视察数据的支罗器，协助开发者构建统一的数据支罗层，助力可不雅视察平台打造各类上层的使用场景。2022年6月底，阿里云iLogtail代码完好开源，正式发布了完好罪能的iLogtail社区版。
iLogtail 焦点劣势
轻质级、高机能
iLogtail主体局部通过C++，插件局部Golang真现，不论内存还是CPU具有自然的机能劣势。
iLogtail也连续针对性的作了不少特定场景的劣化，比如针对日志的极简、Json、正则形式支罗供给了C++加快才华，极大提升了日志支罗效率，单核支罗流质最高能到百M/s。
超强牢靠性
iLogtail做为阿里团体内重要的可不雅视察数据支罗根原设备，多年来接续不乱撑持双11等大促场景，正在应对网络堵塞、流质洪峰、进程重启等方面暗示突出。
公有云上iLogtail也连续撑持着各止各业的客户，寡多复纯业务场景应付iLogtail的牢靠性供给了足够的场景撑持。
毫秒级延时
iLogtail真现如此高吞吐的法门之一是运用了无锁化变乱办理模型。取业界其余开源Agent为每个配置分配独立线程/Goroutine读与数据差异，iLogtail数据的读与只配置了一个线程。由于数据读与的瓶颈其真不正在于计较而是磁盘，单线程足以完成所有配置的变乱办理以及数据读与。运用单线程使得iLogtail的变乱办理和数据读与都可以正在无锁环境下运止，数据构造愈加轻质化，从而得到了相对多线程办理更劣的性价比。
文件支罗基于inotify取polling相联结的发现机制，既借助了inotify的低延迟取低机能泯灭的特点，也通过polling的方式统筹了运止环境的片面性。
云本生撑持
iLogtail供给了业务容器真时动态发现才华，并撑持通过K8s元信息（譬喻Label、环境变质等）停行支罗过滤。出格是一些短Job场景，比如一些呆板进修的训练任务，生命周期只要几多分钟以至几多十秒，也供给了片面的友好的撑持。
陈列形式上，也撑持DaemonsSet、Sidecar等多种形式。
为了更本生的K8s撑持，也供给了Operator机制，用户可以通过CRD的方式停行支罗配置打点。
插件化扩展才华
高粗俗生态：通过插件系统的扩展，目前iLogtail曾经撑持了寡大都据源的接入，数据源类型笼罩Log、Metric、Trace，数据源除了文件的支罗，还蕴含了范例和谈的撑持，譬喻HTTP、Mysql Binlog、Prometheus、Skywalking、syslog等。数据输出生态也从SLS逐步扩展到Kafka、gPRC等，将来也会撑持ClickHouse、ElasticSearch等。
办理才华扩展：iLogtail给取PipeLine的设想，通过Input插件支罗到数据，会颠终支罗配置中设定的Processor办理，之后颠终Aggregator插件打包，最末通过Flusher发送到日志存储系统。数据办理环境包孕数据切分、字段提与、过滤、数据加强等环节，所有插件可以自由组折。另外，针应付正则、Json、分隔断绝结合符等特定格局，iLogtail还供给了C++加快才华。
快捷迭代：开发者也可以依据原人的需求，定制开发相应的插件。果为每个插件互相独立，所以开发者只须要依照接口标准开发便可，着手门槛较低。
多租户断绝
iLogtail给取基于光阳片的支罗调治、多级上下水位应声队列、变乱非阻塞办理、流控/停采战略以及配置动态更新等多项要害技术，融合真现了兼具断绝性、公平性、牢靠性、可控性、性价比五大特性的多租户断绝方案。
iLogtail 陈列形式
做为容器编排规模的范例，Kubernetes（K8s）使用的场景越来越宽泛，iLogtail 正在K8s下也供给了齐备的支罗才华。正在K8s场景下，iLogtail次要罕用的有3种工做形式：
DaemonSet方式：正在K8s的每个node上陈列一个iLogtail，由该iLogtail支罗节点上所有容器的日志到日志系统。此方式特点是运维简略、资源占用少、撑持支罗容器的范例输出和文原文件、配置方式活络，但是正在超大集群存正在一定的机能瓶颈。
Sidecar方式：一个POD中随同业务容器运止一个iLogtail容器，用于支罗该POD中业务容器孕育发作的日志。此方式特点是多租户断绝性好、机能好，但是资源占用较多。
Deployment方式：当业务容器用PVC挂载日志目录大概须要全局连贯API Server获与K8s元数据等场景，可以选择正在集群中陈列一个单正原的iLogtail Deployment停行数据支罗。
iLogtail 支罗本理
自K8s问世以来，Docker运止时接续是收流，但是跟着K8s将dockershim移除，K8s官方引荐劣先选择Containerd 或 CRI-O做为容器运止时。Docker份额目前尽管还是收流但是曾经正在呈逐年下降的趋势，Containerd、CRI-O职位中央逐年都正在快捷回升。果此，从K8s撑持片面性上，iLogtail须要撑持收流的运止时，目前曾经撑持Docker和Containerd两种容器引擎的数据支罗。
K8s供给了壮大的运维陈列、弹性伸缩、毛病规复才华，极大地方便了分布式系统的开发和打点，然而那也带来了可不雅视察数据支罗难度的删大。出格是一些短Job场景，比如一些呆板进修的训练任务，生命周期只要几多分钟以至几多秒，如何快捷精确地发现所须要支罗的容器至关重要。iLogtail正在K8s场景下的支罗分为如下几多个轨范：
容器主动发现取开释：iLogtail通过会见位于宿主机上容器运止时（Docker Engine/ContainerD）的sock获与容器信息，并通过监听Docker Event及删质获与机制，实时感知容器新删取开释。
容器高下文信息获与：蕴含容器层级信息，譬喻容器名、ID、挂载点、环境变质、Label；以及K8s层级信息，譬喻Pod、定名空间、Labels。
容器过滤及断绝性：基于容器高下文信息，供给支罗容器过滤才华，可以将差异支罗配置使用赴任异的支罗容器上，既可以担保支罗的断绝性，也可以减少没必要要的资源华侈。
元信息联系干系：基于容器高下文信息和容器环境变质，供给正在日志中富化K8s元信息的才华。
支罗途径发现：依据容器元信息主动识别差异运止时的范例输尤其式和日志途径；应付overlay、overlay2的存储驱动，可以依据日志类型及容器运止时主动拼接出支罗途径，简略高效。
另外，应付CICD主动化陈列和运维程度要求较高的用户，iLogtail还供给了K8s本生撑持，撑持通过CRD的方式停行支罗配置打点。目前该罪能仅企业版可用，后续会逐步开源。该方案中，iLogtail K8s新删了一个CustomResourceDefinition扩展，名为AliyunLogConfig。同时开发了alibaba-log-controller用于监听AliyunLogConfig变乱并主动创立iLogtail的支罗配置，进而完成日志支罗工做。
安宁数据监测取响应最佳理论
统一存储阐明引擎
安宁数据监控一个重要的才华便是对支罗到的数据，停行真时的折规监控阐明，撑持对汗青数据的折规审计，对来自外部的威逼和内部的违规停行审计阐明。真际安宁阐明场景往往碰面临寡多艰难：
安宁威逼往往是一个逐步的历程，可能须要几多个月或更长的光阳才会实正露出出来。果此，须要供给低老原的存储才华，及壮大的长光阳跨度数据阐明才华。
安宁数据起源寡多，格局不统一，日志、时序数据都可能波及。有些安宁威逼荫蔽性较强，须要多种数据的联动阐明威力发现。果此，须要具备壮大的联系干系阐明才华。
为此，咱们设想了一套统一的可不雅视察数据存储阐明引擎。将日志、目标、Meta等数据全副接入到统一的存储中，正在一些等保场景可以通过开启智能冷热分层存储，降低不生动数据的存储老原。之后，咱们构建了一套统一的查问阐明引擎，该引擎以SQL为根原，扩展了要害词查问、PromQL语法才华及呆板进修算子才华，可便捷收撑查问阐明、可视化、监控诉警、AI 等上层使用场景。同时，SQL做为顶层语言，可以起到串联日志、时序、ML模型、CMDB、外部DB的才华，使得大范围大都据联系干系阐明成为可能。
可以认为，SLS SQL = Search + SQL92（Agg，WIndow，GroupBy...）+ PromQL + ...
以下便是一个比较典型的阐明的例子：
咱们可以通过范例 SQL 语句对日志停行阐明。
还可以通过 PromQL 扩展的 SQL 函数对目标数据停行阐明。
还可以通过嵌套查问，对目标数据的阐明结因停行再聚折。
另外还可以再通过呆板进修函数，给查问和阐明赋予 AI 的才华。
尽管差异阶段的数据孕育发作自差异的系统，也有着差异的格局，但是由于它们的存储和阐明是一致的，咱们可以很是轻松地真现统一的安宁态势及安宁变乱监控。
智能巡检
Ingress会见日志孕育发作质极大，而且取日俱删后会组成大质数据存储，会组成存储老原的急剧回升，并且正在长光阳跨度查问阐明场景下也会效率极低。
为了抵达高机能、低老原、快捷、智能等要求，咱们对Ingress那种超大数据质的方案停行了架构晋级。
本始会见日志存储：当Ingress Controller孕育发作会见乞求后，会真时将乞求的会见日志推送到用户原身的日志库中，SLS的Logstore具备高牢靠、真时索引、主动扩容等罪能，担保日志的牢靠性和可扩展性。
预聚和：由于本始会见日志质弘大，基于本始日志计较目标机能开销较大，果此咱们专门推出了基于会见日志的目标预聚和才华，能够将上百万以至上亿的会见日志真时聚分解目标类型的时序数据，数据质会降低1-2个数质级，后续的阐明取监控可间接基于时序数据停行，大大进步效率。
智能巡检：应付预聚和后的Metrics（目标数据），咱们供给了基于呆板进修的智能巡检罪能，协助用户主动去检测Ingress的各个维度的目标异样，将异样信息真时展如今时序的图表中，联结真时告警才华实时通知给用户处置惩罚惩罚。另外后续还会撑持异样打标，基于用户应声的信息停行愈加正确的检测。
通过以上3层数据链路，真现了从本始会见日志到预聚和的目标最后再到呆板进修的异样变乱整个数据的流转，应付用户来说，告警和监控只须要基于目标和智能巡检的结因停行，而波及到详细效逸的问题阐明可以再回到本始的会见日志并基于统一查问阐明引擎停行自界说的排查和阐明。
老原高、查问效率低：应付日志质极大场景，出格假如再加上长光阳跨度的果素，会组成存储老原的急剧回升，查问效率往往也很低。
效率低：应付异样现场的定位，须要人工配置各类千般的规矩去停行异样的捕获。
时效差：大局部时序数据具有时效性特征。毛病、变更都会惹起对应目标状态的厘革，前一种规矩条件下的异样可能正在下一时刻是一般形态。
配置难：时序数据状态各异。有突刺厘革、合点厘革、周期厘革等诸多状态，阈值领域也各有差异。应付复纯状态下的异样，规矩往往难以配置。
成效差：数据流不停动态厘革，业务状态日新月异，牢固的规矩办法很难正在新的业态下起做用，从而孕育发作大质的误报大概漏报。应付异样的程度，差异场景，差异用户，对其容忍的程度差异。正在排盘问题中，有效异样点捕捉的越多，有助于详细问题的排查；而正在告警通知中，高危异样点越少，越有助于提升告警办理的效率。
针对以上问题，咱们推出智能巡检罪能，通过自研的人工智能算法，对目标、日志等流数据停行一站式整折、巡检取告警。运用智能巡检罪能后，只须要组织一下详细的监控项，算法模型就会主动完成异样检测、业态自适应、告警精密。
安宁态势
咱们供给了安宁态势大盘，协助用户全局理解安宁变乱、安宁态势，便于停行告警链路查察及排错运用。另外，报表还可自由扩展。譬喻审计日志、Ingress核心等大盘，可以清楚的展现K8s集群的控制面、数据面会见状况，蕴含统计、趋势、地域等；变乱核心可以展现集群内的一些异样流动，譬喻POD OOM、节点重启等。
告警取 On-Call 机制
通过上文提到的统一的数据支罗才华、统一的存储及查问阐明才华，咱们可以作到对安宁威逼的根柢探测才华。但是要构建齐备的监控体系，接下来就要处置惩罚惩罚如何连续监控的问题。为此，咱们开发了一套一站式智能运维告警系统。它供给对日志、时序等各种数据的告警监控，告警模版化扩展才华，亦可承受三方告警，对告警停行降噪、变乱打点、通知打点等。
咱们也针对K8s下一些典型安宁场景的汗青经历，供给了寡多内置告警规矩，开箱即用并连续删多中。那些规矩库有笼罩了CIS和安宁场景的最佳理论，用户仅需开启对应规矩，便可享遭到全天候的安宁保障。
当告警规矩探测到异样发作时，须要尽快的将威逼变乱通知给相应的开发人员。咱们对接了富厚的通知渠道，便于威逼变乱的全方位触达。
多渠道：撑持短信、语音、邮件、钉钉、企业微信、飞书、Slack等多种通知渠道，同时还撑持通过自界说 Webhook 停行扩展。同一个告警，撑持同时通过多个渠道、每个渠道运用差异的通知内容停行发送。譬喻通过语音和钉钉来停行告警通知，既可以担保触达强度，又可以担保通知内容的富厚程度。
动态通知：可以依据告警属性动态分拨通知。譬喻：测试环境的告警，通过短信通知到张三，并且只正在工唱光阳通知；而消费环境的告警，通过电话通知到张三和李四，并且无论何时，都要停行通知。
通知晋级：长光阳未处置惩罚惩罚的告警要停行晋级。譬喻某告警触发后，通过短信通知到了某员工，但是该问题长光阳未被办理，招致告警接续没有规复，此时须要通知晋级，通过语音的方式通知到该员工的指点。
安宁变乱发作后，假如不实时办理或不慎遗漏都会组成更大的安宁风险扩展。果此，一定要建设齐备的应声机制，将安宁问题办理造成闭环。基于那个问题，咱们供给了安宁变乱打点核心，便于用户全局查察安宁变乱，并停行相应的打点止动。当开发或安宁人员接管到安宁告警变乱通知后，可以登陆安宁变乱打点核心停行变乱确真认、办理人的指派、办理止动记录等收配。
基于云本生可不雅视察平台构建 K8s 下的 SecOps 才华
综上，咱们可以基于阿里云SLS搭建一个罪能齐备的K8s安宁监控体系。整体分为四个层次：
数据支罗层：次要供给安宁数据接入才华。此中以iLogtail为最次要的数据支罗方式（撑持前置的数据办理才华），并且同时撑持API方式，兼容寡多范例和谈，譬喻OpenTelemetry、Prometheus、Syslog、Kafka等。
统一存储阐明层：供给了针对Logs、Metric、Trace、安宁变乱、Topo等多种数据的存储层，并且正在此根原上供给了统一的数据联系干系阐明才华。应付不规矩数据，供给了数据加工才华。
智能效逸：基于智能告警效逸，可以真现安宁场景的连续监控及通知响应才华；智能算法效逸供给了智能巡检罪能可以扩展智能巡检、阐明的才华。
上层使用：基于上述三层可以打造属于用户原人的SecOps使用。虽然应付ITOps、DevOps、BussinessOPS也是不错的选择。
K8s 安宁监控体系展望
将来已来，K8s安宁监控体系将来将朝着生态化、轻质化、智能化、一体化的标的目的继续展开，为企业安宁保驾护航。
iLogtail 已开源，接待运用及共建
iLogtail做为阿里云SLS供给的可不雅视察数据支罗器，可以运止正在效逸器、容器、K8s、嵌入式等多种环境，撑持支罗数百种可不雅视察数据（日志、监控、Trace、变乱等），曾经有千万级的拆置质。目前，iLogtail已正式开源，接待运用及参取共建。
GitHub: https://github.com/alibaba/ilogtail
社区版文档：https://ilogtail.gitbook.io/ilogtail-docs/about/readme
企业版官网：https://help.aliyun.com/document_detail/65018.html
参考：
最全Kubernetes审计日志方案：https://developer.aliyun.com/article/686982
Kubernetes可不雅察看性：全方位变乱监控：https://developer.aliyun.com/article/745567
零信任战略下云上安宁信息取变乱打点最佳理论：https://developer.aliyun.com/article/812284
阿里可不雅视察性数据引擎的技术理论：https://developer.aliyun.com/article/814339
阿里 PB 级 Kubernetes 日志平台建立理论：https://developer.aliyun.com/article/704058
Kubernetes 安宁风险以及 29 个最佳理论：https://mp.weixin.qq.com/s/aMadv2d3jHPJyV2h42r8sQ
