项目背景：公司现有的 Prometheus 集群，查询数据时经常超时，告警不及时。为此需要重新搞一套新的 Prometheus 集群解决以上问题。 项目介绍：经分析，以上问题的根源有两点：一是老的 Prometheus 并没有对数据量和 Prometheus 实例的处理能力做评估，超出了 Prometheus 实例的处理上线；二是老的 Prometheus 监控配置不合理，每次请求会有很多冗余数据。为此需要新的方案解决以上痛点。 期间我调研了多套方案，尽量满足数据持久性、服务高可用、水平可扩展、数据一致性等多个维度要求。 结合公司实际情况（公司对集群中非业务组件的资源使用情况比较敏感），最终采用了 Prometheus 集中式部署的方案：即单独部署一套 thanos + Prometheus多副本集群。另外开发一个 rebalancer 组件，监听配置中心下发的 Prometheus 配置，如果一旦有变化则重新均衡 Prometheus 实例之间的配置。 我的职责：我负责压测评估单个 Prometheus 实例的承载上限，并以此根据公司集群规模反推出 Prometheus 集群所需的机器数。另一方面优化 Prometheus 配置，比如过滤掉不必要的标签，增加预聚合规则提高查询相应速度。

项目背景：机密计算是一种解决数据运行时安全的解决方案，该方案严重依赖硬件厂商提供的平台和工具，对普通用户使用门槛极高。目前 Kubernets 几乎已经成为应用管理的最佳方案，越来越多的企业也开始投入 Kubernets。在此背景下开源项目 inclavare-containers 成立，其目的是能够在 Kubernets 运行机密计算容器，使应用在静止态、传输中、运行中都有全方位的安全保护。 项目介绍：该项目比较核心的组件有：shim + epm，rune，Occlume，其功能如下： 1. shim + epm：shim 主要用于容器生命周期的管理，比如创建、删除容器等；epm 则负责把用户的普通镜像转换成机密计算运行时所需要的加密镜像； 2. rune 是一个二进制程序，它接受来自 shim 的请求，最终通过 Occlume 来真正创建、执行或删除机密容器； 3. Occlum 是一款实现机密计算的运行时，业务最终会运行在 Occlume 创建出来的安全区内，避免业务运行时数据篡改或盗窃。 我的工作：我主要负责 shim + emp 模块，按照 containerd shimv2 要求新写了一个 shim，该 shim 实现了容器创建、删除等功能，在创建容器时利用 Occlume 与 emp 模块交互，实现普通镜像的签名和加密，最终生成运行机密计算容器的镜像。该模块最大的好处是将机密计算的复杂操作透明化，降低用户使用机密计算的门槛，从而有益于提高机密计算能力的普及。

项目背景：为了支持同一个应用多个实例能够跨 AZ 部署和故障容灾，需要将实例打散在 2 个或者更多的 AZ 中。默认情况下一个集群下所有机器同属于一个 AZ，为此需要提供一个联邦集群来实现多集群管理以及实例跨 AZ 分发和管理。 项目模块：项目分为 3 个部分：集群状态维护、workload 同步和分发、实例状态控制器。各个模块详细的功能如下： 1. 集群状态维护：向联邦集群注册 member 集群，member 集群向联邦集群同步集群状态，member 集群与联邦集群证书自动轮换，向联邦集群注销 member 集群； 2. 实例分发和同步：用户在联邦集群创建 workload 后，联邦集群会根据部署策略将一个 workload 拆分成多个 workload 并往不同 member 集群分发，member 集群监听到属于自己集群的 workload 请求后，开始创建、更新或者删除； 3. 实例状态控制器：该模块负责监听 workload 下实例的运行状态，并通过调度、重调度等方式最终将这些实例运行到终态。 我的工作：我主要负责“集群状态维护”的工作。该模块的主要目的是让联邦集群和 member 集群之间正常交互通信，联邦侧定期地监测和更新 member 集群运行状态，从而决定 workload 的调度或重调度策略。 该模块有两个组件：agent 和 controller，分别运行在 member 集群和联邦集群。agent 首次启动会将集群自身注册到联邦集群，之后 agent 会周期地向联邦集群上报集群心跳和集群状态。联邦集群的 controller 则检测 member 集群的心跳和状态信息，从而对 member 集群状态做进一步调整，进一步指导 workload 的调度和分发工作。