一、架构描述
1、基本架构
2、pod ，有两类
a、自主式pod
自我管理的，创建之后，任然是需要提交给API Server，API Server接受之后然后由调度器调度到指定的 node节点，由node启动此pod，如果有pod中的容器出现故障，需要重启容器时需要kubelet来完成的，但是，如果节点故障了那么这个pod就消失了。没法实现全局调度。
b、控制器管理的pod。
1）、正是控制器的引入和使用，使得在k8s的集群设计中pod完成可以成为有生命周期的对象。由调度器将其调度到集群中的某节点运行以后任务也就被终止了，但是有一些任务比如nginx或tomcat时，他们是作为守护进程运行的这种如果运行为pod容器的话要确保时刻处于运行状态，一旦出现故障我们必须要第一时间发现，要么是取代他要么是重启他。因此k8s提供了pod控制器来时刻监控pod状态。
2）、最早的控制器叫ReplicationController(副本控制器)
a)、时刻保持定义pod的副本数。
b）、还能实现滚动更新，有两个pod副本，先创建一个pod删掉一个老的pod然后再创建一个pod再删除一个老的pod。
3）、新版本后又是新版本控制器叫ReplicaSet(副本集控制器)，他不直接使用，他有一个声明式更新的控制器Deployment来负责管理，Deployment控制器还支持二级控制器，叫HPA（HorizontalPodAutoscaler：水平pod自动伸缩控制器）。Deployment只能管理那些无状态的应用。
4）、有状态的应用需要使用新的控制器叫statefulSet(有状态副本集)。
5）、如果我们需要在每一个node上运行一个副本那么叫DaemonSet
6）、如果运行作业叫job
7）、周期化容器作业Ctonjob。
3、服务发现service（注册中心,zookeepr等都算）
a）、k8s为每一组提供同类服务的pod和客户端之间添加了一个中间层，这个中间层就叫service，service只要不删除那么他的名称和地址就是固定的。当访问某一个服务时，不用自动再去发现什么功能，他只需要在配置文件中写明这个服务的地址或者服务的名称就行。而这个服务不但能提供一个稳定的访问入口，并且还能起到调度器的功能，服务能将请求代理到后端的Pod上，一旦pod宕机了那么又会自动新建一个pod和service关联。service关联后端的pod不是通过ip地址或者主机名，而是通过lable，因此只要你创建的pod lable只要是固定的那么都能被service识别，当pod被关联进service后service才会探测pod的ip地址和主机名作为自己调度的后端可用服务器主机对象。在k8s中service不是应用程序也不是组件，而是iptable中的dnet规则。我们创建一个dnat规则说所有到达某地址的都统统被目标地址转换成某某某地址。当前iptables已经把负载均衡的功能交给ipvs来实现，因此如果service背后的同一组pod由很多dnat来实现那么调度效果上可能不尽人意，因此，1. 11版本中已经把iptables规则进一步改成了ipvs规则，也就意味着当创建一个service就相当于生成了一条nat 模型的ipvs规则。因此支持用户自己指定调度算法，因此lvs算是基础性服务。
b）、service作为k8s对象来讲，有service名称，而service的名称也相当于是这个服务的名称，可以被解析，可以把service名直接解析为service IP，名称解析靠dns，我们装完k8s集群后你会发现第一件事就是需要在k8s集群上部署一个dns pod以确保各dns被解析。因此dns pod是基础级的系统架构级的对象。因此他们也被称为集群的附件（AddOns）。
c)、在k8s中创建资源是这样的：比如需要创建一个nginx pod，首先定义一个nginx pod控制器，把控制器创建出来他会自动帮你创建出相关的pod来，service需要手动创建，然后将两个nginx发布出去让外部能够发布到，也可以只发布到集群内部只让集群内部能够访问。
4、附件（AddOns）
a）、DNS。service作为k8s对象来讲，有service名称，而service的名称也相当于是这个服务的名称，可以被解析，可以把service名直接解析为service IP，名称解析靠dns，我们装完k8s集群后你会发现第一件事就是需要在k8s集群上部署一个dns pod以确保各dns被解析。因此dns pod是基础级的系统架构级的对象。因此他们也被称为集群的附件(AddOns)。DNS会动态更新解析记录，当集群中IP或名称有变动时DNS pod中的解析记录也会动态改变。
b）、各监控组件， 如普罗米修斯 + granfa
二、kubernetes核心组件
1、整体描述
三、k8s网络模型，k8s要求集群中要有三种网络。
1、pod网络：各pod运行在同一网络中
2、service网络（集群网络）：service网络地址和pod地址是不在同一网段的，pod 地址是配置在pod内部的网络名称空间中，是可以ping通的。而service是一个虚拟地址，只存在于iptables规则中。
3、节点网络。
因此有访问请求时首先到达至节点网络由节点网络代理至集群网络，再由集群网络代理至pod网络。
四、k8s三位通信：那么pod与pod之间是怎样通信的呢，其实在k8s上还存在三位通信。
1、同一pod内的多个容器之间靠 lo回环接口通信。
2、无论是否运行在同一节点上，各pod之间都在同一网段，并且可以直接进行通信。（overlay network：叠加网络）
3、pod与service之间的通信。只要创建一个service那么这个规则会反应到集群每一个节点上，因此当有一个容器要访问service时那么首先会把请求发送到网关，一般是docker0桥的地址，然后docker0桥一检查iptables规则时就能发现这个规则，所pod有改变那么service转发的目标地址也会改变，那么怎么样才能使每个节点上的该service规则都改变呢，此时需要运行在每个node之上的组件kube-proxy，他负责与api-server 进行通信，每个pod发生变化后是需要保存在API Server中的，而API Server通信内容发生改变后会生成通知事件，这个事件可以被任何关联的组件接收到，一旦发现某一service背后的pod(地址)发生改变，那么由kube-proxy负责在本地把此ip地址反应在iptables 或 ipvs中，因此service 的管理是由kube-proxy实现的。
五、k8s证书
1、API Server 需要存集群中的各对象的信息，因此各master 之间需要共享存储。对master来讲，所有数据并不放在本地，而是放在共享存储 etcd 中。etcd是一个键值存储的输出系统，和redis有点像，更有点像zookeeper(支持选举),并且etcd需要做高可用，并且其也是restful集群（通过http或https通信）。一个端口进行集群内部通信，一个端口用于提供客户端服务。因此，内部通信需要专门的点对点证书来配置https。向客户端（api server）提供服务的时候http协议要想加密需要用另外一套证书实现。同理，k8s的API Server http协议也需要加密用https，使用另外一套证书。因为他是k8s客户端和服务端之间通信。而且最好和etcd 不要属于同一个ca来签署。
2、所需证书清单如下：
a、etcd 内部通信需要一套ca和签署证书。
b、etcd 向客户端（API server）提供通信需要一套ca和一套证书。
c、api server向客户端提供服务需要一套ca和一套证书。
d、api server和各node的kubelet组件通信需要一套ca和证书。
e、api server和各node的kube-proxy组件通信需要一套ca和证书。
因此要手动部署一套k8s你至少需要建5套私有ca，为了足够安全。
六、k8s网络插件
1、k8s本身不提供三位网络，由第三方插件提供，也可以作为附件使用 。无论是哪个第三方网络服务商提供的网络解决方案都应该负责至少管理两种网络：pod网络和集群网络。节点网络由自己规划。k8s通过CNI（容器网络接口）插件体系来接入外部的解决方案。只要你是网络服务提供商，能遵循CNI开发这个服务，那么就能作为k8s的网络解决方案来使用。这些网络解决方案可以以附件的方式托管运行在集群之上。他们虽然托管运行在网络集群之上，但是他们需要共享节点的网络名称空间，这样就能以容器的方式来进行系统管理。
2、其实网络功能需要两个维度。第一就是提供网络功能，给pod或service提供ip地址之类的。第二个维度是：k8s之上的网络解决方案还要求它应该能够提供网络策略功能。他能够定义各名称空间pod之间能否互相访问。比如pod之间的隔离，因此需要k8s上的逻辑组件名称空间。
3、目前来讲，能作为附件运行的CNI插件很多。比较流行的如下。
a、flannel（只支持网络配置，不支持网络策略）。纯粹的叠加网络实现。
b、calico（支持网络配置和网络策略，部署比较困难）,使用bgp协议直接路由通信，为三层隧道网络。
c、canel(flannel+calico)