• 1. kubernetes网络模型
    • 1.1. 基础原则
    • 1.2. k8s对集群的网络要求
    • 1.3. 网络架构图
    • 1.4. k8s集群IP概念汇总
  • 2. kubernetes的网络实现
    • 2.1. Pod网络
    • 2.2. Pod内部容器之间的通信
    • 2.3. Pod之间的通信
      • 2.3.1. 同Node的Pod之间的通信
      • 2.3.2. 不同Node的Pod之间的通信
    • 2.4. Service网络
  • 3. 开源的网络组件
    • 3.1. Flannel

    1. kubernetes网络模型

    1.1. 基础原则

    1. 每个Pod都拥有一个独立的IP地址，而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中，不管是否运行在同一Node上都可以通过Pod的IP来访问。
    2. k8s中Pod的IP是最小粒度IP。同一个Pod内所有的容器共享一个网络堆栈，该模型称为IP-per-Pod模型。
    3. Pod由docker0实际分配的IP，Pod内部看到的IP地址和端口与外部保持一致。同一个Pod内的不同容器共享网络，可以通过localhost来访问对方的端口，类似同一个VM内的不同进程。
    4. IP-per-Pod模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度看，Pod可以看作是一台独立的VM或物理机。

    1.2. k8s对集群的网络要求

    1. 所有容器都可以不用NAT的方式同别的容器通信。
    2. 所有节点都可以在不同NAT的方式下同所有容器通信，反之亦然。
    3. 容器的地址和别人看到的地址是同一个地址。

    以上的集群网络要求可以通过第三方开源方案实现，例如flannel。

    1.3. 网络架构图

    这里写图片描述

    1.4. k8s集群IP概念汇总

    由集群外部到集群内部：

    IP类型 说明
    Proxy-IP 代理层公网地址IP，外部访问应用的网关服务器。[实际需要关注的IP]
    Service-IP Service的固定虚拟IP，Service-IP是内部，外部无法寻址到。
    Node-IP 容器宿主机的主机IP。
    Container-Bridge-IP 容器网桥（docker0）IP，容器的网络都需要通过容器网桥转发。
    Pod-IP Pod的IP，等效于Pod中网络容器的Container-IP。
    Container-IP 容器的IP，容器的网络是个隔离的网络空间。

    2. kubernetes的网络实现

    k8s网络场景

    1. 容器与容器之间的直接通信。
    2. Pod与Pod之间的通信。
    3. Pod到Service之间的通信。
    4. 集群外部与内部组件之间的通信。

    2.1. Pod网络

    Pod作为kubernetes的最小调度单元，Pod是容器的集合，是一个逻辑概念，Pod包含的容器都运行在同一个宿主机上，这些容器将拥有同样的网络空间，容器之间能够互相通信，它们能够在本地访问其它容器的端口。 实际上Pod都包含一个网络容器，它不做任何事情，只是用来接管Pod的网络，业务容器通过加入网络容器的网络从而实现网络共享。Pod网络本质上还是容器网络，所以Pod-IP就是网络容器的Container-IP。

    一般将容器云平台的网络模型打造成一个扁平化网络平面，在这个网络平面内，Pod作为一个网络单元同Kubernetes Node的网络处于同一层级。

    2.2. Pod内部容器之间的通信

    同一个Pod之间的不同容器因为共享同一个网络命名空间，所以可以直接通过localhost直接通信。

    2.3. Pod之间的通信

    2.3.1. 同Node的Pod之间的通信

    同一个Node内，不同的Pod都有一个全局IP，可以直接通过Pod的IP进行通信。Pod地址和docker0在同一个网段。

    在pause容器启动之前，会创建一个虚拟以太网接口对（veth pair），该接口对一端连着容器内部的eth0 ，一端连着容器外部的vethxxx，vethxxx会绑定到容器运行时配置使用的网桥bridge0上，从该网络的IP段中分配IP给容器的eth0。

    当同节点上的Pod-A发包给Pod-B时，包传送路线如下：

    1. pod-a的eth0—>pod-a的vethxxx—>bridge0—>pod-b的vethxxx—>pod-b的eth0

    因为相同节点的bridge0是相通的，因此可以通过bridge0来完成不同pod直接的通信，但是不同节点的bridge0是不通的，因此不同节点的pod之间的通信需要将不同节点的bridge0给连接起来。

    2.3.2. 不同Node的Pod之间的通信

    不同的Node之间，Node的IP相当于外网IP，可以直接访问，而Node内的docker0和Pod的IP则是内网IP，无法直接跨Node访问。需要通过Node的网卡进行转发。

    所以不同Node之间的通信需要达到两个条件：

    1. 对整个集群中的Pod-IP分配进行规划，不能有冲突（可以通过第三方开源工具来管理，例如flannel）。
    2. 将Node-IP与该Node上的Pod-IP关联起来，通过Node-IP再转发到Pod-IP。

    不同节点的Pod之间的通信需要将不同节点的bridge0给连接起来。连接不同节点的bridge0的方式有好几种，主要有overlay和underlay，或常规的三层路由。

    不同节点的bridge0需要不同的IP段，保证Pod IP分配不会冲突，节点的物理网卡eth0也要和该节点的网桥bridge0连接。因此，节点a上的pod-a发包给节点b上的pod-b，路线如下：

    1. 节点a上的pod-a的eth0—>pod-a的vethxxx—>节点a的bridge0—>节点a的eth0—>
    3. 节点b的eth0—>节点b的bridge0—>pod-b的vethxxx—>pod-b的eth0

    这里写图片描述

    1. Pod间实现通信

    例如：Pod1和Pod2（同主机），Pod1和Pod3(跨主机)能够通信

    实现：因为Pod的Pod-IP是Docker网桥分配的，Pod-IP是同Node下全局唯一的。所以将不同Kubernetes Node的 Docker网桥配置成不同的IP网段即可。

    2. Node与Pod间实现通信

    例如：Node1和Pod1/ Pod2(同主机)，Pod3(跨主机)能够通信

    实现：在容器集群中创建一个覆盖网络(Overlay Network)，联通各个节点，目前可以通过第三方网络插件来创建覆盖网络，比如Flannel和Open vSwitch等。

    不同节点间的Pod访问也可以通过calico形成的Pod IP的路由表来解决。

    2.4. Service网络

    Service的就是在Pod之间起到服务代理的作用，对外表现为一个单一访问接口，将请求转发给Pod，Service的网络转发是Kubernetes实现服务编排的关键一环。Service都会生成一个虚拟IP，称为Service-IP， Kuberenetes Porxy组件负责实现Service-IP路由和转发，在容器覆盖网络之上又实现了虚拟转发网络。

    Kubernetes Porxy实现了以下功能：

    1. 转发访问Service的Service-IP的请求到Endpoints(即Pod-IP)。
    2. 监控Service和Endpoints的变化，实时刷新转发规则。
    3. 负载均衡能力。

    3. 开源的网络组件

    3.1. Flannel

    具体参考Flannel介绍

    参考《Kubernetes权威指南》