calico网络问题的debug过程

  1. Blog
  2. 2018
Thursday 22 March 2018 Calico, Kubernetes

这篇blog 主要是用来记录我最近在开发Magnum的过程中，集成calico和kuberntes的过程中所遇到的一些问题，以及我对calico的一些粗浅的理解。

什么是Calico

calico 同flannel类似，主要为容器提供网络支持。下面的文字摘自calico官方网站对其的描述。

Calico provides secure network connectivity for containers and virtual machine workloads.

Calico creates and manages a flat layer 3 network, assigning each workload a fully routable IP address. Workloads can communicate without IP encapsulation or network address translation for bare metal performance, easier troubleshooting, and better interoperability. In environments that require an overlay, Calico uses IP-in-IP tunneling or can work with other overlay networking such as flannel.

Calico also provides dynamic enforcement of network security rules. Using Calico’s simple policy language, you can achieve fine-grained control over communications between containers, virtual machine workloads, and bare metal host endpoints.

为什么需要Calico

通常提到calico必然提到网络隔离，这是calico 区别于Flannel的主要一点。因此，使用Calico主要是为了实现不同namespaces的网络隔离。

calico 网络问题的debug过程

这个问题实际上是我最近调试 calico 和 kubernetes所遇到的一个实际问题。具体症状是这样的：通过Magnum创建k8s 集群后， kuberntes dashboard pod和coreDNS pod周期性的重启，而且比较频繁。其他pod正常。

下面是我的分析过程，参考了这篇文章

  1. 判断在pod重启之前是否有问题 这个和上面lijiao的博客里所介绍的分析步骤一样，就是看端到端的连通性是否有问题。测试之后发现没问题。

  2. 回到pod的原理本身，重启说明 liveness 健康检查失败，根源在于网络失效，考虑到calico的原因，基本可以确定是calico 引起的

  3. 周期性问题 经过多次不断实验，发现重启的频率基本在8分钟左右，但在重启之前网络是好的。那么说明，一个东西在破坏，一个东西在修复。去calico 的 slack里channel里询问了他们的工程师之后得到了启发，可能和NetworkManager有关系。因为我们用的Fedora Atomic image里默认仍然启用的是NetworkManager, 它会做一些周期性的检查，清理那些它认为不正确的device。遗憾的是，calico 所创建的某些虚拟device可能就在它认为不正确的范围内。造成的结果 就是NetworkManager不断去删，而calico node不断去修复，多么蛋疼的相爱相杀。

最终的解决办法是在Magnum里修改NetworkManager的配置（/etc/NetworkManager/NetworkManager.conf），让它忽略那些calico创建的devices。

[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:tunl*


具体内容请参考我给calico 提交的document PR https://github.com/projectcalico/calico/commit/a676f8ceb7371182acdd0f949c4d08ae992ac738

在K8s中使用Calico的一些“问题”

  1. k8s master node 到底需不需要 calico-node

这个根据我对calico的理解和实际的测试，master node 是需要calico-node的，否则会导致master和node之间的pod无法通信。这么说其实不准确，准确的说法应该是 从master无法访问到其他node上所运行的pod，例如dashboard。例如 dashboard如果运行在某一（几）个node上，那么通过kube-proxy 是需要从master访问到node上运行的 dashboard的pod的。所以如果这时候master上没有calico-node的话，kube-proxy不知道该把包转发到哪个node上去。

  1. pod 和 k8s api server 的通信问题

这个问题我已经忘记当初为什么写在这里了，简单来说pod理论上不需要和api server通信。但如果是特殊的功能性的pod, 那可能是需要的。