0%

kubelet cri containerd cni runc 之间的业务交互流程

1. kubelet 与底层交互的过程演变:

底层 cri 演变过程

背景:

在 Kubernetes 集群中部署容器化应用时,若依赖的远程数据源出现异常且无法在本地测试环境模拟相同数据条件,可能导致问题难以在开发环境中重现。此时,需要使用远程 dlv 调试技术对生产环境中的容器实例进行实时诊断和问题追踪。

实现过程:

索引重建方案

我们通过创建新索引的方式来解决现有索引字段类型问题:

  1. 创建新索引并设置正确的mapping映射
  2. 使用POST /_reindex迁移数据
  3. 验证数据和mapping映射
  4. 删除原错误索引
  5. 创建别名指向老索引名称

Elasticsearch 时间段查询实战

在实际业务场景中,我们经常需要查询每天特定时间段的数据,比如查询每天早高峰(7-9点)的订单数据,或者夜间(23-6点)的系统日志。本文将详细介绍如何在 Elasticsearch 中实现这类查询。

业务场景

假设我们需要检索每天特定时间段(东八区时间 5:00-6:00)的数据,这在以下场景中很常见:

  • 系统监控:查询每天凌晨时段的系统状态
  • 业务分析:统计每天特定时间段的用户活跃度
  • 日志分析:筛选特定时间窗口的错误日志

核心挑战

  • 时区转换:将 UTC 时间转换为东八区时间(UTC+8)
  • 跨天处理:处理时间范围可能跨越午夜的情况
  • 性能优化:使用高效的查询方式避免全表扫描

解决方案

方案一:Script Query(推荐)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
GET /your_index/_search
{
  "query": {
    "script": {
      "script": {
        "source": """
        // 获取 UTC 时间的小时
        def utcHour = doc['timestamp'].value.getHour();
// 转换为东八区时间
def beijingHour = (utcHour + 8) % 24;
// 检查是否在指定时间段内
return beijingHour >= params.startHour && beijingHour < params.endHour;
""",
"params": {
"startHour": 5,
"endHour": 6
}
}
}
}
}

代码解析

Script Query 详解

1
2
3
4
5
6
7
8
// 1. 获取文档中时间字段的小时部分
def utcHour = doc['timestamp'].value.getHour();

// 2. 时区转换:UTC + 8小时 = 东八区时间
def beijingHour = (utcHour + 8) % 24;

// 3. 时间范围判断
return beijingHour >= params.startHour && beijingHour < params.endHour;

关键点说明

  1. 模运算% 24 确保小时值在 0-23 范围内
  2. 参数化:使用 params 提高查询的复用性
  3. 边界处理:使用 >=< 确保时间边界的准确性

性能优化建议

1. 使用索引优化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
PUT /your_index
{
  "mappings": {
    "properties": {
      "timestamp": {
        "type": "date",
        "format": "yyyy-MM-dd HH:mm:ss||epoch_millis"
      },
      "beijing_hour": {
        "type": "integer"
      }
    }
  }
}