EC2 VS EKS

在当前我们接入新应用的可观测性，当前的做法是在AWS云上开一台新的EC2，并初始化配置（APM\RUM\LOG），并创建ALB绑定到R53上面达到新应用可以通过域名将监控数据传递给Datakit（EC2），这个导致每一次新新应用的接入都需要创建新的基础设施（Terraform），这样去绑定在某种程度上将监控数据达到了不同应用支持不同数据的上报需求并数据互不影响。

一、背景

当前接入的观测云的应用与观测云采集器（Datakit）的搭配是一个环境对应一个Datakit。

1.当前方案优势

采用这种方式主要有以下几点：

• 应用接入方可以独用URL，每个应用上报数据互不影响
• 每个应用独享EC2资源，应用升级互不影响
• 通过Terraform进行服务器部署，基础设施可视化
• 资源只涉及到EC2，使用成本低

2.当前方案存在问题

在接入应用初期，安装的Datakit运行还算稳定，但是随着接入的应用越来越多，需要的功能也越来越多，随之而来的问题也接踵而至，在使用上主要问题有这么几点：

1. 多台部署Datakit的EC2不方便管理（升级、打补丁、安全漏洞）
2. EC2 资源利用不充分
3. Datakit 单台EC2无法达到高可用
4. Datakit内部配置无法可视化，对于开启的采集器类型无法使用文件进行配置管理
5. 无法快速定位到Datakit的问题
6. 存在单个EC2的网络限制（XLB用户访问量巨大（1.8W/U）），用户行为的采集在单台EC2遇到了网络瓶颈，迫使使用带宽更大的EC2服务器

在上诉问题的推动下，需要使用新的处理方案来应对面临的问题。

二、新方案

由于存在上述问题，需要选择新的方案，从可维护性、可扩展性，并且从费用的角度达到达到优化，并不影响原来的使用体验，用户侧可以无感知的进行升级等工作的进行。

1. 当前已知方案差异

序号	Datakit 部署方案	优点	缺点
1	EC2	①部署方式简单 ②使用方式简单 ③Datakit独享EC2资源	①由于是单台EC2无法高可用 ②Datakit配置无法可视化 ③EC2资源利用不充分 ④应用增多之后对EC2维护成本增加
2	ECS	①Datakit独享Fargate资源 ②部署方式简单 ③云厂商负责基础设施升级、全托管基础设施更安全 ④Datakit高可用	①Fargate资源利用不充分 ②Datakit应用配置无法可视 ③应用增多之后需要持续扩展ECS服务
3	K8S	①Datakit高可用 ②EC2资源利用充分 ③配置Yaml可视化、基础设施配置可视化 ④新接入应用简单、扩展方便 ⑤K8S负责每个Datakit服务之间的调度，维护简单	①对使用者有一定使用K8S成本 ②编写繁重YAML、初期发布效率更低 ③K8S全托管云供应商收取昂贵的基座维护费

Datakit部署方案选型

1. 第一种方案
   现进行中方案，凸显问题明显，资源浪费严重、维护困难，跟第二种方式比没有优势。
2. 第二种方案
   a. 资源利用充分并服务高可用，但是对基础设施的维护有一定难度，但是优势大于劣势，并且迁移成本低，可以考虑。
   b. K8S设计方案：按照不同环境创建节点组，每个节点组多副本Datakit，生产环境接入的应用运行在高可用节点组中。
3. 第三种方案
   与第一种方案相差不大，由第一种迁移到第三种迁移成本高。跟第二种方式比没有优势。

三、流程思路

1. 所需资源
   根据目前使用EC2部署Datakit的方式整理出来的服务器资源，现使用资源如下：

环境	实例类型	数量	说明
非生产环境	t3.large（2C8G）	7	包括现接入应用的Dev、ACC、Pre环境接入的应用数据，服务器CPU使用率维持在8%
生产环境	t3.large（2C8G） m6g.2xlarge（8C32G）	7 1	只包含应用的生产环境，CKFM由于网络带宽问题使用了10Gbps的网络型机器，服务器资源利用率基本为20%

由上可以看出Datakit的资源利用率出现严重浪费，但是由于Datakit应用的特殊性，无法在同一台服务器内安装多个服务，不同服务根据token上报到不同的观测云工作空间。

这种情况下只好将Datakit服务虚拟化，部署在K8S容器当中，部署类型为Deployment，这样下来在集群中可以部署多个不同空间的Datakit服务。并且观测云发行的Datakit服务本身对于K8S有很完善的兼容方案，这使得Datakit在K8S环境中可以完美运行，并且更好扩展和维护。

2. 新方案所需资源
   经过对资源的充分利用并考虑到后续维护性以及对费用的均衡，优化后的资源分布如下：

环境	实例类型	数量	说明
非生产环境	t3.large（2C8G）	3	非生产环境共用一个节点组，资源可以根据节点组镜像
生产环境	t3.large（2C8G）	4~7	由于应用在白天处于业务高峰期，消耗的资源会略多。还要考虑到CKFM在白天业务高峰期的时候对服务器带宽消耗特别大，故需要多台服务器进行带宽分流。

由以上资源的设计得出新的K8S对于Datakit的实际方案数据层：

3. K8S方案设计
   在指定LZ账号下创建Kubernetes集群，将集群初始化，包括但不限于以下配置：
   • Kubernetes IAM Role （集群和节点）
   • 集群安全组
   • 集群可视化访问界面（KubeSphere）
4. K8S 节点组分布

EKS Cluster	节点组	实例类型	数量
xlb-eks-datakit-cluster	dev-datakit-node-group	t3.large	3
prod-datakit-node-group	t3.large	4~7	dk-app:prod

- **非生产环境** 各节点所属应用分布情况（列出详细的服务数量）
- **生产环境** 各节点所属应用分布情况（列出详细的服务数量）

创建一个供应用使用的YAML需要使Datakit具备公共访问权限以及开启足够的采集器。

5. EKS配置

• Route53
• ALB(Ingress)
• Target Group
• Datakit采集器标识

综上所需的Datakit运行在K8S当中的配置文件如下，使用Kubectl apply -f datakit.yaml

至此完成所属方案的设计。

1. 针对后续可以看看是否在一个LB中通过资源路径对应Ingress中的服务
2. 云环境中费用问题