1.一个k8s集群由什么组成，请分别说说他们的作用。

k8s集群是由控制平面和一组被称为节点的工作机器组成，这些工作机器分别运行容器化应用。每个集群至少需要一个工作节点才能运行pod。

而控制平面负责管理集群中的工作节点以及pod, 在生产环境中控制平面运行在多台计算机上，并且一个集群中运行多个节点以此来提高容错和高可用性。

重点是控制平面组件，这也是面试经常问的问题。

kube-apiserver: 用于暴露kubenetes api。他是k8s控制平面的前端，也是将所有组件连接在一起的唯一网关。想要修改任何资源都要通过kube-apiserver来处理。

工作流程：

当一个请求到达kube-apiserver,api-server首先会检查你是谁？你提供的证书以及token或密码是否有效。然后api-server会看看你是不是有权利去执行此操作，你的角色是否允许你创建Pod。然后进行准入控制，这个相当于更严格更仔细的检查，校验资源规范是否合规以及修改资源规范，在通过所有关卡后，api-server会将请求对象进行验证并转化为存储格式，写入etcd。只有写入etcd的命令才能触发集群的执行机制去执行命令。

注意，这里api-server的功能只有写入并没有实际执行操作权力，操作请求的任务是交给kubelet和controller-manager去执行的，这样做实现了功能的解耦。

其特点就是唯一能和etcd的组件，并且他是无状态的，本身并不存储长期数据，因此在k8s集群中推荐使用多个api-server，并且在他们前使用负载均衡器去分担流量，实现高可用和水平扩展。

除此之外，他还能将自定义api集成到总路由，也就是api聚合。

什么是api聚合，早期当k8s想自定义资源时候，需要通过修改k8s的源代码才能进行修改，这就导致十分复杂麻烦。而当你可以编写一个自定义api-server来管理那些自定义资源，然后kube-apiserver将这些自定义资源的请求通过其本身然后转发给你的自定义api-server来处理。

最后就是资源版本控制，每个 Kubernetes 资源对象都有一个 resourceVersion 字段。APIServer 利用它来实现 乐观锁。当多个客户端同时更新一个对象时，只有基于最新版本的更新才能成功，防止了更新覆盖。

etcd: 分布式，高可用的键值对存储系统，用于存储一些关键数据并保证其一致性。在k8s中其充当了整个集群配置存储和服务发现数据库。所有集群状态信息都持久化在etcd。

包括工作负载（pod,statefulset,deploymemt），网络（ingress,service）和存储配置集群信息的状态都在其中，kubectl get...就是从此来读取数据，而当你kubectl create/apply变更数据时也会写入etcd。

而service的endpoint存储的ip地址和端口也都存储在其中，当需要负载均衡时kube-proxy或ingress控制器也会通过kube-apiserver来查询etcd获取最新端口列表。

他这么重要，是如何来保证他的可靠性呢？

首先来说说强一致性，这也是etcd的灵魂，他是使用Raft算法来保证分布式环境下多个etcd保存一致性的。

工作原理，一个etcd集群通常由3-5个节点组成（奇数个）

其中一个时leader,其他都是follower。所有的写请求都发送给leader,然后leader再将操作复制给其他follower节点。一旦大多数节点确认，leader才会提交这个请求，并通知客户端写入成功。这样即使少数节点宕机，也不影响集群，并且数据不会丢失。

然而当大多数集群宕机时则会丢失集体数据且不可恢复，这也体现了etcd高可用部署和定期备份的重要性。

另外etcd还有两个核心特性，高可用性（指的是当有节点失败时，其他节点可以迅速接管服务并推举新的leader）和wacth机制(时刻关注数据变更并且通知所有客户端)。他们共同保证了其可靠性。

kube-scheduler: 控制平面的核心组件，来监视那些还没有分配的Pod，并为每一个pod分配一个合适的node。

工作流程大概是，过滤：筛选掉那些不满足pod硬性要求的节点。此阶段结束会出现一个符合条件的节点列表，如果列表为空则pod一直会处于pending状态。

然后则是打分，也可以叫做优选。在候选列表的加点对所有节点采用打分策略，从而在其中找到最优的那一个。如果多个节点同分则会随机选择一个。

最终步骤就是绑定，选定节点后调度器会通知kube-apiserver,将pod的spec.Nodename字段设置为优选节点名称，而这个写入操作会触发kubelet，由他开始创建并运行pod的容器。

当然它的功能远不止于此，它还支持更精细的调度控制，比如指定pod不应该被调度到哪些节点，指定pod不能与其他pod部署在统一领域。污点和容忍度（之前的文章提及过）。

kube-controller-manager：控制平面的核心组件，运行着一系列的控制器。每个控制器都有单独的自控循环，通过api-server监听集群中待定资源的状态变化，并致力于将当前状态调整到所期望的状态。

工作流程（以deployment为例）：
首先是监听，Deployment Controller 和 ReplicaSet Controller 都在持续地 watch kube-apiserver，监听它们所关心的资源（Deployment, ReplicaSet, Pod）的变化。
当你创建deployment时候指定replicas与controller检测的期望状态不一致时，会被检测到差异。
而deployment controller并不会因此创建pod,而是创建一个相应的ReplicaSet，当ReplicaSet controller读取的这个Replica Set后才会创建pod定义，使目前状态和期望状态一致。
然后调度器将pod调度到节点上，节点上的kubelet创建容器并汇报pod状态。
最后controller 持续监听直到目前状态和期望状态一致。

ok以上就是本期全部内容，感谢你的阅读