一、架构描述
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）。
4、附件（AddOns）
a）、DNS。service作为k8s对象来讲，有service名称，而service的名称也相当于是这个服务的名称，可以被解析，可以把service名直接解析为service IP，名称解析靠dns，我们装完k8s集群后你会发现第一件事就是需要在k8s集群上部署一个dns pod以确保各dns被解析。因此dns pod是基础级的系统架构级的对象。因此他们也被称为集群的附件(AddOns)。DNS会动态更新解析记录，当集群中IP或名称有变动时DNS pod中的解析记录也会动态改变。
31分37秒