一个目标:容器操作；两地三中心；四层服务发现；五种Pod共享资源；六个CNI常用插件；七层负载均衡；八个隔离维度；九个网络模型原则；十类IP地址；百级产品线；千级物理机；万级容器；无亿，K8s亿：亿级日服务人数。
Kubernetes（k8s）是自动化容器操作的开源平台。这些容器操作包括：部署、调度和节点集群扩展。
部署和复制自动化容器。
实时弹性收缩容器的规模。
容器分组排列，提供容器之间的负载平衡。
调度：容器在哪台机器上运行。
kubectl:作为整个系统的操作入口，客户端命令行工具。
kube-apiserver:以REST API服务形式提供接口，作为整个系统的控制入口。
kube-controller-manager:整个系统的后台任务，包括节点状态，Pod个数、Pods和Service的关联等。
kube-scheduler:节点资源管理负责接收kube-apiserver创建Pods并将任务分配到某个节点。
etcd:负责节点间的服务发现和配置共享。
kube-proxy:负责每个计算节点的运行Pod网络代理。定期从etcd获取到service做相应的策略。
kubelet:作为每个计算节点运行agent，接收分配该节点的Pods任务和管理容器，定期获取容器状态，反馈kube-apiserver。
DNS：一个可选的DNS为每一个服务Service对象创建DNS记录，这样所有的Pod就可以通过DNS访问服务。
两地三中心包括当地生产中心、当地灾备中心、异地灾备中心。
两地三中心要解决的一个重要问题是数据一致性。k8s使用etcd组件作为一种高可用性、强一致性的服务发现仓库。用于配置共享和服务发现。
作为一种收获Zookeeper和doozer启发产生的项目。除其所有功能外，还具有以下四个特点：
简单：基于http json的api让你用curl可以轻松使用命令。
安全：可选SSL客户认证机制。
快速:每个例子每秒支持1000次写作。
可信：使用Raft该算法充分实现了分布式。
第一张图解释网络七层协议：
k8s服务发现提供了两种方式：
当创建一个环境变量时：Pod的时候，kubelet会在该Pod集群中注入一切Service相关的环境变量。需要注意的是，想要一个Pod中注入某个Service必须有环境变量Service要先比该Pod创建。这几乎使得这种服务发现不可用。
比如，一个ServiceName为redis-master的Service，对应的ClusterIP:Port为10.0.0.11:6379，相应的环境变量为:
DNS：可以通过cluster add-on轻松创造KubeDNS来到集群内Service服务发现。
以上两种方法，一种是基于tcp，众所周知，DNS是基于UDP都是基于四层协议。
Pod是K8s最基本的操作单元包括一个或多个密切相关的容器和一个Pod逻辑宿主机可以被容器化环境视为应用层；Pod多个容器的应用通常是紧密耦合的，Pod在Node每一个都被创造、启动或销毁；Pod一个特殊的操作被称为Volume因此，他们之间的通信和数据交换更有效，在设计过程中，我们可以充分利用这一特将一组密切相关的服务流程放入同一个过程中Pod中。
同一个Pod容器之间只需要通过localhost互相交流。
一个Pod应用容器共享五种资源：
PID命名空间：Pod不同的应用程序可以看到其他应用程序的过程ID。
网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围。
IPC命名空间：Pod可以使用多个容器SystemV IPC或POSIX通信消息队列。
UTS命名空间：Pod多个容器共享一个主机名。
Volumes(共享存储卷):Pod可以访问中间的每个容器Pod级别定义的Volumes。
Pod通过生命周期Replication Controller管理；定义模板，然后分配到一个Node上运行，在Pod所包含的容器运行后，Pod结束。
Kubernetes为Pod为每个人设计了一套独特的网络配置，包括：Pod分配一个IP地址，使用Pod荣期间通信的主机名称等。
CNI(Container Network Interface)是的，容器网络接口Linux用户需要根据这些标准和库开发自己的容器网络插件。CNI只注重解决容器网络连接和容器销毁时的资源释放，提供一套框架CNI可支持大量不同的网络模式，易于实现。
下面用一张图表示六个CNI常用插件：
提到负载平衡，必须先提到服务器之间的通信。
IDC(Internet Data Center),也可称 数据中心、机房，用来放置服务器。IDC网络是服务器间通信的桥梁。
上图中画了很多网络设备。它们是干什么用的？
路由器、交换机、MGW/NAT它们都是网络设备，根据性能和内外网络划分不同的角色。
内网接入交换机：也称为TOR(top of rack),是服务器接入网络的设备。每台内网接入交换机下联40-48台服务器，服务器内网段采用掩码/24的网段。
内网核心交换机：IDC内量转发和跨内网接入交换机IDC流量转发。
MGW/NAT：MGW即LVS用于负载平衡，NAT用于内网设备访问外网时的地址转换。
外网核心路由器:静态互联运营商或BGP互联美团统一外网平台。
先说各层负载均衡:
二层负载平衡：基于MAC地址二层负载均衡。
三层负载均衡：基于IP地址负载平衡。
四层负载均衡：基于IP 端口负载均衡。
七层负载平衡：基于URL平衡应用层信息的负载。
以下是四层和七层负载平衡的区别：
上述四层服务的发现主要是k8s原生的kube-proxy方式。K8s服务暴露主要是通过NodePort通过绑定的方式minion然后进行主机的某个端口pod要求转发与负载平衡，但这种方法存在以下缺陷：
Service如果每个人都绑定一个，可能会有很多node对于主机端口，主机需要打开外围端口进行服务调用，管理混乱。
许多公司要求的防火墙规则无法应用。
理想的方法是通过外部负载平衡器绑定固定端口，如80，然后根据域名或服务名向后移动Service ip转发，Nginx这一需求得到了很好的解决，但问题是如何修改有经验的服务Nginx并加载这些配置？Kubernetes给出的计划是Ingress。这是基于7层的方案。
K8s在集群调度方面，需要对从上到下从粗粒到细粒的隔离进行相应的调度策略。
K8s网络模型应符合四个基本原则，三个网络要求原则，一个架构原则，一个架构原则，一个IP原则。
每个Pod都有独立IP假设所有地址Pod无论是否直接连接在一个平坦的网络空间中，行在同一Node上都可以通过Pod的IP来访问。
K8s中的Pod的IP是最小粒度IP。同一个Pod内所有的容器共享一个网络堆栈，该模型称为IP-per-Pod模型。
Pod由docker0实际分配的IP
Pod内部看到的IP地址和端口与外部保持一致
同一个Pod内的不同容器共享网络，可以通过localhost来访问对方的端口，类似同一个VM内不同的进程。
IP-per-Pod模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度看，Pod可以看做是一台独立的VM或物理机。
所有容器都可以不用NAT的方式同别的容器通信。
所有节点都可以在不同NAT方式下同所有容器心痛，反之亦然。
容器的地址和别人看到的地址是同一个地址。
要符合下面的架构：
由上图架构引申出来IP概念从集群外部到集群内部
大家都知道IP地址分为ABCDE类，另外还有5类特殊用途的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（internet路由发现，使用组播功能），那么你的主机路由表中应该有这样一条路由。第四类
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