ADP底座技术白皮书

更新时间: 2023-04-12 10:13:05

本文从技术角度,阐述ADP底座的整体架构、非功能特性、运维信息,更好更全面地帮助客户理解ADP底座的核心能力,以便更好地被业务集成。

技术架构

应用架构

应用部署架构将云原生运行时环境分为业务产品和ADP底座两层,图中阐述了每一层的核心组件及依赖关系,可以让客户更加透明地了解到ADP底座的组成架构,如果出现问题,能够快速地确定是不是ADP底座的问题。

业务产品:包括业务层和中间件层。业务层即业务组件,一般包括无状态应用和有状态应用2种;中间件层主要为业务组件依赖的基础服务。

ADP底座:包括运维平台、异构运维插件层、应用驱动层、异构K8s层。运维平台ADP-Local承载了所有ADP底座的白屏运维能力;异构运维插件层提供了底座运维的各种功能;应用驱动层帮助安装底座自身和业务产品;异构K8s层主要包括K8s基础组件,其他K8s组件都是对原始的K8s容器服务进行增强。

另外需要注意,在ADP底座中的异构运维插件层中,我们通过自定义CR,最大化地复用了开源社区的运维规则,比如PrometheusRule、LokiRule等。对于运维规则来说,只要下发自定义CR到K8s中,ADP-Local就会自动发现这些运维规则,并且在控制台可视化展示,并不需要客户做特殊的配置。

image

服务架构

API服务依赖架构阐述了业务如何调用并依赖ADP底座提供的基础运维能力。为了让产品方更好地集成ADP底座并快速服务到业务,ADP底座主要划分为三层:

底座产品运维能力:ADP底座的运维对象基本可以概括为产品、组件、集群、节点,我们可以针对这些对象可以提供状态统计、监控大盘、监控指标、诊断规则、告警策略、运维操作、备份还原等能力。

底座基础运维设施:ADP底座内置了很多运维基础设施,这些基础设施并不区分具体的运维对象,可以提供最小粒度的原子运维能力,例如告警规则,并不限定告警的对象范围。一般通过自定义K8s CR向客户提供能力。

异构K8s:ADP Local既可以提供自建的ACK Distro,也可以使用客户已有的K8s服务,通过ADP交付工具将运维平台、产品实例安装到客户的异构K8s环境中。底座和产品的组件都是通过K8s API和K8s集群进行交互,不绑定具体的K8s版本,只对应K8s API兼容的版本范围。

3

部署架构

ADP底座要达到高可用,可以部署3个master,对于ADP底座来说,主要包含5种部署形式:

  • 二进制进程:只有kubelet是二进制进程。

  • static pod:主要包括kube-controlplane管控面组件,需要每个master部署。

  • deployment:无状态应用,可以随意部署到所有节点,例如cn-app-operator,还有部分deployment只能部署到任一master上,例如l-zero等K8s核心组件。

  • daemonset:主要是一些agent组件,例如yoda-agent,calico-node等。

注意:部分工作负载名称较长,为简称,需要看组件说明核对。

image

工作负载及容器进程说明:

K8s基础组件:

  • etcd:K8s集群的元数据库,存储了所有K8s的YAML元数据资源。

  • controller-manager:作为集群内部的管理控制中心,负责集群内的Node、Pod副本、服务端点(Endpoint)、命名空间(Namespace)、服务账号(ServiceAccount)、资源定额(ResourceQuota)的管理。

  • scheduler:负责整个集群资源的调度功能,根据特定的调度算法和策略。

  • api-server:提供了K8s各类资源对象(pod,RC,Service等)的增删改查及watch等HTTP Rest接口,是整个系统的数据总线和数据中心。

  • kube-proxy:是 kubernetes 工作节点上的一个网络代理组件,运行在每个节点上。

  • calico:网络插件,为云原生应用提供两大服务:工作负载之间的网络连接和工作负载之间的网络安全策略。

    • calico-kube-controller:

    • calico-node:calico网络

ACK-Distro:

  • l-zero: 集群诊断组件,用于集群安装时的预检和运行时的诊断

  • yoda:本地磁盘管理组件

    • yoda-scheduler-extender:作为Kubernetes调度器的扩展组件,增加本地存储调度算法

    • yoda-agent:运行在K8s集群的各个节点上,根据配置列表初始化存储设备,上报本地存储设备信息给

    • yoda-controller:获取存储的集群初始配置,并将详细的配置列表传递给每个节点上运行的Agent

运维组件:

  • adp-local:软件产品交付部署到本地环境中的本地运维控制台。

  • app-operator:应用管理器,包括应用部署和镜像管理。

    • cn-app-operator:应用部署控制器,管理Application CR。

    • cn-app-webhook:应用镜像地址替换为本地镜像地址。

  • logging:日志服务相关组件。

    • adp-logging:全名adp-local-adp-logging,日志采集器和字段提取控制器,管理LogCollector CR。依赖loki-stack相关API进行日志打标和日志转metrics。

    • loki-stack:日志收集服务端,接收来自 Promtail 发送的日志

    • loki-stack-promtail:日志收集客户端,以 DaemonSet 方式运行在各个计算节点上、当然也可以通过 sidercar 方式运行在 Pod 内部。Promtail 本身可以替换为 fluent-bit 或者 fluentd。

  • monitor:监控告警通知相关组件。

    • adp-monitor:全名adp-local-adp-monitor,自定义监控告警通知控制器,管理MetricDefinition、AlertStrategy、NotificationChannel、SubscribeGroup等CR。依赖alertmanager处理告警通知。

    • prometheus:全名prometheus-kube-prometheus-stack-prometheus,Prometheus服务器是Prometheus最核心的模块。它主要包含抓取、存储和查询这3个功能。

    • alertmanager:全名alertmanager-kube-prometheus-stack-alertmanager,接收Prometheus推送过来的告警,用于管理、整合和分发告警到不同的目的地。

    • grafana:全名kube-prometheus-stack-grafana,展示各种监控大盘,数据源来源于prometheus。

    • node-exporter:全名kube-prometheus-stack-prometheus-node-exporter,采集各个节点的存储、CPU、内存的指标采集器。

    • kube-state-metrics:全名kube-prometheus-stack-kube-state-metrics ,采集K8s容器、K8s基础组件的指标采集器。

  • operation:

    • adp-operation:全名adp-local-adp-operation,运维操作控制器,管理Operation、OperationRun CR。运维操作依赖函数执行每个步骤。

    • nuclio-controller:函数控制器,支持多语言函数和定时、消息触发器等,管理NuclioFunction等CR。

  • diagnosis:

    • adp-diagnosis:全名adp-local-adp-diagnosis,诊断控制器,管理诊断规则DiagnosisRule CR。

运维流程

为了解决现有的云原生应用运维问题,ADP总结了一套完整的自动化运维流程,在云原生开源技术的基础上,做了大量自研和增强。ADP的运维流程主要分为以下阶段:

image

应用部署管控:ADP内置了应用调度引擎让业务可以通过配置应用的底座参数、业务组件参数,从而面向终态的部署和运维。

监控告警发现问题:能够自定义监控大盘、自定义监控指标、自定义告警策略、自定义通知模板,帮助客户发现问题。

日志服务分析问题:可以自定义日志采集规则,采集各种来源的日志,可以对日志进行字段提取,还可以根据提取的字段进行日志查询和分析,还可以根据日志字段生成Metrics指标进行监控。

故障诊断定位问题:可以配置诊断规则,搜集K8s的事件、告警消息、各种日志诊断各种来源的信息定位问题根因,并且提供问题恢复方案。

运维操作解决问题:可以自定义各种运维操作,不同的组件有不同的运维操作。运维操作提供了多种触发方式,例如Metrics触发器、定时触发器、K8s事件触发器等。还可以对运维操作编排流水线。可以说Metrics触发器完美地解决了智能运维的问题。目前内置了常用中间件的运维操作(主从备份、扩缩容)、无状态应用的通用运维操作(水平扩缩容、垂直扩缩容、存储扩容、日志清理、灰度部署等)。

存储备份让问题留有后门:可以针对应用组件和集群两种维度进行存储备份及还原。对于要求高可用的场景,是非常有用的手段。

非功能特性

ADP底座治理与在稳定、轻量、高可用、安全、灵活非功能特性方面,进行深入打磨,并给客户良好的体验。

稳定

ADP底座经过多个生产级业务验证,稳定性较好。为了更好地保证稳定性,主要提供了以下手段:

集群管家:ADP底座能够集群整体、节点、工作负载级别的各个对象的健康分,通过健康分可以快速甄别当前环境是否稳定。对这些运维对象进行运维信息统计、深入诊断定位问题,并利用运维操作快速解决问题。

完善的预检机制:ADP底座提供了完善的预检和巡检机制,能够有效预防运行时问题的发生。

完善的可观测机制:ADP底座内置了集群整体、节点、工作负载级别的监控大盘和告警规则,能够快速地发现问题。

完善的诊断机制:ADP底座提供了根据诊断知识库的自动诊断能力,能够快速定位问题。

轻量

安装包小:ADP底座核心组件的镜像大小一般不超过50M。

运行时资源占用少:除了Prometheus和Loki等需要根据业务调整容量,核心运维组件的CPU和内存占用都相对较少。

IaaS资源占用少:ADP底座在极端情况下,可以通过单台8C16G机器拉起。

高可用

ADP底座由于内核是K8s容器服务,也符合云原生应用的高可用特性:

弹性:ADP底座的部分无状态应用,可以自如进行水平扩缩容、垂直扩缩容。

多副本:ADP底座的核心应用都是采用多副本,稳定性较好。

掉电自愈:掉电后,K8s会自动拉起服务并重启,所有应用都会恢复运行。

ADP底座经过大量自研和生产级业务验证,也提供了一些核心杀手锏:

备份还原:ADP底座可以针对集群级别、组件级别进行定期PV存储备份和还原,该能力适用于所有组件,对于核心级业务可以默认配置该功能。

安全

ADP底座有非常完善的安全认证机制,主要包括以下几方面:

镜像安全漏洞扫描:ADP底座集成的所有组件,都在集成之前进行了镜像安全漏洞扫描,最大程度地防止从容器层面受到不法攻击。

运维平台权限控制:ADP-Local提供了单点登录、功能权限、接口权限等多重权限控制,防止客户进行非法操作。

运维平台操作审计:ADP-Local提供了操作审计日志、访问日志等多种记录,可以让客户进行操作溯源。

命令行工具权限控制:ADP底座的K8s资源文件,天然配置了K8s的RBAC控制,最大限度地防止客户误删。

网络安全:ADP底座提供的所有组件,默认不暴露对外访问方式,除非客户自己配置。

灵活

可裁剪:参考底座部署架构,ADP底座的异构运维插件层,所有的插件可以根据客户环境,进行适当裁剪。

被集成:参考服务依赖架构,ADP底座可以让客户通过ADP-Local 微前端页面、ADP-Local OpenAPI、K8s API等多个层级,更好地集成ADP底座提供的运维能力。

兼容性:ADP底座对于IaaS层的兼容性相对良好,核心组件同时支持X86和ARM硬件架构,同时容器服务ACK发行版包含的高性能网络插件Hybridnet,又使得网络环境的多样性成为可能,最终确保能够丝滑运行于多样化的基础设施之上。

运维基础设施

系统存储

元数据库存储:ADP的底座元数据库就是存储底座组件资源定义的数据库。ADP的底座组件基本都是通过自定义CR,将元数据存储到etcd。

运维数据存储:ADP底座的运维数据主要包括审计日志、运维操作日志、告警消息、通知事件等,主要存储到本地PV。

系统日志

K8s有两种类型的系统组件,在容器中运行的和不在容器中运行的。例如:

  • Kubernetes 调度程序和 kube-proxy 在容器中运行。

  • kubelet 和 容器运行时 不在容器中运行。

在具有 systemd 的机器上,kubelet 和容器运行时写入 journald。否则,它们会写入.log目录中的/var/log文件。容器内的系统组件总是写入.log目录中的/var/log文件,绕过默认的日志机制。与容器日志类似,您应该轮换/var/log目录中的系统组件日志。在kube-up.sh脚本创建的 Kubernetes 集群中,日志轮换由logrotate工具配置。该logrotate工具每天轮换日志,或者一旦日志大小超过 100MB。

阿里云首页 云原生应用交付平台 相关技术圈