"在 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 …"