搜索客，搜索人自己的社区

【搜索客社区日报】第2028期 (2025-04-24）

社区日报 • Se7en 发表了文章 • 0 个评论 • 2916 次浏览 • 2025-04-24 14:41 • 来自相关话题

【搜索客社区日报】第2027期 (2025-04-23）

社区日报 • kin122 发表了文章 • 0 个评论 • 3280 次浏览 • 2025-04-23 16:51 • 来自相关话题

【搜索客社区日报】第2026期 (2025-04-22）

社区日报 • God_lockin 发表了文章 • 0 个评论 • 3269 次浏览 • 2025-04-22 10:09 • 来自相关话题

搜索服务统一治理（跨引擎多个集群监控管理、流量管控、服务编排）【Workshop 第一期 - 北京站】

活动 • INFINI Labs 小助手发表了文章 • 0 个评论 • 3105 次浏览 • 2025-04-21 15:21 • 来自相关话题

【搜索客社区日报】第2025期 (2025-04-21）

社区日报 • Muses 发表了文章 • 0 个评论 • 2898 次浏览 • 2025-04-21 14:23 • 来自相关话题

【搜索客社区日报】第2024期 (2025-04-17）

社区日报 • Se7en 发表了文章 • 0 个评论 • 3289 次浏览 • 2025-04-17 15:34 • 来自相关话题

【搜索客社区日报】第2023期 (2025-04-16）

社区日报 • kin122 发表了文章 • 0 个评论 • 3477 次浏览 • 2025-04-16 13:27 • 来自相关话题

Easysearch Rollup 相比 OpenSearch Rollup 的优势分析

Easysearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 3569 次浏览 • 2025-04-16 11:56 • 来自相关话题

【搜索客社区日报】第2022期 (2025-04-15）

社区日报 • God_lockin 发表了文章 • 0 个评论 • 2426 次浏览 • 2025-04-15 16:59 • 来自相关话题

谈谈 ES 6.8 到 7.10 的功能变迁（1）- 性能优化篇

Elasticsearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 3234 次浏览 • 2025-04-15 11:21 • 来自相关话题

前言

ES 7.10 可能是现在比较常见的 ES 版本。但是对于一些相迭代比较慢的早期业务系统来说，ES 6.8 是一个名副其实的“钉子户”。

借着工作内升级调研的任务东风，我整理从 ES 6.8 到 ES 7.10 ELastic 重点列出的新增功能和优化内容。将分为 6 个篇幅给大家详细阐述。

本系列文章主要针对 Elasticsearch 传统的使用功能和基础的模块，像是集群任务的管理、搜索、聚合还有字段类型这样的功能。对于付费功能或者全新的模块，比如：CCR、机器学习和数据流，这里不去深入探讨。

内容的主要来源于 Elastic [各个版本的发布信息](https://www.elastic.co/cn/blog/category/releases)，这里主要比对 ES 6.8 版本到 7.10 版本的差异，并不一一枚举各个新的功能点出现的时间版本。

下面是第一篇：关于 ES 性能的优化

ES 7.10 的性能优化

集群协调算法升级

基于 Elastic 博客提供的资料，Elasticsearch 7.0 的核心改进在于集群协调层的彻底重构，取代了旧版 Zen Discovery 的局限性，引入更健壮、自动化的分布式共识机制。从理论上来说这次优化有着不少的进步，可以显著提升了高可用性与运维效率

主要的优化点有下面三点：

消除分裂脑（Split Brain）风险：通过自动化计算，确保集群状态更新的安全性。旧版 minimum_master_nodes 的手动配置被移除，避免人为误操作。
提升集群稳定性与恢复速度：节点故障时，集群更快达成一致，减少服务中断窗口。
简化运维复杂度：可以动态扩缩容无需手动调整配置，系统自动管理选举配置。同时提供更清晰的日志和错误提示，加速故障诊断。

| 旧版配置 | ES 7.0 配置 | 作用 |
| ------------------------------------ | ---------------------- | ----------------------------------------- |
| discovery.zen.ping.unicast.hosts | discovery.seed_hosts | 定义初始发现的种子节点列表（IP 或主机名） |
| discovery.zen.minimum_master_nodes | 已移除 | 由系统自动管理法定人数 |

而在优化的原则里，Elastic 更强调安全第一。比如，在半数以上主节点永久丢失的风险场景下，ES 7.0 之前的集群会静默等待恢复，允许通过启动新空节点强制恢复，这样可能会导致数据不一致或丢失。在 Elasticsearch 7.0 以及更高版本中，这种不安全活动受到了更多限制。集群宁愿保持不可用状态，也不会冒这种风险（除非使用 elasticsearch-node 恢复工具）。

这次优化显著降低了人为错误的风险：移除脆弱的手动配置，减少运维使用的理解成本。同时提升关键业务连续性：快速故障恢复与明确的容错机制，能适合更多场景需求。

当然也并不是尽善尽美的，也会存在大集群下投票节点过多导致竞争激烈而[无法选主的问题](https://mp.weixin.qq.com/s/jU8HCEf2E6hkz_1ZVH_GaQ),这种情况下，建议部署独立的主节点，并且可以考虑适当增大 cluster.election.duration 的配置。

Top K 对检索的加速

这里的 Top K 主要是指在普通检索时展示前列的数据 Top K。也就是说 Elasticsearch 7.0 对检索数据的查询性能做了明显的改善。那是做了所有查询场景的提升么？

ELastic 做了这么一个场景假设：如果用户通常只关注搜索结果的第一页，且并不关心具体匹配的文档总数，对于超出一定数量的数据搜索引擎可以展示“超过 10,000 条结果”并提供分页浏览来优化搜索效率。但是在实际过程中用户常在查询中使用高频词（如“the”或“a”），这迫使 Elasticsearch 为大量文档计算评分，明显占用了查询资源的使用，即使这些常见词对相关性排序贡献甚微。
![](https://infinilabs.cn/img/blog ... .5.png)

而现在，Elasticsearch 现在可以跳过那些在早期阶段就被判定为不会进入结果集顶部的低排名记录的评分计算，从而显著提升查询速度。这里主要涉及了 block-max WAND 算法的实现。这是一个复杂且漫长的优化过程，有兴趣的同学可以阅读一下这段[Magic WAND: Faster Retrieval of Top Hits in Elasticsearch](https://www.elastic.co/blog/fa ... x-wand)。
![](https://infinilabs.cn/img/blog ... .6.png)

从 Elastic 的测试结果来看，新算法的优化让 term 查询加速了 3-7 倍。当然从场景背景可以看出，这个优化主要在大数据量下有明显效果（小数据量也不会有太多的日常高频词）。

默认开启 soft-delete 减少 translog

从 Elasticsearch 7.4 开始,副本的数据恢复，不再完全依赖 translog 了,而是通过索引的 soft-delete 特性（Elasticsearch 7.0 起所有新索引默认启用软删除 soft-deletes）。这样就可以缩小 translog 的使用场景，从而 translog 的保留大小也可以减少了。

那原来使用 translog 是什么样的呢？

translog 是 ES 用于保证数据安全性的重要工具。同时副分片进行恢复时，它也起着重要作用，只要副分片待获取的差异数据是在 translog 所保留的数据范围内，就可以只从 trasnlog 复制差异的部分数据，而不用拖取整个分片。在之前的版本中，Elasticsearch 默认会保留 512M 或 12 小时的 translog 用于副本恢复。

那现在使用的 soft-delete 是什么呢？

soft-deletes 是 Lucene 中实现的特性。这个软删除有时候会和 lucene 本身的标记删除概念发生混淆。为了方便理解，我们在这里归纳一下，lucene 实现删除的方式是一种标记删除的方式，而这种标记删除可以分为硬删除和软删除。软删除和硬删除有一个明显的区分点是：硬删除，被删除的文档对应的文档号用索引文件 .liv 来描述。软删除 soft-delete，被标记为删除的文档不使用索引文件.liv 来描述，而是通过索引文件 .dvd .dvm 来描述。

这里再扩展一下，.liv 文件主要实现 fixedbitset 数据结构。而 .dvd .dvm 则组合实现了 docvalue 这种正排数据结构。

正排索引的数据结构助力了 translog 的‘减负’，副本可以相对简便的通过软删除中的数据标记来实现数据恢复的处理。

![](https://infinilabs.cn/img/blog ... .4.png)

相比较简洁高效的位图索引，docvalue 虽然实现了更多的功能，满足更多的场景，也会带来更多的问题。最明显的就是对于 update 操作，会导致 refresh 变得慢，有些压力场景下 refresh 会达到 10s 以上。

数值/日期排序查询加速

Elasticsearch 7.6 版本提升了按日期或数值（即任何存储为有符号 64 位整数（long 类型）的字段）进行排序的查询性能。

这背后的优化原理和之前 top K 使用的 Block-Max WAND 算法有点相似，都是利用算法跳过非竞争性文档来实现加速。

实际效果可能因环境而异，受多种参数影响。在 Elastic 进行的测试场景下，可以达到 35 倍的速度优化。

FST 内存使用迁移到堆外

Elastic 7.3 版本实现了这个优化，是藏在 release note 里的彩蛋。

Also mmap terms index (.tip) files for hybridfs #43150 (issue: #42838)

看似不经意的一行，但是带来效果却不小。FST 从堆内转移到堆外后，JVM 的空间可以空余出很客观的一部分。
![](https://infinilabs.cn/img/blog ... .3.png)

一直以来，ES 堆中常驻内存中占据比重最大是 FST，即 tip(terms index) 文件占据的空间，1TB 索引大约占用 2GB 或者更多的内存，因此为了节点稳定运行，业界通常认为一个节点 open 的索引不超过 5TB。现在，从 ES 7.3 版本开始，将 tip 文件修改为通过 mmap 的方式加载，这使 FST 占据的内存从堆内转移到了堆外由操作系统的 pagecache 管理。

存储字段压缩优化

Elasticsearch 7.10 基于 Apache Lucene 8.7 引入了对存储字段（stored fields）的更高压缩率优化。不管是对于基于 DEFLATE 的 index.codec: best_compression 还是基于 LZ4 的index.codec: default都有不错的表现，在 Elastic 的测试场景下，最大可达到 10%的存储空间减少。

对于数据压缩 lucene 这次主要做了两个优化。
Elastic 研究发现在存储数据的时候，底层的 block 越大，压缩效果越好，因为中间被压缩的重复数据可能越多。但是大块的 block 也可能因为解码重复数据降低查询速度。
block 间通过共享字典来维持检索效率和数据压缩之间的平衡。

2.1. 首先为压缩算法提供一个数据字典，它也可以用于字符串重复数据删除。如果在要压缩的数据流和字典之间有许多重复的字符串，那么最终可以得到更好的压缩比。在解压缩时也通过字典来快速补足。
![](https://infinilabs.cn/img/blog ... .1.png)

2.2. 同时，ES 使用更大的数据块，这些数据块本身被分成一个字典和 10 个子块，这些子块使用这个字典进行压缩。
![](https://infinilabs.cn/img/blog ... .2.png)

而对于实际业务场景中，日志和监控数据的重复率往往会很好，因此在这两个场景中的压缩效果也是最明显的。

小结

当然，除了这几项外，ES 在各个版本中也做了不少优化，比如：调整 search.max_buckets 增加到 65534；Date histogram 聚合性能优化等等。有兴趣的同学可以参照各个版本的 [release highlight](https://www.elastic.co/guide/e ... s.html)

参考资料：
[Save space and money with improved storage efficiency in Elasticsearch 7.10](https://www.elastic.co/blog/sa ... h-7-10)
[Elasticsearch 7.3 的 offheap 原理](https://mp.weixin.qq.com/s/QviC_9ElknSS9kxXSMjjbg)
[Elasticsearch 7.4 的 soft-deletes 是个什么鬼](https://mp.weixin.qq.com/s/_l8JAtqK_NOSP8b7OqSVDg)

推荐阅读
- [谈谈 ES 6.8 到 7.10 的功能变迁（2）- 字段类型篇](https://infinilabs.cn/blog/202 ... part-2)
- [谈谈 ES 6.8 到 7.10 的功能变迁（3）- 查询方法篇](https://infinilabs.cn/blog/202 ... part-3)
- [谈谈 ES 6.8 到 7.10 的功能变迁（4）- 聚合功能篇](https://infinilabs.cn/blog/202 ... part-4)
- [谈谈 ES 6.8 到 7.10 的功能变迁（5）- 任务和集群管理](https://infinilabs.cn/blog/202 ... part-5)
- [谈谈 ES 6.8 到 7.10 的功能变迁（6）- 其他](https://infinilabs.cn/blog/202 ... part-6)
  
  作者：金多安，极限科技（INFINI Labs）搜索运维专家，Elastic 认证专家，搜索客社区日报责任编辑。一直从事与搜索运维相关的工作，日常会去挖掘 ES / Lucene 方向的搜索技术原理，保持搜索相关技术发展的关注。
  原文：https://infinilabs.cn/blog/202 ... rt-1/

【搜索客社区日报】第2021期 (2025-04-14）

社区日报 • Muses 发表了文章 • 0 个评论 • 2517 次浏览 • 2025-04-14 11:22 • 来自相关话题

代理 Elasticsearch 服务：INFINI Gateway VS Nginx

Elasticsearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 3302 次浏览 • 2025-04-11 15:38 • 来自相关话题

![](https://infinilabs.cn/img/blog ... er.png)

INFINI Gateway 简介

[INFINI Gateway](https://infinilabs.cn/products/gateway/) 是一款面向 Elasticsearch 的高性能应用网关，专为提升 Elasticsearch 集群的性能、安全性和可管理性而设计。它作为 Elasticsearch 的前置网关，能够处理所有客户端请求，并将其转发到后端的 Elasticsearch 集群，同时提供丰富的功能来优化请求处理和管理。此外还支持代理 Opensearch、[Easysearch](https://infinilabs.cn/products/easysearch/) 服务。

Nginx 简介

Nginx 是一个高性能的 HTTP 和反向代理服务器，以其高并发处理能力、低内存消耗和稳定性著称，广泛应用于 Web 服务器、负载均衡和反向代理等场景。在 Elasticsearch 的使用场景里，也有小伙伴使用 Nginx 来代理 Elasticsearch 的服务，利用 Nginx 的负载均衡能力，将请求转发到多个 Elasticsearch 节点。

这两个软件都能代理 Elasticsearch 服务，但是他们有什么区别？我们来一起分析分析。

负载均衡

Elasticsearch 是分布式系统，提倡使用 round-robin 方式将请求发送到多个节点。不管是 Nginx 还是 INFINI Gateway 都默认使用 round-boin 方式转发请求，也都支持 weighted round-robin（加权轮询）方式进行请求转发，这点两者相当。

节点自动更新

Elasticsearch 集群可能会遇到添加、删除节点的情况，代理程序能否感知 Elasticsearch 节点的变化将变得非常关键。

在 Nginx 中，所有转发节点的 IP 地址都必须写入到配置文件中。如果 Elasticsearch 集群加入了新的节点进行请求处理，则需要 Nginx 编辑配置文件把新节点的 IP 地址加入其中，然后重启或重载 Nginx 服务，才能将请求分发到新的节点。反之如果有节点下线，也要编辑 Nginx 配置文件并重载服务。

INFINI Gateway 是面向 Elasticsearch 设计的应用网关，具有后端节点发现和更新的功能，能够感知 Elasticsearch 集群节点加入、离开的情况。开启节点发现和更新功能后，Gateway 会定期自动更新节点列表，将请求均匀转发到列表中的节点。可参考之前的[博客](https://infinilabs.cn/blog/202 ... teway/)开启节点自动更新。

⚠️ 注意：INFINI Gateway 默认后端节点发现和更新的功能为关闭状态。

定向转发请求

使用 Elasticsearch 集群的场景多种多样，如果想对转发的节点做进一步控制，可能需要根据不同条件进行节点筛选：

IP 地址
节点角色
节点标签

Nginx

Nginx 支持根据 IP 地址进行转发的，将需要转发的节点 IP 地址写入配置文件即可。

plain upstream es-cluster { server 192.168.56.102:9200; server 192.168.56.102:9201; server 192.168.56.102:9202; } 

但不支持按节点角色、节点标签进行筛选，因为 Nginx 中并没有这种概念。

INFINI Gateway

INFINI Gateway 支持按 IP 地址进行筛选：
不开节点发现：只转发到配置文件指定的节点（IP 地址）
开启节点发现：转发到所有发现的节点

```plain
flow:
- name: cache_first
 filter:
 - elasticsearch:
 elasticsearch: prod
 refresh:
 enabled: true
 interval: 30s
 filter:
 hosts:
 exclude:
 - 192.168.3.201:9200
 include:
 - 192.168.3.202:9200
 - 192.168.3.203:9200
  此外 Gateway 还支持通过节点角色、节点标签筛选转发节点。  plain
 flow:
- name: cache_first
 filter:
 - elasticsearch:
 elasticsearch: prod
 refresh:
 enabled: true
 interval: 30s
 filter:
 tags:
 exclude:
 - temp: cold
 include:
 - disk: ssd
 roles:
 exclude:
 - master
 include:
 - data
 - ingest
```

多种筛选条件可以同时使用，详细信息请查看官方[文档](https://docs.infinilabs.com/ga ... earch/)。

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。
原文：https://infinilabs.cn/blog/202 ... ginx/

【搜索客社区日报】第2020期 (2025-04-11）

社区日报 • Fred2000 发表了文章 • 0 个评论 • 2410 次浏览 • 2025-04-11 11:56 • 来自相关话题

【搜索客社区日报】第2019期 (2025-04-10）

社区日报 • Se7en 发表了文章 • 0 个评论 • 2541 次浏览 • 2025-04-10 22:15 • 来自相关话题

Operator 开发入门系列（一）：Hello World!

默认分类 • INFINI Labs 小助手发表了文章 • 0 个评论 • 2801 次浏览 • 2025-04-10 16:28 • 来自相关话题

背景

我们公司最近计划将产品迁移到 Kubernetes 环境。为了更好地管理和自动化我们的应用程序，我们决定使用 Kubernetes Operator。本系列博客将记录我们学习和开发 Operator 的过程，希望能帮助更多的人入门 Operator 开发。

目标读者

对 Kubernetes 有一定了解的开发人员和运维人员
希望使用 Operator 自动化管理应用程序的人员
对 Go 语言有基本了解的人员

准备工作

在开始之前，你需要准备以下环境：
Go 语言环境 (>= 1.23): Operator 通常使用 Go 语言开发，你需要安装 Go 语言环境。建议使用 Go 1.21 或更高版本。可以从 [https://go.dev/dl/](https://go.dev/dl/) 下载安装包。安装完成后，请配置好 GOPATH 和 PATH 环境变量。
Kubernetes 集群: 你需要一个可用的 Kubernetes 集群来部署和测试 Operator。可以使用 Minikube、Kind 或其他的 Kubernetes 发行版。
kubectl 命令行工具: kubectl 是 Kubernetes 的命令行工具，用于与 Kubernetes 集群交互。请确保你已经安装并配置了 kubectl，并且能够连接到你的 Kubernetes 集群。
Kubebuilder (>= 3.0): Kubebuilder 是一个用于快速构建 Kubernetes Operator 的框架。使用 Kubebuilder 可以简化 Operator 的开发流程，并生成一些必要的代码框架。可以使用以下命令安装 Kubebuilder：

bash cd $HOME/go/bin curl -L -o kubebuilder "<a href="https://go.kubebuilder.io/dl/latest/" rel="nofollow" target="_blank">https://go.kubebuilder.io/dl/latest/</a>$(go env GOOS)/$(go env GOARCH)" chmod +x kubebuilder 

请确保 $HOME/go/bin 目录在你的 PATH 环境变量中。可以运行 kubebuilder version 命令来验证 Kubebuilder 是否安装成功。
Docker (可选): 如果你需要构建 Operator 的 Docker 镜像，你需要安装 Docker。

我的环境是 MacOS(arm64) + Orbstack

什么是 Operator？

简单来说，Operator 是 Kubernetes 的扩展，它利用自定义资源（Custom Resources, CRs）来自动化管理应用程序。Operator 允许我们像管理 Kubernetes 内置资源一样管理复杂的应用程序，例如数据库、消息队列等。

为什么选择 Operator？

Operator 提供了一种声明式的方式来管理应用程序的生命周期，包括部署、升级、备份、恢复等。它可以简化运维流程，提高自动化程度，并确保应用程序的状态符合预期。

我们的第一个 Operator：Hello World

这个 Operator 将监听一个名为 HelloWorld 的自定义资源，并在 Kubernetes 中创建一个 Pod，该 Pod 运行一个简单的 "Hello World" 应用程序。

1. 初始化 Kubebuilder 项目

首先，我们需要使用 Kubebuilder 创建一个新的项目。在你的 GOPATH 目录下创建一个新的目录，例如 hello-world-operator，然后进入该目录，运行以下命令

bash kubebuilder init --domain infini.cloud --repo github.com/infinilabs/hello-world-operator 

这个命令会创建一个新的 Kubebuilder 项目，并生成一些必要的文件和目录。

2. 创建自定义资源（Custom Resource Definition, CRD）

接下来，我们需要定义 HelloWorld 资源的结构。运行以下命令

bash kubebuilder create api --group example --version v1alpha1 --kind HelloWorld 

这个命令会创建一个新的 API 定义，包括 api/v1alpha1/helloworld_types.go 和 controllers/helloworld_controller.go 两个文件。

编辑 api/v1alpha1/helloworld_types.go 文件，修改 HelloWorldSpec 的定义，添加 name 和 message 字段：

go // HelloWorldSpec defines the desired state of HelloWorld type HelloWorldSpec struct { // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster // Important: Run "make" to regenerate code after modifying this file // Name is the name of the HelloWorld resource Name string `json:"name,omitempty"` // Message is the message to be printed by the pod Message string `json:"message,omitempty"` } 

3. 实现 Reconcile 逻辑

编辑 controllers/helloworld_controller.go 文件，实现 Reconcile 函数，创建一个 Pod，该 Pod 运行一个 busybox 镜像，并输出 HelloWorld 资源中定义的 message。

go package controllers import ( "context" "fmt" corev1 "k8s.io/api/core/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" ctrl "sigs.k8s.io/controller-runtime" "sigs.k8s.io/controller-runtime/pkg/client" "sigs.k8s.io/controller-runtime/pkg/log" examplev1alpha1 "github.com/infinilabs/hello-world-operator/api/v1alpha1" ) // HelloWorldReconciler reconciles a HelloWorld object type HelloWorldReconciler struct { client.Client Scheme *runtime.Scheme } //+kubebuilder:rbac:groups=example.com,resources=helloworlds,verbs=get;list;watch;create;update;patch;delete //+kubebuilder:rbac:groups=example.com,resources=helloworlds/status,verbs=get;update;patch //+kubebuilder:rbac:groups=example.com,resources=helloworlds/finalizers,verbs=update //+kubebuilder:rbac:groups=core,resources=pods,verbs=get;list;watch;create;update;patch;delete // Reconcile is part of the main kubernetes reconciliation loop which aims to // move the current state of the cluster closer to the desired state. // For more details, check Reconcile and its Result here: // - <a href="https://pkg.go.dev/sigs.k8s.io/controller-runtime@v0.13.0/pkg/reconcile" rel="nofollow" target="_blank">https://pkg.go.dev/sigs.k8s.io ... ncile</a> func (r *HelloWorldReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { log := log.FromContext(ctx) // 1. Fetch the HelloWorld instance helloWorld := &examplev1alpha1.HelloWorld{} err := r.Get(ctx, req.NamespacedName, helloWorld) if err != nil { if apierrors.IsNotFound(err) { // Object not found, return. Created objects are automatically garbage collected. // For additional cleanup logic use finalizers. log.Info("HelloWorld resource not found. Ignoring since object must be deleted") return ctrl.Result{}, nil } // Error reading the object - requeue the request. log.Error(err, "Failed to get HelloWorld") return ctrl.Result{}, err } // 2. Define the desired Pod pod := &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: helloWorld.Name + "-pod", Namespace: helloWorld.Namespace, Labels: map[string]string{ "app": helloWorld.Name, }, }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Name: "hello-world", Image: "busybox", Command: []string{"sh", "-c", fmt.Sprintf("echo '%s' && sleep 3600", helloWorld.Spec.Message)}, }, }, }, } // 3. Set HelloWorld instance as the owner and controller if err := ctrl.SetControllerReference(helloWorld, pod, r.Scheme); err != nil { log.Error(err, "Failed to set controller reference") return ctrl.Result{}, err } // 4. Check if the Pod already exists found := &corev1.Pod{} err = r.Get(ctx, client.ObjectKey{Name: pod.Name, Namespace: pod.Namespace}, found) if err != nil && apierrors.IsNotFound(err) { log.Info("Creating a new Pod", "Pod.Namespace", pod.Namespace, "Pod.Name", pod.Name) err = r.Create(ctx, pod) if err != nil { log.Error(err, "Failed to create new Pod", "Pod.Namespace", pod.Namespace, "Pod.Name", pod.Name) return ctrl.Result{}, err } // Pod created successfully - return and requeue return ctrl.Result{Requeue: true}, nil } else if err != nil { log.Error(err, "Failed to get Pod") return ctrl.Result{}, err } // 5. Pod already exists - don't requeue log.Info("Skip reconcile: Pod already exists", "Pod.Namespace", found.Namespace, "Pod.Name", found.Name) return ctrl.Result{}, nil } // SetupWithManager sets up the controller with the Manager. func (r *HelloWorldReconciler) SetupWithManager(mgr ctrl.Manager) error { return ctrl.NewControllerManagedBy(mgr). For(&examplev1alpha1.HelloWorld{}). Owns(&corev1.Pod{}). Complete(r) } 

4. 安装 CRD 到 Kubernetes 集群

运行以下命令安装 CRD 到 Kubernetes 集群：

bash make install 

5. 运行 Operator

运行以下命令在本地运行 Operator：

bash make run 

6. 创建 HelloWorld 资源

创建一个名为 my-hello-world.yaml 的文件，内容如下：

yaml apiVersion: example.com/v1alpha1 kind: HelloWorld metadata: name: my-hello-world spec: name: my-hello-world message: "Hello World from Operator!" 

使用 kubectl apply -f my-hello-world.yaml 创建资源。

7. 验证

使用 kubectl get pods 命令查看是否创建了名为 my-hello-world-pod 的 Pod。使用 kubectl logs my-hello-world-pod 查看 Pod 的日志，确认是否输出了 "Hello World from Operator!"。

总结

恭喜你完成了第一个 Operator！虽然这个 Operator 非常简单，但它展示了 Operator 的基本原理：监听自定义资源，并根据资源的状态来管理 Kubernetes 资源。在接下来的系列中，我们将深入探讨 Operator 的更多高级特性。

敬请期待下一篇博客！

作者：罗厚付，极限科技（INFINI Labs）云上产品设计与研发负责人，拥有多年安全风控及大数据系统架构经验，主导过多个核心产品的设计与落地，日常负责运维超大规模 ES 集群（800+节点/1PB+数据）。
原文：https://infinilabs.cn/blog/202 ... rt-1/

通知设置 新通知

发现

活动海报

活动内容

1、搜索服务统一治理

2、流量管控

3、服务编排

参会提示

背景

Easysearch vs OpenSearch

1. 查询体验：标准接口与无缝集成

2. 索引管理：自动化与扩展能力

3. 聚合能力：更广泛的聚合类型支持

4. 性能优化：精细化配置与资源控制

5. 任务管理：批量控制与更高灵活性

实战示例：节点统计 Rollup 配置

总结

关于 Easysearch

前言

ES 7.10 的性能优化

集群协调算法升级

Top K 对检索的加速

默认开启 soft-delete 减少 translog

数值/日期排序查询加速

FST 内存使用迁移到堆外

存储字段压缩优化

小结

推荐阅读

INFINI Gateway 简介

Nginx 简介

负载均衡

节点自动更新

定向转发请求

Nginx

INFINI Gateway

背景

目标读者

准备工作

什么是 Operator？

为什么选择 Operator？

我们的第一个 Operator：Hello World

1. 初始化 Kubebuilder 项目

2. 创建自定义资源（Custom Resource Definition, CRD）

3. 实现 Reconcile 逻辑

4. 安装 CRD 到 Kubernetes 集群

5. 运行 Operator

6. 创建 HelloWorld 资源

7. 验证

总结

活动推荐

热门话题

通知设置新通知