跳到主要内容

Kubernetes 上 Langflow 的最佳实践

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

资源与扩缩容​

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

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

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

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

  • 运行时 (生产)：部署用于生产工作流的 Langflow 运行时，这是一种专注于提供 Langflow API 的无头 (headless) 服务（仅后端）。用于以编程方式执行工作流而不需要可视化编辑器的生产环境。

    最低要求包括每实例 2Gi RAM 和 1000m (1 CPU)，建议 3 个副本。

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

评估、测试与调整​

从建议的最低资源和副本数开始，然后根据您的部署需求和性能测试结果进行监控和按需扩缩容。 在资源评估和性能测试中考虑以下因素：

  • 工作流的复杂性。

  • 并发用户和请求的数量。

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

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

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

    对于生产部署，建议使用外部 PostgreSQL 数据库。

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

使用外部 PostgreSQL 数据库​

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

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

推荐的配置包括：

  • 持久化存储，以防止容器关闭时数据丢失。
  • 高可用 (HA) 或主主 (Active-Active) 配置，用于自动故障转移、扩缩容和负载均衡。
  • 多实例部署的共享数据库。
  • 多实例部署的共享存储（如 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 进行实时指标收集和监控。

    要公开 Langflow 服务器的 Prometheus 指标，请设置 LANGFLOW_PROMETHEUS_ENABLED=True（默认为 false）。 Prometheus 指标的默认端口为 9090。 要更改端口，请设置 LANGFLOW_PROMETHEUS_PORT。

  • API 性能：监控响应时间、错误率和请求吞吐量。为高延迟或错误激增设置警报。

  • 可观测性工具：与 LangWatch 或 Opik 集成，以获取详细的流追踪和指标。使用这些工具调试流性能并优化执行。

安全​

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

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

另请参阅​

Search