排查 Amazon EKS 环境中 Redis 连接超时 (Timeout) 及调试

排查 Amazon EKS 环境中 Redis 连接超时 (Timeout) 及调试

Redis 已成为现代应用程序架构的基石，作为高速缓存、会话管理和 pub/sub 消息传输等多功能内存数据存储系统。然而，当与容器化应用程序一起部署在 Amazon Elastic Kubernetes Service (EKS) 环境中时，团队经常遇到难以诊断和解决的连接问题。这些问题包括高流量期间的间歇性超时、集群扩容时的连接问题、跨命名空间的性能不一致，以及突发的连接中断。

简介

Redis 连接问题和超时特别令人困扰，因为这些问题多半在高负载时才会间歇性出现，且难以在开发环境中重现。当团队将系统迁移至 EKS 或扩展 Redis 使用规模时，经常会遇到以下问题：

  • 高流量期间发生间歇性连接超时
  • 集群扩容后出现连接问题
  • 跨 Kubernetes 命名空间的性能表现不一致
  • 应用程序 Pod 与 Redis 端点之间发生意外连接中断

这些问题可能导致用户体验下降，严重时甚至造成服务完全中断。因此，确保 Redis 连接的稳定性成为一项关键的运营任务。本文将提供完整指南，帮助您诊断、排除及解决 EKS 环境中的 Redis 连接问题。

Kubernetes 环境中 Redis 超时的常见原因

在深入探讨疑难排解技巧之前，先了解容器化环境中造成 Redis 超时的主要原因至关重要：

Connection Pool 用尽

现代应用程序通常采用连接池来有效管理 Redis 连接。在 Kubernetes 环境中，随着 Pod 动态扩容，连接池会快速倍增：

  • 每个 Pod 维护独立的连接池（一般介于 5-50 个连接）
  • Pod 扩容时，总连接数可能超出 Redis 的限制
  • Redis 的默认连接上限（10,000 个连接1）虽然看似充裕，但系统性能通常在达到此限制前就会开始下降

以下是连接池用尽时的应用程序日志示例：

2023-08-12T14:25:18.456Z ERROR [app-service] - Redis connection error: JedisPoolExhaustedException: Could not get a resource from the pool

网络延迟与不稳定性

Kubernetes 增加了额外的网络层，可能会造成延迟：

  • 容器网络接口 (CNI) 路由开销
  • 如果 Pod 和 Redis 位于不同的 AWS Availability Zone，则会产生跨可用性区流量
  • DNS 解析出现延迟或解析失败
  • Pod 被驱逐时引发大量连接重新建立

超时配置不一致

技术堆栈中的各层超时设置若不一致，往往会引发问题：

  • Redis 服务器本身的超时设置
  • 客户端库对连接和操作各自的超时设置
  • Kubernetes 的存活性与就绪性探测的超时设置
  • 负载均衡器或代理层的超时设置

资源限制

Redis 或客户端的资源受限可能导致连接异常：

  • Redis 服务器内存压力过大，造成数据驱逐或性能降低
  • 应用程序 Pod 的 CPU 限制影响 Redis 响应的处理速度
  • 节点或 Pod 层级的网络流量限制

EKS Pod 与 Redis 之间的网络连接疑难排解

面对连接问题时，系统化的网络故障排除至关重要。从基础的 TCP/IP 连接测试到应用程序层级的 Redis 命令验证，每一层都需要仔细检查。同时监控系统指标和日志，以找出可能的瓶颈或故障点。通过这种结构化的排除流程，能更有效地找出并解决 EKS 环境中的 Redis 连接问题。

以下列举几个最常用来检查和解决 Redis 连接问题的诊断步骤。从基础连接测试到高级监控工具的使用，这些步骤将帮助您有系统地找出问题所在。

基本连接测试

让我们从基本的验证连接开始：

# 在相同命名空间创建调试用的 Pod（有时候可能需要部署到特定节点）
kubectl run redis-debug --rm -it --image=redis:alpine -- sh

# 测试基本连接能力
nc -zv my-redis-master.xxxx.ng.0001.use1.cache.amazonaws.com 6379

# 用 Redis CLI 做简单测试
redis-cli -h my-redis-master.xxxx.ng.0001.use1.cache.amazonaws.com ping

# 检查 DNS 解析是否正常
nslookup my-redis-master.xxxx.ng.0001.use1.cache.amazonaws.com

# 使用 tcpdump 观察 TCP 连接的细节
tcpdump -i any port 6379 -vv

安全组 (Security Group) 配置

对于 ElastiCache Redis 或 EC2 托管的 Redis，Security Group 通常是造成连接问题的主要原因：

# 找出指派给 EKS 节点的安全组
NODE_SG=$(aws eks describe-nodegroup --cluster-name my-cluster \\
  --nodegroup-name my-nodegroup --query 'nodegroup.resources.remoteAccessSecurityGroup' \\
  --output text)

# 确保 Redis 的安全组允许来自节点安全组的流量
aws ec2 authorize-security-group-ingress \\
  --group-id sg-0123456789abcdef0 \\  # Redis 安全组
  --source-group $NODE_SG \\
  --protocol tcp \\
  --port 6379

网络策略 (Network Policy) 分析

如果您使用 Kubernetes 网络策略 (Network Policy)，验证它们是否阻止 Redis 流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-egress
  namespace: application
spec:
  podSelector:
    matchLabels:
      app: my-application
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/16  # Subnet containing Redis
    ports:
    - protocol: TCP
      port: 6379

VPC 与子网路由

对于复杂的 VPC 配置，验证 EKS 子网与 Redis 之间的路由和跨可用性区域的连接，确保应用程序可以可靠地访问 Redis 实例。这需要检查 VPC 内的路由表配置，以及任何 NAT Gateway 或 Transit Gateway 的设置状态。此外，还要注意子网的 CIDR 范围是否有重叠的问题：

# 检查 Pod 是否在预期的子网中
kubectl get pods -o wide

# 检查这些子网关联的路由表设置
aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=subnet-12345"

# 如果 Redis 在不同的 VPC，检查 VPC Peering 连接状态
aws ec2 describe-vpc-peering-connections

容器化环境中 Redis 客户端的最佳配置实践

正确配置 Redis 客户端可大幅提升 Kubernetes 环境中的可靠性。以下是针对不同语言和框架的 Redis 客户端配置最佳实践，这些配置可以帮助您建立更稳定和可靠的 Redis 连接。这些设置包括连接池管理、超时处理、错误重试策略等关键元素。通过遵循这些最佳实践，您可以大幅减少连接问题并提高应用程序的可用性。

Connection Pool

除了使用默认设置，您也可以根据工作负载明确配置 Connection Pool 2：

// Java example with Lettuce client
@Bean
public LettuceConnectionFactory redisConnectionFactory() {
    LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
        .poolConfig(poolConfig())
        .commandTimeout(Duration.ofMillis(500))
        .shutdownTimeout(Duration.ZERO)
        .build();

    return new LettuceConnectionFactory(redisStandaloneConfig(), clientConfig);
}

@Bean
public GenericObjectPoolConfig poolConfig() {
    GenericObjectPoolConfig config = new GenericObjectPoolConfig();
    config.setMaxTotal(20);           // Max connections per pod
    config.setMaxIdle(10);            // Connections to maintain when idle
    config.setMinIdle(5);             // Minimum idle connections to maintain
    config.setTestOnBorrow(true);     // Validate connections when borrowed
    config.setTestWhileIdle(true);    // Periodically test idle connections
    config.setMaxWait(Duration.ofMillis(1000)); // Max wait for connection
    return config;
}

适用于 Node.js 应用程序：

// Node.js with ioredis
const Redis = require('ioredis');

const redis = new Redis({
  host: process.env.REDIS_HOST,
  port: 6379,
  password: process.env.REDIS_PASSWORD,
  db: 0,
  maxRetriesPerRequest: 3,
  connectTimeout: 1000,
  commandTimeout: 500,
  retryStrategy(times) {
    const delay = Math.min(times * 50, 2000);
    return delay;
  }
});

超时 (Timeout) 和重试

根据您的应用程序需求，适当地设置超时时间：

# Python with redis-py
import redis
from redis.retry import Retry

retry = Retry(ExponentialBackoff(), 3)

redis_client = redis.Redis(
    host=os.environ.get('REDIS_HOST'),
    port=6379,
    socket_timeout=1.0,           # Operation timeout
    socket_connect_timeout=1.0,   # Connection timeout
    retry_on_timeout=True,
    retry=retry,
    health_check_interval=30      # Verify connections every 30 seconds
)

Pod 生命周期中的优雅连接处理

在 Pod 启动和关闭期间适当管理连接非常重要，但却经常被忽略：

// Java Spring Boot example
@PreDestroy
public void cleanupRedisConnections() {
    if (redisConnectionFactory instanceof LettuceConnectionFactory) {
        ((LettuceConnectionFactory) redisConnectionFactory).destroy();
        log.info("Cleaned up Redis connections before pod termination");
    }
}

对于 Kubernetes 部署，配置适当的终止宽限期：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-client-app
spec:
  template:
    spec:
      terminationGracePeriodSeconds: 30
      containers:
      - name: app
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 5"]  # Allow time for connection cleanup

影响 Redis 连接的 EKS 网络概念

要解决 Redis 连接问题，我们可以先搞清楚 EKS 网络是怎么运作的。这其实没那么复杂，主要包含几个部分：AWS VPC CNI 插件负责处理 Pod 的网络连接、Security Group 帮你管理 Pod 和 Redis 之间的连接权限、服务发现机制让你可以找到 Redis 在哪里，还有子网设置确保你的 Pod 可以连到不同区域的 Redis 集群。

AWS VPC CNI 概要

Amazon VPC CNI 插件是 EKS 的默认网络解决方案，具有几个重要的特性：

  • 每个 Pod 都会收到一个真正的 VPC IP 地址
  • Pod IP 地址来自于节点的子网
  • 根据实例类型，每个节点都有 IP 地址限制
  • 节点的安全组适用于 Pod 流量

此架构表示您的 Pod 可直接与 Redis 通信，无需 NAT，简化了安全设置，但需要适当的子网和安全组设置。

Pod 密度与 IP 地址耗尽

EKS 节点可使用的 IP 地址数量有限制3：

实例类型 最大 Pod IP
t3.small 11
m5.large 29
c5.xlarge 58

如果 pod 无法获取 IP 地址，就会一直处于 Pending 状态，影响应用程序的可用性。监控 IP 地址使用情况：

# Check available IP addresses per node
kubectl describe node | grep "Allocated"

服务发现机制

要访问 Redis 服务，以下是常见的方法：

1. 使用外部名称服务：

apiVersion: v1
kind: Service
metadata:
  name: redis-master
spec:
  type: ExternalName
  externalName: my-redis.xxxx.ng.0001.use1.cache.amazonaws.com

2. 使用环境变量和 ConfigMaps：

apiVersion: v1
kind: ConfigMap
metadata:
  name: redis-config
data:
  redis-host: "my-redis.xxxx.ng.0001.use1.cache.amazonaws.com"
  redis-port: "6379"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  template:
    spec:
      containers:
      - name: app
        envFrom:
        - configMapRef:
            name: redis-config

安全组考虑

EKS pod 流量会继承节点的安全组。对于 ElastiCache 连接：

  1. 识别节点安全组：
aws eks describe-nodegroup --cluster-name your-cluster --nodegroup-name your-nodegroup --query 'nodegroup.remoteAccessSecurityGroup'
  1. 设置 ElastiCache 安全组：
aws elasticache modify-replication-group --security-group-ids sg-012345abcdef --replication-group-id your-redis-cluster

监控与可观察性策略

建立完整的监控机制，能让您在 Redis 连接问题影响应用程序之前及早发现并处理。

监控的关键指标

针对 Redis：

  • CurrConnections：当前的客户端连接 (警示突然的变化)
  • NetworkBytesIn/Out：网络流量模式
  • CPUUtilization：CPU 使用率 (命令处理期间的峰值)
  • SwapUsage：显示内存压力
  • CommandLatency: 命令延迟：操作响应时间

用于客户端应用程序：

  • 连接超时与错误
  • 连接池使用率
  • 到 Redis 的请求延迟
  • 重试次数和断路器激活

用于 Redis 监控的 CloudWatch 面板

为 Redis 监控创建全面的仪表板：

aws cloudwatch put-dashboard --dashboard-name "Redis-Monitoring" --dashboard-body '{
  "widgets": [
    {
      "type": "metric",
      "x": 0,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "metrics": [
          [ "AWS/ElastiCache", "CurrConnections", "CacheClusterId", "my-redis" ]
        ],
        "period": 60,
        "stat": "Average",
        "region": "us-east-1",
        "title": "Current Connections"
      }
    },
    {
      "type": "metric",
      "x": 12,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "metrics": [
          [ "AWS/ElastiCache", "CPUUtilization", "CacheClusterId", "my-redis" ]
        ],
        "period": 60,
        "stat": "Average",
        "region": "us-east-1",
        "title": "CPU Utilization"
      }
    }
  ]
}'

Prometheus 和 Grafana 集成

如需更详细的监控，请导出 Redis 指标至 Prometheus：

apiVersion: v1
kind: ConfigMap
metadata:
  name: redis-exporter-config
data:
  redis-exporter.conf: |
    redis.addr=my-redis:6379
    namespace=redis
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-exporter
spec:
  template:
    spec:
      containers:
      - name: exporter
        image: oliver006/redis_exporter:latest
        ports:
        - containerPort: 9121
        envFrom:
        - configMapRef:
            name: redis-exporter-config

分布式追踪

实施分布式追踪以找出 Redis 相关瓶颈：

// Using Spring Cloud Sleuth with Redis
@Bean
public RedisTemplate<String, Object> redisTemplate(
        RedisConnectionFactory redisConnectionFactory,
        SpanCustomizer spanCustomizer) {

    RedisTemplate<String, Object> template = new RedisTemplate<>();
    template.setConnectionFactory(
        new TracingRedisConnectionFactory(
            redisConnectionFactory,
            "redis",
            spanCustomizer
        )
    );
    return template;
}

结论与检查清单

虽然 EKS 环境中的 Redis 连接问题看似复杂，但通过系统化的方法便能有效解决。在容器化环境中维持 Redis 的稳定运作，关键在于三个要素：妥善配置客户端、有效管理容器生命周期，以及规划合适的基础架构规模。

要维持一个健康的 Redis 环境，除了刚才提到的这些技术面的设置，你还得常常做一些压力测试，看看系统到底能撑多少负载。也通过增强监控和自动警报系统，这样系统有问题时你马上就知道。别忘了让团队的每个人都熟悉一下怎么解决常见问题，这样遇到状况时才不会手忙脚乱。

以下是一份实用的检查清单，里面列出了处理 Redis 连接问题时要注意的项目：

Redis 连接疑难排解清单

网络连接

  • 验证 Redis 端点的 DNS 解析
  • 确认安全组允许来自 EKS 节点的流量
  • 使用 nc、telnet 和 redis-cli 测试基本连接性
  • 验证 pod 子网与 Redis 之间的路由是否正确

客户端设置

  • 使用明确的连接池设置，而非默认值
  • 为连接和操作设置适当的超时时间
  • 实施连接健康检查
  • 在 pod 终止时设置适当的连接处理

Redis 实例大小

  • 确保实例类型可以处理预期的连接数
  • 监控内存使用量，并考虑启用最大内存策略
  • 针对读取繁重的工作负载，使用读取副本评估读/写分离
  • 针对大型数据集或高吞吐量，考虑使用 Redis Cluster

扩展行为

  • 在 HPA 配置中实施渐进式扩展策略
  • 在扩展事件中监控连接模式
  • 考虑在应用程序层级限制连接
  • 在扩展和缩减事件中测试应用程序行为

监控和警报

  • 为 Redis 指标 (连接、CPU、内存) 设置 CloudWatch 警报
  • 实施 Redis 操作的应用程序层级指标
  • 配置分布式追踪，以获得端到端的可视性
  • 建立显示相关应用程序和 Redis 指标的仪表板

通过留意这些不同方面，你的系统不只能轻松应对高峰期的流量，还能保持稳定。不过，在 EKS 环境中设置 Redis 连接只是第一步，更重要的是要打造具有弹性的系统，以优雅地应对容器化环境的动态特性。

参考资料

  1. Redis Maximum Concurrent Connected Clients ↩

  2. AWS Database Blog - Best practices: Redis clients and Amazon ElastiCache for Redis ↩

  3. EKS node default max pod limits ↩

« 非官方 EKS 集群创建性能：AWS 各区域集群创建时间
我如何在 24 小时内完成 AWS Certified AI Practitioner 认证 »
comments powered by Disqus
Table of Content
Newsletter

订阅并获取更新