Kubernetes 集群应用日志采集最佳实践

Sun, 19 Apr 2026 20:00:00 +0800

1. Kubernetes 集群下应用日志采集面临的挑战

在传统的虚拟机或物理机环境中，应用日志通常以文件形式持久化在固定路径，日志采集 Agent 只需读取这些文件即可。但在 Kubernetes 环境下，日志管理面临一系列独特挑战。

1.1 容器的临时性

Pod 是 Kubernetes 中最小的调度单元，其生命周期具有高度不确定性：

弹性伸缩：HPA 根据负载自动扩缩 Pod，Pod 随时可能被创建或销毁
滚动更新：Deployment 更新时，旧版本 Pod 被逐个替换，历史日志随之消失
节点故障：节点宕机时，Pod 被驱逐并在其他节点重建，原节点日志无法访问
资源回收：节点磁盘压力触发 Eviction，Pod 被强制终止

若日志仅保存在容器内部，Pod 销毁意味着日志永久丢失，这对问题排查和合规审计都是不可接受的。

1.2 日志的分散性

一个中等规模的 K8s 集群可能有数百个节点、数千个 Pod，应用日志分散在每个节点的容器存储中：

日志物理位置随 Pod 调度动态变化，无法预知
跨节点查看日志需要逐台机器登录，效率极低
分布式调用链的日志需要跨节点聚合，才能完整还原请求路径

1.3 多租户隔离需求

企业级 K8s 平台通常服务多个业务团队，因此需要：

按 Namespace / Service 隔离不同团队的日志
支持细粒度的日志访问权限控制
按团队分摊和管控日志存储成本

1.4 传统方案的局限

传统方案	核心问题	K8s 场景下的不足
SSH 登录节点查看	无法集中检索，效率低	Pod 频繁漂移，难以定位日志位置
写入共享存储（NFS/EBS）	需要应用改造，引入依赖	增加应用复杂度，不适合无状态服务
应用直推日志中心	与业务代码耦合	多语言/框架依赖重，难以统一运维

因此，需要一种与业务解耦、集中化、可扩展的日志采集方案。

基于 Terraform 构建企业内部 kubernetes 集群

Sun, 19 Apr 2026 10:00:00 +0800

1. 为什么要构建企业内部 Kubernetes 集群？

随着企业业务规模的不断扩张，微服务架构逐渐成为主流，应用的数量、版本迭代的频率以及部署的复杂度都在急剧上升。在这一背景下，建立一套稳定、高效、可扩展的企业内部 Kubernetes 集群，成为支撑企业数字化转型的核心基础设施之一。

1.1 构建统一的资源调度平台

企业内部往往同时运行着多条业务线、多个团队的应用服务。Kubernetes 提供了统一的容器编排与资源调度能力，能够将计算、存储、网络资源进行统一抽象和调度，避免各团队烟囱式的资源使用模式，显著提升整体资源利用率。

1.2 支撑 CI/CD 流水线落地

Kubernetes 是现代 CI/CD 流水线的天然载体。通过与 GitLab CI、Jenkins、ArgoCD、Tekton 等工具集成，企业可以实现：

持续集成（CI）：代码提交后自动触发构建、测试，产出镜像并推送到私有镜像仓库。
持续交付（CD）：基于 GitOps 理念，通过声明式配置驱动应用在集群中的自动发布与回滚。
多环境隔离：通过 Namespace、NetworkPolicy、RBAC 等机制，在同一集群内划分开发、测试、预发、生产等多套环境，降低环境管理成本。

1.3 提升业务稳定性与弹性

Kubernetes 内置的自愈能力（Pod 自动重启、节点故障迁移）、水平自动伸缩（HPA/VPA/KEDA）以及滚动更新策略，能够大幅提升业务服务的可用性和弹性，满足企业对 SLA 的严格要求。

1.4 降低运维复杂度

统一的控制平面使运维团队可以通过标准化的 kubectl 命令或声明式 YAML 配置管理所有工作负载，结合 Helm Chart 进行应用打包与版本管理，有效降低了跨团队、跨项目的运维协作成本。

2. 构建内部 K8s 集群核心流程

2.1 整体流程概览

基础资源准备 → 操作系统初始化 → 集群安装部署 → 网络插件配置 → 存储插件配置 → 集群验证 → 监控告警部署

2.2 基础资源准备

构建 K8s 集群首先需要准备充足的计算、存储和网络资源。

计算资源方案对比：

Kubernetes on Zhengdong.jzd 个人博客