概念：在K8s中大部分概念如常用的Master,Node,Pod,Service,RC等等都可以看作一种“资源对象”，基本所有资源对象都由kubectl工具操作（或API编写程序调用）,K8s是一个高度自动化的资源控制系统，它通过跟踪对比etcd 库里保存的“资源期望状态”与当前环境中 的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。

1.Master

Master是集群控制节点，每个K8s中都需要一个Master节点来负责整个集群的控制和管理，Master 节点通常会占据一个独 的服务器。 其主要原因是它太重要了，是整个集群的 首脑”，如果岩机或者不可用 ，那么对集群内容器应用的管理都将失效。

关于Master节点上运行着以下一组关键进程：     1.1 Kubernetes API Server ( kube-apiserver 提供了 HTTP Rest 接口的关键服务进程，是Kubernetes 里所有资源的增、删、改、 查等操作的唯一入口，也是集群控制的入口进程。     1.2 Kubernetes Controller Manager ( kube-controller-manager): Kubernetes 里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”。     1.3 Kubernetes Scheduler Manager ( kube-scheduler ）：负责资源调度（ Pod 调度〉的进程，相当于公交公司的“调度室”。     另外，在 Master 节点上还需要启动一个 etcd服务，因为 Kubernetes 里的所有资源对象的数据全部是保存在 etcd 中的。 2.Node Node和Master相同，Node节点可以为一台物理机或者虚拟机。Node节点是Kubernetes集群中的工作负载节点，当某个Node宕机时，Master会将其上的工作负载自动转移到其他节点上。 关于Node节点上运行以下一组关键进程：     2.1 kubelet ：负责Pod 容器的创建、启 停等任务，同时与 Master 节点密切协作，现集群管理的基本功能。     2.2 kube-proxy： 实现 Kubernetes Service 的通信与负载均衡机制的重要组件。     2.3 Docker Engine ( docker) : Docker 擎，负责本机的容器创建和管理工作。 3.Pod Pod是Kubernetes的最重要也最基本的概念，Pod是由一组容器组成的资源对象，每一个Pod都有一个Pause容器，它可以表示整个容器组的状态。Pod中多个业务容器共享Pause容器的IP，共享Pause的Volume,解决了容器之间的通信问题和文件共享问题。 Pod有两种类型，普通Pod和静态Pod,静态Pod并不存放在etcd中，而是存放在某个具体的Node上的具体文件中，并只在此Node上启动运行，而普通Pod一旦创建就会被放入etcd中存储，随后会被Master调度到某个具体的Node上绑定，，该 Pod 被对应的 Node 上的 kubelet 进程实例化成一组相关 Docker 容器并启动起来。默认情况下当Pod中的某个容器停止时，K8s会自动检测到这个问题并重启这个Pod(Pod中的所有容器)，如果Pod所在的Node宕机，则会将Pod调度到其他Node节点上。 4.Label Label是key=value的键值对，Label可以附加到各种资源对象中，一个资源对象可以指定任意数量的Label，同一个Label也可以指定到任意数量的资源对象中，可动态添加或删除。随后可以通过Label Selector查询和筛选拥有某些Label的资源对象。 关于Label Selector的重要使用场景：     4.1 kube-controller 进程通过资源对象RC上定义的 Label Selector 来筛选要监控的 Pod 副本的数量 ，从而实现 Pod 副本的数量始终符合预期设定的全自动控制流程。     4.2 kube-proxy 进程通过 Service的Label Selector 来选择对应的 Pod ，自动建立起每个Service 到对应 Pod 的请求转发路由表，从而实现 Service 的智能负载均衡机制。     4.3 通过对某些 Node 定义特定的 Label ，并且在 Pod 定义文件中使用 NodeSelector 这种标签调度策略，kube-scheduler 进程可以实现 Pod “定向调度”的特性。 5.Replication Controller Replication Controller简称RC，它是定义了一个期望场景，声明某种Pod的副本数量在任意时刻都符合某个预期值，在K8s v1.2时升级为Replica Set，RC与RS的区别在于RS支持基于集合的Label selector,RC支持等式。 关于 RC (Replica Set）的些特性与作用：     5.1 在大多数情况下 ，我们通过定义一个 RC 实现 Pod 的创建过程及副本数量的自动控制。     5.2 RC里包括完整的 Pod 定义模板。     5.3 RC通过 Label Selector 机制实现对 Pod 副本的自动控制。     5.4 通过改变RC里的Pod副本数量 ，可以实现 Pod 的扩容或缩容功能。     5.5 通过改变RC里的Pod模板中的镜像版本，可以实现 Pod 的滚动升级功能。 6.Deployment Deployment是K8s在v1.2时引入的新概念，目的是为了更好的编排Pod,内部使用Replica Set 实现，可以看作是RC的一次升级，通过RS我们可以随时知道当前Pod的部署进度。 关于Deployment 的典型使用场景：     6.1 创建Deployment对象来生成对应的 Replica Set 并完成 Pod 副本的创建过程。     6.2 检查Deployment的状态来看部署动作是否完成（ Pod 副本的数量是否达到预期的值）。     6.3 更新Deployment以创建新的 Pod （比如镜像升级）。     6.4 如果当前Deployment 不稳定，则回滚到一个早先的 Deployment 版本。     6.5 暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment ，进行新的发布。     6.6 扩展Deployment以应对高负载。     6.7 查看Deployment的状态，以此作为发布是否成功的指标。     6.8 清理不再需要的旧版本 ReplicaSets。 7.Service Service 也是 Kubemetes 里的最核心的资源对象之 Kubernetes 里的每个 Service 其实就是我们经常提起的微服务架构中的 个“微服务”。Service 定义了一个服务的访问入口地址，这个入口地址访问其背后的一组由 Pod 副本组成的集群实例， Service 与其后端 Pod 副本集群之间则是通过 Label Selector 来实现“无缝对接”的。而 RC 的作用实际上是保证 Service的服务能力和服务质量始终处于预期的标准。服务之间通过 TCP/IP 进行通信，从而形成了我们强大而又灵活的弹性网格，拥有了强大的分布式能力、弹性扩展能力、容错能力。