一个目标：容器操作；两地三中心；四层服务发现；五种Pod共享资源；六个常见的CNI插件；七层负载均衡；八个隔离维度；九种网络模型原则；十种IP地址；数百条产品线；数千台物理机；数以万计的集装箱；一个目标：容器操作Kubernetes(k8s)是一个用于自动化容器操作的开源平台。这些容器操作包括：部署、调度和节点集群扩展。具体功能：自动化容器部署和复制。实时弹性收缩容器尺寸。容器被组织成组，并提供容器之间的负载平衡。调度：容器在哪台机器上运行。组成：kubectl：客户端命令行工具，作为整个系统的运行入口。kube-apiserver：以RESTAPI服务的形式提供接口，作为整个系统的控制入口。kube-controller-manager：执行整个系统的后台任务，包括节点状态、Pod个数、Pod与Service的关联等。kube-scheduler：负责节点资源管理，接收来自kube-apiserver的任务创建Pod，并将它们分配给一个节点。etcd：负责节点间的服务发现和配置共享。kube-proxy：运行在各个计算节点上，负责Pod网络代理。定期从etcd中获取服务信息，以制定相应的策略。kubelet：运行在各个计算节点上，作为代理，接收分配给该节点的Pods任务并管理容器，周期性获取容器状态，反馈给kube-apiserver。DNS：可选的DNS服务，用于为每个Service对象创建DNS记录，以便所有Pod都可以通过DNS访问该服务。下面是k8s的架构拓扑图：两地三中心，两地三中心，包括本地生产中心，本地容灾中心，异地容灾中心。两地三中心要解决的一个重要问题就是数据的一致性问题。k8s使用etcd组件作为高可用强一致的服务发现存储仓库。用于配置共享和服务发现。它诞生于受Zookeeper和doozer启发的项目。除了具备它们的所有功能外，它还具有以下4个特点：简单：基于HTTP+JSON的API，让您可以轻松使用curl命令。安全性：可选的SSL客户端身份验证机制。快速：每个实例支持每秒千次写入操作。可信：使用Raft算法完全分布式。四层服务发现先用一张图来解释一下七层网络协议：k8s提供了两种服务发现方式：环境变量：kubelet在创建Pod时，会将集群中所有Service的相关环境变量注入到Pod中.需要注意的是，如果要将一个Service的环境变量注入到一个Pod中，Service必须先于Pod创建。这几乎让这种方式的服务发现无法使用。比如一个ServiceName为redis-master的Service，对应的ClusterIP:Port为10.0.0.11:6379，对应的环境变量为：DNS：可以通过集群插件轻松创建KubeDNS，用于监控Service中的Servicecluster执行服务发现。以上两种方式，一种是基于TCP的，DNS是基于UDP的，都是建立在四层协议之上的。五种Pod共享资源Pod是k8s最基本的运行单元，它包含一个或多个密切相关的容器。Pod可以被容器化环境视为应用层的“逻辑主机”；一个Pod中的多个容器应用通常是紧耦合的，Pod的创建、启动或销毁都在Node上；每个Pod运行都有一个特殊的挂载卷，称为Volume，因此它们之间的通信和数据交换更加高效。我们可以在设计时充分利用这个特性，将一组密切相关的服务进程放到同一个Pod中。同一个Pod中的容器只能通过localhost相互通信。一个Pod中的应用容器共享五种资源：PIDNamespace：一个Pod中的不同应用可以看到其他应用的进程ID。NetworkNamespace：一个Pod中的多个容器可以访问相同的IP和端口范围。IPC命名空间：Pod中的多个容器可以使用SystemVIPC或POSIX消息队列进行通信。UTS命名空间：一个Pod中的多个容器共享一个主机名。Volumes（共享存储卷）：Pod中的单个容器可以访问在Pod级别定义的卷。Pod的生命周期由ReplicationController管理；它是由模板定义的，然后分配给一个Node来运行。Pod中包含的容器运行完毕后，Pod结束。Kubernetes为Pod设计了一套独特的网络配置，包括为每个Pod分配一个IP地址，使用Pod名称作为容器间通信的主机名等。CNI的六大常用插件CNI（ContainerNetworkInterface）容器网络接口是一套用于Linux容器网络配置的标准和库。用户需要基于这些标准和库开发自己的容器网络插件。CNI只专注于解决容器网络连接和容器销毁时的资源释放，提供了一套框架。所以CNI可以支持大量不同的网络模式并且易于实现。下图展示了六种常用的CNI插件：七层负载均衡提到负载均衡，首先要提到服务器之间的通信。IDC（InternetDataCenter）也可以称为数据中心或机房，用于放置服务器。IDC网络是服务器之间通信的桥梁。上图中画了很多网络设备。它们的用途是什么？路由器、交换机、MGW/NAT都是网络设备，根据性能和内外网的不同，划分不同的角色。内网接入交换机：又称TOR（topofrack），是服务器接入网络的设备。每台内网接入交换机连接40-48台服务器，掩码为/24的网段作为服务器内网网段。内网核心交换机：负责IDC内各内网接入交换机的流量转发和跨IDC的流量转发。MGW/NAT：MGW或LVS用于负载均衡，NAT用于内网设备访问外网时进行地址转换。外网核心路由器：通过与运营商静态互联或BGP互联美团统一外网平台。先说说各层的负载均衡：二层负载均衡：基于MAC地址的二层负载均衡。三层负载均衡：基于IP地址的负载均衡。四层负载均衡：基于IP+端口的负载均衡。七层负载均衡：基于URL等应用层信息的负载均衡。这里用一张图来说明四层和七层负载均衡的区别：上面的四层服务发现主要讲的是k8s原生的kube-proxy方式。k8s的服务暴露主要是通过NodePort，通过绑定minion主机的某个端口，然后进行Pod请求转发和负载均衡，但是这种方式有以下缺陷：可能有很多Service，如果每个Service绑定一个Node主机端口，主机需要开放外设端口用于服务调用，导致管理混乱。无法应用许多公司要求的防火墙规则。理想的方式是通过外部负载均衡器绑定一个固定的端口，比如80；然后根据域名或者服务名转发给后续的ServiceIP。Nginx很好的解决了这个需求，但是问题是如果新增了一些服务，如何修改和加载这些Nginx的配置呢？Kubernetes给出的解决方案是Ingress。这是一个基于七层的方案。八类隔离维度k8s集群调度需要对上述隔离从上到下，从粗粒度到细粒度有相应的调度策略。九大网络模型原则k8s网络模型必须遵守四项基本原则，三项网络需求原则，一项架构原则，一项IP原则。每个Pod都有一个独立的IP地址，假设所有的Pod都在一个直连的、扁平的网络空间中，不管它们是否运行在同一个Node上，都可以通过Pod的IP进行访问。k8s中Pod的IP是最小粒度的IP。同一个Pod中的所有容器共享一个网络堆栈，称为IP-per-Pod模型。Pod实际上是由docker0分配的IP。在Pod内部看到的IP地址和端口与在外部看到的相同。同一个Pod中的不同容器共享网络，可以通过localhost访问彼此的端口，类似于同一个虚拟机中的不同进程。IP-per-Pod模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度来看，一个Pod可以看作是一个独立的虚拟机或物理机。所有容器都可以在没有NAT的情况下与其他容器通信。所有节点都可以在不同的NAT方法下与所有容器通信，反之亦然。容器的地址和别人看到的地址是一样的。必须符合如下架构：从上面的架构衍生出来，IP的概念是从集群外部到集群内部：十类IP地址。大家都知道IP地址分为ABCDE类型，有五种特殊用途的IP。第一类A类：1.0.0.0-1226.255.255.255，默认子网掩码/8，即255.0.0.0。B类：128.0.0.0-191.255.255.255，默认子网掩码/16，即255.255.0.0。C类：192.0.0.0-223.255.255.255，默认子网掩码/24，即255.255.255.0。D类：224.0.0.0-239.255.255.255，一般用于组播。E类：240.0.0.0-255.255.255.255（其中255.255.255.255是全网广播地址）。E类地址通常用于研究目的。第二类0.0.0.0严格来说，0.0.0.0已经不是真正的IP地址。它代表这样一个集合：所有未知的主机和目的网络。这里不清楚是指在本地路由表中没有具体的条目指示如何到达那里。作为默认路由。127.0.0.1本地机器地址。第三类224.0.0.1多播地址。如果你的主机启用了IRDP（internetroutingdiscovery，使用多播功能），那么你的主机路由表中应该有这样一条路由。第四类169.254.x.x利用DHCP功能自动获取IP主机。如果DHCP服务器出现故障，或者响应时间过长，超过了系统规定的时间，系统就会给你分配这样一个IP，网络就不能正常运行了。.第五类10.xxx、172.16.x.x~172.31.x.x、192.168.x.x私有地址。在企业内部广泛使用。该地址是为了避免访问公网时地址混淆而保留的。转自：stackpush链接：blog.csdn.net/huakai_sun/article/details/82378856
