环境

远程服务器（Linux）：192.168.245.137

本地（macOS）：GoLand

目的

远程调试就是使用使用本地 IDE 来调试远程服务器上的服务。本地打断点，调用远程服务的接口。本地就会停在断点。

为什么需要远程调试呢？主要有以下几点原因：

1. 运行环境：有时候本机不具备调试环境，如开发的程序依赖太多组件，而这些组件在当前机器并不被支持
2. 性能：一般远程服务器的配置都比较高，编译速度也比较快。而开发机器的配置相对要低一些，每次修改程序都要重新编译，非常的消耗时间。
3. 硬盘空间：编译时产生大量的中间临时文件，多达10个G左右，如果本机硬盘空间不足的话，则根本就没有办法进行本地调试

我这里用的系统是macOS，硬盘只有128G大小，硬盘空间非常的紧张，vmware虚拟机占用了30个G, 在虚拟机里编译时发现期间产生的临时文件达到6个G，硬盘空间已经不远远不够，所以选择使用远程调试这种方式。

这些调试方式对于k8s 开发者来讲应该比较常见，如 调试 kube-apiserver 组件。

安装 dlv（远程）

首先我们在远程服务器安装 Golang 环境 和 dlv 命令。

这里默认已经安装好了 Golang 环境，版本为1.20，如果没有安装的话，则需要先安装一下，参考 https://go.dev

安装 dlv 命令参考 https://github.com/go-delve/delve/tree/master/Documentation/installation

# go install github.com/go-delve/delve/cmd/dlv@latest

查看一下 dlv 的用法

# dlv -h
Delve is a source level debugger for Go programs.

Delve enables you to interact with your program by controlling the execution of the process,
evaluating variables, and providing information of thread / goroutine state, CPU register state and more.

The goal of this tool is to provide a simple yet powerful interface for debugging Go programs.

Pass flags to the program you are debugging using `--`, for example:

`dlv exec ./hello -- server --config conf/config.toml`

Usage:
  dlv [command]

Available Commands:
  attach      Attach to running process and begin debugging.
  connect     Connect to a headless debug server with a terminal client.
  core        Examine a core dump.
  dap         Starts a headless TCP server communicating via Debug Adaptor Protocol (DAP).
  debug       Compile and begin debugging main package in current directory, or the package specified.
  exec        Execute a precompiled binary, and begin a debug session.
  help        Help about any command
  run         Deprecated command. Use 'debug' instead.
  test        Compile test binary and begin debugging program.
  trace       Compile and begin tracing program.
  version     Prints version.

Flags:
      --accept-multiclient               Allows a headless server to accept multiple client connections via JSON-RPC or DAP.
      --allow-non-terminal-interactive   Allows interactive sessions of Delve that don't have a terminal as stdin, stdout and stderr
      --api-version int                  Selects JSON-RPC API version when headless. New clients should use v2. Can be reset via RPCServer.SetApiVersion. See Documentation/api/json-rpc/README.md. (default 1)
      --backend string                   Backend selection (see 'dlv help backend'). (default "default")
      --build-flags string               Build flags, to be passed to the compiler. For example: --build-flags="-tags=integration -mod=vendor -cover -v"
      --check-go-version                 Exits if the version of Go in use is not compatible (too old or too new) with the version of Delve. (default true)
      --disable-aslr                     Disables address space randomization
      --headless                         Run debug server only, in headless mode. Server will accept both JSON-RPC or DAP client connections.
  -h, --help                             help for dlv
      --init string                      Init file, executed by the terminal client.
  -l, --listen string                    Debugging server listen address. (default "127.0.0.1:0")
      --log                              Enable debugging server logging.
      --log-dest string                  Writes logs to the specified file or file descriptor (see 'dlv help log').
      --log-output string                Comma separated list of components that should produce debug output (see 'dlv help log')
      --only-same-user                   Only connections from the same user that started this instance of Delve are allowed to connect. (default true)
  -r, --redirect stringArray             Specifies redirect rules for target process (see 'dlv help redirect')
      --wd string                        Working directory for running the program.

Additional help topics:
  dlv backend  Help about the --backend flag.
  dlv log      Help about logging flags.
  dlv redirect Help about file redirection.

Use "dlv [command] --help" for more information about a command.

下面我们会用到 dlv exec 这个命令。

Ceph 是一个分布式存储系统，其广泛用于云平台，最常见的就是在 k8s 平台中，目前大部分云厂商都会选择 ceph 做为基础设施中的后端存储。

Ceph是高度可靠、易于管理和免费的。Ceph 的力量可以改变您公司的IT基础设施和管理大量数据的能力。Ceph提供了非凡的可扩展性——成千上万的客户端访问PB到EB的数据。Ceph节点利用商品硬件和智能守护进程，Ceph存储集群容纳大量节点，这些节点相互通信以动态复制和重新分发数据。

简介

对于一个 Ceph 集群至少需要一个 Ceph Monitor、一个 Ceph Manager 和 一个 Ceph OSDs（其个数决定了对象副本的个数）。

Ceph Metadata Server 是运行 Ceph 文件系统客户端所必需的。

最好的做法是为每个监视器配备一个Ceph管理器，但这不是必须的

Monitors

Ceph Monitor ( ceph-mon) 维护集群状态的映射，包括监视器映射、管理器映射、OSD 映射、MDS 映射和 CRUSH 映射。这些映射是 Ceph 守护进程相互协调所需的关键集群状态。监视器还负责管理守护进程和客户端之间的身份验证。

通常至少需要三个Monitors才能实现冗余和高可用性。

Ceph Manager

Ceph Manager (ceph-mgr) 负责跟踪运行时指标和 Ceph 集群的当前状态，包括存储利用率、当前性能指标和系统负载。Ceph Manager 守护进程还托管基于python的模块来管理和公开Ceph集群信息，包括基于web的 Ceph Dashboard 和 REST API。

通常至少需要两个 Manager 才能实现高可用性。

Ceph OSDs

一个对象存储守护程序（Ceph-OSD）存储数据，处理数据复制、恢复、再平衡，并通过检查其他 Ceph OSD 守护程序的心跳来向 Ceph Monitors 和 Ceph Manager 提供一些监控信息。

上一篇《Kubelet 服务引导流程》我们讲了kubelet的大概引导流程, 本节我们看一下 Plugins 这一块的实现源码。

version: v1.27.3

插件模块入口

入口文件 /pkg/kubelet/kubelet.go中的 NewMainKubelet() 函数，

func 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目录下的 plugins_registry 目录，因此完整的路径为 /var/lib/kubelet/plugins_registry。（这些sock文件是由谁创建的呢？）同时将sock放在子目录里。

const(
    DefaultKubeletPluginsRegistrationDirName = "plugins_registry"
)

func (kl *Kubelet) getPluginsRegistrationDir() string {
    return filepath.Join(kl.getRootDir(), config.DefaultKubeletPluginsRegistrationDirName)
}

第二个参数 kubeDeps.Recorder 是一个事件记录器 EventRecorder ，这里不需要关心。

我们看一下函数 NewPluginManager() 的实现。

// pkg/kubelet/pluginmanager/plugin_manager.go#L54-L80
func NewPluginManager(
    sockDir string,
    recorder record.EventRecorder) PluginManager {
    asw := cache.NewActualStateOfWorld()
    dsw := cache.NewDesiredStateOfWorld()
    reconciler := reconciler.NewReconciler(
        operationexecutor.NewOperationExecutor(
            operationexecutor.NewOperationGenerator(
                recorder,
            ),
        ),
        loopSleepDuration,
        dsw,
        asw,
    )

    pm := &pluginManager{
        desiredStateOfWorldPopulator: pluginwatcher.NewWatcher(
            sockDir,
            dsw,
        ),
        reconciler:          reconciler,
        desiredStateOfWorld: dsw,
        actualStateOfWorld:  asw,
    }
    return pm
}

这里 asw 表示插件实际状态， dsw 表示插件期望状态，而 reconciler 就是用来 reconciler 这里的期望状态与实际状态的。

k8s版本：v1.17.3

组件简介

kube-proxy是Kubernetes中的一个核心组件之一，它提供了一个网络代理和负载均衡服务，用于将用户请求路由到集群中的正确服务。

kube-proxy的主要功能包括以下几个方面：

1. 服务代理：kube-proxy会监听Kubernetes API服务器上的服务和端口，并将请求转发到相应的后端Pod。它通过在节点上创建iptables规则或使用IPVS（IP Virtual Server）进行负载均衡，以保证请求的正确路由。
2. 负载均衡：当多个Pod实例对外提供相同的服务时，kube-proxy可以根据负载均衡算法将请求分发到这些实例之间，以达到负载均衡的目的。它可以基于轮询、随机、源IP哈希等算法进行负载均衡。
3. 故障转移：如果某个Pod实例不可用，kube-proxy会检测到并将其自动从负载均衡轮询中移除，从而保证用户请求不会被转发到不可用的实例上。
4. 会话保持（Session Affinity）：kube-proxy可以通过设置会话粘性（Session Affinity）来将同一客户端的请求转发到同一Pod实例，从而保持会话状态的一致性。
5. 网络代理：kube-proxy还可以实现网络地址转换（NAT）和访问控制列表（ACL）等网络代理功能，通过为集群内的服务提供统一的入口地址和访问策略。

总之 kube-proxy 在Kubernetes集群中扮演着路由和负载均衡的重要角色，为集群内的服务提供可靠的网络连接和请求转发功能。

实现逻辑

组件入口文件为 [cmd/kube-proxy/proxy.go](https://github.com/kubernetes/kubernetes/blob/v1.27.3/cmd/kube-proxy/proxy.go)。

这里我们先介绍一下 options 这个数据结构，它主要有来存储一些配置项

type Options struct {
  // 配置文件路径
  ConfigFile string
​
// 将配置写入到文件
  WriteConfigTo string
​
  // bool值，如果为true,则删除所有iptables/ipvs 规则，然后退出程序
  CleanupAndExit bool

  // WindowsService should be set to true if kube-proxy is running as a service on Windows.
  // Its corresponding flag only gets registered in Windows builds
  WindowsService bool
​
  // KubeProxy configuration配置
  config *kubeproxyconfig.KubeProxyConfiguration
​
  // 监控配置文件对象，fsnotify
  watcher filesystem.FSWatcher

  // proxyServer is the interface to run the proxy server
  proxyServer proxyRun
  // errCh is the channel that errors will be sent
  errCh chan error
​
​
  // master is used to override the kubeconfig's URL to the apiserver.
  master string
  // 服务健康检查 healthServer. 端口号 10256
  healthzPort int32
  // 指标服务器 metrics server. 端口号 10249
  metricsPort int32
​
  // 如果从命令行标志设置，则优先于配置文件中的“HostnameOverride”值
  hostnameOverride string
}

最主要的几个字段

版本：v1.17.3

入口文件： /cmd/kubelet/kubelet.go

本文主要是为了通过阅读kubelet启动流程源码，实现对整个kubelet 组件及其服务有所了解，因此许多相关组件服务的运行机制并没有详细介绍，如果有时间的话，可以针对每个组件服务进行详细介绍。

在k8s中 kubelet 是一个极其重要的组件之一，也是 Kubernetes 里面第二个不可被替代的组件（第一个不可被替代的组件当然是 kube-apiserver）。也就是说，无论如何，都不太建议你对 kubelet 的代码进行大量的改动。保持 kubelet 跟上游基本一致的重要性，就跟保持 kube-apiserver 跟上游一致是一个道理。

kubelet 本身，也是按照“控制器”模式来工作的。它实际的工作原理，可以用如下所示的一幅示意图来表示清楚。

可以看到，kubelet 的工作核心，就是一个控制循环，即：SyncLoop（图中的大圆圈）。而驱动这个控制循环运行的事件，包括四种：

• Pod 更新事件；
• Pod 生命周期变化；
• kubelet 本身设置的执行周期；
• 定时的清理事件。

所以，跟其他控制器类似，kubelet 启动的时候，要做的第一件事情，就是设置 Listers，也就是注册它所关心的各种事件的 Informer。这些 Informer 就是 SyncLoop 需要处理的数据的来源。此外，kubelet 还负责维护着很多很多其他的子控制循环（也就是图中的小圆圈）。这些控制循环的名字，一般被称作某某 Manager，比如 Volume Manager、Image Manager、Node Status Manager 等等。

简单理解就是先通过建立各类 Informer 来建立与 APIServer 的通讯，这样当资源发生变化时，立刻就能感知到，做出相应的处理。

下面我们就从源码来看一下它的实现过程。在 kubelet 中有两个重要的数据结构，一个是 kubeletServer ，另一个是 kubeletDeps 。

配置项 kubeletServer

kubeltServer 封装了启动 kubelet 所需的所有参数，这些可以通过命令行设置，也可以直接设置。

type KubeletServer struct {
    KubeletFlags
    kubeletconfig.KubeletConfiguration
}

它内嵌了两个数据结构，分别为 KubeletFlags 和 KubeletConfiguration 。其中 kubeletFlags 主要是用来接收执行命令时手动指定的参数，而 KubeletConfiguration 则是从配置文件里读取配置信息，其 API 介绍参考 。

在上一篇《Kubelet 服务引导流程》中我们介绍了 kubelet 服务启动的大致流程，其中提到过对 Pod 的管理，这一节将详细介绍一下对Pod的相关操作，如创建、修改、删除等操作。建议先了解一下上节介绍的内容。

在 kubelet 启动的时候，会通过三种 pod source 方式来获取 pod 信息：

1. file: 这种方式只要针对 staticPod 来处理，定时观察配置文件是否发生变更情况来写入 pod
2. http方式： 就是通过一个http请求一个 URL 地址，用来获取 simple Pod 信息
3. 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），然后由下面我们要讲的内容进行读取消费。

对于pod 的操作除了这一个地方可以实现对 pod 的操作，还有l四个地方也可以触发对 pod 的操作。

在启动服务函数 Kubelet.Run(updates <-chan kubetypes.PodUpdate{}) 中参数 updates是一个 kubetypes.PodUpdate的类型，其结构如下

type PodUpdate struct {
    Pods   []*v1.Pod
    Op     PodOperation
    Source string
}

// PodOperation 定义了将对pod配置进行哪些更改。
type PodOperation int

// These constants identify the PodOperations that can be made on a pod configuration.
const (
    // SET is the current pod configuration.
    SET PodOperation = iota
    // ADD signifies pods that are new to this source.
    ADD
    // DELETE signifies pods that are gracefully deleted from this source.
    DELETE
    // REMOVE signifies pods that have been removed from this source.
    REMOVE
    // UPDATE signifies pods have been updated in this source.
    UPDATE
    // RECONCILE signifies pods that have unexpected status in this source,
    // kubelet should reconcile status with this source.
    RECONCILE
)

PodUpdate 定义了一个操作 pod 对象，你可以发送一个 Op == ADD|REMOVE 的Pod切片对象（当REMOVE时，只需要ID）; 如果设置 Op == SET将表示Pod 当前的配置状态（表示未发生任何变化）；如果要移除所有pod，请将pods设置为空对象，将Op设置为SET。

版本号：v1.27.2

Kubernetes 调度程序作为一个进程与其他主组件（例如 API 服务器）一起运行。它与 API 服务器的接口是监视具有空 PodSpec.NodeName 的 Pod，并且对于每个 Pod，它都会发布一个 Binding，指示应将 Pod 调度到哪里。

调度过程

                          +-------+
          +---------------+ node 1|
          |               +-------+
          |
   +----> |  Apply pred. filters
   |      |
   |      |                +-------+
   |      +----+---------->+node 2 |
   |           |           +--+----+
   |  watch    |              |
   |           |              |        +------+
   |           +---------------------->+node 3|
+--+---------------+               |   +--+---+
| Pods in apiserver|               |      |
+------------------+               |      |
                                   |      |
                                   |      |
                      +------------V------v--------+
                      |      Priority function     |
                      +-------------+--------------+
                                    |
                                    | node 1: p=2
                                    | node 2: p=5
                                    v
                               select max{node priority} = node 2

有关调度算法见： https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/scheduler_algorithm.md

Ubuntu 22.04.2 LTS ARM64位系统 kubernetes v1.27.2

以前写过一篇安装教程 https://blog.haohtml.com/archives/30924 ，当时安装的版本是 < v1.24.0 版本，由于k8s 从 v1.24.0 版本开始，弃用了 Dockershim 因此没有办法继续使用 Docker Engine 作为运行时，因此如果还想继续使用旧的运行时的话，则需要安装一个 cri-docker 的软件， 本文主要是介绍（版本 >=v1.24.0 ）继续使用 Docker Engine 的安装方法，这里以最新版本 v1.27.1 为例。

安装环境初始化

以下内容来自： https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/

执行下述指令：

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
​
sudo modprobe overlay
sudo modprobe br_netfilter
​
# 设置所需的 sysctl 参数，参数在重新启动后保持不变
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF
​
# 应用 sysctl 参数而不重新启动
sudo sysctl --system

通过运行以下指令确认 br_netfilter 和 overlay 模块被加载：

源码版本：istio-v1.11.3

为了方便理解，本文会介绍到 vm 和 容器 两种部署形式的情况，一般会在讲解时提到，因此需要注意当前的部署方式，不过他们的架构是完全一样的。

架构

pilot 共分两个主要模块，一个是 pilot-agent 用来提供 pod 中的服务发现 客户端，另一个是 polot-discovery 提供服务发现 服务端。

其中 envoy 和 Istio Agent 就是我们上面所讲的 pilot-agent 模块,其为 数据面 组件，而 Istiod 则为 控制面，模块对应源码见

pilot-agent

对于 polot-agent 它运行在每个pod中 ，并以 sidecar 方式与应用容器运行在同一个pod。如果你使用的是 vm 的话，则可以在当前主机通过 pstree 命令看到进程视图

# pstree -pu 24530
su(24530)───pilot-agent(24611,istio-proxy)─┬─envoy(24619)─┬─{envoy}(24620)
                                           │              ├─{envoy}(24621)
                                           │              ├─{envoy}(24622)
                                           │              ├─{envoy}(24623)
                                           │              ├─{envoy}(24624)
                                           │              ├─{envoy}(24625)
                                           │              ├─{envoy}(24627)
                                           │              ├─{envoy}(24628)
                                           │              ├─{envoy}(24629)
                                           │              ├─{envoy}(24630)
                                           │              └─{envoy}(24635)
                                           ├─{pilot-agent}(24612)
                                           ├─{pilot-agent}(24613)
                                           ├─{pilot-agent}(24614)
                                           ├─{pilot-agent}(24615)
                                           ├─{pilot-agent}(24616)
                                           ├─{pilot-agent}(24617)
                                           ├─{pilot-agent}(24618)
                                           ├─{pilot-agent}(24626)
                                           └─{pilot-agent}(24698)
​

从进程关系可以看到，envoy 属于 pilot-agent 的一个子进程，当前进程以 istio-proxy 用户身份运行。

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

本文主要介绍有关 client go 架构实现原理，在整个client-go架构中有一个很重要的组件就是 informer，本节我们重点对其进行一些介绍。

Informer 机制

采用 k8s HTTP API 可以查询集群中所有的资源对象并 Watch 其变化，但大量的 HTTP 调用会对 API Server 造成较大的负荷，而且网络调用可能存在较大的延迟。除此之外，开发者还需要在程序中处理资源的缓存，HTTP 链接出问题后的重连等。为了解决这些问题并简化 Controller 的开发工作，K8s 在 client go 中提供了一个 informer 客户端库，可以视其为一个组件。

在 Kubernetes 中，Informer 可以用于监视 Kubernetes API 服务器中的资源并将它们的当前状态缓存到本地(index -> store) ，这样就避免了客户端不断地向 API 服务器发送请求，直接从本地即可。

相比直接采用 HTTP Watch，使用 Kubernetes Informer 有以下优势：

• 减少 API 服务器的负载：通过在本地缓存资源信息，Informer 减少了需要向 API 服务器发出的请求数量。这可以防止由于 API 服务器过载而影响整个集群的性能。
• 提高应用程序性能：使用缓存的数据，客户端应用程序可以快速访问资源信息，而无需等待 API 服务器响应。这可以提高应用程序性能并减少延迟。
• 简化代码：Informer 提供了一种更简单、更流畅的方式来监视 Kubernetes 中的资源更改。客户端应用程序可以使用现有的 Informer 库来处理这些任务，而无需编写复杂的代码来管理与 API 服务器的连接并处理更新。
• 更高的可靠性：由于 Informer 在本地缓存数据，因此即使 API 服务器不可用或存在问题，它们也可以继续工作。这可以确保客户端应用程序即使在底层 Kubernetes 基础结构出现问题时也能保持功能。

下面一起看一下 client-go 库的实现原理

当用户发起一个网络请求时，流量会通过默认的网卡接口流出与流入，但有时需要将流量通过指定的网卡进行流出流入，这时我们可能需要进行一些额外的开发工作，对其实现主要用到了 Dialer.Control 配置项。

type 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 "tcp" to Dial
    // will cause the Control function to be called with "tcp4" or "tcp6".
    Control func(network, address string, c syscall.RawConn) error
}

可以看到这是一个函数类型的参数。

上一节 我们大概介绍了一下Envoy中有关速率限制（限流）的一些内容，这一节我们看一下对于外部的 gRPC限流服务它又是如何工作和配置的。

在 Envoy 中对服务限流的配置除了可以在 Envoy 本身中实现外，还可以在通过外部服务实现，此时 Envoy 将通过 gRPC 协议调用外部限流服务，官方对此实现有一套现成的解决方案，主要是redis数据库+令牌桶算法实现，可参考官方

本文中的限制器或限流器均是同一个意思。

Envoy 实现限流

此实现是基于令牌桶算法实现，本身比较的简单，比较适合一般的使用场景。

这里是官方提供的一个配置示例

13          http_filters:
14          - name: envoy.filters.http.local_ratelimit
15            typed_config:
16              "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
17              stat_prefix: http_local_rate_limiter
18              token_bucket:
19                max_tokens: 10000
20                tokens_per_fill: 1000
21                fill_interval: 1s
22              filter_enabled:
23                runtime_key: local_rate_limit_enabled
24                default_value:
25                  numerator: 100
26                  denominator: HUNDRED
27              filter_enforced:
28                runtime_key: local_rate_limit_enforced
29                default_value:
30                  numerator: 100
31                  denominator: HUNDRED
32              response_headers_to_add:
33              - append_action: OVERWRITE_IF_EXISTS_OR_ADD
34                header:
35                  key: x-local-rate-limit
36                  value: 'true'
37              local_rate_limit_per_downstream_connection: false

重点关注配置项 token_bucket ，这里的配置表示当前最多有 10000 个令牌可以被使用，其中令牌在使用的过程中，只要桶中不足10000 个令牌时，则会以每秒再产生 1000 个令牌的速度产生新的令牌并放入令牌桶中，这样就可以实现后期每秒 1000个请求的需求。

在 Envoy 架构中 Rate limit service 共支持 global rate limiting 和 local rate limit filter 两种速率限制。推荐使用 https://github.com/envoyproxy/ratelimit 库。

Global rate limiting

Envoy 提供了两种全局限速实现

1. 每个连接 或 每个HTTP请求 速率限制检查。
2. 基于配额，具有定期负载报告，允许在多个 Envoy 实例之间公平共享全局速率限制。此实现适用于每秒请求负载较高的大型 Envoy 部署，这些负载可能无法在所有 Envoy 实例之间均匀平衡。

Per connection or per HTTP request rate limiting

Envoy 直接与全局 gRPC rate limiting service 集成，配置参考 https://www.envoyproxy.io/docs/envoy/latest/configuration/other_features/rate_limit#config-rate-limit-service。

速率服务可以使用任何 RPC/IDL 协议实现，但Envoy 提供了一个用 Go 编写的参考实现，它使用 Redis 作为后端。速率集成有以下两种特征:

1. Network 级别过滤器：对应 Per connection ，Envoy 将为安装过滤器的侦听器上的每个 新连接 调用速率限制服务。该配置指定一个特定的域名和描述符设置为速率限制。这具有限制每秒传输侦听器的连接速率的最终效果。配置参考 https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/rate_limit_filter#config-network-filters-rate-limit

2. HTTP 级别过滤器: 对应 Per HTTP request，Envoy 将为安装过滤器的 Listener 以及路由表指定应调用全局速率限制服务的侦听器上的每个 新请求 调用速率限制服务。对目标上游集群的所有请求以及从原始集群到目标集群的所有请求都可以进行速率限制。配置参考 https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/rate_limit_filter#config-http-filters-rate-limit

oh-my-zsh 是一款非常不错的shell配置，最近几年一直是重度用户。由于一些原因经常登录一些服务器，这里根据自己的习惯做一个笔记，以后不用每一次都要重新从各个地方找安装脚本了。

安装 zsh

安装zsh

一般系统默认的都是bash，所以我们先安装 zsh。如果不清楚当前使用的哪一类shell的，可通过以下命令查看

$ cat $SHELL
/bin/bash

我这里使用的默认shell。根据平台选择相应的安装zsh命令, 我这里是Ubuntu系统。

Linux、Debian平台

sudo apt install -y zsh

macOS

brew install zsh

Centos/RHE

sudo yum update && sudo yum -y install zsh

确认版本

$ zsh --version
zsh 5.8.1 (aarch64-unknown-linux-gnu)

查看 /etc/shell 看是否存在zsh

$ cat /etc/shells
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/usr/bin/sh
/bin/dash
/usr/bin/dash
/usr/bin/tmux
/usr/bin/screen
/bin/zsh
/usr/bin/zsh

这里有两个 zsh， 其实它们是同一个, 不用管它。

切换默认shell

chsh -s $(which zsh)

注销用户，重新登录终端，再看确认是否切换默认shell成功。

node2% echo $SHELL
/usr/bin/zsh

现在看到终端提示符发生了变化。

进入终端时，可能会提示让配置 zsh ，最终生成一个 .zshrc 配置文件，根据需要配置一下即可。