k8s基本网络模型
k8s网络基本要求：三个要求+四个目标
k8s对于pod间的网络没有任何限制，只需满足如下三个基本条件:
- 所有Pod可以与其它Pod直接通信，无需显示使用NAT
- 所有Node可以与所有Pod直接通信，无需显示使用NAT
- Pod可见的IP地址确为其他Pod与其通信时所用，无需显示转换
k8s的网络方案要有以下四大目标：
- 容器与容器间的通信
- Pod与Pod之间的通信
- Pod与Service间的通信
- 外部与Service之间的通信
对基本约束的解释
容器与其宿主存在寄生关系，从而在实现上，容器网络方案可分为Underlay/Overlay两种。其主要的差异在于是否与Host网络同层，这样对于微服务的发现及治理，容器可访问方式都造成很大的差异，所以以perPodperIP这种简单的模型，摒弃了显示端口映射等NAT配置，统一了容器网络对外服务的视角。
Netns探秘
Netns究竟实现了什么
Network namespace是实现网络虚拟化的内核基础，创建了隔离的网络空间
- 拥有独立的附属网络设备（lo、veth等虚设备/物理网卡）
- 独立的协议栈，IP地址和路由表
- iptables规则
- ipvs等
Pod与Netns的关系
每个Pod拥有独立的Netns空间，Pod内部的Container共享该空间，可通过Loopback接口实现通信，或通过共享的Pod-IP对外提供服务。宿主上还有Root Netns，可以看作一个特殊的容器空间。
主流网络方案简介
典型容器网络实现方案
依据IaaS层的配置、外部物理网络的设置、性能或灵活性优先，可以有不同的实现：
- Flannel：最普遍的实现，提供多种网络backend实现，覆盖多种场景
- Calico，采用BGP提供网络直连，功能丰富，对底层网络有要求
- Canal（Flannel for network + Calico for firewalling），嫁接创新项目
- Cilium，基于eBPF和XDP的高性能Overlay网络方案
- Kube-router，同样采用BGP提供网络直连，继承基于LVS的负载均衡能力
- Romana，采用BGP 或 OSPF提供网络直连能力的方案
- WeaveNet，采用UDP封装实现L2 Overlay，支持用户态（慢，可加密）/内核态（快，不能加密）两种实现
Flannel方案
Flannel是目前使用最为普遍的方案，通过将backend机制独立，它目前已经支持多种数据路径，也可以适用于overlay/underlay等多种场景，封装可以选用用户态udp（纯用户态实现），内核VxIan（性能好），如集群规模不大，处于同一二层域，也可以选择host-gw方式。
Network Policy的用处
Network Policy的概念
Network Policy提供了基于策略的网络控制，用于隔离应用并减少攻击面。它使用标签选择器模拟传统的分段网络，并通过策略控制他们之间的流量以及来自外部的流量。
在使用Network Policy之前，需要注意：
- apiserver开启extensions/v1beta1/networkpolicies
- 网络插件要支持Network Policy，如Calico、Romana、Weave Net和trireme等
配置实例
功能：通过使用标签选择器（包括namespaceSelector和podSelector）来控制Pod之间的流量
要决定三件事：
- 控制对象：通过spec字段，podSelector等条件筛选
- 流方向：Ingress（入Pod流量）+from，Egress（出Pod流量）+to；
- 流特征：对端（通过name/pod Selector), IP段（ipBlock），协议（protocol），端口（port）
小结总结
- Pod在容器网络中的核心概念是IP，每个Pod必须有内外视角一致的独立IP地址
- 影响容器网络性能的关键是拓扑设计，也就是数据包端到端的路径设计
- Overlay/Underlay下各种网络方案的设计选择，如果不知道，可以这样选：普适性最强—Flannel-VxLan，2层可直连—Calico/Flannel-Hostgw
- Network Policy是个强大的工具，可以实现I/Engress的流量精准控制，关键是选择好Pod Selector, 定义好流特征
