架构图
K8s集群主要由两部分组成，分别是Master（主控节点）和Node（工作节点）
Master
K8s集群的控制节点，对集群进行调度管理，接受集群外的用户请求去操作集群。 主要由 API Server、Scheduler、ClusterState Store（ETCD 数据库）和 Controller MangerServer 所组成。
- API Server
- 客户端工具组件，K8s集群的统一入口，以Restful的方式对外提供操作集群的接口，相当于K8s的前端接口。
- Scheduler
- 节点调度，负责选择Node节点部署应用。
- Controller Manager
- 处理K8s集群中的常规后台任务，一个资源（replication、namespace等）对应一个控制器，管理Pod
- Etcd
- 负责保存K8s的配置信息以及各种资源的状态信息，当数据发生变化时可以快速通知相关组件。（相当于普通应用中的数据库）
Node
K8s集群的工作节点，运行用户的业务应用容器（Pod）的地方，主要由 kubelet、kube proxy 组成。
- kubelet
- 根据具体的信息进行Pod的创建和运行操作，用于管理本机的容器
- kube proxy
- 提供外界对Pod的访问、多个Pod之间的网络通信、负载均衡等
核心概念
- Pod
- K8s的最小工作单元，包含一个或多个容器。
- 作用：
- 按组管理：如果有一些容器可以紧密的连接在一起的话，那么我们可以将他们部署到一个Pod单元中。
- 通信、资源的共享：在一个Pod中有相同的IP和端口，那么他们之间可以通过localhost进行通信，如果挂载，那么将挂载该Pod中的每一个容器。
- Controller
- Pod的管理者，K8s通过他来管理Pod
- Deployment：
- 最常用的Controller，用来管理Pod的多个副本
- ReplicaSet
- 也是用于管理Pod的多个副本，我们使用Deployment的时候，他会自动创建ReplicaSet，也就是说Deployment是通过ReplicaSet进行Pod的多副本管理的。
- DaemonSet
- 也是对Pod的多副本管理。
- StatefulSet
- 确保Pod的每个副本在整个生命周期中的名称和环境是不变的，主要用于部署有状态的应用。
- Job
- 用于运行结束就删除的应用，主要用于定时任务或批处理应用。
补充说明：什么是有状态应用？什么又是无状态应用？
- 有状态应用：
- 有状态应用指的是需要在本地存储持久化数据的应用。,典型的是分布式数据库的应用中分布式节点实例之间有依赖的拓扑关系。比如数据库的主从关系，如果K8S停止分布式集群中任 一实例pod,就可能会导致数据丢失或者集群的宕机。这种应用建议使用StatefulSet部署管理。
- 无状态应用
- 无状态应用指的是不会在本地存储持久化数据的应用。多个应用实例对于同一个用户请求的响应结果是完全一致的，这种多应用实例之间是没有依赖关系的。比如web应用，在K8s控制器中动态启停无状态应用的Pod并不会对其它的Pod产生影响。这种应用通常使用Deployment 部署管理。