k8s 组织架构详解

费了一番心思搞k8s 的架构图，经过一番探究弄清楚各个组件的关系
直接上图：

解释一下：
1.首先分成两个部分，master和node、基本master 是在创建资源或者资源变更时用到，node受master管理，是通过node 的 kubelet 监听master的apiserver组件来实现的，同时kubelet也会通过apiserver向master汇报自己当前节点的信息

2.node部分
2.1.客户端的访问是直接通过node的ip进行访问的，service通过相同标签将一组pod关联起来对外提供服务，service 的ip 成为cluster ip,只能在集群内部访问，必须绑定到node的某个指定端口才能用应用客户端访问。
2.2.deployment 的作用是为方便的创建一组相同的pod,同时要定义这一组pod的标签，因为pod要受service调度，可以认为service是一组pod的逻辑对外负载均衡器，deployment是底层docker创建一组 pod 的模版
2.3.pod 是k8s管理的最小单位，相当于主机，有pod ip，pod内可以有多个container，也即我们的应用
2.4.kube_proxy 监听apiserver，当有资源变更时，更新本地的iptable,因为service负载均衡的实现依赖iptable，可以认为辅助service实现负载均衡
2.5.多个node之间可以负载均衡（如果在部署配置文件中有配置允许在集群范围内分发请求，则可以实现应用客户端调用node1:端口，也会将请求转发到node2中，externalTrafficPolicy: Cluster）

3.master 部分
3.1.当k8s部署配置文件中deployment部分配置可以部署在master节点时，那么master就会有两个角色，master和node
3.2 master,node 的所有组件必须通过 apiserver 才能与etcd进行通信，同时接收来自k8s客户端(kubectl和dashboard)的命令，在集群初始化时同时受conterller，schedule和kubelet 的监听
3.3 etcd 是一个键值数据库，保存了整个集群的元信息
3.4 所有和资源创建/变更相关的命令都受controller和schedule控制，controller则负责关注集群的变化并做出调整决策(启动修复流程)，schedule控制资源创建在哪个节点上