【云原生】Kubernetes网络知识

Kubernetes网络管理

一、案例概述

• 随着Docker容器化的兴起，云计算面对的挑战越来越大。例如：网络管理、存储等。一个数据中心基本上都有成千个容器，这么多的容器需要运维人员集中管理。而在云计算的世界中，计算是最基础的，存储是最重要的，网络则是最复杂的，。Kubernetes网络的实现不是集群内部自己实现，而是依赖于第三方网络插件。本章主要介绍Kubernetes网络相关知识与Kubernetes网络组件中的一个重要成员——Calico

二、案例前置知识点

2.1、Kubernetes网络模型

• Kubernetes网络模型设计的基础原则是：每个Pod都拥有一个独立的IP地址，而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对象的IP地址进行访问。设计这个原则的原因是，用户不需要额外考虑如果建立Pod之间的连接，也不需要考虑讲容器端口映射到主机端口等问题

• 实际上，在Kubernetes中IP电子hi是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈，实际上就是一个网络命名空间，包括它们的IP地址、网络设备、配置等都是共享的。

Kubernetes对集群网络有如下要求：

• 所有的容器都可以在不用NAT的方式下同别的容器通讯
• 所有节点都可以在不用NAT的方式下同所有容器通讯
• 容器的地址和别人看到的地址是同一个地址

2.2、Docker网络基础

• Kubernetes网络依赖于Docker，Docker网络又离不开Linux操作系统内核特性的支持。所以学习Kubernetes网络之前，有必要 先了解Docker网络的基础知识。下面针对Docker使用到的与Linux网络有关的主要技术进行简单介绍

• 网络命名空间：Linux在网络栈中引入网络命名空间，将独立的网络协议栈隔离到不同的命名空间中。处于不同命名空间的网络栈是完全隔离的，彼此之间无法通信。Docker正式利用这一特性，实现了不同容器之间的网络隔离

• Veth设备对：Veth设备对的引入是为了实现不同网络命名空间之间的通信，利用它可以直接将两个命名空间连接起来。由于要连接两个命名空间，所以Veth设备都是成对出现的

• 网桥：网络是要给二层网络设备，通过网桥可以将Linux支持若干个网络端口“连接”起来，使得网络节点之间的报文能够相互转发，并实现类似于交换机一样的多对多通信

• iptables/Netfilter：Netfilter负责在内核中执行各种挂接的规则，运行在内核模式中；iptables是在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表。通过二者的配合来实现整个Linux网络协议中灵活的数据包处理机制

• 路由：Linux系统包含一个完整的路由功能，当IP层在处理数据发送或者转发的时候，会使用路由表来决定发往哪里

2.3、Kubernetes网络通信

在实际的业务应用场景中，业务组件之间的关系十分复杂。特别是随着微服务的不断发展与成熟，应用部署的粒度也更加细小和灵活。为了支持应用组件之间的通信，kubernetes网络通信主要分为以下几种情况

• Pod内容器与容器之间的通信
• Pod与Pod之间的通信
• Pod与Service之间的通信
• 集群外部与内部组件之间的通信

2.3.1、Pod内容器与内容之间的通信

• 在同一个Pod内的容器（Pod内的容器时不会跨主机的）共享同一个网络命名空间，所以对于网络的各类操作，就和它们在同一台机器上一样，甚至可以用localhost地址访问彼此的端口。Pod内网络拓扑模型如下所示
  

2.3.2、Pod与Pod之间的通信

Pod与Pod之间的通信分为两种情况：同一个Node内Pod之间的通信、不同Node上Pod之间的通信

• 同一个Node内Pod之间的通信

每个Pod都有一个真实的全局IP地址，同一个Node内不同Pod之间可以直接采用对方Pod的IP地址进行通信，不需要采用其他发现机制，例如DNS、Consul或者etcd。同一个Node内Pod之间的关系如下图所示。由下图可以得知，Pod1与Pod2都是通过Veth连接到同一个docker0网桥，地址段相同，所以它们之间可以直接通信

• 不同Node上Pod之间的通信

Pod地址与docker0在同一个网段，docker0网段与宿主机网卡是两个不同的网段，且不同Node之间的通信只能通过宿主机的物理网卡进行。要想实现不同Node上Pod之间的通信，就必须想办法通过主机的这个IP地址进行寻址和通信。因此不同Node中Pod间通信要满足两个条件：Pod的IP地址不能冲突；将Pod的IP和所在的Node的IP关联起来，通过这个关联让Pod可以相互访问

• Pod与Service之间的通信

在kubernetes中Pod的IP地址并不是固定的每当应用程序按比例放大或者缩小，或遇到错误并需要重新启动时，其IP地址将消失并需要重新分配。因此kubernetes引进了Service的感念

Service是一个抽象的实体，kubernetes在创建Service时，会为其分配一个虚拟IP地址。当外界需要访问Pod里的容器提供的功能时，不直接访问Pod的IP地址和端口，而是访问Service的虚拟IP地址和端口，由Service把请求转发给它背后的Pod，kubernetes在创建Service时，根据Service的标签选择器来查找Pod，据此创建与Service同名的EndPoints对象。当Pod的地址发生变化时，EndPoints也随之变化。Service接收到请求时，就能通过EndPoints找到对应的Pod

当然Service只是一个虚拟的概念，真正完成请求转发的是运行在Node节点上的kube-proxy。Service的虚拟IP就是由kube-proxy实现的。kube-proxy有两种请求转发模式：userspace模式和iptables模式

• 集群外部与内部组件之间的通信

ClusterIP类型：这种类型的Service只会得到虚拟的IP和端口，只能在kubernetes集群内部被访问，此模型是默认类型

NodePort类型：这种类型的Service除了会得到虚拟的IP和端口，kubernetes还会在所有Node节点上为其分配端口。分配的端口的值可以通过spec.ports[*].nodePort指定，或由kubernetes在配置好的区间里分配（默认为30000-32767）.这种Service既可以从kubernetes集群通过虚拟IP:端口访问，也可以从集群外部通过Node节点的IP:nodePort访问

LoadBalancer类型：这种类型的Service除了会得到虚拟的IP和端口，kubernetes还会再所有Node节点上为其分配端口，然后为其开通负载均衡。这种Service既可以从kubernetes集群通过虚拟IP:端口访问，也可以从集群外部通过Node节点的IP:nodePort访问，还可以通过负载均衡的IP访问

• K8S网络的实现不是集群内部自己实现，而是依赖于第三方网络插件——CNI，例如Flannel、Calico等

2.4、Flannel网络插件

• Flannel是CoreOS团段针对kubernetes设置的一个网络规划服务。简单来说，它的功能让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的问题是，不同节点上容器可能获得相同的内外IP地址

• Flannel的设计目的就是为了集群中的所有节点重新规划IP地址的使用规划，从而使得不同节点上的容器能够获得“同属于一个内网”且不重复的IP地址，并让属于不同节点上的容器能够直接通过内网IP地址通信

• Flannel实质上是一个“覆盖网络（overlay network）”，也就是将TCP数据包装在另一中网络包里面进行路由转发和通信，目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式，默认的节点间数据通信方式是UDP转发。Flannel具体工作原理如下图所示
  

• 数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到faanel0虚拟网卡，这是个P2P的虚拟网卡，flanneld服务监听的网卡另外一段

• Flannel通过Etcd服务维护了以后一张节点间的路由表。源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直接进入母的节点的flannel0虚拟网卡，之后被转发目的主机的docker0虚拟网卡，最后就像本机容器通信一下的有docker0路由到达目标容器

2.5、Calico网络插件

• Calico是一种基于BGP的、纯三层的、容器间互通的网络方案。与Openstack、kubernetes、AWS、GCE等云平台都能够良好的集成。在虚拟话平台中，如Open stack、Docker等都需要实现workloads之间互联，但同时也需要对容器作隔离控制，就像在internet中的服务仅开放80端口、共有元的多租户一样，提供隔离和管控机制
• 而在多数的虚拟化平台实现中，通常使用二层隔离技术来实现容器的网络，这些二层技术有一些弊端，比如需要依赖VLAN、bridge和隧道技术。其中bridge带来了复杂性，vlan隔离和tunnel隧道则消耗更多的资源并对物理环境有要求，随着网络规模的增大，整体会变得越加复杂。我们尝试把Host当作internet中的路由器，同样使用BGP同步路由并使用iptables来做安全访问策略，最终设计出了calico方案
  

2.5.1、Calico网络模型工作组件

• Felix：运行在每一台Host的agent进程，主要负责网络接口管理和监听、路由、ARP管理、ACL管理和同步、状态上报等
• etcd：分布式键值存储，主要负责网络元数据的一致性，确Calic网络状态的准确性，可以与kubernetes公用
• VGP Client（BIRD）：Calico为每一台Host部署一个BGP Client，使用BIRD实现。BIRD是一个单独的持续发展的项目，实现了众多动态路由协议比如VGP、OSPF、RIP等。在Calico的角色是监听Host上由Felix注入的路由信息，然后通过BGP协议广播告诉剩余Host节点，从而实现网络互通
• BGP Route Reflector：在大型网络规模中，如果仅仅使用BGP client形成mesh全网互联的方案就会导致规模限制，因为所有节点之间俩俩相连，需要N^2个连接，为了解决这个规模问题，可以采用BGP的Route Reflector的方法，使所有BGP client仅与特定RR节点互联并路由同步，从而大大介绍连接数
• CalicoCtl：Calico命令行工具

2.5.2、Calico网络Node之间两种网络

• IPIP

从字面来理解，就是把一个IP数据包又套在一个IP包里，即把IP封装到IP层的一个runnel。它的作用相当于基于IP层的网桥一般来说，普通的网桥是基于mac层的，根本不需要IP，而这个ipip则是通过两端的路由作一个runnel，把两个本来不通的网络通过点对点连接起来

• BGP

边界网关协议是互联网上一个核心的去中心化自治路由协议。它通过维护UP路由表或“前缀”表来实现自治系统（AS）之间的可达性，属于矢量路由协议。BGP不适用传统的内部网关协议（IGP）的指标，而使用基于路径、网络策略或规则集来决定路由。因此，它更适合被称为矢量协议，而不是路由协议。BGP，通俗的讲就是讲接入到机房的多条线路（如电信、联通、移动等）融为一体，实现多线单IP，BGP机房的优点：服务器只需要设置一个IP地址，最佳访问路由是由网络上的骨干路由器根据路由跳数与其他技术指标来确定的，不会占用服务器的任何系统