kubernetes中overlay网络与underlay网络的区别

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

Underlay 网络

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

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

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

Overlay 网络

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

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

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

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

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

read more

如何实现访问k8s集群服务之原理

当我们想将 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 配置

read more

Raspberry Pi 安装Kubernetes

这里是 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 可以验证镜像是否设置成功。

read more

使用kubectl create service 命令无法为pod创建service问题

在做一个试验时，无意中发现使用 kubectl create service 命令无法为一个通过 deployment 创建出来的pod创建对应的 service， 感觉有点奇怪，经过分析才明白怎么回事，这里将过程记录一下。

这里需要说明一下，本文操作全部是通过 kubectl create 命令来完成的，并没有使用 kubectl apply -f pod.yaml 这种方式。

这里先创建一个实验命名空间 lab

$ kubectl create ns lab

首先创建一个deployment 对象

$ kubectl create deployment test --image=nginx:1.23-alpine --replicas=2 --port=80 -n lab

确认创建成功

$ kubectl get deploy,pod -n lab
NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/test   2/2     2            2           16s

NAME                              DESIRED   CURRENT   READY   AGE
replicaset.apps/test-8544f5598b   2         2         2       16s

NAME                        READY   STATUS    RESTARTS   AGE
pod/test-8544f5598b-7tfq4   1/1     Running   0          16s
pod/test-8544f5598b-d48js   1/1     Running   0          16s

这里我们成功创建了一个 test的 deployment 对象，而由此创建的 Pod.Lables 也都有 app=test 标签对。

read more

pod sandbox 创建netns源码分析

在上一篇《创建Pod源码解析》文中，我们大概介绍了Pod的整体创建过程。其中有一步很重要，就是在创建三类容器之前必须先创建一个 sandbox （源码)，本篇就来分析一下sandbox这一块的 netns 实现过程。

对 sandbox 的创建由 kubelet 组件通过调用 CRI 容器运行时服务来实现的，对于容器运行的实现目前市面上有多个，如 Docker Engine(不推荐)、 containerd、CRI-O 等，由于目前生产环境中选择 containerd 的占大多数，所以这里我们以 containerd 为例来看一下其实现过程。

https://github.com/containerd/containerd/blob/32bf805e5703bc91387d047fa76625e915ac2b80/pkg/cri/server/sandbox_run.go

对 sandbox 的创建是由 cri 服务调用 RunPodSandbox()方法来实现的。

// RunPodSandbox creates and starts a pod-level sandbox. Runtimes should ensure
// the sandbox is in ready state.
func (c *criService) RunPodSandbox(ctx context.Context, r *runtime.RunPodSandboxRequest) (_ *runtime.RunPodSandboxResponse, retErr error) {

  ...
  
  // Save sandbox name
	sandboxInfo.AddLabel("name", name)

  // 初始化 sandbox, 注意此时的 network namespace 未指定
	// Create initial internal sandbox object.
	sandbox := sandboxstore.NewSandbox(
		sandboxstore.Metadata{
			ID:             id,
			Name:           name,
			Config:         config,
			RuntimeHandler: r.GetRuntimeHandler(),
		},
		sandboxstore.Status{
			State: sandboxstore.StateUnknown,
		},
	)

	if _, err := c.client.SandboxStore().Create(ctx, sandboxInfo); err != nil {
		return nil, fmt.Errorf("failed to save sandbox metadata: %w", err)
	}
  
  ...
  
  // Setup the network namespace if host networking wasn't requested.
	if !hostNetwork(config) && !userNsEnabled {
		netStart := time.Now()

		var netnsMountDir = "/var/run/netns"
		if c.config.NetNSMountsUnderStateDir {
			netnsMountDir = filepath.Join(c.config.StateDir, "netns")
		}
    
    // 创建 network namespace! 本文重点关注函数
		sandbox.NetNS, err = netns.NewNetNS(netnsMountDir)
    
    // 指定 network namespace 路径
    // Update network namespace in the store, which is used to generate the container's spec
		sandbox.NetNSPath = sandbox.NetNS.GetPath()
    
    ...

		if err := c.setupPodNetwork(ctx, &sandbox); err != nil {
			return nil, fmt.Errorf("failed to setup network for sandbox %q: %w", id, err)
		}

  }  
}

这里我们了解一个上面提到的 /var/run/netns 这个特殊的目录，以下来自GPT的解释：

By admin

read more

Rust中与闭包相关的三个trait

在 Rust 中，闭包就是一种能捕获 上下文环境变量 的函数。

let range = 0..10;
let get_range_count = || range.count();

代码里的这个 get_range_count 就是闭包，range 是被这个闭包捕获的环境变量。

虽然说它是一种函数，但是不通过 fn 进行定义。在 Rust 中，并不把这个闭包的类型处理成 fn 这种函数指针类型，而是有单独的类型定义。

切记这里是将闭包处理成是 单独的类型定义，这一点区别与其它开发语言。

至于按哪一种类型来处理，这个没有办法得知，因为只有在Rust编译器在编译的时候才可以确定其类型，并且在确定类型时，还需要根据这个闭包捕获上下文环境变量时的行为来确定。

闭包trait分类

根据闭包行为划分为三类trait（ 主因是受到所有权影响）：

  1. FnOnce 适用于能被调用一次的闭包，所有闭包都至少实现了这个 trait，因为所有闭包都必须能够被调用。一个会将捕获的值移出闭包体的闭包只实现 FnOnce trait，这是因为它只能被调用一次。其获取了上下文环境变量的所有权。
  2. FnMut 适用于不会将捕获的值移出闭包体的闭包，但它可能会修改被捕获的值，这类闭包可以被调用多次。其只获取了上下文环境变量的 &mut 引用。
  3. 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，它们三者有层次关系的。

read more

Rust中的迭代器iter

迭代器模式允许你对一个序列的项进行某些处理。迭代器（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...
    assert_eq!(Some(&1), iter.next());
    println!("{:?}", iter.len());

    assert_eq!(Some(&2), iter.next());
    println!("{:?}", iter.len());

    assert_eq!(Some(&3), iter.next());
    println!("{:?}", iter.len());

    // 所有值已迭代完毕，从此以后再调用就是 None
    assert_eq!(None, iter.next());

    // More calls may or may not return `None`. Here, they always will.
    assert_eq!(None, iter.next());
    assert_eq!(None, iter.next());

    // 上面使用了 iter() 获取不可变迭代器，因此可以打印原始变量值
    println!("len={}", iter.len());
    println!("{:?}", iter);
    println!("{:?}", a);
}

首先声明一个包含三个元素的数组，然后使用 iter() 获取不可变引用迭代器，也就是这种迭代器并不影响原来变量 a 的值，这时迭代器元素个数为 3。接着调用三次 iter.next() 读取出下一个元素，并在每次调用后面打印其元素个数，可以看到其个数为递减，走到为 0 为止。

read more

Rust 中的 Result 与 Option

在 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!("Problem opening the file: {:?}", error),
    };
    println!("{:?}", greeting_file);
}

这里File::open 的返回值是 Result<T, E>。泛型参数 T 会被 File::open 的实现放入成功返回值的类型 std::fs::File，这是一个文件句柄。错误返回值使用的 E 的类型是 std::io::Error。这些返回类型意味着 File::open 调用可能成功并返回一个可以读写的文件句柄。

read more

kubectr 一款快速查看Pod容器的kubectl插件

以前工作中经常需要查看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.k8s.io/sig-storage/csi-provisioner:v3.5.0	  IfNotPresent	  container
csi-attacher   	  1    	  Running	  5 (3d21h ago)	  3d21h	  -    	  registry.k8s.io/sig-storage/csi-attacher:v4.3.0   	  IfNotPresent	  container
csi-snapshotter	  1    	  Running	  5 (3d21h ago)	  3d21h	  -    	  registry.k8s.io/sig-storage/csi-snapshotter:v6.2.2	  IfNotPresent	  container
csi-resizer    	  1    	  Running	  5            	  3d21h	  -    	  registry.k8s.io/sig-storage/csi-resizer:v1.8.0    	  IfNotPresent	  container
csi-do-plugin  	  0    	  Waiting	  1672 (3m ago)	  -    	  -    	  digitalocean/do-csi-plugin:v4.7.1                 	  Always      	  container

普通命令用法

$ kubectr ephemeral-demo

NAME          	  READY	  STATUS    	  RESTARTS	  AGE 	  PORTS	  IMAGE                    	  PULLPOLICY  	  TYPE
ephemeral-demo	  1    	  Running   	  0       	  1d4h	  -    	  registry.k8s.io/pause:3.1	  IfNotPresent	  container
debugger-kbm5m	  0    	  Terminated	  0       	  -   	  -    	  busybox:1.28             	  IfNotPresent	  ephemeralContainer

目前插件支持普通 container、initContainer 和 ephemeralContainer三类容器。

read more

envoy中 lua filter 与 wasm filter使用教程

在 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 FilterWasm Filter
编程语言Lua，解释型脚本语言WebAssembly，编译型语言
运行环境Envoy 内置的 Lua 虚拟机Envoy 内嵌的 WebAssembly 虚拟机
生态系统丰富的 Lua 库可供使用逐渐形成的 WebAssembly 生态系统
性能较低较高
安全性较弱较强
可移植性受宿主环境和依赖库限制平台无关的二进制格式，可在不同环境中运行

在不同的环境中Lua 的行为和功能可能略有差异，特别是在与底层操作系统和硬件交互的方面，而 Wasm 则没有这个问题。

但对于选择哪类 Filter 扩展 Envoy 的过滤器逻辑时，需要根据你的需求和对编程语言的熟悉程度。

read more

WebAssembly开发入门教程

wasm简介

WebAssembly（Wasm）是一种通用字节码技术，它可以将其他编程语言（如 Go、Rust、C/C++ 等）的程序代码编译为可在浏览器或服务端环境直接执行的字节码程序。

使用场景

主要有两个使用场景，分别为 浏览器 和 服务端。

浏览器

wasm最早的出现是为了解决浏览器端的性能问题，让web应用可以达到与本地原生应用类似的性能。

Image

对于浏览器chrome 采用了v8 javascript引擎，其内置了一个 Wasm Runtime，因此可以实现对 wasm 的支持，这也正是浏览器可以运动wasm的原因。

服务端

2019 年 3 月，Mozilla 推出了 WebAssembly 系统接口（Wasi），以标准化 WebAssembly 应用程序与系统资源之间的交互抽象，例如文件系统访问、内存管理和网络连接，该接口类似于 POSIX 等标准 API。Wasi 规范的出现极大地扩展了 WebAssembly 的应用场景，使得 Wasm 不仅限于在浏览器中运行，而且可以在服务器端得到应用。同时，平台开发者可以针对特定的操作系统和运行环境提供 Wasi 接口的不同实现，允许跨平台的 WebAssembly 应用程序运行在不同的设备和操作系统上。

Image

开发教程:

运行原理

下面介绍下为什么需要runtime以及常见的运行时有哪些？

为什么需要Runtime

WebAssembly (WASM) 需要运行时环境来提供执行和管理 WASM 模块的功能。下面是一些 wasm 需要运行时的原因：

  1. 跨平台执行：WebAssembly 是一种跨平台的二进制指令集格式，用于在不同的环境中执行。运行时环境负责将 WASM 模块加载到特定的执行环境中，并提供必要的接口和功能，使其能够在不同的操作系统和硬件平台上运行。
  2. 安全性限制：WebAssembly 是一种沙箱化的执行环境，它在运行时提供了严格的安全性限制。运行时负责执行这些限制，以确保 WASM 模块只能访问其限定的资源，并且不能执行恶意操作。
  3. 内存管理：WASM 运行时负责管理线性内存，这意味着它负责分配、释放和管理 WASM 模块的内存资源。运行时提供了合适的内存管理功能，以确保模块运行期间的内存访问的正确性和安全性。
  4. 调用外部功能：WASM 运行时提供了一种机制，使 WASM 模块能够与宿主环境进行交互，并调用外部的功能和服务。运行时环境定义了模块与宿主环境之间的接口和调用约定，使得模块能够访问特定功能，如文件系统、网络连接等。
  5. 性能优化和代码优化：WASM 运行时可以对加载的 WASM 模块进行解析、编译和优化，以提高执行效率和性能。运行时环境可以实现一些优化技术，如即时编译（Just-in-Time Compilation）和调用间内联（Function Inlining），从而使模块的执行更高效。

综上所述，WASM 需要运行时环境来提供必要的功能和接口，以便在跨平台的环境中安全地加载、执行和管理模块。运行时环境扮演了连接 WASM 模块和宿主环境之间的桥梁角色，使得在不同的环境中使用 WASM 变得更加便捷和可靠。

read more

istio 中 sidecar 注入实现原理

在 istio 中为了对流量进行有效的管理，一般通过注入的方式将代理 istio-proxy 与应用程序一起位于同一个Pod，然后通过 istio-init initContainer修改 iptables 实现 ingress 或 egress，那么在 istio 中这个注入是如何实现的呢，本节对其实现原理进行一些分析。

https://istio.io/latest/docs/concepts/security/arch-sec.svg

实现原理

在上一节《apiserver 中的webhook开发教程》 我们介绍过admission controller 基本实现原理，由此得知当创建一个资源对象的时候，可以通过定义 ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration 实现在创建的进程中对这些 webhook 进行调用。而 MutatingWebhookConfiguration 则可以对请求的资源进行修改。在istio中的 injection 正是基于此原理实现的。

webhook配置

当我们在k8s集群中安装 istio 后，会创建一些资源，如 deployment、service、crd 等

$ istioctl install --set profile=demo -y
✔ Istio core installed
✔ Istiod installed
✔ Egress gateways installed
✔ Ingress gateways installed
✔ Installation complete

$ kubectl get deployment -n istio-system
NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
istio-egressgateway    1/1     1            1           126m
istio-ingressgateway   1/1     1            1           126m
istiod                 1/1     1            1           131m

$ kubectl get pod -n istio-system -o wide
NAME                                    READY   STATUS         RESTARTS   AGE    IP            NODE          NOMINATED NODE   READINESS GATES
istio-egressgateway-7b8b76f497-w2xvj    1/1     Running        0          139m   10.244.1.7    kind-worker   <none>           <none>
istio-ingressgateway-7f58d78f47-xfmd7   1/1     Running        0          139m   10.244.1.6    kind-worker   <none>           <none>
istiod-86b84db666-tj7c4                 1/1     Running        0          144m   10.244.1.5    kind-worker   <none>           <none>

同时还为这些 deployment 创建对应的service

By admin

read more

terraform 中的 provider

本文主要对 terraform 中的 Providers 进行介绍，让刚刚接触 terraform 的用户对其有一个大概的了解，以下内容翻译自：https://developer.hashicorp.com/terraform/language/providers

什么是 Providers

实践: Try the Perform CRUD Operations with Providers tutorial.

Terraform 依赖于称为提供商的插件来与云提供商、SaaS 提供商和 其他 API 进行交互。 Terraform 配置必须声明它们需要哪些 providers，以便 Terraform 可以 安装 和 使用 它们。此外，某些提供商在使用之前需要进行配置（例如 端点 URL 或 云区域）。

Providers 能做什么

每一个 Providers 都会有一组 Terraform 可以管理的 resource types 和或 data sources。如我们经常使用的 docker provider, 它提供了一些 Resources 和 Data sources，使用的时候只需要查看一下 provider 提供的有哪些配置直接 。

每个 resouce type 都由 Provider 实现；如果没有Provider的话，Terraform 就无法管理任何类型的基础设施。 大多数提供商配置特定的基础设施平台（云或自托管）。提供商还可以提供本地实用程序来执行诸如为唯一资源名称生成随机数之类的任务。

Providers 来自哪里

providers 与 Terraform 本身分开分发，每个提供程序都有自己的发布节奏和版本号。 Terraform Registry 是公开可用的 Terraform providers，并托管大多数主要基础设施平台的提供程序。

By admin

read more

k8s 中 CRD controller 开发教程

本文主要介绍 crd controller 的基本开发过程，让每一个刚接触k8s开发的同学都可以轻松开发自己的控制器。

kubebuilder 简介

kubebuilder 是一个帮助开发者快速开发 kubernetes API 的脚手架命令行工具，其依赖 controller-tools 和 controller-runtime 两个库。其中 controller-runtime 简化 kubernetes controller 的开发，并且对 kubernetes 的几个常用库进行了二次封装， 以简化开发工程。而 controller-tool 主要功能是代码生成。

下图是使用 kubebuilder 的工作流程图：format%2Cpng

安装 kubebuilder

# download kubebuilder and install locally.
➜ curl -L -o kubebuilder "https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH)"
➜ chmod +x kubebuilder && mv kubebuilder /usr/local/bin/

确认安装成功

➜ kubebuilder version
Version: main.version{KubeBuilderVersion:"3.11.1", KubernetesVendor:"1.27.1", GitCommit:"1dc8ed95f7cc55fef3151f749d3d541bec3423c9", BuildDate:"2023-07-03T13:10:56Z", GoOs:"darwin", GoArch:"amd64"}

相关命令

➜  kubebuilder --help
CLI tool for building Kubernetes extensions and tools.

Usage:
  kubebuilder [flags]
  kubebuilder [command]

Examples:
The first step is to initialize your project:
    kubebuilder init [--plugins=<PLUGIN KEYS> [--project-version=<PROJECT VERSION>]]

<PLUGIN KEYS> is a comma-separated list of plugin keys from the following table
and <PROJECT VERSION> a supported project version for these plugins.

                             Plugin keys | Supported project versions
-----------------------------------------+----------------------------
               base.go.kubebuilder.io/v3 |                          3
               base.go.kubebuilder.io/v4 |                          3
        declarative.go.kubebuilder.io/v1 |                       2, 3
 deploy-image.go.kubebuilder.io/v1-alpha |                          3
                    go.kubebuilder.io/v2 |                       2, 3
                    go.kubebuilder.io/v3 |                          3
                    go.kubebuilder.io/v4 |                          3
         grafana.kubebuilder.io/v1-alpha |                          3
      kustomize.common.kubebuilder.io/v1 |                          3
      kustomize.common.kubebuilder.io/v2 |                          3

For more specific help for the init command of a certain plugins and project version
configuration please run:
    kubebuilder init --help --plugins=<PLUGIN KEYS> [--project-version=<PROJECT VERSION>]

Default plugin keys: "go.kubebuilder.io/v4"
Default project version: "3"

Available Commands:
  alpha       Alpha-stage subcommands
  completion  Load completions for the specified shell
  create      Scaffold a Kubernetes API or webhook
  edit        Update the project configuration
  help        Help about any command
  init        Initialize a new project
  version     Print the kubebuilder version

Flags:
  -h, --help                     help for kubebuilder
      --plugins strings          plugin keys to be used for this subcommand execution
      --project-version string   project version (default "3")

Use "kubebuilder [command] --help" for more information about a command.

初始化项目使用 init 子命令，创建脚手架使用 create 子命令。

By admin

read more

apiserver 中的webhook开发教程

k8s: v1.27.3

什么是准入控制插件？

准入控制器 是一段代码，它会在请求通过认证和鉴权之后、对象被持久化之前拦截到达 API 服务器的请求。

准入控制器可以执行 变更（Mutating） 和或 验证（Validating） 操作。 变更（mutating）控制器可以根据被其接受的请求更改相关对象；验证（validating）控制器则不行。

准入控制器限制创建、删除、修改对象的请求。 准入控制器也可以阻止自定义动作，例如通过 API 服务器代理连接到 Pod 的请求。 准入控制器不会 （也不能）阻止读取（get、watch 或 list）对象的请求。

某些控制器既是变更准入控制器又是验证准入控制器。如果两个阶段之一的任何一个控制器拒绝了某请求，则整个请求将立即被拒绝，并向最终用户返回错误。

Kubernetes 1.27 中的准入控制器由下面的列表组成， 并编译进 kube-apiserver 可执行文件，并且只能由集群管理员配置。 在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 它们根据 API 中的配置， 分别执行变更和验证准入控制 webhook。

参考： https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/

同类型的webhook的顺序无关紧要。

什么是准入 Webhook？

除了内置的 admission 插件， 准入插件可以作为扩展独立开发，并以运行时所配置的 Webhook 的形式运行。 此页面描述了如何构建、配置、使用和监视准入 Webhook。

准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 可以定义两种类型的准入 webhook，即 修改性质的准入 Webhook(Mutating admission) 和 验证性质的准入 Webhook ( Validating admission) 。apiserver-webhook

Mutalting Webhook 会先被调用，它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。

By admin

read more