在 Rust 中，闭包就是一种能捕获 上下文环境变量 的函数。 let range = 0..10; let get_range_count = || range.count(); 代码里的这个 get_range_count 就是闭包，range 是被这个闭包捕获的环境变量。 虽然说它是一种函数，但是不通过 fn 进行定义。在 Rust 中，并不把这个闭包的类型处理成 fn 这种函数指针类型，而是有单独的类型定义。 切记这里是将闭包处理成是 单独的类型定义，这一点区别与其它开发语言。 至于按哪一种类型来处理，这个没有办法得知，因为只有在Rust编译器在编译的时候才可以确定其类型，并且在确定类型时，还需要根据这个闭包捕获上下文环境变量时的行为来确定。 闭包trait分类 根据闭包行为划分为三类trait（ 主因是受到所有权影响）： FnOnce 适用于能被调用一次的闭包，所有闭包都至少实现了这个 trait，因为所有闭包都必须能够被调用。一个会将捕获的值移出闭包体的闭包只实现 FnOnce trait，这是因为它只能被调用一次。其获取了上下文环境变量的所有权。 FnMut 适用于不会将捕获的值移出闭包体的闭包，但它可能会修改被捕获的值，这类闭包可以被调用多次。其只获取了上下文环境变量的 &mut 引用。 Fn 适用于既不将被捕获的值移出闭包体也不修改被捕获的值的闭包，当然也包括不从环境中捕获值的闭包。这类闭包可以被调用多次而不改变它们的环境，这在会 多次并发调用闭包的场景中十分重要。其只获取了上下文环境变量的 & 不可变引用。 在编译时会将闭包确定为以上三种类型中的一种或多种组合。 Rust 给我们暴露了 FnOnce、FnMut、Fn 这 3 个 trait，就刚对应上面这三类数据类型。 它们在标准库中的定义为 trait FnOnce<Args> { type Output; fn call_once(self, args: Args) -> Self::Output; } trait FnMut<Args>: FnOnce<Args> { fn call_mut(&mut self, args: Args) -> Self::Output; } trait Fn<Args>: FnMut<Args> { fn call(&self, args: Args) -> Self::Output; } 注意这三者的关系，其中 Fn 继承了 FnMut ，而 FnMut 又继承了 FnOnce，它们三者有层次关系的。

迭代器模式允许你对一个序列的项进行某些处理。迭代器（iterator）负责遍历序列中的每一项和决定序列何时结束的逻辑。当使用迭代器时，我们无需重新实现这些逻辑。 在 Rust 中，迭代器是 惰性的（lazy），这意味着在调用方法使用迭代器之前它都不会有效果。例如，示例中的代码通过调用定义于 Vec 上的 iter 方法在一个 vector v1 上创建了一个迭代器。这段代码本身没有任何用处： let v1 = vec![1, 2, 3]; let v1_iter = v1.iter(); 迭代器被储存在 v1_iter 变量中。一旦创建迭代器之后，可以选择用多种方式利用它。 迭代器分类 Rust 中迭代器根据 所有权 可分为 iter()、iter_mut()、into_iter() 三种迭代器，使用场景： 获取集合元素不可变引用的迭代器，对应方法为 iter() 获取集合元素可变引用的迭代器，对应方法为 iter_mut() 获取集合元素所有权的迭代器，对应方法为 into_iter() 也就是说当你在 Rust 中看到调用了 iter() 方法，则表示这里使用了不可变迭代器，只能读取元素值，无法修改；如果看到 iter_mut() 则表示使用了可变迭代器，您可以对原始值进行修改；而如果看到 into_iter() 的话，则说明使用了集合元素的所有权引用，当迭代器使用完毕后，就对应的内存将自动根据所有权规则被释放回收。 不可变引用迭代器 iter() fn main() { let a = [1, 2, 3]; // 不可变引用迭代器 let mut iter = a.iter(); println!("{:?}", iter.len()); // 当前集合元素个数 // A call to next() returns the next value.

在 Rust 中有两个常用的 enum 枚举类型，分别为 Result 和 Option，本节介绍它们两者各自的使用场景和用法。 这里我们先给出结论 结果 Result 表示 成功 或 失败 选项 Option 表示 有 或者 无 当从本地读取一个文件时，这时候可能读取成功，也有可能由于文件不存在或权限不足导致读取时候，这种场景一般就需要使用 Result；而当从一组数据集中查询指定元素是否存在时，这时有可能存在，也有可能不存在（用None 表示)，这时情况就应该选择Option。 由此看到，这两个枚举类型的区别理解起来还是挺简单的，下面我们单独对每一种类型做一下详细的介绍。 结果 Result 定义 enum Result<T, E> { Ok(T), Err(E), } Result<T, E> 类型拥有两个取值： Ok(value) 表示操作成功，并包装操作返回的 value（value 拥有 T 泛类型）。 Err(why)，表示操作失败，并包装 why，它（但愿）能够解释失败的原因（why 拥有 E 类型）。 举个例子，这里打开一个文件，如果文件存在则打印文件句柄信息，否则打印错误信息，查看 playground use std::fs::File; fn main() { let greeting_file_result = File::open("hello.txt"); // 返回 Result<T, E> let greeting_file = match greeting_file_result { Ok(file) => file, Err(error) => panic!

以前工作中经常需要查看Pod里容器相关信息，特别是容器镜像信息，以前一直是通过 kubectl describe命令查看的 $ kubectl describe my-pod 但由于输出的内容特别多，查看容器关键信息特别麻烦。印象最深的莫过于在部署 istio时，由于国内网络环境不稳定，经常性的遇到镜像下载失败的情况，当时极其的头疼。 于是最近花了一点时间，开发了一款快速查看 Pod 容器信息的插件 kubectr 。 安装 安装方法主要有三种 krew 安装（推荐） $ kubectl krew install ctr 目前已提交到 krew ，但由于官方审核速度较慢，此安装方法不敢保证可用 二进制安装 从 https://github.com/cfanbo/kubectr/releases 下载对应的平台版本，并解压到对应的 PATH 环境变量目录即可。 $ tar zxvf kubectr_linux_amd64.tar.gz $ sudo mv kubectr /usr/local/bin/ $ kubectr -h 源码安装 $ git clone https://github.com/cfanbo/kubectr.git $ make $ bin/kubectr -h 用法 共两种用法，一种是 krew 风格的插件用法 ，另一种是普通命令格式的用法。 krew 插件用法 $ kubectl ctr csi-do-controller-0 -n kube-system NAME READY STATUS RESTARTS AGE PORTS IMAGE PULLPOLICY TYPE csi-provisioner 1 Running 5 (3d21h ago) 3d21h - registry.

在 Envoy 中当我们需要对 http_connection_manager 中的请求进行修改时，如添加或删除一个请求header，一般通过 HTTP Filter 过滤器来实现。 而在Envoy 包含的几十个Filter中，通常会选择 Lua Filter (extensions.filters.http.lua.v3.Lua) 或 Wasm Filter (extensions.filters.http.wasm.v3.Wasm)这两类过滤器。 Lua Filter 与 Wasm Filter 下表是 Lua Filter 与 HTTP Filter 的对比 Lua Filter Wasm Filter 编程语言 Lua，解释型脚本语言 WebAssembly，编译型语言 运行环境 Envoy 内置的 Lua 虚拟机 Envoy 内嵌的 WebAssembly 虚拟机 生态系统 丰富的 Lua 库可供使用 逐渐形成的 WebAssembly 生态系统 性能 较低 较高 安全性 较弱 较强 可移植性 受宿主环境和依赖库限制 平台无关的二进制格式，可在不同环境中运行 在不同的环境中Lua 的行为和功能可能略有差异，特别是在与底层操作系统和硬件交互的方面，而 Wasm 则没有这个问题。 但对于选择哪类 Filter 扩展 Envoy 的过滤器逻辑时，需要根据你的需求和对编程语言的熟悉程度。