"在 Envoy 中当我们需要对 http_connection_manager 中的请求进行修改时，如添加或删除一个请求header，一般通过 HTTP Filter 过滤器来实现。\n而在Envoy 包含的几十个Filter中，通常会选择 Lua Filter (extensions.filters.http.lua.v3.Lua) 或 Wasm Filter (extensions.filters.http.wasm.v3.Wasm)这两类过滤器。\nLua Filter 与 Wasm Filter 下表是 Lua Filter 与 HTTP Filter 的对比\nLua Filter Wasm Filter 编程语言 Lua，解释型脚本语言 WebAssembly，编译型语言 运行环境 Envoy 内置的 Lua 虚拟机 Envoy 内嵌的 WebAssembly 虚拟机 生态系统 丰富的 Lua 库可供使用 逐渐形成的 WebAssembly 生态系统 性能 较低 较高 安全性 较弱 较强 可移植性 受宿主环境和依赖库限制 平台无关的二进制格式，可在不同环境中运行 在不同的环境 …"

"wasm简介 WebAssembly（Wasm）是一种通用字节码技术，它可以将其他编程语言（如 Go、Rust、C/C++ 等）的程序代码编译为可在浏览器或服务端环境直接执行的字节码程序。\n使用场景 主要有两个使用场景，分别为 浏览器 和 服务端。\n浏览器 wasm最早的出现是为了解决浏览器端的性能问题，让web应用可以达到与本地原生应用类似的性能。\n对于浏览器chrome 采用了v8 javascript引擎，其内置了一个 Wasm Runtime，因此可以实现对 wasm 的支持，这也正是浏览器可以运动wasm的原因。\n服务端 2019 年 3 月，Mozilla 推出了 WebAssembly 系统接口（Wasi），以标准化 WebAssembly 应用程序与系统资源之间的交互抽象，例如文件系统访问、内存管理和网络连接，该接口类似于 POSIX 等标准 API。Wasi 规范的出现极大地扩展了 WebAssembly 的应用场景，使得 Wasm 不仅限于在浏览器中运行，而且可以在服务器端得到应用。同时，平台开发者可以针对特定的操作系统和运行环境提供 Wasi 接口的不同实现，允许 …"

"在 istio 中为了对流量进行有效的管理，一般通过注入的方式将代理 istio-proxy 与应用程序一起位于同一个Pod，然后通过 istio-init initContainer修改 iptables 实现 ingress 或 egress，那么在 istio 中这个注入是如何实现的呢，本节对其实现原理进行一些分析。\n实现原理 在上一节《apiserver 中的webhook开发教程》 我们介绍过admission controller 基本实现原理，由此得知当创建一个资源对象的时候，可以通过定义 ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration 实现在创建的进程中对这些 webhook 进行调用。而 MutatingWebhookConfiguration 则可以对请求的资源进行修改。在istio中的 injection 正是基于此原理实现的。\nwebhook配置 当我们在k8s集群中安装 istio 后，会创建一些资源，如 deployment、service、crd 等\n$ istioctl …"

"本文主要对 terraform 中的 Providers 进行介绍，让刚刚接触 terraform 的用户对其有一个大概的了解，以下内容翻译自：https://developer.hashicorp.com/terraform/language/providers\n什么是 Providers 实践: Try the Perform CRUD Operations with Providers tutorial.\nTerraform 依赖于称为提供商的插件来与云提供商、SaaS 提供商和 其他 API 进行交互。 Terraform 配置必须声明它们需要哪些 providers，以便 Terraform 可以 安装 和 使用 它们。此外，某些提供商在使用之前需要进行配置（例如 端点 URL 或 云区域）。\nProviders 能做什么 每一个 Providers 都会有一组 Terraform 可以管理的 resource types 和或 data sources。如我们经常使用的 docker provider, 它提供了一些 Resources 和 Data sources，使用的 …"

"本文主要介绍 crd controller 的基本开发过程，让每一个刚接触k8s开发的同学都可以轻松开发自己的控制器。\nkubebuilder 简介 kubebuilder 是一个帮助开发者快速开发 kubernetes API 的脚手架命令行工具，其依赖 controller-tools 和 controller-runtime 两个库。其中 controller-runtime 简化 kubernetes controller 的开发，并且对 kubernetes 的几个常用库进行了二次封装， 以简化开发工程。而 controller-tool 主要功能是代码生成。\n下图是使用 kubebuilder 的工作流程图：\n安装 kubebuilder # download kubebuilder and install locally. ➜ curl -L -o kubebuilder \u0026#34;https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH)\u0026#34; ➜ chmod +x kubebuilder …"

"k8s: v1.27.3\n什么是准入控制插件？ 准入控制器 是一段代码，它会在请求通过认证和鉴权之后、对象被持久化之前拦截到达 API 服务器的请求。\n准入控制器可以执行 变更（Mutating） 和或 验证（Validating） 操作。 变更（mutating）控制器可以根据被其接受的请求更改相关对象；验证（validating）控制器则不行。\n准入控制器限制创建、删除、修改对象的请求。 准入控制器也可以阻止自定义动作，例如通过 API 服务器代理连接到 Pod 的请求。 准入控制器不会 （也不能）阻止读取（get、watch 或 list）对象的请求。\n某些控制器既是变更准入控制器又是验证准入控制器。如果两个阶段之一的任何一个控制器拒绝了某请求，则整个请求将立即被拒绝，并向最终用户返回错误。\nKubernetes 1.27 中的准入控制器由下面的列表组成， 并编译进 kube-apiserver 可执行文件，并且只能由集群管理员配置。 在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 它们 …"

"Kubernetes 控制器管理器（kube-controller-manager）是一个守护进程，内嵌随 Kubernetes 一起发布的核心控制回路。 在机器人和自动化的应用中，控制回路是一个永不休止的循环，用于调节系统状态。 在 Kubernetes 中，每个控制器是一个控制回路，通过 API 服务器监视集群的共享状态， 并尝试进行更改以将当前状态转为期望状态。 目前，Kubernetes 自带的控制器例子包括副本控制器、节点控制器、命名空间控制器和服务账号控制器等。\n本文不对 kube-controller-manager 管理的每个控制器的执行原理做介绍，只是从全局观看一下kube-controller-manager 启动每个控制器的整体实现过程。\nk8s: v1.27.3\n文件： cmd/kube-controller-manager/app/controllermanager.go\n控制器选项初始化 // cmd/kube-controller-manager/app/controllermanager.go#L104 func …"

"上一篇 《k8s调度器 kube-scheduler 源码解析》 大概介绍一调度器的内容，提到扩展点的插件这个概念，下面我们看看如何开发一个自定义调度器。\n本文源码托管在 https://github.com/cfanbo/sample-scheduler。\n插件机制 在Kubernetes调度器中，共有两种插件机制，分别为 in-tree 和 out-of-tree。\nIn-tree插件（内建插件）：这些插件是作为Kubernetes核心组件的一部分直接编译和交付的。它们与Kubernetes的源代码一起维护，并与Kubernetes版本保持同步。这些插件以静态库形式打包到kube-scheduler二进制文件中，因此在使用时不需要单独安装和配置。一些常见的in-tree插件包括默认的调度算法、Packed Scheduling等。 Out-of-tree插件（外部插件）：这些插件是作为独立项目开发和维护的，它们与Kubernetes核心代码分开，并且可以单独部署和更新。本质上，out-of-tree插件是基于Kubernetes的调度器扩展点进行开发的。这些插件以独立的二进制文件形 …"

"上一节《GoLand+dlv进行远程调试》我们介绍了如何使用 GoLand 进行远程调试，本节我们就以 kube-apiserver 为例演示一下调试方法。\n服务器环境 作为开发调试服务器，需要安装以下环境\n安装 Golang 环境，国内最好设置 GOPROXY 安装 dlv 调试工具 安装 Docker 环境， 同时安装 containerd 服务（对应官方教程中的 containerd.io 安装包）并设置代理 同步代码(本地) 以下为我们本机环境设置。\n本机下载 kubernetes 仓库\ngit clone --filter=blob:none https://github.com/kubernetes/kubernetes.git 这里指定 –filter=bold:none 可以实现最小化下载\n这里 k8s 项目目录为 /Users/sxf/workspace/kubernetes, 对应远程服务器目录为 /home/sxf/workspace/kubernetes，如图所示\n映射关系配置\n同时选择自动上传 Automatic upload (Always) 菜单，这样以后 …"

"环境\n远程服务器（Linux）：192.168.245.137\n本地（macOS）：GoLand\n目的 远程调试就是使用使用本地 IDE 来调试远程服务器上的服务。本地打断点，调用远程服务的接口。本地就会停在断点。\n为什么需要远程调试呢？主要有以下几点原因：\n运行环境：有时候本机不具备调试环境，如开发的程序依赖太多组件，而这些组件在当前机器并不被支持 性能：一般远程服务器的配置都比较高，编译速度也比较快。而开发机器的配置相对要低一些，每次修改程序都要重新编译，非常的消耗时间。 硬盘空间：编译时产生大量的中间临时文件，多达10个G左右，如果本机硬盘空间不足的话，则根本就没有办法进行本地调试 我这里用的系统是macOS，硬盘只有128G大小，硬盘空间非常的紧张，vmware虚拟机占用了30个G, 在虚拟机里编译时发现期间产生的临时文件达到6个G，硬盘空间已经不远远不够，所以选择使用远程调试这种方式。\n这些调试方式对于k8s 开发者来讲应该比较常见，如 调试 kube-apiserver 组件。\n安装 dlv（远程） 首先我们在远程服务器安装 Golang 环境 和 dlv 命令。\n这里默认 …"

"Ceph 是一个分布式存储系统，其广泛用于云平台，最常见的就是在 k8s 平台中，目前大部分云厂商都会选择 ceph 做为基础设施中的后端存储。\nCeph是高度可靠、易于管理和免费的。Ceph 的力量可以改变您公司的IT基础设施和管理大量数据的能力。Ceph提供了非凡的可扩展性——成千上万的客户端访问PB到EB的数据。Ceph节点利用商品硬件和智能守护进程，Ceph存储集群容纳大量节点，这些节点相互通信以动态复制和重新分发数据。\n简介 对于一个 Ceph 集群至少需要一个 Ceph Monitor、一个 Ceph Manager 和 一个 Ceph OSDs（其个数决定了对象副本的个数）。\nCeph Metadata Server 是运行 Ceph 文件系统客户端所必需的。\n最好的做法是为每个监视器配备一个Ceph管理器，但这不是必须的\nMonitors Ceph Monitor ( ceph-mon) 维护集群状态的映射，包括监视器映射、管理器映射、OSD 映射、MDS 映射和 CRUSH 映射。这些映射是 Ceph 守护进程相互协调所需的关键集群状态。监视器还负责管理守护进程和客户 …"

"上一篇《Kubelet 服务引导流程》我们讲了kubelet的大概引导流程, 本节我们看一下 Plugins 这一块的实现源码。\nversion: v1.27.3\n插件模块入口 入口文件 /pkg/kubelet/kubelet.go中的 NewMainKubelet() 函数，\nfunc NewMainKubelet(kubeCfg *kubeletconfiginternal.KubeletConfiguration,...) (*Kubelet, error) { ... // 插件管理器 /pkg/kubelet/kubelet.go#L811-L814 klet.pluginManager = pluginmanager.NewPluginManager( klet.getPluginsRegistrationDir(), /* sockDir */ kubeDeps.Recorder, ) ... } 这里第一个参数 klet.getPluginsRegistrationDir() 是返回 plugins 所在目录，默认位于kubelet …"

"k8s版本：v1.17.3\n组件简介 kube-proxy是Kubernetes中的一个核心组件之一，它提供了一个网络代理和负载均衡服务，用于将用户请求路由到集群中的正确服务。\nkube-proxy的主要功能包括以下几个方面：\n服务代理：kube-proxy会监听Kubernetes API服务器上的服务和端口，并将请求转发到相应的后端Pod。它通过在节点上创建iptables规则或使用IPVS（IP Virtual Server）进行负载均衡，以保证请求的正确路由。 负载均衡：当多个Pod实例对外提供相同的服务时，kube-proxy可以根据负载均衡算法将请求分发到这些实例之间，以达到负载均衡的目的。它可以基于轮询、随机、源IP哈希等算法进行负载均衡。 故障转移：如果某个Pod实例不可用，kube-proxy会检测到并将其自动从负载均衡轮询中移除，从而保证用户请求不会被转发到不可用的实例上。 会话保持（Session Affinity）：kube-proxy可以通过设置会话粘性（Session Affinity）来将同一客户端的请求转发到同一Pod实例，从而保持会话状态的一致性。 网 …"

"版本：v1.17.3\n入口文件： /cmd/kubelet/kubelet.go\n本文主要是为了通过阅读kubelet启动流程源码，实现对整个kubelet 组件及其服务有所了解，因此许多相关组件服务的运行机制并没有详细介绍，如果有时间的话，可以针对每个组件服务进行详细介绍。\n在k8s中 kubelet 是一个极其重要的组件之一，也是 Kubernetes 里面第二个不可被替代的组件（第一个不可被替代的组件当然是 kube-apiserver）。也就是说，无论如何，都不太建议你对 kubelet 的代码进行大量的改动。保持 kubelet 跟上游基本一致的重要性，就跟保持 kube-apiserver 跟上游一致是一个道理。\nkubelet 本身，也是按照“控制器”模式来工作的。它实际的工作原理，可以用如下所示的一幅示意图来表示清楚。\n可以看到，kubelet 的工作核心，就是一个控制循环，即：SyncLoop（图中的大圆圈）。而驱动这个控制循环运行的事件，包括四种：\nPod 更新事件； Pod 生命周期变化； kubelet 本身设置的执行周期； 定时的清理事件。 所以，跟其他控制器 …"

"在上一篇《Kubelet 服务引导流程》中我们介绍了 kubelet 服务启动的大致流程，其中提到过对 Pod 的管理，这一节将详细介绍一下对Pod的相关操作，如创建、修改、删除等操作。建议先了解一下上节介绍的内容。\n在 kubelet 启动的时候，会通过三种 pod source 方式来获取 pod 信息：\nfile: 这种方式只要针对 staticPod 来处理，定时观察配置文件是否发生变更情况来写入 pod http方式： 就是通过一个http请求一个 URL 地址，用来获取 simple Pod 信息 clientSet: 这种方式直接与 APIServer 通讯，对 pod 进行watch 上面这三种 pod source ，一旦有pod 的变更信息，将直接写入一个 kubetypes.PodUpdate 这个 channel（参考： https://github.com/kubernetes/kubernetes/blob/v1.27.3/pkg/kubelet/kubelet.go#L278-L313），然后由下面我们要讲的内容进行读取消费。\n对于pod 的操作除了这一个 …"