开篇：
本文是结合我个人学习经验以及官方文档对整个K8S知识体系的总结，同时也是分享记录学习过程。意在使用通俗，易懂的话语使大家对K8S有个整体印象。面向对象是初学者以及学习过想要复盘的同学，如果有错漏欢迎指出！大家一起进步！
一、k8s架构
K8s系统在设计是遵循c-s架构的，也就是我们图中apiserver与其余组件的交互。
K8S集群主要由Master 和 Node 组成，Master的组件包括：apiserver、controller-manager、scheduler和etcd等几个组件，其中apiserver是整个集群的网关。Node上组件包括 kubelet 、kube-porxy 以及服务于pod的容器运行时 (Container Runtime)。外部storage与registry用于为容器提供存储与镜像仓库服务。
二、组件介绍
api-server
提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接和etcd进行交互。API Server 扮演着通信枢纽的位置。API Server 不仅负责和 etcd 交互（其他组件不会直接操作 etcd，只有 API Server 这么做），并切对外提供统一的API调用入口, 所有的交互都是以 API Server 为核心的，通俗来说就是：整个集群的唯一入口，集群的访问，操作，组件调用都要通过它
control-manager
这个看名字就知道，控制器的管理者，它作为K8S集群的管理控制中心，负责集群内 Node、Namespace、Service、Token、Replication 等资源对象的管理。这里要理解一个概念，K8S中每个资源就是一个对象，每个对象都是用一个管理器去管理控制这个资源对象，控制器使集群内的资源对象维持在预期的工作状态。每一个 controller 通过 api-server 提供的 restful 接口实时监控集群内每个资源对象的状态，当发生故障，导致资源对象的工作状态发生变化，就进行干预，尝试将资源对象从当前状态恢复为预期的工作状态，常见的 controller 有 Namespace Controller、Node Controller、Service Controller、ServiceAccount Controller、Token Controller、ResourceQuote Controller、Replication Controller等。通俗来说就是：控制维护集群状态在预期值，这里的集群状态包括节点，容器等等。
scheduler
负责对集群内部资源进行调度，它接受（监视）来自kube-apiserver创建Pods的任务，通过内部的算法或者预设的策略，去选择这个 pod 应该运行在哪个节点
etcd
etcd在kubernetes集群是用来存放数据并通知变动的。etcd有个watch的机制，，可以调用它的api监听其中的数据，一旦数据发生变化了，就会收到通知。有了这个特性之后，kubernetes中的每个组件只需要监听etcd中数据，就可以知道自己应该做什么。kube-scheduler和kube-controller-manager呢，也只需要把最新的工作安排写入到etcd中就可以了，不用自己费心去逐个通知了。当然还是要通过API-SERVER。生产环境中建议将ETCD和MASTER解耦。
kubelet
运行在每个计算节点上的代理
- kubelet 组件通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器。
- 同时监视分配给该Node节点的 pods，周期性获取容器状态，再通过api-server通知各个组件 通俗来说：他就是MASTER派到各个节点的小弟，负责监控节点上pod的状态，同时负责上报节点和节点上pod的状态，负责与master（kube-api）节点通信，并管理节点上的Pod（维护pod的生命周期，创建删除，启停等，包括网络和存储卷等）
kube-proxy
负责pod之间的通信和负载均衡，将指定的流量分发到后端正确的机器上。这样说可能不好理解，换个说法：首先k8s 里所有资源都存在 etcd 中，各个组件通过 apiserver 的接口进行访问etcd来获取资源信息，kube-proxy 会作为 daemon（守护进程） 跑在每个节点上通过watch的方式监控着etcd中关于Pod的最新状态信息,它一旦检查到一个Pod资源被删除了或新建或ip变化了等一系列变动，它就立即将这些变动，反应在iptables 或 ipvs规则中，以便之后 再有请求发到service时，service可以通过ipvs最新的规则将请求的分发到pod上
Container Runtime
负责镜像管理以Pod和容器的真正运行
kubectl 用于操作kubernetes集群的命令行接口
总结
以上就是K8S各组件的大概介绍，现在我们再结合第一张图和刚刚的介绍理一下K8S的工作流程。
从kubectl开始，我们来看一下K8s的基本工作流程：
- kubectl 客户端首先将CLI命令转化为RESTful的API调用，然后发送到kube-apiserver。
- kube-apiserver 在验证这些 API 调用后，将任务元信息并存储到etcd，kube-scheduler 监测到ETCD调度信息， 开始决策一个用于作业的Node节点。
- 一旦 kube-scheduler 返回一个适合调度的目标节点后，kube-apiserver 就把任务的节点信息存入etcd，并创建任务。
- 此时目标节点中的 kubelet正监听apiserver，当监听到有新任务需要调度到本节点后，kubelet通过本地runtime创建任务容器，执行作业。
- 接着kubelet将任务状态等信息返回给apiserver存储到etcd。
- 这样我们的任务已经在运行了，此时control-manager发挥作用保证任务一直是我们期望的状态。
