跳到主要内容
SolidwayLLM 网关

以下页面描述网关的预期行为。开源版本与企业版本正在拆分中,首个正式版本发布后细节会同步更新。

Kubernetes

Deployment、探针,以及为什么控制台状态要放在卷上而不是 ConfigMap 里。

清单要点

apiVersion: apps/v1
kind: Deployment
metadata:
  name: solidway
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: solidway
          image: solidway/gateway:latest
          ports:
            - { name: http, containerPort: 8080 }
            - { name: console, containerPort: 8081 }
          livenessProbe:
            httpGet: { path: /health, port: http }
          readinessProbe:
            httpGet: { path: /ready, port: http }
          volumeMounts:
            - { name: config, mountPath: /etc/solidway, readOnly: true }
            - { name: state, mountPath: /var/lib/solidway }
          resources:
            requests: { cpu: 250m, memory: 128Mi }
            limits: { memory: 512Mi }
      volumes:
        - name: config
          configMap: { name: solidway-bootstrap }
        - name: state
          persistentVolumeClaim: { claimName: solidway-state }

两个卷不能互换

ConfigMap 存放启动配置:监听地址、对外域名、控制台绑定。它很小、很少变, 可以按普通配置对待。

PersistentVolumeClaim 存放控制台管理的一切 —— provider、凭据、加密后的密钥、路由、策略、告警规则。 不要把它放进 ConfigMap。 它在运行期被写入、包含密钥,而且丢掉它意味着要重新录入每一个凭据。

多副本与共享状态

多于一个副本时,每个 Pod 需要看到同一份状态。三种做法:

做法 取舍
ReadWriteMany 卷 最简单,前提是你的存储类支持
只让一个副本提供控制台 控制台改动在单个 Pod 上完成,其余副本读同一个卷
企业版集群模式 状态在节点间复制,健康信号共享

没有共享状态时,各副本对「存在哪些 target」的判断可能不一致,暂停状态也是每副本各自持有。 这是刻意的取舍:对一个不健康 target 多发一次探测的成本,低于在整个集群里协调健康状态的成本。

探针

探针 端点 含义
存活 /health 进程在跑。失败会重启容器。
就绪 /ready 状态目录可读,且至少配置了一个 provider

存活探针要尽量简单。依赖上游 provider 的探针,会在 provider 抖动时把你的网关重启掉。

资源规划

容量由连接并发数决定,而不是由历史请求量决定:

  • CPU 随每秒请求数变化
  • 内存由配置的连接池界定,不随流量增长

每秒几百个请求的场景,可以从 250m CPU、128Mi 内存起步;只有在调大连接池时才需要提高内存上限。

下一步