Excalidraw Kubernetes 部署实践：构建高可用协作白板系统
在现代技术团队中，一张“纸”可能比代码还重要——尤其是当这张纸是能跨时区实时协作、支持版本回溯、还能对接 AI 生成草图的虚拟白板时。Excalidraw 正是这样一款工具，它以极简的手绘风格和零学习成本，迅速成为架构设计、产品原型与远程脑暴的首选画布。
但再好的工具，如果只能跑在本地 Docker 容器里，一旦主机宕机就全盘归零，显然无法满足企业级协作的需求。真正的生产力工具，必须具备高可用、可扩展、易维护的特性。而这正是 Kubernetes 的用武之地。
将 Excalidraw 部署到 K8s 上，不只是把容器从单机搬到集群那么简单。我们需要思考：如何让多个实例共享状态？如何确保用户访问的是同一个稳定的入口？崩溃后能否自动恢复？资源是否合理分配？安全又该如何保障？
下面我们就通过一个生产可用的 YAML 模板，一步步拆解这套系统的构建逻辑。
从一个 Deployment 开始
最核心的部分当然是应用本身的部署。我们使用Deployment来管理 Excalidraw 的 Pod 副本，确保即使某个节点出问题，服务依然可用。
apiVersion: apps/v1 kind: Deployment metadata: name: excalidraw labels: app: excalidraw spec: replicas: 2 selector: matchLabels: app: excalidraw template: metadata: labels: app: excalidraw spec: containers: - name: excalidraw image: excalidraw/excalidraw:v1.8.0 ports: - containerPort: 80 env: - name: ALLOW_SAVE_URL value: "true" - name: FIREBASE_DATABASE_URL valueFrom: secretKeyRef: name: excalidraw-secrets key: firebase-db-url resources: requests: memory: "128Mi" cpu: "100m" limits: memory: "256Mi" cpu: "200m"几点关键优化值得特别说明：
- 固定镜像版本：不再使用
:latest，而是明确指定v1.8.0，避免因镜像突变导致环境不一致； - 敏感信息外置化：
FIREBASE_DATABASE_URL这类密钥不应硬编码在配置中，而是通过Secret引用，实现配置与凭证分离； - 资源请求与限制：为容器设置合理的 CPU 和内存上下限，既防止资源争抢，也便于调度器做决策。
你可能会问：“Excalidraw 不是前端静态页面吗？为什么还要关心后端同步？”没错，它的前端确实是纯静态的，但多人协作依赖外部状态同步机制。如果你没配好 Firebase 或自建 room server，那所谓的“协同编辑”其实只是各自为政的幻觉。
网络暴露：Service + Ingress 双剑合璧
光有 Pod 还不够，Kubernetes 内部的服务发现和外部访问需要两层抽象：Service和Ingress。
--- apiVersion: v1 kind: Service metadata: name: excalidraw-service spec: selector: app: excalidraw ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP这个ClusterIP类型的服务会在集群内部提供一个稳定的虚拟 IP，所有 Pod 都注册在这个服务下，实现负载均衡。虽然你看不到它对外暴露，但它却是 Ingress 路由的基础。
接下来是真正让用户能访问到服务的关键组件：
--- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: excalidraw-ingress annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true" nginx.ingress.kubernetes.io/backend-protocol: "HTTP" spec: ingressClassName: nginx tls: - hosts: - excalidraw.example.com secretName: excalidraw-tls-secret rules: - host: excalidraw.example.com http: paths: - path: / pathType: Prefix backend: service: name: excalidraw-service port: number: 80这里有几个细节值得注意：
- 使用了 TLS 加密，证书通过名为
excalidraw-tls-secret的 Secret 管理； - 注解中启用了 HTTPS 重定向，强制所有 HTTP 请求跳转至安全连接；
- 后端协议显式声明为 HTTP，避免 Nginx Ingress Controller 默认尝试 HTTPS 回源造成错误。
这样一来，用户只需访问https://excalidraw.example.com，就能获得加密、稳定且负载均衡的服务体验。
生产级考量：不只是跑起来
如何应对流量高峰？
默认两个副本适合小团队使用。但如果某天全员突然开始画架构图（比如发布前评审），CPU 占用飙升怎么办？
答案是 Horizontal Pod Autoscaler（HPA）：
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: excalidraw-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: excalidraw minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70当平均 CPU 利用率超过 70%，系统会自动扩容；空闲时则缩容，节省资源。这才是云原生应有的弹性思维。
日志与监控不能少
没有监控的系统就像盲人开车。建议至少接入以下可观测性组件：
- Prometheus + Grafana：采集容器的 CPU、内存、网络等指标，设置告警阈值；
- Loki / Fluentd + Elasticsearch：集中收集容器日志，方便排查协作异常或加载失败问题；
- 健康探针：添加 liveness 和 readiness 探针，避免将请求转发给尚未启动完成的 Pod。
例如，在容器配置中加入：
livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5这些看似琐碎的配置，实则是保障 SLA 的基石。
数据持久化的取舍
Excalidraw 默认数据保存在浏览器本地存储，关掉页面就没了。这对临时草图没问题，但如果是会议纪要级别的白板，显然需要持久化。
解决方案有两种：
- 启用 Firebase 同步：官方推荐方式，适合快速上线；
- 自建 excalidraw-room 服务：配合 Redis 或 MongoDB 存储房间状态，完全掌控数据生命周期。
后者更适合企业私有化部署。你可以将其作为一个独立的微服务运行在同一个集群内，并通过 Service 内网通信。
env: - name: ROOMS_SERVER_URL value: "http://excalidraw-room-service:3000"此时整个架构变成：
[Browser] ↓ [Ingress → Service → Excalidraw Frontend Pod] ↓ (WebSocket) [excalidraw-room Backend] ↓ [Redis/MongoDB for state]这种前后端分离模式更灵活，也为后续功能扩展留足空间——比如接入审计日志、权限控制、甚至 AI 自动生成图表。
安全加固不容忽视
即使是内部工具，也不能放松安全要求。几个关键点：
- 所有敏感配置（Firebase 密钥、数据库连接串）必须使用
Secret，禁止明文写入 YAML； - 配置
NetworkPolicy限制 Pod 之间的访问，比如只允许 frontend 访问 room server 的特定端口； - 启用 RBAC，限制非管理员对 Deployment 的修改权限；
- 定期扫描镜像漏洞，可通过 Trivy 或 Clair 集成 CI 流程。
一个小技巧：可以把所有配置抽离成 Helm Chart，通过values.yaml参数化不同环境（dev/staging/prod），实现一键部署与合规检查。
工程价值远超“画图”
也许你会觉得，“不就是个画画的吗？”但当我们把它放在 Kubernetes 上重新审视，会发现这背后是一整套现代化应用交付范式：
- 声明式运维：YAML 即基础设施，可版本控制、Code Review、回滚；
- GitOps 实践：结合 ArgoCD 或 Flux，做到配置变更即自动同步；
- 多环境一致性：开发、测试、生产环境差异最小化；
- 故障自愈能力：Pod 崩溃自动重启，节点宕机自动迁移；
- 弹性伸缩：根据负载动态调整资源，无需人工干预。
更重要的是，这种部署模式为未来集成更多智能能力打下基础。想象一下：
- 用户输入“帮我画一个微服务架构图”，AI 自动生成初步布局并导入 Excalidraw；
- 白板内容自动解析为 PlantUML 或 Mermaid 代码，嵌入 Confluence 文档；
- 每次修改都有时间轴记录，支持“回放”整个设计演进过程。
这些都不是科幻，而是建立在稳定、可扩展基础设施之上的自然延伸。
结语
Excalidraw 看似简单，但它所代表的是一种新型工作流：轻量、开放、可编程。而 Kubernetes 则赋予它企业级的生命力。
这套部署模板的意义，不仅在于让你快速拥有一个高可用的协作白板，更在于展示了一个典型静态 Web 应用如何走向生产就绪的过程——从镜像管理、资源配置、网络策略到安全与监控，每一步都是现代 DevOps 的标准动作。
下次当你准备“随便起个容器试试”的时候，不妨多想一步：如果明天就要给全公司用，你现在做的设计扛得住吗？
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
