https://www.cnblogs.com/cyh00001/p/16488539.html
kube-apiserver kube-apiserver负责和etcd交互， 提供了k8s各类资源对象的增删改查及watch等HTTP Rest接口，这些对象包括pods、services、replication controllers等，API Server 为REST操作提供服务， 并为集群的共享状态提供前端，所有其他组件都通过该前端进行交互。同时也是外部的唯一入口 kube-scheduler kubernetes调度器是一个控制面进程，负责将Pods指派到节点上。通过调度算法为待调度Pod列表的每个Pod从可用Node列表中选择一个最适合的Node，并将信息写入etcd中。node节点上的kubelet通过API Server监听到kubernetes Scheduler 产生的Pod绑定信息，然后获取对应的Pod清单，下载Image，并启动容器。 策略： LeastRequestedPriority：优先从备选节点列表中选择资源消耗最小的节点（CPU+内存） CalculateNodeLabelPriority：优先选择含有指定Label的节点 BalanceResourceAllocation：优先从备选节点列表中选择各项资源使用率最均衡的节点 kube-controller-manager kube-controller-manager：Controller Manager还包括一些子控制器（副本控制器、节点控制器、命名空间控制器和服务账号控制器等），控制器作为集群内部的管理控制中心，负责集群内部的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群中的pod副本始终处于预期的工作状态。 controller-manager控制器每间隔5秒钟检查一次节点的状态。 如果controller-manager控制器没有收到自节点的心跳，则将该node节点标记为不可达。 controller-manager将在标记为无法访问之前等待40秒。 如果该node节点被标记为无法访问后5分钟还没有恢复，controller-manager会删除当前node节点的所有pod并在其它可用节点重建这些pod。 pod高可用机制： node monitor period：节点监视周期，5s node monitor grace period：节点监视器宽限期，40s pod eviction timeout：pod驱逐超时时间，5m Kubelet kubelet是运行在每个worker节点的代理组件，它会监视已分配给节点的pod，具体功能如下： 向master汇报node节点的状态信息 接受指令并在Pod中创建docker容器 准备Pod所需的数据卷 返回pod的运行状态 在node节点执行容器健康检查 coredns pod向coredns提供服务名，coredns负责进行域名解析，解析为ip返回pod，pod在用ip去和msater交互。 tiger： 服务名是固定的，但是cluster ip 是不断变化的。如果跨namespace 访问，则可以直接通过curl servicename.namesapce这样访问 单个node内的pod通信机制： 主机网卡etho0，docker0网桥，pod内虚拟网卡veth0的作用： 主机网卡eth0是用来跨node节点pod通信用的。 docker0网桥类似一个虚拟交换机，她是支持该节点上不同pod之间进行ip寻址和通讯的设备。 veth0则是pod1的虚拟网卡，是支持该pod内容器互通和对外访问的虚拟设备。docker0和veth0都是linux支持和创建的虚拟网络设备。 比如一个pod内有三个容器，则这三个容器就共享一个虚拟网卡veth0.内部的这些容器可以通过localhost访问，但他们不能使用同一个端口， 否则会有网络冲突。 每一个pod内还有pause容器，这个pause容器的唯一目的就是为pod建立共享的veth0的网络接口