Excalidraw Kubernetes部署方案，高可用集群搭建指南

Excalidraw Kubernetes 高可用部署实践：构建稳定可扩展的协作白板平台

在远程办公成为常态的今天，团队对可视化协作工具的需求早已超越“能画图”的基础功能。无论是架构师绘制系统拓扑，还是产品经理梳理业务流程，一个响应迅速、永不掉线、支持多人实时互动的在线白板，已经成为技术协作链条中不可或缺的一环。

Excalidraw 正是在这一背景下脱颖而出的开源项目。它以极简的手绘风格降低了用户的表达心理门槛，同时通过开放的数据结构和插件机制，为深度定制提供了可能。但当我们将目光从个人使用转向企业级部署时，问题也随之而来：如何让这样一个前端主导的应用，在高并发、多区域、持续协作的场景下依然保持稳定？答案指向了现代云原生基础设施的核心——Kubernetes。

将 Excalidraw 部署在 Kubernetes 上，并非简单地把容器跑起来就完事。真正的挑战在于，如何利用 K8s 的控制能力，解决服务可用性、状态一致性与弹性伸缩三大难题。尤其对于依赖 WebSocket 进行实时同步的协作应用来说，任何一次 Pod 重启或节点故障都可能导致连接中断、数据不同步，甚至用户被迫重新加载页面。

为此，我们设计了一套完整的高可用部署方案，核心思路是：以声明式配置驱动自动化运维，用多副本+健康探针消除单点故障，通过智能扩缩容应对流量波动，并为未来集成 AI 功能预留扩展空间。

首先来看最基础也是最关键的组件——Deployment。为了让 Excalidraw 实例具备自我修复能力，我们必须定义至少三个副本，确保即使某个节点宕机，仍有实例可以继续提供服务。

apiVersion: apps/v1 kind: Deployment metadata: name: excalidraw-deployment labels: app: excalidraw spec: replicas: 3 selector: matchLabels: app: excalidraw template: metadata: labels: app: excalidraw spec: containers: - name: excalidraw image: excalidraw/excalidraw:latest ports: - containerPort: 80 resources: requests: memory: "128Mi" cpu: "100m" limits: memory: "256Mi" cpu: "200m" livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 5

这里有几个关键细节值得强调：

• livenessProbe负责判断容器是否“活着”。如果连续几次无法返回 200 状态码，Kubelet 会自动重启该 Pod。这对于防止内存泄漏导致的假死非常有效。
• readinessProbe决定 Pod 是否准备好接收流量。即便容器启动完成，也可能因静态资源未加载完毕而暂时不可用。设置合理的就绪检查，能避免新上线的实例立即被打满请求。
• CPU 和内存限制不仅是为了隔离资源，更是为了集群整体稳定性。如果不加限制，某个异常实例可能会耗尽节点资源，影响其他服务。

接下来是服务暴露层。我们不直接使用 NodePort 或 LoadBalancer，而是通过 Ingress 统一管理外部访问入口，实现路径路由、HTTPS 卸载和域名绑定。

apiVersion: v1 kind: Service metadata: name: excalidraw-service spec: selector: app: excalidraw ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: excalidraw-ingress annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true" cert-manager.io/cluster-issuer: "letsencrypt-prod" spec: 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

这套配置配合 cert-manager 可实现 SSL 证书的自动签发与续期，彻底告别手动更新证书的繁琐操作。更重要的是，Ingress 控制器本身也可以做高可用部署（如使用 DaemonSet + HostNetwork），进一步提升入口层的可靠性。

当然，静态部署只是第一步。真正体现 Kubernetes 弹性优势的是动态扩缩容能力。我们通过 Horizontal Pod Autoscaler（HPA）根据 CPU 使用率自动调整副本数量：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: excalidraw-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: excalidraw-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70

这意味着当团队集中开会、多人同时打开白板时，系统会自动扩容；会议结束后又会逐步缩容，节省计算成本。相比固定资源分配，这种方式资源利用率更高，也更符合现代云原生的成本优化理念。

不过需要提醒的是，HPA 对于 I/O 密集型或长连接类应用效果有限。Excalidraw 虽然是静态站点为主，但如果后端接入了 WebSocket 协作服务，则需额外考虑连接亲和性（session affinity）问题。此时建议启用 Service 的sessionAffinity: ClientIP，或将状态下沉至 Redis 等共享存储中，避免因负载漂移导致连接中断。

说到后端增强，这是许多企业在生产环境中必须面对的问题。默认的 Excalidraw 是纯前端应用，数据保存在浏览器本地。一旦清缓存或换设备，内容即丢失。为此，我们可以选择部署社区维护的excalidraw-room服务，或者自行开发基于 Node.js + Socket.IO 的协作后端。

这类服务同样应以 Deployment 形式运行，并通过 Headless Service 注册到集群内部 DNS，供前端 Pod 发现和连接。若涉及敏感数据，还应配置 NetworkPolicy 限制其仅能被特定命名空间内的前端 Pod 访问：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-excalidraw-to-backend spec: podSelector: matchLabels: app: excalidraw-backend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: excalidraw ports: - protocol: TCP port: 3000

此外，日志收集与监控也不容忽视。建议统一使用 Fluent Bit 或 Filebeat 将容器日志发送至 Elasticsearch，再通过 Kibana 进行查询分析。对于性能指标，则可通过 Prometheus 抓取 Nginx status 或自定义埋点，结合 Grafana 构建可观测性看板。

一个典型的运行架构如下所示：

[User Browser] ↓ HTTPS (Ingress) [Kubernetes Ingress Controller] ↓ [Service → Pod (Replica Set)] ├── Pod 1: Excalidraw Instance ├── Pod 2: Excalidraw Instance └── Pod 3: Excalidraw Instance ↓ [Optional Backend: WebSocket Server] ↓ [Shared Storage: Redis / PostgreSQL] [Logging & Monitoring Stack]

在这个体系中，每个层级都有明确职责：Ingress 处理安全与路由，Service 实现负载均衡，Deployment 保障可用性，而附加组件则支撑更复杂的功能演进。

值得一提的是，这种架构也为未来集成 AI 功能打下了坚实基础。比如，我们可以新增一个独立的 LLM Gateway 服务，接收来自前端的自然语言指令（如“画一个微服务架构图，包含用户网关、订单服务和数据库”），调用大模型生成初步草图 JSON，再推送给 Excalidraw 渲染展示。整个过程无需改动现有部署结构，只需增加一个新的 Deployment 和相应的 API 路由即可。

最后，关于 CI/CD 流程的设计也至关重要。推荐采用 GitOps 模式，将所有 YAML 配置纳入版本控制，通过 ArgoCD 或 Flux 自动同步集群状态。这样不仅能实现环境一致性，还能快速回滚到任意历史版本，极大提升发布安全性。

总结来看，Excalidraw 本身是一个轻量级工具，但其背后反映的是现代协作软件工程化的趋势。通过 Kubernetes 提供的自动化、弹性与可观测性能力，我们不仅能将其打造成一个稳定可靠的企业级服务，更能以此为基础，探索更多智能化协作的可能性。这种高度集成的设计思路，正引领着下一代协同工具向更高效、更智能的方向演进。