Kubernetes 核心原理 之一

Kubernetes API Server原理分析

Kubernetes API Server概述

Kubernetes API Server提供了Kubernetes各类资源对象如，（如Pod、RC、Service等）的增、删、改、查以及watch等http接口，成为集群内各个功能模块之间数据交互和通信中心的枢纽，是整个系统的数据总线和数据中心。除此之外，它还有以下特性：

• 是集群管理的API入口
• 是资源配额控制的入口
• 提供了完备的集群安全机制

Kubernetes API Server通过一个kube-apiserver的进程提供服务，该进程运行在Master节点上。通常我们可以通过Kubernetes API Server交互，他们之前的接口是Rest调用。

Kubernetes Proxy API接口

Kubernetes Proxy API代理REST请求，Kubernetes API Server把收到的REST请求转发到某个Node上的Kubernetes守护进程的REST端口上，由该Kubernetes进程负责响应。

集群功能模块之间的通信

集群内每个功能模块，通过API Server将信息存入etcd，当需要获取和操作这些数据时，则通过API Server提供的REST接口来实现，从而实现了各个模块之间的信息交互。kubernetes结构图如下：

Control Manager原理

Control Manager作为集群内部的股哪里控制中心，负责集群内的Node、Pod副本、服务端点（EndPoint）、命名空间（Namespace）、服务帐号、资源定额等管理，的那个某个Node意外宕机时，Control Manager会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态。Control Manager结构图：

Replication Controller

Replication Controller用于确保在任何时候一个集群中一个RC所关联的Pod副本数量保持在预设值。如果发现Pod的副本数量超过预设值，则Replication Controller会销毁一些Pod副本，反之，Replication Controller会自动创建新的Pod副本，直到符合条件的Pod副本数量达到预设值。

Node Controller

Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群的中的每个Node节点的相关信息，

ResourceQuota Controller

资源配额管理这一高级功能，资源配额管理确保指定的系统资源对象在任何时候都不会超量占用系统物理资源
目前Kubernetes支持如下三个层次的资源管理配额管理：

• 容器级别，可以对CPU和Memory进行限制
• Pod级别，可以对一个Pod里面的所有容器的可用资源进行限制

• Namespace级别，为Namespace(多租户）级别的资源限制，包括：

      Pod数量；
      Replication Controller 数量；
      Service数量；
      ResourceQuota数量；
      Secret数量；
      可持有的PV（Presistent Volume）数量。
  

Namwspace Control

用户可以创建新的API Server可以创建新的Namespace并保存在etcd中，Namespace Controller定时可以通过API Server读取这些Namespace信息并保存到etcd中

Service Controller与Endpoint Controller

Service、Endpoints与Pod的关系，如图：

Endpoints表示一个Service对应的所有的Pod副本的访问地址，而Endpoints Controller,就是负责生成和维护所有Endpoints对象的控制器，它负责监听Service和对应的Pod副本的变化，如果监听到Service被删除，则删除和该Service同名的Endpoints对象。Node上的kube-proxy进程读取每个Service的Endpoints,实现了Service的负载均衡功能。

Scheduler原理分析

Kubernetes Scheduler的作用是将待调度的Pod(API创建的Pod、Controller Manager为弥补副本而创建的Pod等）按照特定的调度算法和调度策略绑定到集群中某个合适的Node上，并将绑定信息写入etcd。在调度过程中涉及三个对象：待调度列表、可用Node列表、以及调度算法和策略。

目标节点上的kubelets通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像，并启动容器。Scheduler流程，如下图：

Kubernetes Scheduler 当前提供的调度流程分为以下几步：

• 预选调度过程
• 确定最优节点

Kubernetes Scheduler的调度流程是通过插件方式加载的“调度算法提供者”，具体实现的，func RegisterAlgorithmProvider(name string, predicatekeys, priorityKeys, util.StringSet)
它包含三个参数，name string为参数名，predicateKeys,参数为算法用到的预选策略集合，priorityKeys为算法用到的优选策略集合。

Kubernetes 运行机制分析

在Kubenetes集群中，在每个Node节点上都会启动一个kublet服务进程，该进程用于处理Master节点下发到本节点的任务，管理Pod及Pod里面的容。 每个kubelet进程会在API Server上注册节点自身信息，定期向Master节点汇报资源的使用情况，并通过cAdvisor监控容器和节点资源。

节点管理

节点通过设置kubelet的启动参数，”–register-node”, 来决定是否向API Server注册自己。

Pod 管理

kublet通过以下几种方式获取自身Node上所要运行的Pod清单：

• 文件： kubelet启动参数，”–config”指定的配置文件目录下的文件。通过–file-check-frequency设置检查该文件目录的时间间隔，默认为20s。
• HTTP站点（URL）: 通过”–manifest-url”,参数设置
• API Server: kublet通过API Server监听etcd目录，同步Pod列表。

容器健康检查

Pod通过两类指针来检查容器的状态。一个是LivenessProbe指针，用于判断容器是否健康，如果LivenessProbe探测指针不健康，则kubernetes将删除该容器，并根据容器的重启策略作相应处理。另一类是，ReadinessProbe指针，用于判断容器是否启动完成，并且准备接受请求。

cAdvisor 资源监控

在kubernetes集群中,应用程序的级别可以在不同的级别上监测到，这些级别包括：容器、Pod、Service和整个集群，cAdvisor是一个开源的分析容器资源使用率和功能特性的代理工具。在kubernetes项目中，cAdvisor被集成到kubernetes代码中。

kube-proxy 运行机制分析

kubernetes在创建服务时会分配一个虚拟的IP地址，客户端通过这个虚拟的IP地址来访问服务，而服务则负责把请求转发到后端的Pod上。

深入分析集群安全机制

kubernetes通过一系列机制来实现集群的安全机制，其中包括API Server的认证授权、准入控制机制及保护敏感的信息的Secret机制等。集群的安全性必须考虑主机的如下几个目标：

• 保证容器与所在主机的隔离
• 限制容器给基础设施及其他容器带来消极影响的能力
• 最小权限原则
• 明确组件间边界的划分
• 划分普通用户和管理员的角色
• 在必要的时候允许将管理员权限赋值给普通用户
• 允许拥有”Secret”数据（Keys,Certs, Passwords)的应用在集群中运行

API Server 认证

Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server的REST API来实现的，所以集群的安全的关键就在于识别并认证客户端身份以及随后访问权限的授权。

kubernetes集群提供了3种级别的客户端身份认证方式。

• 最严格的HTTPS证书认证：基于CA证书签名的双向数字证书认证方式。
• HTTP Token认证： 通过一个Token来识别合法用户
• HTTP Base认证： 通过用户名+密码的方式认证

这里需要一个CA证书，CA认证涉及诸多的概念，比如根证书、自签名证书、密钥、私钥、加密算法及HTTPS等。下面讲述SSL协议的流程，有助于CA认证和kubernetes CA认证的配置过程的理解。

SSL双向认证大概包含下面几个步骤：

1. HTTP 通信双方的服务器向CA机构申请证书，CA机构下发根证书、服务端证书以及私钥给申请者。
2. HTTP 通信双方的客户端向CA机构申请证书，CA机构下发根证书、客户端证书以及私钥给申请者。
3. 客户端向服务器发送请求，服务端下发服务端证书给客户端，客户端收到证书后，通过私钥解密证书，并利用服务端证书中的公钥认证信息比较证书里面的信息，如域名和公钥与服务器刚刚发送的相关消息是否一致，如果一致，则客户端认可这个服务器的合法身份。
4. 客户端发送客户端证书给服务器，服务器收到证书后，通过私钥解密证书，获得客户端证书公钥，并用该公钥认证证书信息，确认客户端是否合法。
5. 客户端通过随机密钥加密信息，并发送加密后的信息给服务端，服务端和客户端协商好加密方案后，客户端会产生一个随机的密钥，客户端通过协商好的方案，加密该随机密钥，并发送该随机密钥到服务端。服务端接收到这个密钥后，双方通信的所有内容都通过该随机密钥加密。
   

HTTP Token的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串-Token来表明客户身份的一种方式。在通常情况下，Token是一个很复杂的字符串，比如我们用私钥签名一个字符串后的数据就当作一个Token，每个Token对应一个用户名，存储在API Server能访问的一个文件中，当客户端发起API调用请求时，需要在HTTP Header里面放入Token，这样一来API Server就能识别合法用户和非法用户了。

API Server授权

授权就是对不同用户进行授权。API Server目前支持以下几种授权策略（通过API Server的启动参数，”–authorization_mode”设置）。

• AlwaysDeny， 拒绝所有请求
• AlwaysAllow，接受所有请求
• ABAC

ABAC模式的授权，有以下四个基本属性：

• 用户名
• 是否是只读请求
• 被访问的是哪类资源
• 被访问的对象所属的Namespace

当我们为API Server启用ABAC模式时，需要指定授权策略文件的路径和名字，授权策略里面的每一行都是一个Map类型的Json对象，称为被访问对象。我们可以通过设置”访问策略对象”的如下属性来确定对象的授权行为。

• user (用户名): 为字符串类型，该字符串类型的用户名来源于Token文件或基本认证文件中的用户名字段的值
• readonly(只读标识）：为布尔类型，当它的值为True时，表明该策略允许Get通过
• resource（资源）: 为字符串类型，来自与URL的资源, 例如”Pods”
• namespace（命名空间): 为字符串类型，表明该策略允许访问某个Namespace的资源。

如：kubelet 只能访问Pod的只读API:{“user”:”kubelet”,”resource”:”pods”,”readonly”:true};

客户端发起API Server调用时，API Server内部先要进行用户认证，接下来执行鉴权流程，鉴权流程通过之前提到的”授权策略”来决定一个API调用是否合法，当API Server接收到请求后，会读取请求中的数据，会生成一个”访问策略对象”，然后用这个访问策略的对象和授权策略文件中所有”访问策略对象”逐条匹配，如果至少有一个策略对象被匹配上，测该请求被鉴权通过，否则终止API调用流程、并返回客户端错误调用码。

Admission Control 准入机制

Admission Control配有一个”准入控制器”，发送给API Server的任何请求都需要通过列表中每个准入控制其的检查，检查不通过，则API Server拒绝执行该请求。

Service Account

Service Account是一种账号，但它并不是给kubernetes的集群用户（系统管理员、运维人员、租户等）使用的，而是给运行在Pod里的进程用的，为Pod里面的进程提供必要的身份证明。

一个Service Account可以包含多个Secret对象，如图：

• 名为Token的Secret用于访问API Server的Secret,也被称为Service Account Secret
• Image pull secrets的Secret用于下载容器镜像时的认证过程，通常镜像库运行在Insecure模式下，所以这个Secret为空
• 用户自定义的其他Secret,用于用户的进程