登录自治区建设厅的网站查询,如何修改网站底部,长沙十大必去景点,自动获取网站缩略图Kubernetes网络管理 文章目录 Kubernetes网络管理一、案例概述二、案例前置知识点2.1、Kubernetes网络模型2.2、Docker网络基础2.3、Kubernetes网络通信2.3.1、Pod内容器与内容之间的通信2.3.2、Pod与Pod之间的通信 2.4、Flannel网络插件2.5、Calico网络插件2.5.1、Calico网络模…Kubernetes网络管理 文章目录 Kubernetes网络管理一、案例概述二、案例前置知识点2.1、Kubernetes网络模型2.2、Docker网络基础2.3、Kubernetes网络通信2.3.1、Pod内容器与内容之间的通信2.3.2、Pod与Pod之间的通信 2.4、Flannel网络插件2.5、Calico网络插件2.5.1、Calico网络模型工作组件2.5.2、Calico网络Node之间两种网络 一、案例概述
随着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网络依赖于DockerDocker网络又离不开Linux操作系统内核特性的支持。所以学习Kubernetes网络之前有必要 先了解Docker网络的基础知识。下面针对Docker使用到的与Linux网络有关的主要技术进行简单介绍 网络命名空间Linux在网络栈中引入网络命名空间将独立的网络协议栈隔离到不同的命名空间中。处于不同命名空间的网络栈是完全隔离的彼此之间无法通信。Docker正式利用这一特性实现了不同容器之间的网络隔离 Veth设备对Veth设备对的引入是为了实现不同网络命名空间之间的通信利用它可以直接将两个命名空间连接起来。由于要连接两个命名空间所以Veth设备都是成对出现的 网桥网络是要给二层网络设备通过网桥可以将Linux支持若干个网络端口“连接”起来使得网络节点之间的报文能够相互转发并实现类似于交换机一样的多对多通信 iptables/NetfilterNetfilter负责在内核中执行各种挂接的规则运行在内核模式中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把请求转发给它背后的Podkubernetes在创建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 ClientBIRDCalico为每一台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节点互联并路由同步从而大大介绍连接数CalicoCtlCalico命令行工具
2.5.2、Calico网络Node之间两种网络
IPIP
从字面来理解就是把一个IP数据包又套在一个IP包里即把IP封装到IP层的一个runnel。它的作用相当于基于IP层的网桥一般来说普通的网桥是基于mac层的根本不需要IP而这个ipip则是通过两端的路由作一个runnel把两个本来不通的网络通过点对点连接起来
BGP
边界网关协议是互联网上一个核心的去中心化自治路由协议。它通过维护UP路由表或“前缀”表来实现自治系统AS之间的可达性属于矢量路由协议。BGP不适用传统的内部网关协议IGP的指标而使用基于路径、网络策略或规则集来决定路由。因此它更适合被称为矢量协议而不是路由协议。BGP通俗的讲就是讲接入到机房的多条线路如电信、联通、移动等融为一体实现多线单IPBGP机房的优点服务器只需要设置一个IP地址最佳访问路由是由网络上的骨干路由器根据路由跳数与其他技术指标来确定的不会占用服务器的任何系统
