kubernets之机理概览
一 了解kubernets的运行机理
1.1 了解架构
众所周知,kubernets的组成由2个部分组成
-
-
- kubernets 平面
- node节点 (工作节点)
-
控制平面的组成
-
-
- etcd 分布式的持久化存储
- apiserver 服务器
- scheduler 调度器
- controller manager 控制器管控器
-
工作节点的组成
-
-
- kubelet
- kubelet服务代理 (kube-proxy)
- 容器运行时（主要是docker）
-
其他可能出现的一些组件(非必需)
-
-
- kubernets DNS服务器
- 仪表盘
- Ingress控制器
- 容器网络接口插件
-
1.1.1 kubernets组建的分布式特性
若想获得完整kubernets的全部功能需要部署全部的组件，各个组件的功能和依赖如下图所示
这里可以通过以下命令来检查集群服务器的健康状态
k get componentstatuses
组件间的通信方式:
kubernets组件间不能直接通信，只能通过apiserver与etcd进行通信，例如修改某个资源状态，都是通过API服务器
单组件运行多个实例
工作节点上面的应用需要发布在单个节点上面，但是控制平面的组件却可以分布在多个节点上，etcd和apiserver可以有多个实例同时进行，但是控制器和调度器某个时间点只有一个有作用，其余的组件就只处于待命状态
组件部署形态
控制平面的组件以及一些常见的插件(网络插件以及Ingress)等这些都是以pod形式部署，而工作节点上面的kube-proxy以pod形式部署，而唯一一个不以pod部署的是kubelet
1.1.2 kubernets中与etcd相关
任何所有资源的mainifest都存储在etcd中，并且唯一能与之通信的只有apiserver，这样的好处是增加乐观锁的系统，并且etcd是kubernets中唯一的存储地方，还有一点要注意的是，由于etcd使用的是RATF算法，这种算法只有当一半以上(不含一半)的节点数能够转换到了另外一种形态的话，系统里面的存储才能够转换形态，具体细节可以查看下图所示
由于这个原因，故通常在部署高可用集群的时候经常需要部署奇数个数的节点数(3,5,7)
1.1.3 kubernets中与api服务器相关
api服务器作为kubernets里面作为k8s中心组件，其他组件或者客户端都会过来调用它，它对外提供了一个restfulapi形式的接口，支持客户端进行增删改查，并将修改后的资源持久化存储到etcd中
同时它还提供了一种一致的方式将对象存储到etcd中也对这些对象进行效验，这样客户端就无法将非法数据存储到集群中的etc中，同时还会处理乐观锁机制，对于并发的写入就不会被其他用户修改
kuberct作为客户端之一，当以json形式文件创建一个资源的时候，实际上是将数据以post形式发布到api服务器中，之后经过api服务器的多重认证写入etcd中
-
- 第一个需要通过就是认证插件，api服务器可以配置一个或者多个认证插件，在有请求到来的时候，API服务器会轮流调度这些插件，直到有一个能够辨别出来这个请求是谁发过来的
- 第二个需要通过的鉴权插件，这个插件的作用主要是用来鉴别这个用户是否有权限在这个命名空间里面对资源进行一些列的增删改查，这个也可以配置一到多个，之后会进入第三个插件
- 第三个需要通过的准入插件，如果创建或者修改一个资源，需要经过准入插件的认证，服务器可以同时配置很多的准入插件，在这个过程中插件会去修改或者添加资源的某些字段，甚至于拒绝对资源的修改或者创建，这个过程比较验证，需要请求能够通过所有的准入插件才能进行资源验证最后到达存储空间中，之后返回一个响应到客户端
1.1.4 服务端是如何通知客户端资源的变化情况的呢
除了之前讨论的，服务端不会多做任何其他的事情，当创建一个deployment的时候，API服务器不会去创建RS以及任何的pod，这些创建工作是经由控制器以及调度器来执行的任务，api服务器也不会去通知这些调度器以及控制器需要干啥，它做的就是启动这些控制器以及其他的组件来监听已部署资源的变更，控制平面可以请求订阅资源被创建，删除，修改等的通知，这使得组件们去执行相应的操作去完成。
客户端通过创建到API服务器的HTTP连接来监听变更，通过此连接，客户端会收到来自服务端的资源变更，服务端会在创建，修改等操作完成之后，会将更新后的资源发送给所有监听该对象的客户端中，图示描述了，一个资源创建的过程中客户端服务端等的交互过程
小技巧：可以通过以下命令来实时的监控集群中的pod变化
k get po --watch
k get po -o yaml --watch
