在Zed IDE中，默认只支持以下几种 providers :

• Zed AI (Configured by default when signed in)
• Anthropic
• GitHub Copilot Chat 1
• Google AI 1
• Ollama
• OpenAI

这对于国内开发者来说，由于政策原因，想使用起来可能需要借助一些科学上网的方法，这就有点麻烦了。另外国内几个大模型公司也都提供了一定的免费额度的 tokens，如果可以在 Zed 里集成国内几家的大模型，也是一个不错的主意。

几个月前试图通过自定义Endpoint 的方法绕过官方对使用区域的限制，但一直没有成功。今天重新试了一下仍是无效，本想打算在官方仓库里开发一个自定义provider的功能，就是感觉着有点麻烦，另外更担心个人电脑过旧，编译是一个大问题，于是重新在issue里找到了一个解决办法 https://github.com/zed-industries/zed/pull/13276，就是设置起来有点麻烦。

本文将其设置方法整理如下。

配置 settings.json

首先配置 settings.json 里的 assistant 和 language_models 。

这里以 DeepSeek 为例，完整的内容如下

{
  "assistant": {
    "default_model": {
      "provider": "openai",
      "model": "deepseek-chat"
    },
    "enabled": true,
    "provider": {
      "name": "openai",
      "default_model": {
        "custom": {
          "max_tokens": 32000,
          "name": "deepseek-chat"
        }
      },
      "available_models": [
        {
          "custom": {
            "name": "deepseek-chat",
            "max_tokens": 32000
          }
        },
        {
          "custom": {
            "name": "deepseek-code",
            "max_tokens": 32000
          }
        }
      ],
      "api_url": "https://api.deepseek.com/v1"
    },
    "version": "2"
  },
  "language_models": {
    "openai": {
      "version": "1",
      "api_url": "https://api.deepseek.com/v1",
      "available_models": [
        {
          "provider": "openai",
          "name": "deepseek-chat",
          "max_tokens": 32000
        },
        {
          "provider": "openai",
          "name": "deepseek-code",
          "max_tokens": 32000
        }
      ]
    }
  },
}

上面有些配置项看起来是重复的，这个不用管它，不要做任何删除操作，将其复制到 settings.json 文件里代替原来的配置项即可。其中 assistant.default_model 里的值会在后面选择不同模型时动态的更新。

AI Translate 是一款基于LLM实现的IDE专用翻译插件，主要为开发人员在查看项目源码时，可以快速对一些代码英文注释进行中文翻译，这对于英文有些弱的同学很有帮助，下面讲一下为什么开发这款IDE插件，以及它比其它同类翻译插件有什么好处。

为什么开发这款翻译插件

在以前使用IDE看项目源码时，经常遇到长段的英文段落注释信息，理解起来经常会吃力。当时找了一些翻译插件，但都感觉多多少少有些缺陷。

主要表现以下几点：

1. 翻译质量差，有些翻译软件可能将一些专业术语翻译成了其它名词，整体翻译后的语句读起来很让人头疼
2. 由于在源码文件里，多数源码说明 信息都是以注释方式出现的，多数翻译软件无法做到忽略注释符后连贯起来翻译。
3. 目前市面比较好用的翻译插件“沉浸式翻译”，可惜只支持浏览器，并不支持IDE

曾有一段时间的做法是手动从IDE里复制信息、删除注释符、重新整理段落，再到网页翻译里进行翻译，有时翻译的效果不太好，可能同时会用两个翻译软件。

去年看kubernets源码时，再次被折腾一番，当时花了两三个小时开发了一款基于chrome浏览器的插件，主要实现功能是在软件翻译前，将注释符移除和重新整理段落，这样效果稍微好一些，毕竟节省了不少时间，只是仍未解决从IDE复制代码再进行翻译的问题。

前段时间看ETCD源码时，再次被这个折腾一番，最终还是决定开发一款IDE翻译插件，正好可以使用LLM来解决以前传统翻译软件翻译质量不太好的问题。主要改进两点，一个是有一些专业术语被翻译成了普通的单词，读起来很无语；另一个是有些单词没有必要翻译成中文，保持原样即可，但翻译软件硬是翻译成了中文。

调研了几款目前市面上流行的插件，好像都不支持IDE的这种翻译功能。

1. 沉浸式阅读插件功能十分强大，即可以使用传统翻译软件，也可以使用LLM进行翻译，只可惜的是当前只有浏览器插件，并不支持IDE的翻译功能。
2. Alibaba的“通义灵码”IDE插件，功能也十分强大，在IDE工具里直接集成LLM，实现用户交互，可惜的只竟然不支持翻译功能

既然没有轮子，那就造一个吧，插件开发也挺简单的，也花不了太多的时间。

JetBrains IDE 插件开发太麻烦了，每次都等于开启两个窗口，内存和CPU几乎吃完了，调试一次运气不好的话，花1个小时也正常，相对来说vscode 插件开发就容易的多了。

实现原理

插件的功能很简单，只做一件事：将用户在IDE里选择的文本信息发送到LLM提供的API接口，然后再将接口返回的信息在IDE控制终端输出。

至于这个翻译功能主要是在LLM应用端通过配置 prompt 来实现的，告诉LLM你是一个技术开发人员，熟练各种开发语言，将收到的信息整理后，翻译中文并输出就可以了。

在LLM端可以配置多种功能，如是否启用“记忆”功能和一些插件，以实现更多的功能。

插件功能

因此可以自定义prompt实现类似的功能，如 程序员变量命名、SQL解释、代码解释等。

如果IDE插件“通义灵码”有翻译功能，则完全满足当前需求了，遗憾就是没有这个翻译功能，这也正是开发这个插件的原因。

支持哪些IDE

目前主要支持 VSCode 编辑器和 JetBrains 公司的IDE产品。

• VSCode：https://marketplace.visualstudio.com/items?itemName=cfanbo.ai-translate (GitHub)
• JetBrains Marketplace: https://plugins.jetbrains.com/plugin/25313-ai-translate (GitHub)

使用教程

使用插件前，需要填写通义千问应用的 APPID 和 APPKEY，如果还没有开通的话，需要开通后(https://bailian.aliyun.com/)，创建应用后可获取这两项信息。

使用方法很简单，共两步：

1. 在 IDE 里选择要翻译的内容，一般指注释信息
2. 右键选择“AI 翻译“ 菜单即可，也可以使用快捷键 Ctrl+Alt+T

如果使用的是 JetBrains 系统IDE的话，注意快捷键是否有冲突，可以自行设置快捷键。

为了实现翻译的功能，还需要设置应用的prompt ，告诉LLM要实现翻译的功能，这里可以参考github仓库里的 README.md 文档，用户也可以根据需要进行调整。

今年又一次重新学习RUST这门编程语言，并从零开发了一个kv存储系统 minKV，慢慢的越来越有感觉了。

本篇主要将日常学习中收集的一些入门教程进行一下汇总，希望对于一些想学习这门开发语言的同学有所帮助。

下面教程按照推荐顺序，由浅到深依次列出。以下内容将不定期的更新，请自行收藏。 如果您有更多好的教程的话，也可以在评论区列出，大家相互学习。

入门教程

1. Rust 程序设计语言 https://doc.rust-lang.org/book/ / (中文版)

   官方教程，强烈推荐，同时还有非官方翻译的中文版。遗憾的是这个教程有许多概念介绍的都有点不清不楚，只能通过下方的一些资料自行补习。

2. https://play.rust-lang.org/ 在线 RUST 程序 Playground，类似golang的 Playground，非常的方便

3. Rust Language Cheat Sheet 看完官方的教程后，紧接着就看这篇，先了解一些内存布局，后面再看其它教程就更容易理解了

4. The Cargo Book Cargo 是RUST 中的包管理工具，开发必备工具

5. https://rust-lang-nursery.github.io/rust-cookbook/ / (Rust Cookbook 中文版)

6. Rust语言圣经(Rust Course)

7. rust-by-example 在实践中学 Rust

8. Rust By Practice Rust语言实战 / (中文版)

9. 100 Exercises To Learn Rust

10. Comprehensive Rust 由Google 的 Android 团队开发的免费 Rust 课程

11. Tour of Rust

进阶教程

1. Tokio 异步运行时 强烈推荐 ！！！一个强大的运行时，目前市场占有绝对的优势，每个RUST必学
2. Command Line Applications in Rust 开发命令行工具必具。有一个 clap 的crate，它有 Builder 和 Derive 两种用法，本人在开发 gitig 和 minkv 两个项目时分别使用到了这两种用法，推荐使用 Derive 用法，比较简单易理解
3. The Rustonomicon
4. Rust 宏小册
5. Rust and WebAssembly WASM开发手册
6. 深入RUST标准库 国内同学翻译的，不过是两年前翻译的，可能与现在使用的标准库有些差别，不过作为阅读标准库的参考书也不错

开发规范

• Rust API Guidelines
• PingCAP Style Guide

视频教程

如果习惯看视频学习的话，可以看以下列出的一些B站UP主视频，前两个UP主的视频与一些教程是同步的，以视频的形式重新对教程进行了讲解。

上一篇 我们介绍了一些错误处理的最基本的用法，主要是指对 panic! 、unwrap、expect 和 ? 这些宏或函数的介绍。但这仅仅是一些最基本的处理方法，对于自定义错误这一块并没有做任何介绍。

实际开发中可能默认的错误类型，并无法满足我们的业务需求，这时一般需要通过定义自己的错误类型来实现。在rust中错误类型是通过 enum 枚举定义的，对此官方文档也做了一些简介，本文主要介绍一些业务开发过程中对错误的处理方案，当然主要是一些最基本的用法。

自定义 Error

在 Rust 中，自定义错误类型是一种常见的类型，特别是当你需要提供比标准错误类型更具体的错误信息时。Rust 中的错误处理是通过 Result 和 Error trait 来实现的。以下是如何实现一个自定义错误的示例：

1. 定义一个错误枚举类型。
2. 实现 std::fmt::Display 为自定义错误提供用户友好的错误信息。
3. 实现 std::error::Error trait，这通常是通过派生 Error trait 来完成的。

下面是一个简单的示例：

use std::fmt;
use std::error::Error;

// 定义一个自定义错误枚举
#[derive(Debug)]
enum MyError {
    Io(std::io::Error), // 包装标准库的I/O错误
    NotFound(String),    // 一个未找到的错误，包含一个描述信息
    InvalidInput(String), // 无效输入错误，包含一个描述信息
}

// 为自定义错误实现 Display trait
impl fmt::Display for MyError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match *self {
            MyError::Io(ref err) => write!(f, "IO error: {}", err),
            MyError::NotFound(ref desc) => write!(f, "Not found: {}", desc),
            MyError::InvalidInput(ref desc) => write!(f, "Invalid input: {}", desc),
        }
    }
}

// 为自定义错误实现 Error trait
impl Error for MyError {
    fn source(&self) -> Option<&(dyn Error + 'static)> {
        match *self {
            MyError::Io(ref err) => Some(err),
            _ => None,
        }
    }
}

// 使用自定义错误类型的例子
fn do_something_that_might_fail(input: &str) -> Result<(), MyError> {
    if input.is_empty() {
        Err(MyError::InvalidInput("Input cannot be empty".to_string()))
    } else {
        // 假设这里有一些可能失败的操作
        Ok(())
    }
}

fn main() {
    match do_something_that_might_fail("") {
        Ok(_) => println!("Success!"),
        Err(e) => println!("Error occurred: {}", e),
    }
}

在这个示例中，MyError 是一个自定义的错误枚举，它包含了几种可能的错误情况。我们为它实现了 Display 和 Error trait，这样就可以在需要的时候提供错误信息，并且可以与其他错误处理机制无缝集成。在 main 函数中，我们展示了如何使用 do_something_that_might_fail 函数，它可能会返回我们的自定义错误。

gitig 是一款基于 https://github.com/github/gitgnore 仓库开发的.gitignore 客户端CLI 管理工具，也是每个开发者必不可少的提高工作效率的必具工具。

它基于官方仓库 https://github.com/github/gitgnore 丰富的 .gitignore 数据源，帮助开发者快速实现添加各类开发项目的git版本控制忽略文件清单。

开发背景

工作中，经常需要开发各类项目，如基于 vscode 编写 rust 项目，这时为了方便进行Git管理控制，有些项目文件可能并不需要提交到git仓库，需要将一些文件写入 .gitignore 文件进行忽略。

如果手动编辑 .gitignore文件可能有些麻烦，另外也能会有一些文件项被遗忘或写错，这时如果有一些工具可以将行业能用的忽略配置项一键写入 .gitignore 文件似乎是一个不错的主意。

其中著名的 https://github.com/github/gitignore 就是一个专门收集各类开发语句或IDE 需要忽略的 .gitignore 推荐配置的仓库，目前star 已高达 160K，它也是由 GitHub 官方旗下的一个仓库，目前仍在更新。

官方对它的介绍

This is GitHub’s collection of .gitignore file templates. We use this list to populate the .gitignore template choosers available in the GitHub.com interface when creating new repositories and files.

可以看下收集的各种开发语言或ide 推荐忽略文件

gitig就是一款专用解决这个问题的工具，软件安装后自动包含数据源信息，后期随着数据源仓库的更新也会更新发布新版本，它不需要联网支持直接离线操作，只有不到 2M 大小。

功能介绍

对于它的安装方法也很简单，可以参考 https://github.com/cfanbo/gitig.git 介绍，安装完成后，查看版本号

$ gitig -v
gitig v0.0.3-f306ec4

添加配置项

最常用的操作就是将仓库推荐类型的忽略清单添加到本地的 .gitignore 文件，如上面用 vscode 开发 rust 项目，这时就需要将与 VSCode 相关忽略项与 Rust 语言相关忽略项一并添加到本地 .gitignore文件。

Rust 中错误可分为两大类：可恢复的（recoverable）和 不可恢复的（unrecoverable）错误。

对于一个可恢复的错误，比如文件未找到或权限不足的错误，我们很可能只想向用户报告问题，让用户来决定后续操作。

不可恢复的错误总是 bug 出现的征兆，比如试图访问一个超过数组末端的位置，因此我们要立即停止程序，主要通过 panic! 实现。

panic!

panic!属于不可恢复错误类型，一旦发生程序将立即退出。

fn main() {
    panic!("crash and burn");
}

这里由用户调用 panic! 宏来实现程序的中止，同时自定义错误信息。

➜  cargo run
   Compiling hello-world v0.1.0 (/Users/sxf/workspace/rust/hello-world)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.68s
     Running `target/debug/hello-world`
thread 'main' panicked at src/main.rs:2:5:
crash and burn
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

切记：一旦调用 panic! ，程序将立即中止运行，且无法恢复。

至于什么时候使用 panic! ，可参考文档：要不要 panic!

系统默认错误 unwrap

unwrap 底层调用的 panic!，因此也属于不可恢复错误。

调用 unwrap() 获取 Result 中 Ok(value) 的value，如果 Result 的值为 Err，则直接 panic!() 并中止程序。

在 Rust 中有 包、crate、模块 概念，本文我们介绍一下它们之间的关系和调用方法。

包 和 Crate

在Rust中，包（package）是提供一系列功能的一个或者多个 crate。一个包会包含一个 Cargo.toml 文件，阐述如何去构建这些 crate。

我们先看一下通过 cargo new 创建一个 my_project 包。

➜  cargo new my_project   
    Creating binary (application) `my_project` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

➜  rust tree my_project 
my_project
├── Cargo.toml
└── src
    └── main.rs

2 directories, 2 files

它将创建一个 Cargo.toml文件，内容：

[package]
name = "my_project"
version = "0.1.0"
edition = "2021"

[dependencies]

文件里并没有提到 src/main.rs，因为 Cargo 遵循的一个约定：src/main.rs 就是一个与包同名的二进制 crate 的 crate 根。同样的，Cargo 知道如果包目录中包含 src/lib.rs，则包带有与其同名的库 crate，且 src/lib.rs 是 crate 根。crate 根文件将由 Cargo 传递给 rustc 来实际构建库或者二进制项目。

官方文档将一个模块拆分成多个文件时，介绍的是将原来多个模块写在同一个文件中，拆分成了每个模块一个文件。不过还有一种情况没有提到，如果一个模块中的某个 struct 实现代码过多时，仍写在同一个模块文件的话，维护成本就显的比较高了，这时我们可能还需要对这个 struct 的实现按某种粒度拆分成多个文件来实现。

✗ tree
.
├── main.rs
├── model
│   ├── article.rs // 文章相关
│   └── user.rs // 用户相关
└── model.rs

这里是按官方教程拆分后的样子

• article.rs 是文件模块相关实现 -
• user.rs 是与用户相关的实现
• model.rs 公开模块

model.rs

// src/model.rs

pub mod article;
pub mod user;

pub 关键字表示该模块是公开的，可以被其他模块访问。

mod article 声明了一个名为 article 的模块，并且 Rust 编译器会在同文件名的目录下( src/model/ )找到一个名为 article.rs 或者 src/article/mod.rs 的文件来实现这个模块。

文章模块article.rs

// src/model/article.rs
pub struct Article {
    id: u32,
    title: String,
}

impl Article {
    pub fn new(id: u32, title: String) -> Self {
        Article { id, title }
    }

    pub fn info(&self) {
        println!("Article info [id: {}, title: {}]", self.id, self.title);
    }
}

用户模块 user.rs

今天收到一个项目重构的需求，项目源码使用私有 gitlab 托管平台，但由于考虑安全原因，必须通过vpn软件才可以访问。公司用的vpn客户端是 Pritunl, 看了一下项目主页 https://github.com/pritunl/pritunl-client-electron，发现它是一个 OpenVPN 客户端，是基于Golang+Electron 框架开发的一个跨平台的客户端。

以前主要接触的是 wireGuard 和 openvpn 这两个项目，这个客户端还是第一次听说。不过后面发现使用这个客户端会经常出现DNS无法解析的情况，不清楚具体是什么原因引起的，因此不推荐这个客户端。另外从性能方面考虑openvpn也不是推荐方案，推荐优先考虑 wireGuard 这个项目，它的客户端也是跨平台的，而且性能要比openvpn好太多，代码也少很好，无论维护和开发成本都要低的多。个人有很长一段时间一直用wireGuard作为内网穿透方案，不过此方案需要一个公网IP地址，所以后期换成了更节约成本的解决方案，当然这是另一个话题了，不是本文要介绍的内容。

遇到问题

当在macOS上安装好客户端后，使用同事发给我的vpn配置文件，发现一直无法连接到vpn服务器。第一反映就是怀疑是配置文件有问题，但同事反馈一直这样用的，他也是第一次遇到这个情况，所以就排除了配置文件这个原因。

通过查看客户端也并未发现什么原因，一直在重试连接错误。

初步分析

由于以前做零信任网关时，对于网关客户端的流量拦截也是通过vpn这套机制来实现的，因此知道一般会在客户端机器创建一个 tap/tun 虚拟网卡。同时再创建一些路由规则，根据这些规则将需要代理的流量导入到创建的虚拟网卡。然后客户端再从虚拟网卡读取流量内容，然后通过 UDP 协议传到vpn服务端，最后服务端再解包重放从而进入到 vpn服务所在的内网，最终实现流量代理。

虚拟网卡

因此这里首先就要排查本机是否存在tap/tun虚拟网卡，奇怪的是竟然未发现任何虚拟网卡，为什么无法创建虚拟网卡呢？权限问题？正好本机安装有 Cloudflare WARP 这个软件，打开软件测试后，发现本机是可以正常创建 tun 虚拟网卡的，那这样就排除了权限问题了。

路由规则

上面说过vpn的原理，是通过虚拟网卡和路由来配合使用的，路由规则创建了没有？经排查路由规则也没有创建。

客户端版本

难道是客户端版本的原因？咨询了几个同事，版本有的相同，有的不同，但都可以正常连接服务器，并未出现此现象。

openvpn工作原理

由于一直无法找到原因，因此只能还是从vpn工作原理这块入手了。

前面我们知道了虚拟网卡和路由规则都没有创建，那问题会不会出现在前面的一些初始化步骤呢？要确认这一点，首先我们先看一下 openvpn的实现原理：

1. 建立连接：OpenVPN 客户端与服务器之间首先建立一个 TCP 或 UDP 连接。这个连接可以是客户端主动发起，也可以是服务器响应客户端的请求。
2. 身份验证：在连接建立之后，客户端需要通过提供用户名、密码或其他认证方式（如证书）向服务器进行身份验证，以确保连接的合法性。
3. 密钥交换：通过使用密钥交换协议（如 TLS/SSL），客户端和服务器交换密钥，生成一个共享的对称密钥。这个密钥将用于后续的数据加密和解密过程，确保数据的机密性。
4. 数据传输：一旦加密通道建立，客户端和服务器就可以在其中安全地传输数据。数据在发送前会被使用共享密钥进行加密，接收方在收到数据后会使用相同的密钥进行解密。
5. 使用 TUN/TAP 虚拟网络设备：OpenVPN 利用操作系统内核中的虚拟网络设备 TUN/TAP 来转发数据。TUN 工作在网络层，负责 IP 数据包的传输；TAP 工作在数据链路层，负责以太网帧的传输。这些虚拟设备使得 OpenVPN 能够在用户空间处理网络数据。
6. 配置路由：OpenVPN 服务器会为每个客户端分配一个虚拟 IP 地址，并配置相应的路由规则。这样，客户端就成为了虚拟网络的一部分，可以访问服务器所在网络的其他资源。
7. 数据封装：OpenVPN 将网络层的数据封装在 VPN 数据包中，然后通过物理网络发送。在接收端，OpenVPN 将数据解封装，恢复原始数据包，然后通过虚拟网络设备发送给目标。
8. 安全性：OpenVPN 支持多种加密算法（如 AES、DES、3DES 等），并提供了数据完整性检查和抗重放攻击的特性，增强了通信的安全性。

从VPN实现原理得知，我们上面排查的虚拟网卡和路由规则是步骤中的第5和第6步，现在我们只需要对前面这几步进行确认基本就可以找到原因了。

git merge 与 git rebase 的区别

对于两者的区别，网上已经有很多文章做了介绍，不过有些初学者没有亲自实验过，多数也是作为八股文死记硬背而已。本文为了让大家彻底搞懂两者的区别，所以搞了一个实验环境并模拟了一些真实环境的操作。

实验环境主要用到两个分支，其中 main 分支做了主要分支，而 dev 作为开发功能分支。

在生产环境中需要选择合适的分支，这里只是实验环境，所以分支名不是本文关注的重点。

注意实际提交顺序与合并后git log 记录显示的顺序差异：在 git log 中可以看出在 a.txt - e.txt 之间是连续的，尽管在其提交过程中在main分支也进行了一些提交，git log 的最后才将在main分支中的修改追加在 dev 分支历史记录的后面（4.txt 和 5.txt）。 总结一下，就是当一个分支dev 从另一个基分支 main 拆分出来后。当在基分支通过 git rebase 合并分支时，会将被合并分支所有commit id 顺序提交到git log 后面。如果在其间main分支也做了一些commit, 时会在合并之后再追加到后面。因此如果有冲突的话，合并的时候要确认清楚哪些是最新的代码，这个与使用 git merge 命令是不一样，它是基于时间点顺序合并的。

当我们通过域名（例如 www.example.com）访问一个网站时，第一步就是通过DNS服务器找到目的服务器IP地址（例如 93.184.215.14），接着再将请求数据包发送到这个 IP 服务器。

而要想通过 DNS 服务器进行域名，必须得先知道 DNS 服务器地址才行，而这一般是通过读取配置文件实现，在 *nux 操作系统中，DNS 服务器一般配置在 /etc/resolv.conf文件，如

search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

用户可以通过 nameserver 指定多个 DNS 服务器，依次对域名进行解析，如果解析成功，则解析操作立即中止，如果解析不到的话，则将回退到公网 DNS 服务器进行解析，这个公网 DNS 服务器一般是由网络运营商来定的，用户不需要关心。如果公网 DNS 仍解析失败的话，则直接响应域名无法解析，此时用户将无法正常访问域名。

什么是 FQDN

在介绍域名解析前，我们先了解一下什么是 FQDN。它是 Fully Qualified Domain Name 的缩写,中文称为 “完全限定域名”。

一个 FQDN 由以下部分组成:

1. 主机名(Hostname): 如 www、mail、app 等,用于标识特定的主机或服务
2. 域名(Domain Name): 如 example.com、company.org 等,用于标识特定的组织或网络域
3. 根域(Root Domain): 表示为".“的根域,代表 DNS 域名层次结构的根

一个完整的 FQDN 看起来类似这样:

www.example.com.

注意最后的”.“表示根域的结尾。

FQDN 的作用是唯一地标识互联网上的主机名和域名。它能够避免由于域名冲突导致的解析歧义。例如,如果有 www.example.com 和 www.example.net 两个不同的域名,仅使用 www 是不够的,必须使用 FQDN 来精确指定。

动态扩缩容主要包括两个层级的动态扩缩容。一个层级是应用本身级别的扩缩容，如HPA、VPA。当应用负载过高时，可以通过HPA多部署几个Pods副本；或者通过VPA对当前Pod硬件资源进行扩容，以此来减少应用负载。

另一层是对集群自身的扩容，如 worker 节点的扩容。如部署Pods应用时，如果出现无可用节点资源可用时，则通过 Cluster Autoscaler 加入一些新的节点，并在新节点上重建Pods。

本文主要看一下应用这个层级的扩缩容方案。

水平扩展HPA && 垂直扩展VPA

HPA

在 Kubernetes 中，HPA(HorizontalPodAutoscaler)也称为水平扩缩容，它将根据当前应用程序工作负载，自动更新工作负载资源 （例如 Deployment 或者 StatefulSet）以满足当前需求。简单讲的话，就是如果集群检测到当前应用程序的n个Pod负载如果比较高的话，就再创建几个Pod副本，以减少当前负载，也就是我们平时说的水平扩容。相反如果应用程序Pod负载比较低的话，则将Pod副本数量进行减少，节省服务器资源，这个就是水平缩容。

它的工作原理是这样的，集群控制器会定期（默认每 30 秒）查询目标资源的 Pod 的资源使用情况，并将其与 HPA 对象中指定的指标进行比较。如果资源使用情况超过或低于目标指标，HPA 控制器会根据扩缩容策略来扩缩容 Pod 数量。

Kubernetes 默认支持根据容器的 CPU 和内存的使用率。拿下面例子来说

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 80

这里 scaleTargetRef 表示要操作的 Kind 对象 Deployment，其中副本最小数量为1，最大为10。而对条件的定义就是 metrics字段，这个示例里只指定了CPU，表示当 CPU 平均使用率达到80% 的时候就开始扩容。

可以看到其使用方法比较简单。

另外也可以对扩缩容行为进行定义，如

behavior:
  scaleDown:
    policies:
    - type: Pods
      value: 4
      periodSeconds: 60
    - type: Percent
      value: 10
      periodSeconds: 60

这里只对 scaleDown 缩容行为进行了定义，一共有两个策略。第一个策略（Pods）允许在一分钟内最多缩容 4 个副本，第二个策略（Percent） 允许在一分钟内最多缩容当前副本个数的百分之十。

Kubernetes 中的 overlay 网络和 underlay 网络是两个不同的网络层面。

Underlay 网络

在 Kubernetes 网络架构中，Underlay 网络是指承载 Kubernetes 网络流量的物理网络或底层网络。这个网络通常由物理交换机、路由器和其他网络硬件组成，它们之间通过各种路由协议（例如 OSPF、BGP 等）连接在一起组成的传统网络。

Underlay 网络负责为 Kubernetes 节点提供基本的网络连接，它为上层的 overlay 网络提供支持。

总之，Kubernetes 的网络流量，例如 Pod 到 Pod、Pod 到 Service 等都将在这个 Underlay 网络上进行传输。

Overlay 网络

对于 Overlay 网络也被称为 覆盖网络，想必只要接触过一点 kubernetes 网络知识的同学都不陌生，它主用来解决 不同节点 中 Pod 之间通讯的一种网络解决方案。

在上图可以看到 Overlay 网络是构建在 underlay 网络之上的一层虚拟网络，它通过封装数据包（如VXLAN）通过物理网络进行传输，到达目标网络后再对数据包进行解包得出真正的目标地址，最后响应数据包原路返回，从而实现跨网段的网络通讯。

它就像创建了一个逻辑网络，可以实现跨越不同节点和集群实现网络正常通讯，但有一个前提是对于 overlay 网络要求节点网络三层互通。对于 overlay 不好的一点是存在封装、解封装过程，带来一定性能损耗，也因此各大云厂商均大力发展 underlay容器网络，使得容器网络具有直通能力，比如ELB直通容器，容器直接绑eip等。

常见的 overlay 网络有 Flannel、Calico、Weave 等。

总之，Overlay 网络为 Kubernetes 集群中的 Pod 提供 IP 地址,并实现 Pod 之间的通信。

当我们想将 k8s 集群里的服务向外暴露时，一般是将 k8s service 指定 LoadBalancer类型。目前大多数云厂商会绑定云平台的负载均衡器，并为其分配一个固定的公网 IP 从而向外提供服务。而对于我们自建的 kubernetes 裸机集群则只能选择类似 MetalLB 这类解决方案，这种情况下如何让用户可以通过这个 IP 访问到自建 k8s 的服务呢，本文来分析一下其实现原理。

本文的环境安装了 MetallB，它指定分配 IP Pool 为内网 IP 地址，实验环境为 https://blog.haohtml.com/posts/install-kubernetes-in-raspberry-pi/。

将外部请求流入集群节点

当我们需要访问一台机器时,无论是使用 IP 地址还是域名,最终都需要将其解析为 IP 地址。而要真正建立连接并传输数据,我们必须获取目标 IP 地址对应的 MAC 地址,这是由于 TCP/IP 协议分层机制决定的。

在 TCP/IP 协议栈的链路层,数据是通过封装成数据帧的方式在局域网内传输的。数据帧中包含了目标 MAC 地址,用于标识应该将数据发送到哪个网络设备。因此,如果我们想要与某台机器建立通信,就必须首先知道其 IP 地址对应的 MAC 地址。

而 ARP 协议正是解决这一问题的利器。它通过在局域网内广播 ARP 请求,询问拥有某 IP 地址的主机的 MAC 地址。拥有该 IP 地址的目标主机会作出 ARP 响应,将自身的 IP 地址和 MAC 地址映射关系回复给发送方。发送方就可以基于这个映射关系,构建含有正确目标 MAC 地址的数据帧,并最终通过物理网络将数据传输到目的地。

搞明白了一点，理解起来就简单多了。

这里先贴一下实验环境，k8s master 节点 ip 配置

这里是 arm64 架构，树莓派 4B, 四核八 G 内存 配置，系统为 Ubuntu 22.04.1 LTS

$ uname -a
Linux ubuntu 5.15.0-1049-raspi #52-Ubuntu SMP PREEMPT Thu Mar 14 08:39:42 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

$ cat /etc/issue
Ubuntu 22.04.1 LTS \n \l

环境检查

由于 k8s 会使用 8080 和 6443 这两个端口，因此要保证端口可用，然后禁用 swap。

sudo swapoff -a

最后对安装环境初始化，参考 https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/

安装 Docker

参考 https://docs.docker.com/engine/install/ubuntu/

安装成功后，修改 cgroupdriver 为 systemd，同时为了国内访问 docker 镜像加速，需要设置一下 aliyun 的 docker 镜像地址

sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "registry-mirrors": ["https://gfxrbz51.mirror.aliyuncs.com"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

用 docker info 可以验证镜像是否设置成功。