07-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规则