以下页面描述网关的预期行为。开源版本与企业版本正在拆分中,首个正式版本发布后细节会同步更新。
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 内存起步;只有在调大连接池时才需要提高内存上限。