关注「索引目录」公众号，获取更多干货。
我们运行着 Logtide，这是一个功能齐全的可观测性平台，集成了日志管理、安全信息和事件管理 (SIEM)、实时流处理和分析功能，部署在 Docker Compose 上。我们每天处理 50 万条日志，服务数千用户，并保持着 99.8% 的正常运行时间。
我们的基础设施？一台服务器，一个docker-compose.yml文件，零 Kubernetes 复杂性。
这就是为什么大多数应用程序不需要 Kubernetes，以及我们是如何使用看似枯燥的技术大规模运行生产工作负载的。
Kubernetes税
每项技术都有其复杂性代价。每次部署、每次调试、每次新人上手，你都要付出代价。
对于 Kubernetes 来说，这笔开销非常巨大。
Kubernetes 的实际成本是多少
学习曲线：
-
经验丰富的工程师需要 2-3 个月才能熟练掌握。 -
了解 Pod、Service、Deployment、Ingress、ConfigMap、Secret 和持久卷 -
网络模型、服务网格、CNI插件 -
RBAC、安全上下文、Pod 安全策略
运营成本：
-
etcd 集群管理 -
控制平面更新 -
证书轮换 -
网络策略调试 -
存储类配置 -
监控堆栈（Prometheus、Grafana、Alertmanager）
基础设施成本：
-
高可用性至少需要 3 个控制平面节点。 -
工作节点（至少 2-3 个） -
负载均衡器 -
托管 Kubernetes 服务费用（计算费用另加每月 70-150 美元）
最近的一项案例研究表明，一个团队每月花费 60 小时用于维护一个包含 5 个服务的应用程序的 Kubernetes 系统。这相当于1.5 个月的工程师时间，仅仅是为了维持系统的正常运行。
行业现状
CNCF 2025 年数据显示：
-
80% 的 Kubernetes 用户来自员工人数超过 1000 人的公司。 -
79%的生产问题源于配置变更 -
大多数 Kubernetes 集群运行的服务少于 20 个。
翻译：Kubernetes 是一种企业级工具，却被初创公司盲目地奉为圭臬。
我们实际运行的动力是什么？
我们的整个技术栈：
version: '3.8'
services:
postgres:
image: timescale/timescaledb:latest-pg16
volumes:
- postgres_data:/var/lib/postgresql/data
environment:
POSTGRES_DB: logtide
POSTGRES_USER: logtide
POSTGRES_PASSWORD: ${DB_PASSWORD}
deploy:
resources:
limits:
memory: 4G
healthcheck:
test: ["CMD-SHELL", "pg_isready -U logtide"]
interval: 10s
timeout: 5s
retries: 5
backend:
image: logtide/backend:latest
depends_on:
postgres:
condition: service_healthy
environment:
DATABASE_URL: postgresql://logtide:${DB_PASSWORD}@postgres:5432/logtide
NODE_ENV: production
deploy:
replicas: 2
resources:
limits:
memory: 1G
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 30s
timeout: 10s
retries: 3
frontend:
image: logtide/frontend:latest
depends_on:
- backend
deploy:
resources:
limits:
memory: 512M
nginx:
image: nginx:alpine
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- ./certs:/etc/nginx/certs:ro
depends_on:
- frontend
- backend
volumes:
postgres_data:就这些。60行。团队里的每个人都看得懂。
我们的生产数据
服务器规格：
-
Hetzner CX33：4 个虚拟 CPU，8GB 内存 -
160GB NVMe 存储 -
费用：每月 12.50 欧元（约 14 美元）
交通：
-
每天摄入50万条日志 -
平均每秒约 6 个对数单位，峰值每秒 50 个对数单位 -
1000 多个并发 SSE 连接用于实时跟踪 -
15GB 压缩存储空间（TimescaleDB 压缩）
表现：
-
P50 日志摄取：45毫秒 -
P95 日志摄取：120毫秒 -
实时流媒体延迟：<50毫秒 -
搜索查询：50-200毫秒
可靠性：
-
三个月内正常运行时间达 99.8%。 -
零停机部署 -
部署时间：30 秒 -
恢复时间：2 分钟（重启所有服务）
成本比较：
-
我们的方案：每月 14 美元 -
同等托管的 Kubernetes 服务：每月 150-300 美元（EKS/GKE/AKS 基础服务 + 节点） - 每年
节省： 1,632-3,432 美元
我们实际使用的产品特性
零停机部署
#!/bin/bash
# deploy.sh
echo "Pulling latest images..."
docker compose pull
echo "Updating backend (rolling)..."
docker compose up -d --no-deps --scale backend=3 backend
sleep 10
docker compose up -d --no-deps --scale backend=2 backend
echo "Updating frontend..."
docker compose up -d --no-deps frontend
echo "Reloading nginx..."
docker compose exec nginx nginx -s reload
echo "Deploy complete!"无需 Kubernetes 滚动更新，无需副本集，只需 Docker Compose 和一个 10 行的 bash 脚本。
健康检查和自动重启
Docker Compose 可以处理这个问题：
healthcheck:
test: ["CMD-SHELL", "pg_isready"]
interval: 10s
retries: 5
restart: unless-stopped容器崩溃了？Docker 会重启它。健康检查失败了？Docker 会将其标记为不健康并停止路由流量。
资源限制
deploy:
resources:
limits:
memory: 4G
cpus: '2'
reservations:
memory: 2G无需设置K8s资源配额或限制范围。
秘密管理
# .env file (git-ignored)
DB_PASSWORD=xxx
JWT_SECRET=xxx
SMTP_PASSWORD=xxx结合正确的文件权限：
chmod 600 .env它是 HashiCorp Vault 吗？不是。它能用吗？能。
生产环境中，我们使用 CI/CD 系统注入的环境变量。对于真正敏感的数据（例如 TLS 证书），我们使用 LUKS 加密卷。
监测
我们在同一个 Docker Compose 堆栈中自行托管 Prometheus 和 Grafana：
prometheus:
image: prom/prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
grafana:
image: grafana/grafana
volumes:
- grafana_data:/var/lib/grafana
depends_on:
- prometheus总共新增 15 行代码。未使用 Kubernetes Operator。未使用 Helm Chart。
备份
#!/bin/bash
# backup.sh
docker compose exec -T postgres pg_dump -U logtide logtide | \
gzip > /backups/logtide-$(date +%Y%m%d).sql.gz
# Upload to S3
aws s3 cp /backups/logtide-$(date +%Y%m%d).sql.gz \
s3://logtide-backups/
# Keep last 30 days locally
find /backups -name "logtide-*.sql.gz" -mtime +30 -delete通过 cron 运行，完美运行。无需 Velero，也无需 Kubernetes 备份操作员。
我们何时真正需要 Kubernetes
我们对此毫不隐瞒。我们将在以下情况下迁移到 Kubernetes：
1. 多区域合作变得至关重要
Docker Compose 是单主机的。如果我们需要真正的多区域故障转移和自动流量路由，就需要使用 Kubernetes。
目前的权宜之计：在每个区域运行独立的 Docker Compose 堆栈，并启用 DNS 故障转移。目前有效。
2. 我们需要超过 10 台服务器
管理跨 10 台以上主机的 Docker Compose 非常繁琐。在这种规模下，Kubernetes 编排更胜一筹。
目前情况：我们只有一台服务器。在需要 Docker Swarm 或 K8s 之前，我们或许可以扩展到 3-5 台服务器。
3. 复杂的微服务网络
如果我们将服务拆分成 50 多个，并且每个服务都有复杂的服务网格要求，那么 K8s 就胜出。
当前架构：4 个服务。简单的 nginx 路由。无需 Istio 或 Linkerd。
4. 我们聘请了一支专门的平台团队
Kubernetes 需要专人负责。如果我们发展到能够负担得起 2-3 人平台工程团队的规模，那么 Kubernetes 就很有意义了。
目前团队只有2名工程师。我们负担不起Kubernetes的维护费用。
真正的问题
采用 Kubernetes 之前，请先问自己：
我们是否面临 Kubernetes 能够解决的问题？
-
运行100多项服务？（否） -
需要跨数据中心编排吗？（不需要） -
公司有5名以上的平台工程师吗？（没有） -
需要复杂的流量拆分吗？（不需要） -
每月在基础设施上花费超过 5 万美元？（否）
如果你对以上大多数问题的回答是“否”，那么你不需要 Kubernetes。
真正重要的是什么
良好的基础设施具备三个特点：
1. 它消失了
你部署代码，它就能运行。你不需要每天都考虑基础设施的问题。
有了 Kubernetes，基础设施成了我们的全职工作。有了 Docker Compose，我们git push就能继续前进。
2. 人人都明白。
凌晨两点设备坏了，团队里有人能修好吗？
使用 Docker Compose：是的。它只是容器和 bash 脚本。
使用 Kubernetes 的话：不行。你需要一个“Kubernetes 专家”。
3. 它与你的比例尺成正比。
基础设施的复杂程度应该与你的实际规模相匹配，而不是与你设想的未来规模相匹配。
我们用一台服务器服务成千上万的用户，为什么要为数百万用户设计服务器架构呢？
我们实际的扩展路径
今天（每天 50 万条日志）：
-
1 台服务器 -
Docker Compose -
每月14美元
每天 500 万条日志：
-
3 台服务器（1 台主服务器，2 台只读副本服务器） -
仍然是 Docker Compose -
手动故障转移 -
每月 50 美元
每天记录 5000 万条日志：
-
10台以上服务器 - 可以考虑使用
Kubernetes 或 Docker Swarm。 -
需要妥善安排 -
每月 500 美元以上
关键见解：我们距离真正需要 Kubernetes 还差三个数量级。
我们实际构建的技术栈
后端： Fastify（Node.js）- 2 个副本
前端： SvelteKit 5 - 静态文件由 nginx 提供服务
数据库： PostgreSQL，带有 TimescaleDB 扩展
实时： PostgreSQL LISTEN/NOTIFY + 服务器发送事件
搜索： PostgreSQL 全文搜索 + GIN 索引
缓存： PostgreSQL 非日志表（可选 Redis）
队列： PostgreSQL，已启用 SKIP 锁定
发布/订阅： PostgreSQL 监听/通知
分析： TimescaleDB 连续聚合
看出规律了吗？PostgreSQL 几乎包办一切。
一个数据库，一个连接字符串，零微服务复杂性。
为什么这种方法有效
1. Postgres 功能非常强大
借助扩展（TimescaleDB、pg_cron、pgvector），Postgres 可以处理：
-
时间序列数据（TimescaleDB） -
全文检索 -
JSON 文档 -
作业队列 -
发布/订阅 -
地理空间数据（PostGIS）
2. 枯燥的技术是可靠的
Docker Compose 自 2014 年就已存在，它成熟稳定，文档也十分出色。
Kubernetes 每三个月更新一次。你的部署清单会失效。你的 Helm Chart 需要更新。
3. 简单的系统是可以调试的。
日志不显示时：
-
检查 Docker Compose 日志： docker compose logs -f backend -
检查数据库 psql并运行查询 -
检查 nginx： docker compose exec nginx cat /var/log/nginx/error.log
无需进行 kubectl 上下文切换。无需进行 pod 网络调试。无需解决 CNI 插件问题。
4. 限制激发创造力
由于必须将所有内容都放在一台服务器上，我们不得不这样做：
-
使用 TimescaleDB 压缩（节省 90% 的空间） -
正确优化查询 -
使用Postgres构建高效的实时功能 -
真正了解我们的性能特征
如果 Kubernetes 资源无限，我们就会用硬件来解决问题，而不是解决问题。
我们学到了什么
企业最佳实践往往并不适用于你。
谷歌之所以运行 Kubernetes，是因为他们拥有 5 万名工程师和数百万个容器。
你不是谷歌。
简洁是一种特点
最好的基础设施就是你无需操心的基础设施。
过早优化也延伸到了基础设施领域。
不要在只有 100 个用户的情况下，按照 1000 万用户的标准来开发。
平庸的选择往往才是正确的。
Docker Compose很无聊。PostgreSQL很无聊。nginx很无聊。
无聊意味着：成熟、稳定、有据可查、广为人知。
技术债务是真实存在的。
你增加的每一项基础设施都会产生债务。你将通过以下方式永远支付利息：
-
维护 -
升级 -
监测 -
文档 -
培训新团队成员
谨慎选择。
从简单的开始
如果您正在构建一个新应用程序：
第一天：单台服务器上使用 Docker Compose，
100 个用户：仍然使用 Docker Compose；
1000 个用户：仍然使用 Docker Compose，可能需要添加监控；
10000 个用户：添加只读副本，仍然使用 Docker Compose；
100000 个用户：现在考虑采用合适的编排方式。
大多数公司用户数量永远达不到10万。不要过早地为永远无法达到的规模进行优化。
我们的建议
如果符合以下情况，请使用 Docker Compose：
-
您拥有的服务少于 20 项 -
您可以在少于 5 台服务器上运行 -
团队规模：工程师少于10人 -
你更看重简洁而非功能。 -
您没有管理多区域部署。
如果符合以下情况，请考虑使用 Kubernetes：
-
您拥有超过 50 项服务 -
你需要超过 10 台服务器 -
你们有专门的平台工程师。 -
复杂的网络需求 -
多区域合作至关重要 -
企业合规性要求它
对于其他人来说：Docker Compose 就足够了。
自己动手试试
Logtide 完全基于 Docker Compose 运行。我们是开源软件（AGPLv3）。
2分钟即可开始：
git clone https://github.com/logtide-dev/logtide
cd logtide
cp .env.example .env
docker compose up -d无需 Kubernetes，无需复杂技术，只需运行软件即可。
生产就绪的日志管理、SIEM 和可观测性，适用于枯燥的技术。
每天 50 万条日志。一台服务器。零 Kubernetes 配置。
有时候，最好的解决方案往往是最简单的。
关注「索引目录」公众号，获取更多干货。