版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/huangjun0210/article/details/86703626
kubernetes集群网络
1. kubernetes集群的“三个网络”
- node网络
- pod网络
- service网络
2. kubernetes网络设计面对的问题
- 如何实现跨节点的pod见得通信(东西向流量)
- pod中运行的服务如何被其他pod发现，并且当访问这个服务时的流量如何被负载均衡
- pod的服务如何被暴露到集群外部并服务外部请求(南北向流量)
3. kubernetes网络设计基本要求
让pod像传统物理主机或虚拟机一样被使用：
- 所有pod间均应可以在无需NAT的情况下直接通信
- 所有集群节点与所有集群的pod之间均应可以在无需NAT的情况下直接通信
- 容器自身的地址和其他pod看到的地址是同一个地址
3. kubernetes网络实现
kubernetes并没有原生内置某种网络实现
- CNI（Container Network Interface）成为kubernetes网络第三方实现的主流规范接口
- CNI最初是由Coreos提出的一个容器网络规范
- CNI是目前容器运行时与网络实现之间最简单的接口规范之一
CNI插件模型
CNI工作流程
容器runtime调用CNI网络插件实现网络配置
- 一般CNI网络插件是以独立的可执行文件形式存在
- 调用插件时，数据通过两种方式传递给插件：环境变量或标准输入
- CNI将容器添加到特定网络的一般流程
CNI插件
4. Pod网络实现原理
可能的Pod网络实现选择：
- 二层（交换）方案
- 三层（路由）方案
- Overlay网络方案
4.1 二层（交换）方案
- Pod与Nodes处于同一个二层广播域
- Node的物理网卡桥接到虚拟网桥，开启混杂模式，这样可以将目的MAC地址不是自己的包也转发到Linux Bridge
- 适用于小型kubernetes集群部署
二层（交换）方案
4.2 三层（路由）方案
- 通过路由而不是变换的方式的方式实现pod网络
- 更具扩展性
- 在集群添加或删除Node时自动维护路由表
三层（路由）方案1
三层（路由）方案2
4.3 Overlay网络方案
- 优点：最大程度的保留原网络结构，保证原有网络尽量不做改造
- 不足：Overlay网络方案在传输性能上无法与二层、三层方案相比
- 在节点上维护Overlay网络相关路由，实现Pod与Node间的直接通信
Overlay网络方案
4.4 方案对比
- 二层方案：简单，性能好，但难于扩展，适用于小规模实验环境
- 三层方案：目前生产环境主流使用的一种方案。原生网络的性能是他的优势，同时还具备相比于二层方案更为良好的扩展性
- Overlay方案：最大优势是不改动现有网络结构，但额外负担大导致网络性能不佳
5. Service网络
5.1 Service的特性
Service解决了因Pod的短暂性给开发者带来的开发复杂性问题
- Service是面向Kubernetes云应用的基本构建单元
- Service通过Pod label以及label selector与Pod（endpoint）自动建立联系
- Service会将来自客户端的请求流量自动负载均衡到后面的endpoints上
5.2 Service网络是什么
- Cluster IP：Kubuernetes集群赋予每个Service在集群内部不变的IP地址
- Service网络：所有Service的Cluster IP地址组合而成的“虚拟网络”
- 通过Nodeport将服务暴露到集群外部
外部请求 -> NodeIP:NodePort -> ClusterIP:Port -> ContainerIp:TargetPort
5.3 基于iptables的流量转发与负载均衡
kube-proxy监听服务和端点变化设定和更新iptables规则