初次接触k8s最让我感到复杂的是网络，CNI所涉及的技术名词太多，每种不同类型的CNI都有一套各自的实现。本篇的目的是flannel为切入点对k8s集群pod之间通信有个基本的理解。当然我也不是专业的网工，所以内容不够详尽，只能尽可能描述我所理解的内容。本篇参考了不少网上其他人的博客，更像是内容的缝合。

默认的calico-node之间是full mesh形式的，即所有calico-node之间都会建立BGP连接，如果有200个节点就在整个集群一共建立了4w个BGP连接，当集群节点数量比较多时，路由信息的变更都会带来集群流量的激增，在混合云环境中会带来额外的成本开销，也会对集群应用造成影响。参考网络上的文档，如果集群规模超过100个节点就推荐使用route reflector，本篇记录下我对于集群中自有节点和公有云节点部署route reflector的过程。

本篇想要介绍一下calico的基本原理，阐述以Calico作为CNI时pod间是如何通信的。总的来说，CNI实现主要有两种:

1. 使用 overlay network，如 Flannel，它将pod与pod间的报文包裹在VXLAN报文里面，VXLAN报文会在宿主机之间流动，实际的网络链路不需要感知overlay network的任何信息。
2. 使用纯路由方案，额外配置好一些路由信息，让pod与pod间流量可以被正确的转发，将宿主机作为一个路由器（文档描述是vRouter），使用BGP来同步宿主机之间的路由信息。

虽然总体上可以这样划分，但是各个CNI的功能都比较多，Flannel的host-gw方案将宿主机作为路由器，只要保证宿主机之间可以直接互通。

之前的文章介绍了 iptables ，接下来就可以介绍 service 是如何实现的，本文所需的前置知识是 iptables。

Pod是一个多变的事物，它可能被重建、消亡因此直接以Pod对外提供服务并不是一个很好的选择，为此k8s提供了service能够对外同一个稳定的IP作为提供服务的Pod的入口。本篇从 iptables 规则入手对 service 的工作原理做一个基本介绍。

用户请求到达实际的服务往往经过多轮的负载均衡，这给问题排查带来了额外的难度。在一个 k8s 集群当中，网关（ingress nginx，kong）以nodeport的形式作为集群外负载均衡的后端。最近遇到的问题业务反馈网关负载均衡效果不好，因此我的方案是在kong节点上分析http报文，这可以帮助我们分析是ipvs -> nodeport还是网关->业务pod的负载均衡问题。我借助了BPF_PROG_TYPE_SOCKET_FILTER实现了一个简单的链路最终工具，抓取kong pod的报文。