文章讨论答疑： 深入浅出kubernetes中的CNI

[linkingli]

谢谢博主，学习了，有个问题想请教一下，cri创建好网络之后，容器异常，pod重启了，这种情况是重新创建一个网络栈，还是使用之前的那个呢，如果是重新创建一个，对于性能影响大吗。ps: github上面的图片被吞了，:)。

[helios741]

@linkingli pod重启了是会重新调用CNI创建网络栈的，基本的网络栈包含网卡，回环设备，路由表等，在pod重启之前看一下pod内的网卡

# kubectl exec -ti nginx-ds-xg8qk bash
root@nginx-ds-xg8qk:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
53: eth0@if54: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
    link/ether 02:42:ac:1e:c8:04 brd ff:ff:ff:ff:ff:ff
    inet 172.30.200.4/21 brd 172.30.207.255 scope global eth0
       valid_lft forever preferred_lft forever

这里是if54表示通过宿主机上通过veth pair创建出来的虚拟网卡是54号（宿主机上也是ip a命令可以看到）， 当pod重启之后这个，可以看到这个网卡变了，也就意味着网络栈重建了。 具体源码可以看：killPodWithSyncResult -> StopPodSandbox -> TearDownPod

这个对于性能的影响我有点没理解呢，这个是指的如果重新创建网络栈影响对外提供的服务？

[helios741]

@linkingli 辣个图片被吞了呢🤦‍♂️，我这都行的呢😂

[linkingli]

是这样的，这里有个k8s的集群，目前200多个pod，准备scale到1000，目前qos已经满足测试了。但是里面的服务不太稳定，老是会restart pod，这种情况下，频繁的重启，每次重新构建网络栈for new pod, 对于系统的开销要不要考虑呢，还是取决于cni plugin的实现有所不同，目前使用的是flannel,:)

[root@paas net.d]# pod|wc -l
231

[helios741]

@linkingli

先说一下一个pod什么时候能够作为service的后端提供服务。 每个service会对应一个endpoints资源，当一个pod通过了readiness探针之后，会把这个pod的ip加入到endpoints中，也就能作为对应service的后端提供服务了。

所以这个POD频繁重启会影响对外提供服务滴（因为启动服务的时间肯定相对比较长）。

当然每次重新给新pod构建网络栈，肯定会消耗一部分宿主机的计算资源，但是这个影响不大。

按照您的描述我感觉问题应该不是出现在网络的问题上（flannel如果用的vxlan的话，消耗主要是隧道两端的封包和解包的操作，host-gw模式的话会更快）。

请问您那边是遇到什么问题了么？问题是出从pod冲200多scale到1000？

[linkingli]

是的scale到1000的时候，会出现FailedCreatePodSandBox error，目前更新cni已经解决了，但是还不清楚具体的原因。看看问题还会不会复现吧.sad.

[root@paas-m1 ~]# kubectl version --short
Client Version: v1.11.0+d4cacc0
Server Version: v1.11.0+d4cacc0

          cat <<EOF | {{ bin_dir }}/kubectl create -f -
          apiVersion: "k8s.cni.cncf.io/v1"
          kind: NetworkAttachmentDefinition
          metadata:
            name: macvlan-conf
          spec:
            config: '{
              "cniVersion": "0.3.0",
              "type": "macvlan",
              "master": "eth0",
              "mode": "bridge",
              "ipam": {
                "type": "host-local",
                "subnet": "192.168.1.0/24",
                "rangeStart": "192.168.1.200",
                "rangeEnd": "192.168.1.216",
                "routes": [
                  { "dst": "0.0.0.0/0" }
                ],
              "gateway": "192.168.1.1"
            }
          }'
          EOF

[helios741]

@linkingli 更新的cni指的是升级的CNI的什么呢，ipam么？

[linkingli]

修改了cni的version value ,不知道是不是kube-spray的原因
"cniVersion": "0.3.0",
你说的sum of pod 是那个配置，我还真没注意到

[helios741]

@linkingli 以前的 cniVersion是什么呢？ 你们现在这个集群多少个节点？

[linkingli]

以前的版本
cniVersion="v0.2.0"

node information
paas-m1   Ready     compute,infra,master   6d        v1.11.0+d4cacc0
paas-m2   Ready     compute,infra,master   6d        v1.11.0+d4cacc0
paas-m3   Ready     compute,infra,master   6d        v1.11.0+d4cacc0
paas-w1   Ready     compute                6d        v1.11.0+d4cacc0
paas-w2   Ready     compute                6d        v1.11.0+d4cacc0

一般来说节点的pod数量是不确定的，看服务的nodeselector

[helios741]

以前cniVersion中的0.2.0前面有个v？

根据您ipam的host-local的设置

"ipam": {
                "type": "host-local",
                "subnet": "192.168.1.0/24",
                "rangeStart": "192.168.1.200",
                "rangeEnd": "192.168.1.216",
                "routes": [
                  { "dst": "0.0.0.0/0" }
                ],
              "gateway": "192.168.1.1"
}

一台节点最多能有253 - 17 = 236个pod，您可以查看一下当scale到1000的时候是不是某个node上的数量超过了这个限制。

如果不是这个问题，就要查查cni的各个插件对0.3.0的实现相比于0.2.0有什么bugfix。

[linkingli]

是的，目前追踪版本的release feature,考虑到目前的k8s的版本问题，准备后续优先升级k8s的版本。

[yvanu]

求助， 这个组网模型怎么通不了外网呢？在ns中ping114.114.114.114不通，在宿主机的eth0上抓不到包