Kubernetes学习笔记-了解kubernetes机理-了解架构（1）20220702

kubernetes集群分为两部分：kubernetes控制平面、工作节点
1）kubernetes控制平面组件：

• etcd分布式持久化存储
• api服务器
• 调度器
• 控制器管理器

这些组件用来存储、管理集群状态，但他们不是运行应用的容器
2）工作节点上运行的组件
运行容器的任务依赖于每个节点上运行的组件：

• kubelet
• kubelet服务代理（kube-proxy）
• 容器运行时（docker、rkt或其他）

附加组件，包含：

• kunernetes DNS服务器
• 仪表板
• Ingress控制器
• Heapster（容器集群监控）
• 容器网络接口插件

这篇文章主要是了解kubernetes架构，主要从以下几部分入手：

1）kubernetes组件分布式特性

2）kubernetes如何使用控制平面组件的etcd

3）kubernetes控制平面组件api服务做了什么

4）kubernetes控制平面组件api服务器如何通知客户端资源变更

1、kunernetes组件分布式特性
检查控制平面组件的状态
api服务器对外暴露了一个名为ComponentStatus的api资源，用来显示每个控制平面组件的健康状态
命令 $kubectl get componentstatus---查看组件的健康状态
组件间的通信
kubernetes系统组件间只能通过api服务器通信，他们之间不会直接通信。api服务器是和etcd通信的唯一组件。其他组件不会直接和etcd通信，而是通过api服务器来修改集群状态。
api服务器和其他组件的连接基本都是由组件发起的，但是当使用kubectl获取日志、使用kubectl attach连接到一个运行中的容器或运行kubectl port-forward命令时，api服务器会向kubectl发起连接
注意：kubectl attach命令和kubetl exec命令类似，区别是：前者会附属到容器中运行着的主进程上，而后者是重新运行一个进程

单组件运行多实例
工作节点上的组件需要运行在同一个节点，控制平面的组件可以被简单的分割在多台服务器上。为了保证高可用性；控制平面的每个组件可以有多个实例。etcd和api服务器的多个实例可以同时并行工作，但调度器和控制器管理器在给定定的时间内只能有一个实例起作用，其它实例处于待命模式

2、kubernetes如何使用etcd

etcd是一个响应快、分布式、一致的key-value存储。因为它是分布式的，故可以运行多个etcd实例来获取高可用性和更好的性能。
唯一能直接和etcd通信的是kubernetes的api服务器。所有其他组件通过api服务器间接的读取、写入数据到etcd。这样的好处之一是增强乐观锁系统、验证系统的健壮性；并且，通过把实际存储机制从其他组件剥离，未来替换起来也更容易。值得强调的是，etcd是kubernetes存储集群状态和元数据的唯一地方
关于乐观并发控制
有时候指乐观锁，是指一段数据包含一个版本数字，而不是锁住该数据并阻止读写操作。每当更新数据时，版本数就会增加。当更新数据时，就会检查版本值是否在客户端读取数据时间和提交时间之间被增加过。如果增加过，那么更新就会被拒绝，客户端必须重新读取新数据，重新尝试更新。两个客户端尝试更新同一个数据条目，只有第一个会成功。
所有的kubernetes包含一个metadata.resourceVersion字段，当更新对象时，客户端需要返回该值到api服务器。如果版本值与etcd中存储的不匹配，api服务器会拒绝该更新。
 

资源如何存储在etcd中
kubernetes既可以使用etcd版本2也可以用版本3，推荐用版本3，性能更好。etcd v2是key存储在一个层级键空间中，这使得键值对类似文件系统的文件。etcd中每个key要么是一个目录，包含其他key，要么是一个常规key，对应一个值。etcd v3不支持目录，但是由于key格式保持不变（key键可以包含斜杠），仍然可以认为他们被组织为目录。kubernetes存储所有数据到etcd的／registry下。

注意 如果使用etcd v3的api，无法使用ls查看目录的内容，可以通过etcdctl get ／registry --prefix=true列出所有以给定前缀开始的key。

$etcdctl ls /registry/pods

查看存储的内容

$etcdctl get /registry/pods/default/kubia-159041347-wt6ga

确保存储对象的一致性和可验证性

kubernetes要求所有控制平面组件只能通过api服务器操作存储模块，使用这周方式更新集群状态总是一致的，因为api服务器实现了乐观锁机制，如果有错误的，也会更少。api服务器同时确保写入存储的数据总是有效的，只有授权客户端才能更改数据。

确保etcd集群一致性

为保证高可用性，常常运行多个etcd实例。多个实例需要保持一致性。这周分布式系统需要对系统的实际状态达成一致，etcd使用RAFT一致性算法来保障这一点，确保在任何时间点，每个节点的状态要么是大部分节点的当前状态，要么是之前确认过的状态。

连接到etcd集群不同节点的客户端，得到的要么是当前的实际状态，要么是之前的状态（在kubernetes中，etcd的唯一客户端是api服务器，但有可能有多个实例）

一致性算法要求集群大部分（法定数量）节点参与才能进行到下一个状态。可过就算，如果集群分裂为两个不互联的节点，在更新状态的时候，需要有过半节点参与状态更新。如果一个组包含了大部分节点，那么另一个组只有少量节点成员，第一个组就可以更改集群状态，后者则不可以。当两个组重新恢复链接，第二个组的节点会更新为第一个组的节点状态。

为什么etcd实例数应该是奇数

因为每次状态更新需要有过半节点参与，如上描述

通常，对于大集群，etcd集群有5个或7个节点就足够了，可以允许2-3个节点宕机，这对于大多数场景来说足够了。

3、api服务器做了什么

kubernetes api服务器作为中心组件，其他组件或客户端（如kubetcl）都会调用他。以Restful api的形式提供可以查询、修改集群状态的CRUD（Create、Read、Update、Delete）接口，他将状态存储到etcd中。

api服务器出了提供一种一致的方式将对象存储到etcd，也对这些对象做校验，这样客户端就无法存入非法的对象（直接写入存储的话有可能）。除了娇艳，还会处理乐观锁，这对于并发更新情况，对对象做更改就不会被其他客户端覆盖。

api服务器的客户端之意就是命令行工具kubectl。当以JSON文件创建一个资源，kubectl 通过一个http post请求将请求将文件内容发布到api服务器。

通过认证插件认证客户端

api服务器需要认证发送请求的客户端，这是通过配置在api服务器上的一个或多个认证插件来实现的。api服务器会轮流调用这些插件，直到有一个能确认是谁发送了该请求，这是通过检查http请求实现的。根据认证方式，用户信息可以从客户端证书或http标头获取，插件抽取客户端的用户名、用户id和归属组。

通过授权插件授权客户端

除了认证插件，api服务器海可以配置使用一个或多个授权插件。他们的作用是决定认证的用户死否可以对请求资源执行请求操作。如，当创建pod时，api服务器会轮询所有授权插件，来确认该用户是否可以在请求命名空间创建pod。一旦插件确认了用户可以执行该操作，api服务器会继续下一步操作。

通过准入控制插件验证and/or修改资源请求

如果请求尝试创建、修改或删除一个资源，请求需要经过准入控制插件的验证。服务器会配置多个准入控制插件，这些插件会因为各种原因修改资源，可能会初始化资源定义中漏配的字段为默认值甚至重写它们。插件甚至会去修改病不在请求中的相关资源，同时也会因为某些原因拒绝一个请求。资源需要经过所有准入控制插件的验证。

注意：如果请求知识常识读取数据，则不会做准入控制验证

准入控制插件包括：
AlwaysPullImages----重写po的imagepullpolicy为always，强制每次部署pod时拉去镜像

ServiceAccount---未明确定义服务账户的使用默认账号

NamespaceLifecycle---防止在命名空间中的pod只能使用该命名空间分配数量的资源，如cpu和内存。

验证资源以及持久化存储

请求通过了所有准入控制插件后，api服务器会验证存储到etcd的对象，然后返回一个响应给客户端

4、api服务器如何通知客户端资源变更

api服务器启动控制器，以及其他一些组件来监控已部署资源的变更。控制平面可以请求订阅资源被创、修改或删除的通知，这使得组件可以在集群元数据变化时执行任何需要做的任务。

客户端通过创建到api服务器的http链接来监听变更，通过此链接，客户端会接收到监控对象的一系列变更通知。每当更新对象，服务器把新版本对象发送到所有监听该对象的客户端。

$kubectl get pods --watch      -------坚挺创建删除pod事件