跳到主要内容

Kubernetes 上部署 Langflow 的最佳实践

本指南提供了在 Kubernetes 生产环境中部署 Langflow 的最佳实践。

资源和扩展​

Langflow 的最低资源需求因部署类型而异：

  • IDE (开发): 同时部署 Langflow 可视化编辑器（前端）和 API（后端）。通常用于开发环境，开发人员使用可视化编辑器创建和管理流程，然后打包并通过生产运行时部署提供服务。

    前端服务每个实例需要至少 512Mi RAM 和 0.3 CPU，配置 1 个副本。

    后端服务每个实例需要至少 1Gi RAM 和 0.5 CPU，配置 1 个副本。

  • Runtime (生产): 部署用于生产流程的 Langflow 运行时，这是一个无头（仅后端）服务，专注于提供 Langflow API。这用于生产环境，其中流程以编程方式执行，无需可视化编辑器。

    最低要求包括每个实例 2Gi RAM 和 1000m（1 CPU），配置 3 个副本。

有关 Langflow 部署类型的更多信息，请参阅 Kubernetes 上的 Langflow 架构。

估算、测试和调整​

从最低推荐资源和副本开始，然后根据部署需求和性能测试结果进行监控和扩展。 在资源估算和性能测试中考虑以下因素：

  • 流程复杂度。

  • 并发用户和请求数量。

    对于 IDE（开发）部署，请考虑前端活动也会 ping 后端服务，因此通常需要同时扩展前端和后端。

  • 请求负载内容和大小，特别是生产部署中的文件上传。

  • 缓存、文件管理和 Langflow 数据库的存储需求。

    建议在生产部署中使用 外部 PostgreSQL 数据库。

  • 可能需要更多资源的选项，例如多核 CPU。

使用外部 PostgreSQL 数据库​

建议在生产部署中使用外部 PostgreSQL 数据库，以提高可扩展性和可靠性，相比默认的 SQLite 数据库。

您的资源分配和Replicate策略必须能够支持 PostgreSQL 服务和存储。 例如，对于运行时（生产）部署，您可能需要分配 4Gi RAM、2 CPU 和多个副本以实现高可用性。 根据资源需求和性能指标调整 PostgreSQL 参数，如 work_mem 和 shared_buffers。

推荐的配置包括：

  • 持久存储以防止容器关闭时数据丢失
  • 高可用性（HA）或主动-主动模式，用于自动故障转移、扩展和负载均衡
  • 多实例部署的共享数据库
  • 多实例部署的共享存储，如 NFS 或云存储，用于访问存储在磁盘上的大文件，例如 /opt/langflow/data/ 中的文件。

有关更多信息，请参阅 配置外部 PostgreSQL 数据库 和 面向企业 DBA 的 Langflow 数据库指南。

使用 HPA 进行动态扩展​

建议在运行时（生产）部署中使用负载均衡和动态扩展。

例如，考虑在 Kubernetes 中使用水平 Pod 自动扩展器（HPA）根据 CPU 或内存使用情况进行动态扩展。 以下示例展示了基于 CPU 扩展的 Langflow HPA 配置：


_18
apiVersion: autoscaling/v2
_18
kind: HorizontalPodAutoscaler
_18
metadata:
_18
name: langflow-runtime-hpa
_18
spec:
_18
scaleTargetRef:
_18
apiVersion: apps/v1
_18
kind: Deployment
_18
name: langflow-runtime
_18
minReplicas: 1
_18
maxReplicas: 10
_18
metrics:
_18
- type: Resource
_18
resource:
_18
name: cpu
_18
target:
_18
type: Utilization
_18
averageUtilization: 80

故障点​

Langflow 在生产环境中的可靠性取决于缓解关键故障点，特别是围绕数据库、文件系统和实例可用性：

  • 数据库故障: 请参阅 面向企业 DBA 的 Langflow 数据库指南。
  • 文件系统故障: 文件缓存中的并发问题，如 /app/data/.cache，可能导致多实例设置中的 IO 错误。 为避免此问题，请使用共享的、POSIX 兼容的文件系统或云存储。 使用持久卷而不是 ramdisk 解决方案，后者会导致容器关闭时数据丢失。
  • 实例故障: 部署多个副本，以在单个实例故障时避免服务中断。使用健康检查来检测和替换失败的 Pod。
  • 网络和依赖故障: 流程中使用的外部 API 或服务可能会失败，导致流程错误。在流程或应用程序代码中实现重试逻辑和错误处理。监控网络延迟和依赖健康状况。

监控​

有效的监控确保Langflow在不同负载下能够可靠运行并保持良好性能：

  • 数据库监控：请参阅面向企业DBA的Langflow数据库指南。
  • 应用程序日志：收集并分析日志中的错误、警告和流程执行问题。使用ELK Stack或Fluentd等工具集中管理日志。您还可以检查Langflow日志。
  • 资源使用情况：跟踪Langflow实例的CPU、内存和磁盘使用情况。在Kubernetes中使用Prometheus和Grafana进行实时指标收集和监控。
  • API性能：监控响应时间、错误率和请求吞吐量。为高延迟或错误峰值设置警报。
  • 可观测性工具：与LangWatch或Opik集成，以实现详细的流程跟踪和指标监控。使用这些工具调试流程性能并优化执行。

安全性​

在生产环境中运行Langflow需要强大的安全措施来保护应用程序、数据和用户。 请遵循行业最佳实践，并使用安全的Langflow配置，例如以下措施：

  • 容器安全性：为容器化应用应用安全最佳实践。例如，在生产容器中设置readOnlyRootFilesystem: true以防止未经授权的修改。限制对包含敏感数据和不应向未经授权用户公开的配置文件的文件和代码库的访问。
  • 密钥管理：将API密钥和PostgreSQL凭据等敏感数据存储在Kubernetes机密或外部机密管理器（如HashiCorp Vault）中。
  • 身份验证、授权和访问控制：按照API密钥和身份验证中的说明，在启用身份验证的情况下启动Langflow服务器。使用防火墙、网络策略、网络安全组或VPC限制网络和资源访问。例如，限制PostgreSQL数据库仅允许Langflow实例访问。
  • 加密和隐私：遵循行业最佳实践和法律要求，对传输中和静态数据进行隐私保护和加密，包括GDPR要求、HTTPS、TLS和SSL。例如，使用有效的SSL证书配置PostgreSQL，并在连接字符串中添加?sslmode=require或?sslmode=verify-full以启用数据库连接的SSL。
  • 安全态势维护：定期进行安全审计，及时更新软件，并使用入侵检测系统监控可疑活动。

另请参阅​

Search