作者：久氢、丛霄、章进
背景
SAE（Serverless 应用引擎）是一个全托管、免运维、高弹性的通用 PaaS 平台，实现了微服务应用、定时任务的 Serverless 化。产品初衷是将底层 Kubernetes 复杂度予以屏蔽，降低用户理解成本和使用门槛。用户并不感知底层 Infra，只需聚焦于核心的业务逻辑开发，而应用生命周期管理，微服务管理，日志，监控等功能交由 SAE 完成。
SAE 的极简易用、自适应弹性等特性吸引了越来越多的用户。然而，随着用户对应用可观测性和运维能力的需求不断提升，许多客户提出了更高层次的需求：如何在不修改主应用代码的情况下，灵活扩展日志采集、监控指标收集等功能？为了满足这些需求，SAE 推出了全新的自定义日志与监控解决方案，通过引入 Sidecar 容器的技术，为用户提供更强大的运维能力。
用户需求驱动：场景痛点分析
在日常答疑和工单反馈中，我们发现许多用户明确表达了对以下场景的强诉求：
日志自由采集
许多用户希望通过某种方式，将主应用容器的日志实时采集并发送到自建日志系统（如 Elasticsearch 或 Loki），以实现日志的集中管理和分析。例如：使用 Filebeat 将日志数据采集发送到 Kafka 或其他日志存储平台。监控自定义指标收集
用户希望在不修改主应用代码的情况下，轻松采集主应用容器自定义性能指标和监控数据，并将其发送到监控平台（如 Prometheus ）。资源隔离强诉求
部分用户在单个容器里运行多个进程，进程间的资源抢占问题引发服务受损。用户迫切需要一种机制来隔离不同进程的资源使用，确保核心业务不受干扰。
方案落地
为了让用户能够灵活扩展应用的功能，SAE 引入了 Sidecar 容器技术。允许用户在应用中添加一个或多个 Sidecar 容器，用于实现自定义日志采集、监控指标收集等功能。
在实现这一解决方案的过程中，我们也面临了一些挑战，并针对这些挑战提出了相应的应对策略。
应用多容器资源划分
在 Kubernetes 中，每个容器都可以设置资源请求（request）和资源限制（limit）。当没有 Sidecar 容器的时候主应用容器独享整个 Pod 资源，但在引入 Sidecar 容器后，如何合理划分资源成为一个关键问题。
我们为用户提供两种 Sidecar 资源划分模式，以满足不同场景的需求：
模式一：共享资源模式
a. 配置方式：Sidecar 容器 request=0 && limit >0
b. 特点：Sidecar 容器和主应用容器共享 Pod 的资源，但设置了 Sidecar 容器最大资源使用上限( limit>0 )，以防止 Sidecar 容器和业务主容器过度争抢资源，
c. 适用场景：适用于资源敏感型用户，希望最大化利用资源的场景。
模式二：独立资源模式
a.配置方式：Sidecar 容器 request=limit
b. 特点：Sidecar 容器独立占用指定的资源，不会与应用主容器发生资源争抢。例如，如果用户指定应用实例规格为 1c2g，而 Sidecar 容器的资源设置为 0.5c0.5g，则应用主容器可用资源为 0.5c1.5g。
c. 适用场景：适用于对资源隔离要求较高的场景，确保 Sidecar 容器不会影响主应用容器的性能。
通过这两种模式，我们既满足了用户对资源灵活性的需求，也提供了足够的资源隔离保障。
应用运维复杂度降低
Sidecar 模式虽好，但它也增加了运维复杂度。为了让 Sidecar 容器既“好用”又“好管”，SAE 提供了一系列全链路的运维能力，覆盖 Sidecar 容器的生命周期管理。
Sidecar 容器运行状态
用户可以在控制台上清晰地查看 Sidecar 容器的状态变化，包括 Pending、Running、CrashLoopBackOff 等，方便实时观察 Sidecar 容器的健康状况。
Sidecar 容器日志
通过控制台，用户可以轻松查看 Sidecar 容器的日志，快速定位和排查问题。
Sidecar 容器 Webshell
用户可以通过控制台的 Webshell 功能直接登录到 Sidecar 容器，查看容器内的目录文件或执行命令，进一步提升问题排查效率。
Sidecar 容器监控
SAE 提供了 Sidecar 容器的 CPU 和内存监控指标，帮助用户更好地跟踪其资源消耗情况。（该功能目前处于灰度阶段）
Sidecar 事件通知
对于对 Sidecar 容器重启事件敏感的用户，SAE 提供了事件订阅功能。用户可以在事件中心里订阅应用重启事件，并通过通知机制及时响应。
Sidecar 容器重启
SAE 实现了实例级别的容器重启能力，用户可以单独重启 Sidecar 容器，而无需重启整个 Pod。（该功能目前处于灰度阶段）
saectl 工具运维
为了进一步提升运维效率，SAE 提供了 saectl 工具，允许用户与底层 Kubernetes 集群进行通信，实现对 Sidecar 容器的资源管理。对于熟悉 kubectl 的用户，推荐使用 saectl 工具来简化操作。
应用稳定性保障
Sidecar 容器作为主应用容器的辅助容器，虽然扩展了功能，但也带来了潜在的风险。为了确保整个应用的稳定性，我们采取了以下措施：
1.隔离性保障
Sidecar 容器的运行状态失败不会影响主应用容器继续承接流量，确保核心业务不受干扰。
2.自动恢复机制
当 Sidecar 容器出现异常时，SAE 会自动尝试重启容器，确保其尽快恢复正常运行。
3.资源限制
通过设置 Sidecar 资源上限，避免 Sidecar 容器因资源争抢导致主应用容器性能下降。
案例：使用 SAE 优雅实现自定义日志采集
以下是一个典型的实战案例，展示用户如何通过 SAE 实现自定义日志采集功能。
场景描述
某些用户希望将 SAE 应用日志实时采集并发送到自建日志系统，以统一的方式进行日志分析和处理，用户自定义日志采集方案架构图如下所示：
操作实践
Sidecar 日志收集的核心原理是通过共享挂载卷实现应用主容器与 Sidecar 容器之间的日志传递。通过将应用主容器的日志路径挂出，用 Sidecar 容器访问路径下的日志来实现日志收集。实践这里只演示架构图中使用 Filebeat 采集日志数据输出到 Kafka 这一流程。
步骤1：创建 SAE 应用并添加 Sidecar 容器
在 SAE 控制台创建应用的时候，在「添加 Sidecar 容器」TAB 页可以点击添加 Sidecar 容器。
Sidecar 容器基础配置参数如下：
自定义容器名称
为 Sidecar 容器指定一个易于识别的名称，如 filebeat。选择容器镜像
使用公网 filebeat 镜像，例如：swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/elastic/filebeat:8.15.3设置 Sidecar 容器资源上限
Sidecar 容器与主应用容器共享 CPU 和内存资源。为了确保主应用容器的正常运行，请合理设置Sidecar 容器的最大资源使用上限。
Sidecar 容器高级设置如下：
设置启动命令
在启动命令区域为 Sidecar 容器设置启动命令：./filebeat -e -c filebeat.kafka.yml挂载 Sidecar 配置文件
在配置管理区域通过 ConfigMap 将 Sidecar 容器的配置文件挂载到容器的 /usr/share/filebeat/filebeat.kafka.yml 路径。以下是一个典型的 filebeat 采集日志到 Kafka 的配置文件内容示例：
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/*.log
output.kafka:
hosts: ["kafka1:9092", "kafka2:9092", "kafka3:9092"]
topic: "topic"
partition.round_robin:
reachable_only: true
required_acks: 1
compression: gzip
max_message_bytes: 1000000
｜注意：请根据实际需求调整日志路径、Kafka 地址和 topic 名称。
- 配置共享存储卷
在共享临时存储区域，通过设置 emptyDir 并将其挂载到主应用容器和 Sidecar 容器中，实现日志的共享。例如将挂载路径设置为 /var/log ,来收集该路径下的应用日志。
步骤2：验证日志采集到 Kafka
登录 Kafka 实例控制台，可以看到 Sidecar 容器 filebeat 将主应用容器 /var/log 下的日志数据成功采集到 Kafka 指定的 Topic 中。
未来展望
通过引入 Sidecar 容器的技术，SAE 为用户提供了更强大的自定义日志与监控解决方案，帮助用户轻松实现日志采集、监控指标收集等功能。未来，SAE 将会支持 istio 多租场景，帮助用户更高效地部署和管理服务网格。
最后，欢迎大家来使用 SAE，一款零代码改造、极简易用、自适应弹性的容器化应用全托管平台：“我们希望让用户做的更少而收获更多，通过 Serverless 化，深度用云就像用水电煤一样简单” 。
