kubernetes多租户管理与资源控制


namespace设计解读

​ namespace是Kubernetes进行多租户资源隔离的主要手段,那么它在系统中的表现形式是什么样的?实现原理和使用方法又是怎样的呢?

什么是namespace

​ namespace是一个将Kubernetes的资源对象进行细分的类似于DNS子域名的概念。namespace能够帮助不同的租户共享一个Kubernetes集群。Kubernetes引人namespace的目的包括以下几点:

  • 建立一种简单易用,能够在逻辑上对Kubernetes资源对象进行隔离的机制。
  • 将资源对象与实际的物理节点解耦,用户只需关注namespace而非工作节点上的资源情况。
  • 随着Kubernetes访问控制代码开发的深人,与Kubernetes认证和授权机制相结合。
  • 通过namespace对Kubernete,资源进行归类,使得APIserver能够建立一套有效的过滤Kubernetes资源请求的机制。

Kubernetes用户认证机制

​ Kubernetes用以认证用户请求的方式主要有5种,下面将逐一进行简单说明。

基于客户端证书的认证机制

​ 在APIServer启动过程中,通过传入–client-ca-file=SOMEFILE参数可以启用客户端证书认证。上面引用的文件必须包含一个或多个证书颁发机构(CA)用于检验用户传给APIServer的证书的合法性。如果客户端证书提交给APIServer且被认证通过,则SSL证书主题中的共用名(Common Name)将作为客户端发起API请求的用户名。

基于token的认证机制

​ 当客户端向Kubernetes安全端口发起API请求时,Kubernetes还支持使用token来认证用户的合法性。token预先存储在一个token文件中,在APIServer启动过程中传人–token-auth-file=SOMEFILE参数便可启用Kubernetes认证模块。token文件是一个CSV格式的文件(token文件格式目前由package tokenfite实现,具体代码见:plugin/pkg/auth/authenticator/token/token-file/…),至少有3列数据,分别是token, user name和user id,其后可以有选择地加上groupnames。

基于OpenID Connect ID Token的认证机制

​ OpenID ConnectID Token是一种特殊的认证方式。与其为每个希望访问的服务器都单独构建一个新的账户,不如使用一个通用的OpenID,而该OpenID的签发方来向各个服务器来提供认证服务。

Basic认证机制

​ Basic认证通过–basic-auth-file参数简单地传人用户名、用户id和密码进行认证。当某个HTTP客户端使用这种认证方式向APIServer发起请求时,应该在Authorization头部附上一个Basic BASE64ENCODED(USER:PASSWORD)的值。事实上,该认证方式在安全方面并不十分可靠,通常只用作其他几种认证方式的补充。

Keystone认证机制

​ 当启用这种认证方式时,用户会从Keystone API中获得一个token,并且将该token作为该用户的密码注入到kubeconfig文件中。当用户向APIServer发送请求时,APIServer会向Keystone校验该用户及其token是否合法,验证通过时则对该请求进行过应答。

Kubernetes用户授权机制

​ 在Kubernetes中,认证和授权是分开的,而且授权发生在认证完成之后,认证过程是检验发起API请求的用户是不是他所声称的那个人,而授权过程则判断此用户是否有执行该API请求的权限,因此授权是以认证的结果作为基础的。Kubernetes授权模块应用于对APIServer安全端口的HTTPS访问请求。

​ Kubernetes授权模块检查每个HTTP请求并提取请求上下文中的所需属性(例如user,resource, namespace)与访问控制规则进行比较。任何一个API请求在被处理前都需要通过一个或多个访问控制规则的验证。

​ 目前Kubernetes支持并实现了以下的授权模式(authorization mode ),这些授权模式可以通过在APIServer启动时传人参数进行选择:

--authorization_mode=AlwaysDeny --authorization_mode=AlwaysAllow --authorization_mode=ABAC --authorization_mode=Webhook --authorization_mode=RBAC --authorization_mode=Node 

Kubernetes多维资源管理机制admission control

​ 除了上一节介绍的3种相对传统的授权模式之外,Kubernetes还提供了一种多维度可扩展的资源管理机制admission control,方便用户实现资源配额等功能。

​ 与Kubernetes用户认证与授权模块一样,对admission control的调用也是由APIServer来完成的。APIServer启动过程中就进行了3个初始化操作,创建了3个对象:认证、授权和admission control。APIServer会在用户的请求通过认证授权之后调用admission control,对用户请求进行进一步的审核。所以即使用户请求通过了认证授权,也有可能因为申请的资源超过资源配额而被admission control驳回。

​ 需要说明的是,admission control只负责管理API对资源的请求量,一旦pod或容器实际在某台机器上运行后,并不控制它们的行为。因此admission control实际上是一个静态的、运行前的概念,而不是运行时的概念。

​ admission control是一种多维度可扩展的资源管理机制,每个维度通过一个admission control插件实现。这种插件被称为admission controller或者admission control plugino Kubernetes APIServer接受以下可选参数来启用admission control。

  • admission-control。以逗号作为分割符的admission control插件的列表,在新建、修改和删除Kubernetes对象之前会调用这些插件来检查该操作是否合法。默认是AlwaysAdmit,即永远允许。
  • iadmission-control-config-file。启动admission control插件的配置文件。

​ 下面将会以Kubernetes系统自带的几个admission control插件为例,介绍如何向Kubernetes集
群加入用户自定义的admission control插件,以更好地实现对集群资源的定制化管理控制。

admission control插件是以下接口的一个实现:

在这里插入图片描述

​ Attributes接口被admission control用来获取一个API请求中能够用于帮助进行决策的信息,这些信息包括API请求所处上下文的namespae, API操作的Kubernetes对象类型、API操作类型和实际运行时的Kubernetes对象。

在这里插入图片描述

​ Interface接口是一个抽象的、可插拔的、用于进行资源管理控制决策的admission control接口。工nterface接口的Admit则根据一个API请求的实际信息进行实际的管理决策,负责主要逻辑部分。Handles用于指明该admission controller否支持CREATE, UPDATE, DELETE或CONNECT操作,返回值为bool型。

​ 任意一个admission control插件都是admission.Interface,接口的一个实现用户也可以非常容易地实现自定义的插件。在撰写本书时,共有9个推荐使用的系统admission control插件,分别是AlwaysDeny, AlwaysAdmit, AlwaysPullImages, DenyEscalatingExec, ServiceAccount, SecurityContextDeny, ResourceQuota, LimitRanger和NamespaceLifecycle。

NamespaceLifecycle插件

​ 该插件拒绝在终止状态的namespace(即用户发起删除一个namespace的请求后,此时该namespace的.status.phase为Terminating状态,待该namespace下的所有资源全部被删除后,它才会退出)中创建新资源的请求,以及在尚未存在的namespace下创建资源的请求。

​ NamespaceLifecycle的Admit函数非常直观地展示了该admission controller的策略,它接受CREATE、UPDATE和DELETE操作。在每次接收到API请求之后,执行如下检查:

  • 当接收到的API请求试图删除namespace时,如果该namespace为default,拒绝该请求,否则接收该请求,并且从本地cache中将该namespace的记录删除。
  • 当接收到的API请求为资源相关的请求时,查找其对应的namespace,如果该namespace不存在,拒绝该请求。
  • 当接收到的API请求为创建资源请求时,如果该namespace为Terminating状态,拒绝该请求。
  • 当上述情况均未违反相应规则时,则通过该请求。

LimitRanger插件

​ LimitRanger插件的作用是判断客户端API请求中的资源需求是否符合系统管理员预设值,包括上限、下限、默认值以及默认比率。为了配合LimitRanger插件的使用,Kubernetes引人了LimitRange对象,用于对特定namespace中的Kubernetes对象设置资源使用的预设值。当前Kubernetes支持以namespace为单位,在pod和容器两个层次对资源使用进行管理。

​ 先来看一下LimitRange的数据结构定义:

在这里插入图片描述

​ 其中,ObjectMeta表示LimitRange对象的元数据(所有Kubernetes资源对象都有元数据),而LimitRangeSpec本质上是一个包含LimitRangeItem类型数组的结构体。LimitRangeItem是对具体Kubernetes对象类型应用其能够使用的资源列表的设定值,其中资源列表是键为资源名值为整型或字符串类型的map结构。

​ 最后,看一个具体的例子:limit-range.yaml。该Kubernetes资源文件描述了一个LimitRange对象(由kind字段指定)。

在这里插入图片描述

​ 与定义Kubernetes其他对象(pod等)的资源文件一样,该yaml文件的kind字段表明该资源文件定义的是LimitRange对象。spec.limits.type字段指定应用限制的对象,这里分别是pod和containero spec.limits.max和spec.limits.min字段分别表示资源列表上限与下限,该文件定义的资源列表包含两个资源类型:内存和CPU。该文件表明,应用到namespace中每个pod的资源限制均为:最大内存1 Gi,最小内存6Mi,最大CPU计算资源2,最小CPU计算资源200m(即0.2 );spec.limits.default和spec.limits.defaultRequest字段分别表示资源列表的默认请求上限和默认请求下限,同样包含了CPU和内存两种资源类型。如果用户在创建pod时未指定spec.container[].resources.limits和spec.container[].resources.requests,这两个值将会被启用。此处应用到namespace中每个容器的资源限制为,默认请求下限:CPU200m,内存1 OOMi ;默认请求上限:CPU300m,内存200Mi。

​ 接下来我们将从代码的角度,简要分析下LimitRanger插件的实现原理:

  • 首先,向admission control注册一个名为LimitRanger的插件。
  • 然后,实现Admit方法。该方法首先获取发起API请求所在的namespace中的LimitRange对象列表。遍历该LimitRange对象列表,执行如下检查:
    • 对于.spec.container.resources.limits和.spec.container.resources.requests字段为空的manifest,填入LimitRange设定的默认值。
    • 对于pod中的每个container,检查其.container.resources.limits和.container.resources.requests是否满足LimitRange的.spec.limits.max, .spec.limits.min和.spec.limits.maxLimitRequestRatio的设定。如果不满足,则拒绝该请求。

​ LimitRanger插件只适用于Kubernetes对象创建(CREATE)和更新(UPDATE)操作,并不受理删除操作。需要注意的是,一个namespace中可能存在不止一个LimitRange对象,因此,任何一个针对Kubernetes对象的创建和更新操作都要接受该namespace中所有LimitRange对象的限制。

SecurityContextDeny插件

​ pod manifest中的security context定义了应用于容器的安全设置(如uid. gid, SELinux角色等),包括pod级别和容器级别的限制。SecurityContextDeny插件会拒绝任何定义了其中某些字段的pod。

​ SecurityContex取在pod创建(CREATE)和更新(UPDATE)时发生作用。它的Admit函数逻辑如下:

  • 检查REST资源类型,如果不是pod,则接受该请求。
  • 检查pod级别的SecurityContext。如果.supplementalGroups, .seLinuxOptions, .runAsUser或.fsGroup不为空,拒绝该API请求。
  • 逐一检查容器级别的SecurityContext。如果.seLinuxOptions, .runAsUser不为空,则拒绝该请求。

ServiceAccount插件

​ service account为pod中的进程提供id。实际上,当用户试图与APIServer打交道时,往往通过user account来进行身份的认证及授权;类似地,集群中的pod也可能希望与APIServer通信,系统并不为其创建user account,而作为代替的就是service account。

​ 如果用户启用了service account自动生成的功能,controller就会接管这项工作,主要涉及了3个层面,分别对应service account admission controller, token controller和service account controllero这里我们主要关注第一个。

service account插件在pod创建(CREATE)时发挥作用,其Admit函数包括如下检查:

  • 如果创建的pod是mirror pod,且其.spec.serviceAccountName或volumes.VolumeSource.secret不为空,则拒绝该请求。
  • 如果创建的pod的.spec.serviceAccountName为空,则将该字段设为同一namespace下的default service account。
  • 检查pod引用的service account是存在的,如不存在拒绝该请求。
  • 查找service account对应的secret token,如该pod中未存在该volume,则为其挂载。

ResourceQuota插件

​ ResourceQuota插件的作用是为特定namespace应用资源使用的配额。与LimitRanger插件类似,为了配合ResourceQuota插件的使用,Kubernetes引人了ResourceQuota对象,用于对特定namespace中的Kubernetes对象设置资源配额。

​ 这里先梳理一下Kubernetes资源的概念。直观地,CPU、内存等通用计算机资源也属于Kubernetes资源类型,在Kubernetes的代码中可以找到以下定义:

在这里插入图片描述

​ 而Kubernetes系统定义的对象类型,譬如pod, service, replication controller, resourcequota
等,也属于Kubernetes资源类型,同样可以在Kubernetes的代码中可以找到以下定义:

在这里插入图片描述

​ 每种Kubernetes资源对象都对应一组元数据,包括Name, Namespace和ResourceVersion,分别表示该资源对象的名字,所在Namespace和资源版本号,其中资源版本号用于标识该资源的新旧程度,方便进行版本和数据一致性控制。

​ Resource0uota的数据结构定义如下所示:

在这里插入图片描述

​ 其中,unversioned.TypeMeta表示ResourceQuota对象的元数据。此外,Resource0uota包含两个数据类型:ResourceQuotaSpec和ResourceQuotaStatus,分别表示特定namespace中预设的资源配额和资源配额的实际使用情况,存储在etcd中的ResourceQuota.Status字段的数据会由controller manager的资源配额管理器根据系统实际的资源使用量而动态更新。

​ 结束了对ResourceQuota对象的讨论后,再来看具体的例子resource-quota.yaml,该资源文件描述了一个ResourceQuota对象(见kind字段)。

在这里插入图片描述

如上所示,spec:hard即资源配额列表,其各字段的含义和单位如表所示。

在这里插入图片描述

ResourceQuota插件只检验创建和更新资源的API请求,其一般过程如下所示:

  • 首先检查该API操作对象是否在ResourceQuota资源列表内,及该操作是否会影响资源对象的数量,如不满足,则接受该API请求。
  • 检查该资源对象所在的namespace是否有ResourceQuota对象,如没有,则接受该API请求。
  • 遍历所有与该资源对象相关的ResourceQuota,根据操作资源对象的不同,检查其.spec定义是否符合要求。以pod为例,如果在ResourceQuota对象中对于cpu进行了定量限制,那么则要求所有在该namespace中的pod必须定义.spec.containers.resource下的cpu值。
  • 根据API请求的资源需求量,检查资源请求量总和是否超过.status.hard的限定,如果超过,则拒绝该请求。对于不同的API请求操作,计算资源请求量总和的方法各不相同。
    • 如果请求的类型是CREATE,资源请求量总和为请求的资源需求量与当前.status.used中对应的资源使用量求和。
    • 如果请求的类型是UPDATE,资源请求量总和为请求的资源更新值(请求值减去原先值)与当前.status.used中对应的资源的使用量求和。
  • 对于每个ResourceQuota,更新其对应的资源对象数目及.status.used,并在etcd中持久化该更新。

原文链接:https://blog.csdn.net/fy_long/article/details/88570104?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165277103516782248556448%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165277103516782248556448&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-12-88570104-null-null.nonecase&utm_term=%E8%B5%84%E6%BA%90

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享
评论 抢沙发
头像
文明发言,共建和谐米科社区
提交
头像

昵称

取消
昵称表情图片