bind -r k select-pane -U # 绑定k为↑ bind -r j select-pane -D # 绑定j为↓ bind -r h select-pane -L # 绑定h为← bind -r l select-pane -R # 绑定l为→ bind -r ^k resizep -U 5 # 绑定Ctrl+k为往↑调整面板边缘10个单元格 bind -r ^j resizep -D 5 # 绑定Ctrl+j为往↓调整面板边缘10个单元格 bind -r ^h resizep -L 5 # 绑定Ctrl+h为往←调整面板边缘10个单元格 bind -r ^l resizep -R 5 # 绑定Ctrl+l为往→调整面板边缘10个单元格 run-shell ~/.tmux/tmux-resurrect/resurrect.tmux bind -r V copy-mode # 绑定Ctrl+l为往→调整面板边缘10个单元格 bind-key -T copy-mode v send -X begin-selection # default is <space> bind-key -T copy-mode V send -X select-line bind-key -T copy-mode C-v send -X rectangle-toggle # default is C-v, or R in copy-mode (non-vi) bind-key -T copy-mode y send -X copy-pipe-and-cancel 'xclip -selection clipboard -in' bind p paste-buffer # default ]
kube-apiserver PodPriority TaintNodeByCondiction ResourceQuataScopeSelectors ScheduleDaemonSetPods feature gate 默认打开 --encryption-provider-config cacheSize: 0 配置值会解析错误, 如果目的是关掉配置, 要设置一个负值 kubectl kubectl 以及 k8s.io/client-go 默认 apiserver endpoint 取消默认值为 http://localhost:8080 kubectl run 命令改为启动 pod (之前是启动 deployment), 如果需要启动 deployment 或者其他资源, 使用 kubectl create 删除 kubectl rolling-update 这个弃用的命令 ref: k8s 官网changelog
#!/bin/bash do=$1 pod=$2 t= if [[ $do == "e" ]]; then do=exec t="-it bash" fi if [[ $do == "l" ]]; then do=logs fi if [[ $do == "d" ]]; then do="delete pods" fi if [[ $do == "de" ]]; then do="get pods" t="-o yaml" fi echo $do podname=`kubectl get pods | grep ${pod} | grep Running | head -n 1 | awk '{print $1}'` echo $podname echo "kubectl ${do}${podname}${t}$3$4$5$6" kubectl ${do} ${podname} ${t} $3 $4 $5 $6
本文记录了对 MOSN 的源码研究 - MOSN 的共享内存模型。 本文的内容基于 MOSN v0.9.0，commit id b2a239f5。 机制 MOSN 用共享内存来存储 metrics 信息。MOSN 用 mmap 将文件映射到内存，在内存数组之上封装了一层关于 metrics 的存取逻辑，实现了 go-metrics 包的关于 metrics 的接口，通过这种方式组装出了一种基于共享内存的 metrics 实现供 MOSN 使用。 创建共享内存：Mmap 操作共享内存的方法主要在 pkg/shm/shm.go 文件下： func Alloc(name string, size int) (*ShmSpan, error) { ... return NewShmSpan(name, data), nil } func Free(span *ShmSpan) error { Clear(span.name) return syscall.Munmap(span.origin) } func Clear(name string) error { return os.Remove(path(name)) } 都是围绕着 ShmSpan 结构体的几个操作方法。再来看 ShmSpan 结构体： type ShmSpan struct { origin []byte // mmap 返回的数组 name string // span 名, 创建时指定 data uintptr // 保存 mmap 内存段的首指针 offset int // span 已经使用的字节长度 size int // span 大小 } Alloc 方法按照给定的 name 参数，在配置文件的目录下创建文件，并执行 sync.
本文记录了对 MOSN 的源码研究 - MOSN 的内存复用机制。 本文的内容基于 MOSN v0.9.0，commit id 1609ae14。 MOSN 在内存管理复用方面有 内存对象注册/管理 和 byte/io buffer 复用 两部分内容。MOSN 最新的 master 分支用了 mod 管理依赖， 发现后一部分也迁移到了 vendor 目录下，可单独使用。下面就分这两部分来讲述 MOSN 的内存复用机制。 机制 简述一下两部分内容的机制，具体实现原理会在后面带上源码解析。 1. 内存对象注册/管理 MOSN 在 go sync 包外，对 sync.Pool 对象进行了进一步封装，增加了管理和易用性。 MOSN 的 buffer 包提供了注册函数和统一的接口。将实现了接口的不同类型的 buffer 对象注册到 buffer 包， 在用到的使用通过 buffer 包导出的方法进行初始化和管理，增强了内存对象的管理。 而易用性方面，MOSN 封装了 bufferValue 对象，管理上面初始化出来的对象，并且将 bufferValue 对象也进行了池化管理。在这之上，封装出方法 NewBufferPoolContext 和 PoolContext，使内部根据 context 传值的场景更加易用。MOSN 里面在不同协程协作（比如连接被协程1 accept 后， 交由 worker 协程2 进行 IO）的过程，会将必要参数使用内部实现的 context with value 机制进行传递， 其中 buffer 传递的方法就是通过上述封装的方法进行传递的。
本文记录了对 MOSN 的源码研究 - MOSN 的插件机制, 以及如何创建自己的插件来扩展 MOSN。 本文的内容基于 MOSN v0.9.0。 机制 使用过滤器模式来实现扩展是常见的设计模式，MOSN 也是使用了这种方式来构建可扩展性。 MOSN 把过滤器相关的代码放在了 pkg/filter 目录下： ➜ mosn git:(2c6f58c5) ✗ ll pkg/filter total 24 drwxr-xr-x 8 mac staff 256 Feb 5 08:52 . drwxr-xr-x 30 mac staff 960 Feb 5 08:52 .. drwxr-xr-x 3 mac staff 96 Aug 28 22:37 accept -rw-r--r-- 1 mac staff 2556 Feb 5 08:52 factory.go -rw-r--r-- 1 mac staff 2813 Feb 5 08:52 factory_test.
本系列文章主要介绍了在非 kubernetes 环境，使用 gloo 搭建服务网关的过程，以及 gloo 的简单的使用指南。 系列文章目录如下: 使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 初识 gloo 使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 路由能力: tcp / http [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 路由能力: grpc][3] [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - envoy 高可用、错误注入、超时控制、熔断][4] [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 指标监控、报警][5] [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 链路跟踪][6] [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 权限、流控][7] 上篇文章主要简单介绍了 gloo 以及在非 k8s 环境下运行了简单的 gloo demo。 接下来两篇文章我会简单讲述一下 gloo 的路由能力。
本系列文章主要介绍了在非 kubernetes 环境，使用 gloo 搭建服务网关的过程，以及 gloo 的简单的使用指南。 系列文章目录如下: 使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 初识 gloo 使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 路由能力: tcp / http [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 路由能力: grpc][3] [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - envoy 高可用、错误注入、超时控制、熔断][4] [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 指标监控、报警][5] [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 链路跟踪][6] [使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 权限、流控][7] 首先: 使用非 kubernetes 环境意义何在? 调试快速
本文记录了对 mosn 的源码研究，研究 mosn 是如何做到平滑重启的。 本文的内容基于 mosn v0.8.1。 我们先将被重启的 mosn 进程称为 旧 mosn，将重启并接管流量的进程成为 新 mosn。 1. 机制 mosn 没有使用重新读取 config 文件的方法来实现 reconfig，而是通过 unix socket 作为进程间通信，并将旧进程的监听 fd 通过 socket 传过去，新 mosn 接管 fd 并且重新读取 config，旧 mosn 进行 gracefully shutdown，以达到 reconfig 和平滑重启的功能。 2. 旧mosn 我们先从一个启动着的 mosn 进程看起，看看它是如何被重启的。 mosn 的 reconfig 逻辑在 server 包的 reconfigure.go 内。 mosn 进程启动后，会创建一个叫 reconfig.sock 的 unix socket，创建一个协程，开始监听并往里面写入一个字节的内容，这时会出现写阻塞。一旦有另一个进程从 reconfig.sock 读取到这一个字节，旧 mosn 便开始 reconfig 逻辑。 reconfig 逻辑: 当写阻塞结束，协程会尝试链接另一个 unix socket ：listen.
安装 cfssl wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 chmod +x cfssl_linux-amd64 mv cfssl_linux-amd64 /usr/local/bin/cfssl wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 chmod +x cfssljson_linux-amd64 mv cfssljson_linux-amd64 /usr/local/bin/cfssljson wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 chmod +x cfssl-certinfo_linux-amd64 mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo export PATH=/usr/local/bin:$PATH 找到 kubernetes 的根证书 ca.pem, ca-key.pem, ca-config.json 生成证书请求配置文件, 可以替换 usage 为其他名字, 替换 usage.common.name 为服务器域名 cat > usage.json <<EOF { "CN": "usage.common.name", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "BeiJing", "L": "BeiJing", "O": "k8s", "OU": "System" } ], "ca": { "expiry": "87600h" } } EOF 用 cfssl 工具签名服务端证书 cfssl gencert -ca=ca.