client-go RingGrowingBuffer 环形缓冲区

在client-go源码中,processorListener对象里面定义了一个RingBuffer用于缓存所有尚未分发的事件通知,在此记录下这个RingBuffer。 RingBuffer一般用于数据的缓存机制,例如tcp协议里面数据包的缓冲就利用到了RingBuffer。 client-go中的这个buffer是非线程安全、可增长、无边界的先进先出环形缓冲区。环是一个逻辑上的概念,有了环,此段内存空间就可以重复利用,不用频繁重新申请内存,本质上数据还是存在数组里面的,这个数组的大小可以按需进行倍数扩容,扩容后需要重新分配内存空间并拷贝未消费的数据到新数组来。因为它是数组,内存是预先分配的,数组是内存上连续的一段空间,它有一个容易预测的访问模式,因此对CPU高速缓存友好,垃圾回收(GC)在这种情况下也不用做什么。 在实现上,可以理解为两个指针:a) 读指针、b)写指针。在一段buffer上,读指针控制下一次该读数据的位置,写指针控制下一次该写数据的位置。在数组里面我们可以直接用数组下标。要遵循FIFO原则,读指针不能超过写指针,两指针重叠了要么buffer写满了,要么buffer为空。 参考这里的一张图 目前我们只需要考虑: 存储啥数据类型 数据如何存放 何时空间满了需要扩容 不能丢失未消费数据 k8s中的源码: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 // 源码路径k8s....

October 11, 2021 · 2 min · 252 words · erpan

信号和容器关闭

前提概要 信号概念 进程间通信 socket 消息队列 管道:类似瀑布开发模式 共享内存 信号量:一般和共享内存一起使用 信号:应急事件、通知 信号,一般是异常情况下的工作模式(其他几种通信方式是常规情况下的),是进程间通信唯一一种异步通信方式,即可以在任何时候发送信号给一个进程。 为了响应各种各样的事件,定义了下面64种信号: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [root@whatfuck ~]# kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX 对收到的信号有三种处理方式...

June 10, 2021 · 6 min · 1093 words · erpan

为普通用户授权生成kubeconfig

概述 开发同学用kubectl查看线上Kubernetes集群中的一些情况,如何生成kubeconfig? 对指定的用户赋予合适的权限,首先需要明确这里的授权对象(用户)、该对象的认证方式、授权权限大小及授权方式几个概念。 在k8s集群中,当一个请求到达APIServer时,会经过多个阶段以执行访问验证、控制的行为,阶段顺序依次是: 传输安全,一般我们APIServer只开启https端口,建立TLS连接以确保传输安全 认证,请求到达APIServer后会依次尝试每个认证模块,有一个认证通过即可 鉴权,认证通过后进入到鉴权阶段,即判断特定的用户对特定的对象进行特定的操作是否有相应的权限 准入,鉴权通过则进入准入阶段,准入模块可以对请求进行验证和修改,多个准入控制器会被依次调用。有一个准入失败则立即响应拒绝服务 下面概括了认证授权相关的概念 用户 Kubernetes集群中的用户有两类: 服务账户serviceaccount,由k8s管理,绑定到指定的名称空间,每个sa与一个secret关联用以保存相关凭据 普通用户,集群中没有对应的资源专门管理普通用户,一般是在集群外管理的。这里当然也有用户组的概念 认证策略 身份认证策略有下面几种: 客户端证书:传递给APIServer的--client-ca-file=SOMEFILE参数指定了一个或多个证书机构,用此证书机构验证客户端提供的证书,验证通过则表示认证通过 持有者令牌 静态令牌:给APIServer传递--token-auth-file=SOMEFILE选项以启用 启动引导令牌:动态管理的令牌,一般用作平滑启动引导新集群 服务账户令牌:sa关联的secret中保存APIServer公开的CA证书和一个已签名的JWT令牌。一般在pod内使用,当然也可以在集群外部使用 OpenID Connect令牌:OAuth2方式 webhook令牌:用回调机制来验证令牌,Webhook插件用POST请求发送一个JSON序列化的对象到远程服务 静态密码 HTTP基本认证 用户伪装 身份认证代理 匿名 鉴权 鉴权主要有下面四个模块: Node:限制kubelet对APIServer的请求 ABAC:基于属性的访问控制 RBAC:基于角色的访问控制 Webhook:http回调,查询外部的REST服务 生成kubeconfig 利用ssl工具一步步生成 一般我们给开发同学的权限是只读的,那如何给单个开发同学或者开发组生成对应的kubeconfig以只读权限访问集群? 在kubeconfig文件中,包含的信息有用户(组)、集群地址、客户端的数字证书(或Bearer token,或basic auth)等信息。由集群CA签名的有合法证书的用户都是通过认证的用户,Kubernetes使用证书中的subject的通用名称(Common Name)字段作为用户名,Organization字段作为用户组信息。 因此可以为指定用户或用户组生成集群CA机构签发的客户端证书,以证书认证的方式访问APIServer。 常用的证书生成工具有easyrsa、cfssl和openssl,这里以openssl为例: 1 2 3 4 5 6 7 8 9 mkdir developer; cd developer/ # 生成私钥 openssl genrsa -out developer.key # 生成签名请求文件,CN为developer,可指定organization字段值作为组名 openssl req -new -key developer.key -out developer....

November 9, 2020 · 4 min · 703 words · erpan

Nginx优化

参考:https://www.nginx.com/blog/tuning-nginx/ nginx一般用作高性能反向代理。在http七层代理的情况下,它首先接收客户端请求,经过处理后再请求upstream server,因此nginx服务器上的连接数是客户端请求数的2倍,在高并发情况下,建立的连接数非常多,因此系统相关资源如打开文件数、tcp连接、可分配端口等很可能称为其瓶颈。可以从系统内核参数及nginx自身做一些优化。下面提到的相关参数按需调整。 相关内核参数 tcp连接队列调整 在内核中,为tcp连接维护了两个队列。一个是已经建立了连接的accept队列,这时候连接三次握手已经完毕,处于 established 状态;一个是还没有完全建立连接的队列,这个时候三次握手还没完成,处于 syn_rcvd 的状态。过程如下: 当server接收到client的 SYN 报⽂时,会将其加⼊到内核的SYN半连接队列 接着发送SYN+ACK给client,等待client回应ACK报⽂,client收到此包后connect()调用返回,进入establish状态 server接收到ACK报⽂后,把此连接从SYN队列移除并放⼊到Accept队列 此时server端应⽤调⽤accpet() socket接⼝从Accept 队列取出连接用于数据通信 如何查看这两个队列情况? 全连接查看:ss -ant 半连接查看:ss -ant | grep -i syn_recv | wc -l LISTEN: Recv-Q 表示当前socket完成三次握手等待用户进程(此处即nginx)accept的连接个数,即全连接队列使用量。一般我们常常看到此值为0,没有堆积 Send-Q 表示当前socket全连接队列最大长度 非LISTEN: Recv-Q 表示receive queue中已收到未读取的字节大小 Send-Q 表示send queue中已发送未收到确认的字节大小 队列满了的情况 半连接满 此时会发生syn包被丢弃的现象,因而客户端会重试,性能下降。可能是syn攻击导致 1 2 $ netstat -s | grep -i syn 612 SYNs to LISTEN sockets dropped 全连接满 并发量大,server端accept()调用过慢时出现,可能由于服务器负载、应用程序本身等问题导致。 满了后新的连接直接丢弃或者回复reset包,此行为由内核参数tcp_abort_on_overflow控制(为0直接丢弃,为1回reset包),且内核socket统计信息里面listen overflowed数加1。 1 2 $ netstat -s | grep -i overflow 612 times the listen queue of a socket overflowed 调优上可以适当增大全连接和半连接队列...

August 2, 2020 · 2 min · 228 words · erpan

bash中alias不生效

alias不生效 在修改一段shell脚本时,需要将函数里面的kubectl命令替换为kubectl --insecure-skip-tls-verify=True,使得脚本中的所有kubectl命令执行时会自动加上选项--insecure-skip-tls-verify=True。首先想到的就是利用alias别名,示例如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 function func1(){ ... kubectl get deployment -n ${NAMESPACE} ${CI_PROJECT_NAME} # 不生效 ... } ... function main(){ ... alias kubectl="kubectl --insecure-skip-tls-verify=True" kubectl get ns # 不生效 ... } 但是用上面方式改来改去kubectl选项不生效。 原因是:alias不能直接在同一个命令解析单元里面定义并使用,必须在定义alias的命令解析单元解析执行完成后,才能生效。 因此,在函数里面使用alias时,可以用下面函数的方式: 1 2 3 4 function main(){ kubectl() { /usr/bin/kubectl --insecure-skip-tls-verify=True "$@"; } kubectl get ns # 此处等同于kubectl加了--insecure-skip-tls-verify=True选项 } 当然也可以把alias放在函数外、脚本的前面。 命令解析单元 解析单元就是一组完整的命令(包括组合命令、循环等)后面跟上换行符。 shellcheck项目的示例: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 # 单个命令跟换行,一个解析单元 unit 1 # 俩命令在同一解析单元,之间无换行 unit 2; unit 2; # 大括号的同一个解析单元 { unit 3 unit 3 } # 也是同一个解析单元,在大括号组之间无换行 { unit 4 }; { unit 4 } 上面示例中,unit1中定义的别名,只能在unit2及后面才能使用。...

June 12, 2020 · 1 min · 117 words · erpan