Kubernetes微服务部署Redis Cache架构方案咨询

一、方案可行性 #

你考虑的两种架构思路都完全可行，只是适用场景不同：

• 单Redis实例给5个应用副本使用：适合缓存数据需要跨应用副本共享、对缓存一致性要求高的场景。但要注意单Redis存在性能瓶颈和单点故障风险，如果是高并发场景，后续可能需要扩展为主从集群或Redis Cluster。
• 每个应用单独部署Redis Deployment：适合各应用缓存数据需要完全隔离、缓存策略（比如过期时间、内存限制）差异大的场景。缺点是会增加Kubernetes集群的资源开销和运维成本，比如要维护多个Redis实例的配置、备份等。

二、应用与Redis的通信方式 #

必须通过Service暴露Redis Pod，原因很直接：

• Kubernetes里Pod的IP是动态变化的，重启、调度都会导致IP改变，Service能提供稳定的DNS名称和固定入口，应用不用关心底层Pod的变动。
• 操作方式：给Redis Deployment创建一个ClusterIP类型的Service（默认类型，仅集群内部可访问），应用容器内直接用Service的名称（比如my-app-redis）加Redis默认端口6379作为连接地址，比如代码里写redis://my-app-redis:6379即可。

三、Redis与应用同节点部署：必要性与实现 #

• 是否必要？ 不是必须的，分场景判断：
  • 优势：减少跨节点网络延迟，提升缓存访问速度；降低集群内部网络带宽占用。
  • 劣势：如果节点故障，应用和Redis会同时不可用，单点风险更高；节点资源压力集中，容易出现CPU、内存争抢。
• 实现方法：
  • 方法一：节点亲和性（Node Affinity）
    先给目标节点打上自定义标签，比如kubectl label nodes node-01 app=my-web-app，然后在Redis和应用的Deployment里配置节点亲和性，指定调度到带有该标签的节点：

    # Redis Deployment 亲和性配置片段
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: app
              operator: In
              values:
              - my-web-app
    

    应用的Deployment也添加同样的配置，就能保证两者在同一节点运行。
  • 方法二：Pod亲和性（Pod Affinity）
    不需要预先给节点打标签，直接让应用Pod调度到已经运行Redis Pod的节点上：

    # 应用Deployment 亲和性配置片段
    affinity:
      podAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - my-app-redis
          topologyKey: kubernetes.io/hostname
    

    这里的topologyKey: kubernetes.io/hostname表示要调度到同一主机节点。

内容的提问来源于stack exchange，提问作者Josh Wright