"上一篇《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 "

"本文主要介绍有关 client go 架构实现原理，在整个client-go架构中有一个很重要的组件就是 informer，本节我们重点对其进行一些介绍。\nInformer 机制 采用 k8s HTTP API 可以查询集群中所有的资源对象并 Watch 其变化，但大量的 HTTP 调用会对 API Server 造成较大的负荷，而且网络调用可能存在较大的延迟。除此之外，开发者还需要在程序中处理资源的缓存，HTTP 链接出问题后的重连等。为了解决这些问题并简化 Controller 的开发工作，K8s 在 client go 中提供了一个 informer 客户端库，可以视其为一个组件。\n在 Kubernetes 中，Informer 可以用于监视 Kubernetes API 服务器中的资源并将它们的当前状态缓存到本地(index -\u0026gt; store) ，这样就避免了客户端不断地向 API 服务器发送请求，直接从本地即可。\n相比直接采用 HTTP Watch，使用 Kubernetes Informer 有以下优势：\n减少 API 服务器的负载：通过在本地缓存资源信 …"

"当用户发起一个网络请求时，流量会通过默认的网卡接口流出与流入，但有时需要将流量通过指定的网卡进行流出流入，这时我们可能需要进行一些额外的开发工作，对其实现主要用到了 Dialer.Control 配置项。\ntype Dialer struct { ​ // If Control is not nil, it is called after creating the network // connection but before actually dialing. // // Network and address parameters passed to Control method are not // necessarily the ones passed to Dial. For example, passing \u0026#34;tcp\u0026#34; to Dial // will cause the Control function to be called with \u0026#34;tcp4\u0026#34; or \u0026#34;tcp6\u0026#34;. Control func(network, …"

"上一节 我们大概介绍了一下Envoy中有关速率限制（限流）的一些内容，这一节我们看一下对于外部的 gRPC限流服务它又是如何工作和配置的。\n在 Envoy 中对服务限流的配置除了可以在 Envoy 本身中实现外，还可以在通过外部服务实现，此时 Envoy 将通过 gRPC 协议调用外部限流服务，官方对此实现有一套现成的解决方案，主要是redis数据库+令牌桶算法实现，可参考官方\n本文中的限制器或限流器均是同一个意思。\nEnvoy 实现限流 此实现是基于令牌桶算法实现，本身比较的简单，比较适合一般的使用场景。\n这里是官方提供的一个配置示例\n13 http_filters: 14 - name: envoy.filters.http.local_ratelimit 15 typed_config: 16 \u0026#34;@type\u0026#34;: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit 17 stat_prefix: http_local_rate_limiter 18 …"

"在 Envoy 架构中 Rate limit service 共支持 global rate limiting 和 local rate limit filter 两种速率限制。推荐使用 https://github.com/envoyproxy/ratelimit 库。\nGlobal rate limiting Envoy 提供了两种全局限速实现\n每个连接 或 每个HTTP请求 速率限制检查。 基于配额，具有定期负载报告，允许在多个 Envoy 实例之间公平共享全局速率限制。此实现适用于每秒请求负载较高的大型 Envoy 部署，这些负载可能无法在所有 Envoy 实例之间均匀平衡。 Per connection or per HTTP request rate limiting Envoy 直接与全局 gRPC rate limiting service 集成， …"

"oh-my-zsh 是一款非常不错的shell配置，最近几年一直是重度用户。由于一些原因经常登录一些服务器，这里根据自己的习惯做一个笔记，以后不用每一次都要重新从各个地方找安装脚本了。\n安装 zsh 安装zsh 一般系统默认的都是bash，所以我们先安装 zsh。如果不清楚当前使用的哪一类shell的，可通过以下命令查看\n$ cat $SHELL /bin/bash 我这里使用的默认shell。根据平台选择相应的安装zsh命令, 我这里是Ubuntu系统。\nLinux、Debian平台\nsudo apt install -y zsh macOS\nbrew install zsh Centos/RHE\nsudo yum update \u0026amp;\u0026amp; sudo yum -y install zsh 确认版本 $ zsh --version zsh 5.8.1 (aarch64-unknown-linux-gnu) 查看 /etc/shell 看是否存在zsh\n$ cat /etc/shells /bin/sh /bin/bash /usr/bin/bash /bin/rbash …"

"在mac上创建了一个ubuntu的虚拟机做为k8s远程开发调试机器，但在编译程序的时候发现磁盘空间不足，于是需要对磁盘进行扩容。\n下面为整个硬盘扩容过程。\n硬盘扩容 首先将虚拟机关机，在 Vmware Fusion 软件上面菜单，点击 Virtual Machine -\u0026gt; Setting 菜单，然后在突出框框里的找到硬盘 Hard Disk ，点击调整硬盘空间大小，然后点击Apply 应用按钮。\n磁盘格式化 查看当前磁盘分区信息\nsxf@vm:~/workspace$ sudo fdisk -l [sudo] password for sxf: Disk /dev/loop0: 63.29 MiB, 66359296 bytes, 129608 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/loop1: …"

"前段时间使用 iptables 的 DNAT 实现一个业务需求的时候，遇到了一些问题这里将其整个过程记录下来。\n需求 这里假设开发机地址为 192.168.3.80，要实现的需求是当用户在开发机访问一个IP地址 192.168.3.196时，将请求转发到另一台机器 192.168.3.58，很明显直接使用 DNAT 来实现即可。\n问题现象 iptables 命令如下\nsudo iptables -t nat -F sudo iptables -t nat -A PREROUTING -d 192.168.3.196 -p tcp --dport 8080 -j DNAT --to-destination 192.168.3.58:8080 sudo iptables -t nat -A POSTROUTING -d 192.168.3.58 -p tcp --dport 8080 -j SNAT --to-source 192.168.3.196:8080 这时在开发机器访问\ncurl http://192.168.3.196:8080 发现提示错误\ncurl: (7) Failed …"