1. Apiserver
唯一与etcd进行数据交互的组件，也是其他核心组件连接交互的枢纽，承载整个架构的核心和最大的压力。Controller Manager、Scheduler、Kube-proxy 和 Kubelet 等均通过 API Server watch API 监测资源变化情况，并对资源作相应的操作，所有需要更新资源状态的操作均通过 API Server 的 REST API 进行，所以一般要对apiserver组件做高可用配置。
由于apiserver是整个架构的核心，所以在安全上尤为重要，k8s集群对apiserver做了多重安全控制。从认证、授权到准入控制三部曲。
2. Control Manager控制器
通过list watch方式监控本身负责的apiserver资源变化，控制着deployment、replicatset、namespaces、nodes、serviceaccount等控制器
3. Scheduler调度器
scheduler通过list watcher方式监控apiserver任务的调度，接到pod任务调度的scheduler将通过调度策略进行pod的创建，调度策略分为预选策略和优选策略。
预选策略：是从集重列出所有node工作节点，通过调度算法将不满足条件的node去掉。例举：A.磁盘、cpu、内存、负载等基础资源是否充足 B. Hosts ports是否冲突 C.检查 pod.Spec.NodeName 是否与候选节点一致 D.pod.Spec.NodeSelector 是否匹配 E.NoVolumeZoneConflict：检查 volume zone 是否冲突 F.PodToleratesNodeTaints：检查 Pod 是否容忍 Node Taints 等等。
优选策略：优先级排序，选择优先级最高的节点。 例举：A.NodeAffinityPriority：优先调度到匹配 NodeAffinity 的节点上 B.TaintTolerationPriority：优先调度到匹配 TaintToleration 的节点上 C. LeastRequestedPriority：优先调度到请求资源少的节点上 D.InterPodAffinityPriority：优先将 Pod 调度到相同的拓扑上（如同一个节点、Rack、Zone 等） E.SelectorSpreadPriority：优先减少节点上属于同一个 Service 或 Replication Controller 的 Pod 数量
5. Kubelet
每个Node节点上都运行一个 Kubelet 服务进程，默认监听 10250 端口，接收并执行 Master 发来的指令，管理 Pod 及 Pod 中的容器。每个 Kubelet 进程会在 API Server 上注册所在Node节点的信息，定期向 Master 节点汇报该节点的资源使用情况，并通过 cAdvisor 监控节点和容器的资源。Kubelet 可以通过设置启动参数 --register-node 来确定是否向 API Server 注册自己；如果 Kubelet 没有选择自注册模式，则需要用户自己配置 Node 资源信息，同时需要告知 Kubelet 集群上的 API Server 的位置；Kubelet 在启动时通过 API Server 注册节点信息，并定时向 API Server 发送节点新消息，API Server 在接收到新消息后，将信息写入 etcd。
6. Kube-proxy
每台机器上都运行一个 kube-proxy 服务，它监听 API server 中 service 和 endpoint 的变化情况，并通过 iptables等来为服务配置负载均衡（仅支持 TCP 和 UDP）。kube-proxy 可以直接运行在物理机上，也可以以 static pod 或者 daemonset 的方式运行。其实kube-proxy基本上负责的是代理、负载均衡等网络层面的事情，最终体现在iptables（ipvs）规则。
7. Etcd
Etcd 是 CoreOS 基于 Raft 开发的分布式 key-value 存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）
8. 创建pod的整体流程
官网图例：
8.1 创建replicaset工作流程：
a. 首先通过kubectl命令或api接口方式向apiserver发起创建replicaset的请求，api响应命令,通过一系列认证授权，比如通过kubectl apply -f xx.yaml或kubectl create等方式。
b. apiserver将要创建replicaset的信息保存为yaml，再写入etcd。截至目前，仅仅在ectd中加入一条信息，没有实际的进展。
c. Control manager通过list watch监控到apiserver数据变化，apiserver在etcd中读取到需要创建rs的需求，然后control manager调用apiserver接口获取创建多少个pod的信息，apiserver将信息同步更新保存在etcd中。
d. scheduler检测到未绑定 Node 的 Pod，通过list watch调用apiserver接口在etcd中获取到相应信息，执行调度策略，先经过过滤不满足的node预选策略，再通过pod优选策略最终决定将pod调度到哪个node上，apiserver将信息同步更新保存在etcd中。
e. 被选中node的kubelet将通过list watch 实时监控apiserver读取etd数据，检测到有新的 Pod 调度过来，通过 Container Runtime 运行该 Pod，Kubelet 通过 Container Runtime 取到 Pod 状态，并更新到 API Server 中，并同步更新写入到etcd中。
8.2 创建pod工作流程：
创建pod的工作流程大体和创建rs工作流程差不多，具体差异是pod不再受rs的管理。
a. 用户通过 REST API 创建一个 Pod
b. API Server 将其写入 etcd
c. Scheduluer 检测到未绑定 Node 的 Pod，开始调度并更新 Pod 的 Node 绑定
d. Kubelet 检测到有新的 Pod 调度过来，通过 Container Runtime 运行该 Pod
e. Kubelet 通过 Container Runtime 取到 Pod 状态，并更新到 API Server 中
