Kubernetes中针对非REST容器（Shiny App）的会话保持与自适应扩缩容方案咨询

嘿，针对你遇到的Shiny App会话上下文问题和自适应扩缩容需求，我给你整理了两个简单可行的方案，都是Kubernetes原生或者轻量工具能实现的，不用太复杂的配置：

一、实现基于IP的会话保持（同一用户IP固定路由到同一Pod） #

首先，Kubernetes的Service本身就支持ClientIP类型的会话亲和性，刚好能满足你“同一IP路由到同一Pod”的需求，还能设置超时时间，超时后会重新分配Pod，完美适配Shiny App的会话上下文特性。

具体配置超简单，你只需要在Service的YAML里加几行配置就行：

apiVersion: v1
kind: Service
metadata:
  name: shiny-app-service
spec:
  selector:
    app: shiny-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3838  # Shiny App默认端口是3838，根据你的实际情况调整
  sessionAffinity: ClientIP  # 开启基于客户端IP的会话绑定
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 1800  # 超时时间设为30分钟，你可以根据业务需求调整（比如设为3600就是1小时）

配置完成后，同一个IP的用户请求会被持续路由到同一个Pod，直到超时时间到期或者Pod被销毁。如果你的Shiny App是通过Ingress对外暴露的（比如用NGINX Ingress），也可以在Ingress的注解里配置IP亲和性：

annotations:
  nginx.ingress.kubernetes.io/affinity: "ip"
  nginx.ingress.kubernetes.io/session-cookie-expires: "1800"
  nginx.ingress.kubernetes.io/session-cookie-max-age: "1800"

不过用Service的ClientIP亲和性更直接，不需要额外折腾Ingress规则，适合简单场景。

二、实现基于用户数的自适应扩缩容（2 + ceiling(用户数/10)） #

默认的HPA（水平Pod扩缩容）只能基于CPU、内存这些资源指标，但你需要的是基于用户会话数，这时候我们可以用自定义指标来实现，这里给你两种方案：

方案1：原生HPA + Prometheus（无额外依赖，适合熟悉K8s原生组件的用户） #

首先，你需要让Shiny App暴露用户会话数的指标。可以用shinymetrics这个R包，它能帮你在Shiny App里快速添加一个/metrics端点，输出当前活跃的会话数指标（比如shiny_active_sessions）。

接下来部署Prometheus采集这个指标，再部署Prometheus Adapter，把Prometheus的指标转换成Kubernetes API能识别的自定义指标。

最后创建HPA配置，设置最小副本数为2，基于总会话数来匹配你的扩缩容公式：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: shiny-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: shiny-app-deployment
  minReplicas: 2  # 预先生成2个基础副本
  maxReplicas: 20  # 最大副本数，根据你的集群资源情况调整
  metrics:
  - type: External
    external:
      metric:
        name: shiny_total_active_sessions  # Prometheus Adapter暴露的总会话数指标
      target:
        type: Value
        value: "10"  # 每10个用户对应1个额外副本

这个配置的逻辑是：HPA会自动计算ceil(总用户数/10)，再结合最小2个副本的设置，刚好匹配你要的2 + ceiling(用户数/10)规则。比如总用户数21时，HPA会自动扩容到5个副本。

方案2：KEDA（更灵活的轻量方案，适合快速落地） #

KEDA是专门做事件驱动扩缩容的工具，支持各种自定义指标，配置起来比原生HPA更灵活，不需要复杂的Prometheus Adapter配置。

步骤很简单：

1. 先把KEDA部署到你的Kubernetes集群（官方有一键部署脚本，很方便）。
2. 同样让Shiny App用shinymetrics暴露会话数指标，用Prometheus采集。
3. 创建ScaledObject配置，直接用你的扩缩容公式：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: shiny-app-scaledobject
spec:
  scaleTargetRef:
    name: shiny-app-deployment
  minReplicaCount: 2  # 基础副本数
  maxReplicaCount: 20
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus-server.default.svc.cluster.local:9090  # 你的Prometheus地址
      metricName: shiny_total_active_sessions
      query: ceil(sum(shiny_active_sessions)/10) + 2  # 直接用你的公式计算目标副本数
      threshold: "2"  # 阈值设为2，因为我们的query已经算出了准确的副本数

这样KEDA会定期执行Prometheus查询，根据结果自动调整Pod的数量，完全符合你要的扩缩容规则。

最后提醒你几个注意点：

• 确保Shiny App的会话数指标采集准确，不然扩缩容会出错；
• 最大副本数要根据你的集群资源（CPU、内存）来设置，避免资源耗尽；
• 会话亲和性的超时时间要设置合理，太短会导致用户会话频繁切换Pod，太长会导致Pod负载不均。

备注：内容来源于stack exchange，提问作者Arnaud Feldmann