在日常开发的过程中，经常会需要在本地开发的程序需要在k8s中调试的场景，比如，写了一个operator。如果此时，本地又没有可以直接可达的k8s集群，比如k8s是在公有云的vpc环境内，外面无法直接访问。此时，ssh又是可以直接通过公网vip访问的vpc的网络内的。为了满足此类需要，可以采用ssh tunnel的方式来打通本地跟远程的k8s集群。
mac用户可以通过SSH TUNNEL这个软件来在界面上自动化配置，具体的配置方式如下：
需要增加一个ssh的动态代理，监听本地的9909端口号。
将k8s集群中~/.kube/config文件复制到本地的~/.kube/config目录下
在命令行中配置http和https代理
1 | export http_proxy=127.0.0.1:9909 |
然后至此就可以通过kubectl命令来访问远程的k8s集群了。
conntrack是netfilter提供的连接跟踪机制，允许内核识别出数据包属于哪个连接。是iptables实现状态匹配(-m state)以及nat的基础，由单独的内核模块nf_conntrack实现。
conntrack在图中有两处，一处位于prerouting，一处位于output。主机自身进程产生的数据包会经过output链的conntrack，主机的网络设备接收到的数据包会通过prerouting链的conntrack。
每个通过conntrack的数据包，内核会判断是否为新的连接。如果是新的连接，则在连接跟踪表中插入一条记录。如果是已有连接，会更新连接跟踪表中的记录。
需要特别注意的是，conntrack并不会修改数据包，如dnat、snat，而仅仅是维护连接跟踪表。
/proc/net/nf_conntrack可以看到连接跟踪表的所有内容，通过hash表来实现。
1 | ipv4 2 tcp 6 117 TIME_WAIT src=10.45.4.124 dst=10.45.8.10 sport=36903 dport=8080 src=10.45.8.10 dst=10.45.4.124 sport=8080 dport=36903 [ASSURED] mark=0 zone=0 use=2 |
net.netfilter.nf_conntrack_buckets: 用来设置hash表的大小net.netfilter.nf_conntrack_max: 用来设置连接跟踪表的数据条数上限iptables使用-m state模块来从连接跟踪表查找数据包的状态，上面例子中的TIME_WAIT即为连接跟踪表中的状态，但这些状态对应到iptable中就只有五种状态。特别需要注意的是，这五种状态是跟具体的协议是tcp、udp无关的。
| 状态 | 含义 |
|---|---|
| NEW | 匹配连接的第一个包 |
| ESTABLISHED | NEW状态后，如果对端有回复包，此时连接状态为NEW |
| RELATED | 不是太好理解，当已经有一个状态为ESTABLISHED连接后，如果又产生了一个新的连接并且跟此时关联的，那么该连接就是RELATED状态的。对于ftp协议而言，有控制连接和数据连接，控制连接要先建立为ESTABLISHED，数据连接就变为控制连接的RELATED。那么conntrack怎么能够识别到两个连接是有关联的呢，即能够识别出协议相关的内容，这就需要通过扩展模块来完成了，比如ftp就需要nf_conntrack_ftp |
| INVALID | 无法识别的或者有状态的数据包 |
| UNTRACKED | 匹配带有NOTRACK标签的数据包，raw表可以将数据包标记为NOTRACK，这种数据包的连接状态为NOTRACK |
1 | # 查看连接跟踪表 |
控制器向上提供接口，用来供应用程序调用，此接口成为北向接口；控制器向下调用接口，控制网络设备，此接口成为南向接口。
OpenFlow是控制器和网络设备之间互通的南向协议，OpenvSwitch 用于创建软件的虚拟交换机。
用户态进程
1 | # 安装依赖 |
在编译的时候有如下报错：
1 | File "/usr/lib64/python2.7/site-packages/jinja2/sandbox.py", line 22, in <module> |
是因为markupsafe的版本不对导致的，解决方法为安装合适的版本：
1 | pip uninstall markupsafe |
1 | # 创建虚拟交换机ovs_br |
1 | # 创建namespace |
可以使用如下命令来查看刚才的操作：
1 | # 可以看到刚才创建的网桥 |
接下来测试一下网络的连通性是没问题的。
1 | ip netns exec ns1 ping 192.168.1.200 |
查看当前流表，可以看到有一条默认的规则，该条规则用来实现交换机的基本动作。
1 | $ ovs-ofctl dump-flows ovs1 |
将上述规则删除，再执行ping命令发现已经不通。说明该默认规则会将流量在端口之间进行转发。
1 | ovs-ofctl del-flows ovs1 |
新增加如下两条规则，用来表示将port 1的流量转发到port 3，将port 3的流量转发到port 1。其中的1和3分别为port编号，使用ovs-vsctl list interface veth1_br命令中的ofport可以看到。
1 | ovs-ofctl add-flow ovs1 "priority=1,in_port=1,actions=output:3" |
再执行ping命令，发现可以ping通了。
重新增加一条优先级更高的规则，将port 1的数据drop掉。此时再ping发现已经不通了。
1 | ovs-ofctl add-flow ovs1 "priority=3,in_port=1,actions=drop" |
接下来清理掉规则，并将规则重新写入到table1中，默认规则是写入到table0中的
1 | ovs-ofctl del-flows ovs1 |
此时再执行ping命令，发现网络是不通的。因为table0中没有匹配成功，包被drop掉了。
再增加如下规则，即将table 0的规则发送到table 1处理，此时可以ping通。
1 | ovs-ofctl add-flow ovs1 "table=0,actions=goto_table=1" |
执行ovs-ofctl del-flows ovs1重新清理掉规则，执行下面命令查看group table内容，可以看到内容为空。
1 | # ovs-ofctl -O OpenFlow13 dump-groups ovs1 |
执行如下命令，完成数据包从table0 -> group table -> table1的过程，真正数据处理在table1中。
1 | # 创建一个group table，其作用为将数据包发送到table 1 |
此时再执行ping命令，发现是可以ping通的。
1 | # 删除网桥 |
ovs-appctl fdb/show ovs1: 查看mac地址表ovs-ofctl show ovs1: 可以查看网桥的端口号ovs-vsctl set bridge ovs1 stp_enable=false: 开启网桥的生成树协议ovs-appctl ofproto/trace ovs1 in_port=1,dl_dst=7a:42:0a:ca:04:65: 可用来验证一个包到达网桥后的处理流程kube-proxy默认使用iptables规则来做k8s集群内部的负载均衡，本文通过例子来分析创建的iptabels规则。
主要的自定义链涉及到：
创建nginx deployment
1 | apiVersion: apps/v1 |
创建service对象
1 | apiVersion: v1 |
环境信息如下：
提交后创建出来的信息如下：
从本机请求ClusterIP的数据包会经过iptables的链：OUTPUT -> POSTROUTING
要想详细知道iptabels的执行情况，可以通过iptables的trace功能。如何开启trace功能可以参考：http://kuring.me/post/iptables/。
执行 iptables -nvL OUTPUT -t nat 可以看到如下的iptables规则命令
1 | pkts bytes target prot opt in out source destination |
执行 iptables -nvL KUBE-SERVICES -t nat 可以查看自定义链的具体内容，里面包含了多条规则，其中跟当前Service相关的规则如下。
1 | pkts bytes target prot opt in out source destination |
执行 iptables -nvL KUBE-SVC-Y5VDFIEGM3DY2PZE -t nat 查看自定义链的具体规则
1 | pkts bytes target prot opt in out source destination |
上述规则会按照特定的概率将流量均等的执行自定义链的规则，两个自定义的链的规则跟endpoint相关，执行 iptables -nvL KUBE-SEP-IFV44I3EMZAL3LH3 -t nat可查看endpoint级别的iptabels规则。dnat操作会修改数据包的目的地址和端口，从clusterip+service port修改为访问pod ip+pod端口。
1 | pkts bytes target prot opt in out source destination |
会在dnat操作之前为对数据包执行打标签操作。KUBE-MARK-MASQ 自定义链为对数据包打标记的自定义规则，执行 iptables -nvL KUBE-MARK-MASQ -t nat
1 | pkts bytes target prot opt in out source destination |
接下来看一下POSTROUTING链上的规则，iptables -nvL POSTROUTING -t nat。
1 | pkts bytes target prot opt in out source destination |
继续看一下KUBE-POSTROUTING链的内容，iptables -nvL KUBE-POSTROUTING -t nat，其中最后一条的MASQUERADE指令的操作实际上为SNAT操作。
1 | Chain KUBE-POSTROUTING (1 references) |
即从本机访问service clusterip的数据包，在output链上经过了dnat操作，在postrouting链上经过了snat操作后，最终会发往目标pod。pod在处理完请求后，回的数据包最终会经过nat的逆过程返回到本机。
从外部访问本机的nodeport数据包会经过iptables的链：PREROUTING -> FORWARD -> POSTROUTING
nodeport都是被外部访问的情况，入口位于PREROUTING链上。执行 iptables -nvL PREROUTING -t nat：
1 | pkts bytes target prot opt in out source destination |
在KUBE-SERVICES链的最后一条规则为跳转到KUBE-NODEPORTS链
1 | 4079 246K KUBE-NODEPORTS all -- * * 0.0.0.0/0 0.0.0.0/0 /* kubernetes service nodeports; NOTE: this must be the last rule in this chain */ ADDRTYPE match dst-type LOCAL |
执行iptables -nvL KUBE-NODEPORTS -t nat， 查看KUBE-NODEPORTS链
1 | pkts bytes target prot opt in out source destination |
其中KUBE-MARK-MASQ链只有一条规则，即打上0x4000的标签。
1 | pkts bytes target prot opt in out source destination |
自定义链KUBE-SVC-Y5VDFIEGM3DY2PZE的内容如下，跟clusterip的规则是重叠的：
1 | pkts bytes target prot opt in out source destination |
KUBE-SEP-IFV44I3EMZAL3LH3的内容为，会经过一次DNAT操作:
1 | pkts bytes target prot opt in out source destination |
在经过了PREROUTING链后，接下来会判断目的ip地址不是本机的ip地址，接下来会经过FORWARD链。在FORWARD链上，仅做了一件事情，就是将前面大了0x4000的数据包允许转发。
1 | pkts bytes target prot opt in out source destination |
KUBE-FORWARD的内容如下：
1 | pkts bytes target prot opt in out source destination |
跟clusterip一样，会在POSTROUTING阶段匹配mark为0x4000/0x4000的数据包，并进行一次MASQUERADE转换，将ip包替换为宿主上的ip地址。
加入这里不做MASQUERADE，流量发到目的的pod后，pod回包时目的地址为发起端的源地址，而发起端的源地址很可能是在k8s集群外部的，此时pod发回的包是不能回到发起端的。NodePort跟ClusterIP的最大不同就是NodePort的发起端很可能是在集群外部的，从而这里必须做一层SNAT转换。
在上述分析中，访问NodePort类型的Service会经过snat，从而服务端的pod不能获取到正确的客户端ip。可以设置Service的spec.externalTrafficPolicy为Local，此时iptables规则只会将ip包转发给运行在这台宿主机上的pod，而不需要经过snat。pod回包时，直接回复源ip地址即可，此时源ip地址是可达的，因为源ip地址跟宿主机是可达的。如果所在的宿主机上没有pod，那么此时流量就不可以转发，此为限制。
1 | -A KUBE-SERVICES -d 10.149.30.186/32 -p tcp -m comment --comment "acs-system/nginx-ingress-lb-cloudbiz:http loadbalancer IP" -m tcp --dport 80 -j KUBE-FW-76HLDRT5IPNSMPF5 |
docker bridge是默认的网络模式
默认情况下，容器即可访问外网。
启动一个容器：docker run -d nginx
容器中访问外网的请求如www.baidu.com，内核协议栈根据路由信息，会选择默认路由，将请求发送到容器中的eth0网卡，目的mac地址为网关172.17.0.1的mac地址。
1 | $ route -n |
eth0网卡接收到数据包后，会将数据包转发到veth pair的另外一端，即宿主机网络中的veth6b173fd设备。
veth6b173fd设备是挂在网桥上的，会将数据包转发到网桥br0，br0即为网关172.17.0.1。
br0接收到数据包后，会将数据包转发给内核协议栈。
宿主机上的/proc/sys/net/ipv4/ip_forward为1，表示转发功能开启，即目的ip不是本机的会根据路由规则进行转发，而不是丢弃。
仅在宿主机上开启了ip_forward后，包即使转发了，还是无法回来的，因为包中的源ip地址为172.17.0.1，是私有网段的ip地址。需要做一次SNAT才可以，docker会在iptabels的nat表中的postrouting链中增加SNAT规则，下面规则的意思是源地址为172.17.0.0/16的会做一次地址伪装，即SNAT。
1 | # iptables -nL -t nat |
在eth0网卡上抓包，可以发现源ip已经是eth0的网卡ip地址。
命令格式：-p ${host_port}:${container_port}
启动一个容器：docker run -d -p 8080:80 nginx
查看本地的iptables规则
1 | $ iptables -nL -t nat |
SNAT在并发比较高的情况下，会存在少量的丢包现象，具体原因跟conntrack模式的实现有关。conntrack在SNAT端口的分配和插入conntrack表之间有个延时，如果在这中间存在冲突的话会导致插入失败，从而出现丢包的问题。
该问题没有根治的解决办法，能大大缓解的解决办法为使用iptabels的–random-fully选项，SNAT选择端口为随机，大大降低出现冲突的概率。
ipip协议为在ip协议报文的基础上继续封装ip报文，基于tun设备实现，是一种点对点的通讯技术。
ipip需要内核模块ipip的支持
1 | $ modprobe ipip |
两台主机：172.16.5.126(host1)和172.16.5.127(host2)
在host1上创建tun1设备，执行如下命令：
1 | # 用来创建tun1设备，并ipip协议的外层ip，目的ip为172.16.5.127， 源ip为172.16.5.126 |
同样在host2上创建tun1设备：
1 | ip tunnel add tun1 mode ipip remote 172.16.5.126 local 172.16.5.127 |
并分别在host1和host2上打开ip_forward功能
1 | echo 1 > /proc/sys/net/ipv4/ip_forward |
然后在host1上ping 10.10.200.10，可以ping通。
在host1的tun1上抓包，可以看到正常的ping包。
在host1的eth1上抓包，可以看到已经是ipip的数据包了。
清理现场分别在两台主机上执行
1 | ip link delete tun0 |
tap/tun常用于隧道通讯，通过一个字符设备来实现用户态和内核态的通讯，字符设备一端连接着用户空间，一端连接着内核空间。
与物理网卡的最大不同是，tap/tun的数据源来自于用户态的程序，而物理网卡的数据源来自于物理链路。
对应的字符设备文件位置：
当应用程序打开字符设备文件时，驱动程序会创建并注册相应的虚拟设备接口，以tunX或tapX命名。应用程序关闭设备文件时，驱动程序会删除tunX和tapX网络虚拟设备，并删除建立起来的路由信息。
两个设备的不同点：
1 | ┌──────────────┐ |
1 | ┌──────────────┐ ┌──────────────┐ |
应用程序A要发送数据到其他物理机192.168.1.100，由于物理网络环境下只有10.1.1.11和10.1.1.100是相互连通的，192.168.1.11和192.168.1.100是不通的，为了192.168.1.11和192.168.1.100能够进行通讯，需要将数据包进行一次封装。
应用程序B是通过打开字符设备文件/dev/net/tun0的方式来打开网络设备
流程如下：
网卡的混杂模式是指网卡将其接收的所有流量都交给cpu。非混杂模式下，网卡仅接收目的mac地址是自己mac地址的单播，以及多播和广播包，可以看出混杂模式是工作在二层的。
通过ifconfig eth0的方式，如果输出中包含了PROMISC字段，说明网卡处于混杂模式。但是如果ifconfig 命令的输出中未包含PROMISC字段，并不能说明网卡处于非混杂模式下。
可以通过查看 cat /sys/class/net/bond0/flags 的输出得知，如果置位了0x100，说明处于混杂模式。
veth pair是一对虚拟的网络设备，两个网络设备彼此连接。常用于两个network namespace之间的连接，如果在同一个命名空间下有很多的限制。
1 | ┌──────────────────────────────────────────────────────────────────────────────┐ |
给veth0配置ip 192.168.100.10，可以看到主机的路由表中增加了目的地为192.168.100.0的记录
1 | [root@localhost vagrant]# ip link add veth0 type veth peer name veth1 |
默认情况下arp表如下：
1 | # arp |
使用ping命令ping -I veth0 192.168.100.11 -c 2，默认情况下veth1和veth0会接收到arp报文，但并没有arp的响应报文。这是因为默认情况下有些arp内核参数的限制。执行如下命令解决arp的限制。
1 | echo 1 > /proc/sys/net/ipv4/conf/veth1/accept_local |
1 | # 删除veth0后会自动删除veth1 |
veth pair的其中一个设备位于container中备位于container中，另外一个设备位于host network namespace中，如何知道container中的eth0和host network namesapce中的veth设备的对应关系呢？
原理为veth pair设备都有一个ifindex和iflink值，，容器中的eth0设备的ifindex值跟host network namespace中的对应veth pair设备的iflink值相等，反之亦然。
方法一
获取iflink值：cat /sys/class/net/eth0/iflink
也可用此方法获取ifindex值：cat /sys/class/net/eth0/ifindex
方法二
1 | $ ip link show eth0 |
其中的3为eth0的ifindex。18为eth0的iflink，即对应的veth pair的另外一个设备的ifindex。
1 | $ ip addr |
其中的18为ifindex，3为对应的veth pair的ifindex。
距离上次的知识分享系列已经过去了半年之久，难以想象。在该系列的开始我就说过该系列是不定期的，果不食言，只是这次的不定期有些久😓。该系列会继续下去，但节奏仍然是不定期的，但应该不会间隔半年之巨了。
题图来自首钢工业遗址公园，首钢于2010年完成了搬迁到唐山市的工作，位于石景山的工厂被废弃。2019年国庆节前夕以公园的形式部分对外开放，跟普通公园不同的地方在于保留了很多之前的工厂建筑及大型生产机械，足够硬核，非常原汁原味。
2022年要举办的冬奥会也非常明智的将场地选择在了该公园，预计将来会有很多的场馆位于该公园内且对外开放。
国内很多的地市都有一些类似的建筑，比如90年代下岗潮之前的一些国企工厂，我知道的济南的机床厂就有很多个，但很多这些倒闭关门的工厂后来的建筑及地皮都给卖掉了，建筑物也直接给拆掉了，殊不知其衍生价值也是有不少的。位于北京酒仙桥的798就是个非常好的改造案例，798园区的建筑稍加改造，给很多艺术工作室提供了非常好的办公场地，也是城市中的一个亮眼的名片。
json作为一种常见的数据序列化方案，存在占用空间过多、反序列化过于消耗cpu的问题。MessagePack是一种基于二进制的高效轻量的数据序列化方案，支持数据的压缩，支持丰富的编程语言。在上图中，可以看出原27字节的json数据转换为MessagePack后仅占用了18字节。
另外，据今日头条的压测，要比Thrift的二进制序列化方案更高效一些。
Golang中的ast、parser、token包可用来对golang的源码进行语法分析，并构建出AST树。GoAst Viewer支持在线输入Golang源码来构建AST树。
3.KubeEdge
IoT目前正在大力发展，边缘设备的计算能力在逐渐增强，同时处理的数据量的需求正在快速增加，而数据中心的数据处理能力、网络带宽、扩展能力并没有太多的增强，未来势必会将部分计算能力下放到边缘设备，以降低数据中心的成本。
华为开源的KubeEdge为基于Kubernetes的边缘计算平台，支持边缘集群的编排和管理。
4.Mycat
国内开源的关系型数据库中间件，支持MySQL、Oracle等常见的关系型数据库。关系型数据库单表过大导致性能下降后的解决思路往往是分库分表，分库分表后需要增加中间件层来解决多个数据库多张表的数据增删改查问题，而Mycat是一个不错的解决方案。
当然Mycat的功能不仅限于此，比如支持跨库的两张表join、Mycat-eye可以来监控Mycat等，更多功能请参照官方网站。
一款转换markdown格式的文档为微信公众号排版的工具，排版比较精美，推荐一试。
6.GitNote
一款基于git的笔记管理软件，可以将笔记存放到Github中，支持多种图床插件，支持多个平台（还没有移动端），支持富文本编辑和Markdown编辑。由于笔记是可以同步Github上的，可以做到永久保存和版本控制，而且笔记的存放目录和格式不受该工具的影响，可以说是完全没有侵入性，脱离了该工具仍然可以通过直接编辑git项目的方式来发布笔记。
7.Vlang开源啦
V语言宣布开源，从V语言的特性上看到了很多Golang的影子，并未看到耳目一新的特性。
8.krew
一款kubectl的plunin管理工具，mac平台下有brew包管理工具，随着kubectl的plugin机制的成熟，plugin管理工具应运而生。
运行在k8s上的证书管理工具，可以签发证书，基于CRD实现。
Let’s Encrypt提供了免费的tls证书，但证书有有效期限制，过期后需要手工重新申请证书，cert-manager可以做到从Let’s Encrypt自动申请证书，并过期后重新申请证书。
10.cmatrix
一款黑客帝国效果的命令行工具，除了炫酷也没啥其他用途了。
11.boxes
boxes为一款有趣的命令行工具，可以显示很多神奇效果。
1 | __ _,--="=--,_ __ |
12.rally
一款elasticsearch的压测工具。
13.tekton
Google开源的一款基于Kubernetes的应用发布框架，Google在云原生生态中出品一般质量都比较高，主要用来做CI/CD。
一款基于kubectl插件的debug工具，基础镜像使用nicolaka/netshoot(内置了大量的网络排查工具)，可用于kubernetes集群中快速定位问题。值得一提的是，该工具的初版是作者在参加pingcap面试时的小作业。
15.Monocular
Rancher出品的一款基于管理helm chart的ui工具。
16.gitmoji
github上的开源项目中经常会看到一些git commit message中包含了moji表情，而且有越来越多的趋势，这些moji表情不紧紧是好玩，而且还非常生动形象的表达了commit message的含义，并且非常醒目，但这些moji表情可不应该是滥用的。该网站记录了一些常用的moji表情在git commit中的含义。
1.Monitoring and Tuning the Linux Networking Stack: Receiving Data
本文讲解了一个数据包到达网卡后是怎么一步步从网卡 -> 操作系统 -> 应用程序，并讲解了Linux中的实现方式。
绝大多数的工程师对于这一块的知识是较为模糊的，建议一读。
半年多前比较火的视频，但我还是经常会想起来，给大家重温一下。
视频中为杭州一小伙深夜骑车逆行被交警拦下后情绪崩溃，失声痛哭。小伙每晚加班到十一二点，一方面女朋友在催着给送药匙，另一方面公司还在催着赶回公司，再加上被交警拦下，最终来自三方面的催促导致积压在小伙内心长久以来的压力爆发而情绪失控。隔着屏幕都能感受到小伙长期以来的压力，我猜想如果给他一些自由的时间，他一定会选择独自一人到一个安静的地方过上一段时间与世隔绝的生活。
生活本不易，在觉大多数的成年人生活中没有简单二字，祝愿各位生活如意！