在Kubernetes中使用CNI的网络插件优势在哪?


  1. 在Kubernetes中使用CNI网络插件的优势在那?
    目前在宿主机启了个flannel然后docker使用flannel网络感觉也没啥问题啊。

  2. 请求源IP如何获得?
    目前在容器中或得到的IP都是flannel网桥IP
已邀请:

wisen

赞同来自:


对于CNI/CNM之间的优劣,我没什么好说的,无非是网络控制主导力量的撕逼之战。
对于flannel网络方案的话,我想说下:
1. 你需要租户网络隔离吗?
2. 你需要精细的网络规则控制吗?
3. 你想要容器网络直接与外部网络打通吗?(也就是你说的第二个问题)
4. 网络性能(众所周知overlay的性能不咋地)
这些问题都是flannel 的痛点,但是flannel使用简单啊,再说了,你对网络性能要求有那么高吗?三五倍的差距你在乎吗?

yekaifeng - 唯品会云平台开发工程师

赞同来自:


CNI过于简单,接口机制是命令行加环境变量,传参方式不统一,网络信息保存在容器外部,容易导致状态不同步。好处是可以支持多种容器类型。如果用Docker作为容器化实现的话,还是建议用CNM。

tonybai_cn - 关注Go、Docker和Kubernetes

赞同来自:


问题1:
相对cnm这个docker专用网络模型,k8s的cni不局限于docker,它的目标是支持更为广泛的容器提供商的茶品,比如rocket。至于技术细节,cni的确接口很简单,似乎就两个吧。cnm则定义的非常多的接口。具体可以search google。

问题2:
你确认所有源ip都看不到么?如果是k8s的overlay网络内部通信,你看到的应该的源ip应该是overlay网络中的ip吧。如果是外部流量,k8s只会在iptables nat只会DNAT,源ip应该是不变的,否则response的路由就找不到了吧。

要回复问题请先登录注册