"本文主要介绍 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 的操作除了这一个 …"

"版本号：v1.27.2\nKubernetes 调度程序作为一个进程与其他主组件（例如 API 服务器）一起运行。它与 API 服务器的接口是监视具有空 PodSpec.NodeName 的 Pod，并且对于每个 Pod，它都会发布一个 Binding，指示应将 Pod 调度到哪里。\n调度过程 +-------+ +---------------+ node 1| | +-------+ | +----\u0026gt; | Apply pred. filters | | | | +-------+ | +----+----------\u0026gt;+node 2 | | | +--+----+ | watch | | | | | +------+ | +----------------------\u0026gt;+node 3| +--+---------------+ | +--+---+ | Pods in apiserver| | | +------------------+ | | | | | | +------------V------v--------+ | Priority function | …"

"Ubuntu 22.04.2 LTS ARM64位系统 kubernetes v1.27.2\n以前写过一篇安装教程 https://blog.haohtml.com/archives/30924 ，当时安装的版本是 \u0026lt; v1.24.0 版本，由于k8s 从 v1.24.0 版本开始，弃用了 Dockershim 因此没有办法继续使用 Docker Engine 作为运行时，因此如果还想继续使用旧的运行时的话，则需要安装一个 cri-docker 的软件， 本文主要是介绍（版本 \u0026gt;=v1.24.0 ）继续使用 Docker Engine 的安装方法，这里以最新版本 v1.27.1 为例。\n安装环境初始化 以下内容来自： https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/\n执行下述指令：\ncat \u0026lt;\u0026lt;EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF ​ sudo …"

"源码版本：istio-v1.11.3\n为了方便理解，本文会介绍到 vm 和 容器 两种部署形式的情况，一般会在讲解时提到，因此需要注意当前的部署方式，不过他们的架构是完全一样的。\n架构 pilot 共分两个主要模块，一个是 pilot-agent 用来提供 pod 中的服务发现 客户端，另一个是 polot-discovery 提供服务发现 服务端。\n其中 envoy 和 Istio Agent 就是我们上面所讲的 pilot-agent 模块,其为 数据面 组件，而 Istiod 则为 控制面，模块对应源码见\npilot-agent 对于 polot-agent 它运行在每个pod中 ，并以 sidecar 方式与应用容器运行在同一个pod。如果你使用的是 vm 的话，则可以在当前主机通过 pstree 命令看到进程视图\n# pstree -pu 24530 su(24530)───pilot-agent(24611,istio-proxy)─┬─envoy(24619)─┬─{envoy}(24620) │ ├─{envoy}(24621) │ ├─{envoy}(24622) │ …"

" https://zhuanlan.zhihu.com/p/305982159 https://www.cnblogs.com/wushuai2018/p/16450239.html "