Chandra生产部署：K8s集群中Chandra服务的水平扩展与健康检查配置

Chandra生产部署：K8s集群中Chandra服务的水平扩展与健康检查配置

1. 从单机到集群：为什么需要生产级部署

你已经在本地或者测试环境体验过Chandra了，对吧？那个响应飞快、完全私有的AI聊天助手，用起来确实很爽。但当你准备把它交给团队使用，或者打算集成到自己的产品里时，问题就来了。

想象一下这个场景：早上10点，整个团队都开始用Chandra查资料、写周报，突然服务卡住了，所有人都跑来问你：“Chatbot怎么挂了？” 或者，随着用户量慢慢增加，每次对话的等待时间从1秒变成了5秒，大家开始抱怨“这AI变笨了”。

这就是单机部署的局限性。它就像一家只有一个服务员的小餐馆，平时客人少的时候服务很好，但一到饭点就忙不过来，客人等得着急，服务员也累得够呛。

真正的生产环境需要的是“连锁餐厅”级别的服务能力：客人多了就多开几个窗口，某个服务员不舒服了马上有人顶替，确保任何时候来都能吃到饭。

今天我要跟你聊的，就是怎么把Chandra这个“单间小馆”升级成“连锁餐厅”。具体来说，我们要解决两个核心问题：

• 水平扩展：用户多了怎么办？答案是开更多的“服务窗口”（Pod副本）。
• 健康检查：某个“服务员”（Pod）状态不好怎么办？答案是系统自动发现并替换。

我会手把手带你走一遍完整的配置过程，从基础的Deployment定义，到自动扩缩容策略，再到各种健康检查机制。等你跟着做完，你的Chandra服务就能真正扛起生产流量了。

2. 基础部署：让Chandra在K8s里跑起来

在考虑扩展和健康之前，我们得先让Chandra在Kubernetes里有个安稳的“家”。这个家就是Deployment——K8s里用来管理Pod副本的核心对象。

2.1 创建Chandra的Deployment配置

我们先从最基础的配置开始，创建一个能让Chandra正常运行的Deployment：

apiVersion: apps/v1 kind: Deployment metadata: name: chandra-deployment labels: app: chandra spec: replicas: 2 # 先启动2个副本，看看效果 selector: matchLabels: app: chandra template: metadata: labels: app: chandra spec: containers: - name: chandra image: your-registry/chandra:latest # 替换成你的镜像地址 ports: - containerPort: 8080 # Chandra WebUI默认端口 env: - name: OLLAMA_HOST value: "0.0.0.0" - name: OLLAMA_MODEL value: "gemma:2b" resources: requests: memory: "2Gi" cpu: "1000m" limits: memory: "4Gi" cpu: "2000m"

我来解释一下这里面的关键点：

• replicas: 2：这是副本数，现在我们先启动2个Pod。就像餐厅先安排2个服务员试营业。
• image：这里要换成你实际构建的Chandra镜像地址。如果你用的是CSDN星图镜像，可以直接用他们提供的镜像名。
• ports：Chandra的Web界面默认跑在8080端口，我们把这个端口暴露出来。
• env：设置了两个环境变量。OLLAMA_HOST=0.0.0.0让Ollama监听所有网络接口，OLLAMA_MODEL=gemma:2b指定使用哪个模型。
• resources：这是资源限制，非常重要。我给了每个Pod“最低2G内存、1核CPU”的保障，最多可以用到4G内存、2核CPU。这样既能保证服务稳定，又不会无限制占用资源。

2.2 第一次部署和验证

把上面的YAML保存为chandra-deployment.yaml，然后执行：

# 部署到K8s集群 kubectl apply -f chandra-deployment.yaml # 查看部署状态 kubectl get deployments # 应该看到类似这样的输出： # NAME READY UP-TO-DATE AVAILABLE AGE # chandra-deployment 2/2 2 2 10s # 查看具体的Pod运行情况 kubectl get pods -l app=chandra # 应该看到2个Pod都在Running状态

如果一切顺利，你会看到2个Chandra的Pod已经跑起来了。但这时候它们还只是“孤岛”，外部无法访问。我们需要给它们配个“前台接待”——Service。

2.3 添加Service：让外部能访问

创建Service的配置：

apiVersion: v1 kind: Service metadata: name: chandra-service spec: selector: app: chandra ports: - port: 80 targetPort: 8080 type: ClusterIP # 先用集群内部访问，后面可以改成LoadBalancer

应用这个配置：

kubectl apply -f chandra-service.yaml

现在，在K8s集群内部，其他服务就可以通过chandra-service这个域名访问到Chandra了。如果你想让外部也能访问，可以把type: ClusterIP改成type: LoadBalancer，或者配合Ingress使用。

到这一步，Chandra已经在K8s里安家了。但我们的工作才刚开始——现在的部署还很“脆弱”，接下来我们要给它加上“健康监测”和“自动扩容”能力。

3. 健康检查：给Chandra装上“体检仪”

健康检查是生产部署的“生命线”。想象一下，你的服务员虽然站在岗位上，但可能正在发烧头晕（进程卡住），或者动作特别慢（响应超时）。健康检查就是定期给服务员做体检，发现不健康的就换人。

K8s提供了三种健康检查机制，我们给Chandra全都配上。

3.1 存活探针：检查“是否活着”

存活探针（Liveness Probe）回答一个最基本的问题：这个容器还活着吗？如果检查失败，K8s会重启这个Pod。

对于Chandra这种Web服务，最适合用HTTP探针：

# 在Deployment的container部分添加： livenessProbe: httpGet: path: / # 访问WebUI根路径 port: 8080 initialDelaySeconds: 60 # 容器启动后等60秒再开始检查 periodSeconds: 10 # 每10秒检查一次 timeoutSeconds: 5 # 5秒没响应就算超时 failureThreshold: 3 # 连续失败3次才认为不健康

为什么这么配置？

• initialDelaySeconds: 60：这是关键！Chandra启动时需要拉取模型、初始化Ollama，这个过程可能需要几十秒。如果一启动就检查，肯定失败。我们给足60秒的启动时间。
• path: /：我们检查WebUI的根路径，如果能正常返回页面，说明服务是活的。
• failureThreshold: 3：连续3次失败（也就是30秒）才重启，避免网络抖动导致的误杀。

3.2 就绪探针：检查“是否准备好接客”

就绪探针（Readiness Probe）回答另一个问题：这个容器准备好接收流量了吗？如果检查失败，这个Pod会从Service的负载均衡池里移除，但不会被重启。

配置和存活探针类似，但意义不同：

readinessProbe: httpGet: path: /api/health # 建议专门做一个健康检查接口 port: 8080 initialDelaySeconds: 30 periodSeconds: 5 # 检查更频繁 timeoutSeconds: 3 failureThreshold: 1 # 一次失败就认为没准备好

这里我用了/api/health而不是根路径。为什么？因为根路径可能能访问（服务进程还在），但背后的Ollama可能已经卡住了。理想情况下，你应该在Chandra应用里添加一个真正的健康检查接口，它会去检查Ollama服务是否正常。

如果暂时不想改代码，也可以用根路径，但要知道这只能检查“Web服务是否在运行”，不能检查“AI模型是否正常”。

3.3 启动探针：解决“慢启动”问题

启动探针（Startup Probe）是K8s 1.16之后引入的，专门解决“启动慢”的服务的问题。Chandra就是典型的慢启动服务——拉取模型可能要几十秒。

startupProbe: httpGet: path: / port: 8080 failureThreshold: 30 # 可以尝试很多次 periodSeconds: 5 # 每5秒试一次

启动探针的特别之处在于：在它成功之前，存活探针和就绪探针都不会启动。这样，K8s会给Chandra足够的时间完成初始化，不会在启动过程中就把它杀掉。

3.4 完整的健康检查配置

把三种探针组合起来，我们的Deployment配置就变成了这样：

# containers部分完整示例： containers: - name: chandra image: your-registry/chandra:latest ports: - containerPort: 8080 env: - name: OLLAMA_HOST value: "0.0.0.0" - name: OLLAMA_MODEL value: "gemma:2b" resources: requests: memory: "2Gi" cpu: "1000m" limits: memory: "4Gi" cpu: "2000m" livenessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 60 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 readinessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 30 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 1 startupProbe: httpGet: path: / port: 8080 failureThreshold: 30 periodSeconds: 5

现在部署这个更新后的配置：

kubectl apply -f chandra-deployment-with-probes.yaml # 查看Pod的详细状态，可以看到探针信息 kubectl describe pod chandra-deployment-xxxxx

在describe命令的输出里，你会看到类似这样的信息：

Liveness: http-get http://:8080/ delay=60s timeout=5s period=10s #success=1 #failure=3 Readiness: http-get http://:8080/ delay=30s timeout=3s period=5s #success=1 #failure=1 Startup: http-get http://:8080/ delay=0s timeout=1s period=5s #success=1 #failure=30

这意味着健康检查已经生效了。如果某个Pod的Ollama服务卡住，Web界面无法访问，就绪探针会先把它从服务列表里踢出去，如果问题持续，存活探针会让K8s重启这个Pod。

4. 水平扩展：让Chandra随流量自动伸缩

健康检查保证了每个“服务员”的状态，水平扩展则解决了“客人太多”的问题。在K8s里，我们使用Horizontal Pod Autoscaler（HPA）来实现自动扩缩容。

4.1 HPA的工作原理

HPA的工作逻辑很简单：

1. 定期检查Pod的CPU/内存使用率（或者其他自定义指标）
2. 如果使用率超过设定的阈值，就增加Pod数量
3. 如果使用率低于阈值，就减少Pod数量
4. 在设定的最小和最大副本数之间调整

对于Chandra这种AI服务，CPU使用率是最直接的扩缩容指标——用户提问越多，模型推理越频繁，CPU占用就越高。

4.2 创建Chandra的HPA配置

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: chandra-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: chandra-deployment minReplicas: 2 # 最少2个副本 maxReplicas: 10 # 最多10个副本 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU平均使用率目标70% behavior: scaleDown: stabilizationWindowSeconds: 300 # 缩容冷却时间300秒 policies: - type: Percent value: 50 # 一次最多缩容50%的Pod periodSeconds: 60 scaleUp: stabilizationWindowSeconds: 60 # 扩容冷却时间60秒 policies: - type: Percent value: 100 # 一次最多扩容100%（翻倍） periodSeconds: 60 - type: Pods value: 4 # 或者一次最多增加4个Pod periodSeconds: 60 selectPolicy: Max # 取两个策略中扩容更快的那一个

这个配置有几个精妙之处：

• averageUtilization: 70%：为什么是70%而不是80%或90%？因为要留出缓冲空间。如果等到CPU跑到90%才扩容，扩容过程中可能已经超载了。70%是个比较安全的值。
• scaleDown stabilizationWindowSeconds: 300：缩容冷却时间5分钟。避免流量短暂下降就立即缩容，然后流量上来又要扩容的“抖动”。
• scaleUp stabilizationWindowSeconds: 60：扩容冷却时间只有1分钟。流量增长时需要快速响应。
• 一次最多缩容50%：避免一下子缩容太多，万一判断错误，还有缓冲。
• 一次最多扩容100%或4个Pod：流量暴增时可以快速扩大规模。

4.3 部署和测试HPA

# 创建HPA kubectl apply -f chandra-hpa.yaml # 查看HPA状态 kubectl get hpa chandra-hpa # 输出类似： # NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE # chandra-hpa Deployment/chandra-deployment 42%/70% 2 10 2 1m # 详细查看 kubectl describe hpa chandra-hpa

现在HPA已经生效了。你可以用一些压力测试工具模拟用户请求，观察Pod数量的变化：

# 监控Pod数量变化 watch kubectl get pods -l app=chandra # 监控HPA指标 watch kubectl get hpa chandra-hpa

4.4 基于自定义指标的扩缩容

CPU指标对于Chandra来说可能不够精确。有时候，更好的指标是“请求排队长度”或“平均响应时间”。这需要安装Metrics Server和Prometheus Adapter，配置稍微复杂一些。

如果你需要基于QPS（每秒查询数）来扩缩容，配置大概是这样的：

metrics: - type: Pods pods: metric: name: requests_per_second target: type: AverageValue averageValue: 50 # 每个Pod平均每秒处理50个请求

不过对于大多数场景，基于CPU的HPA已经足够好用。关键是设置合理的阈值和冷却时间。

5. 实战技巧与常见问题

配置都写好了，但在实际运行中你可能会遇到一些坑。我总结了几条实战经验，帮你少走弯路。

5.1 资源限制要合理

我给Chandra设置的资源限制是requests: 2Gi内存/1核CPU，limits: 4Gi内存/2核CPU。这个配置对gemma:2b模型是足够的，但如果你换更大的模型，需要调整。

怎么知道需要多少资源？先不设limits跑一段时间，观察监控：

# 查看Pod的资源使用情况 kubectl top pods -l app=chandra

你会看到每个Pod的实际CPU和内存使用量。在这个基础上加20-30%的余量作为limits，用80%的实际使用量作为requests。

5.2 镜像拉取策略

如果你的镜像仓库在海外，或者镜像很大，Pod启动可能会因为拉取镜像而变慢。可以设置镜像拉取策略：

imagePullPolicy: IfNotPresent # 如果本地有就不拉取

对于生产环境，更推荐使用本地镜像仓库，或者提前把镜像拉到各个节点上。

5.3 处理Ollama模型拉取

Chandra启动时需要拉取gemma:2b模型，大约1.4GB。如果每个Pod都从零开始拉取，启动会很慢。有几种优化方案：

1. 使用Init Container预拉模型：

initContainers: - name: download-model image: your-registry/ollama:latest command: ["ollama", "pull", "gemma:2b"] volumeMounts: - name: model-storage mountPath: /root/.ollama

2. 使用PVC共享模型文件：所有Pod挂载同一个存储卷，模型只需要下载一次。

3. 使用已经包含模型的镜像：构建镜像时就把模型打包进去，但这样镜像会很大。

5.4 监控和告警

部署好了，扩展和健康检查也配了，但你不能一直盯着看。需要设置监控和告警：

1. Pod重启告警：如果某个Pod频繁重启（比如一小时重启3次），说明可能有问题。
2. HPA频繁伸缩告警：如果HPA在短时间内频繁扩容缩容，可能是阈值设置不合理。
3. 请求失败率告警：如果HTTP错误率超过5%，需要关注。

你可以用Prometheus + Grafana + Alertmanager搭建完整的监控体系，或者用云服务商提供的监控服务。

5.5 滚动更新策略

当你需要更新Chandra镜像版本时，怎么做到不停机升级？Deployment默认的滚动更新策略已经不错，但我们可以优化：

strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # 更新时最多可以比期望副本数多1个Pod maxUnavailable: 0 # 更新时保证至少有当前副本数的Pod可用

这样更新时，K8s会先启动一个新版本的Pod，等它通过健康检查后，再关掉一个旧版本的。整个过程服务不中断。

6. 总结

我们从头到尾走了一遍Chandra的生产级部署流程。现在你的Chandra服务应该具备：

1. 健壮的健康检查：三种探针确保每个Pod都处于健康状态，不健康的自动替换。
2. 智能的水平扩展：根据CPU使用率自动调整Pod数量，流量高峰时扩容，低谷时缩容。
3. 合理的资源管理：每个Pod都有明确的内存和CPU限制，不会无节制占用资源。
4. 零停机更新能力：滚动更新策略让你可以安全地升级版本。

让我再强调几个关键点：

• 健康检查的initialDelaySeconds一定要给够：Chandra启动慢，如果检查太早，Pod会陷入“启动→被kill→重启”的死循环。
• HPA的阈值要保守一点：70%的CPU使用率是个不错的起点，你可以根据实际观察调整。
• 监控比配置更重要：再好的配置也需要监控来验证。一定要看实际运行数据，而不是“我觉得应该这样”。

最后，生产部署不是一次性的工作。随着用户量增长、使用模式变化，你可能需要调整HPA的阈值、资源限制、探针参数等。定期回顾监控数据，持续优化，才能让服务越来越稳定。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。