企业级运维之云原生与Kubernetes实战课程
第一章第6讲 Kubernetes网络
视频地址：https://developer.aliyun.com/learning/course/913/detail/14600
摘要：本小节主要内容为K8s容器网络介绍，包括：网络约束和目标、节点内的Pod通信、跨节点的Pod通信、Pod与Netns的关系、典型容器网络实现方案。
1. Kubernetes网络约束和目标
Kubernetes对于Pod间的网络没有任何限制，只需满足如下三个基本条件：
- 所有Pod可以与其他Pod直接通信，无需显式使用NAT；
- 所有Node可以与所有Pod直接通信，无需显式使用NAT；
- Pod可见的IP地址确为其他Pod与其通信时所用，无需显式转换；
基于以上准入条件，我们在审视一个网络方案的时候，需要考虑如下四大目标：
- 容器与容器间的通信；
- Pod与Pod之间的通信；
- Pod与Service间的通信；
- 外部世界与Service间的通信；
2. 对约束的解释
容器与其宿主存在寄生关系，从而在实现上，容器网络方案可分为 Underlay和Overlay两大派别，其主要的差异在于：是否与Host网络同层，这样对于微服务发现及治理，容器可访问方式都造成很大的差异，所以社区的同学以 perPodperIP这种简单武断的模型，摒弃了显示端口映射等NAT配置，统一了容器网络对外服务的视角。
3. 节点内的Pod通信
每个Pod都有其自身的Netns，通过一个虚拟的以太网对连接到root netns。这基本是一个管道对，一端在root netns内，另一端在Pod的netns内。
节点内Pod1与Pod2的通信
如图节点内Pod1与Pod2的通信：首先Pod1的eth0流量会先到vethxxx，再到cbr0，然后到vethyyy，再到Pod2的eth0。
4. 跨节点的Pod通信
每个节点都为Pod IPs分配了唯一的CIDR块，有不同的网络命名空间、网络接口以及网桥。
跨节点的Pod1与Pod3的通信
如图跨节点的Pod1与Pod3的通信，需要通过路由规则转发，因为Pod1的ip和Pod3的IP不同，而且如果网络是Flanneld的话，这两个Pod还不在同一个网段，只能通过路由转发。
当Pod3接收到来自Node1节点上Pod1的eth0包，在回包时如何确认eth0与Pod1有关系呢？
如图，如果网络使用Flanneld方案，首先会在每个节点上创建不同的Docker和Flannel网段，通过Docker的网段分发每个Pod的IP，比如节点1是10.1.15.1/24，节点2上是10.1.20.3/24，而Pod内的网段是在节点网段内的，在进行流量分发时，Pod1上的流量首先经过Docker0通过Flanneld，而Flanneld会读取etcd保存的Pod节点所在的信息，进而将流量进行转发，实现了整个网络的流通性。
5. Netns究竟实现了什么
Network namespace是实现网络虚拟化的内核基础，创建了隔离的网络空间。
- 拥有独立的附属网络设备（Io、veth等虚设备/物理网卡）；
- 独立的协议栈，IP地址和路由表；
- iptables规则；
- ipvs等；
6. Pod与Netns的关系
每个Pod拥有独立的Netns空间，Pod内的Container共享该空间，可通过Loopback接口实现通信，或通过共享的Pod-IP对外提供服务。宿主上存在RootNetns，可以看做一个特殊的容器空间。
7. 典型容器网络实现方案
容器网络可能是Kubernetes领域最为百花齐放的一个领域，依照laaS层的配置、外部物理网络的设备、性能or灵活优先，可以有不同的实现：
- Flannel：最为普遍的实现，提供多种网络backend实现，覆盖多种场景；
- Calico：采用BGP提供网络直连，功能丰富，对底层网络有要求；
- Canal：Flannel for network + Calico for firewalling，嫁接型创新项目；
- Cilium：基于eBPF和XDP的高性能Overlay网络方案；
- Kube-router：同样采用BGP提供网络直连，集成基于 LVS的负载均衡能力；
- Romana：采用BGP or OSPF 提供网络直连能力的方案；
- WeaveNet：采用UDP封装实现L2 Overlay，支持用户态(慢，可加密)/内核态(快，不能加密)两种实现；
8. Flannel方案
Flannel是目前使用最为普遍的方案，通过将Backend机制独立，它目前已经支持多种数据路径，也可以适用于overlay/underlay等多种场景，封装可以选用用户态udp(纯用户态实现)，内核Vxlan(性能好)，如集群规模不大，处于同一二层域，也可以选择 host-gw方式。
9. Network Policy基本概念
Network Policy提供了基于策略的网络控制，用于隔离应用并减少攻击面。它使用标签选择器模拟传统的分段网络，并通过策略控制它们之间的流量以及来自外部的流量。
在使用Network Policy之前需要注意：
- apiserver开启 extensions/v1beta1/networkpolicies；
- 网络插件要支持 Network Policy，如Calico、Romana、Weave Net和trireme等；
K8s的Network Policy就是网络ACL，是基于CNI、terway、clico网络类型的集群，基于pod维度实现IP/ns/Pod的访问控制。
比如某个Pod的label为1，可以设置default的命名空间无法访问，也可以设置哪些IP可以访问含有label为1的Pod，Pod和Pod之间可以设置，如Pod label为2的Pod不能访问label为1的Pod等。
第一章总结
