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

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

"\u003cp\u003e上一篇\u003ca href=\"https://blog.haohtml.com/archives/33188\"\u003e《Kubelet 服务引导流程》\u003c/a\u003e我们讲了kubelet的大概引导流程, 本节我们看一下 \u003ccode\u003ePlugins\u003c/code\u003e 这一块的实现源码。\u003c/p\u003e\n\u003cp\u003eversion: v1.27.3\u003c/p\u003e\n\u003ch1 id=\"插件模块入口\"\u003e插件模块入口\u003c/h1\u003e\n\u003cp\u003e入口文件 \u003ccode\u003e/pkg/kubelet/kubelet.go\u003c/code\u003e中的 \u003ccode\u003eNewMainKubelet()\u003c/code\u003e 函数，\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\"\u003e\u003ccode class=\"language-go\" data-lang=\"go\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#66d9ef\"\u003efunc\u003c/span\u003e \u003cspan style=\"color:#a6e22e\"\u003eNewMainKubelet\u003c/span\u003e(\u003cspan style=\"color:#a6e22e\"\u003ekubeCfg\u003c/span\u003e \u003cspan style=\"color:#f92672\"\u003e*\u003c/span\u003e\u003cspan style=\"color:#a6e22e\"\u003ekubeletconfiginternal\u003c/span\u003e.\u003cspan style=\"color:#a6e22e\"\u003eKubeletConfiguration\u003c/span\u003e,\u003cspan style=\"color:#f92672\"\u003e...\u003c/span\u003e) (\u003cspan style=\"color:#f92672\"\u003e*\u003c/span\u003e\u003cspan style=\"color:#a6e22e\"\u003eKubelet\u003c/span\u003e, \u003cspan style=\"color:#66d9ef\"\u003eerror\u003c/span\u003e) {\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e \u003cspan style=\"color:#f92672\"\u003e...\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e \u003cspan style=\"color:#75715e\"\u003e// 插件管理器 /pkg/kubelet/kubelet.go#L811-L814\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e \u003cspan style=\"color:#a6e22e\"\u003eklet\u003c/span\u003e.\u003cspan style=\"color:#a6e22e\"\u003epluginManager\u003c/span\u003e = \u003cspan style=\"color:#a6e22e\"\u003epluginmanager\u003c/span\u003e.\u003cspan style=\"color:#a6e22e\"\u003eNewPluginManager\u003c/span\u003e(\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e \u003cspan style=\"color:#a6e22e\"\u003eklet\u003c/span\u003e.\u003cspan style=\"color:#a6e22e\"\u003egetPluginsRegistrationDir\u003c/span\u003e(), \u003cspan style=\"color:#75715e\"\u003e/* sockDir */\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e \u003cspan style=\"color:#a6e22e\"\u003ekubeDeps\u003c/span\u003e.\u003cspan style=\"color:#a6e22e\"\u003eRecorder\u003c/span\u003e,\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e )\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e \u003cspan style=\"color:#f92672\"\u003e...\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e}\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e这里第一个参数 \u003ccode\u003eklet.getPluginsRegistrationDir() …\u003c/code\u003e\u003c/p\u003e"

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

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

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

"\u003cp\u003e版本号：v1.27.2\u003c/p\u003e\n\u003cp\u003eKubernetes 调度程序作为一个进程与其他主组件（例如 API 服务器）一起运行。它与 API 服务器的接口是监视具有空 \u003ccode\u003ePodSpec.NodeName\u003c/code\u003e 的 Pod，并且对于每个 Pod，它都会发布一个 \u003ccode\u003eBinding\u003c/code\u003e，指示应将 Pod 调度到哪里。\u003c/p\u003e\n\u003ch1 id=\"调度过程\"\u003e调度过程\u003c/h1\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e +-------+\n +---------------+ node 1|\n | +-------+\n |\n +----\u0026gt; | Apply pred. filters\n | |\n | | +-------+\n | +----+----------\u0026gt;+node 2 |\n | | +--+----+\n | watch | |\n | | | …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003eUbuntu 22.04.2 LTS\nARM64位系统\nkubernetes v1.27.2\u003c/p\u003e\n\u003cp\u003e以前写过一篇安装教程 \u003ca href=\"https://blog.haohtml.com/archives/30924\"\u003ehttps://blog.haohtml.com/archives/30924\u003c/a\u003e ，当时安装的版本是 \u003ccode\u003e\u0026lt; v1.24.0\u003c/code\u003e 版本，由于k8s 从 \u003ccode\u003ev1.24.0\u003c/code\u003e 版本开始，弃用了 \u003ccode\u003eDockershim\u003c/code\u003e 因此没有办法继续使用 \u003ccode\u003eDocker Engine\u003c/code\u003e 作为运行时，因此如果还想继续使用旧的运行时的话，则需要安装一个 \u003ccode\u003ecri-docker\u003c/code\u003e 的软件， 本文主要是介绍（版本 \u003ccode\u003e\u0026gt;=v1.24.0\u003c/code\u003e ）继续使用 \u003ccode\u003eDocker Engine\u003c/code\u003e 的安装方法，这里以最新版本 \u003ccode\u003ev1.27.1\u003c/code\u003e 为例。\u003c/p\u003e\n\u003ch2 id=\"安装环境初始化\"\u003e安装环境初始化\u003c/h2\u003e\n\u003cp\u003e以下内容来自： \u003ca href=\"https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/\"\u003ehttps://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e执行下述指令：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\"\u003e\u003ccode class=\"language-shell\" data-lang=\"shell\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ecat \u003cspan style=\"color:#e6db74\"\u003e\u0026lt;\u0026lt;EOF | sudo tee /etc/modules-load.d/k8s.conf\n\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#e6db74\"\u003eoverlay\n\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#e6db74\"\u003ebr_netfilter\n\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#e6db74\"\u003eEOF\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e​\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003esudo …\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e"

"\u003cp\u003e源码版本：istio-v1.11.3\u003c/p\u003e\n\u003cp\u003e为了方便理解，本文会介绍到 \u003ccode\u003evm\u003c/code\u003e 和 \u003ccode\u003e容器\u003c/code\u003e 两种部署形式的情况，一般会在讲解时提到，因此需要注意当前的部署方式，不过他们的架构是完全一样的。\u003c/p\u003e\n\u003ch1 id=\"架构\"\u003e架构\u003c/h1\u003e\n\u003cp\u003e\u003ccode\u003epilot\u003c/code\u003e 共分两个主要模块，一个是 \u003ccode\u003epilot-agent\u003c/code\u003e 用来提供 pod 中的服务发现 \u003ccode\u003e客户端\u003c/code\u003e，另一个是 \u003ccode\u003epolot-discovery\u003c/code\u003e 提供服务发现 \u003ccode\u003e服务端\u003c/code\u003e。\u003cimg src=\"https://blogstatic.haohtml.com/uploads/2023/04/d2b5ca33bd970f64a6301fa75ae2eb22-4.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003cp\u003e其中 \u003ccode\u003eenvoy\u003c/code\u003e 和 \u003ccode\u003eIstio Agent\u003c/code\u003e 就是我们上面所讲的 \u003ccode\u003epilot-agent\u003c/code\u003e 模块,其为 \u003ccode\u003e数据面\u003c/code\u003e 组件，而 \u003ccode\u003eIstiod\u003c/code\u003e 则为 \u003ccode\u003e控制面\u003c/code\u003e，模块对应源码见\u003c/p\u003e\n\u003ch1 id=\"pilot-agent\"\u003epilot-agent\u003c/h1\u003e\n\u003cp\u003e对于 \u003ccode\u003epolot-agent\u003c/code\u003e 它运行在每个pod中 ，并以 \u003ccode\u003esidecar\u003c/code\u003e 方式与应用容器运行在同一个pod。如果你使用的是 \u003ccode\u003evm\u003c/code\u003e 的话，则可以在当前主机通过 \u003ccode\u003epstree\u003c/code\u003e 命令看到进程视图\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e# pstree -pu 24530\nsu(24530)───pilot-agent(24611,istio-proxy)─┬─envoy(24619)─┬─{envoy}(24620) …\u003c/code\u003e\u003c/pre\u003e"

"\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://zhuanlan.zhihu.com/p/305982159\"\u003ehttps://zhuanlan.zhihu.com/p/305982159\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.cnblogs.com/wushuai2018/p/16450239.html\"\u003ehttps://www.cnblogs.com/wushuai2018/p/16450239.html\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"

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

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

"\u003cp\u003e\u003ca href=\"https://blog.haohtml.com/archives/32108\"\u003e上一节\u003c/a\u003e 我们大概介绍了一下Envoy中有关速率限制（限流）的一些内容，这一节我们看一下对于外部的 gRPC限流服务它又是如何工作和配置的。\u003c/p\u003e\n\u003cp\u003e在 Envoy 中对服务限流的配置除了可以在 Envoy 本身中实现外，还可以在通过外部服务实现，此时 Envoy 将通过 gRPC 协议调用外部限流服务，官方对此实现有一套现成的解决方案，主要是redis数据库+令牌桶算法实现，可参考官方\u003c/p\u003e\n\u003cp\u003e本文中的限制器或限流器均是同一个意思。\u003c/p\u003e\n\u003ch1 id=\"envoy-实现限流\"\u003eEnvoy 实现限流\u003c/h1\u003e\n\u003cp\u003e此实现是基于令牌桶算法实现，本身比较的简单，比较适合一般的使用场景。\u003c/p\u003e\n\u003cp\u003e这里是官方提供的一个配置\u003ca href=\"https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/local_rate_limit_filter#example-configuration\"\u003e示例\u003c/a\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e13         http_filters:\n14         - name: envoy.filters.http.local_ratelimit\n15           typed_config:\n16             \u0026#34;@type\u0026#34;: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit\n17 …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e在 Envoy 架构中 \u003ca href=\"https://www.envoyproxy.io/docs/envoy/latest/configuration/other_features/rate_limit#config-rate-limit-service\"\u003eRate limit service\u003c/a\u003e 共支持 \u003ca href=\"https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting#arch-overview-global-rate-limit\"\u003eglobal rate limiting\u003c/a\u003e 和 \u003ca href=\"https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/local_rate_limiting#arch-overview-local-rate-limit\"\u003elocal rate limit filter\u003c/a\u003e 两种速率限制。推荐使用 \u003ca href=\"https://github.com/envoyproxy/ratelimit\"\u003ehttps://github.com/envoyproxy/ratelimit\u003c/a\u003e 库。\u003c/p\u003e\n\u003ch1 id=\"global-rate-limiting\"\u003eGlobal rate limiting\u003c/h1\u003e\n\u003cp\u003eEnvoy 提供了两种全局限速实现\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e每个连接 或 每个HTTP请求 速率限制检查。\u003c/li\u003e\n\u003cli\u003e基于配额，具有定期负载报告，允许在多个 Envoy 实例之间公平共享全局速率限制。此实现适用于每秒请求负载较高的大型 Envoy 部署，这些负载可能无法在所有 Envoy 实例之间均匀平衡。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"per-connection-or-per-http-request-rate-limiting\"\u003ePer connection or per HTTP request rate limiting\u003c/h2\u003e\n\u003cp\u003eEnvoy 直接与全局 gRPC rate limiting service 集成， …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"%5Bhttps://ohmyz.sh%5D(https://link.zhihu.com/?target=https%3A//ohmyz.sh/)\"\u003eoh-my-zsh\u003c/a\u003e 是一款非常不错的shell配置，最近几年一直是重度用户。由于一些原因经常登录一些服务器，这里根据自己的习惯做一个笔记，以后不用每一次都要重新从各个地方找安装脚本了。\u003c/p\u003e\n\u003ch1 id=\"安装-zsh\"\u003e安装 zsh\u003c/h1\u003e\n\u003ch2 id=\"安装zsh\"\u003e安装zsh\u003c/h2\u003e\n\u003cp\u003e一般系统默认的都是\u003ccode\u003ebash\u003c/code\u003e，所以我们先安装 \u003ccode\u003ezsh\u003c/code\u003e。如果不清楚当前使用的哪一类shell的，可通过以下命令查看\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e$ cat $SHELL\n/bin/bash\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e我这里使用的默认shell。根据平台选择相应的安装zsh命令, 我这里是Ubuntu系统。\u003c/p\u003e\n\u003cp\u003eLinux、Debian平台\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003esudo apt install -y zsh\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003emacOS\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ebrew install zsh\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eCentos/RHE\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003esudo yum update \u0026amp;\u0026amp; sudo yum -y install zsh\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"确认版本\"\u003e确认版本\u003c/h2\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e$ zsh --version\nzsh 5.8.1 (aarch64-unknown-linux-gnu)\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e查看 \u003ccode\u003e/etc/shell\u003c/code\u003e 看是否存在zsh\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e$ cat /etc/shells\n/bin/sh\n/bin/bash\n/usr/bin/bash\n/bin/rbash …\u003c/code\u003e\u003c/pre\u003e"