架构模型为master/nodes(work)

可以理解master为蜂后，nodes为工蜂(干活的)

1. master为集群唯一入口，需要做高可用。
2. 每一个node节点都提供一部分计算能力和存储能力。(运行容器的节点)

请求过程：

客户端请求(创建启动容器)首先发往master，master当中有一个调度器，会去分析各node节点的资源状态，找一个最佳适配运行用户所请求的容器的节点，并把它调度上去，由这个node的docker或是其他容器引擎来负责把这个容器启动起来。启动容器时检查本地是否有镜像，如果没有需要从镜像仓库中pull来启动(镜像仓库可以是云上的，也可以是自检的私有仓库，也可以以容器运行在node节点上)。

Master

• API Server 接收并处理用户请求
• Scheduler 调度容器创建的请求
• controller-manager 确保已创建的容器处于健康状态

控制器管理器是确保控制器健康的，控制器是用来确保容器健康的。

• etcd 所有的组建的状态保存

• 再K8s上运行的最小单元不是容器，而是pod

• kubernets并不直接调度容器，而是调度pod,pod是对容器的一层封装。
• pod里可以有多个容器，他们共享同一网络协议栈，存储卷
• 一般一个pod只有一个容器

• label selector 可以通过控制器给pod打标签，之后控制器可以根据tag来识别出pod

Node

• kubelet 与apiserver交互运行的
• docker 运行pod中的容器
• kube-proxy 与apiserver进行通信，每一个pod发生变化，结果是需要保存到apiserver中，apiserver会生成一个通知事件，该事件可以被任何关联的组建所接收到， 管理service，service的创建及变动是依靠kube-proxy在iptables上创建出规则

Pod

1. 自主式Pod

自我管理，创建后仍然要提交给apiserver，由apiserver将其调度至指定的node的节点，由node启动此pod，如果一个pod中的容器出现故障，需要重启容器，需要又kubelet来完成。但是，如果节点故障了，该容器就消失了。无法实现全局进行调度。

1. 控制管理的Pod

正是有控制器机制的引入使得pod成为有生命周期的对象，而后由调度器将其调度至集群中的某节点运行以后，有一些任务作为守护进程运行为pod或容器，要确保它们随时处于运行状态，一旦发生故障，要随时重启它或者替代它。

• Replication Controller
  • 多退少补，必须精确符合人定义的期望
  • 滚动更新
  • 回滚
• ReplicaSet
• Deployment 只能管理无状态应用
• StatefulSet 管理有状态的应用
• DaemonSet 每个node上运行一个副本，而不是随意运行
• Job,Cronjob 作业
• HPA(HorizontalPodAutoscaler) 自动分析添加或减少pod