Kubernetes架构及相关服务详解

 11.1.了解架构

K8s分为两部分：

　　1.Master节点

　　2.node节点

Master节点组件：

　　1.etcd分布式持久化存储

　　2.api服务器

　　3.scheduler

　　4.controller

Node节点：

　　1.kubelet

　　2.kube-proxy

　　3.容器运行时（docker、rkt及其它）

附加组件：

　　1.Dns服务器

　　2.仪表板

　　3.ingress控制器

　　4.Heapster控制器

　　5.网络容器接口插件

11.1.1.k8s组件分布式特性

　　k8s系统组件之间通信只能通过API服务器通信，他们之间不会之间进行通信。

 　　API服务器是和etcd通信的唯一组件，其他组件不会直接和etcd进行通信。

　　API服务器与其他组件之间的通信基本上是由其他组件发起的，

       

//获取Master节点服务健康状况
#kubectl get componentstatuses   

11.1.2.k8s如何使用etcd

　　 etcd是一个响应快，分布式，一致的key-value存储。

　　是k8s存储集群状态和元数据唯一的地方，具有乐观锁特性，

 　　

关于乐观锁并发控制
    乐观锁并发控制（有时候指乐观锁），是指一段数据包含一个版本数字，而不是锁住该段数据并阻止读写操作。每当更新数据，版本数就会增加。当更新数据时，版本就会增加。当更新数据时，就会检查版本值是否在客户端读取数据时间和提交时间之间被增加过。如果增加过，那么更新会被拒绝，客户端必须重新读取新数据，重新尝试更新。
    两个客户端尝试更新同一个数据条目，只有一个会被更新成功。

资源如何存储在etcd中

　　flannel操作etcd使用的是v2的API，而kubernetes操作etcd使用的v3的API，所以在下面我们执行etcdctl的时候需要设置ETCDCTL_API环境变量，该变量默认值为2。

　　etcd是使用raft一致性算法实现的，是一款分布式的一致性KV存储，主要用于共享配置和服务发现。

　　Etcd V2和V3之间的数据结构完全不同，互不兼容。

 

确保etcd集群一致性

　　一致性算法要求大部分节点参与，才能进行到下一个状态，需要有过半的节点参与状态的更新，所以导致etcd的节点必须为奇数个。

11.1.3.API服务器

　　Kubernetes API服务器为API对象验证和配置数据，这些对象包含Pod，Service，ReplicationController等等。API Server提供REST操作以及前端到集群的共享状态，所有其它组件可以通过这些共享状态交互。

　　1.API提供RESTful API的形式，进行CRUD(增删查改)集群状态

　　2.进行校验

　　3.处理乐观锁，用于处理并发问题，

　　4.认证客户端

　　　　（1）通过认证插件认证客户端

　　　　（2）通过授权插件认证客户端

　　　　（3）通过准入插件验证AND/OR修改资源请求

　　API服务器如何通知客户端资源变更

　　　　API服务器不会去创建pod，同时他不会去管理服务的端点，

　　　　它做的是，启动控制器，以及一些其他的组件来监控一键部署的资源变更，是得组件可以再集群元数据变化时候执行任何需要做的任务，

11.1.4.了解调度器

　　调度器指定pod运行在哪个集群节点上。

　　调度器不会命令选中节点取运行pod，调度器做的就是通过api服务器更新pod的定义。然后api服务器再去通知kubelet该pod已经被调用。当目标节点的kubelet发现该pod被调度到本节点，就会创建并运行pod容器。

　　

调度方法：

　　1.通过算法过滤所有节点，找到最优节点

 　　2.查找可用节点

　　　　（1）是否满足对硬件的资源要求

　　　　（2）节点是否资源耗尽

　　　　（3）pod是否要求被调度到指定的节点、

　　　　（4）是否和要求的lable一致

　　　　（5）需求端口是否被占用

　　　　（6）是否有符合要求的存储卷

　　　　（7）是否容忍节点的污染

11.1.5.介绍控制器管理器中运行的控制器

（1）RC控制器

　　启动RC资源的控制器叫做Replication管理器。

　　RC的操作可以理解为一个无限的循环，每次循环，控制器都会查找符合其pod选择器的pod数量，并且将该数值和期望的复制集数量做比较。

（2）RS控制器

　　与RC类似

（3）DaemonSet以及job控制器

　　从他们各自资源集中定义pod模板创建pod资源，

（4）Deployment控制器

　　Deployment控制器负责使deployment的实际状态与对应的Deployment API对象期望状态同步。

　　每次Deployment对象修改后，Deployment控制器会滚动升级到新的版本。通过创建ReplicaSet，然后按照Deployment中定义的策略同时伸缩新、旧RelicaSet，直到旧pod被新的替代。

（5）StatefulSet控制器

　　StatefulSet控制器会初始化并管理每个pod实例的持久声明字段。

（6）Node控制器

　　Node控制器管理Node资源，描述了集群的工作节点。

（7）Service控制器

　　Service控制器就是用来在loadBalancer类型服务被创建或删除，从基础设施服务请求，释放负载均衡器的。

　　当Endpoints监听到API服务器中Aervice资源和pod资源发生变化时，会对应修改、创建、删除Endpoints资源。

 （8）Endpoint资源控制器

　　Service不会直接连接到pod，而是通过一个ip和端口的列表，EedPoint管理器就是监听service和pod的变化，将ip和端口更新endpoint资源。

 

（9）Namespace控制器

　　当收到删除namespace对象的通知时，控制器通过API服务群删除后所有属于该命名空间的资源。

（10）PV控制器

　　创建一个持久卷声明时，就找到一个合适的持久卷进行绑定到声明。

 

11.1.6.kubelet做了什么

了解kubelet的工作内容

　　简单来说，就是负责所有运行在工作节点上的全部内容。

　　第一个任务，在api服务器中创建一个node资源来注册该节点；第二任务，持续监控api服务器是否把该节点分配给pod；第三任务，启动pod；第四任务，持续监控运行的容器，向api服务器报告他们的状态，事件和资源消耗。

　　第五任务，kubelet也是运行容器的存活探针的组件，当探针报错时，他会重启容器；第六任务，当pod从api服务器删除时，kubelet终止容器，并通知服务器pod已经终止。

 

11.1.7.kube-proxy的作用

　　service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP。
　　kube-proxy的作用主要是负责service的实现，具体来说，就是实现了内部从pod到service和外部的从node port向service的访问。

 　　kube-proxy有两种代理模式，userspace和iptables，目前都是使用iptables。